IAMポリシーをどれだけ丁寧に書いても、権限を持つ管理者が「うっかり」あるいは「意図的に」やってしまう操作は防げません。組織全体で「これだけは絶対にやらせない」という一線を引くのが AWS Organizations と SCP の役割です。この記事は、クラウド設計ガイドラインの実装編として、SCPによるガードレールの敷き方を実務目線でまとめます。
01IAMだけでは統制しきれない、という前提
アカウントを立ち上げ、最小権限のIAMポリシーを設計する。ここまでは IAM設計の現実解 や アカウント初期設定 で扱ってきた通りです。しかしIAMには構造的な限界があります。IAMは「その主体に何を許可するか」を定義する仕組みであって、「権限を持つ管理者に何をさせないか」を強制する仕組みではありません。
典型的なのが、AdministratorAccess を持つ運用担当者です。彼らは業務上ほぼ何でもできます。だからこそ、東京リージョン以外にうっかりリソースを立ててしまう、検証のつもりで本番のS3バケットを消してしまう、といった操作も「権限的には」通ってしまいます。IAMポリシーで縛ろうとしても、管理者権限を持つ本人がそのIAMポリシーを書き換えられるなら、統制は成立しません。
ここで必要になるのが、個々のアカウントやIAMの外側から、組織全体に上限をかけるガードレールです。それが AWS Organizations と SCP（サービスコントロールポリシー）です。マルチアカウント全体の統制像は マルチアカウント統制 でも整理しています。
02SCPは「許可を上限で絞る」もの、許可自体はIAM側
SCPで最初に必ず押さえてほしい原則があります。SCPは権限を「付与」しません。あくまで、IAMで付与できる権限の「上限（ガードレール）」を定義するだけです。ある操作が実際に実行できるかどうかは、「SCPで許可されている」かつ「IAMで許可されている」の両方を満たしたときだけ、というANDの関係になります。
- SCPで
ec2:*を許可していても、IAM側で許可がなければ実行できません。 - IAM側で
ec2:*を許可していても、SCPでDenyされていれば実行できません。 - つまりSCPは「フタ」です。フタの範囲内で、実際の権限をIAMが決めます。
この原則を取り違えると、「SCPを付けたのに権限が足りない」「SCPで許可したのに動かない」という混乱に陥ります。SCPは足し算ではなく引き算、と覚えておくのが実務では安全です。
03OU設計 — ガードレールを掛ける単位を決める
SCPはアカウント単位でも掛けられますが、実務ではOU（Organizational Unit）に掛けるのが基本です。OUは目的や環境が近いアカウントをまとめる箱で、SCPはこのOUの階層に沿って継承されます。ルート → 親OU → 子OU → アカウント、と上から下へ全てのSCPが積み重なって効いていきます。
まず作りたいのが、AWSも推奨する定番のOU構成です。過度に細分化せず、意味のある単位に留めるのが長持ちのコツです。
- Security OU：ログ集約、監査、セキュリティツール用のアカウント。Security Lake のログ集約先などをここに置きます。
- Infrastructure OU：共有ネットワーク（Transit Gateway や共有VPC）、共通基盤系のアカウント。
- Workloads OU：実際のアプリを動かすアカウント。配下に本番用OUと非本番用OUを分け、SCPの厳しさを変えるのが定石です。
- Sandbox / Exceptions OU：検証用や、意図的にガードレールを緩めた例外アカウント。
04実際に敷くガードレールの型
ここからは具体的に、どんなSCPを敷くかです。最初から全部盛りにせず、事故インパクトの大きいものから順に入れていくのが安全です。代表的なガードレールを挙げます。
- リージョン制限：東京（ap-northeast-1）と、必要なら大阪（ap-northeast-3）以外での新規リソース作成を禁止します。
Conditionのaws:RequestedRegionで対象外リージョンをDenyします。ただしIAMやCloudFront、Route 53など一部のグローバルサービスは特定リージョン（多くはus-east-1）を経由するため、それらのアクションは除外条件に入れておかないと正規の操作まで止まります。 - ルートユーザ操作の抑止：各メンバーアカウントのルートユーザによる操作を
Condition（aws:PrincipalArnがルートに一致）でDenyします。ルートは本来ほとんど使わないはずの存在なので、封じておくのが定石です。 - 特定サービスの禁止：使わないサービス、統制上使わせたくないサービスを丸ごと
Denyします。例えば特定のML/生成AI系や、コスト事故につながりやすいサービスを非本番以外で塞ぐ、といった使い方です。 - 重要リソースの削除防止：CloudTrail の停止・削除、Config の無効化、GuardDuty の停止、ログ用S3バケットの削除などを
Denyします。監査の目を潰す操作を組織レベルで封じるのは、統制の要です。 - タグ強制：
aws:RequestTagを条件に、必須タグ（コストセンター、オーナー、環境区分など）が付いていないリソース作成をDenyします。コスト配賦の精度が上がり、気づかないうちに増えるコスト の棚卸しも効きやすくなります。 - セキュリティのベースライン保護：IAMパスワードポリシーの緩和、SCPやOUの操作、組織からの離脱などを
Denyし、統制の土台自体を守ります。
NotAction や Condition で除外できているか、必ず検証アカウントで先に確認してください。除外リストはAWSの公式ドキュメントで最新を確認するのが安全です。05SCPの限界と、RCP・IAMとの役割分担
SCPは強力ですが万能ではありません。実務で必ず知っておくべき限界がいくつかあります。
- 管理アカウント（Management Account）にはSCPが効きません。だからこそ、管理アカウントには本番ワークロードやリソースを置かず、Organizations管理に用途を絞るのが鉄則です。
- SCPは自組織のIAMプリンシパルの権限上限を絞るものです。「組織外の第三者アカウントから自社リソースへのアクセスを制限したい」といった、リソース側から見た制御はSCPの守備範囲外です。ここは2024年に登場したRCP（リソースコントロールポリシー）が担います。SCPが主体（プリンシパル）側の上限、RCPがリソース側の上限、と役割が分かれています。
- SCPは「何をさせないか」の上限であって、細かい権限設計そのものではありません。誰に何を許すかは、あくまでIAMロール／ポリシー側の仕事です。SCPで細かい業務権限まで表現しようとすると、ポリシーが肥大化して破綻します。
整理すると、組織全体の「絶対にやらせない一線」をSCP、リソースへの外部アクセス境界をRCP、個々の主体の実権限をIAM、という三層で考えると設計が素直になります。SCPの文字数上限などのクォータもあるため、詰め込みすぎず、この役割分担を守ることが結果的に運用を軽くします。
06導入の進め方 — いきなり本番に掛けない
SCPの怖いところは、間違えると組織全体の作業が一斉に止まる点です。だからこそ、段取りが全てです。EMWが実務で踏む手順はおおむね次の通りです。
- ステップ1：棚卸し。今どのリージョン・どのサービスが正規に使われているかを CloudTrail や Config で洗い出します。ここを飛ばすとリージョン制限で正規作業を止めます。
- ステップ2：Sandbox/検証OUで先行適用。本番と同じSCPを、影響の小さいアカウントに先に掛けて挙動を確認します。
- ステップ3：非本番 → 本番の順で段階展開。いきなり全OUに掛けず、緩いOUから広げます。
- ステップ4：例外運用の設計。「どうしても外したい」が必ず出ます。例外アカウントを専用OUに隔離し、誰がどう承認するかを決めておきます。承認なしの野良例外がガードレールを空洞化させます。
この考え方は、移行プロジェクトの初期に統制の土台を作る流れとも地続きです。全体像は 移行の全体フロー や 設計ガイドライン と合わせて読むと、どの工程でガードレールを敷くべきかが見えてきます。
—まとめ
IAMは「何を許可するか」、SCPは「何を絶対にさせないか」。この二つは競合するものではなく、層が違う別々の仕事です。SCPは権限を付与せず上限を絞るだけ、という原則さえ外さなければ、リージョン制限・ルート抑止・重要リソースの削除防止・タグ強制といったガードレールは、組織全体の事故を確実に減らします。
大切なのは、統制を掛けすぎて現場を止めないこと、そして例外を野放しにして空洞化させないこと。この落とし所は、実際に手を動かしながら組織の実態に合わせて調整するしかありません。マルチアカウント全体の統制像は マルチアカウント統制、費用感は 料金 も併せてご覧ください。
← ブログ一覧へ戻る