Service Control PolicyによるGovernance

1. SCPは組織ポリシーによる権限ガードレール

サービスコントロールポリシー（SCP）はAWS Organizationsの組織ポリシーの1つです。組織ルート、OU、メンバーアカウントへアタッチし、その範囲に属するプリンシパルが利用できる権限へ上限を設定します。

ルート
├─ 本番OU  ← 本番ガードレール
│  ├─ 決済アカウント
│  └─ 注文アカウント
└─ サンドボックスOU     ← サンドボックスガードレール
   └─ サンドボックスアカウント

共通制御要件を持つアカウント群へ同じガードレールを適用する場合は、各アカウントへ個別設定するよりOUを範囲にする方が構造を保ちやすくなります。

2. SCPは権限を付与しない

最重要ポイントは、SCPの許可だけではアクセスできないことです。

SCPでアクションを許可
+
IAM等で権限付与なし
↓
実行不可

実際の権限はIAMのアイデンティティベースポリシーやリソースベースポリシーなど、適用される別の権限ポリシーによって付与されます。SCPはその権限に対して組織側の上限を加えます。

3. 実効権限はSCPだけでは決まらない

設計判断では、次のように考えます。

IAM / リソースポリシー等による権限付与
             │
             ▼
適用されるSCPによる上限
             │
             ▼
他の適用可能ポリシーも含めAWSのポリシー評価
             │
             ▼
最終的な実行可否

例えばIAMロールへec2:RunInstancesが許可されていても、適用されるSCPでそのアクションを利用できなければ実行できません。逆にSCPで利用可能でも、IAM等から権限が付与されていなければ実行できません。

現行のAWS Organizationsでは、リソース側のアクセス上限を定義するリソースコントロールポリシー（RCP）もポリシー評価に参加します。したがって実効権限は、SCPだけでなく、該当するRCPとIAMのアイデンティティベースポリシー／リソースベースポリシーなどの組み合わせで決まります。このページでは、そのうちプリンシパル側の組織ガードレールであるSCPに責任を限定します。

4. AdministratorAccessでもSCPを越えられない

メンバーアカウント内の管理者がIAM権限を広げても、適用されるSCPの上限を越えることはできません。

IAM AdministratorAccess
        │
        ▼
適用されるSCPガードレール
        │
        ▼
実行可能な権限

組織として禁止したアクションをアカウント管理者自身がIAM変更だけで解除できないため、SCPはマルチアカウントガバナンスのガードレールとして機能します。

5. ルート → OU → メンバーアカウントの親チェーンを見る

メンバーアカウントへ影響するSCPは、アカウントへ直接アタッチされたSCPだけではありません。

ルート
└─ ワークロードOU
   └─ 本番OU
      └─ 決済アカウント

決済アカウントを評価するときは、ルートから決済アカウントまでの親チェーンにある適用されるSCPを確認します。アカウントを別OUへ移動すると親チェーンが変わるため、利用可能なアクションも変化し得ます。

6. 明示的な拒否は下位の許可で解除できない

上位のSCPでアクションを明示的に拒否した場合、下位OUやアカウントで許可を追加しても、その拒否を打ち消せません。

ルート
拒否: s3:DeleteBucket
        │
        ▼
本番OU
許可: s3:*
        │
        ▼
s3:DeleteBucket は実行不可

明示的な拒否はガードレールとして優先されると判断します。

7. 拒否リスト戦略

ほとんどのAWSサービスを利用可能にし、少数の危険アクションだけを組織として禁止したい場合は拒否リスト型が適しています。

FullAWSAccess
+
明示的な拒否
↓
基本は利用可能
特定アクションだけ禁止

例えば本番OU全体でセキュリティ制御の無効化や特定の危険運用を禁止する、といったガードレールです。

8. 許可リスト戦略

承認したサービス / アクションだけを利用可能にしたい場合は許可リスト型を検討します。

許可リストでは、対象アクションがルートからメンバーアカウントまでの各レベルで利用可能である必要があります。

ルート許可 EC2 / S3
   ∩
本番許可 EC2
   ∩
アカウント許可 EC2 / S3
↓
SCP上利用可能なのは EC2

上位または途中のレベルで必要アクションが許可されていなければ、下位で許可を追加しても利用可能にはなりません。

9. FullAWSAccessを残したまま狭い許可を追加しても制限にならない

FullAWSAccessはSCPガードレール上すべてのアクションを許可するAWS管理SCPです。ただし、IAM AdministratorAccessのようにプリンシパルへ権限を付与するポリシーではありません。

許可リストへ切り替えるときは、同じレベルにFullAWSAccessを残したまま狭い許可SCPを追加するだけでは絞り込みになりません。

同じOU
├─ FullAWSAccess
└─ 許可 EC2 のみ
↓
「EC2 のみ」にはならない
FullAWSAccess側でも他アクションが許可候補になる

承認アクションだけへ制限するなら、対象階層でFullAWSAccessを外す／置き換えたうえで必要な許可を設計します。

10. SCPを利用する組織の前提

SCPを使用するには、AWS Organizationsですべての機能を有効にし、SCPポリシータイプを利用できる状態にします。

一括請求のみ
↓
SCPは利用不可

すべての機能
+
SCPポリシータイプ
↓
SCPによるガバナンス

11. 管理アカウントはSCPによる制限対象外

