fTLD DMARC：金融機関における電子メールセキュリティのベストプラクティス

組織は毎日、数え切れないほどの電子メールを送受信しているが、そのすべてが安全とは限らない。銀行や保険業者にとって、これらのメッセージを安全に保つことは、顧客と評判の両方を守るために非常に重要です。この必要性を認識し、2023年にfTLDは.BANKと.INSURANCEのトップレベルドメイン（TLD）にパブリックサフィックスドメイン（PSD）用のDMARCを導入し、レジストリレベルの自動的な電子メール保護レイヤーを提供しました。

PSD DMARCとは？

パブリックサフィックスドメインDMARC（PSD DMARC）は、.BANKと.INSURANCEというTLDの下に登録されたすべてのドメインに、ベースラインのメール認証ルールを適用するセキュリティ対策です。ドメイン所有者が個別に実装しなければならない従来のDMARCとは異なり、PSD DMARCはレジストリレベルで運用されるため、すべてのドメインで一貫した保護が保証されます。

この開発は インターネット技術タスクフォース（IETF）で正式に文書化されています。 RFC 9091.fTLDはInternet Corporation for Assigned Names and Numbers (ICANN)の承認を得て、この自動セーフガードの実装が可能になりました。

fTLDとは？

fTLDレジストリは .BANKおよび .INSURANCE.fTLDレジストリは、これらのドメインにサイバー攻撃や詐欺に対する強力なシールドを提供することを目的としています。

fTLD (.BANK / .INSURANCE) ドメインコンプライアンスチェックリスト

このチェックリストは、レジストラントが電子メール認証および暗号化（TLS）要件に準拠するのに役立ちます。 fTLDドメインの要件を遵守するのに役立ちます。

1.電子メール認証要件

必須DNSレコード

有効な 有効なDMARCレコードドメインの有効なDMARCレコードを発行する（ドメインがメールを送信するかどうかにかかわらず必要）。以下の少なくとも1つを発行する：

