fTLD fTLDにおけるDMARC要件と金融機関向けメールセキュリティ対策をイメージした画像

fTLD DMARCの概要と金融機関向けメールセキュリティ対策

金融機関向けfTLD DMARC運用の要点


著者: Yunes Tarada
翻訳: 東條 百々朱

この記事はPowerDMARCのブログ記事 fTLD DMARC: Email Security Best Practices for Financial Institutions の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

主なポイント

  1. fTLD DMARCは、SPF、DKIM、およびDMARCアライメントを組み合わせた厳格な認証によって、正当なメール送信者を検証します。
  2. .BANKおよび.INSURANCEドメインでは、すべてのドメインでp=rejectポリシーの適用が必須となっており、不正なメール送信を防止します。
  3. DMARCを適切に導入することで、ドメインの信頼性が向上し、メールの到達率改善にもつながります。
  4. コンプライアンス要件を満たすことで、金融業界におけるサイバーセキュリティ規制への対応を支援するとともに、詐欺による金銭的損失のリスクを軽減できます。
  5. DMARCレポートを継続的に監視し、ベンダの認証設定との整合性を維持することで、すべてのメール送信元に対する継続的な保護とコンプライアンスを実現できます。

企業では毎日膨大な数のメールが送受信されていますが、そのすべてが安全とは限りません。
銀行や保険会社にとって、メールを安全に保護することは、顧客や企業への信頼を守るために欠かせません。

こうした背景を受け、fTLDは2023年に、.BANKおよび.INSURANCEトップレベルドメイン（TLD）向けにPublic Suffix Domain（PSD）DMARCを導入しました。
これにより、レジストリレベルでメールを自動的に保護できる仕組みが実現しました。

PSD DMARCとは？

Public Suffix Domain（PSD）DMARCは、.BANKおよび.INSURANCETLD配下のすべての登録ドメインへ共通のメール認証ポリシーを適用する仕組みです。
従来のDMARCでは、各ドメイン所有者が個別にDMARCレコードを設定する必要がありました。

一方、PSD DMARCはレジストリレベルで機能するため、すべての登録ドメインに対して一貫した保護を実現します。
この仕組みは、Internet Engineering Task Force（IETF）が策定した標準に基づいており、RFC 9091として正式に文書化されています。
fTLDはInternet Corporation for Assigned Names and Numbers（ICANN）の承認を受け、この自動保護機能を実装しました。

fTLDとは？

fTLD Registryは、.BANKおよび.INSURANCEドメインを管理するレジストリです。
これらは、銀行、保険会社、保険代理店のみが利用できる、金融業界向けの高い信頼性を備えたドメインです。
fTLD Registryは、これらのドメインをサイバー攻撃や詐欺から保護することを目的としています。

fTLD（.BANK／.INSURANCE）ドメインのコンプライアンスチェックリスト

このチェックリストは、fTLDが定めるメール認証およびTLS暗号化の要件を満たすために役立ちます。

1.メール認証要件

必須DNSレコード
メール送信の有無にかかわらず、有効なDMARCレコードを公開してください。
また、次のいずれかを少なくとも1つ設定する必要があります。
  • SPF（Sender Policy Framework）
  • DKIM（DomainKeys Identified Mail）
DMARCポリシー要件
ドメインの利用状況 必須DMARCポリシー 備考
メール送信を行わないドメイン p=reject スプーフィングや不正なメールの送信を防止します。
メール送信を行うドメイン p=reject（本番運用では必須） 導入時はp=noneまたはp=quarantineから開始できますが、できるだけ早く、遅くとも90日以内にp=rejectへ移行する必要があります。
推奨されるDMARC設定
必須ではありませんが、fTLDではadkim=sおよびaspf=sによる厳格なアライメントを推奨しています。
組織ドメインでDMARCを公開する場合は、サブドメインポリシーを定義するため、適切なsp=タグも設定してください。
この設定のメリット
メール認証により、自社ドメインを悪用したスプーフィングや不正メールを防止できます。
ドメインの信頼性が向上し、メールの到達率改善にもつながります。

2.暗号化／Transport Layer Security（TLS）要件

