決済処理事業者は、デジタル経済において最も標的にされやすい分野の一つで事業を営んでいます。彼らのメールには、決済確認、加盟店通知、請求更新、アカウントアラート、セキュリティメッセージ、運用指示など、顧客やパートナーが信頼することを期待される情報が含まれています。

そのため、メールは重要なセキュリティチャネルとなっています。

攻撃者が決済処理事業者のドメインを偽装したり、従業員になりすましたり、類似したドメインを悪用したりすると、単一のフィッシング攻撃を超えた被害をもたらす可能性があります。これらの攻撃は、顧客の信頼、加盟店の信頼、業務ワークフロー、そして組織の広範なセキュリティ態勢に影響を及ぼす可能性があります。

DMARCは、SPFとDKIMによってサポートされ、受信メールサーバーが組織のドメインから送信されたと主張する認証されていないメッセージを識別できるようにすることで、決済処理事業者が完全一致ドメインスプーフィングのリスクを低減するのに役立ちます。

DMARCはPCI DSSコントロールの代替ではありません。保存されたカード会員データを直接保護するものでもありません。しかし、より広範なPCI DSSコントロール環境内での、フィッシング対策、安全な通信、アクセスリスクの低減、インシデントの可視性という目的をサポートします。

決済処理事業者にとって、メール認証は、単なる配信性の衛生管理ではなく、セキュリティ態勢の一部として扱われるべきです。

I. PCI DSSとメールセキュリティ:適切なフレーミング

PCI DSSは、アカウントデータの保護と、決済環境を支えるシステム、人員、プロセスの保護に焦点を当てています。

PCI DSSは、すべての環境においてDMARC、SPF、またはDKIMを独立した必須技術として規定していません。この基準はセキュリティ目標を設定し、組織がリスク、スコープ、評価要件に基づいて適切なコントロールを実装することを期待しています。

関連する接点はフィッシング対策です。

PCI DSS v4.0は、フィッシング攻撃から人員を検出し保護するメカニズムの要件を導入しました。メール認証は、攻撃者が信頼されたドメインを偽装する能力を低減し、セキュリティチームにスプーフィング試行や未承認のメールソースの可視性を提供することで、この目的をサポートすることができます。

PCI DSSに対してDMARCを位置付ける最も安全な方法は:

DMARCはPCI DSSのフィッシング対策と安全な通信の目的をサポートします。これは、それ自体で完全なPCI DSSソリューションとして提示されるのではなく、階層化されたセキュリティプログラム内の一つのコントロールとして文書化されるべきです。

II. 決済処理事業者が強力なメール認証を必要とする理由

決済処理事業者は、信頼されたメールコミュニケーションに大きく依存しています。

一般的なメールフローには以下が含まれます:

• 取引確認
• 加盟店オンボーディングメッセージ
• 請求および決済通知
• セキュリティアラート
• アカウント確認メール
• パスワードリセットメール
• 規制またはコンプライアンス通知
• サポートコミュニケーション
• 社内財務および運用メッセージ
• サードパーティプラットフォーム通知

これらのメッセージが偽装またはなりすまされた場合、受信者は認証情報を明らかにしたり、不正な変更を承認したり、悪意のあるリンクをクリックしたり、虚偽の支払い指示を信頼したりするよう騙される可能性があります。

DMARCは、特定の、しかし重要なリスクに対処するのに役立ちます:可視Fromアドレスでの組織の実際のドメインの不正使用です。

正しく実装されると、DMARCは、ドメイン所有者が、認証および整合性チェックに失敗したメッセージをどのように扱うかを受信メールサーバーに指示できるようにします。

III. DMARCができることとできないこと

DMARCは完全一致ドメインスプーフィングから保護します。

メッセージがDMARCに合格するのは、次のうち少なくとも1つが真である場合のみです:

• SPFが合格し、SPF認証されたドメインが可視Fromドメインと整合している
• DKIMが合格し、DKIM署名ドメインが可視Fromドメインと整合している

SPFの合格だけでは不十分です。DKIMの合格だけでも不十分です。整合性が、認証を受信者が見るドメインに結びつけるものです。

