すべての認証レポートを永久に保存することは、保持ポリシーではありません。生の集計データ、メッセージ固有 失敗レポート と調査メモは異なる目的を果たし、異なるリスクを伴います。有用な保持計画では、各クラスが保持される理由、有用な期間、およびその期間が終了したときに何が起こるかを説明します。
DMARCのレポート仕様には、レポートの内容、プライバシー、セキュリティに関する考慮事項が記載されています。すべての組織に対して普遍的な法的保存期間を定めているわけではありません。以下のワークフローは、プライバシー、セキュリティ、および適用される法的義務の責任者と一緒にレビューするための運用設計です。
実際のレコードクラスをインベントリする
参考文献: RFC 9990 §7.1, RFC 9990 §7.2, RFC 9991 §2, RFC 9991 §7.1.
生を分離する 集計レポート、解析されたレコード、要約されたメトリクス、障害レポート、制御されたメッセージのサンプル、およびインシデントの結論。各ストアとすべてのダウンストリーム コピー (メールボックス、パーサー キュー、分析システム、チケット、アナリストのエクスポート、バックアップ) の所有者を特定します。
標準の集計レポートでは、個々のメッセージの内容と特定のエンドユーザー情報は除外されます。 RFC 9990 §7.2ただし、トラフィック メタデータは依然として次のような運用パターンを明らかにする可能性があります。 RFC 9990 §7.1。集約ストアをアクセスと保持のレビューから免除されるものとして扱わないでください。集計レポートには、適切な処理が必要となる可能性のあるインフラストラクチャおよび交通情報が含まれます。障害レポートには次のような内容が含まれる可能性があるため、特に注意が必要です。 メッセージヘッダー、本体と識別子。ファイル拡張子やダッシュボードのラベルではなく、実際のコンテンツの可能性に基づいて分類します。
クラスごとに目的と時間を設定する
記録が保持される理由を述べます: 取り込みのトラブルシューティング、季節の比較、特定の調査、または適用される義務。レポートの受信やインシデントの終了など、保持クロックがいつ開始されるか、および誰が例外を所有するかを定義します。使用後はしばらく保管するなどの曖昧な指示は避けてください。
一般的なセキュリティ チェックリストからコピーした数値ではなく、文書化されたニーズと義務に基づいて期間を選択してください。長期間の季節比較は、適切に最小化されたメトリクスによって提供される可能性がありますが、生のメッセージ コンテンツははるかに短い診断ニーズのために保持されます。カバレッジと構成の変更を解釈するために必要なコンテキストがサマリーに保持されていることを確認します。
保持設計を実行する
例示的なデザイン: 生の集計レポートはパーサーのトラブルシューティングをサポートします。派生カウントは長期的な傾向分析をサポートします。メッセージ固有のレポートは、期限付きの調査をサポートします。編集されたインシデントの結論には、原因と是正措置が保存されます。各クラスには、独自の承認された期間、開始イベント、所有者、および削除方法があります。
この例では、意図的に普遍的な日数カウントを割り当てていません。組織の義務とシステムがそれらを決定します。インシデントに例外が必要な場合は、理由、範囲、承認者、レビュー日を記録します。通常の削除による証拠の破壊を許可するのではなく、関連する証拠を有効な保持の下で保存し、無関係なデータに対する無制限の保持を回避します。
1 つの合成レジスタ行を計算する
次の行では、保持メカニズムを示すためだけに、任意の仮説上の承認を使用しています。 7 日間という期間は、組織の現在のポリシーに関する推奨事項、法的最低限度、または主張ではありません。すべてのタイムスタンプは UTC です。
- レジスタフィールド: レコードクラスと識別子。仮説の値: 実際のメッセージ データを含まない生の障害レポート フィクスチャ RET-TEST-01
- 登録フィールド: システムおよび責任のある所有者。仮説値: 分離されたテスト レポート ストア。レポート操作の所有者
- レジスタフィールド: 目的。仮説の値: テスト パーサーによる無害なフィクスチャの処理を検証します。
- レジスタフィールド: クロックスタート。仮定の値: 2026-11-01T10:00:00Z の受信
- 登録フィールド: 仮定の承認期間。仮説値: 受領から 24 時間経過後の 7 日間
- レジスタフィールド: 計算された有効期限。仮定の値: 2026-11-08T10:00:00Z
- 登録フィールド: 廃棄対象。仮説の値: アクティブなフィクスチャ オブジェクト、解析されたメッセージ コンテンツのコピー、および一時的な平文のコピー
- レジスタフィールド: 例外決定。仮説の値: 基本ケースでは成立しません。別途承認された保留により、この特定の記録の処分を一時停止できます
- レジスタフィールド：バックアップ処理。仮説の値: テスト バックアップは、文書化された個別の有効期限に従います。復元されたレコードは、通常のアクセスの前に元の有効期限および保持状態と照合されます。
保留されていないケースの場合、2026-11-08T09:59:59Z で提案されたチェックにより、フィクスチャが保留されていることが判明するはずです。有効期限の小切手で処分の対象となることが判明するはずです。クリーンアップを実行し、リストされたアクティブな廃棄ターゲットが削除され、承認された最小限の廃棄イベントのみが保持されていることを確認します。有効期限の適格性と削除の成功は別の事実です。失敗したジョブは期限を過ぎたレコードを残し、誤った削除エントリではなく所有者を必要とします。
保留中のケースの場合、範囲指定されたテスト保留が 2026-11-07T12:00:00Z に承認されたと仮定します。有効期限チェックでは、管理されたストレージに保持されたレコードを保存し、保持参照を識別する必要があります。保留が 2026-11-10T10:00:00Z に解除された場合、元の有効期限はすでに過ぎています。記録は自動的に新しい 7 日間を受け取るのではなく、承認された廃棄プロセスに入る必要があります。
復元テストの場合は、RET-TEST-01 を含むバックアップを 2026-11-09T10:00:00Z に復元します。アクティブな保留がない場合は、期限切れのレコードが通常のアクセスに戻らないようにし、承認された廃棄プロセスを適用します。アクティブなスコープ付き保留の場合は、制御された保留ワークフロー内でのみ保存します。これらは提案された結果であり、完了したシステム テストではありません。オフライン タイムスタンプの計算では、算術のみが検証されます。
複数のコピーにわたって有効期限を機能させる
メイン アプリケーションから削除すると、エクスポート、キャッシュされたプレビュー、一時パーサー ファイル、およびチケットの添付ファイルも削除されるかどうかをテストします。バックアップは別の有効期限スケジュールに従う場合があります。技術的に真実でない場合は即時消去を主張するのではなく、それを文書化し、アクセスを制御します。
期限切れのコンテンツが日常的な使用に黙って再導入されないように、復元されたバックアップの処理方法を計画します。契約処理者が承認されたスケジュールを適用し、意味のある証拠を提供できるかどうかを判断します。組織が削除を実行するシステムを特定できない場合、保持ステートメントは不完全です。
余分なコンテンツを含まずに有用な証拠を保存する
参考文献: RFC 9991 §7.
診断レポートを削除する前に、承認された最小化レコードに関連する ID、時間、障害状態、修正措置、および検証結果を保存する必要があるかどうかを決定します。保持されているナラティブから不要なメッセージ コンテンツ、受信者、シークレットを削除します。自動編集が完了したと仮定するのではなく、抽出を確認してください。
記録が保持されている間は、制御されたアクセスを使用します。有効期間が短いからといって、保護されていないストアが許容されるわけではありません。また、暗号化によって不要になったデータを削除する必要がなくなるわけでもありません。
システムの変更に応じてポリシーを確認する
レポート プロセッサの追加、エクスポート統合の変更、またはレコードに予想よりも機密性の高いコンテンツが含まれていることを発見した後は、スケジュールを再検討してください。意図したとおりにまだ削除できないものを含め、有効期限切れの動作と例外のテスト記録を保持します。
最終的な成果物は、記録クラス、目的、システム、所有者、時計、承認された期間、例外プロセス、および検証された廃棄動作を含む小さな保持レジスターです。組織が実際に何を行っているかを説明し、未解決のギャップは修正のために割り当てられる必要があります。
イラストは証拠の範囲内に留めてください
ローカル UTC の計算により、2026-11-01T10:00:00Z から 7 経過日が 2026-11-08T10:00:00Z に達することが確認されます。リリースおよび復元のタイムスタンプは、元の有効期限より後になります。彼らはそれを再起動しません。算術のみが実行されました。削除、訴訟ホールド、バックアップ復元、システム廃棄テストは実行されませんでした。