一元ログ（Log Archiveアカウント設計）難易度 高無料
組織のログ専用アカウント（Log Archive）に、全アカウントのCloudTrailログ・Config記録・VPC Flow Logsを集約している。監査部門から「万一Log Archiveアカウントの管理者権限が攻撃者に奪取されても、既に格納済みの過去ログは一切削除・改ざんできないようにしたい」という要件が追加された。これを満たす設計として最も適切なものを選べ。（単一選択）
- Aログ格納先S3バケットのバケットポリシーに、あらゆるプリンシパルからの
s3:DeleteObject/s3:PutObject（上書き）を拒否するDenyステートメントを追加する - Bログ格納先S3バケットでバージョニングを有効化した上でS3 Object Lockをコンプライアンスモードで有効化し、指定した保持期間中はルート/管理者を含め誰もオブジェクトの削除・上書き・保持期間短縮ができないようにする
- CCloudTrailログの保存先をS3からCloudWatch Logsのみに変更し、ログの改ざん耐性を高める
- DLog ArchiveアカウントのルートユーザーにMFAを必須化し、IAMユーザーのパスワードポリシーを強化する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・独立検証済
解説
「アカウント管理者権限を奪取されても既存ログを改ざん・削除できない」という要件は、S3のバケットポリシーやIAM権限だけでは満たせない （管理者権限があればIAMポリシー自体やバケットポリシー自体を変更できてしまうため）。この場合に有効なのがS3 Object Lock （コンプライアンスモード）である。
- S3 Object Lockをコンプライアンスモードで有効化すると、指定した保持期間中は、そのバケットのルート/管理者を含め いかなるユーザーもオブジェクトの削除・上書きができなくなる（保持期間の短縮や設定解除もできない）。
- これはIAMポリシーの上位に位置するストレージレイヤーでの技術的強制（technical enforcement）であり、 「IAM権限を奪われても」という前提のシナリオに対して唯一有効な防御である。
- Object Lockを有効にするにはバケットのバージョニングが必須である。バケット作成時に有効化できるほか、 2023年11月以降は既存バケットに対しても有効化できる（いずれもバージョニングの有効化が前提）。
- A管理者権限を奪取されるシナリオでは、攻撃者がそのバケットポリシー自体を書き換えてDenyを解除できてしまい防御にならない。
- CCloudWatch LogsもIAM権限で削除・変更操作が可能であり、それ自体がObject Lockのような技術的な削除不能性を提供するわけではない。保存先の変更だけでは要件を満たさない。
- D認証強化は侵入自体のリスクを下げる有効な対策だが、「万一管理者権限を奪取された場合」という前提のシナリオには対応しておらず、奪取後の改ざん防止にはならない。
ひっかけ： 「バケットポリシーで
s3:DeleteObject をDenyしておけば十分（誤答の1つ）」という発想が典型的な誤り。
管理者権限を奪取されるシナリオでは、バケットポリシー自体も攻撃者に書き換えられてしまうため防御にならない。
IAMやポリシーより下のレイヤー（ストレージ自体のロック機構）で技術的に強制することがProfessionalレベルで問われる急所。公式ドキュメント・関連Amazon S3 User Guide ― Locking objects using S3 Object Lock↗Amazon S3 User Guide ― Object Lock modes (governance vs compliance)↗Amazon S3 User Guide ― Configuring S3 Object Lock（Enable Object Lock on an existing S3 bucket）↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）