【AWS Organization】SCPで別AWSアカウントの権限を管理してみる

もくじ

はじめに

AWSでAWS Organizarionsを使用して2つのAWSアカウントを管理し、SCPを使用してポリシーの管理をやってみたいと思います。

SCPを使用すれば、AWSアカウント内のIAMポリシーIAMロール上書きして権限の付与ができます。

たとえば、AWSアカウントの中で「AdministratorAccess」が付与されているユーザーであろうと、SCPでEC2だけの権限を付与すれば、EC2しか操作できなくなります。

SCPとは

SCPとはService Control Policyの略で、AWS Organizationを使って組織単位やアカウント単位でポリシーを付与する(管理する)ことができる仕組みです。

例えば以下の図の例ですと、OU1に所属するAWSアカウント1はEC2の操作のみできます。

OU2に所属するAWSアカウント2はS3のみ実行できません。

SCPでは上位で許可されたポリシーが下位に継承され、上位で許可されなかったポリシーは、下位で許可することができません

たとえば、AWSアカウント1では、EC2とRDS以外の権限を付与することができません。(OU1でEC2とRDSのみ許可しているため)

設定投入

AWS Organizarionsの状態

「AtsushiAWS」、「AtsushiAWS1」、「AtsushiAWS2」の3つのアカウントを使って、AWS Organizationsを構成してみました。

SCPの検証は、「AtsushiAWS1」と「AtsushiAWS2」で行います。なぜなら、「AtsushiAWS」アカウントは管理アカウントとなっており、SCPの影響を受けないからです。(サービスコントロールポリシー (SCPs)

構成図を書いてみると、以下のようになります。

付与するSCP構成

今回は以下のようにしてみたいと思います。

  • OU1:実行不可→S3(すべて不可)
  • AtsushiAWS1:特に指定しない。
  • OU2:実行可能→EC2とRDS(すべてFullAccess)
  • AtsushiAWS2:実行可能→EC2(FullAccess)

想定される動作は、以下になるはずです。

  • AtsushiAWS1:S3以外のことが実行できる。
  • AtsushiAWS2:EC2のみ実行できる(FullAccess)

OU1のSCP作成

「AWS Organizations」→「ポリシー」→「サービスコントロールポリシー」→「ポリシーの作成」からSCPを作成します。

以下のように作成しました。

コードは下記です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

「ターゲット」から「OU1」アタッチしました。

OU2のSCP作成

ポリシーのJSONコードのみ記載します。作成後は「OU2」にアタッチしました。

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

AtsushiAWS2のSCP作成

JSONコードのみ記載します。作成後は「AtsushiAWS2」アカウントにアタッチしました。

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

補足(OUから直接アタッチされたポリシーを削除)

もしOUに対して、直接アタッチされたポリシー(FullAWSAccessなど)があった場合は削除します。

動作確認

AtsushiAWS1の動作確認

想定される動作は「S3のみ操作できない」です。

AdministratorAccess権限があるユーザーでログインします。

S3コンソールを開いてみると、「バケットを一覧表示するアクセス許可がありません」と表示され、S3での操作ができないことがわかります。

たとえIAMユーザーがAdministratorAccessなど強い権限を持っていても、SCPで権限が制御されていることがわかります。

S3以外(ここではIAMのコンソール)を開いてみると、特にエラーは表示されず操作可能であることがわかります。

AtsushiAWS2の動作確認

こちらもAdministratorAccessがあるユーザーでログインしました。

RDSコンソールにアクセスしてみると、権限がないためエラーが発生します。

EC2コンソールにアクセスすると、参照できています。(インスタンスの作成もできます)

アラームの箇所でエラーになっているのは、CloudWatchの権限が無いからです。

他にもLambdaにアクセスしてみましたが、EC2の権限しかないため参照すらできません。

最後に

このように、AWS OrganizationsのSCPを使用すると、IAMユーザーの権限を上書きしてコントロールすることができます。

これならば、複数の組織(AWSアカウント)を運用する場合において、各ユーザー(各組織)に対して権限のコントロールが簡単になりますね。

各AWSアカウントの中でポリシーやロールで管理することなく、ひとつの管理アカウントから複数のAWSアカウントの権限の管理できるので、わかりやすくなります。

IAMポリシーとIAMロールに加えて、AWS OrganizationsのSCPも使っていきたいですね。

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!

コメント

コメントする

コメントは日本語で入力してください。(スパム対策)

CAPTCHA

もくじ
閉じる