セキュリティチームでリーダーを務めている藤田です。普段はプロダクトセキュリティの施策を中心に担当しています。
この投稿は、現在進行中の案件に関するものですが、世間で DMARC への対応が話題になっているにも関わらず、業務分担が進んでいる組織や複数のサービスで会社共通のドメインを用いてメールを送信しているような場合になぜ対応が進まないのか、それに対し私たちがどのようにアプローチしているかを示すものです。まだ完璧とはいえる状況ではありませんが、ある程度目処が見えてきたため、ノウハウを共有します。
タイトルの通り技術的なトピックも取り扱いますが、社内での調整や進め方を中心に解説しています。 ステークホルダーが多く、調整に苦労している方や、DMARC 対応を始めたもののレポートの分析に着手できていない方が一歩を踏み出すための助力となれば幸いです。
結論
外部の分析サービスに頼ることなく、AWS を活用しながら DMARC レポート分析基盤を構築しました。 順調に分析と見える化が進み、メール送信しているサービス側やシステム担当者側の理解が深まり、SPF や DKIM への対応について共通言語で語れるようになってきました。
技術スタックは、次のとおりです。
- オープンソースの DMARC レポート分析ツールである「parsedmarc」
- Amazon WorkMail（メール受信できれば何でもよい）
- Amazon OpenSearch Service（Kibana、Grafana、Splunk でもよい）
前提
以下のような用語については、すでに多くの記事等で紹介されているため、知っていることを前提とします。もしご存じでない場合、日経電子版の記事(Gmailに送れなくなる恐れ 迷惑メール対策を大幅強化)や Google 社のガイドライン、RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) 日本語訳 などを参考にたどることができます。
- Header From, Envelope From(Return-Path)といったメール仕様に関する基本用語
- DMARC, SPF, DKIM, ARC ヘッダといったメールセキュリティ用語
- BIMI＝メール送信者のアイコンにブランドのロゴを表示するための標準仕様
DMARC を適切に運用することのメリットとして以下の３つの軸を置いてこの投稿を構成しています。
- 正しく送信したメールが正しく届く
- なりすまし等の不正なメールが正しく隔離される
- 将来的に、BIMI を設定することでメール送信者のブランドイメージを向上させる
DMARC対応が進みづらい理由
DMARC 対応がすぐにうまくいくパターンとしては、単一のドメインで単一のサービスを持つようなドメイン運用の場合です。初期対応は、メール管理者やドメイン管理者が SPF と DKIM を設定したうえで DMARC レコード(p=none)が設定できれば完了となります。次に、SaaS 等を活用して DMARC レポートを分析した上で、p=quarantine や reject といった迷惑メールを防止するための措置をとることでうまくいきます。
しかし、ドメイン運用の複雑さに起因し、DMARC 対応を困難にする課題がいくつかあります。
仮説を交えつつ以下のような状況を想定していますが、多くの企業で同じような課題があるのではないでしょうか。
SPFが設定できない事情がある
これは、企業が単一のドメインで業務メール、CRM、メルマガなどを複数のサービスを用いて運用している場合に起こり得る運用上の課題です。
一般的には、SPF の DNS ルックアップ制限と呼ばれる問題が発生します。つまり、単一のドメインから送信されるメールの送信サーバー（IP アドレス）が多岐にわたる場合、SPF を設定しても認証が通らない可能性があります。これを解決するためには、例えばサービスや役割ごとにメール送信ドメインを分割するなどの運用上の変更が必要となります。ただし、送信元ドメインを分割することは、ドメインの信頼性に影響を与える可能性があるため、迷惑メールとして認識されるリスクを受け入れるかどうかを慎重に検討する必要があります。
ドメインや IP アドレスのレピュテーションに関する情報は、Google のPostmaster Toolsを活用できます。
DMARC対応を始めるための主体がいない
これは、組織体制やサイロによって生じる課題です。
DMARC は親ドメインに設定された場合、サブドメインにもその設定が継承されます。また、サブドメインに設定されている場合には、サブドメインの設定が優先されるという性質を持ちます。
例えば、日経 ID は id.nikkei.com、メルマガなどは mx.nikkei.com といったサブドメインを用いて送信されています。サービスごとに運用チームが分かれていると、各チームが独自に DMARC を設定し、各サブドメインに対して分析を始めることもあります。また、DMARC の重要性を認識していないチームや、「誰かがやってくれるだろう」と考えて DMARC 設定を怠るチームもあるかもしれません。さらに、将来的に BIMI を設定するためには親ドメインに DMARC を設定する必要があります。したがって、nikkei.com 全体の DMARC を適切に運用するには、親ドメインの設定がサブドメインに継承される仕様に従い、業務用、BtoC、BtoB を含むすべての nikkei.com のサブドメインが SPF と DKIM を適切に設定する必要があります。また、組織によっては、海外子会社やサプライチェーンも含まれる可能性があります。これらの理由から、ドメイン運用担当者が DMARC を導入しようとする際には、影響範囲が広いため、リーダーシップを発揮し、関係者を巻き込みながら適切に対応する覚悟が必要です。
メール運用体制の多様化による知識の底上げ
多くのサービスを運用していると、メール送信業務をパートナーに委託したり、外部のメールサービスを契約して利用することがあります。
その際、メール送信担当者が SPF や DKIM などの概念を知らず、初期設定のまま利用していることがあります。そのまま DMARC への対応を始めようとすると、メールサーバ管理者に依頼する前提となるメールセキュリティに関する知識をキャッチアップする必要も出てきます。初期のハードルが高く感じられる可能性があります。
この課題に対処するためには、前述のように、DMARC 対応を始める際に適切なフォローアップを行いながら理解を促進する必要があります。
日経のアプローチ
組織的側面
私が所属するプロダクトセキュリティチームは、全プロダクトを横断的にカバーする組織として機能しています。特定のチームでは進めにくいような横断的な案件に積極的に取り組むことができます。DMARC や迷惑メール対策などのテーマは、広義のセキュリティ対策とも言えますので、当チームが主導して進めることにしました。
対応を始めるにあたりいくつかのチームに声をかけてみたところ、サービスによってはすでに DMARC 対応を進めているところもありました。しかし、p=none で集めた DMARC レポートの分析方法に悩んでいたり、他のチームの対応状況を気にする声もありました。そのため、当チームが情報集約を図ることで、各チームの知識の底上げを促進することができました。
施策的側面
DMARC 対応を始めるにあたり、専門ベンダーのサポートを利用する選択肢も検討しました。
しかし、サポート先からの説明を一次的にセキュリティチームで受け、各部門へ説明することに伴う調整負担や、長期的な視点で各チームが自らダッシュボードを活用し、自発的な改善活動を促進することが望ましいとの考えから、AWS と OSS を活用してダッシュボードを用意することとしました。
技術的側面
DMARC レポートは、メール受信サーバーが不定期に圧縮された XML 形式のファイル（.gz ファイル）を送信するものです。受信した DMARC レポートをパースし、ダッシュボードで閲覧できるようにすることで、気軽に DMARC レポートの分析が行えるようにしました。
次の章で詳しく説明します。
DMARCダッシュボードの展開
DMARC対応の周知
幸いにも、p=none という仕様のおかげで、直ちにメール受信の動作に影響を及ぼさない形で DMARC レコードを設定することができました。
社内の情報共有ツールで、セキュリティチームが DMARC レコードを設定することと同時に、p=none で対応を開始することを周知しました。
各チームの Slack を覗いてみると、この周知を読んで SPF や DKIM の対応を見直しはじめてくれるところと、そうでないところがありました。組織の中での課題を感じながらも、後述の DMARC レポートの分析結果の通知と共に、各チームのメールセキュリティに関する知識や認識を確認するなど、地道な取り組みを行いました。
DMARCレポート分析基盤の構築
長い前置きとなりましたが、技術ブログとしてはこの部分が本題です。
DNS に DMARC レコードを設定する際に、rua 属性や ruf 属性を指定することで、集計レポート（rua）とフォレンジックレポート（ruf）を受け取ることができます。SPF や DKIM の設定状況や設定ミスの有無を確認する観点では、集計レポートの分析のみで十分です。フォレンジックレポートは、正しいメールが届かなかったときに調査する際に有効化することとしました。
集計レポートを分析するための基盤として、次の図のような構成の基盤を構築しました。
parsedmarc
parsedmarc はオープンソースの DMARC レポート分析ツールです。コマンドラインから操作することができ、DMARC レポートに関する ETL（抽出・変換・格納）が提供されています。
詳しくは公式ドキュメントに記載がありますが、簡単に概要を説明します。
- 抽出
- 受信した DMARC レポートの IMAP 監視、POP メール受信、S3 ファイルなどに対応しています
- 変換
- 抽出したメールから xml ファイルをパースし、適切な形式に変換されます
- 格納
- 変換した DMARC レポートを指定した URL（Elasticsearch, Splunk）への送信や、JSON/CSV 形式で S3 に格納できます
Amazon WorkMail
Amazon WorkMail は、安価に利用を始められる IMAP 対応のメールサービスとして適しています。parsedmarc が動作している環境から IMAP 接続して受信することが可能であり、受信後は削除できるため、受信容量も増えません。
Amazon WorkMail で DMARC レポート専用のメールアドレスを取得し、parsedmarc を使用して IMAP 接続して DMARC レポートを受信することができます。parsedmarc は、Amazon WorkMail の IMAP 接続情報を設定し、定期的に DMARC レポートを取得し、解析・処理することができます。
Amazon OpenSearch Service
Amazon OpenSearch Service を使用することで手早く安全な環境を構築することにしました。parsedmarc に付属するダッシュボードテンプレートはKibana、Grafana、Splunk向けに提供されていますが、今回は Amazon OpenSearch Service Dashboards を利用することになりました。
ただし、Kibana のテンプレートを Amazon OpenSearch Service Dashboards 用に直接使用することができず、互換性の問題がありました。そのため、古いバージョンの Kibana テンプレートをインポートし、その後改良して Amazon OpenSearch Service Dashboards で利用することになりました。
DMARCレポートの分析
ダッシュボードを開くと、SPF や DKIM のアラインメント、DMARC のパス率を確認することができます。
メール配信量が多いサービスが SPF や DKIM に対応している場合、メール配信量の少ないドメインの設定漏れや設定ミスが埋もれてしまう可能性があります。そのため、Header From ごとにフィルタをかけて分析を進めます。 チェックしたものから順番にフィルタを除外していくと、すでにサービスが終了しているか、メール送信業務を行っていないはずのサブドメインからメールが送られていることが確認できました。これらがなりすましメールなのか、あるいは把握されていなかっただけで正しい業務として送られたメールなのかを確認していきます。
その他にも、日別の DMARC パス率の推移グラフや、レポート元別統計、Header From 別のメール送信統計などを分析することもできます。
個別の SPF や DKIM のエラー状況を見ることもできるため、「SPF のアラインメントがすべて false になっているメール送信元サーバがある」や、「特定のレポート元（メール受信サーバ）だけ SPF のアラインメントが false になっている」といった状況も把握できます。
前者の場合、メール送信元の SPF や DKIM の設定漏れや設定ミスが考えられます。また、後者の場合、メール受信者がメール転送やメーリングリストを使用していることが考えられ、転送に使われたメールサーバの SPF、DKIM、ARC ヘッダなどの設定を誤っている可能性があります。
DMARC レポートは基本的に Header From のドメインに基づいて送られるため、メール転送やメーリングリストで受信した側の設定不備も、送信元の DMARC 対応状況に影響を与えます。企業向けのメール配信などで受信者と個別の連絡が取れる場合は、SPF や DKIM、ARC ヘッダへの対応を促したり、どうしても難しい場合はメール転送やメーリングリストの使用を回避することで正しくメールを受信できるようになります。一方で、多数の個人向けにメール配信していてメール受信者への個別の連絡が難しい場合は、FAQ や利用規約などで「メール転送やメーリングリストで受信している場合、届かなくなるおそれがある」と明記することも一案です。
チームへの伝達
各チームが気軽にアクセスできるよう、ドキュメントを整備し、サブドメインごとにフィルタをかけた状態のショート URL を用意し、Slack で一斉に連絡しました。
また、チームごとに SPF や DKIM への対応状況が異なるため、壁打ちも兼ねて 1 回 30 分以内で状況の説明と相談会を実施しました。
このような連絡の際に快く受け入れてくださるチームが多く、普段からのコミュニケーションによるセキュリティ文化の醸成が功を奏したと感じています。
日頃からの各チームとの関係づくりの工夫については、Cloud Native Days Tokyo 2023(CNDT2023) でお話させていただきました。（36, 37 スライド目）
現在地点
現在は各部門との連絡や相談も一段落し、部門ごとの個別の課題解決に向けてサポートしている段階です。
今後は、DMARC ポリシーの強化や BIMI の導入によりブランド向上に貢献することを目指して、着実に進めています。
最後に
最後までお読みいただきありがとうございました。 日経における DMARC への対応について、課題感と対応へのアプローチについて紹介させていただきました。 このような取り組みの事例が、誰かのお役に立てると幸いです。
セキュリティチームが各チームに対し、第三者的に「DMARC レポートを見て SPF と DKIM を適切に設定してください」と言うことは簡単ですが、技術的側面から誰もがアクセス可能なダッシュボードを構築し、一歩を踏み出すためのハードルを下げることで、より協力しやすくなったのではないかと感じています。
テクノロジーメディアを目指す日経のプロダクトセキュリティチームでは、Engineering Visionを目指して、日々のセキュリティ推進活動を通じてマネージドな AWS 環境を活用するなど、技術的な取り組みにも挑戦しています。その一方で、事業部門がスピードを損なうことなくセキュリティを担保することをミッションとして活動しています。メディアの未来を共に築く仕事に興味のある方は、ぜひお気軽にご連絡ください。
日経のデジタルサービスを支えるプロダクトセキュリティチームの紹介ページはこちら。 https://hack.nikkei.com/jobs/product_security/
ユーザ企業で勤めるセキュリティ人材には、今回のような、基本的なセキュリティ対策の地道な取り組みを、適切な時期に、適切に企画し、適切に推進できるスキルも求められているような気がします。 業務内容を詳しく知りたい方は、カジュアル面談をお申し込みいただくこともできます。
