スイッチロールを試してみたい、実際の権限分離動作を見てみたいという衝動に駆られたのでAWS Organizationsを用いて簡単に試してみました。なお、この辺は最上位権限で操作をする必要があるため、もし試す方がいらっしゃいましたら注意して操作してください。
登場人物
IAM
IAM(Identity and Access Management: アイアム)とは、AWS上のリソースへのアクセスを制御するためのサービスです。IAMがあることで、AWSを利用するユーザーやAWSのサービスへ役割に応じた権限を個別に付与できるようになります。
(AWS Identity and Access Management)
スイッチロール
スイッチロールは複数のアカウントで作業する際にアカウントの切り替えを楽にする機能です。
一般的に開発環境(開発、ステージング、本番)ごとにAWSアカウントを作成して開発を行うのが一般的です。これは環境をアカウントで分離することにより意図しない干渉を用意に防ぐためです。スイッチロール機能がないとログインする環境を変更したい場合に毎回、ログイン・ログアウトが必要になってしまったり、複数のIAMユーザーを管理する必要があるため、効率面や安全面で問題があります。そこでスイッチロールを使用することで、1つのAWSアカウントにログインしていれば、そこを起点に各AWSアカウントへログインできるため、先の問題を解決できます。
AWS Organizations
AWS Organizationsは複数のAWSアカウントをまとめて管理できるサービスです。主には請求をまとめたり、アカウントを跨いでのサービスコントロールポリシー(SCP)で権限管理を行うなどガバナンスを効かせたりするために利用できます。
AWS Organizationsでは組織という単位を作成してその中でアカウントを持ちます。
スイッチング先アカウントの作成とログイン
ここで、今回、AWS OrganizationsからAWSアカウントを新規作成したのは、通常のアカウント作成に比べて以下のメリットがあるためです。
- 作成手順が少ない
- IAM Roleが同時作成される
- 組織に所属した状態で作成できる
実運用でもAWS Organizationsを使用できる環境もしくは予定があれば、利用することをおススメします。
では、スイッチング先アカウントの作成を行っていきます。
手順1. 管理用AWSアカウントにてAWS Organizationsからアカウントの追加
Administrator権限を持つIAMユーザーもしくはルートユーザーでAWS Organizationsを開きます。なお、すでにAWS Organizationsで組織が作成されている前提です。
アカウントの追加をクリックし、アカウントの作成を選択し、下記のように必要な項目を入力します。IAMロール名は任意の名前を指定できます。デフォルトではOrganizationAccountAccessRole
という名前で作成されます。作成されるIAMロールのIAMポリシーはAdministratorAccess
です。
作成を実行すると、Organaizationsのホーム画面に新たなアカウントが追加されます。作成されたアカウントからアカウントIDを控えておきます。
手順2. スイッチングロールで新規AWSアカウントにアクセス
1で作成したAWSアカウントにアクセスするために、右上のアカウントから「ロールの切り替え」を選択します。
先ほど控えたアカウントIDと作成したIAMロール(設定していない場合はOrganizationAccountAccessRole
)入力します。表示名と色は任意で決めてください。
ロール切り替えをクリックするとスイッチロールされ、AWSアカウントが切り替わります。
手順3. Developer用のIAMロールを作成
今あるIAMロールは管理者権限しかないため、権限を弱めたIAMロールを作成します。
ここではAWSマネジメントポリシーPowerUserAccess
をアタッチしたSwitchRole-developerというIAMロールを作成します。
スイッチング元管理アカウントによるアクセス制御設定
スイッチング元である管理用アカウントにて、IAMユーザーに応じてアクセス可能なIAMロールを制限する設定を行います。 ここでは、IAMポリシーの作成をクリックし、CustomPolicy-Allow-SwithRole-DevelopRolesという名前のポリシーを作成します。ポリシードキュメントは以下のポリシー例1を採用します。
- ポリシー例1
特定のIAMロールのみアクセス許可したい場合の設定です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<AccountID Switching>:role/SwitchRole-Developer",
}
}
]
}
- ポリシー例2
特定のタグを持つすべてのIAMロールへのアクセスを許可したい場合の設定です。例えば、開発環境のIAMロールすべてにアクセスさせたい場合などに一括で許可することができます。 設定は楽になりますが、ややセキュリティーが不安です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::*:role/*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/env": "dev"
}
}
}
]
}
作成したIAMポリシーをIAMグループにアタッチします。ここではMaintainer
というグループを作成し、アタッチしました。
次にIAMユーザーdeveloper
を作成し、Maintainerグループをアタッチします。
developerのIAMユーザーでログインします。
2章-手順2にて実施した要領でスイッチングロールを行います。IAMロール名はdeveloper用のSwitchRole-Developer
を入力します。なお、当たり前ですが、これ以外のIAMロールを入力した場合はアクセスできません。
developer用のIAMロールでスイッチできました。当然ながらIAMロールにアタッチしたポリシーが許可していないリソースにはアクセスできません。
まとめ
スイッチロールを試してみました。AWS Organizationsを利用すれば、思っていたより簡単に設定ができるとわかりました。 使用するアカウント数が増加すると手動による管理が難しそうであるため、IaCの利用が必須だと感じました。
参考
未解決事項 雑記
- AdministratorAccess権限を持つIAMユーザーから請求系サービスにはアクセスできないが、スイッチロールでAdministratorAccess権限を持つIAMロールではアクセスすることができるのはなぜか?両方ともIAMポリシーは同じなのに…
- スイッチングロールにおいて、IAMロール作成権限をDeveloperに付与してしまうと、セキュリティー上大きな問題になるのではないか?
- Developerが管理者権限のIAMロールを作成できてしまい、安全性担保が難しくなるのでは?