DMARCはすべてのフィッシング攻撃を止めるものではありません。

類似ドメインの登録を防ぐことはできません。表示名のなりすましを止めることはできません。受信トレイへの配置を保証するものでもありません。従業員の意識向上、セキュアメールゲートウェイ、エンドポイント保護、アクセス制御、インシデント対応の代替にはなりません。

決済処理事業者にとって、DMARCは階層化されたフィッシング対策戦略の一部として使用されるべきです。

IV. DMARCがPCI DSSフィッシング対策目的をサポートする方法

DMARCは、いくつかの実用的な方法でPCI DSS準備をサポートできます。

完全一致ドメインスプーフィングの削減

攻撃者は、信頼された決済ブランドから送信されたように見えるメッセージを送信しようとすることがよくあります。DMARC強制により、受信システムは、組織の実際のドメインを不正使用する認証されていないメッセージを拒否または隔離できます。

フィッシング対策コントロールのサポート

PCI DSSは、組織がフィッシング攻撃から人員を保護することを期待しています。DMARC、SPF、DKIMは、攻撃者が信頼されたドメインを成功裏になりすますことを困難にすることで、この目的をサポートします。

可視性の向上

DMARC集約レポートは、どのシステムがドメインに代わってメールを送信しているか、どのソースが認証に合格または失敗しているか、どこで不正な活動が発生している可能性があるかを示します。

この可視性により、決済処理事業者は以下を識別できます:

• 未知の送信ソース
• 設定ミスのあるベンダー
• 未承認のIPアドレス
• 認証の失敗
• まだ強制なしで運用されているドメイン
• 決済関連ドメインに対するスプーフィング試行

ベンダー監視の強化

決済処理事業者は、CRM、チケットシステム、請求ツール、マーケティングプラットフォーム、サポートプラットフォーム、トランザクショナルメールプロバイダーなどに依存することがよくあります。

DMARCレポートは、これらのサードパーティ送信者が適切に認証され、整合されているかどうかを識別するのに役立ちます。

監査証拠のサポート

DMARC実装は、セキュリティ評価のための有用な証拠を生成できます:

• DNSレコード
• 認証ステータス
• 強制ポリシー
• レポート分析
• 送信者インベントリ
• モニタリング手順
• インシデントエスカレーション基準

この証拠は、メール認証が組織のフィッシング対策コントロール環境の一部として積極的に管理されていることを示すのに役立ちます。

V. 決済処理事業者のための実装戦略

決済処理事業者は、DMARCを慎重に実装する必要があります。性急な強制ポリシーは、特に複数の事業部門とサードパーティプラットフォームが組織に代わって送信している場合、正当なメールを妨げる可能性があります。

段階的なアプローチがより安全です。

VI. フェーズ1:メールフローの発見

ドメインに代わってメールを送信するすべての正当なソースを特定することから始めます。

これには以下を含めるべきです:

• トランザクショナルメールシステム
• 加盟店コミュニケーションプラットフォーム
• カスタマーサポートツール
• 請求および請求書発行システム
• CRMプラットフォーム
• マーケティングオートメーションツール
• 規制通知システム
• HRおよび内部コミュニケーションシステム
• サードパーティサービスプロバイダー
• 地域または事業部門固有の送信者

各送信者について、以下を文書化します:

• 送信プラットフォーム
• 送信IPまたはインクルード
• DKIM署名ステータス
• SPF承認ステータス
• 整合性動作
• メッセージ量
• ビジネスオーナー
• 重要度
• 失敗の影響

発見は最も重要なフェーズです。ほとんどのDMARC強制失敗は、正当な送信者が見逃されたために発生します。

VII. フェーズ2:SPFとDKIMの基盤の構築

DMARCはSPFとDKIMに依存します。

強制に向かう前に、決済処理事業者は、正当なメールが整合されたSPFまたは整合されたDKIMを通過できることを確認する必要があります。

SPFガイダンス

SPFは、すべての承認された送信ソースを含み、不要なインクルードを避ける必要があります。

簡略化された例:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all

正当な送信者が識別およびテストされた後にのみ、-allに移行してください。発見が不完全な場合、ハードフェイルポリシーは回避可能な配信問題を引き起こす可能性があります。