TLS証明書
ドメインおよびすべてのサブドメインで、有効なTLS証明書を使用してください。
また、後述する使用が推奨されていない暗号スイート要素が含まれていないことを確認してください。
HTTPSの強制
すべてのドメインおよびサブドメインはHTTPSのみで公開してください。
HTTPでアクセスした場合は、自動的にHTTPSへリダイレクトされるよう設定する必要があります。
暗号化されていないHTTP通信を許可してはいけません。

接続の種類 要件 備考
Web接続 TLS 1.2以上を維持する 古いTLSバージョンは、ブラウザのセキュリティ教育など特別な用途で一時的に使用される場合がありますが、推奨されません。
サーバ間メール通信 TLS 1.1以上を優先して使用する 相手先がfTLD以外のドメインでTLSに対応していない場合のみ、古いTLS/SSLまたは平文通信が許可されます。
その他のサービス TLS 1.1以上を使用する 現時点ではTLS 1.0を直ちに無効化する必要はありません。
RFC 5746（Transport Layer Security Renegotiation Indication Extension） 実装必須 TLS接続へ悪意のあるデータを挿入する中間者攻撃を防止します。
使用が推奨されていない暗号スイート要素
TLS設定および証明書では、次の暗号スイート要素は使用しないでください。
Anon、CBC、DES、3DES、FIPS、GOST 28147-89、IDEA、SEED、WITH_SEED、MD5、NULL、SHA1、RC4、EXPORT、EXPORT1024、SRP
この設定のメリット
Webサイトやメール通信を安全に暗号化できます。
データの改竄や盗聴、通信の傍受を防止できます。
コンプライアンス要件の概要
fTLDの要件を満たすためには、以下のポイントを押さえる必要があります。
  • DMARC（p=reject）を適用し、SPFおよびDKIMも設定する
  • すべてのサービスでTLS 1.1以上を実装する
  • すべてのHTTPアクセスをHTTPSへリダイレクトする
  • 推奨された暗号スイートのみを使用する
  • メール運用開始後90日以内にDMARCポリシーをp=rejectへ移行する

fTLDでDMARCが重要な理由

金融機関向けドメインでは、DMARCは次のような重要な役割を果たします。

ドメインの不正利用を防止する
p=rejectポリシーは、認証に失敗したメールを拒否するよう受信側メールサーバへ指示します。
これにより、攻撃者が金融機関のドメインになりすましてメールを送信することを効果的に防止できます。
メールの到達率を向上させる
適切に設定されたDMARCは送信ドメインの信頼性を高め、正規のメールが受信者へ届きやすくなります。
規制要件への対応を支援する
金融業界では、多くの法令や規制への対応が求められます。
DMARCは、サイバーセキュリティ要件を満たすための重要な技術的対策の一つです。
金銭的損失のリスクを軽減する
メールを悪用した攻撃を防止することで、情報漏洩による規制当局からの制裁金や復旧費用、ブランドイメージの低下など、大きな損失を防ぐことができます。

DMARC導入のベストプラクティス

DMARCを安全に導入するには、段階的に運用を進めることが重要です。

1.すぐにp=rejectへ移行しない
最終的にはp=rejectポリシーを適用する必要がありますが、まずはp=noneやp=quarantineで運用しながら状況を監視し、問題がないことを確認してから移行しましょう。
fTLDでも、p=rejectへの移行まで90日間の猶予期間が設けられています。
2.SPFとDKIMのアライメントを確認する
SPFとDKIMは、すべての正当なメール送信元について適切に設定する必要があります。
また、認証で使用するドメインは、受信者に表示される「From:」ヘッダのドメインと一致していなければなりません。
3.DMARCレポート分析ツールを活用する
DMARCでは、集計レポート（RUA）およびフォレンジックレポート（RUF）が生成されます。
これらはXML形式で提供されるため、そのままでは内容を把握することが困難です。
専用のDMARCレポート分析ツールを利用することで、レポートを分かりやすく可視化し、問題の早期発見につなげることができます。
4.社内とベンダの認証ポリシーを統一する
自社ドメインを利用してメールを送信するすべてのサードパーティーサービスは、自社の認証ポリシーに準拠している必要があります。
そのため、ベンダと連携しながら認証設定を管理することが重要です。

よくある課題

DMARCを導入する際には、次のような課題が発生することがあります。

