SRE2課 佐竹です。
MFA 強制に引き続き、AWS Organizations のお話です。
はじめに
AWS Organizations の SCP を設計していくうえで「ハマりやすい」ポイント（制限）をまとめました。AWS Organizations の SCP を設計する前にご一読頂けると嬉しく思います。
また、公式ドキュメントのリンクも紹介します。
なお、SCP についての基本用語（エンティティ）などの説明は以下のブログで触れておりますので、合わせてこちらの記事もご確認いただけますと幸いです。
制限（Limits）
1 つのエンティティにアタッチできる SCP の数
最小：1
各エンティティには、最低1つの SCP をアタッチすることが必須です。つまり、SCP を1つも持たない OU や AWSアカウントを作成することはできません。
以下の図のように、SCP が1つもついていないエンティティの存在は許されません。
以下の図のように、全ての OU に SCP が最低1つついていることが必須です。
最後1つの SCP を外そうとした場合、以下のエラーメッセージが出力されます。
You cannot remove the last policy attached to the specified target. You must have at least one attached at all times.
最大：5
各エンティティには、最大5つの SCP をアタッチすることが可能です。この5つの最大値は上限緩和できない制限になります。
以下の図のように、SCP が6つアタッチされたエンティティの存在は許されません。今回は「SCP5」が6つ目のアタッチに相当しています。
もし6つの SCP をアタッチしたい場合は「継承」を利用する対応方法が考えられます。
上位の OU に SCP をアタッチすることで、上図の通り SCP は下位のエンティティに継承されます。今回の図では Layer1 の OU に SCP5 をアタッチすることで、 Layer2 の OU がそれを継承しています。また Layer2 の OU 配下となるエンティティ：AWSアカウント(Account2) は Layer1 OU 及び Layer2 OU それぞれの SCP を全て継承します。
補足ですが「FullAWSAccess」をデタッチすると先に紹介しましたブログの通り「暗黙的なDeny」の問題に抵触する可能性がありますので、「FullAWSAccess」は全てのエンティティにアタッチしておくほうが安全です。
6つ目の SCP をアタッチしようとした場合、以下のエラーメッセージが出力されます。
You have attached the maximum number of policies to the specified target.
OU ネスト数
最大：5
OU は複数の層としてネストすることが可能です。その場合の最大は 5 となっており、ネストできるのは 5階層 までとなります。
以下が最大の階層 = 5階層まで OU をネストした組織です。Root を最上層、 AWSアカウントを最下層として、7層となります。
この上限も緩和不可能な制限となります。
このため、 最下層のAWSアカウントにアタッチできる SCP の最大数は、Root と各 OU からの継承を考えると以下の通りとなります。
- AWSアカウントに直接アタッチできる SCP の最大数：5
- 継承可能な SCP の最大数：30
- 合計：35
マネジメントコンソールでは、Layer5 では「+ New organizational unit」が表示されない制限があるため、以下の画面キャプチャの通りそれ以上 OU が作成できないことがわかります。
SCP JSON の最大サイズ
最大：5120 bytes
公式では「ポリシードキュメント」と記載がありますが、ようはポリシーの JSON として記載できる最大バイト数に制限があり、これが 5,120 バイトまでとなります。
先に記載した通り、各エンティティには SCP を5つまでしかアタッチできません。その場合、取れる対応として上位の OU を利用した SCP の継承をご紹介しました。もう1つの手が「SCPの統合」です。
SCP の統合とは、役割ごとに分離した SCP をまとめて1つのポリシーにしてしまうことです。先ほどもお見せした図を再度以下に貼ります。
この図では、「SCP5」が6つ目にあたるため、アタッチできない状況でした。本対応として「SCP4」と「SCP5」の JSON を統合して、「SCP4+SCP5」という新しい SCP を新規に作ります。
このように、JSON を修正して SCP の役割を統合することも対応方法として検討可能です。
実際問題、以下のように SCP を役割ごとに細分化していくとすぐに SCP の最大数 5 に抵触してしまいます。
- CloudTrail 編集禁止
- Config 編集禁止
- GuardDuty 編集禁止
- IAMへのMFA強制
- RI/SP購入禁止
この場合、CloudTrail 、Config、GuardDutyの編集禁止権限を1つの SCP に統合すれば、数を2つ減らすことができます。
SCP の統合時に注意する必要があるのが SCP JSON の最大サイズが 5,120バイトまでという制約です。5,120バイトあればある程度長いポリシー JSON が記載可能ですので抵触することは稀かと存じますが、SCP を統合し続けると抵触してしまう可能性があるため念のためご注意ください。
Management Account は SCP で制限されない
以下の通り、Management Account（元 Master Account：管理アカウント）は SCP の制限を受けません。
SCP は、管理アカウントのユーザーやロールには影響しません。組織内のメンバーアカウントにのみ影響します。
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html
そのため、Management Account の権限を制限されたい場合は、IAM ポリシーにて制限頂く必要があります。
まとめ
本ブログでは AWS Organizations の SCP で 設計時に気を付けるべきポイントとして以下の制限を紹介しました。
- 1 つのエンティティにアタッチできる SCP の最小数：1
- 1 つのエンティティにアタッチできる SCP の最大数：5
- OU の最大ネスト数：5
- SCP JSON の最大サイズ：5,120バイト
- Management Account は SCP で制限されない
また、「1 つのエンティティにアタッチできる SCP の最大数：5」に抵触した場合の対応方法として「OU をネストして継承を利用する方法」と「SCP の統合を利用する方法」をそれぞれ注意点と共に紹介しました。SCP の設計においては、これらに注意しつつ設計ください。
ではまたブログでお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
