AWS OrganizationsのSCPでresourceやconditionが指定できるようになりさらに便利になりました

AWS Organizationsに待望のアップデートがありました!SCPでresourceやconditionの指定が可能となり、柔軟によりきめ細やかなアクセス制御が可能となりました。
2019.04.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。サービスグループの武田です。

AWS Organizationsに待望のアップデートがありました!AWS OrganizationsにはSCP(サービスコントロールポリシー)という機能があり、IAMポリシーと同じ文法で組織内のアカウントに対して一括で制限がかけられます。これまでSCPではresourceやconditionの指定ができず、ある操作に対してオンかオフすることしかできませんでした。今回のアップデートでそれが可能となり、柔軟によりきめ細やかなアクセス制御が可能となりました。

Service control policies in AWS Organizations enable fine-grained permission controls

具体的には、メンバーアカウントに対してSCPで次のような制御が可能となりました。

  • 特定リージョンのみアクセスを許可する
  • EC2やRDSで特定インスタンスタイプのみ起動を許可する
  • CloudTrailやAWS Configの設定変更を禁止する
  • etc

今回、マスターアカウントとメンバーアカウントを用意して、IAMロールの削除制御を検証してみました。

今回のゴール

次の2点を今回のゴールとして進めます。これが実現できると、組織内で必須のロールをメンバーアカウントが間違って消してしまうといった事故を防ぐことができます。

  • メンバーアカウントにnot-delete-roleロールを作成し、このIAMロールの削除をSCPで制限する
  • ただしroleadmin-roleロールにスイッチした場合は削除ができる

登場人物の整理

今回の検証では3個のAWSアカウントおよび3個のIAMロールが登場します。それぞれの役割を整理しておきます。

  • Master
    • 組織のマスターアカウント
  • Member1
    • メンバーアカウントその1
    • roleadmin-role
      • 管理者ロール。ロールを消せる
    • user-role
      • 一般ロール。ロールを消せない
    • not-delete-role
      • 検証で削除されるロール
  • Member2
    • メンバーアカウントその2。Member1アカウントのロールにスイッチできる

やってみた

前提

次のリソースはすでに作成済みとして進めます。実際にご自身の環境で試す際には注意してください。

  • Masterアカウントおよび作業用IAMロール
  • Member1アカウントおよび作業用IAMロール
  • Member2アカウントおよび作業用IAMユーザー

また組織のルートには次のFullAWSAccessポリシーがアタッチされています。

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

Member1アカウントにロールを作成

まずはMember1アカウントに次の3個のIAMロールを作成します。検証用なのでポリシーはAdministratorAccessをアタッチします。

  • roleadmin-role
  • user-role
  • not-delete-role

Masterアカウントでポリシーを作成しMember1アカウントにアタッチ

続いてMasterアカウントでSCPの作成などを行います。AWS Organizationsの画面で次のポリシーを作成します。

DenyAccessWithException

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "DenyAccessWithException",
			"Effect": "Deny",
			"Action": [
				"iam:AttachRolePolicy",
				"iam:DeleteRole",
				"iam:DeleteRolePermissionsBoundary",
				"iam:DeleteRolePolicy",
				"iam:DetachRolePolicy",
				"iam:PutRolePermissionsBoundary",
				"iam:PutRolePolicy",
				"iam:UpdateAssumeRolePolicy",
				"iam:UpdateRole",
				"iam:UpdateRoleDescription"
			],
			"Resource": [
				"arn:aws:iam::*:role/not-delete-role"
			],
			"Condition": {
				"StringNotLike": {
					"aws:PrincipalARN": "arn:aws:iam::*:role/roleadmin-role"
				}
			}
		}
	]
}

参考までに、今回作成したポリシーはドキュメントのExampleに掲載されています。ほかにも例が載っていますので目を通しておくと良さそうです。

Example Service Control Policies - AWS Organizations

作成したポリシーはそのままでは意味がありません。本番運用ではOUにアタッチしますが、今回は検証ですのでMember1アカウントに直接アタッチします。

Member2からスイッチしてSCPが適用されているかの確認

それでは作成したポリシーが適用されているか確認してみましょう。Member2からMember1のuser-roleにスイッチします。

IAMロールの画面からnot-delete-roleロールの削除を試します。

削除できません!

一度Member2に戻り、続けてMember1のroleadmin-roleにスイッチします。

先ほどと同様にIAMロールの画面からロール削除を試してみると、今度は削除できました!

まとめ

AWS OrganizationsのSCPを利用することで、組織内の複数アカウントに対して共通のポリシーを適用できます。resourceやconditionが指定可能となり、利用の幅が広がりましたね!便利に使っていきましょう!