AWS

AWS SCPの書き方と適用手順：JSON例・CLI・Terraform・検証の切り分けまで解説

AWS SCPの書き方と適用手順：JSON例・CLI・Terraform・検証の切り分けまで解説

AWS SCP（サービスコントロールポリシー）は、AWS Organizations配下のメンバーアカウントで「何をしてはいけないか」の上限を組織側から縛るポリシーです。この記事では、SCPの評価ロジックと2025年9月に拡張された構文を公式ドキュメントで確かめたうえで、リージョン制限と組織離脱禁止のJSONを書き、AWS CLIでOUへ適用し、Terraformでコード管理するまでを順に進めます。適用後に権限エラーが出たときの切り分け方と、SCPを入れるべき組織・入れすぎる失敗例まで扱います。

まとめ：AWS SCPは拒否リスト型で書き、検証用OUで段階適用するのが基本形

SCPは権限を与える仕組みではありません。IAMポリシーで許可した操作のうち、組織として認めない操作を上から削る「ガードレール」です。実装の出発点は、既定のFullAWSAccessを残したまま、Denyだけを足す拒否リスト型にすることです。最初に入れる候補は、利用リージョンの限定と、組織離脱・監査ログ停止の禁止の2系統になります。

適用はルートに直接付けず、検証用OUへアカウントを1つずつ移して影響を確かめます。JSONはIAM Access Analyzerで構文検査し、Terraformで差分レビューできる状態にしておくと、誰がいつ何を縛ったかを追えます。上限は1ポリシー10,240文字、1つのOUやアカウントに10本です。この枠に収まらない設計は、統制の粒度そのものを見直すサインと捉えてください。

AWS SCPの評価ロジックとIAMポリシーとの関係を構文から確認する

JSONを書く前に、SCPがどの主体に効き、どの順で評価されるかを押さえます。ここを誤解したまま書くと、効いていないSCPや全員を締め出すSCPができあがります。Organizations全体の構成要素はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断で整理しているので、OUやルートの階層に不安がある方は先に目を通してください。

SCPが縛る範囲と、管理アカウント・サービスリンクロールの例外

AWS Organizationsユーザーガイドの「サービスコントロールポリシー (SCP)」によると、SCPはメンバーアカウントのIAMユーザーとIAMロールに効き、メンバーアカウントのルートユーザーも対象に入ります。アカウント管理者がAdministratorAccessを付けても、SCPでブロックされた操作は実行できません。

例外は2つあります。管理アカウントのユーザーとロールにはSCPが効きません。サービスにリンクされたロールも制限の外です。委任管理者に指定したメンバーアカウントには効くので、セキュリティ系サービスの委任先を縛りすぎないよう注意が要ります。組織外のアカウントからリソースベースのポリシー経由で入ってくる利用者にもSCPは届かず、そちらはリソースコントロールポリシー（RCP）の守備範囲です。

Allowは全階層で必要、Denyは1か所で効くという評価順序の読み方

SCP評価のページが示す規則は2つです。Allowはルート・OU・アカウントの経路上のすべての階層に必要で、どこか1段でも許可が欠ければ拒否になります。Denyは経路上のどこに置いても下位すべてに効き、下位のAllowでは打ち消せません。

既定では全階層にFullAWSAccessが付いているため、Allow側は最初から満たされています。拒否リスト型が扱いやすいのはこのためです。逆にFullAWSAccessを外すと、その階層より下はAllowに書いた操作しかできなくなります。最終的に実行できる操作は、SCP・RCP・IAMのアイデンティティベースポリシー・リソースベースポリシーの交点で決まり、IAM側の全体像はIAMのポリシー評価論理にまとまっています。

2025年9月のフルIAM言語対応で書けるようになった構文要素

2025年9月19日のAWSの発表で、SCPはIAM管理ポリシーと同じ記法に近づきました。Allow文での条件指定・個別リソースARN・NotActionが使えるようになり、Action文字列の先頭や途中へのワイルドカード、NotResource要素にも対応しています。既存SCPはそのまま動く後方互換です。

注意点があります。SCP構文のページは要素表でResourceとNotResourceをAllow・Deny両対応と書く一方、本文には「Allow文のResourceは*のみ」という記述が2026年10月時点で残っています。Allow文で個別ARNを使う設計は、検証用アカウントで挙動を確かめてから本番に持ち込んでください。PrincipalとNotPrincipalは引き続き使えないので、主体の絞り込みはaws:PrincipalArnの条件で書きます。

