継承された送信者インベントリは、IP アドレスのリストではなく、意思決定ツールです。取得したドメインを標準化する前に、観察されたメールを、そのメールを作成した顧客固有のサービス、そのビジネス所有者、および承認された ID に接続します。使い慣れたプロバイダーは正規のトラフィックと不要なトラフィックの両方をホストする可能性があるため、インフラストラクチャの認識だけでは承認とはなりません。
複数の証拠ソースから始める
承認された構成のエクスポート、アプリケーション レジスタ、ベンダー アカウント レコード、 DNS観察、および利用可能なメール証拠を収集します。各観測値がどこから来たのか、いつ収集されたのかを保存します。 集計レポート 送信元 IP と認証パターンを明らかにすることはできますが、組織のビジネス意図や完全な送信者集団を独立して確立することはできません。 RFC 9990.
各サービスについて、記録の目的、責任のある所有者、プロバイダーのアカウントまたはテナント、重要度、可視の From ドメイン、エンベロープ ドメイン、 DKIM 署名ID、最後の代表的なテストおよび承認の証拠。不明なフィールドは明示的に保ちます。休止中または防御的なドメインの場合は、送受信の目的を個別に記録します。
権限を追加する前の属性アイデンティティ
観察された識別子を実際のベンダー構成およびビジネス ワークフローと比較します。 DMARC 用途 アライメント 作成者ドメインと認証に成功した識別子との間。識別子のない一般的な合格結果では、解決する必要がある問題が隠蔽される可能性があります。 RFC 9989.
不明なソースを追加しないでください SPF 単にメールがそこから発信されているように見えるからです。 SPF 、評価された ID に対してホストを承認し、その評価にはDNSルックアップ制限が含まれます。 RFC 7208 、セクション 4.6.4。新しいインクルードは権限を拡大したり、操作上の制限を超えたり、調整を修正できなかったりする可能性があります。まず、目的のサービスと適切な認証ルートを確立します。
承認とテストを分離する
承認されたサービスでも移行テストに失敗する可能性があります。認証されたメッセージが未承認のサービスから送信される可能性もあります。両方の状態を保存します。承認の証拠は説明責任のある決定を特定する必要があり、テストの証拠は実際の取引、身元、結果、時間を説明する必要があります。テストパスをビジネス所有権の代わりとして使用しないでください。
継承された請求サービスには指定されたビジネス所有者と承認された目的があるが、ターゲット アカウントの署名 ID が検証されていないとします。 2 番目のサービスには、調整された受け渡しメッセージがありますが、識別されたビジネス所有者はありません。 1 つ目は、移行前にルートの証拠が必要です。 2 つ目は、認可されたサービスとして扱われる前に、帰属と承認が必要です。どちらのギャップも、他のサービスの安心できる結果によって解決されるわけではありません。
これらは仮説上のインベントリに関する決定であり、生成されたレコードや実行されたテストではありません。所有権、対象となる ID、承認、および現在のテスト範囲については、個別のフィールドを保持します。アプリケーション所有者が不足しているアカウントの証拠を提供した場合は、確立された状態のみを更新します。未テストの移行結果を自動的に合格に変更しないでください。
アトリビューションを移行計画に変える
検証済みの所有者、依存関係、準備状況ごとにサービスをグループ化します。レコードを編集する前に、目的のターゲット ID とテストを定義します。不明なルートを黙って承認または削除するのではなく、所有者と期限を指定して調査用に保存します。古い構成と、結果として生じる移行ごとに承認された復旧計画を保持します。
標準化後、実際の観察結果を承認された目録と照合し、新しいアイデンティティを調査します。廃止されたサービスとその決定を履歴に保存します。有用な在庫は、合併プロジェクトの終了時に放棄されるスプレッドシートではなく、ベンダーの変更やインシデント対応を通じて運用記録として残ります。
このインベントリとレビューのワークフローは、推奨される運用モデルです。 NIST SP 800-53 Rev. 5 CM-8 および CM-3 は、責任ある在庫と管理された変更の一般的な基礎を提供します。これらの電子メール固有のフィールドを規定したり、承認を与えたりするものではありません。 NIST管理カタログ.