Service Control Policy（SCP）の上限緩和のアップデートがもたらすメリット

はじめに

今回は、先日発表されたService Control Policy（SCP）の上限緩和のアップデートについて説明します。

このアップデートにより、OUまたはアカウントにアタッチできるSCPの最大数が5から10へ、SCPの最大文字数が5120文字から10240文字へと緩和されました。 一見地味なアップデートに思えるかもしれませんが、共通基盤の運用においては、SCPの数や内容が増えることは珍しくないため、今回のアップデートは多くのユーザーに歓迎されるのではないかと思います。いくつか具体的な例を挙げて説明します。

1. SCPの数が増えることのメリット

昨今のマルチアカウント環境では、AWS社から提供されているOU構成のベストプラクティスに従い、以下の画像のようなOU構成を採用するケースが多いでしょう。ここで課題となりやすいのは、多数のメンバーアカウントが配置されるWorkloads OUに対するSCPです。

• 

Workloads OUに対しては、例えば以下のようなSCPをアタッチすることが考えられます。

• 共通基盤の運営上の阻害要因となる操作を禁止するSCP（例：AWSアカウントのOrganizationsからの離脱やサポートプランの変更など）
• CCoEにて作成したセキュリティガードレールの変更を禁止するSCP（例：CloudTrailの停止やSecurity Hubの無効化など）
• ネットワーク関連の操作を禁止するSCP（例：VPCの削除やTransit Gatewayの作成など）
• IAM関連の操作を禁止するSCP（例：IAMユーザーの作成やIAM Identity Centerで利用するカスタムIAMポリシーの変更など）

本来はある程度意味のある単位でSCPを分けて管理することが望ましいですが、SCPの数が5つまでしかアタッチできない場合、上記のようなSCPを1つのSCPにまとめる必要があり、管理が煩雑になる可能性があります。今回のアップデートにより、SCPの数が10までアタッチできるようになったため、より意味のある単位でSCPを分割して管理することが可能になりました。

2. SCPの文字数が増えることのメリット

前述した理由で複数の制御を行うためのSCPを1つのSCPにまとめていた際は、SCPの文字数が5120文字までしか利用できないことが課題となるケースもあったのではないでしょうか。

第27回で紹介した、ワイルドカードを利用する方法で文字数を節約することもできますが、視認性が悪くなりますし、SCPの内容が複雑になると、ワイルドカードを利用しても文字数が足りないケースもあるでしょう。

また、マルチアカウント環境では、IAM Identity Centerを導入しているケースも多いかと思います。その場合、各メンバーアカウントには、許可セット名ごとに「AWSReservedSSO_許可セット名_ランダムな文字列」というIAMロールが作成されることになります。共通基盤を運営している場合、CCoEをSCP適用の例外として設定したいケースが多いと思います。したがって、以下のようにSCPのConditionで「StringNotLike」を利用して、IAM Identity Centerで作成されるCCoE用のIAMロールを除外することが考えられます。

{
  "Effect": "Deny",
  "Action": "何らかのIAMアクション",
  "Resource": "*",
  "Condition": {
    "StringNotLike": {
      "aws:PrincipalARN": [
        "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_CCoE*"
      ]
    }
  }
}

細かくIAMアクションを定義したり、除外条件を厳密に定義したりすることで、SCPの内容が複雑になり、文字数が足りないケースも現場ではよく起きていました。今回のアップデートにより、SCPの文字数が10240文字まで利用できるようになったため、よりきめ細やかなSCPを作成することが可能になりました。

3. Control Tower環境でのSCP上限管理

ここまでSCPの数と文字数が増えることのメリットを説明しましたが、AWS Control Towerを利用している環境では、この上限緩和の恩恵がより大きく感じられます。

Control Towerを利用している環境では、Control TowerがOUごとにSCPを自動的にアタッチして予防的コントロール（Preventive Control）を実装しています。これらのSCPはカスタムSCPと同様にOUへのアタッチ数にカウントされるため、旧上限の5では以下のような状況になりやすい環境でした。

Control Towerの必須コントロールだけで1～3枠が占有されるため、任意の予防的コントロールを有効化している場合は、カスタムSCPに残せる枠が1～2枠しかなかったケースも珍しくありませんでした。今回のアップデートで上限が10になったことで、カスタムSCPに余裕を持って枠を確保できるようになりました。

Control Tower管理のSCPは、AWSコンソールのOrganizationsからOUを選択し、「サービスコントロールポリシー」セクションから確認できます。下記の画像のように、Control Towerが管理しているSCPは aws-guardrails- で始まる名前が付けられており、説明欄にも「This policy and the contents implement controls, managed by AWS Control Tower」と表示されるため、カスタムSCPと容易に区別できます。

• 

なお、これらのSCPは直接編集してはいけません。 Control Towerは管理しているSCPを毎日自動スキャンしており、変更が加えられるとガバナンスドリフトとして検出され、通知が送られます。AWSドキュメントでは、管理されているSCPを変更するとコントロールが不明な状態になる可能性があると明記されており、解消にはランディングゾーンのリセットまたはOU再登録が必要になることがあります。予防的コントロールの追加・削除はControl Towerコンソールから行うようにしてください。

OUネストによるSCP枠の工夫

この制約に対して、一部の環境ではWorkloads OU内にさらに子OUをネストすることで、実質的なカスタムSCPの枠を確保するという設計が採用されることもありました。

SCPはOU階層を通じて親OUから子OUへ継承されます。そのため、Workloads OU（親）にアタッチしたSCPは、その配下の子OUにも自動的に適用されます。この仕組みを利用すると、以下のような分割設計が可能です。

