マルチアカウント環境を運用していると、「あるアカウントの担当者が意図せず危険な設定をしてしまった」「全社ポリシーに反するリソースが作られてしまった」という問題が頻発します。IAMポリシーで対応しようとしても、アカウントごとにルールを徹底させるのは現実的ではありません。
AWS OrganizationsのSCP（Service Control Policies）は、複数のAWSアカウントにまたがって「やってはいけないこと」を一括で制限できる仕組みです。この記事では、SCPの動作原理からオンプレ経験者が迷いやすいIAMポリシーとの違い、そして現場で実装すべきガードレールのパターンを体系的に解説します。
SCPとは何か？オンプレとの違いと必要性
オンプレ環境では、ネットワーク境界・Active Directoryのグループポリシー・セキュリティ製品の組み合わせでアクセス制御を実現していました。しかしクラウドでは、各アカウントの管理者がAPIを通じてほぼあらゆるリソースを作成・変更できます。
このとき問題になるのが「管理者が意図的または誤って、会社ポリシーに違反する設定をしてしまう」リスクです。
・本番環境でCloudTrailを誤って無効化してしまった
・開発用アカウントから外部に意図せずリソースを公開してしまった
・コスト上限を超える高額なEC2インスタンスタイプを起動してしまった
IAMポリシーはアカウント内のアクセス制御には有効ですが、「そのアカウントの管理者（admin権限保持者）」への制限には使えません。SCPはそのアカウント全体に対して「この操作は絶対に許可しない」という上位制約を課せる点が、IAMポリシーとの最大の違いです。
Active Directoryのグループポリシーが組織単位（OU）に適用されるように、SCPはAWS OrganizationsのOU階層に適用します。OU以下のすべてのアカウントで、SCP違反のAPIコールは自動的に拒否されます。
SCPの仕組みを理解する
1. OU階層とSCPの適用範囲
SCPを理解するにはAWS Organizationsの階層構造が前提になります。組織（Root）の下にOU（Organizational Unit）があり、その下に複数のAWSアカウントが所属します。
AWS OrganizationsでSCPを有効化すると、Rootに適用したSCPは組織全体に、特定のOUに適用したSCPはそのOU内のアカウントすべてに効きます。
・Root SCP: 全アカウント共通の最低ラインのガードレール
・OU SCP: 本番OU・開発OU・セキュリティOUなど用途別の追加制約
・アカウント SCP: 特定のアカウントのみへの追加制約（例外的に使用）
2. ポリシー評価の順序（SCPは最大権限を制限する）
SCPの動作で最も重要な概念が「SCPはIAMポリシーで付与された権限の上限を制限する」という点です。
たとえば、あるIAMユーザーに AdministratorAccess ポリシーが付与されていても、そのアカウントが所属するOUのSCPで "Action": "ec2:*" をDenyしていれば、そのユーザーはEC2操作を一切できません。
| ポリシー種別 | 誰が設定するか | 適用範囲 |
|---|---|---|
| SCP（Deny） | Organizations管理アカウント | アカウント全体（adminユーザー含む） |
| IAMポリシー（Allow） | 各アカウントの管理者 | IAMプリンシパル単位 |
| Permission Boundary | 各アカウントの管理者 | 特定のIAMユーザー/ロール |
つまり、権限の有効化には「SCPが許可している範囲内で、IAMポリシーがAllowしている」という二重の条件が必要です。SCPのDenyはIAMのAllowに勝ちます。
AWS IAM Permission Boundariesと組み合わせると、「管理者が作ったロールの権限範囲をさらに絞る」三層構造の制御が実現できます。
3. Allow型SCPとDeny型SCPの使い分け
SCPには2つの使い方があります。
Deny型（明示的な禁止）：特定の操作を禁止する。FullAWSAccess SCPを維持しつつ、追加のDenyで制限を加える最も一般的なパターンです。
Allow型（許可リスト方式）：明示的に許可したアクションのみを有効化し、それ以外をすべて禁止する。デフォルトのFullAWSAccess SCPを外してAllow型のみを適用するため、管理コストが高く、実務では対象アカウントを絞って慎重に使います。
多くの組織では「Deny型ガードレール＋IAMで最小権限」の組み合わせを採用しています。
実装すべきガードレールのパターン集
1. リージョン制限（東京リージョン以外禁止）
日本の法令・社内コンプライアンス上、データを国内に置く必要がある場合、東京リージョン（ap-northeast-1）以外へのリソース作成を禁止します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonTokyoRegion", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["ap-northeast-1"] }, "ArnNotLike": { "aws:PrincipalARN": [ "arn:aws:iam::*:role/SecurityBreakGlassRole" ] } } } ] }
ポイントは ArnNotLike 条件で「例外ロール」を設けること。IAM・CloudFront・Route 53などのグローバルサービスは内部的にus-east-1エンドポイントを使います。これらの操作が必要なロールはArnNotLikeで除外します。
2. rootユーザーアクションの禁止
rootアカウントへのアクセスは原則禁止が鉄則です。SCPで以下を強制します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyRootUserActions", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } } } ] }
このSCPを適用すると、rootユーザーで行えるのはSCP自体の変更（管理アカウントから）と、サポートプランの変更など一部の請求関連操作のみになります。注意点として、Organizations管理アカウントにはSCPが適用されません。管理アカウントのrootは別途MFAと物理的な鍵管理で保護します。
3. CloudTrail・AWS Configの無効化禁止
監査証跡の保護は最優先事項です。攻撃者はまずCloudTrailを止めて証拠を隠滅しようとします。CloudTrailとGuardDutyの無効化をSCPで防ぎます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ProtectAuditServices", "Effect": "Deny", "Action": [ "cloudtrail:DeleteTrail", "cloudtrail:StopLogging", "cloudtrail:UpdateTrail", "config:DeleteConfigRule", "config:DeleteConfigurationRecorder", "config:DeleteDeliveryChannel", "config:StopConfigurationRecorder", "guardduty:DeleteDetector", "guardduty:DisassociateFromMasterAccount", "securityhub:DisableSecurityHub" ], "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": [ "arn:aws:iam::*:role/SecurityAdminRole" ] } } } ] }
AWS Configのレコーダー停止やルール削除も合わせて禁止することで、コンプライアンス証跡の完全性を担保します。GuardDutyの無効化禁止も組み込むと、脅威検知基盤の恣意的な停止を防げます。
4. Organizations離脱禁止とIAM危険アクションの制限
アカウントがOrganizationsから離脱すると、SCPや集中管理されたセキュリティツールがすべて無効化されます。この操作を必ず禁止します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyOrganizationsLeave", "Effect": "Deny", "Action": [ "organizations:LeaveOrganization" ], "Resource": "*" }, { "Sid": "DenyMFADeviceManagement", "Effect": "Deny", "Action": [ "iam:DeactivateMFADevice", "iam:DeleteVirtualMFADevice" ], "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::*:role/IAMAdminRole" } } } ] }
MFAデバイスの無効化・削除をIAMAdmin以外に禁止することで、アカウントのMFA保護が意図せず解除されるリスクを低減します。
5. 開発OU向け高額インスタンス制限
コスト制御の観点から、開発OUでは本番相当の高額サービスを制限します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyExpensiveInstancesDev", "Effect": "Deny", "Action": ["ec2:RunInstances"], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotLike": { "ec2:InstanceType": [ "t3.*", "t2.*", "m5.large", "m5.xlarge" ] } } } ] }
このSCPを開発OUに適用すると、開発者が誤って p3.16xlarge（GPU付き高額インスタンス）を立ち上げることを防げます。Root SCPではなくOU単位で適用するため、本番環境には影響しません。
SCPの設計で陥りやすい落とし穴
【落とし穴1】管理アカウントはSCPが効かない
Organizations管理アカウント（master account）はSCPの適用範囲外です。管理アカウントには本番ワークロードを一切置かず、Organizations管理専用として最小限の利用に留めます。
【落とし穴2】グローバルサービスがリージョン制限SCP適用後に壊れる
IAM・CloudFront・Route 53・AWS Organizations自体などのグローバルサービスは、内部的にus-east-1のエンドポイントを使います。リージョン制限SCPの適用範囲に入ると、IAMユーザー作成や証明書更新が全滅します。Condition内の StringNotEquals の許可リストに "us-east-1" を追加するか、グローバルサービスのアクションをNotActionで明示的に除外する設計が必要です。
【落とし穴3】SCP適用後のテスト不足
SCPは即座に全アカウントに効きます。本番OUに誤ったSCPを適用すると、業務停止が発生します。必ず以下の順序で適用します。
・新規に作成したテスト用OU（Sandboxアカウント）で検証する
・開発OUに適用して一週間以上様子を見る
・本番OUは最後に適用し、適用直前に担当者全員に通知する
【落とし穴4】Deny型SCPの例外ロールARNパターンの誤り
ArnNotLike の例外ロールARNが正しくないと、SecurityAdminさえもブロックされてしまいます。例外ロールARNは arn:aws:iam::*:role/RoleName（アカウントID部分を * でワイルドカード）で記述します。ロール名に揺れがある場合は *SecurityAdmin* のようにワイルドカードを使います。
SCPのテスト・検証方法
1. IAM Policy Simulatorによる事前確認
AWSマネジメントコンソールの「IAMポリシーシミュレーター」では、SCPを含めたポリシー評価をシミュレーションできます。対象アカウントにログインした状態で実行し、意図したAPIコールが拒否されるか・意図しない拒否が発生しないかを確認します。
2. AWS IAM Access Analyzerを使った権限確認
AWS IAM Access Analyzerを使うと、SCP適用後に意図せず外部公開されているリソースや、権限過剰のロールを自動検出できます。SCP適用前後でAnalyzerの検出結果を比較することで、意図しない制限の有無を確認できます。
3. Control Tower Sandboxアカウントの活用
AWS Control Towerを導入している場合は、Control TowerのSandboxOUに検証用アカウントを作成し、そこで新規SCPをテストしてから本番OUに昇格させるフローを確立します。Control TowerはSCPのバージョン管理もサポートしています。
4. CloudTrailによるSCP拒否イベントの監視
SCPによる拒否はCloudTrailに AccessDenied イベントとして記録されます。errorCode: "AccessDenied" かつ errorMessage に explicit deny が含まれるイベントをCloudWatch Logsに流してアラートを設定することで、SCP適用直後の意図しない拒否を素早く検知できます。
本記事のまとめ
SCPはマルチアカウント環境における「守り」の要であり、IAMポリシーでは防げない管理者権限のミスユーズを防ぐ組織レベルの制御手段です。
| ガードレールの種類 | 守れるリスク | 推奨適用OU |
|---|---|---|
| リージョン制限 | データ越境・コンプライアンス違反 | Root（全体） |
| rootアクション禁止 | rootアカウントの不正利用 | Root（全体） |
| 監査サービス保護 | CloudTrail/Config無効化による証跡消失 | Root（全体） |
| Organizations離脱禁止 | 管理外アカウント化・SCP無効化 | Root（全体） |
| 高額インスタンス制限 | コスト暴走 | 開発OU・検証OU |
SCPの設計は一度で完成させるのではなく、インシデントや監査結果に応じて継続的に見直します。適用順序（Sandbox→開発→本番）と例外ロールの管理を徹底することで、業務影響なくセキュリティのベースラインを引き上げられます。
マルチアカウント管理の全体設計についてはAWS Organizations入門、SCPと組み合わせて使う権限制御についてはIAM Permission Boundariesの記事もあわせてご覧ください。
PR
AWSではじめるクラウドセキュリティ（松本照吾ほか／日経BP）
IAM・VPC・SCPなどAWSセキュリティの実装を体系的に学べる一冊。マルチアカウント環境のガードレール設計にも詳しく触れており、本記事の内容をさらに深掘りしたい方に最適です。
