AWS OrganizationsとSCPを理解する

この単元で学ぶこと

• SCPの階層を評価する
• SCPの適用主体と例外を説明する
• 組織変更を安全に展開する

本文解説

1. 上限と付与 SCPは組織内の対象主体が利用できる最大権限を定めます。FullAWSAccessが付いていても、新しいIDへ管理者権限を与えるものではありません。IAM等による実際の付与と、組織側の許容範囲を分けます。

2. 同じ階層のAllow 同じOUへ二つのSCPがあり、一方がGetObject、他方がPutObjectをAllowする場合、その階層では両方が許容候補になります。狭いAllowを同じ階層へ追加しただけで、既存の広いAllowを狭くしたと考えないでください。

3. 親子のAllow 組織ルートから対象アカウントまで、各階層で対象操作のAllowが必要です。ルートが両操作、OUがGetObjectだけ、アカウントが両操作を許容する例では、経路上の許容はGetObjectだけです。実際のID付与も必要です。

4. 明示的Deny 経路上のどこかに一致する明示的Denyがあれば、下位でAllowしても打ち消せません。メンバーのAdministratorAccessでも同じです。FullAWSAccessを外す際は代替Allowが経路にあるか確認し、Denyだけを残して全許可を失わないようにします。

5. 主体の範囲 メンバーのIAMユーザー・一般ロール・rootはSCPの対象です。一方、管理アカウントの主体とサービスリンクロールは対象外です。サービスの委任管理者となったメンバーは、管理アカウントと異なり対象のままです。

6. 外部から資源を使う場合 アカウントAのSCPは、Aの資源を使う組織外Bの主体を直接制限するものではありません。S3の資源ポリシー等で外部アクセスを管理します。SCPを付けただけで資源側の全公開・共有が止まると一般化しません。

7. OU移動と検証 OU移動は継承経路の変更です。移動先の上限を読み、管理・監視・復旧に必要な操作まで検証します。まず小さいOUや少数アカウントで影響を確認し、失敗したAPIと適用ポリシーを記録します。

8. 変更権限を管理 SCPによる制御はOrganizationsの全機能を前提にします。許可する範囲と変更できる管理者を整理し、広い例外を恒久化しない運用を考えます。今回の集合例は対象メンバーのIDベース付与だけで、他の制限や資源側付与がない条件に限定します。

図解

重要ポイント

• 同一階層はAllowを合わせ、親子は各階層のAllowを確認する。
• 上位Denyを下位Allowは打ち消せない。
• 外部主体の資源アクセスは資源側も制御する。

間違えやすい点

• 同階層へ狭いAllowを足せば既存の広いAllowが消えると思う。
• SCPで組織外の主体も直接制限できると思う。
• FullAWSAccessを代替なしで外す。

用語解説

階層

組織ルート・各OU・アカウントというSCPの適用位置。

許可リスト方式

経路の各階層で許容する操作を明示して範囲を絞る方式。

サービスリンクロール

AWSサービスにリンクした特別なロールで、SCPの対象外。

関連教材

• AWS OrganizationsとSCPのシナリオ判断
• クロスアカウントアクセスのシナリオ判断
• クロスアカウントアクセスを理解する