SAA / SAP 攻略ナビ
ホーム アイデンティティ・アクセス管理

SCP と RCP — サービスコントロールポリシー設計

AWS Organizations の SCP と RCP (Resource Control Policy) の違い、ガードレール設計、段階的適用、Deny の局所化を SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: アイデンティティ・アクセス管理

AWS Organizations の サービスコントロールポリシー (SCP) は、 組織単位 (OU) やアカウントに適用する 許可の最大範囲 (ガードレール) を定義します。 近年登場した RCP (Resource Control Policy) はリソースレベルのガードレールを提供します。 本記事では SCP / RCP の設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

SCP の本質 — ガードレール

SCP は IAM ポリシーと 同じ JSON 構文 ですが、本質が異なります。

SAA レベル：基礎概念

SCP の核心は 「許可を与えるのではなく、許可の上限を定める」 ことです。 IAM ポリシーで許可されていても、SCP で許可されていなければ アクセスは拒否 されます。 「SCP = ガードレール（上限の設定）」が SAA の最重要ポイントです。

# アクセスが許可される条件
  IAM ポリシー (Allow) AND SCP (Allow) = 許可
  IAM ポリシー (Allow) AND SCP (Deny)   = 拒否
  IAM ポリシー (Deny)  OR  SCP (Deny)   = 拒否
条件IAM ポリシーSCP結果
許可AllowAllow許可
拒否AllowDeny拒否
拒否DenyAllow拒否
拒否DenyDeny拒否

SAA 試験のポイント

「SCP で Allow しても、それだけではアクセスできない」 は SAA の超頻出です。 SCP の Allow は「最大範囲を設定する」だけで、IAM ポリシーでも許可が必要です。 逆に SCP の Deny は 絶対拒否（IAM ポリシーで Allow でも拒否）。 この非対称性が SAA の核心です。

SCP の適用単位

SCP は Root、OU、アカウント に適用できます。適用範囲は階層的に下位に継承します。

Root
  └── SCP: FullAWSAccess (必須デフォルト)
      └── Security OU
          └── SCP: セキュリティサービス無効化を拒否
              └── Production OU
                  └── SCP: リージョン制限
                      └── アカウント A
                          └── 適用される SCP: 3 つの AND
  • 下位は上位の SCP を継承: 全親 OU の SCP が AND で適用
  • FullAWSAccess: Root にはデフォルトで FullAWSAccess が必要（無いと全アカウントが停止）
  • 管理アカウントは SCP 対象外: 管理アカウント自体は SCP の影響を受けない

SAA 頻出

管理アカウント (Management Account) は SCP の対象外 です。 これは「SCP で管理アカウント自身をロックアウトする事故」を防ぐための仕様です。 SAA で「管理アカウントに SCP は適用されるか？」というひっかけ問題が頻出します。

代表的なガードレール例

ガードレール目的SCP の内容
リージョン制限データ主権・コスト管理許可リージョン外の新規リソース作成を Deny
セキュリティサービス無効化防止セキュリティ維持GuardDuty/Security Hub の無効化操作を Deny
ルートユーザー使用制限セキュリティルートユーザーの日常使用を Deny
サービス制限ガバナンス未承認サービス（例: 未認可リージョンの Rekognition 等）を Deny

SAP レベル：高度な設計シナリオ

段階的 SCP 適用の設計

SAP では 階層的に SCP を段階適用 して、リスクの高い操作を階層ごとに防ぎます。

SAP レベル：高度な設計シナリオ

段階的 SCP 設計の定石は 「上位 OU は広く、下位 OU は狭く」 です。 Root 直下は最小限の Deny（全組織共通の禁止事項）、 Production OU ではより厳格なリージョン制限や承認要求を追加、という階層化で 「局所的な要件は局所的な SCP で」実現します。

Root
  └── SCP 1: ルートユーザー日常使用禁止、全組織共通 Deny
      └── Security OU
          └── SCP 2: セキュリティサービス無効化禁止
              └── Production OU
                  └── SCP 3: リージョン制限 + 本番 IAM ロール作成に承認要求
                      └── Sandbox OU
                          └── SCP 4: 本番リージョンへのアクセス禁止

Deny の局所化原則

設計上の落とし穴