決済処理事業者は、SPFルックアップ制限も監視する必要があります。過負荷のSPFレコードは評価中に失敗し、正当なメッセージがSPF認証を失う原因となる可能性があります。

DKIMガイダンス

DKIMは、すべての主要なメールストリーム、特に顧客向けおよびビジネスクリティカルなコミュニケーションで有効にする必要があります。

推奨される実践には以下が含まれます:

• サポートされている場合、一般的に2048ビットの強力なDKIMキー長を使用します
• 文書化されたキーローテーション手順を維持します
• サードパーティ送信者のDKIM署名を確認します
• 可視Fromドメインとの整合性を検証します
• プラットフォーム変更後のDKIM失敗を監視します

決済処理事業者にとって、メールがサードパーティサービスまたは転送パスを経由してルーティングされる場合、DKIM整合性はSPF整合性よりも信頼性が高いことがよくあります。

VIII. フェーズ3:監視モードでDMARCを開始

配信に影響を与えることなく可視性を収集するために、監視ポリシーから始めます。

例:

v=DMARC1; p=none; rua=mailto:[email protected]

この段階での目標は、メールエコシステムを理解することです。

以下を監視します:

• DMARCに合格する正当なソース
• DMARCに失敗する正当なソース
• 未知または未承認の送信者
• 大量送信ソース
• サブドメインの動作
• 地域の送信パターン
• サードパーティプラットフォームの整合性
• 繰り返されるスプーフィング試行

デフォルトで法医学的失敗レポートを有効にすることは避けてください。失敗レポートは、プライバシー、データ処理、保持に関する懸念を引き起こす可能性があります。法的、プライバシー、セキュリティレビュー後にのみ使用してください。

IX. フェーズ4:強制に向けた移行

正当な送信者が識別され修正されたら、決済処理事業者は強制に向けて移行できます。

推奨される進行:

1. 発見と分析のためのp=none
2. 制御された強制のためのp=quarantine
3. 正当な送信者が一貫して整合されたらp=reject

強制は、推測ではなく証拠に基づくべきです。

p=rejectに移行する前に、以下を確認します:

• すべての重要なシステムがDMARCに合格している
• サードパーティ送信者が整合されている
• サブドメインが理解されている
• レポートが監視されている
• 緊急ロールバック手順が存在する
• ビジネスオーナーが変更を承認している
• サポートチームが配信問題の処理方法を理解している

X. サブドメインポリシー管理

決済処理事業者は、ポータル、サポート、マーケティング、アプリケーション、開発者ツール、地域運用のために多くのサブドメインを運用することがよくあります。

成熟したDMARC戦略には、サブドメインのレビューを含めるべきです。

例:

yourpaymentprocessor.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

サブドメインについては、必要に応じて明示的なレコードを使用します:

portal.yourpaymentprocessor.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

開発または非本番ドメインについては、必要でない限り外部メールの送信を避けてください。送信する必要がある場合は、適切に認証し、個別に監視してください。

決済処理事業者は、忘れられたサブドメインがスプーフィングの機会になることを避けるべきです。

XI. トランスポートセキュリティのためのMTA-STSとTLS-RPT

DMARCは送信者認証を保護します。メールサーバー間の暗号化されたトランスポートを強制するものではありません。

MTA-STSとTLS-RPTは、その別の層に対処するのに役立ちます。

MTA-STSにより、ドメインは、サポートするメールサーバーがドメインにメールを配信する際にTLSを使用することを要求するポリシーを公開できます。

例のポリシーファイルの場所:

https://mta-sts.yourpaymentprocessor.com/.well-known/mta-sts.txt

例のポリシー:

version: STSv1
mode: enforce
mx: mail1.yourpaymentprocessor.com
mx: mail2.yourpaymentprocessor.com
max_age: 86400

対応するDNSレコード:

_mta-sts.yourpaymentprocessor.com. IN TXT "v=STSv1; id=20260115T123000"

TLSレポートは、TLSに関連する配信問題の監視に役立ちます:

_smtp._tls.yourpaymentprocessor.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

決済処理事業者にとって、DMARC、MTA-STS、TLS-RPTは、メール信頼チェーンの異なる部分に対処します:

• DMARCは送信者の真正性を検証します
• MTA-STSは暗号化されたメールトランスポートをサポートします
• TLS-RPTはTLS配信失敗の可視性を提供します

XII. サードパーティ送信者管理

サードパーティ送信者は、多くの場合、DMARC実装の最も困難な部分です。

決済処理事業者は、以下を含む正式な送信者インベントリを維持する必要があります:

• ベンダー名
• ビジネスオーナー
• 送信ドメイン
• DKIMセレクター
• SPFインクルードまたはIP承認
• DMARC整合性ステータス
• メッセージタイプ
• リスク評価
• 承認日
• レビュー日

ベンダーは可能な限り整合されたDKIMをサポートすることが要求されるべきです。

これは重要です。なぜなら、SPFは転送または共有インフラストラクチャを通じて破綻する可能性があるからです。DKIM整合性は、サードパーティ送信者間で安定したDMARCコンプライアンスへのより強力なパスを組織に提供します。

ベンダーオンボーディングには、本番送信が開始される前にメール認証チェックを含めるべきです。

XIII. モニタリングとアラート

DMARCは1回限りのDNSプロジェクトとして扱われるべきではありません。

決済処理事業者は、メール認証を継続的に監視する必要があります。

重要なメトリクスには以下が含まれます:

• DMARC合格率
• SPF整合率
• DKIM整合率
• 未承認ソース数
• 新規送信者の検出
• 認証失敗量
• まだ監視のみポリシーのドメイン
• カバレッジのないサブドメイン
• TLS-RPT失敗パターン
• MTA-STSポリシーエラー

アラート条件には以下が含まれる可能性があります:

• DMARC失敗の突然の増加
• ドメインとして送信する新しい未承認ソース
• 認証に失敗する重要なベンダー
• 予期しない地理的送信パターン
• DKIM整合性の変化
• MTA-STS配信失敗
• 認証に影響するDNSレコードの変更

モニタリングは、単なるレポートではなく、インシデント対応に結びつけられるべきです。

XIV. メール認証失敗のためのインシデント対応

決済処理事業者は、メール認証インシデントへの対応手順を定義する必要があります。

実用的な対応ワークフローには以下を含めるべきです:

• 問題が正当な送信者に関わるものか、未承認ソースに関わるものかを判断します
• DMARC集約データでソース、量、受信者、整合性ステータスをレビューします
• SPF、DKIM、DNSレコードを検証します
• ベンダーがインフラストラクチャを変更したかどうかを確認します
• 顧客向けメールが影響を受けているかどうかを確認します
• 疑わしいスプーフィングキャンペーンをセキュリティ運用にエスカレーションします
• 重要なワークフローが影響を受けている場合、ビジネスオーナーに通知します
• 是正措置とタイムラインを文書化します

疑わしいスプーフィングについては、ヘッダー、ソースIP、レポート組織、可能な場合はメッセージサンプル、影響を受けたドメインなどの証拠を収集します。

正当な送信者の失敗については、ビジネスへの影響に基づいて修復の優先順位を付けます。

XV. 事業継続性の考慮事項

メール認証の変更は、運用コミュニケーションに影響を与える可能性があります。

決済処理事業者は、以下のための緊急手順を維持する必要があります:

• DNSロールバック
• ベンダーの設定ミス
• 重要なメール配信の中断
• DKIM署名の失敗
• SPFルックアップ制限の失敗
• DMARC強制の問題
• MTA-STSポリシーのミス

緊急手順には以下を含めるべきです:

• 承認された承認者
• DNS変更プロセス
• ロールバックレコード
• ベンダー連絡先
• 内部エスカレーションパス
• 必要に応じて顧客コミュニケーションプロセス

強制は、1人の人物または文書化されていないプロセスに依存すべきではありません。

XVI. コンプライアンス文書と証拠

決済処理事業者は、PCI DSS評価をサポートする方法でDMARCおよび関連するメールセキュリティコントロールを文書化する必要があります。

有用な証拠には以下が含まれます:

