どーも！shihopowerです！

前回の記事ではIAMの全体像とポリシーの7種類（IDベース・リソースベース）を整理しました。今回はAWS Organizationsの機能として提供されるSCPとRCPを扱います。

SCPとRCPは「組織全体に一括で適用する外壁」のような仕組みです。個別のIAMポリシーよりも上位のレイヤーで権限を制御します。

この記事で扱うこと

SCPとRCPの役割分担
SCPの仕組みの詳細
RCPの仕組みの詳細
有効な権限の評価ロジック
SCPとRCPを併用したデータ境界の概念

1. SCPとRCPの役割分担

まず最も重要な前提を押さえます。

SCPもRCPも「許可を付与しない」 という点です。上限を定義するだけで、実際に権限を与えるのはIDベースのポリシーやリソースベースのポリシーの役割です。

SCPはプリンシパル中心のガードレール

SCP（Service Control Policy：サービスコントロールポリシー）は、組織内のIAMユーザーとIAMロールが利用できる最大アクセス許可を一元的に制御するものです。

「IDが何にアクセスできるか」を組織全体で絞り込むイメージです。

【SCPの適用イメージ】
組織のルート → OU → アカウント → IAMユーザー・ロール

SCPで「東京リージョン以外のEC2は作成不可」と設定すると
→ そのOU配下のすべてのアカウントで適用される
→ 個別のIAMポリシーで許可されていても実行できない

RCPはリソース中心のガードレール

RCP（Resource Control Policy：リソースコントロールポリシー）は、組織内のリソースで利用できる最大アクセス許可を制御するものです。2024年11月に登場した比較的新しい機能です。

「誰がリソースにアクセスできるか」を組織全体で絞り込むイメージです。

SCPとの最大の違いは、組織外部のIDからのアクセスにも効く点です。SCPは組織内のプリンシパルにしか影響しませんが、RCPは組織外のIDが自社リソースにアクセスしようとした場合にも制限をかけられます。

【SCPが防げないパターン】
組織外の攻撃者 → 自社のS3バケットに不正アクセスを試みる
→ SCPは組織内IDにしか効かないため防げない

【RCPが防ぐパターン】
組織外の攻撃者 → 自社のS3バケットに不正アクセスを試みる
→ RCPで「組織外のIDからのアクセスを拒否」と設定すれば防げる

2. SCPを深掘りする

2.1 AllowとDenyの評価順序

SCPはデフォルトで拒否するモデルに従います。SCPで明示的に許可されていないアクセス許可はすべて拒否されます。

以下のA~Dの4つのケースでSCPのAllowとDenyの評価順序を確認してください。

SCPを有効にすると、AWSは FullAWSAccess という名前のAWSマネージドSCPを自動でアタッチします。これがすべてのサービスとアクションを許可しているため、既存のIAM許可がそのまま維持されます。

SCPを有効化
  → FullAWSAccess が自動でアタッチされる（全許可）
  → この状態ではSCPを使う前と権限は変わらない
  → ここから「禁止したいことをDenyで追加する」使い方が一般的

DenyステートメントはルートレベルやOUレベルで適用されると、その下にあるすべてのアカウントに影響します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideTokyoRegion",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

上記は「東京リージョン以外でのすべての操作を禁止する」SCPの例です。

2.2 SCPが影響しないもの

SCPにはいくつかの例外があります。

管理アカウント：SCPは組織のメンバーアカウントにのみ影響します。管理アカウントのユーザーやロールには影響しません
サービスにリンクされたロール：AWSサービスがユーザーに代わって動作するために使うロールで、SCPによって制限できません
一部のタスク：Lightsailメールサーバーの逆引きDNSの設定やCloudFrontプライベートコンテンツ関連など

3. RCPを深掘りする

3.1 対応サービス一覧

RCPは以下のAWSサービスのアクションに適用されます（2025年時点）。

サービス
Amazon S3
AWS Security Token Service (STS)
AWS Key Management Service (KMS)
Amazon SQS
AWS Secrets Manager
Amazon Cognito
Amazon CloudWatch Logs
Amazon DynamoDB
Amazon Elastic Container Registry (ECR)
Amazon OpenSearch Serverless

