はじめまして。
クロスインダストリー第１部クラウドコンサルティング２課の古屋です。
以前は圧倒的犬派だったのですが一人暮らしを始めてから猫と暮らしたくて仕方がありません。 通勤で電車に揺られながら〇nstgramで猫動画を漁る毎日です。
そんな話は置いておいて本題に入りますが、皆さまAWS Organizations（以下、Organizations）は使っていますか？？
Organizationsとは一言でいうと複数のAWSアカウントを1つの組織として一元管理するサービスです。マルチアカウント構成には必須のサービスですよね。
さて、そんなOrganizationsですがこんな壁にぶつかったことはありませんか？
「サービスコントロールポリシー（以下、SCP）の5個制限」
共通のガードレールを敷き、セキュリティ基準を適用し……と運用を重ねるうちに、気づけばOU（組織単位）にアタッチ済みのSCPがMAX（5個）に…
なんてことも珍しくありません。
今回はそんなSCP枠の不足を解消する方法を一つご紹介します。
結論
いきなり結論です。
「aws:PrincipalOrgPaths」でルールの適用範囲をコントロールすることでSCPの枠不足を解消可能！
この記事で伝えたいことはこれだけです。 これだけですが、状況と使い方によってはうれしい機能なのでここから詳細に説明させてください。
ぶつかる壁：なぜSCPの「5枠」はすぐに埋まるのか
まず、Organizationsにおいて1つのOUやアカウントにアタッチできるSCPの数は5個までとなります
この数字、一見余裕があるように思えるのですがガバナンスを効かせようとするとすぐに限界が訪れます。
OUを健全な状態に保つために以下のようなSCPが枠を埋めてしまうからです。
・FullAWSAccess: デフォルトで必要なSCP
・共通ガードレール: リージョン制限、特定サービスの禁止、などのSCP
※共通ガードレールはAWS Control Towerによって作成され、各OU（組織単位）でアタッチされます。
※SCPドキュメントの最大サイズは 5,120 文字となるため、制限が多いと分割され2枠以上使用する場合もあります。
このように、土台を固めようと思うとその時点でOU独自の制御に使えるのは実質2枠程度となってしまいます。
そうなるとプロジェクトごとに「このOUだけはこのサービスを禁止したい」といった柔軟な対応が難しくなります。
考えうる回避策
この制限を回避するために以下のような回避策が考えられます。
①OUの階層を深くする：
→親OUで共通設定、子OUで個別設定を行う。OU層を増やすことでSCP枠を増やす。
②SCPの結合：
→複数のポリシーを1つのJSONに結合することでSCP枠を増やす。
しかし、これらの回避策によって管理が複雑化する場合もあります。
①では、階層が深すぎれば「どこで何が制限されているのか」の把握が困難になります。
また、AWSの公式ドキュメントでもOUの深層化は避けることが推奨されています。※1
②では、単一のSCPが巨大になりすぎると可読性やメンテナンス性が低下し、修正時にミスが発生する可能性があります
また、異なる役割のポリシーを結合することで柔軟性を損なう可能性も考えられます。
※1 参考資料：マルチアカウント設計についてのホワイトペーパー https://docs.aws.amazon.com/ja_jp/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html#avoid-deep-ou-hierarchies
「aws:PrincipalOrgPaths」で何ができるのか
ここで活用したいのが、条件キーの「aws:PrincipalOrgPaths」です。
これを使用することで、「ルートや上位OUにSCPを1つアタッチするだけで、特定の下位OUに対してのみ効果を発揮させる」ことが可能になります。
これの何がうれしいのかというと、「aws:PrincipalOrgPathsを使用したSCPを親OUやRootにアタッチすることで子OUのSCP枠が節約できる」という点です。
また、親OUやRootにSCPが適用できれば、新規AWSアカウント発行時のメンテナンスの手間が減るというメリットもあります。
実践：コード例
・"ForAnyValue:StringLike"もしくは"ForAnyValue:StringNotLike"を使用し、SCPの適用範囲をコントロールすることができます。
・パスは 組織ID / ルートID / OUID/ * という構造になります。
・末尾を /* にすることで、そのOU直下のアカウントだけでなく、さらにその下の階層にあるアカウントすべてを対象に含めることができます。
"Condition": { "ForAnyValue:StringLike": { "aws:PrincipalOrgPaths": [ "o-0123456789/r-xxxx/ou-xxxx-12345678/*" ] } }
実践：検証してみた
それでは、「aws:PrincipalOrgPaths」を使用したSCPをRootにアタッチすることでルールの適用範囲をコントロールできるのか、検証していきます。
検証条件
条件１：
「InfrastructureOUを除くすべてのOUで、Iamリソースの操作を禁止する」Organizations環境を作成します。
条件２：
検証で使用するOrganizations環境は下図の構成となります。
※当該環境はSCP検証用のOrganizations環境になります。
お手元で検証する際はInfrastructureOUとSecurityOUではなく、テストOU等での検証を推奨します。
条件３：
SecurityOUでは既にSCPが5つ適用されているため、新たにIamリソースの操作禁止SCPをアタッチすることはできません。
SCPの作成、アタッチ
①検証条件の条件１に沿ったSCPを、「aws:PrincipalOrgPaths」を使用して作成します。
※今回は"ForAnyValue:StringNotLike"と記述したので、指定したInfrastractureOU以外にSCPのルールが適用されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "iam:CreateUser", "iam:CreateAccessKey", "iam:CreateLoginProfile", "iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:UpdateAccessKey" ], "Resource": "*", "Condition": { "ForAnyValue:StringNotLike": { "aws:PrincipalOrgPaths": [ "o-0123456789/r-xxxx/ou-xxxx-12345678/*" ] } } } ] }
※実際はo-0123456789/r-xxxx/ou-xxxx-12345678/*の部分にInfrastractureOUのパスを記述しています。
②作成したSCPをRootにアタッチします
これで設定は完了です。
指定していないOUで動作確認
「aws:PrincipalOrgPaths」で指定していないSecurityOUではIamリソースの操作が不可能なはずです。
今回はSecurityOU配下のAuditアカウントで確認していきます。
①作成したSCPがRootから継承されていることを確認
②Iamユーザの作成を試みる（#作成できないはず）
③エラーメッセージを確認
ユーザーが作成されませんでした。 User arn:aws:sts::*************:assumed-role/AWSControlTowerExecution/furuya is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::*************:user/test-user with an explicit deny in a service control policy: arn:aws:organizations::*************:policy/o-v4hhxpiz8d/service_control_policy/p-25bkpx46
エラーメッセージを確認すると、「作成した検証用SCP」によってIamユーザ作成が拒否されたことが分かります。
※お手元で検証する際はエラーメッセージに記載されているSCPのARNが検証用に作成したSCPのARNと一致していることを確認してください。
これで指定していないOUにIamリソース操作禁止のルールが適用されていることが確認できました。
指定したOUで動作確認
「aws:PrincipalOrgPaths」で指定したInfrastractureOUではIamリソースの操作が可能なはずです。
今回はInfrastractureOU配下のOperationManagementアカウントで確認していきます。
①作成したSCPがRootから継承されていることを確認
②Iamユーザの作成を試みる（#作成できるはず）
RootにIamリソースの操作を拒否するSCPがアタッチされているにもかかわらず、操作が拒否されずにIamユーザの作成が行えました。
本検証によって「aws:PrincipalOrgPaths」によってSCPの適用範囲がコントロール可能であることが確認できました。
注意点
非常に便利な「aws:PrincipalOrgPaths」ですが、運用上の注意点もあります。
1.パスの変更に弱い
OUを移動させるとパスが変わるため、ポリシーも修正する必要があります。
2.頼りすぎるとメンテナンス性が低下する
「aws:PrincipalOrgPaths」の条件を複雑に書き込んでしまうと可読性が低下する、
「どこで何が制限されているのか」の把握が困難になるといった可能性があります。
使い方次第ではOUの深層化やSCP結合による巨大化と同じデメリットがあることに注意してください。
まとめ
Organizationsでマルチアカウント運用をしていくにあたって、SCPの「5枠制限」という壁があります。
そんな時、「aws:PrincipalOrgPaths」を取り入れることで下位OUの自由度を保ちつつも全体のガバナンスを保つことができます。
ただし、「aws:PrincipalOrgPaths」だけが正解なわけではなく、場合によっては「OU設計から考えなおす」「既存のSCPを結合する」といった方法が最適解な場合もあります。
「OUが複雑になりすぎて管理がつらい」「SCPの枠がもうない……」とお悩みの方は、ぜひ一度試してみてください。
