3月よりIE課（インターナルエデュケーション課） に異動しました山﨑です。
今回はAWS Organizations における「アクセス統制」について整理してみます
AWS Organizations におけるアクセス統制
AWS Organizations のおさらい
AWS Organizations とは要約すると、ユーザーが管理する「組織」と呼ばれる管理単位に1つ以上のAWSアカウントを統合することで、複数のAWSアカウントを効率的に一元管理することができるアカウント管理サービスです。一元管理をする上で、組織の長となるAWSアカウントを「Management Account」と呼び、その他のAWSアカウントを「Member Account」と呼びます。
詳細については以下のブログをご覧ください
アクセス統制について
単一のAWSアカウントを利用する際は該当のAWSアカウント上でIAMユーザー（認証情報）を作成し、そのIAMユーザーにIAMポリシーを割り当てる（認可）ことでアクセスを管理、統制します。
本ブログではAWS Organizations 配下の各AWSアカウントを利用する際の認証認可を一元管理することをアクセス統制と呼称し、アクセス統制を実現するための2つの手段について整理します。
①IAM方式
IAM方式は専用のAWSアカウント（IAM管理アカウント）を作成し、IAM管理アカウントから各種AWSアカウントへスイッチロールを行う方法です。各AWSアカウントで実施する作業は以下の通りです。
IAM管理アカウント
IAM管理アカウントでは、IAMエンティティとしてIAMユーザー、IAMグループ、IAMポリシーを作成します。
| IAMエンティティ | 概要 |
|---|---|
| IAMユーザー | 各種AWSアカウントへスイッチロールを行うユーザーを作成 |
| IAMグループ | ユーザーをグループ管理 |
| IAMポリシー | 以下2つのIAMポリシーを作成 ①セキュリティを向上させるためにMFAを強制するIAMポリシー ②スイッチロールを許可するIAMポリシー |
MFAを強制するポリシー
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowViewAccountInfo", "Effect": "Allow", "Action": [ "iam:GetAccountPasswordPolicy", "iam:ListVirtualMFADevices" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswords", "Effect": "Allow", "Action": [ "iam:ChangePassword", "iam:GetUser" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnAccessKeys", "Effect": "Allow", "Action": [ "iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:ListAccessKeys", "iam:UpdateAccessKey" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSigningCertificates", "Effect": "Allow", "Action": [ "iam:DeleteSigningCertificate", "iam:ListSigningCertificates", "iam:UpdateSigningCertificate", "iam:UploadSigningCertificate" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSSHPublicKeys", "Effect": "Allow", "Action": [ "iam:DeleteSSHPublicKey", "iam:GetSSHPublicKey", "iam:ListSSHPublicKeys", "iam:UpdateSSHPublicKey", "iam:UploadSSHPublicKey" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnGitCredentials", "Effect": "Allow", "Action": [ "iam:CreateServiceSpecificCredential", "iam:DeleteServiceSpecificCredential", "iam:ListServiceSpecificCredentials", "iam:ResetServiceSpecificCredential", "iam:UpdateServiceSpecificCredential" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnVirtualMFADevice", "Effect": "Allow", "Action": [ "iam:CreateVirtualMFADevice", "iam:DeleteVirtualMFADevice" ], "Resource": "arn:aws:iam::*:mfa/*" }, { "Sid": "AllowManageOwnUserMFA", "Effect": "Allow", "Action": [ "iam:DeactivateMFADevice", "iam:EnableMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] }
スイッチロールを許可するポリシー
このIAMポリシーで「スイッチロールを許可するAWSアカウント」と「スイッチロール先のAWSアカウントで引き受ける権限（IAMロール）」を制御します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::<スイッチロール先のAWSアカウントID>:role/<引き受けるIAMロール名>", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "true" } } } ] }
各種AWSアカウント
各AWSアカウントではユーザーに引き受けを許可する権限を定義したIAMロールを作成します。
IAMロールの例
| IAMロール | 概要 |
|---|---|
| AdminRole | AdministratorAccess権限（管理者権限）を付与 |
| ReadOnlyRole | ReadOnlyAccess権限（読み込み権限）を付与 |
| MaintenanceRole | 各AWSアカウントの運用に必要な権限を付与 |
各AWSアカウントで共通して作成するIAMロールと権限が決まっているのであれば、CloudFormation StackSets を利用することで一括デプロイすることも可能です。CloudFormation StackSets であれば自動デプロイ設定ができるため、新規AWSアカウントが発行された場合でも自動デプロイが可能です。
運用イメージ
IAM管理アカウント
IAM管理アカウントでは、「ユーザーにスイッチロールを許可するAWSアカウント」と「スイッチロール先のAWSアカウントでユーザーに引き受けを許可するIAMロール」に応じてIAMポリシーを作成し、必要に応じてアタッチ・デタッチすることでアクセス統制を行う運用が考えられます。
各種AWSアカウントでスイッチロール用のIAMロールが追加/削除されれば、それに応じてIAM管理アカウントでもIAMポリシーを作成/削除する必要が出てきます。
| # | Policy Name | 役割 | メモ |
|---|---|---|---|
| 1 | Switch-HRPrd-AdminPolicy | HR System OU 配下の本番アカウントにAdmin権限でスイッチロールをすることを許可 | 初期構築時以外は基本的に利用しない |
| 2 | Switch-HRPrd-ROPolicy | HR System OU 配下の本番アカウントにRO権限でスイッチロールをすることを許可 | AWS環境の閲覧用途に利用 |
| 3 | Switch-HRPrd-MUPolicy | HR System OU 配下の本番アカウントにMaintenance権限でスイッチロールをすることを許可 | 環境構築後のメンテナンス時に利用 |
各種AWSアカウント
各種AWSアカウントで考えられる運用としては「IAMロールのメンテナンス」「IAMロールの作成/削除」が考えられます。
「IAMロールのメンテナンス」に関しては、例えば新しいAWSサービスの利用を開始し運用保守を行う必要が出た場合、IAMロール（MaintenanceRole）に割り当てているIAMポリシーに対して新しいAWSサービスの操作権限を追加する、といった具合です。
「IAMロールの作成/削除」に関しては、先述した3つのIAMロール以外の用途でIAMロールが必要または不必要になった場合はにIAMロールの作成/削除を行う、といった具合です。
②SSO方式
SSO方式は専用のAWSアカウント（SSOアカウント）を作成し、SSOアカウントのIAM Identity Center で発行されたアクセスポータルサイトからシングルサインオンで各種AWSアカウントへスイッチロールを行う方法です。各AWSアカウントで実施する作業は以下の通りです。
Management Account
Management Accountでは、SSOアカウントに対してIAM Identity Center の統合と委任を有効化します。
aws organizations enable-aws-service-access --service-principal sso.amazonaws.com aws organizations register-delegated-administrator --account-id <SSOアカウントのアカウントID> --service-principal sso.amazonaws.com
SSOアカウント
SSOアカウントでは、IAM Identity Center を有効化して各種コンポーネントを作成し、アクセス先のAWSアカウントにそれらを関連付けます。より詳細について知りたい方は以下のブログも合わせてご覧ください
【AWS SSO】アクセス権の仕組みについて - サーバーワークスエンジニアブログ
【AWS SSO】アクセス権の設定方法 - サーバーワークスエンジニアブログ
| IAMエンティティ | 概要 |
|---|---|
| SSOユーザー | SSOにログインするための個々のユーザー IDソースは「IAM Identity Center Directory」「Active Directory」「外部IDプロバイダー」のいずれかから選択可能 ID ソースを管理する - AWS IAM Identity Center (successor to AWS Single Sign-On) |
| SSOグループ | SSOユーザーをグループ管理 |
| アクセス許可セット | AWSのリソースに対するアクセス許可の集合。SSOユーザーまたはSSOグループに割り当てることで権限を定義 |
関連付けが完了すると、関連付けたAWSアカウント上に「AWSReservedSSO_{関連付けたアクセス許可セット名}_xxxxxxxxxx」というIAMロールが自動作成されます。自動作成されたIAMロールはSSOアカウント以外のAWSアカウント上では操作不可です。
IAM Identity Center によるシングルサインオンの実態は、AWSアカウント上に自動作成されたIAMロールへのスイッチロールです。
IAM方式ではIAMグループにMFAを強制するIAMポリシーをアタッチしてセキュリティを高めていましたが、IAM Identity Center ではアクセスポータルサイトへのアクセスにMFAを設定することができます。
運用イメージ
SSOアカウント
SSO方式の場合、各種AWSアカウントにログインするユーザー/グループ/権限を全てSSOアカウントで管理する必要があります。そのため、基本的にはエンドユーザーからの依頼に基づいてそれらをメンテナンスするという運用が考えられます
IAM方式とSSO方式のどちらが良いの？
結論から言うと私としてSSO方式をオススメしたいです。以下、理由を列挙しています
- IAMのサービスクォータでは、AWSアカウントが数十〜数百に拡張した際に耐えきれなくなる可能性が高い
- IAM方式だとIAM管理アカウント以外での運用作業が発生するが、SSO方式だとSSOアカウント内で完結する
- ユーザー目線だとSSO方式の方がUIがシンプルで分かりやすい
- その他、SSO方式だとIDソースとしてActive Directoryや外部IDプロバイダーを指定できるため、既存IDリソースを活用しやすい
参考
IAM のサービスクォータ
| リソース | デフォルトクウォータ | 上限緩和可否 |
|---|---|---|
| IAMユーザー数 | 5,000 | 不可 |
| IAMグループ数 | 300 | 可 最大500 |
| IAMロール数 | 1,000 | 可 最大5,000 |
| IAM ユーザーがメンバーになれるグループ | 10 | 不可 |
| IAM グループにアタッチされた管理ポリシー | 10 | 不可 |
IAM クォータおよび AWS STS クォータ、名前の要件、および文字の制限 - AWS Identity and Access Management
IAM Identity Center のサービスクォータ
| リソース | デフォルトクウォータ | 上限緩和可否 |
|---|---|---|
| IAM Identity Centerで許可される許可セット数 | 2,000 | 可 |
| AWSアカウントあたりに許可されるアクセス許可セット数 | 50 | 可 |
| アクセス許可セットごとの管理ポリシーとカスタマー管理ポリシーの数 | 20 | 不可 |
| IAM Identity Centerでサポートされるユーザの数 | 100,000 | 可 |
| IAM Identity Centerでサポートされるグループの数 | 100,000 | 不可 |
| 設定可能なAWSアカウントまたはアプリケーションの総数 | 3,000 | 可 |
まとめ
ということで、今回も超大作になってしまいましたが、AWS Organizations における「アクセス統制」について整理してみました。どなたかのお役に立てば幸いです。
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers
