PCI DSS DMARC要件：セクション5.4.1が要求するもの（そして要求しないもの）

23分で読めます 共有 PCI DSS DMARC要件：セクション5.4.1が要求するもの（そして要求しないもの） PCI DSS DMARC要件は、支払い監査の前に every IT admin が尋ねる質問です — そして正直な答えは、ほとんどのベンダーページが認めるよりも正確です。 PCI DSS v4.0.1 は DMARC を義務付けていません。 要件 5.4.1 は自動化されたアンチフィッシングメカニズムを必須とし、標準のガイダンス列は DMARC、SPF、および DKIM をアンチスポーフィングコントロールの例として挙げています — これは 2025年3月31日以降、すべての評価で有効な要件です。 では、PCI DSS は DMARC を要求するのでしょうか？ 名前ではいいえ。 実際には、それはあなたの監査官が参照することを期待する管理策です。 このガイドは、PCI 評価に直面し、標準が言うこととベンダーブログが言うことを切り離そうとしている IT マネージャー、DevOps リード、またはコンプライアンスオーナー向けです。 セクション 5.4.1 の原文、どのメール認証プロトコルがそれを満たすか、ステップバイステップで実装する方法、および監査に失敗する間違いを得られます。 ここにあるすべては、標準自体から引用されたものであり、言い換えではありません。そして、例と義務の区別を明確に保ちます。なぜなら、その区別こそが競合他社のガイダンスが不注意になる場所だからです。 常に有効な、プロトコルごとの詳細については、PCI DSS プロトコルリファレンスから始めてください。 PCI DSS v4.0.1 とは何か？ PCI DSS（Payment Card Industry Data Security Standard）は、グローバルな小売業者から単一の決済端末を運営する小規模ビジネスまで、カードホルダーデータを保存、処理、または送信するすべての組織に対する契約上のセキュリティ標準です。 2024年6月11日に PCI Security Standards Council (PCI SSC) によって公開されたバージョン 4.0.1 は、唯一有効なバージョンです。 PCI DSS 4.0 の要件を理解することは、バージョンのタイムラインから始まります。なぜなら、日付があなたの監査義務を決定するからです。 v4.0.1 は限定的で明確化された改訂です — 要件を追加または削除しておらず、有効期限も変更していません。 その前身は公開されたスケジュールで廃止されました：v3.2.1 は 2024年3月31日に廃止され、v4.0 は 2024年12月31日に廃止され、v4.0.1 が評価される唯一の標準として残っています。 カードホルダーデータ環境（CDE）— 決済カードデータを保存、処理、または送信するシステム、およびそれらに接続されているものすべて — は、以下のすべての要件の範囲を定義します。 標準は、6つのコントロール目標の下にグループ化された12の主要な要件にコントロールを整理しています： コントロール目標 要件 焦点 セキュアなネットワークとシステムの構築と維持 1–2 ファイアウォール、セキュアな設定 アカウントデータの保護 3–4 保存データの暗号化、転送中のデータの暗号化 脆弱性管理プログラムの維持 5–6 アンチマルウェア/アンチフィッシング、セキュアな開発 強力なアクセス制御策の実装 7–9 アクセス制限、認証、物理的セキュリティ ネットワークの定期的な監視とテスト 10–11 ログ記録、セキュリティテスト 情報セキュリティポリシーの維持 12 ポリシー、セキュリティ意識向上トレーニング PCI DSS v4.0.1 の6つのコントロール目標とその12の主要な要件。 要件4と5は、メールを管理する2つです。 メールに直接関わるコントロール目標は2つあります：要件4（転送中のデータの暗号化）と要件5（アンチフィッシングコントロール）。 どちらも以下でカバーされています。 v4.0 の1つの構造的な変更も、それらをどのように満たすかに影響します。 標準は現在、従来の定義アプローチに加えて、カスタマイズアプローチを提供しています。 定義アプローチでは、コントロールを記述どおりに実装します。カスタマイズアプローチでは、文書化されたターゲットリスク分析に裏打ちされ、監査官によって検証されたコントロールで、述べられたセキュリティ目標を満たします。 メール認証に関して言えば、セクション 5.4.1 は代替のアンチフィッシングメカニズムを通じて満たすことができます — しかし、実際には、挙げられた例のコントロールが監査官が期待するものです。 v4.0 で変更された点：セクション 5.4.1 アンチフィッシングコントロール セクション 5.4.1 は v4.0 で新しく追加されたもので、v3.2.1 には同等のものがありません — これは PCI DSS 4.0 の主要な変更点の1つです。 §5.4 の見出しは次のとおりです：「アンチフィッシングメカニズムはユーザーをフィッシング攻撃から保護します。」 要件自体は短く、拘束力があります：「プロセスと自動化されたメカニズムが、フィッシング攻撃を検出し、担当者を保護するために配置されていること。」 — PCI DSS v4.0.1、要件 5.4.1（定義アプローチ） これが拘束力のあるテキスト全体であり、PCI SSC Document Library の PCI DSS v4.0.1 標準から直接引用されています。 それが何を言っていないかに注意してください：プロトコル、ベンダー、またはポリシーレベルの名前は挙げていません。 アンチフィッシングの義務は、結果として書かれています — 検出して保護する自動化されたメカニズム — そしてメカニズムの選択はあなたに委ねられています。 DMARC は、要件に付随するガイダンス列にのみ登場します：「アンチフィッシングコントロールを開発する際、エンティティはアプローチの組み合わせを検討することが推奨されます。たとえば、Domain-based Message Authentication, Reporting & Conformance (DMARC)、Sender Policy Framework (SPF)、および Domain Keys Identified Mail (DKIM) のようなアンチスポーフィングコントロールを使用すると、フィッシャーがエンティティのドメインを偽装して担当者をなりすますのを阻止するのに役立ちます。」 — PCI DSS v4.0.1、要件 5.4.1 ガイダンス タイムラインは物語のもう半分です。 セクション 5.4.1 は 2025年3月31日までベストプラクティスとして分類されていました。標準の適用可能性の注記には次のように書かれています：「この要件は 2025年3月31日までベストプラクティスであり、その後は必須となり、PCI DSS 評価中に完全に考慮されなければなりません。」 これは、2025年3月31日に必須となった51の将来の日付が設定された要件（v4.0 で導入された64の新しい要件のうち）の1つでした。 v4.0.1 はそれを移動させませんでした。 要件 5.4.1 は、フィッシングを認識するように担当者を教育するセキュリティ意識向上トレーニングである要件 12.6.3.1 と混同してはなりません。 PCI DSS は両方を要求しています：5.4.1 の下の技術的メカニズムと 12.6.3.1 の下の人間の意識。 標準は、5.4.1 がトレーニングだけでは満たされないことを明確にしています — DMARC とその同類は技術的な側面を扱い、トレーニングは人間的な側面を扱います。 また、PCI DSS アンチフィッシングの議論が一般的な「PCI DSS 要件 5」アンチマルウェアコントロールと最も頻繁に混同される場所でもあります。5.4.1 は、フィッシングとメールのなりすましを管理する、明確なサブ要件です。 DMARC は PCI DSS の下で必須ですか？ 監査官は何を期待するか いいえ — 具体的には。 PCI DSS v4.0.1 は、要件 5.4.1 の下で自動化されたアンチフィッシングメカニズムを必須としていますが、標準は単一の必須技術を挙げていません。 DMARC、SPF、および DKIM は例としてのみ登場し、カスタマイズアプローチは明確に許可されています。 主張できる方法は次のとおりです：メカニズムは必須であり、DMARC は最も一般的に引用され、期待される例であり、特定のプロトコルまたはポリシーレベルは PCI 要件ではありません。 その正確さが準備方法に影響します。 定義アプローチでは、監査官は自動化されたアンチフィッシングメカニズムが存在し、機能していることを確認します。 カスタマイズアプローチでは、ターゲットリスク分析を文書化し、資格のあるセキュリティ監査官（QSA）がそれを検証すれば、セキュリティ目標を満たす代替コントロールに置き換えることができます。 どちらのパスも有効です。どちらも DMARC を名前で要求しません。 実務家はどう読んでいますか？ Jeremy Simon — PCI QSA（CISSP、CISA）であり、HALOCK Security Labs の PCI コンプライアンスプラクティスリード — は 5.4.1 ガイダンスをそのまま再現し、SAQ チェックボックスを通過することが完全な DSS コンプライアンスと同じではないと警告しています。DSS 自体が最終的にすべての組織が満たさなければならないものです。 これは、一次隣接監査官の声に最も近いものです。 DMARC ツーリングを販売するベンダーはさらに一歩進んでおり、彼らのアドバイスは、監視のみのレコードは担当者を積極的に保護しないという理由で、強制ポリシー — p=quarantine または p=reject — を実証することを示唆しています。 彼らは DMARC 採用に商業的関心を持つベンダーなので、「監査官は強制を期待する」を、条項ではなく期待として扱ってください。 注目すべきは、PowerDM でさえ