AWS Organizations の SCP で 設計時に気を付けるべきポイント

記事タイトルとURLをコピーする

SRE2課 佐竹です。
MFA 強制に引き続き、AWS Organizations のお話です。

はじめに

AWS Organizations の SCP を設計していくうえで「ハマりやすい」ポイント(制限)をまとめました。AWS Organizations の SCP を設計する前にご一読頂けると嬉しく思います。

また、公式ドキュメントのリンクも紹介します。

docs.aws.amazon.com

なお、SCP についての基本用語(エンティティ)などの説明は以下のブログで触れておりますので、合わせてこちらの記事もご確認いただけますと幸いです。

blog.serverworks.co.jp

制限(Limits)

1 つのエンティティにアタッチできる SCP の数

最小:1

各エンティティには、最低1つの SCP をアタッチすることが必須です。つまり、SCP を1つも持たない OU や AWSアカウントを作成することはできません。

以下の図のように、SCP が1つもついていないエンティティの存在は許されません。

f:id:swx-satake:20200901114757p:plain

以下の図のように、全ての OU に SCP が最低1つついていることが必須です。

f:id:swx-satake:20200901114454p:plain

最後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つ目のアタッチに相当しています。

f:id:swx-satake:20200901115903p:plain

もし6つの SCP をアタッチしたい場合は「継承」を利用する対応方法が考えられます。

f:id:swx-satake:20200901144622p:plain

上位の 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.

f:id:swx-satake:20200901121613p:plain

OU ネスト数

最大:5

OU は複数の層としてネストすることが可能です。その場合の最大は 5 となっており、ネストできるのは 5階層 までとなります。

以下が最大の階層 = 5階層まで OU をネストした組織です。Root を最上層、 AWSアカウントを最下層として、7層となります。

f:id:swx-satake:20200901122614p:plain

この上限も緩和不可能な制限となります。
このため、 最下層のAWSアカウントにアタッチできる SCP の最大数は、Root と各 OU からの継承を考えると以下の通りとなります。

  • AWSアカウントに直接アタッチできる SCP の最大数:5
  • 継承可能な SCP の最大数:30
  • 合計:35

マネジメントコンソールでは、Layer5 では「+ New organizational unit」が表示されない制限があるため、以下の画面キャプチャの通りそれ以上 OU が作成できないことがわかります。

f:id:swx-satake:20200901122807p:plain

SCP JSON の最大サイズ

最大:5120 bytes

公式では「ポリシードキュメント」と記載がありますが、ようはポリシーの JSON として記載できる最大バイト数に制限があり、これが 5,120 バイトまでとなります。

先に記載した通り、各エンティティには SCP を5つまでしかアタッチできません。その場合、取れる対応として上位の OU を利用した SCP の継承をご紹介しました。もう1つの手が「SCPの統合」です。

SCP の統合とは、役割ごとに分離した SCP をまとめて1つのポリシーにしてしまうことです。先ほどもお見せした図を再度以下に貼ります。

f:id:swx-satake:20200901115903p:plain

この図では、「SCP5」が6つ目にあたるため、アタッチできない状況でした。本対応として「SCP4」と「SCP5」の JSON を統合して、「SCP4+SCP5」という新しい SCP を新規に作ります。

f:id:swx-satake:20200901125430p:plain

このように、JSON を修正して SCP の役割を統合することも対応方法として検討可能です。

実際問題、以下のように SCP を役割ごとに細分化していくとすぐに SCP の最大数 5 に抵触してしまいます。

  1. CloudTrail 編集禁止
  2. Config 編集禁止
  3. GuardDuty 編集禁止
  4. IAMへのMFA強制
  5. RI/SP購入禁止

この場合、CloudTrail 、Config、GuardDutyの編集禁止権限を1つの SCP に統合すれば、数を2つ減らすことができます。

SCP の統合時に注意する必要があるのが SCP JSON の最大サイズが 5,120バイトまでという制約です。5,120バイトあればある程度長いポリシー JSON が記載可能ですので抵触することは稀かと存じますが、SCP を統合し続けると抵触してしまう可能性があるため念のためご注意ください。

まとめ

f:id:swx-satake:20200818185726p:plain:w200

本ブログでは AWS Organizations の SCP で 設計時に気を付けるべきポイントとして以下の制限を紹介しました。

  1. 1 つのエンティティにアタッチできる SCP の最小数:1
  2. 1 つのエンティティにアタッチできる SCP の最大数:5
  3. OU の最大ネスト数:5
  4. SCP JSON の最大サイズ:5,120バイト

また、「1 つのエンティティにアタッチできる SCP の最大数:5」に抵触した場合の対応方法として「OU をネストして継承を利用する方法」と「SCP の統合を利用する方法」をそれぞれ注意点と共に紹介しました。SCP の設計においては、これらに注意しつつ設計ください。

ではまたブログでお会いしましょう。

佐竹 陽一 (Yoichi Satake) 記事一覧はコチラ

SRE2課所属。AWS資格12冠。2010年1月からAWSを利用してきました。
AWSのコスト削減、最適化を得意としています。