目次を開く
結論
削除を防ぐ保持設定と、侵害後に復元できる運用を一つの設計として扱う。
背景
バックアップが本番と同じ認証情報で削除できると、侵害時に両方を失う可能性がある。保持設定と独立した復元経路を一緒に検討する。
設計と検証の論点
構成を検討するときは、次の責任と境界を分けて確認します。
- Governance
- Compliance
- 保持期間
- バージョン管理
- 認証情報
- 本番環境の信頼領域との分離
- 復旧試験
判断理由
Governance modeとCompliance modeの保持中の扱いを比較し、誰が保持を変更・回避できるかを確認する。保持対象のオブジェクト版、バックアップの書き込み主体、暗号鍵、復元する主体を分け、侵害された本番権限からの到達性を点検する。
トレードオフ
強い保持は削除耐性を高める一方、誤ったデータや不要データも期間中は残り、費用と削除要件へ影響する。Compliance modeの保持短縮不可、KMS鍵の喪失、復元速度と復旧手順の検証を分けて扱う。
制約
保持モード、バイパス権限、アカウントとKMS権限、ライフサイクル、復元テスト条件を確認する。Object Lockは暗号鍵や書き込み前のデータ整合性まで保護しない。
関連事例
関連事例の担当範囲や設計判断を参照します。記事で提案する実験・構成を、その事例で実施済みとするものではありません。