古い例外はレビュー候補であり、権限を削除できることを自動的に証明するものではありません。もともと何が必要だったのか、そのニーズがまだ存在するのか、影響を受けるサービスがその後どのように機能するのかを確立します。退職により、新たな配送インシデントが発生することなく、不必要な権限が削減されるはずです。
本来の原因を取り戻す
例外のスコープ、所有者、承認、および意図された終了テストを読み取ります。それが以下のものに関係するかどうかを判断する SPF メカニズム、 DKIM 代表団、 DMARC ポリシー、ゲートウェイ ルール、またはレポートの除外。これらにはさまざまな効果があります。サードパーティ DKIMセレクター とSPFインクルードは、権限を付与する代替可能な方法ではありません。 RFC 6376 、鍵管理 そして RFC 7208.
本来の理由が不明な場合は、不明のラベルを付けて調査員を割り当てます。よく知られたプロバイダー名からビジネス上の正当な理由をでっち上げないでください。インフラブランドだけでなく、実際の顧客サービスやテナントも確認しましょう。責任ある所有者が確認できるように、契約上または運用上の依存関係を保存します。
提案された最終状態をテストする
代替ルートを特定し、承認されたテスト計画に基づいて代表的なフローを実行します。関連する場合、認証 ID、信頼できる結果、および業務受領書を記録します。季節限定の使用や少量の使用をビジネス カレンダーと照らし合わせて確認します。沈黙期間が短いと、四半期ごとのキャンペーンや災害復旧通知を見逃す可能性があります。
使用 集計レポート 1 つの観察ソースとして、必要に応じて送信者のログと所有者の確認を行います。レポートはすべての受信者をカバーしているわけではなく、サービスが非アクティブであることを証明するものでもありません。 RFC 9990。観察間隔とギャップを文書化します。証拠の不在は、不使用の証拠とは区別されなければなりません。
準備状況と削除の許可を区別する
3 つの仮定の例外を考えてみましょう。 EX-01 には、確認された所有者、確認された代替ルート、および関連するビジネス サイクル全体にわたる古いルートの文書化されたレビューがあります。変更承認の候補です。 EX-02 には現在の所有者がおらず、静かな短い報告期間しかないため、帰属と報道範囲は未解決のままです。 EX-03 は引き続きスケジュールされたキャンペーンを提供するため、交換品がテストされる前に EX-03 を削除すると、正当な使用が中断される可能性があります。
これらは、実行された退職モデルや実際の検証証拠ではなく、意思決定ウォークスルーのための想定された入力です。 EX-01 でさえ自動的に削除されません。正確な依存関係、共有使用、現在の状態、承認を確認する必要があります。証拠が完全であるという声明では、普遍的な可視性を示唆するのではなく、対象となるサービスと期間を指定する必要があります。
承認された依存関係のみを削除します
変更前後の正確な計画と復旧計画を作成します。突然変異の前に現在の状態を再確認します。スコープにDNSが含まれる場合は、後で信頼できる観察結果を検証し、影響を受ける正当なフローをテストします。キャッシュされた回答は持続する可能性があるため、検証期間は実際の依存関係に適合する必要があります。 RFC 1035.
承認された削除と関連するサービスの結果が記録された場合にのみ、例外を閉じます。以前の範囲、退職が正当化された理由、および残留リスクを維持します。依存関係をまだ削除できない場合は、責任ある決定と具体的な次のアクションのみを使用して更新してください。新しい証拠がないまま更新を繰り返すことは、進歩ではなくガバナンスの所見です。
レコードを閉じる前に退職を確認する
承認された削除後は、変更されたオブジェクトをそのまま保持し、意図した権限の喪失と正当な継続性の両方を検証します。どちらかが不確かな場合は、例外履歴を消去するのではなく、名前付きの次のチェックを行ってクロージャを保留したままにしておきます。