Root 直下に過剰な Deny を設定すると、意図せず全組織を停止 させるリスクがあります。 Deny はなるべく 下位 OU に局所化 し、影響範囲を最小化するのが SAP のベストプラクティスです。 特に Root 直下の Deny は「組織全体に影響」するため、慎重な設計が必要です。

リージョン制限 SCP の実装例

データ主権やコスト管理のため、許可リージョン以外でのリソース作成を禁止 する SCP は頻出です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/AWSControlTowerExecution"
        }
      }
    }
  ]
}

除外ロールの設計

リージョン制限 SCP では 自動化ロール（Control Tower 実行ロール等）を除外 する条件を入れるのが定石です。 これを忘れると、Control Tower のアカウント初期化が特定リージョンで失敗する事故に繋がります。 SAP では「誰を除外すべきか」の設計判断が問われます。

RCP (Resource Control Policy) の登場

近年登場した RCP は、SCP とは異なる リソースレベルのガードレール を提供します。

ポリシー制御対象代表ユースケース
SCPアイデンティティ の許可上限アカウント内のプリンシパルが何をできるか
RCPリソース へのアクセス上限リソースが誰からアクセスされるか

SAP レベル：高度な設計シナリオ

RCP は 「組織外からのリソースアクセスを禁止」 というリソース側のガードレールを実現します。 従来は各リソースのリソースポリシーで個別設定していた「外部アカウント拒否」を 組織レベルで一括適用 できるのが RCP の強みです。 S3 バケット、KMS キー、Secrets Manager シークレット等の外部共有を組織的に防止できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

この RCP は 「組織外のプリンシパルからのリソースアクセスを禁止」 します。 組織 ID (aws:PrincipalOrgID) で組織メンバーかを判定するのがキモです。

SCP と RCP の使い分け

シナリオ推奨ポリシー理由
アカウント内のアクション制限SCPプリンシパルの行動を制限
リソースへの外部アクセス禁止RCPリソース側の受信を制限
サービスの利用禁止SCPアクション単位の制限
データ主権の強制RCPリソースへのアクセス制限

SCP と RCP の混同

SCP は「アイデンティティが何をできるか」、RCP は「リソースが誰からアクセスされるか」 です。 「リソースポリシーがないサービス」でも RCP で組織的ガードレールを設定できるのが新しい強みですが、 適用対象のサービスは限定されているため、対応状況を確認する必要があります。

タグポリシーと SCP の連携

タグポリシー (Tag Policy) はタグの標準化を定義しますが、単体では 強制力が弱い です。 SCP と連携することで 必須タグ未付与のリソース作成を拒否 できます。

タグポリシー: タグの標準定義（強制力なし）
  + SCP (Resource Control): 必須タグ未付与リソース作成を Deny
  = タグ付けの強制

タグ強制の完成形

タグポリシー + SCP + Config Rules の 3 段構えが SAP のタグガバナンス定石です。

  1. タグポリシーで標準定義
  2. SCP で未付与リソース作成を拒否（予防的）
  3. Config Rules で既存リソースの不備を検知・修復（是正的）

ガードレールのテストと段階導入

SCP/RCP の誤設定は 組織全体を停止 させるリスクがあるため、段階導入が重要です。

段階手法目的
1Audit OU でテスト影響範囲を限定して検証
2Dry Run (CloudTrail IAM Action)実際の Deny 影響を事前確認
3Sandbox OU に適用実環境での動作確認
4本番 OU に段階展開影響を見ながら拡大

ガードレール導入の鉄則

「いきなり Production OU に SCP を適用しない」 が SAP の鉄則です。 まず Sandbox / Audit OU でテストし、CloudTrail で Deny されるべき操作が実際に Deny されるか を確認してから本番展開します。

制約とクォータ

項目制約
SCP の適用単位Root / OU / アカウント
1 アカウントあたり SCP5（クォータ拡張可）
管理アカウントSCP 対象外
RCP 対象サービスS3, KMS, Secrets Manager, SQS 等（順次拡大）

まとめ

  • SAA: SCP はガードレール（許可上限）、Allow だけでは許可されない、 管理アカウントは対象外、という基本を理解する。
  • SAP: 段階的 SCP 適用、Deny の局所化、RCP との使い分け、タグポリシー連携、 段階的テスト導入が求められる。

次は AWS Organizations ガバナンス設計 で、組織全体の統制体制を統合的に学びましょう。

スポンサーリンク（広告枠） 728×90

関連記事