🥚
私有AWSアカウントでマルチアカウント環境構築

2025/05/24に公開
AWS IAM Identity Center
tech
 はじめに以前から複数のAWSアカウントを効率的に管理するためのこれらサービスが気になっていたので、プライベートで所有しているAWSアカウントにて実践しました。
AWS Organizations
AWS Control Tower
AWS IAM Identity Center(旧称:AWS Single Sign-On)

 実践内容プライベートのAWSアカウントでControl Towerを用いてマルチアカウント環境を構築
AWSアカウント、ユーザ、グループ、許可セットを作成し、特に開発者に必要な権限について、自分なりに考えた

 1. AWS Control TowerまずControl Towerでランディングゾーンを設定します。ランディングゾーンとは、AWSのベストプラクティスに沿ったマルチアカウント環境(統制を利かせたマルチアカウント環境)のことです。Control Towerを利用することでランディングゾーンを容易に構築できます。設定手順についてはこちらのBlack Beltが大変参考になりました。
AWS Control Tower 手順編 AWS Control Tower の有効化【AWS Black Belt】
Control Towerによって2つのOU(Security OUとSandbox OU)、2つのAWSアカウント(監査アカウントとログアーカイブアカウント)、SCPが作成されます。Organizations、Identity Center、CloudTrailの組織証跡の有効化されます。また、メンバーアカウントではAWS Configの有効化、SNSトピックス・サブスクリプションが作成されます。※知らず知らずのうちに有効化・作成されているものがありそう。

デフォルトではControl Tower、Organizations、Identity Centerの管理アカウントは同一ですが、Organizations、Identity Centerの管理者権限をメンバーアカウントに委任することも可能です。

理解が曖昧だったことはSCPの適用範囲です。SCPは管理アカウント内のユーザやロールには影響せず、組織のメンバーアカウントにのみ影響するようです。
Service control policies (SCPs)
AWS OrganizationsとAWS Control Towerを使ったマルチアカウント管理
セットアップ完了後のアーキテクチャは次のようになります。
ランディングゾーンの設定項目を少し深堀りします。
ホームリージョン
＝Control Towerを有効化するリージョン
Identity Centerを利用する場合はホームリージョンで有効化されます

ガバナンスのための追加リージョンを選択
＝ランディングゾーンリージョンを選択
ランディングゾーンリージョンとは、ランディングゾーンが構築されるリージョンで、Control Towerによってリソース(Config,SNS)が作成されます
追加/削除が後から可能です

リージョン拒否設定
＝ホームリージョン・ランディングゾーンリージョン以外のAPI操作を禁止する設定
「ガバナンスのための追加リージョンを選択」で選択したリージョンに基づいて設定されます
実態はSCPです
有効化後はランディングゾーンリージョン以外での操作ができなくなるため、事前にAWS Resource Explorerを使って各リージョンのリソースの状況確認・削除を行いましょう

AWSアカウントを新規発行するときは、Control TowerのAccount Factoryから行います。ランディングゾーンの設定においてもそうですが、アカウント発行にはメールアドレスが必須の設定項目です。「アカウントの数だけGmailアカウントが必要で管理が面倒」と思っていましたが、サブメールアドレス(エイリアス)機能を使って解消できます。Gmailの場合、@の前に「+」と任意の文字列を付与すれば利用できます。例えば、「XXX@gmail.com」を流用して、「XXX+user@gmail.com」で設定可能です。サブメールアドレスへ送られるメールはメインアドレスと同じメールボックスに送られます。Gmail側の操作は不要です。
アカウントのEメールアドレス

 2. AWS IAM Identity CenterIAM Identity Center管理下のユーザにメンバーアカウントの操作権限を与える
Account Factoryで発行したAWSアカウントに開発者向けユーザの作成と権限付与を行います。手順は以下になります。
Identity Centerでユーザを作成
IAMグループと同じ考え方で、Identity Centerのグループを作成しておくと、複数ユーザにまとめて権限を付与できます
ユーザのメールアドレスに届く招待メールからパスワード、MFAの設定を行います
この段階では何も権限が付与されていないので、アクセスポータルには何も表示されません


Identity Centerユーザへの権限付与①
Identity Center>マルチアカウント許可>許可セットを作成します
「事前定義された許可セット」と「カスタム許可セット(推奨)」から選択します
今回は後者にカスタマーマネージドポリシーをアタッチします
メンバーアカウントで事前にIAMポリシーを作成しておきます


管理アカウントにて、カスタマーマネージドポリシーのポリシー名には、メンバーアカウントで作成したIAMポリシー名「CustomPowerUserAccess」を入力します


