はじめに
今回は、先日発表されたService Control Policy（SCP）の上限緩和アップデートについて説明します。このアップデートにより、OUまたはアカウントにアタッチできるSCPの最大数が5から10へ、SCPの最大文字数が5120文字から10240文字へと緩和されました。一見地味なアップデートに思えるかもしれませんが、共通基盤の運用においてはSCPの数や内容が増えることは珍しくないため、今回のアップデートは多くのユーザーに歓迎されるでしょう。
SCPの数が増えることのメリット
昨今のマルチアカウント環境では、AWSが提供するOU構成のベストプラクティスに従い、Workloads OUに多数のメンバーアカウントを配置するケースが多いです。Workloads OUに対しては、共通基盤の運営を阻害する操作を禁止するSCPや、セキュリティガードレールの変更を禁止するSCP、ネットワーク関連の操作を禁止するSCP、IAM関連の操作を禁止するSCPなど、多岐にわたる制御が必要です。本来は意味のある単位でSCPを分割管理することが望ましいですが、旧上限5では1つにまとめる必要があり管理が煩雑でした。上限10への緩和により、より細かく分割して管理できるようになりました。
SCPの文字数が増えることのメリット
複数の制御を1つのSCPにまとめる場合、文字数5120文字の制限が課題となることがありました。ワイルドカードを利用して文字数を節約する方法もありますが、視認性が悪くなり、複雑な内容では文字数が不足するケースもありました。また、IAM Identity Centerを導入している環境では、許可セットごとにIAMロールが作成されるため、ConditionでCCoE用ロールを除外する必要があり、文字数が不足しがちでした。上限10240文字への緩和により、よりきめ細やかなSCPが作成可能になりました。
Control Tower環境でのSCP上限管理
AWS Control Towerを利用している環境では、Control Towerが自動的にSCPをアタッチするため、旧上限5ではカスタムSCPに割ける枠が限られていました。Control Towerの必須コントロールだけで1～3枠を占有し、任意の予防的コントロールを有効化すると、カスタムSCPは1～2枠しか残らないこともありました。上限10への緩和により、カスタムSCPに余裕を持って枠を確保できるようになりました。
OUネストによるSCP枠の工夫
従来は、Workloads OU内に子OUをネストすることで、親OUのSCPを継承しつつ子OUにカスタムSCPを割り当てる設計が採用されることもありました。上限緩和によりこの必要性は薄れましたが、OU単位で役割を分けて管理する設計思想は引き続き有効です。
SCP分割の推奨設計テンプレート
上限10への緩和を踏まえた設計例として、Workloads OU（親）に共通SCPを集約し、子OUには環境固有のSCPのみを配置する構成が推奨されます。親OUには組織ガバナンス系、セキュリティ監査系、ネットワーク系、IAM系、リージョン制限系のSCPをアタッチし、子OUには踏み台経路強制系などのSCPをアタッチします。親OUのSCPは子OUに継承されるため、子OUの枠を有効活用できます。
既存SCPの安全な分割手順
既存環境でSCPを分割する際は、以下の手順を踏むことで安全に移行できます。
- 現状の棚卸し：対象OUのSCPを一覧化し、管理SCPとカスタムSCPを分類。
- 新しいSCPの設計：カテゴリごとに分割し、CCoE除外Conditionを含める。
- 設計レビュー：漏れなくStatementが含まれているか確認。
- 新しいSCPの作成：アタッチはせずに作成。
- テストOUでの検証：サンドボックスで動作確認。
- 先行グループへの段階的適用：アカウント直接アタッチで影響範囲を限定。
- OUへの切り替えと古いSCPの削除：新SCPをOUにアタッチしてから古いSCPをデタッチ。
- 最終確認：全アカウントで問題ないか確認。
重要なのは、新SCPをOUにアタッチしてから古いSCPをデタッチすることです。逆順で実施すると、Denyが一時的に外れ、意図しない操作が可能になります。
おわりに
今回のSCP上限緩和は、実務上非常に喜ばしいアップデートです。本稿がOrganizationsのSCP管理に悩む方の参考になれば幸いです。
奥村康晃（おくむら やすあき）NTTデータ入社以来、クラウド管理プラットフォームの開発に従事。現在はクラウド導入の技術コンサルや技術戦略立案に携わる。2025年度Top AWS Ambassador受賞。