拒否リスト型SCPのJSONを書く：リージョン制限と組織離脱・監査停止の禁止

ここからは実際に適用できるJSONを書きます。題材はAWSが公開しているaws-samples/service-control-policy-examplesのサンプルです。ユーザーガイドの例示ページもこのリポジトリを参照先にしています。

NotActionとaws:RequestedRegionによるリージョン制限SCP

東京（ap-northeast-1）と大阪（ap-northeast-3）以外での操作を止めるSCPです。IAMやCloudFront、Route 53のようなグローバルサービスは米国東部のエンドポイントで動くため、NotActionで除外しないと管理コンソールの一部が開けなくなります。除外リストは公式サンプルの42項目をそのまま写しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideTokyoOsaka",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*", "acm:*", "aws-marketplace-management:*", "aws-marketplace:*",
        "aws-portal:*", "budgets:*", "ce:*", "chime:*", "cloudfront:*", "config:*",
        "cur:*", "directconnect:*", "ec2:DescribeRegions", "ec2:DescribeTransitGateways",
        "ec2:DescribeVpnGateways", "fms:*", "globalaccelerator:*", "health:*", "iam:*",
        "importexport:*", "kms:*", "mobileanalytics:*", "networkmanager:*",
        "organizations:*", "pricing:*", "route53:*", "route53domains:*",
        "route53-recovery-cluster:*", "route53-recovery-control-config:*",
        "route53-recovery-readiness:*", "s3:GetAccountPublic*", "s3:ListAllMyBuckets",
        "s3:ListMultiRegionAccessPoints", "s3:PutAccountPublic*", "shield:*", "sts:*",
        "support:*", "trustedadvisor:*", "waf-regional:*", "waf:*", "wafv2:*",
        "wellarchitected:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1", "ap-northeast-3"]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrgBreakGlassRole"
        }
      }
    }
  ]
}

ArnNotLikeの行は、障害対応用のロールだけを例外にする仕掛けです。ロール名は自組織の命名に置き換えてください。Bedrockのクロスリージョン推論を使う環境向けには、同じリポジトリに別版のサンプルが用意されています。

組織離脱とCloudTrail停止を禁止する保護系SCPと例外ロールの指定

2本目は、メンバーアカウントが組織から抜ける操作と、監査証跡を止める操作を封じるSCPです。どちらも公式サンプルの2本を1つに束ねました。証跡名は実環境の値に置き換えます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectOrgTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail", "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail", "cloudtrail:PutEventSelectors"
      ],
      "Resource": "arn:aws:cloudtrail:*:*:trail/org-trail",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrgBreakGlassRole"
        }
      }
    }
  ]
}

Deny文で個別ARNを指定する書き方は、2025年9月の拡張以前から使えました。証跡そのものの設計はCloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説を参照してください。同じ発想で、AWS Configの記録停止やGuardDutyの無効化を禁じるサンプルもリポジトリに並んでいます。

AWS CLIでSCPを有効化・作成し、検証用OUへアタッチする作業手順

コンソールでも同じ操作はできますが、手順を再現できるようCLIで進めます。実行は管理アカウント（または委任管理者）の認証情報で行います。

enable-policy-typeからattach-policyまでの4本の実行手順

使うのはenable-policy-type、create-policy、attach-policyの3つと、確認用の一覧取得です。SCPはすべての機能を有効にした組織でしか使えず、一括請求のみの組織では先に機能の切り替えが必要になります。

# 1. ルートIDを確認し、SCPのポリシータイプを有効にする
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)
aws organizations enable-policy-type --root-id "$ROOT_ID" \
  --policy-type SERVICE_CONTROL_POLICY

# 2. JSONファイルからSCPを作成し、ポリシーIDを控える
POLICY_ID=$(aws organizations create-policy \
  --name deny-outside-tokyo-osaka \
  --type SERVICE_CONTROL_POLICY \
  --description "Deny actions outside ap-northeast-1 and ap-northeast-3" \
  --content file://scp-deny-region.json \
  --query 'Policy.PolicySummary.Id' --output text)

# 3. 検証用OUにだけアタッチする（ルートには付けない）
aws organizations attach-policy --policy-id "$POLICY_ID" \
  --target-id ou-abcd-11111111