SCPは管理アカウントで実行されるアクションを制限しません。ルートへSCPをアタッチしても、管理アカウント自体をそのSCPで保護することはできません。

このため管理アカウントは通常ワークロードを置く場所として扱わず、組織管理に必要な用途へ限定する設計が重要です。

12. メンバーアカウントのルートユーザーはSCP対象

一方、メンバーアカウントのルートユーザーが通常のAWS APIアクションを実行する場合も適用されるSCPによる制限を受けます。

メンバーアカウントルートユーザー
↓
適用されるSCP
↓
ルートユーザーだからガードレールを回避できるわけではない

13. サービスリンクロールはSCPの制限対象外

主要な例外として、サービスリンクロールの権限はSCPによる制限を受けません。

ただし、利用者のユーザー / ロールがAWS APIを呼び出す最初のアクションまで自動的にSCPを回避できるという意味ではありません。

ユーザー / ロールがサービスAPIを呼ぶ
→ 呼び出し側プリンシパルは通常どおりポリシー評価

AWSサービスがサービスリンクロールの権限で処理
→ サービスリンクロール自体はSCPの制限対象外

14. OUをガードレール範囲として使う

共通制御要件を持つアカウント群にはOU単位でSCPを適用します。

範囲を広げすぎると不要なアカウントまで影響し、狭すぎると同じ制御をアカウント単位で繰り返すことになります。

15. OU移動では移動後のアクション結果まで確認する

アカウントをサンドボックスOUから本番OUへ移動すると、新しい親チェーンのSCPが適用されます。

サンドボックスOU
幅広いサービスを許可
     │
     ▼ 移動
本番OU
危険なアクションを拒否
     │
     ▼
移動後は本番ガードレールで実行可否を再評価

「範囲が変わる」で終わらず、移動後に必要な運用が継続できるかを確認します。

16. SCPはきめ細かなIAM設計の代わりではない

「本番OU全体でCloudTrail停止を禁止」のような制御はSCPに向きます。一方、特定ユーザーだけに特定リソースへの読み取りを許可するような細かなアクセス制御はIAM側で設計します。

17. SCPは段階的に展開する

強いSCPをいきなりルートへ適用すると、多数のアカウントで必要な運用を止めるリスクがあります。まずテスト用OUや限定アカウントで影響を確認し、必要な運用と例外を検証してから範囲を広げます。

SCP案
↓
テスト用OU / 限定的なアカウント
↓
必要運用の検証
↓
影響確認
↓
段階的に本番 / より広い範囲へ展開

ガバナンス要件を満たすだけでなく、既存ワークロードを壊さず導入できることもアーキテクチャ成立条件です。

18. 障害モード

SCPで許可すればアクセスできると思う

SCPは権限を付与しません。IAM等の権限付与が別途必要です。

AdministratorAccessならSCPを越えられると思う

メンバーアカウントでは適用されるSCPの上限を越えられません。

下位許可で上位拒否を解除できると思う

明示的な拒否は下位許可で上書きできません。

FullAWSAccessを残して許可リストを追加するだけで絞れると思う

同じレベルのFullAWSAccessが他アクションも許可候補にするため、狭い許可の追加だけでは許可リスト化できません。

管理アカウントもルートSCPで制御できると思う

管理アカウントで実行されるアクションはSCPの制限対象外です。

サービスリンクロールも通常ロールと同じSCP評価だと思う

サービスリンクロールの権限はSCPの制限対象外です。

19. SAP-C02判断フロー

組織全体の権限ガードレールが必要？
        │
        ▼
AWS Organizations / すべての機能
        │
        ▼
範囲は？
ルート / OU / メンバーアカウント
        │
        ▼
基本は広く許可？ 承認アクションだけ？
      ┌──────┴──────┐
      │             │
   拒否リスト許可リスト
      │             │
FullAWSAccess     FullAWSAccessを
+ 明示的な拒否外して必要許可
      │             │
      └──────┬──────┘
             ▼
ルート → OU → アカウントの適用されるSCP
             │
             ▼
IAMなどの権限付与と合わせて評価
             │
             ▼
テスト用OUで検証 → 段階展開

20. まとめ

SCPはAWS Organizationsで利用する権限ガードレールであり、プリンシパルへ権限を付与するポリシーではありません。

権限付与
+
適用されるSCPの上限
+
その他の適用可能ポリシー評価
↓
最終的な実行可否

明示的な拒否は下位許可で解除できず、許可リストではルートから対象アカウントまでの各レベルで必要アクションが利用可能であることを確認します。

拒否リストではFullAWSAccess＋明示的な拒否が代表的です。許可リストへ絞る場合は、同じ階層レベルにFullAWSAccessを残したまま狭い許可を追加するだけでは不十分です。

また、管理アカウントで実行されるアクションとサービスリンクロールの権限は主要なSCP例外で、メンバーアカウントのルートユーザーは通常アクションでSCP対象です。

要件 → 範囲 → 戦略 → 適用されるSCP → 権限評価 → 段階的ロールアウトまで一続きで判断します。

21. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) 試験ガイド — ドメイン 1 / タスク 1.4
• AWS Organizations — サービスコントロールポリシー
• AWS Organizations — SCPの評価
• AWS Organizations — SCPの構文
• AWS Organizations — SCPの例
• IAM — ポリシー評価ロジック