AWS Organizations / SCP戦略難易度 高無料
ある組織のOrganizationsのルートには、デフォルトの FullAWSAccess（Effect: Allow, Action: "*", Resource: "*"）SCPがアタッチされたままになっている。セキュリティチームは、あるOU「Restricted」配下では許可された一部のサービスしか使わせない（明示的に許可したものだけを使える＝allow-list方式）運用へ切り替えたいと考えている。この移行方法として最も適切なものを選べ。（単一選択）
- A「Restricted」OUから
FullAWSAccessSCPをデタッチし、許可したいサービス/アクションのみをAllowする新しいSCPを作成してアタッチする。基盤サービス（IAM/STS等）のAllow漏れがないよう事前に検証する - B
FullAWSAccessはルートにアタッチされたままで変更・デタッチできないため、禁止したいサービスごとにDenyステートメントを個別に積み上げていく - CIAMの権限境界（permission boundary）を全IAMユーザー・ロールに個別にアタッチすることで、OU単位のSCPと同等のallow-list運用を実現する
- DRestricted OU配下のアカウントすべてに、S3バケットポリシーで許可サービスを列挙する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
SCPの運用方針には大きく2つの戦略がある。
- deny-list戦略（デフォルト）：ルートに
FullAWSAccessを残したまま、禁止したい操作だけを 個別のDenyステートメントで追加していく。「原則すべて許可、例外だけ禁止」の考え方。 - allow-list戦略：
FullAWSAccessをデタッチ（または対象OUで無効化）し、代わりに 許可したいサービス/アクションだけを明示的にAllowするSCPを作成してアタッチする。「原則すべて禁止、例外だけ許可」の考え方。 ただし、SCPはそのOU配下の全アカウントの実効権限の上限になるため、必要なサービス（IAM、STS、CloudFormation等の基盤サービス含む）を Allow漏れさせると、正規業務まで止まってしまう点に注意が必要。
要件の「許可された一部のサービスしか使わせない」はallow-list戦略そのものであり、Restricted OUから FullAWSAccess をデタッチし、
許可したいサービスのみをAllowする新しいSCPをアタッチすることで実現する。
- B前提が誤り。
FullAWSAccessはOU/アカウント単位でデタッチ可能であり、要件の「一部のサービスしか使わせない」という allow-list運用にはデタッチが必要。deny-list方式のままでは網羅的な禁止が困難で漏れが生じやすい。 - C権限境界はプリンシパル単位で設定するものであり、OU配下の全アカウント・将来追加されるアカウントも含めた一元的な制御にはならない。運用負荷も大きい。
- DバケットポリシーはS3リソースへのアクセス制御に限定され、EC2やLambda等の他サービス全般の利用制限には使えない。
ひっかけ： 「
FullAWSAccess はルートの必須ポリシーなので絶対にデタッチできない（誤答の1つ）」という思い込みに注意。
OU/アカウント単位でデタッチ可能であり、allow-list戦略ではこれが前提の操作になる。
またallow-list移行時にIAMやSTSなど基盤サービスのAllowを漏らすと、管理者自身も含め誰も操作できなくなる「締め出し」事故が
Professionalレベルで頻出の落とし穴である。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）