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

以前 SCP について調べてみたので今回は実際に試してみたいと思います。
サービスコントロールポリシー (SCP) とは

以下のブログの手順を参考にして設定してみます。
AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する | DevelopersIO

前提

AWS Organizations にてマスターアカウントと子アカウントを作成してある状態から始めます。

初期状態の確認

まずはマスターアカウントの IAM ユーザーで AWS Organizations のコンソールに移動します。

SCP が有効になっているかを確認するため「ポリシー」をクリックします。

既に有効になっていることが確認できました。

有効になっていない場合は「サービスコントロールポリシー」をクリックすると以下のような画面が表示されますので、右上のボタンで有効にしましょう。

アカウント一覧に戻って Root の権限を確認します。
「Root」をクリックします。
まだ OU を作成していませんがこの後作成します。

「ポリシー」のタブを開くとデフォルトで FullAWSAccess の権限が付与されていることが確認できます。

OU 作成

アカウント一覧から「Root」を選択し、「アクション」から「組織単位」以下の「新規作成」をクリックします。

組織単位名を入力し、右下の「組織単位の作成」をクリックします。

Root 配下に作成した OU が追加されたことが確認できます。

「ポリシー」タブを開くと FullAWSAccess が付与されています。
これは Root 配下に作成したことで Root の権限が継承されている状態です。

アカウントを OU に移動

移動するアカウントを選択し、「アクション」から「AWS アカウント」以下の「移動」をクリックします。

作成した OU を選択し、右下の「AWS アカウントを移動」をクリックします。

組織構造を見ると TestOU の中にアカウントが移動したことが確認できます。

ポリシーを定義

サイドバーから「ポリシー」をクリックします。

「サービスコントロールポリシー」をクリックします。

「ポリシーを作成」をクリックします。

ポリシー名と説明を入力します。

デフォルトでは以下のように 1 つのステートメントが Deny で記述されています。
左側からサービスとアクションを選択することができますのでこちらを使用して設定していきます。

Effect を Deny から Allow に書き換えます。

権限は EC2 のすべてのアクセス権限を選択しました。
選択すると右側の Action の中に自動的に追記されていきます。

続いて CloudWatch のすべてのアクセス権限を選択しました。

今回はリソースも全てで良いので Resource に * を指定しました。

ちなみに Effect を Deny にした時のみ左下でリソースの追加と条件の追加ができるようです。

今回はこれでいいので右下の「ポリシーの作成」をクリックします。

作成したポリシーは参考リンクと同じですが、一応以下に記載しておきます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*"
            ],
            "Resource": "*"
        }
    ]
}

ポリシーが作成されたことが確認できます。

ポリシーを OU にアタッチ

ポリシーを選択し、「アクション」から「ポリシーのアタッチ」をクリックします。

OU を選択し、「ポリシーのアタッチ」をクリックします。

OU の詳細画面でポリシータブを開くとポリシーがアタッチされたことが確認できます。

ただし、この状態では継承された FullAWSAccess ポリシーによってすべてのサービスにアクセスできる状態のため、FullAWSAccess はデタッチします。
なお、OU には 1 つ以上のポリシーがアタッチされている必要があるため、FullAWSAccess を先に外してから作成したポリシーをアタッチするということはできませんのでご注意ください。

FullAWSAccess を選択し、「デタッチ」をクリックします。

確認画面が表示されるので「ポリシーのデタッチ」をクリックします。

これで TestOU にアタッチされたポリシーは作成したポリシーだけになり、EC2 と CloudWatch にしかアクセスできなくなったはずです。

動作確認

では実際に OU に所属させたアカウントの IAM ユーザーで各サービスにアクセスしてみます。

まずは EC2 のコンソールです。

ほぼ OK ですがロードバランサーの項目のみエラーが出ています。

ロードバランサーのコンソールで以下のようなエラーが発生していました。

ロードバランサーのデータの取得中にエラーが発生しました: User: arn:aws:sts::<Account ID>:assumed-role/<role name>/<IAM user name> is not authorized to perform: elasticloadbalancing:DescribeLoadBalancers with an explicit deny

ロードバランサー関連のアクセス権限がないようです。
改めて Organizaions のポリシー設定画面で見てみると、ロードバランサーへのアクセス権限は EC2 Auto Scaling のサービスで設定が必要だということが分かりました。

続いて CloudWatch のコンソールを見てみます。
アラームを作成していないので何も表示されていませんが、エラーは出ていないので大丈夫そうです。

ちなみにロググループではエラーが発生しました。
ロググループは CloudWatch Logs の機能なので、CloudWatch Logs へのアクセス権を設定しないとアクセスできません。

続いて S3 のコンソールです。
日本語でアクセス許可がないと表示されましたので期待通りです。

EC2 と CloudWatch へのアクセスはできて他のサービスへのアクセスは拒否されることが確認できました。
試しにルートユーザーでもアクセスしてみましたが結果は同じでした。

まとめ

今回は SCP を実際に試してみました。
コンソールでサービスとアクションを選択するだけで簡単に設定できたので、思ったよりスムーズに設定できました。また、同じサービスのコンソールに分類されていてもアクセス権限は分かれているということも分かりました。
SCP もうまく使って安全な AWS の利用を心がけたいですね。
今回の内容がどなたかの参考になれば幸いです。

参考資料

• サービスコントロールポリシー (SCP) とは
• AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する | DevelopersIO