サービスコントロールポリシー (SCP) の継承を試してみた
以前 SCP について調べたうえで実際に試してみました。
SCP には「継承」の仕組みもあるため、以下のブログを参考に今回は継承を試してみます。
[AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO
継承におけるポイントは以下の通りです。
- 「暗黙の Deny」を把握する
- SCP 継承は「フィルター」である
前提
- AWS Organizations でマスターアカウントと子アカウントは作成済み
- Root - TestOU - TestOUChild - 子アカウントの OU 構成を作成済み
ポリシーの作成
今回は以下のようにポリシーをアタッチします。
- TestOU: IAM への Deny
- TestOUChild: EC2への Deny
まずは IAM と EC2 の拒否用ポリシーを作成します。
AWS Organizations コンソールの左側から「ポリシー」をクリックします。
「サービスコントロールポリシー」をクリックします。
「ポリシーを作成」をクリックします。
ポリシー名と説明を入力します。
サービスから IAM を選択します。
All actions を選択し、IAM のすべてのアクションを拒否します。
「2.リソースを追加する」をクリックします。
AWS サービスは IAM、Resource type は All Resources を選択し、「リソースの追加」をクリックします。
右下の「ポリシーの作成」をクリックします。
このようなポリシーが作成されました。
続けて EC2 の拒否用ポリシーも作成しますが、ポリシー名、説明、サービスの選択部分以外は同じ手順なのでできあがったポリシーだけご覧ください。
ポリシーのアタッチ
作成したポリシーを各 OU にアタッチします。
まずは IAM 拒否用のポリシーを親 OU にアタッチするため、「アクション」から「ポリシーのアタッチ」をクリックします。
親 OU である TestOU を選択し、「ポリシーのアタッチ」をクリックします。
同様の手順で EC2 拒否用のポリシーを子 OU にアタッチします。
これで各 OU にポリシーがアタッチされました。
各 OU のポリシー状況は以下の通りです。
動作確認
今回は TestOUChild に存在するアカウントの IAM ユーザーで試してみます。
まずは IAM コンソールですが、想定通りアクセスが拒否されています。
続いて EC2 コンソールですがこちらも拒否されています。
ロードバランサーのみエラーが出ないのは、ロードバランサー関連のアクセス権限が EC2 のサービス単位ではなく Auto Scaling のサービス単位だからです。
ここからわかる通り、親 OU と子 OU にアタッチしたポリシーにより IAM と EC2 は明示的な拒否となり、ロードバランサーなどのその他のサービスについてはフィルターで除外されていないのでフルアクセスが可能となっています。
許可フィルターによって IAM と EC2 だけ拒否されています。
許可リスト形式のアクセス権限
今度は許可リスト形式で明示的な許可を与えてみます。
細かいコンソールでの設定方法は大体先ほどと同じなので、各 OU のアクセス権限だけご覧ください。
親 OU
親 OU には S3、Lambda、IAM のすべてのリソースへのアクセスを許可し、デフォルトの AWSFullAccess はデタッチしました。
子 OU
子 OU には S3 と Lambda のすべてのリソースへのアクセスを許可し、デフォルトの AWSFullAccess はデタッチしました。
動作確認
S3 と Lambda にはアクセスできて、IAM とその他サービスでは拒否されれば OK です。
S3
Lambda
IAM
EC2
明示的に許可したサービスのうち、親でも子でも許可された S3 と Lambda 以外は暗黙の Deny によって拒否されることが確認できました。
まとめ
今回は SCP の継承について試してみました。
「暗黙の Deny」と「フィルター」が実際に設定してみてよくわかりました。
これらを理解できるとブログでも紹介されている「ダメな例」も理解できると思いますので、そちらもぜひご覧ください。
どなたかの参考になれば幸いです。
Discussion