EC2やRDSなど多くのサービスはまだRCPに対応していません。対応していないサービスには、リソースベースのポリシーを個別に設定することで同様の制御を実現します。

3.2 AWSマネージドキーには適用されない

RCPはAWSが管理するKMSキー（AWSマネージドキー）には適用されません。AWSマネージドキーはユーザーがアクセス許可を変更・管理できないためです。

3.3 SCPとRCPが影響しない共通の例外

両方とも、サービスにリンクされたロールの有効なアクセス許可には影響しません。サービスにリンクされたロールはAWSサービスがユーザーに代わって動作するために使う特殊なロールです。

4. 有効な権限の評価ロジック

SCPとRCPを踏まえた有効な権限の評価は以下のように整理できます。

有効なアクセス許可 =

  SCP で許可されている範囲
        ∩
  RCP で許可されている範囲
        ∩
  IDベースのポリシーで許可されている範囲
  （または リソースベースのポリシーで許可されている範囲）

いずれかで明示的なDenyがあれば、それが最優先になります。

具体例で確認する

【シナリオ】
SCP：S3・EC2・CloudWatchのみ許可
RCP：組織内IDからのアクセスのみ許可（組織外は拒否）
IDベース：S3フルアクセス + EC2フルアクセス + IAMフルアクセス

→ 有効な権限：S3 + EC2のみ
  （IAMはSCPで許可されていないため無効）
  （組織外IDがアクセスしようとしてもRCPで拒否）

5. SCPとRCPを併用するとデータ境界ができる

SCPとRCPを両方有効にして組み合わせることで、「データ境界（Data Perimeter）」と呼ばれるセキュリティのガードレールを作ることができます。

データ境界とは

データ境界は「信頼できるIDだけが、想定されるネットワークから、信頼できるリソースにアクセスできるようにする」ための、AWS環境内のアクセス許可ガードレールのセットです。

信頼できるID：自社組織のIAMロール・ユーザー、およびユーザーに代わって動作するAWSサービス
信頼できるリソース：自社AWSアカウントが所有するリソース
想定されるネットワーク：自社のオンプレミスやVPC

3つの境界とSCP・RCPの使い分け

境界の種類	目的	使うポリシー	条件キーの例
アイデンティティ境界	信頼できるIDだけがリソースにアクセスできる	RCP	`aws:PrincipalOrgID`
リソース境界	IDは信頼できるリソースにしかアクセスできない	SCP	`aws:ResourceOrgID`
ネットワーク境界（ID側）	IDは想定されるネットワークからのみアクセスできる	SCP	`aws:SourceVpc`
ネットワーク境界（リソース側）	リソースには想定されるネットワークからのみアクセスできる	RCP	`aws:SourceVpce`

具体的なユースケース

SCPのみで防げないパターン → RCPが必要

例えば「自社のS3バケットに社外ベンダーがオブジェクトをアップロードする」という業務があるとします。S3バケットポリシーでベンダーのアカウントにアクセスを許可している状況です。

ここで「アップロード時に必ず暗号化を要求したい」というポリシーを設けたい場合、SCPは組織内のIDにしか効かないためベンダー（組織外ID）には適用されません。RCPであれば組織外IDからのアクセスにも条件を課せるため、ベンダーからのアップロードにも暗号化を強制できます。

まとめ

項目	SCP	RCP
制御の対象	プリンシパル（ID）	リソース
組織外IDへの影響	なし（組織内IDのみ）	あり
許可を付与するか	しない（上限のみ）	しない（上限のみ）
適用できる場所	組織・OU・アカウント	組織・OU・アカウント
管理アカウントへの影響	なし	なし
サービスリンクロールへの影響	なし	なし

次の記事では、アカウント内の個別制御としてアクセス許可の境界とセッションポリシーを解説します。「組織全体の外壁」であるSCP・RCPに対し、「アカウント内の個別制御」にあたる機能です。

参考