許可セットの作成が完了すると、メンバーアカウントにCustomPowerUserAccessがアタッチされたロール「AWSReservedSSO_CustomAWSPowerUserAccess_{uudi}」が作成されます
「AWSReservedSSO_」から始まるロールやそれにアタッチされているポリシーはIdentity Centerマネージドなリソースのため、Admin権限をもつユーザでも削除不可です(SCPによって制限されている訳ではありません)
ロールの信頼関係にはIDプロバイダー（IdP）としてAWS SSO（Identity Center）が設定されています
このリソースは同アカウントのIAM>IDプロバイダに作成されていました（これ以上深掘ると沼なのでやめる）
I get a ‘Cannot perform the operation on the protected role' error when modifying an IAM role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::{AccountId}:saml-provider/AWSSSO_{uuid}_DO_NOT_DELETE"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                }
            }
        }
    ]
}

Identity Centerユーザへの権限付与②
Identity Center>マルチアカウント許可>AWSアカウント>{アカウント名}>割り当てを行います
ここでは許可セットとそれを割り当てるユーザ・グループを選択します
設定後のアクセスポータルにはAWSアカウントが表示されています
許可セットをクリックしてマネジメントコンソールにアクセスできるようになりました

 3. カスタマイズ先ほどメンバーアカウントに作成したIAMポリシー「CustomPowerUserAccess」はマネージドポリシー「PowerUserAccess」と同じ内容です。よく使われるポリシーと思いますが、開発者がロールを作成する、ポリシーを参照する、といった操作ができないため不便に感じています。そこでちょっとカスタマイズしてみました。ポイントはIAMフルアクセスを付与しつつ、開発者が自身に割り当てられたこのポリシーを編集できないようDenyを追記しました（開発者が自身の権限を勝手に拡張できないようにするため）。また、ユーザ管理系のサービスは使わないと思うのでNotActionに「sso:*」を追加しました。※IAMフルアクセスはリッチ過ぎなのでマネしないように。
PowerUserAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "account:GetAccountInformation",
                "account:GetPrimaryEmail",
                "account:ListRegions",
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeEffectivePolicy",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}
CustomPowerUserAccess(カスタマイズver.)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "organizations:*",
                "account:*",
                "controltower:*",
                "sso:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "account:GetAccountInformation",
                "account:GetPrimaryEmail",
                "account:ListRegions",
                "organizations:DescribeOrganization",
                "iam:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": "iam:CreatePolicyVersion",
            "Resource": "arn:aws:iam::745167176844:policy/CustomPowerUserAccess"
        }
    ]
}

 Identity Centerユーザがアカウントにアクセスする仕組みアクセスポータルにログインしたユーザは各アカウントに用意されたIAMロール（AWSReservedSSO_XXX）にスイッチロールすることで、メンバーアカウントのリソースを操作する権限を得ます。こちらの解説がとても参考になりました。
AWS SSOを図解してみた

 Identity Centerがアクションするための権限Identity Centerの実行ロールはAWSServiceRoleForSSOです
アタッチされているポリシー「AWSSSOServiceRolePolicy」には、パス「/aws-reserved/sso.amazonaws.com/」を有するロールに対する管理権限と、IDプロバイダ（saml-provider/AWSSSO_*）に対するcreate/update権限が記載されていました（Identity Centerがこのロールを使ってIAMリソースを操作していることを確認できました）
Using service-linked roles for IAM Identity Center
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "sso.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}


 アーキテクチャ最終的な構成はこちらです。

 マルチアカウント環境のメリット使い終わった環境(アカウント)を即座に削除できるため、リソースの消し忘れを防げる
依存関係などが問題でリソースを削除できなくなった場合はアカウントごと消してしまえばいい、という暴挙に出られる
SCP,RCP,宣言型ポリシー,クロスアカウントなど検証の幅が増える

 メンバーアカウントのrootユーザAccount Factoryで作成したAWSアカウントにもrootユーザが存在します。メンバーアカウントにrootユーザは認証情報が発行されていないため、ログインするにはパスワードリセットが必要です。rootユーザメールアドレス、rootユーザ名はAccount Factory>アカウントの作成>アカウントの詳細で入力した「アカウントEメール」、「表示名」になります。

詳しいログイン手順は下記を参照ください。
ルートユーザーとしてサインインする場合
管理アカウントから各メンバーアカウントに対してroot権限が必要な操作を行うために「Root access management」という機能があります。rootユーザの使用を禁止することもできるようです（本記事では扱いません）。

 さいごに今回はControl Towerを使ってマルチアカウント環境を構築しました。裏側の仕組みが気になって色々と調べながら執筆しました。かなり手に馴染んできた感覚があります。一方で、Identity CenterとSAMLの関係や仕組みを全然理解できていません。引き続き、学びを進めていこうと思います。本記事が参考になれば幸いです。最後までお読みいただき、ありがとうございました。