# 4. 付いているSCPを確認する
aws organizations list-policies-for-target \
  --target-id ou-abcd-11111111 --filter SERVICE_CONTROL_POLICY

文字数を数える際は、コンソールとCLI・SDKで保存方法に差がある点にも注意が必要です。クォータのページによれば、コンソール保存では引用符の外の空白や改行が除かれますが、CLIやSDKでは指定どおりに保存されます。上限の10,240文字に近いJSONは、jq -cで1行に圧縮してから渡すと枠を空けられます。

Access Analyzerのvalidate-policyによる適用前の構文検査

create-policyに渡す前に、IAM Access Analyzerのvalidate-policyでJSONを検査します。--policy-typeにSERVICE_CONTROL_POLICYを指定でき、SCPで使えない要素や存在しないアクション名を指摘してくれます。

aws accessanalyzer validate-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --policy-document file://scp-deny-region.json \
  --query 'findings[].[findingType,issueCode,findingDetails]' --output table

結果が空なら指摘なしです。CIでこのコマンドを走らせ、ERRORが1件でもあればマージを止める運用にすると、レビュー担当がJSONを目で追う負担が減ります。

TerraformでSCPをコード管理し、OU単位の適用差分をレビューする

SCPを数本以上運用するなら、コンソールの手作業は避けてIaCに載せます。誰がいつどのOUを縛ったかがPull Requestに残り、戻すときも差分を当て直すだけで済みます。

aws_organizations_policyとOUへの付与の最小構成・注意点

Terraform AWS Providerでは、ポリシー本体をaws_organizations_policy、OUへの付与をaws_organizations_policy_attachmentで書きます。JSONは前章のファイルをそのまま読み込みます。

resource "aws_organizations_policy" "deny_region" {
  name        = "deny-outside-tokyo-osaka"
  description = "Deny actions outside ap-northeast-1 and ap-northeast-3"
  type        = "SERVICE_CONTROL_POLICY"
  content     = file("${path.module}/policies/scp-deny-region.json")
}

resource "aws_organizations_policy_attachment" "deny_region_sandbox" {
  policy_id = aws_organizations_policy.deny_region.id
  target_id = var.sandbox_ou_id
}

注意点は、attachmentを足すたびに対象OUの10本枠を1つ消費することです。FullAWSAccessも1本に数えるため、拒否リスト型で実際に使えるのは9本になります。OUごとに似たSCPを量産するより、Statementを束ねて本数を抑えるほうが長く持ちます。Control Towerを併用している場合は、Control Towerが管理するSCPもこの枠に入る点を確認してください。

SCPが効かない・効きすぎるときのテストと原因切り分けの手順

SCPの事故は「付けたのに効かない」と「想定外の操作まで止まった」の2種類です。前者は管理アカウントで試しているケースが大半で、後者は適用範囲を急いで広げたときに起きます。

検証用OUへ1アカウントずつ移して業務操作への影響を確かめる段階適用

AWSはSCP本体のページで、影響を十分にテストしないままルートにアタッチしないよう強く勧めています。手順は、SCPを付けた検証用OUを作り、アカウントを1つずつ移して業務操作を一巡させ、問題がなければ本番OUへ付け替える流れです。

移す前に、IAMのOrganizationsの最終アクセス情報で、対象アカウントが実際に使っているサービスを洗い出します。CLIではaws iam generate-organizations-access-reportを使うと、対象アカウントのサービス利用状況を確認するレポートの作成が可能です。直近に東京以外のリージョンで動いているサービスがあれば、リージョン制限SCPを付けた瞬間に止まるので、先に移設か例外ロールの設計を済ませます。

拒否エラーの文面とCloudTrailでSCPが原因かを特定する方法

SCPで止まった操作は、エラー文に原因の種類が出ます。IAMのアクセス拒否エラーのトラブルシューティングによると、明示的なDenyならwith an explicit deny in a service control policy、Allowが足りない場合はbecause no service control policy allowsという文面です。前者はポリシーARNが付くこともあり、どのSCPが止めたかまで分かります。

エラー文を受け取れない自動処理では、CloudTrailのイベント履歴でerrorCodeがAccessDenied系のイベントを探し、errorMessageを読みます。文面に「service control policy」が無ければ、原因はIAMポリシーかリソースベースポリシー側です。IAM側の権限設計はAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスで整理しています。

