記事公開日
【AWS Organizations SCPアップデート】DenyとAllowのハイブリッド方式で実現する、現実的で堅牢な新世代ガードレール

はじめに
DXソリューション営業本部の小原です。
今回はAWS OrganizationsのSCPのアップデートに伴う新しい形のガードレールについて検討していきます。
AWS Organizationsのガードレール、SCPの役割とは
AWSを利用する企業にとって、複数のAWSアカウントを効率的かつ安全に管理することは、ガバナンス上非常に重要な課題です。AWS Organizationsは、この課題を解決するための中心的なサービスであり、その中でもサービスコントロールポリシー(SCP)は、組織全体のセキュリティガードレールとして不可欠な機能です。
SCPを利用することで、組織内の各アカウントが実行できる操作の上限を定義できます。例えば、「許可されていないリージョンの利用を禁止する」「ルートユーザーでの特定の操作を禁止する」といった統制を一元的に強制することが可能です。
これまで多くの企業では、特定の危険な操作を名指しで禁止する「Denyリスト方式」でSCPを運用してきました。しかし、2025年9月のアップデート※により、SCPがIAMポリシーの全機能をサポートしたことで、この常識は変わるかもしれません。
本記事では、このアップデートがもたらした変化を解説し、これからのSCPのベストプラクティスとなりうる「Allowリストを基本としつつ、重要な部分のみDenyを組み合わせるハイブリッド方式」を提案します。
※参考: Unlock new possibilities: AWS Organizations service control policy now supports full IAM language
これまでのSCP:「Denyリスト方式」とその課題
従来、SCPで一般的だったのは「Denyリスト方式」です。これは、デフォルトではすべての操作が許可されている状態(FullAWSAccess
)をベースに、禁止したい特定の操作(Action)を"Effect": "Deny"
で明示的に記述するアプローチです。
<従来のDenyリスト方式の例>
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:DeleteUser",
"organizations:LeaveOrganization"
],
"Resource": "*"
}
]
}
この方法はシンプルで分かりやすい反面、組織の成長やAWSのサービス拡充に伴い、いくつかの課題が顕在化していました。
-
課題1:新しいサービス・機能への追従が困難 AWSでは日々新しいサービスや機能がリリースされます。Denyリスト方式では、新たなリスクとなりうる操作が追加されるたびに、人間がそれを検知し、SCPのDenyリストに追加し続けなければなりません。この運用は大きな負担であり、対応が遅れればセキュリティホールとなり得ます。
-
課題2:意図しない許可を生むリスク 「禁止リストに書かれていない操作は、すべて許可される」という性質上、リストに漏れがあれば、本来は禁止すべき危険な操作が意図せず実行されてしまう可能性があります。
-
課題3:ポリシーの複雑化・肥大化 組織のセキュリティ要件が増えるにつれて、禁止事項も増えていきます。結果としてSCPは長大で複雑なものとなり、可読性が低下し、管理が困難になるという問題がありました。
【本題】アップデートで何が変わったのか?
今回のアップデートにより、SCPはこれまで利用できなかったIAMポリシーの条件キーやNotAction
、NotResource
といった要素を完全にサポートするようになりました。
アップデートによってポリシーの表現力が向上したことで、「明示的に許可した操作以外は、すべて禁止する」というAllowリスト(ホワイトリスト)方式が、セキュリティの基本原則「最小権限の原則」を実現する上で非常に効果的になりました。
<Allowリスト方式のメリット>
-
最小権限でアクセス付与: 明示的に許可していないサービス・操作はすべて拒否されるため、未知のリスクに対して堅牢です。
-
ガバナンスの強化とポリシーの明確化: 「組織として利用を許可しているサービスは何か」が一目瞭然になります。
-
ポリシーのシンプル化と管理コストの削減: 肥大化しがちなDenyリストとは対照的に、許可するサービスを列挙していくため、ポリシーをシンプルに保てます。
しかし、Allowリスト方式だけを純粋に採用すると思わぬ落とし穴にはまる可能性もあります。そこで、より現実的で堅牢な構成としてDenyポリシーを組み合わせたハイブリッド方式を推奨します。
現実解としての「ハイブリッド方式」と具体的な構成
Allowリスト方式は強力ですが、運用ミスにより意図せず広い権限を持つSCP(例えばFullAWSAccess
)が下位のOUとアカウントにアタッチされてしまうリスクもゼロではありません。
そこで、組織全体に「絶対に越えてはならない一線」をDenyポリシーで定義し、その内側でOUやアカウントごとにAllowリスト方式を適用する、多層防御の考え方が有効になります。
<ハイブリッド方式の構成例>
-
組織のルート (Root) に適用するポリシー
組織からの離脱やSCPの無効化など、ガバナンスの根幹を揺るがす絶対に許可したくない操作をDeny
で固めます。これは組織の最後の砦となります。【ルートに設定するDenyポリシーの例】
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "organizations:LeaveOrganization", "organizations:DetachPolicy", "organizations:DisablePolicyType" // その他、セキュリティツール(GuardDuty, SecurityHub等)の無効化など ], "Resource": "*" } ] }
-
各OUや各アカウントに適用するポリシー
ルートで設定した絶対的なガードレールの内側で、各OUや各アカウントの役割に応じて、許可するサービスを列挙したAllowリスト方式のSCPを適用します。【開発OUに設定するAllowポリシーの例】
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "s3:*", "rds:*", "iam:List*", "iam:Get*" // 開発で必要なサービスを列挙 ], "Resource": "*" } ] }
このハイブリッド方式により、「普段は許可されたサービスしか使えないが、万が一運用ミスがあっても、組織の根幹を守る操作は絶対にできない」という、より安全な状態を作り出すことができます。
SCPの制御の仕組みと例
ハイブリッド方式でSCPを制御していくにあたり、知っておく必要のあるSCPの制御の仕組みについてまとめます。
AWS OrganizationsのSCPでは複数のStatementがアタッチされている場合、それぞれのAllowとDenyの評価方法が異なります。
違いをまとめると以下のようになります。
評価タイプ | 評価ロジック | 目的・使われ方 |
Allow | AND型フィルタリング すべての適用されるSCPで Allow と評価されなければ、その操作は許可されません。一つでも Allow の範囲外であれば、その操作は暗黙的に拒否されます。 |
利用可能なサービスのホワイトリスト化 OUやアカウントごとに、「この範囲のサービスしか使わせない」という許可の最大範囲を定義するために使います。 |
Deny | OR型フィルタリング 適用されるSCPのうち一つでも Deny と評価されるものがあれば、その操作は明示的に拒否されます。 |
禁止したい操作のブラックリスト化 組織からの離脱やセキュリティ設定の無効化など、IAMポリシーの内容に関わらず「この操作は許可しない」という禁止操作を定義するために使います。 |
SCPにおける権限評価は、常にDeny
がAllow
に優先します。
-
まず、Denyの評価が行われます。適用されるSCPの中に一つでも対象操作を
Deny
とする記述があれば、その時点で操作は即座に拒否されます。 -
どのSCPでも
Deny
に該当しなかった場合、次にAllowの評価が行われます。適用されるすべてのSCPで対象操作がAllow
の範囲内に含まれていれば、その操作はSCPのガードレールを通過できます。(その後、IAMポリシーで許可されていれば実行可能) -
どのSCPでも
Deny
に該当せず、かつ、Allow
の範囲にも含まれていない場合、その操作は拒否されます。
具体例としてのイメージ図を以下に示します。