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

8 min read読了の目安(約7300字

以前、
サービスコントロールポリシー (SCP)ってなんだろ?
という記事を書いたので、今回は実際に試してみます。

参考手順

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

前提

AWS Organizationsにてマスターアカウントの設定と別アカウントの作成をしてある状態です。

初期状態の確認

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

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

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

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

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

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

OU作成

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

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

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

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

アカウントをOUに移動

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

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

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

ポリシーを定義

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

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

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

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

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

EffectDenyからAllowに書き換えます。
image.png

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

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

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

ちなみにEffectDenyにした時のみ、左下でリソースの追加と条件の追加ができるようです。
image.png

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

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

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

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

ポリシーをOUにアタッチ

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

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

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

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

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

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

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

動作確認

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

まずはEC2のコンソールです。ほぼOKですが、ロードバランサーの項目のみエラーが出ています。どんなエラーか見てみましょう!
image.png

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

ロードバランサーのデータの取得中にエラーが発生しました: 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のサービスで設定が必要だということが分かりました。
image.png

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

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

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

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

まとめ

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