Account Access Managerで割り当てるIAMロールの配置先と運用構成を検証してみた
はじめに
こんにちは、クラウド事業統括本部の浅野です。
最近のアップデートで、IAM Identity Centerのユーザー・グループに既存のIAMロールをそのまま割り当てられる新機能「Account Access Manager」がIAMに追加されました。従来の許可セットは、IAM Identity Center側でロールを一元的に生成・管理する仕組みでしたが、この新機能では自分たちで用意したIAMロールをそのまま割り当てられます。アップデートの概要と基本的なセットアップ手順については、以下の記事で紹介されています。
気になるのは運用体制です。多くの組織では、アクセス許可の割り当てはIAM Identity Centerの委任管理アカウントに集約する一方、ワークロード用のIAMロールは各メンバーアカウントでチームごとにIaC管理しています。Account Access Managerでもこの分担のまま、割り当ての運用は委任管理アカウントに一元化し、各アカウントの既存ロールをそのまま割り当て対象にする、というイメージで検証しました。
あわせて、既存のIAMロールは信頼ポリシーを自由に設定できることから、許可セットが自動生成するロールでは実現できなかった、信頼ポリシーでのaws:SourceIpによるIPアドレス制限ができるかも検証しました。
前提: Account Access Managerの委任管理者はIAM Identity Centerと揃える
Account Access Managerでは、IAM Identity Centerと同様に、管理業務の大部分をメンバーアカウントに委任できます。
AWS SRAでは、委任管理者機能の活用がベストプラクティスとして強調されており、委任先をサービスごとにバラバラにするのではなく、関心事ごとに集約する構成が採用されています(セキュリティ検知系サービスはSecurity Toolingアカウント、IAM Identity CenterはShared Servicesアカウント、という具合です)。
Account Access ManagerはIAM Identity Centerと同じ「ワークフォースのアクセス統制」を扱うサービスです。SRAの考え方をふまえると、Account Access Managerの委任先はIAM Identity Centerの委任先と同じアカウントに統一する(それがどのアカウントであっても)のが、運用のあるべき姿だと考えました。
両者を別のアカウントに分けると「誰がどのアカウントにアクセスできるか」を握るアカウントが2つに増え、統制対象が不必要に広がるためです。
今回の検証もこの構成で実施しました。
検証すること
- 委任管理アカウントから、別のメンバーアカウントで管理されている既存IAMロールへの割り当てを作成・運用できるか
- 信頼ポリシーに
aws:SourceIp条件を書いて、IAM Identity Center経由でのAWSマネジメントコンソールアクセス時にIPアドレスベースのアクセス制限ができるか
今回の検証構成のイメージです。管理アカウントは有効化と委任管理者の登録にのみ使い、割り当ての作成は委任管理アカウントから行います。IdCユーザーは、割り当てられたワークロードアカウントのロールをaccount access portal経由で引き受けます。
検証環境
今回登場するアカウントは3つです(アカウントIDはすべてダミー値に置き換えています)。
| アカウント | 役割 |
|---|---|
管理アカウント(111111111111) |
Organizationsの管理アカウント。Account Access Managerの有効化と、委任管理者の登録にのみ使用 |
委任管理アカウント(222222222222) |
IAM Identity Centerの委任管理者。Account Access Managerの委任管理者としても登録し、日常運用(ユーザーへのロール割り当て)をここから行う |
ワークロードアカウント(333333333333) |
検証用のIAMロールを配置する、委任管理アカウントとは別のメンバーアカウント |
実際の環境では、ロールはこのようなワークロードアカウントが複数あってそれぞれに散らばっている想定です。ロールを1つのアカウントに集約する必要はなく、今回はその代表として1つのワークロードアカウントで検証します。リージョンはap-northeast-1です。
検証1: 別アカウントに置かれたIAMロールの割り当て
Account Access Managerの有効化
まず、管理アカウントでAccount Access Managerを有効化します。IAMコンソールから「アカウントアクセスマネージャー」を選択し、「有効化」を押すだけで完了します。
CLIの場合は、事前に以下のコマンドでOrganizationsの信頼されたアクセスを有効化しておきます(コンソールから有効化した場合は自動で有効化されます)。
aws organizations enable-aws-service-access \
--service-principal account-access.amazonaws.com
有効化が完了すると、アカウント/ユーザー/グループ/設定のタブが表示されます。
委任管理者の登録
続けて、冒頭の方針の通り、IAM Identity Centerの委任管理者と同じアカウントをAccount Access Managerの委任管理者としても登録します。登録はAccount Access Managerコンソールの「設定」タブ→「委任管理者」の「登録」から行えます。
CLIの場合は以下のコマンドで登録できます。
aws organizations register-delegated-administrator \
--account-id 222222222222 \
--service-principal account-access.amazonaws.com
なお、この有効化・委任管理者登録の2つは、管理アカウントでしか実行できません。委任管理アカウントの権限セットにはaccount-access:CreateApplication権限が含まれておらず、日常運用(割り当ての作成・削除)だけが委任管理アカウントに移譲される設計です。
IAMロールの作成
ワークロードアカウントに、検証用のIAMロールを作成します。既にIaC等で管理しているロールがあれば、それをそのまま使えます(その場合は、以下の信頼ポリシーのステートメントを既存の信頼ポリシーに追記するだけです)。信頼ポリシーはaccount-access.amazonaws.comを信頼し、aws:SourceAccount/aws:SourceArn条件で自組織のAccount Access Managerアプリケーションからのリクエストのみを許可します。
aws iam create-role \
--role-name aam-verify-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "account-access.amazonaws.com" },
"Action": ["sts:AssumeRole", "sts:SetContext", "sts:SetSourceIdentity"],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111111111111",
"aws:SourceArn": "arn:aws:account-access:ap-northeast-1:111111111111:application/xxxxxxxxxxxxxxxx"
}
}
}
]
}'
aws iam attach-role-policy \
--role-name aam-verify-role \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
割り当てを作成
委任管理アカウントのAccount Access Managerコンソールから、ワークロードアカウントのアカウントID + ロール名を指定して割り当てを作成します。ここで2つほどハマりポイントがあったので紹介します。
ハマりポイント1: sts:SetSourceIdentityが必要
信頼ポリシーに必要なSTS権限については冒頭のアップデート紹介記事でもハマりポイントとして紹介されていますが、今回も同様にハマりました。当初sts:AssumeRole + sts:SetContextのみの信頼ポリシーで割り当てを作成しようとしたところ、以下のエラーになりました。
ValidationException
Error while verifying role for organization instance. Please ensure the role exists,
trusts the account-access service, and that the account is a member of the
application's organization
公式ドキュメントではsts:SetContextのみ必須、sts:TagSessionは"Optional"と明記されていますが、sts:SetSourceIdentityへの言及は一切ありません。信頼ポリシーにsts:SetSourceIdentityを追加したところ、このエラーは解消しました。
興味深いのは、sts:TagSessionは追加しなくても割り当て・ログインとも成功したことです。ドキュメントの「Optional」という記載通り、sts:TagSessionは本当に任意でした。つまり最終的に必要なActionは以下の3つです。
"Action": ["sts:AssumeRole", "sts:SetContext", "sts:SetSourceIdentity"]
ハマりポイント2: ユーザー検索は表示名の前方一致
Account Access Managerコンソールで割り当てるユーザーを検索する際、検索は表示名の前方一致で動作します。ユーザー名(ログインID)ではなく表示名(例: 「Taro Yamada」)で検索する必要があり、ユーザー名の一部を入力しても候補に出てきません。地味にハマったポイントなので共有しておきます。
上記2点を踏まえて操作すると、割り当てが正常に作成できました。
結果: 別アカウントのロールを問題なく割り当てできる
account access portalを開くと、割り当てたロールが表示されます。
ロールを選択すると、ワークロードアカウントのAWSコンソールに管理者権限でログインできました。右上のアカウントメニューにフェデレーティッドユーザーとして割り当てたロールが表示されています。
これにより、割り当ての運用を委任管理アカウントに一元化したまま、各メンバーアカウントに散らばったIAMロールをそのまま割り当て対象にできることを確認できました。委任管理アカウント側の運用担当者は、ロールの中身を一切把握しなくても、対象アカウントIDとロール名(ARN)さえ分かれば割り当てを作成できます。ロールの定義・ライフサイクルは各ワークロードアカウントのチームに残したまま、「誰がどのロールを使えるか」だけを委任管理アカウントで統制する、という役割分担が成立します。
注意: ロール自体を1箇所に集約することはできない
逆に、ロールを委任管理アカウント等の1箇所に集約して、各アカウントへのアクセスに使い回すことはできません。ロールを引き受けて得られるのは、そのロールが属するアカウントのセッションだからです(IAMの原則通りの挙動です)。割り当てで指定できるのはアクセス先アカウント自身に存在するロールだけで、コンソールにも「選択したアカウントの既存のIAMロールである必要があります」と明記されています。
Account Access Managerで一元化できるのは割り当ての管理だけで、ロール自体は必ず各アカウントに分散します。
トレードオフ: ロールは自分で用意する必要がある
許可セットは1回の定義で全アカウントにロールが自動展開されますが、Account Access Managerにはこの仕組みがありません。対象アカウントごとに、自分たちでロールを用意する必要があります。公式の比較表にもこの違いが明記されています。
| IAM roles + Account Access Manager | IAM Identity Center Permission sets | |
|---|---|---|
| IAM role provisioning | Requires infrastructure as code (IaC) or manual provisioning | Automatically provisioned |
つまりAccount Access Managerは、「各アカウントに散らばった既存ロールをそのまま活かせる」というメリットと引き換えに、「ロールを一元的に自動展開できない」という運用コストを引き受ける機能です。この点を理解した上で採用を検討する必要があります。
検証2: 信頼ポリシーでのIPアドレス制限
許可セットでは信頼ポリシーがIAM Identity Center側で固定管理されており、aws:SourceIpのようなネットワーク条件を追加することはできません。Account Access Managerでは信頼ポリシーを自分で自由に書けるため、「AdministratorAccessのような強い権限のロールは社内IPからのみ引き受け可能にする」といった制御が信頼ポリシーだけで実現できるのではないか、と考えて試しました。
実機で試す
先ほどのロールの信頼ポリシーに、実際に使っている自分のグローバルIPを許可リストに含めたaws:SourceIp条件を追加しました。
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111111111111",
"aws:SourceArn": "arn:aws:account-access:ap-northeast-1:111111111111:application/xxxxxxxxxxxxxxxx"
},
"IpAddress": {
"aws:SourceIp": ["<許可したいIPアドレス>/32"]
}
}
この状態でaccount access portalからログインを試みたところ、許可リストに自分の実際のIPを含めているにもかかわらず、以下のエラーでログインに失敗しました。
Federation failed
The specified role does not have sufficient STS permissions
CloudTrailで原因を特定
ロールが存在するアカウント側のAWS CloudTrailで、このときのAssumeRoleイベントを確認しました。
{
"eventName": "AssumeRole",
"sourceIPAddress": "account-access.amazonaws.com",
"userIdentity": {
"type": "AWSService",
"invokedBy": "account-access.amazonaws.com"
},
"requestParameters": {
"roleArn": "arn:aws:iam::333333333333:role/aam-verify-role",
"policy": "{ ... Effect:Deny unless aws:PrincipalOrgID matches ... Effect:Allow if aws:PrincipalOrgID matches ... }"
}
}
決定的なのはsourceIPAddressの値です。実際のIPアドレスではなく、"account-access.amazonaws.com"というサービスのドメイン名が入っています。これはAWSのサービスプリンシパルが呼び出し元になっている場合の既定の挙動です。
つまりsts:AssumeRoleを実際に呼び出しているのは、ログインしたユーザー本人ではなくAccount Access Managerサービス自身です。ユーザーのブラウザが直接STSを叩いているわけではないため、aws:SourceIpという「呼び出し元の実IP」を見る条件キーは、この呼び出しパターンにおいてはそもそも評価対象となる実IPが存在せず、常に条件不成立(=拒否)になります。
なお、CloudTrailからはもう1つ面白い事実も分かりました。Account Access ManagerはAssumeRole時に、aws:PrincipalOrgIDが自組織と一致しない限り全操作を拒否するセッションポリシーを自動的に付与しています。信頼ポリシーのaws:SourceAccount/aws:SourceArn条件とは別レイヤーで、もう一段の防御が組み込まれているようです。
結果: 信頼ポリシーでのIPアドレス制限はできない
以上の通り、信頼ポリシーへのaws:SourceIpによるIPアドレス制限は機能しないことを、CloudTrailの実データで確認しました。Account Access Manager経由のロール引き受けは常にサービスプリンシパルが仲介するアーキテクチャであるため、信頼ポリシーの条件で利用者のネットワーク情報を評価することはできません。
ネットワークベースでのアクセス制御をしたい場合は、ロールにアタッチする許可ポリシー側で行う必要があります。ロールを引き受けた後のAPI呼び出しは利用者本人の端末から発信されるため、許可ポリシーのaws:SourceIp条件は評価されます。
まとめ
- 割り当ての運用は委任管理アカウントに一元化しつつ、割り当て対象にはOrganization内の任意のメンバーアカウントで管理されている既存ロールを指定できる。「割り当ての統制は委任管理アカウント、ロールの定義は各チーム」という分担がそのまま成立する
- 一方、IAMロールは必ずアクセス先アカウント自身に存在する必要がある。ロールを委任管理アカウント等の1箇所に集約して各アカウントへのアクセスに使い回すことはできず、一元化できるのは割り当ての管理のみ
- 2026年8月現在、信頼ポリシーに必要な
Actionはsts:AssumeRole+sts:SetContext+sts:SetSourceIdentityの3つ。sts:SetSourceIdentityがないと割り当て作成時にValidationExceptionになる - 信頼ポリシーでのIPアドレス制限はできない。AssumeRoleを呼び出すのはAccount Access Managerサービス自身であり、利用者の実IPは信頼ポリシーの評価対象にならない。ネットワークベースでのアクセス制御をしたい場合は、許可ポリシー側で検討する
最後に
Account Access Managerを使って、委任管理アカウントから、各メンバーアカウントに散らばったIAMロールを割り当てる運用が成立するかを検証しました。「アクセス許可の統制はセキュリティ/基盤チームの委任管理アカウント、ロールの定義は各チームのIaC」という分担を敷いている組織でも、その体制のままAccount Access Managerを導入できることを確認できました。
一方で、許可セットが持っていた「ロールの自動展開」はないため、割り当て対象のロールは各アカウントで用意・管理されている必要があります。既存ロールを使う場合も、Account Access Manager用の信頼ポリシーステートメントを対象ロールそれぞれに追記する作業は発生します。このステートメントは全ロール共通の固定値になるので、IaCのロール作成モジュールにテンプレートとして組み込んでおく運用が現実的です。
Account Access Managerは、許可セットに取って代わる万能な新機能というよりは、既に大量のカスタムIAMロールを運用している組織が、それらを作り直さずにIAM Identity Center配下へ持ち込むための現実的な選択肢、という位置づけで捉えるのが実態に近いと感じました。許可セットとの使い分けを検討する際の参考になれば幸いです。今回は以上です。