サードパーティー送信元の把握
多くのシステムを利用している大規模な組織では、自社ドメインを利用してメールを送信しているすべてのサービスを把握することは容易ではありません。
DNS反映の遅延
DMARC、SPF、DKIMはDNSレコードによって設定されます。
そのため、設定変更がインターネット全体へ反映されるまでに時間がかかり、導入スケジュールへ影響する場合があります。
DMARCレポートの管理
DMARCレポートは大量のXMLデータで構成されているため、専用ツールを使用せずに分析することは非常に困難です。

推奨ツールおよびサービス

DMARCデータは量が多く内容も複雑なため、手作業で管理するのは現実的ではありません。
そのため、専用プラットフォームの活用をおすすめします。
サービスを選定する際は、次のような機能が備わっているか確認しましょう。

分かりやすいレポート表示
XMLデータを見やすいダッシュボードへ変換し、送信状況や脅威の傾向を把握しやすくできることが重要です。
メール送信元の識別
メール送信元を自動的に分類し、それぞれの送信元に必要な認証設定を分かりやすく案内できることが望まれます。
リアルタイムの脅威通知
認証失敗や新たなスプーフィング攻撃をリアルタイムで通知し、迅速な対応を支援する機能があると安心です。
PowerDMARCでは、包括的なマネージドメール認証サービスを提供しています。
DMARC分析ツールは、複雑なXMLレポートを見やすいグラフへ変換し、脅威の状況を容易に把握できます。

PowerSPFは、複雑なSPFレコードを自動的に最適化し、検証エラーを防止するとともに、正当な送信元をSPFへ適切に登録できるよう支援します。
さらに、メールへブランドロゴを表示するHosted BIMIや、送信中のメールを保護するMTA-STSなど、高度なメール認証技術も簡単に導入できます。

まとめ

DMARCの導入は、.BANKおよび.INSURANCEドメインを利用するすべての金融機関にとって、重要なセキュリティ要件です。
DMARCは、ブランドを保護し、顧客を守るとともに、業界の規制要件へ対応するうえで欠かせない技術となっています。

DMARCを導入する際は、まずp=noneによる監視専用ポリシーから開始し、メール送信環境全体を把握することが重要です。
その後、すべての正当な送信元でSPFおよびDKIMを適切に設定し、最終的にp=rejectポリシーへ移行することで、より強固なメールセキュリティを実現できます。

また、DMARC専門ベンダと連携することで、導入時の負担を軽減しながら、安全で継続的な運用を実現できます。
金融機関のドメインを十分に保護する準備はできていますか。
PowerDMARCのDMARC Complianceソリューションを活用して、DMARCの完全適用に向けた取り組みを始めましょう。

よくある質問

fTLD DMARC要件は、自社ドメインのメール運用へどのような影響がありますか？
現在のメール認証の設定状況によって影響は異なります。
  • すでにDMARCレコードを設定している場合は、現在のDMARCポリシーやレポート内容に変更はありません。
    PSD DMARCは、既存のDMARC設定に追加される保護層として機能します。
  • DMARCレコードを設定していない場合は、PSD DMARCによって、メールセキュリティを大幅に強化できます。
    メールサービスプロバイダはPSD DMARCポリシーに基づき、不正なメールをより適切に処理できるようになります。
    この保護は、メインサイトのドメインだけでなく、メール送信を行わない保有ドメインや、防御目的で取得したドメインにも適用されます。
fTLD DMARCによって収集されるメールデータは変わりますか？
独自のDMARCポリシーをすでに運用している場合は、DMARCレポートの内容に大きな変更はありません。
主な違いは、fTLDがDMARCを公開していないドメイン（保有ドメインや防御目的のドメインなど）や、存在しないドメインへのスプーフィング攻撃に関する集計データを取得できるようになる点です。
このデータは、.BANKおよび.INSURANCE全体の健全性や脅威の状況を把握するために利用されます。
fTLDはこのデータをどのように利用しますか？
目的は、.BANKおよび.INSURANCEコミュニティ全体の安全性を向上させることです。
fTLDは集計データを分析し、新たな脅威の検知、不正利用の把握、セキュリティコンプライアンスの強化に役立てています。
これにより、.BANKおよび.INSURANCEドメイン全体の安定性と安全性の向上につながります。
詳細情報はどこで確認できますか？