• Workloads OU（親）: Control Towerの必須ガードレールSCPと、全メンバーアカウントに共通して適用したいカスタムSCP（組織ガバナンス系・セキュリティ監査系など）をアタッチする

• 子OU: Workloads OUのSCPを継承しつつ、接続形態やセキュリティ要件が異なるOUにのみ必要なSCPを直接アタッチする

子OUではControl Towerの必須SCPが継承されるため、子OUのSCP枠をすべてカスタムSCPに充てることができます。旧上限5の環境でも、この設計を採用することで、親OUと子OUを合わせて実質的に多くのSCPを運用することが可能でした。

なお、Production/Development OUのように環境の違いでOUを分けるケースも多いですが、環境の差だけではSCPとして制御内容が変わりにくく、実態としてフォルダ的な役割に留まることも少なくありません。SCPとして差が生じやすいのは、オンプレミス接続の有無やインターネットアクセスの有無といった接続形態の違いによるケースです。次の章の設計テンプレートではこの点を踏まえた例を紹介します。

今回の上限10への緩和により、「SCPの枠を稼ぐための苦肉の策」としての必要性はやや薄れましたが、「OU単位で役割を分けてSCPを管理する」という設計の考え方は引き続き有効です。

4. SCP分割の推奨設計テンプレート

上限10への緩和と、前述のOUネスト設計の考え方を踏まえた設計テンプレートの一例を示します。共通のSCPをWorkloads OU（親）に集約し、子OUには環境固有のSCPのみを置く構成です。

Workloads OU（親OU）にアタッチするSCP

子OU（オンプレ接続ありOUなど）にアタッチするSCP

Workloads OU（親）にアタッチしたSCPは子OUに継承されるため、子OUには改めてアタッチする必要はありません。この設計により、子OU側のSCP枠を環境固有の制御や将来の要件拡張のために確保しておくことができます。

なお、第2章で説明したCCoE用のIAMロールを除外するConditionは、各SCPに個別に定義する必要があります。 SCPを分割すると定義箇所が増えるため、設定漏れが発生しやすくなります。SCPの管理をTerraformやAWS CDKなどのIaCでコード化しておくと、こうした漏れを防ぎやすくなります。

5. 既存SCPの安全な分割手順

最後に、すでに運用を開始しているControl Tower環境でSCPを分割する際の手順を説明します。SCPのDenyは変更が即座に反映されるため、手順を誤るとアクセス権限に意図しない影響が出る可能性があります。

Step 1: 現状の棚卸し

対象OUにアタッチされているSCPを一覧化し、Control Tower管理のSCPとカスタムSCPを分類します。カスタムSCPについては各Statementの内容を整理し、どのカテゴリに属するかを確認します。

Step 2: 新しいSCPの設計

棚卸し結果をもとに新しいSCPの設計を決定します。各SCPにCCoE用の除外Conditionが含まれているかも設計段階で確認しておきます。

Step 3: 設計レビュー

設計したSCPに漏れなく変更前のStatementが含まれていることを確認します。SCPを分割することでStatementが複数のファイルに分散するため、この確認をIaCのコードレビューとして実施できると効率的です。

Step 4: 新しいSCPの作成（アタッチはしない）

設計に基づき、新しいSCPを作成します。IaCで管理している場合はコードとして作成し、レビューを経てデプロイします。この時点ではOUへのアタッチはまだ行いません。

Step 5: テストOUでの検証

本番OUへの適用前に、テスト用OUを用意してサンドボックスアカウントなどを配置し、新しいSCPをアタッチして動作を確認します。意図したアクションがDenyされること、およびCCoEのIAMロールが正しく除外されていることを確認します。

Step 6: 先行グループへの段階的な適用

テストOUでの検証が完了したら、新しいSCPをアカウントに直接アタッチする形で先行グループへ展開します。この段階ではまだOUへのアタッチは行いません。OUへアタッチすると配下の全アカウントに一括適用されてしまうため、先行適用の段階ではアカウントへの直接アタッチを活用することで影響範囲を絞れます。

• 開発用アカウントから先行する: 本番環境への影響がないアカウントで先に適用し、問題がないかを確認します。
• 協力プロジェクトを先行させる: 事前に調整済みのプロジェクトチームのアカウントから適用を始めると、問題発生時の対応がしやすくなります。

Step 7: OUへの切り替えと古いSCPの削除

先行グループでの確認が取れたら、OUへのアタッチによって残りのアカウントを含む全体への切り替えを行います。

1. 新しいSCPをOUにアタッチする: OU配下の全アカウント（残りのアカウントを含む）に新SCPが適用されます。先行グループのアカウントはアカウント直接アタッチとOUアタッチの両方で新SCPが適用される状態になりますが、同一内容の制御のため、動作上の問題はありません。
2. 古いSCPをOUからデタッチし、削除する。
3. 先行グループのアカウントから新SCPの直接アタッチを外す（クリーンアップ）。

Step 8: 最終確認

全アカウントへの展開が完了したら、各プロジェクトチームが普段の業務で実施している操作が問題なく行えるかを確認します。展開後しばらくは、プロジェクトチームからの問い合わせや障害報告に対応できるよう、CCoE側で窓口を設けておくとよいでしょう。

おわりに

今回はSCPの上限緩和のアップデートについて説明しました。一見地味なアップデートに見えますが、実務上は非常にうれしい内容となっており、このアップデートを心待ちにされていた方も多かったのではないかと思います。本稿がOrganizationsのSCPの管理に悩まれている方の参考になれば幸いです。