DMARCレポートとは
DMARCは、 Domain-based Message Authentication, Reporting, and Conformance の略です。これは、電子メールフィッシング および スプーフィングに対する保護に役立つ電子メール認証プロトコルです。
電子メールの送信時に、DMARCにより、ドメイン所有者は、SPF (Sender Policy Framework) や DKIM (DomainKeys Identified Mail)など、どの認証方式を使用して、電子メールの信頼性を検証するかを指定するDNSレコードを設定できます。電子メールがこれらの認証チェックに失敗した場合、DMARCは、受信者の電子メールプロバイダーに、そのメッセージを隔離するか、完全に拒否するかのいずれかの処理方法を指示します。
電子メールのフィッシングやスプーフィング攻撃がより巧妙化し、蔓延している今日のインターネットにおいて、DMARCは、ますます重要になってきています。DMARCを導入することで、ドメイン所有者は、信頼の喪失、風評被害、金銭的損失など、これらの攻撃による悪影響から自社ブランドと顧客を保護できます。
DMARCは、フィッシングやスプーフィング攻撃からの保護に加え、 レポートの機能も提供します。ドメイン所有者は、どのメッセージがDMARCチェックに合格したか、不合格になったか、およびこれらのメッセージの発信元など、メール認証アクティビティに関するレポートを受け取ることができます。
DMARC管理では、ドメインに対するDMARCポリシーの設定とメンテナンスを行います。効果的なDMARC管理には、メール認証活動の継続的な監視と分析、および必要に応じてDMARCポリシーの調整と更新を行う機能が必要です。
効果的なDMARC管理の主要な要素には、以下のものがあります：
- DMARCポリシーの設定：ドメインのDMARCレコードを設定し、認証チェックに失敗したメッセージを処理するための適切な認証方法とポリシーを指定することが含まれます。DMARC DNSレコードとは、どのようなものかは、以下の通りです：
v=DMARC1; p=reject; rua=mailto:[email protected]
これは、DMARCバージョン1を使用すること、DMARCチェックに失敗した場合、ポリシーは、メールを拒否すること、プロバイダーがDMARCレポートを送信するメールアドレスを指定します。
- 電子メール認証アクティビティの監視：電子メールのセキュリティと配信到達性を確保し、業界標準や規制に準拠するために、DMARCレポートは、ドメイン所有者にとって重要なツールです。DMARCレポートを定期的に監視、分析することで、ドメイン所有者はメールの脅威を特定し、メールキャンペーンを最適化し、メール認証全体を改善できます。
- 必要に応じた調整：DMARCレポートの分析に基づき、ドメイン所有者は、メールメッセージが適切に認証され、フィッシングやスプーフィング攻撃から確実に保護されるように、DMARCポリシーや認証方法を調整する必要がある場合があります。
- メールプロバイダーやサードパーティベンダーとの連携：効果的なDMARC管理には、DMARCポリシーが適切に実装、実施されるように、メールプロバイダーやサードパーティベンダーとの協力が必要な場合があります。
本日、 DMARC管理を開始しました。これが、構築方法です。
構築方法
クラウドベースのセキュリティおよびパフォーマンスソリューションのリーディングプロバイダーとして、私たちCloudflareは、製品のテストに特定のアプローチを採用しています。私たちは、当社独自のツールやサービスを「ドッグフーディング」し、つまり、そのツールやサービスを使用して、ビジネスを運営しているのです。これにより、お客様に影響を与える前に、問題やバグを特定できます。
開発者が当社のグローバルネットワーク上でコードを実行できるサーバーレスプラットフォームであるCloudflare Workersなどの当社独自の製品を社内で使用しています。2017年の発売以来、Workersのエコシステムは大きく成長しました。現在、数千人もの開発者がこのプラットフォーム上でアプリを構築し、デプロイしています。Workersエコシステムの威力は、これまで、クライアントの近くで実行することが不可能、あるいは非現実的であった高度なアプリを開発者が構築できるようにする能力にあります。Workersは、APIの構築、動的コンテンツの生成、画像の最適化、リアルタイム処理の実行など、さまざまに使用することができます。その可能性は、事実上無限です。Workersを使用して、Radar 2.0などのサービスや、Wildebeestなどのソフトウェアパッケージを提供しました。
最近、当社の Email Routingの製品が Workers と提携し、Workersスクリプトを介し、受信メールを処理できるようになりました。 ドキュメント に記載されている通りです：「Email Workersで、Cloudflare Workersの力を活用して、メールを処理し、複雑なルールを作成するために必要なロジックを実装できます。これらのルールは、お客様がメールを受信したときに何が起こるかを決定します。」ルールと検証済みアドレスはすべて、当社の APIを介して設定できます。
簡単なEmail Workerとは、どのようなものかは、以下の通りです：
export default {
async email(message, env, ctx) {
const allowList = ["[email protected]", "[email protected]"];
if (allowList.indexOf(message.headers.get("from")) == -1) {
message.setReject("Address not allowed");
} else {
await message.forward("inbox@corp");
}
}
}かなり簡単ですよね？
プログラムに、受信メールを処理する機能が備わっているため、スケーラブルかつ効率的な方法で、DMARCレポートメールの受信を処理するのに最適な方法のように思えました。Email RoutingとWorkersは、世界中から無限の数のメールを受信するという激務をこなすことができます。必要なものの概要は以下の通りです：
- メール受信とレポート抽出
- 関連する詳細を分析プラットフォームに公開
- 生レポートを保存
Email Workerにより、#1を簡単に行うことができます。メール()ハンドラーを使用してワーカーを作成するだけです。このハンドラーは SMTP エンベロープ要素、メールヘッダーを事前に解析したバージョン、生の電子メール全体を読み取るストリームを受け取ります。
#2では、Workersプラットフォームも、調べることができ、Workers Analytics Engineを見つけることができます。適切なスキーマを定義する必要がありますが、これはレポートの中に含まれるものと、後で行う予定のクエリの両方に依存します。その後、GraphQLまたはSQLAPI のいずれかを使用してデータをクエリーできます。
#3では、 R2オブジェクトストレージ以上のものを探す必要はありません。WorkersからR2にアクセスするのは簡単です。電子メールからレポートを抽出した後、今後のためにR2に保存します。
これをゾーンで有効にできるマネージドサービスとして構築し、利便性のためにダッシュボードインターフェイスを追加しましたが、実際にはすべてのツールが利用可能で、サーバー、スケーラビリティ、パフォーマンスを心配することなく、お客様自身のアカウントで、Cloudflare Workers上に独自のDMARCレポートプロセッサをデプロイできます。
アーキテクチャ
Email Workers は、Email Routingの製品の機能です。Email Routingコンポーネントは全てのノードで実行されるため、ノードのうちのいずれかが、受信メールを処理できます。これは、全てのデータセンターからEmailイングレスBGPプレフィックスをアナウンスするため、重要です。Email Workerへのメールの送信は、Email Routingのダッシュボードでルールを設定するのと同じくらい簡単です。
Email Routingコンポーネントが、Workerに配信されるルールに一致する電子メールを受信すると、最近、オープンソース化された workerd ランタイムの内部バージョンに接続し、すべてのノード上で実行されます。このインタラクションを管理するRPCスキーマは、 Capnproto スキーマで定義されており、電子メールの本文の読み上げ時に、Edgeworkerにストリーミングできるようにします。Workerスクリプトがこの電子メールを転送することを決定した場合、Edgeworkerは、元のリクエストで送信された機能を使用して、Email Routingに接続します。
jsg::Promise<void> ForwardableEmailMessage::forward(kj::String rcptTo, jsg::Optional<jsg::Ref<Headers>> maybeHeaders) {
auto req = emailFwdr->forwardEmailRequest();
req.setRcptTo(rcptTo);
auto sendP = req.send().then(
[](capnp::Response<rpc::EmailMetadata::EmailFwdr::ForwardEmailResults> res) mutable {
auto result = res.getResponse().getResult();
JSG_REQUIRE(result.isOk(), Error, result.getError());
});
auto& context = IoContext::current();
return context.awaitIo(kj::mv(sendP));
}
DMARCレポートのコンテキスでは、受信メールを処理する方法は、以下の通りです：
- 処理中のメールの受信者を取得します。これは使用されたRUAです。 RUAは、特定のドメインに関する、集約されたDMARC処理フィードバックをどこに報告する必要があるかを示すDMARC構成パラメータです。 この受信者は、メッセージの「to」属性で確認することができます。
const ruaID = message.to
- DMARCのレポートを処理するドメイン数は無限なので、Workers KVを使用して各ドメインに関する情報を保存し、この情報をRUAでキーにしています。 また、このようなレポートを受け取る必要があるかどうか知ることができます。
const accountInfoRaw = await env.KV_DMARC_REPORTS.get(dmarc:${ruaID})
- この時点で、解析するために電子メール全体をarrayBufferに読み込みます。レポートのサイズによっては、無料のWorkersプランの制限に引っかかるかもしれません。このような場合、この問題のないWorkers Unboundリソースモデルに切り替えることをお勧めします。
const rawEmail = new Response(message.raw)
const arrayBuffer = await rawEmail.arrayBuffer()
- 生の電子メールを解析するには、特にMIME部分の解析が含まれます。これを可能にするライブラリが複数利用可能です。例えば、postal-mimeを使用することができます：
const parser = new PostalMime.default()
const email = await parser.parse(arrayBuffer)
- 電子メールを解析した結果、その添付ファイルにアクセスできるようになりました。これらの添付ファイルはDMARCレポートそのものであり、圧縮できます。最初にやることは、長期保存用に圧縮形式でR2に保存します。後日、再処理や興味深いレポートの調査に役立ちます。これは、R2バインディングでput()を呼び出すのと同じくらい簡単です。後で検索しやすくするために、レポートファイルは現在の時刻に基づいて、ディレクトリに分散しておくことをお勧めします。
await env.R2_DMARC_REPORTS.put(
`${date.getUTCFullYear()}/${date.getUTCMonth() + 1}/${attachment.filename}`,
attachment.content
)
-
ここで、添付ファイルの MIME タイプを調べる必要があります。DMARCレポートの生の形式はXMLですが、圧縮することができます。この場合、最初に解凍する必要があります。DMARCレポーターファイルは、複数の圧縮アルゴリズムを使用することができます。MIMEタイプを使用して、どの圧縮アルゴリズムを使用すべきか、判断します。Zlibで圧縮されたレポートには、pakoが使用可能で、ZIPで圧縮されたレポートには、unzipitが、良い選択です。
-
レポートの生の XML 形式を取得したので、fast-xml-parserは、それらを解析する上でうまく機能しました。以下は、DMARCレポートのXMLがどういうものかは、以下の通りです：
<feedback>
<report_metadata>
<org_name>example.com</org_name>
<[email protected]</email>
<extra_contact_info>http://example.com/dmarc/support</extra_contact_info>
<report_id>9391651994964116463</report_id>
<date_range>
<begin>1335521200</begin>
<end>1335652599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>business.example</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>business.example</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>business.example</domain>
<result>fail</result>
<human_result></human_result>
</dkim>
<spf>
<domain>business.example</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
- これで、レポート内のすべてのデータがすぐに利用できるようになりました。これからどうするかは、データをどのように表示したいかに大きく依存します。当社の場合、目標は、レポートから抽出した有意義なデータをダッシュボードに表示することでした。そのため、エンリッチされたデータをプッシュできる分析プラットフォームが必要でした。Workers Analytics Engineに入ります。Analytics Engineにより、Workersからデータを送信できるようになるため、このタスクに最適です。GraphQL APIを公開し、その後、データとやりとりができます。このようにして、ダッシュボードに表示するデータを取得します。
将来的には、ワークフローに Queuesを統合して、レポートを非同期的に処理し、クライアントがレポートの完成を待つのを回避することも検討しています。
Workersインフラストラクチャのみに依存してこのプロジェクトをエンドツーエンドで何とか実装を成し遂げ、スケーラビリティ、パフォーマンス、ストレージ、セキュリティの問題を心配することなく、重要なアプリケーションを構築することが可能であり、有利であることを証明できました。
オープンソーシング
先に述べたように、お客様が有効化して、利用できるマネージドサービスを構築し、当社が、お客様に代わり、それを管理します。しかし、当社が行ったことはすべて、お客様のアカウントでデプロイできるため、お客様自身のDMARCレポートを管理できます。これは簡単で、無料です。これを支援するために、上記の方法でDMARCレポートを処理するWorkerのオープンソースバージョンを公開しています。 https://github.com/cloudflare/dmarc-email-worker
データを表示するダッシュボードがない場合は、 WorkerからAnalytics Engineにクエリーを行うことも可能です。また、リレーショナルデータベースに保存したい場合は、 D1 が役立ちます。可能性は無限であり、これらのツールで何を構築するのかを見いだせたら嬉しく思います。
投稿してください、自身のものを作ってください、私たちは耳を傾けます。
最後に
この記事で、Workersのプラットフォームの理解を深めていただけたら幸いです。 今日、Cloudflareはこのプラットフォームを活用して、ほとんどのサービスを構築しています。お客様もそうすべきだと思います。
自由にオープンソースバージョンへ投稿して、それでお客様ができることを私たちに教えてください。
Email Routingは、Email Workers APIをより機能的に拡張することにも取り組んでいますが、これについては、近いうちに別のブログでお話しします。