• 現在のSPF、DKIM、DMARC、MTA-STS、TLS-RPTレコード
• 送信者インベントリ
• DMARCモニタリング手順
• 強制ポリシー履歴
• レポート分析サマリー
• 認証失敗修復記録
• ベンダーメール認証要件
• インシデント対応手順
• セキュリティ意識およびフィッシング対策トレーニング記録
• DNSおよびメールインフラストラクチャの変更管理記録
• メール認証をフィッシング対策目的に結びつけるリスク評価メモ

目標は、メール認証が実装され、監視され、レビューされ、維持されていることを示すことです。

XVII. 決済処理事業者のための実装チェックリスト

このチェックリストを実用的な出発点として使用してください。

• [ ] 決済処理事業者のコミュニケーションに使用されるすべてのドメインとサブドメインを識別します
• [ ] 事業部門とベンダー全体でメールフローの発見を完了します
• [ ] 組織に代わって送信することを承認されたすべてのサードパーティ送信者を文書化します
• [ ] 正当な送信者のSPFを実装し、ルックアップ制限をレビューします
• [ ] すべての重要な送信プラットフォームでDKIM署名を有効にします
• [ ] 可視Fromドメインとの SPFおよびDKIM整合性を検証します
• [ ] 集約レポート付きのDMARC監視ポリシーを公開します
• [ ] 強制に移行する前にDMARCレポートをレビューします
• [ ] 認証に失敗する正当な送信者を修復します
• [ ] 証拠に基づいてp=quarantine、次にp=rejectに移行します
• [ ] プライバシーおよび法的レビューが承認しない限り、デフォルトの法医学的レポートを避けます
• [ ] 適切な場合、受信メールトランスポートセキュリティのためにMTA-STSを実装します
• [ ] メールトランスポート失敗を監視するためにTLS-RPTを設定します
• [ ] 送信者インベントリとベンダーレビュープロセスを維持します
• [ ] 認証失敗のアラート条件を定義します
• [ ] ロールバックおよびインシデント対応手順を確立します
• [ ] メール認証がPCI DSSフィッシング対策目的をどのようにサポートするかを文書化します
• [ ] メール認証態勢を定期的にレビューします

XVIII. Skysnag Protectの支援方法

Skysnag Protectは、決済処理事業者がドメイン、送信者、サードパーティプラットフォーム全体でメール認証を管理するのを支援します。

プラットフォームは以下をサポートします:

• DMARCモニタリングとポリシーの進行
• SPFおよびDKIM整合性の可視性
• 正当な送信者の識別
• 未承認送信者の検出
• サブドメインの可視性
• MTA-STSおよびTLS-RPT管理
• 該当する場合のBIMI準備
• セキュリティおよびコンプライアンスチームのためのレポート
• 認証失敗と強制準備への継続的な可視性

決済処理事業者にとって、その価値は運用制御です。

Skysnagは、チームがどの送信者が正当か、どのソースが失敗しているか、どのドメインが強制の準備ができているか、どこに認証ギャップが注意を必要としているかを理解するのに役立ちます。

これは、複雑な決済環境全体でメール認証を管理する手作業の負担を軽減しながら、フィッシング対策目的をサポートします。

XIX. 重要なポイント

決済処理事業者は、顧客、加盟店、業務運用、セキュリティのワークフローにおいて、信頼できるメール通信に依存しています。

DMARCは、受信システムが認証とアライメントに失敗したメッセージを識別できるようにすることで、完全一致ドメインなりすましからの保護を支援します。

PCI DSSは、DMARCを単独の普遍的な義務として定めていませんが、DMARCはより広範なPCI DSS管理環境における、フィッシング対策と安全な通信の目的をサポートします。

導入を成功させるには、検出、SPFとDKIMのアライメント、段階的なDMARC施行、サードパーティ送信者の管理、監視、文書化が必要です。

MTA-STSとTLS-RPTは、暗号化されたメール転送と、TLS配信問題への可視性をサポートすることで、さらなる保護層を追加します。

決済処理事業者にとって、メール認証は単なる配信制御ではありません。安全な決済通信を支える信頼インフラの一部です。

決済処理事業者環境のメール認証を強化する準備はできていますか?Skysnag Protectをでご確認ください。