SAP組織の複雑さに対応する設計複数選択
ある金融サービス企業は AWS Control Tower でランディングゾーンを構築し、複数のワークロードアカウントを OU 配下で運用している。開発者は自身のワークロードアカウントで EC2 や Lambda などのリソースを自由に作成できる一方、同社のセキュリティ部門は、いかなるアカウント管理者権限をもってしても CloudTrail・AWS Config・GuardDuty を無効化できないこと、および承認済みリージョン以外での操作を禁止することを求めている。さらに、開発者が新規に作成する IAM ロールが権限昇格に悪用されないよう、作成されるロールの実効権限を一定の範囲に制限する必要がある。これらを満たすために実施すべき対策を2つ選べ。
AOU に SCP を適用し、cloudtrail:StopLogging、config:DeleteConfigurationRecorder、guardduty:DeleteDetector などのセキュリティサービス無効化 API と、承認済みリージョン以外での操作を明示的に Deny する
✓ 正解
SCP は OU 配下の全アカウントに適用される予防的ガードレールで、セキュリティサービス無効化 API や承認外リージョンを Deny すればアカウント管理者でも実行できず、組織の統制を確実に強制できる。
BSCP で iam:CreateRole および iam:PutRolePolicy の許可条件として特定の Permissions Boundary ポリシーの付与（iam:PermissionsBoundary 条件キー）を必須化し、開発者が作成するロールの権限昇格を防ぐ
✓ 正解
iam:PermissionsBoundary 条件キーで Permissions Boundary の付与を必須化する SCP により、開発者が作成するロールの実効権限が境界内に制限され、自己昇格や過剰権限ロールの作成を予防できる。
CIAM Identity Center の許可セットで開発者に付与する権限を制限し、セキュリティサービスの無効化 API を許可ポリシーから除外することで意図しない操作を防止する
IAM Identity Center の許可セットは SSO でのアクセス付与を定義するもので、アカウント内で作成される他のロールや、それらによるセキュリティサービス無効化を防ぐ組織的ガードレールにはならない。
DAWS Config のマネージドルールと自動修復（SSM Automation ドキュメント）を Organizations 全体に展開し、CloudTrail や GuardDuty が無効化された場合に検知して各リージョンで自動的に再有効化するワークフローを構成する
Config ルールと自動修復は設定変更を検出して事後的に修復する検出的統制であり、無効化操作そのものを予防できない。検出から再有効化までのタイムラグにログ欠落などのリスクが残る。
E各ワークロードアカウントの root ユーザーに IAM ポリシーを直接アタッチし、承認済みリージョン以外およびセキュリティサービス無効化アクションを拒否する
root ユーザーには IAM ポリシーを直接アタッチできず、この手法は技術的に成立しない。root の制御は SCP による Deny や root 資格情報の適切な管理によって行うべきである。
解説
組織全体の予防的ガードレールには SCP が最適で、セキュリティサービスの無効化 API や承認外リージョンでの操作を Deny すれば、メンバーアカウントの管理者権限をもってしても実行できなくなる。さらに開発者が作成する IAM ロールの権限昇格を防ぐには、iam:CreateRole および iam:PutRolePolicy を Permissions Boundary の付与を条件として許可する SCP を用いることで、作成されるロールの実効権限を境界内に制限できる。
選択肢2の IAM Identity Center 許可セットは付与するアクセスを定義するが、アカウント内で別途作成されるロールやポリシーによる無効化を防ぐガードレールにはならない。
選択肢3の Config と自動修復は検出・事後修復であり予防的統制ではなく、無効化と再有効化の間に猶予が生じる。
選択肢4の root ユーザーへの IAM ポリシー直接アタッチは技術的に不可能で、root は IAM ポリシーの対象にできない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →