はじめに
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も使っていきたいですね。
コメント