受信メッセージはドメイン認証を通過しても、受信者に危険な行為を要求する可能性があります。正当なルートが壊れたために認証に失敗することもあります。認証をメッセージの測定されたプロパティの 1 つとして扱い、受信側システムのその他の制御と組織のビジネス検証プロセスを適用します。これらのステップを崩壊させると、誤った安心感と不必要な混乱の両方が生じます。
3 つの決定事項を特定する
最初の決定は技術的なものです。認証された識別子が、該当する規定の下で作成者のドメインと一致しているかどうかです。 DMARC ルール？ 2 つ目は運用に関するものです。ポリシーやその他の信号を考慮して、この受信環境はメッセージをどのように処理すべきでしょうか。 3 番目はビジネス固有の問題です。要求されたアクションは合法的で承認されていますか? RFC 9989 ドメインベースの認証とポリシーを定義します。通過メッセージが請求書の支払いの承認に変わるわけではありません。 DMARC仕様.
これらの決定を別のフィールドに記録します。請求書変更リクエストの場合、認証フィールドは合格、処理フィールドは検疫保留のレビュー、ビジネス フィールドは未検証である可能性があります。これらの値には互換性があります。受信者はDMARC外部のシグナルを使用でき、メールが認証された場合でも従業員は独立した承認ワークフローに従う必要があります。
信頼できる境界からの結果を使用する
アン Authentication-Resultsヘッダー 出自が理解されている場合にのみ役に立ちます。攻撃者はメッセージにヘッダー テキストを挿入する可能性があります。受信側の組織は、信頼できる認証サービスによって生成された結果と、信頼できないアサーションを区別する必要があります。 RFC 8601では、その信頼境界について説明しています。 認証結果.
生のメッセージと信頼できる受信システムのログを保存します。表示されている From ドメインを検証済みのそれぞれと比較します DKIM 署名ドメインと SPF 実際に評価されたアイデンティティ。表示名、返信先フィールド、または転送されたスクリーンショットを認証された作成者ドメインとして扱うことは避けてください。メッセージが転送された場合は、どの証拠が適用されるかを決定する前に、元の評価ポイントとその後の変換を記録します。
3 つの合成リクエストを比較する
3 つの架空の支払い変更メッセージについて考えてみましょう。 1 つ目は brand.test を主張していますが、evil.test 署名のみが合格しており、 SPFパスはありません。想定される唯一の認証された識別子は厳密に失敗します アライメント。 2 つ目は、From とその受け渡しDKIM ID の両方で brand-pay.test を使用するため、類似した懸念にもかかわらず、そのモデル化された認証は合格します。 3 つ目は、brand.test を一貫して使用し、これもパスするため、アカウントの悪用や不正なリクエストの可能性が残ります。
それぞれのケースに対して提案されるビジネス アクションは、変更を保留し、独自に検証することです。これらは発明された認証入力であり、暗号化や受信者の結果ではありません。記載されているケースでは、指定された ID が利用可能な唯一の認証済み ID であることを前提としており、厳密なドメイン一致が分離されており、完全なDMARC検出は実装されていません。メッセージ、署名、受信者のテストは実行されませんでした。これは、認証ブール値だけからビジネス アクションを計算できない理由を示しています。
レビューを回避しない設計処理
制御パスごとに承認されたテスト メッセージを選択し、システムがそれらを拒否、隔離、配信、または後で修復したかどうかを記録します。ベンダーの機能ラベルは、構成された動作の証拠ではありません。例外と許可ルールは、実際の結果を変える可能性があるため、テストに含めます。壊れた正当なルートを通過させるためだけに広範なホワイトリストを作成することは避けてください。
財務上のリクエストについては、以前に確立された連絡チャネルを使用してください。 FBI は、支払い要求とアカウント詳細の変更を独自に検証することを推奨しています。不審なメッセージによって紹介された連絡先の詳細を、その独立したチャネルとして使用しないでください。 FBI ビジネス電子メール侵害に関するガイダンス.
3 つの決定すべて、それぞれの証拠、および未解決の問題を提出してレビューを終了します。これにより、財務部門が支払い保留を保持している間にメール チームが認証を修復したり、セキュリティ部門がDMARC欠陥があると主張することなく通過した不審なメッセージを調査したりすることができます。
ソースと実行境界
RFC 9989セクション 4.4、5.3.5、および 5.4 認証、調整、処理を区別する。パスはメッセージの内容を保証するものではありません。ここでの運用上の決定は、範囲を絞った推奨事項と明確に仮説的な例であり、顧客、プロバイダー、または過去の設備の新しいテストではありません。実際の変更には、独自に承認された範囲、保持された証拠、および責任ある決定が必要です。