ある大手金融サービス企業は、AWS Organizationsを使用して300のAWSアカウントを以下のOU階層で管理しています。 [OU構造] Root OU → Security OU（audit・log-archiveアカウント）/ Infrastructure OU（network・shared-servicesアカウント）/ Workloads OU → Production OU（50アカウント）/ Development OU（200アカウント）/ Staging OU（50アカウント） 最近AWS Control Towerを導入しました。以下の要件を最小限の運用オーバーヘッドで満たす必要があります。 [要件] ① 全アカウントでCloudTrailの削除・停止・変更を禁止する（予防的統制として実装すること） ② Production OUとStaging OUでは ap-northeast-1 と us-east-1 のみでリソース作成を許可する ③ Development OUでは全リージョン利用を許可するが、m5.xlarge以上のEC2インスタンスタイプの起動を禁止する ④ セキュリティチームが全アカウントに対して読み取り専用の横断アクセスを持つ これらの要件をすべて満たす最も適切な設計はどれですか？
正解： SCPによる予防的統制: Root OUに cloudtrail:DeleteTrail・cloudtrail:StopLogging・cloudtrail:UpdateTrail を拒否するSCPをアタッチする。Production OUとStaging OUには aws:RequestedRegion グローバル条件キーを用いて許可リージョン以外を拒否するSCPをアタッチする。Development OUには ec2:InstanceType 条件で m5.xlarge 以上を対象とした ec2:RunInstances 拒否SCPをアタッチする。セキュリティチームのアクセスは IAM Identity Center で読み取り専用 Permission Set を作成し、Organizations 配下の全アカウントにアカウント割り当てを設定する。 SCPはOU単位で継承され配下の全アカウントに自動適用されるため、アカウントごとの設定が不要で運用オーバーヘッドが最小となる予防的統制手段です。Root OUへのCloudTrail拒否SCPは操作自体を阻止し（要件①）、aws:RequestedRegionグローバル条件キーによりリージョン制限を実現します（要件②）。IAM Identity CenterのPermission SetとOrganizations統合により、セキュリティチームの横断アクセスをスケーラブルに管理できます（要件④）。 選択肢Bは、ConfigによるリアクティブなSSM修復は操作後の対処であり予防的統制ではありません（要件①不適合）。Permission BoundaryはIAMロールごとの個別設定が必要でスケールしないため、リージョン制限の実装手段として不適切です（要件②不適合）。 選択肢Cは、Control TowerのElective GuardrailsはEC2インスタンスタイプ制限をネイティブにサポートしておらず（要件③不適合）、BudgetsはEC2起動を事前に禁止する予防的統制ではなく検知・通知にとどまります。 選択肢Dは、EventBridge+Lambdaによる修復はリアクティブな対処であり予防的統制ではありません（要件①不適合）。各アカウントへの個別IAMユーザー発行は長期認証情報のリスクがあり、スケールしません。