A DMARC レポート プログラムには、いくつかの異なる種類のデータが含まれる場合があります。メッセージ固有の集計観察 失敗レポート また、調査のためにアップロードされた元の電子メールには、同じ内容や露出が含まれていません。
実際にシステムにデータが入ることから始めます。次に、なぜそれが必要なのか、誰が見るのか、どこで処理されるのか、いつ削除するのかを決定します。これらは、 DMARCレポートと呼ばれるすべてのものに 1 つのプライバシー ラベルを割り当てるのではなく、組織の要件によってサポートされる運用上の決定として扱います。
収集段階をマップする
受信メールボックス、ストレージ、パーサー、分析プラットフォーム、エクスポート、サポート チャネル、およびワークフローで使用される追加の AI サービスをリストします。トラブルシューティング中に作成された管理ログとコピーが含まれます。
どの情報が各段階に到達し、どの当事者がそれを操作するかを記録します。分析プロバイダーとの契約では、その後のすべてのエクスポートまたはアップロードされたメッセージが同じ処理取り決めに従うことを確立するわけではありません。
1 つの収集システムが複数の顧客をサポートする場合は、サービスとアカウントの境界を明確にしてください。アナリストが 1 つのテナントにアクセスすると、別のテナントのレポートや調査サンプルが黙って公開されるべきではありません。
データ型を区別する
| 材料 | 質問への対応 |
|---|---|
| 集計レポート | 観察によってどのようなドメインレベルのアクティビティと運用上の関係が明らかになりますか? |
| 障害レポート | どのようなメッセージ固有の情報を含めることができますか?また収集は必要ですか? |
| オリジナルメッセージサンプル | どのようなアドレス、ヘッダー、コンテンツ、添付ファイルがアップロードされますか? |
| エクスポートとサポートコピー | コピーは誰が受け取り、どのように保管されますか? |
RFC 9990セクション 7 では、個別のメッセージ本文ではなく、グループ化されたドメイン認証情報としての集計レポートについて説明しています。さらに、サービスが収集する実際のデータ、拡張機能、および周囲の運用記録を評価します。その設計目的を、あらゆる処理環境に関する包括的な法的結論として扱うことは避けてください。
RFC 9991セクション 7 では、障害報告のさまざまな内容と開示リスクについて説明します。必要性、可用性、および取り扱いの取り決めが評価された場合にのみリクエストしてください。 rua 集約要求は、完全なユーザー メールボックスの収集を許可するかのように記述すべきではありません。
最小限の有用な調査サンプルを要求する
レポート行でサービスを特定できない場合は、代表者が受け取ったメッセージが役立つ場合があります。関連するすべてのメールを要求する前に、サンプルがどの ID またはルートの質問に答える必要があるかを確立します。
タスクに必要な証拠を保存する承認済みの編集手順を使用します。署名付きメッセージを編集すると後で影響する可能性があります DKIM 検証するため、元の信頼できる受信者の結果と変更されたコピーとの区別が保持されます。
スクリーンショットは共有しやすいですが、診断に必要な封筒や署名 ID が省略される可能性があります。実際の質問に答えるサンプルを選択し、何が削除または変更されたかを記録します。
アクセスと二次使用の制御
適切な顧客とドメインの境界を設定して、オペレーターにその責務に必要なアクセス権を与えます。エクスポート権限、サポート アクセス、およびユーザーまたはサプライヤーがオフボードされた場合に何が起こるかを確認します。
追加の分析先を個別に評価します。メッセージ サンプルを AI サービス、発券システム、または個人のメールボックスに送信することも、別の処理ステップです。元の収集者が承認されたというだけの理由で対象となるとみなすべきではありません。
認証パーサーは信頼できない入力も受け取ります。 RFC 9990セクション 8.1 解凍と XML リソースの枯渇のリスクを特定します。これらのリソースを制限し、出所を保持し、レポートの内容が運用担当者への指示として扱われないようにします。
不要なコピーの例に取り組む
この合成ケースでは、アナリストは From をDKIM署名ドメインと比較する必要があります。代わりに、サポート リクエストでは、その週の失敗したすべてのメッセージとすべての添付ファイルが求められます。
要求されたボリュームは、指定された質問を超えています。チームはリクエストを、代表的な承認済みサンプル、関連する元のヘッダー、およびレポート間隔に絞り込みます。その証拠がどこに保存されているか、誰がアクセスできるかを記録します。
別のケースでは、より広範なセットが本当に必要になる場合があります。簡単なアップロード メカニズムに収集ポリシーを決定させるのではなく、その理由と範囲を明示的に文書化します。
ワークフロー全体にわたって保持と削除を定義する
運用上のニーズと該当する組織の要件に応じて保持を選択します。普遍的なDMARC保存期間を発明したり、管轄区域固有の法的アドバイスとしてプロトコル文書を提示したりしないでください。
未加工の添付ファイル、解析されたレコード、キャッシュ、エクスポート、バックアップ処理、およびサポート コピーを保持評価に含めます。ダッシュボード行を削除するアプリケーション設定では、すべてのコピーが削除されない場合があります。
収集または調査ごとに、この例示的な取り扱いチェックリストを使用してください。これは計画を支援するものであり、法的に定められた保存スケジュールではありません。
- 目的: アライメントされていない送信サービスを識別するなど、データが回答する質問に名前を付けます。
- 最小限のデータ: 必要なレポート間隔と ID フィールドをリストします。質問で必要な場合にのみ、オリジナルのコンテンツをリクエストしてください。
- 所有者とアクセス: 関連する顧客またはドメインの境界とともに、責任のあるチームと許可された役割を指定します。
- プロセッサーとコピー: 各収集、サポート、輸出または AI の宛先、および承認された共有の取り決めを記録します。
- 保持の決定: ユニバーサル番号をコピーするのではなく、目的と該当する要件に合わせて選択された期間またはレビューのトリガーを文書化します。
- 削除範囲: RAW ファイル、解析された行、エクスポート、サポート コピー、バックアップ処理が含まれます。完了または保持された例外がどのようにチェックされるかを記録します。
所有者、アクセス ルール、承認されたプロセッサ、レビュー トリガーを記録します。を使用します。 集計レポートガイド 証拠を理解するため、そして 報告漏れ診断 収集の失敗を調査するとき。目的は、デフォルトで最大限の収集を行うことではなく、理解された取り扱いを伴う有用で説明責任のある証拠です。