SCPを導入すべき組織の条件と、許可リスト型・過剰な制限を避ける場面

最後に、SCPを入れる判断と、入れ方を誤る典型を言い切っておきます。

SCPを入れるべき組織の条件と、最初に適用する2本の優先順位

メンバーアカウントが3つ以上あり、各アカウントの管理者権限を開発チームに渡しているなら、SCPは入れるべきです。IAMの権限をどれだけ絞っても、アカウント管理者が自分で外せる以上、組織側の上限は別に要ります。反対に、アカウントが管理アカウントだけ、または全アカウントを1人の運用者が握っている体制では、SCPを書く手間に見合う効果は出ません。

優先順位ははっきりしています。1本目は組織離脱と監査証跡停止の禁止、2本目がリージョン制限です。前者は業務を止めるリスクがほぼ無く、後者は移設の下調べが要るためです。マルチアカウントの設計からSCPの運用までをまとめて相談したい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で既存環境の棚卸しから支援しています。

許可リスト型を選ばない理由と、文字数・10本上限で詰まる失敗例

FullAWSAccessを外して使うサービスだけをAllowに書く許可リスト型は、統制の強さだけ見れば魅力的です。ただ、新サービスを使うたびにSCP改修が要り、開発チームから見ると申請待ちの壁になります。規制業種で利用サービスを監査上固定する必要がある組織を除き、採用しません。

よくある失敗は、案件ごとに細かいDenyを足し続けて10本枠と10,240文字の両方を使い切るパターンです。SCPはアクション単位の粗いガードレールに留め、リソース設定の細かな強制はAWS Configのルールや宣言型ポリシーに任せます。Configの使い方はAWS Configとは？設定変更の記録・ルール評価・料金の実額と導入判断で扱っています。

よくある質問

AWS SCPの実装でつまずきやすい点を、検索の多い質問から5つ選んで答えます。

SCPは管理アカウントやルートユーザーにも効きますか？

管理アカウントには効きません。管理アカウントのユーザーとロールは、ルートユーザーを含めてSCPの対象外です。メンバーアカウントのルートユーザーには効くため、メンバー側のルート操作を縛る目的には使えます。SCPの動作確認を管理アカウントで行うと「効かない」と誤解するので、必ずメンバーアカウントで試してください。

SCPだけでIAMユーザーに権限を付与することはできますか？

できません。SCPは実行できる操作の上限を定めるだけで、権限そのものは付与しない仕組みです。SCPですべての操作を許可していても、IAMポリシーが付いていないユーザーは何もできません。実際に使える権限は、SCPとIAMポリシーの両方で許可された操作の重なりになります。

1つのOUに付けられるSCPの数と文字数の上限はいくつですか？

2026年10月時点のOrganizationsクォータでは、ルート・OU・アカウントのいずれにも最大10本、1本あたり最大10,240文字です。各エンティティには最低1本のSCPが必要で、最後の1本は外せません。組織全体で作れるSCPは10,000本までです。アタッチ数の上限はハード制限と明記されており、申請による引き上げはできません。

特定のIAMロールだけをSCPの制限から外せますか？

外せます。SCPにはPrincipal要素が書けないため、Deny文のConditionにArnNotLikeとaws:PrincipalARNを置いて例外ロールを指定します。本記事のJSON例と同じ書き方です。例外ロールは引き受けられる人を限定し、利用をCloudTrailで監視する前提で設計してください。

Control Towerを使っている環境でもSCPを自作して追加できますか？

追加できます。Control Towerの予防コントロールはSCPやRCPで実装されており、自作SCPはそれと並んでOUに付きます。ただし同じ10本枠を分け合うので、有効化しているコントロールの数を先に確認してください。Control Tower自体の構成はAWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断で解説しています。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.09.30　テックブログ OpenAI Dotsとは？常時稼働エージェントの権限設計と自社システム接続【2026年9月】
  2. 2026.09.28　テックブログ タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計
  3. 2026.09.27　コラム 法定調書合計表とは？令和8年分の書き方と提出義務、給与・支払データからの集計自動化
  4. 2026.03.10　コラム 年収の壁【2026年最新】178万円・136万円・130万円の一覧と手取りの分岐点
  5. 2026.09.05　コラム 犯罪収益移転防止法の本人確認：2027年4月の対面IC読み取り義務化と改修要件

RELATED POSTS 関連記事

一覧へ戻る

目次