• SPF(送信者ポリシーフレームワーク）レコード
• DKIM(DomainKeys Identified Mail）レコード

DMARCポリシー要件

推奨DMARC設定

必須条件ではありませんが、fTLD は以下のような厳格なアライメントを推奨しています。 SPFとDKIMタグを使用することを推奨します。DMARCを公開する組織ドメインでは、適切なsp:タグを設定し、サブドメインポリシーを定義する。

コンフィギュレーションの利点：

• 電子メール認証により、お客様のドメインを装ったなりすましメールや詐欺メールを防止します。
• 信頼とメール配信の可能性を高める

2.暗号化／トランスポート・レイヤー・セキュリティ（TLS）要件

デジタル証明書

• ドメインとすべてのサブドメインの有効なTLS証明書を取得します。
• 禁止されている暗号コンポーネントが使用されていないことを確認する（以下のリストを参照）。

HTTPSの実施

• すべてのドメインとサブドメインのトラフィックをHTTPS（暗号化）に強制する。
• HTTPのURLはすべて、自動的にHTTPSにリダイレクトされなければならない。
• リダイレクトは、fTLDドメインのHTTPSバージョンから発信される必要があります。
• ドメインはHTTPS専用でなければならない（暗号化されていないアクセスはできない）。

禁止されている暗号スイート・コンポーネント

ガイドラインでは、TLSの設定や証明書に以下のものを使用したり、含めたりしないよう勧告している：

Anon、CBC、DES、3DES、FIPS、GOST 28147-89、IDEA、SEED、WITH_SEED、MD5、NULL、SHA1、RC4、EXPORT、EXPORT1024、SRP

コンフィギュレーションの利点

• ウェブや電子メールでの安全で暗号化された通信を保証します。
• データ改ざん、傍受、盗聴の防止

コンプライアンスの総括

• DMARC(p=reject)とSPF/DKIMの発行と実施
• すべてのサービスにTLS v1.1+を導入する。
• すべてのHTTPをHTTPSにリダイレクトする
• 承認された暗号スイートのみを使用する
• 強制 DMARCポリシーメール設定後90日以内

DMARCがfTLDにとって重要な理由

DMARCは以下のような利点があるため、金融ドメインにとって非常に重要である： 

不正なドメイン使用を防ぐ

A p=拒否ポリシーは、認証に失敗したメールをすべてブロックするよう、世界中のメールサーバーに直接指示するものである。この措置により、犯罪者がフィッシング攻撃で金融ドメインを直接詐称することを効果的に防ぐことができる。

メールの配信性を高める

DMARCを適切に設定することで、送信者のレピュテーションが向上し、信頼性の高い、手間のかからない公式通信の配信が促進されます。

規制遵守をサポート

金融セクターには 法律や規制.DMARCは、組織がサイバーセキュリティの要件を満たすための重要な技術的コントロールとして機能する。

財務上の損失のリスクを軽減

電子メールベースの攻撃を防止することで、規制当局による罰金、修復費用、風評被害など、データ漏洩に関連する深刻なコストを回避することができます。

DMARC実装のベストプラクティス

電子メール認証の実装には、理路整然としたアプローチが要求される。

1.p=拒否を急がない

最終的なコンフィギュレーションは、拒否のポリシーであるべきだ。(p=reject)でなければならない。ただし、この措置は、p=noneとp=quarantineで一定期間ドメインを監視した後、慎重に行う必要があります。fTLDのガイドラインでも、施行までに90日間の猶予期間を設けています。

2.SPFとDKIMのアライメントの確認

SPFとDKIMはどちらも、認証されたメール送信元ごとに正確な設定が必要です。これらの認証メカニズムで使用されるドメインは、顧客が目にする「From:」ドメインと一致していなければなりません。

3.DMARCレポート分析ツールの使用

DMARCは、ドメインの電子メールトラフィックに関する重要なデータを含む集計レポート（RUA）とフォレンジックレポート（RUF）を生成しますが、直感的または人間が読めるものではありません。専用の DMARCレポートアナライザーは、この情報を解析し、理解しやすくします。

4.社内メールポリシーとベンダーメールポリシーの整合

教育機関に代わって電子メールを送信するすべてのサードパーティ・サービスは、認証ニーズ に適合していなければならない。この点については、これらのベンダーとのコミュニケーションが重要である。

共通の課題

組織はDMARCの採用プロセスにおいて、いくつかの技術的なハードルに直面するかもしれない。

第三者送信者の発見

電子メールを送信するすべての外部サービスの包括的なインベントリは、多様な技術スタックを持つ大規模な組織や企業にとって複雑な作業となる可能性があります。

DNSの伝播遅延

DMARC、SPF、DKIMはDNSを通じて設定される。これらのレコードの更新は、インターネットを伝搬するのに時間を要し、展開スケジュールに遅延を生じさせる要因となる。

DMARCレポートデータの管理

DMARCレポートから得られる生のXMLデータは高密度で膨大です。専門プラットフォームなしでの分析は、非常に困難で非効率的です。

推奨ツールとプロバイダー

DMARCデータは大量かつ複雑であるため、手作業による管理は現実的ではありません。効果的な監視には、専門的なプラットフォームが不可欠です。プロバイダーに求められる主な機能は以下の通りです：

インテリジェントなレポートの可視化

プラットフォームは、生のXMLデータを、トレンドや脅威を示す明確で実用的なダッシュボードに変換しなければならない。

送信者の識別

このサービスは、電子メールの送信元を自動的に分類し、正当な送信者ごとに必要な認証手順について明確なガイダンスを提供する必要がある。

プロアクティブ・スレット・アラート

また、認証の失敗や新たななりすましの試みをリアルタイムで通知し、迅速なセキュリティ対応を可能にするプラットフォームであれば、大きなプラスとなる。

PowerDMARCのプラットフォームは、マネージドEメール認証サービス一式を提供します。私たちの DMARC アナライザーは、複雑な XML レポートを人間が読めるグラフに変換し、脅威を明確に可視化します。DMARCアナライザー PowerSPFツールは、複雑なSPFレコードを動的に最適化することで、検証エラーを防ぎ、正当な送信者がすべて認証されるようにします。

さらに、電子メールにロゴを表示するHostedBIMIや、転送中の電子メールを暗号化するMTA-STSなどの高度な標準の導入を簡素化します。

最終的な感想

結局のところ、DMARCの採用は、.BANK.comを利用するすべての機関にとって中核的な運用要件となります。 .BANKおよび .INSURANCETLDを利用する機関にとって、DMARCの採用は運用上の中核要件です。DMARCは、金融機関のブランド防衛、顧客保護、規制上の義務を果たすために不可欠な技術です。

完全なコンプライアンスへの道は、メール状況を完全に可視化するためのモニター専用ポリシーから始まります。その後、組織は合法的な送信者を体系的に認証し、最終的な拒否ポリシーへと移行することができます。DMARCサービスの専門家とパートナーシップを組むことで、この移行のリスクを軽減し、持続的なセキュリティを確保することができます。

ファイナンシャル・ドメインを確保する準備はできていますか？当社の DMARCコンプライアンスソリューションをご覧ください。

よくあるご質問

fTLDのDMARC要件は、私のドメインのメールにどのような変化をもたらしますか？

どのように影響するかは、現在のセットアップ次第だ：

• すでにDMARCレコードをお持ちの場合：既存のメールポリシーやレポートは変更されません。PSD DMARCは単に強力なバックアップとして機能します。
• DMARCレコードがない場合：これは、セキュリティの大きな向上です。PSDのDMARCポリシーは、メールプロバイダに詐欺メールに対する明確な指示を与えます。この保護は、プライマリWebサイト、パークドメイン、防御目的で所有するドメインなど、登録されているすべてのドメインに適用されます。

fTLD DMARCは、私のEメールから収集されるデータを変更しますか？

すでに独自のDMARCポリシーを持っている場合、報告データに変更はありません。主な変更点は、fTLDがアクティブに公開されていないドメイン（防御登録など）、または存在しないドメインに対するなりすまし試行について、高レベルの集計レポートを受け取ることができるようになったことです。このデータは、システム全体の健全性を監視するのに役立ちます。

fTLDはこのデータをどのように利用しているのか？

その目的は、.BANKと.INSURANCEコミュニティを保護することです。fTLDは、この集約データを使用して、新たな脅威を発見し、悪意のある活動を特定し、セキュリティコンプライアンスを実施し、これらのTLDの全体的な安定性と安全性を高めます。

詳しい情報はどこにありますか？

• 技術標準：IETFの公式仕様であるRFC9091を読むことができる。
• PSD DMARCの詳細 公式 PSD DMARC ドキュメントをご覧ください。

fTLD固有の規則：DMARCのセキュリティ要件は、.BANKと.INSURANCEのレジストリのウェブサイトで直接確認できます。 レジストリのウェブサイト.