📝

サービスコントロールポリシー (SCP) の継承を試してみた

2021/04/24に公開

以前 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

ログインするとコメントできます