こんにちは！イーゴリです。
AWS IAM Identity Center（旧 AWS SSO）は、マルチアカウント環境における認証・認可の中枢を担うサービスです。シンプルに見える設定の裏側には、設計を誤ると後から変更できない制約や、外部 IdP 連携特有の罠が存在します。今回の記事では、IAM Identity Centerの構築及び設計の注意点を紹介します。
- IAM Identity Center インスタンスの配置要件
- Delegated Administrator による Management Account 保護
- Permission Set の設計
- Microsoft Entra ID（旧 Azure AD）や他のIdP連携の注意点
- セキュリティベストプラクティス総まとめ
- まとめ
IAM Identity Center インスタンスの配置要件
Management Account に作られる理由
IAM Identity Center のインスタンスは、AWS Organizations の Management Account に作成されるという制約があります。これは IAM Identity Center が組織内の全メンバーアカウントに対して IAM ロールのプロビジョニング・デプロビジョニングを行う必要があるためで、Organizations との統合が前提となっています。
Delegated administration – AWS IAM Identity Center User Guide
Control Tower との同一リージョン制約
IAM Identity Center を有効化する AWS リージョンは Control Tower のホームリージョンと一致させる必要があります。これは Control Tower がランディングゾーンをセットアップする際に、IAM Identity Center インスタンスを同じリージョンで使用するためです。
なお、IAM Identity Center がすでに us-east-1 に存在する場合は、Control Tower がどのホームリージョンを選択しても us-east-1 のインスタンスが利用されます。
Prerequisite: Automated pre-launch checks – AWS Control Tower User Guide
ポイントまとめ：
- IAM Identity Center は単一リージョンで有効化（ユーザーへのアクセス自体はグローバルに提供される）
- Control Tower のホームリージョンと IAM Identity Center のリージョンは一致が必須
- Active Directory を使う場合、そのディレクトリのホームリージョンも IAM Identity Center のリージョンと同じにする必要がある
Considerations for choosing an AWS Region – AWS IAM Identity Center User Guide
マルチリージョン対応（2024年以降）
外部 IdP を使用した組織インスタンスでは、追加リージョンへのレプリケーションがサポートされています。
プライマリリージョンで障害が発生した場合でも、追加リージョンのアクセスポータルエンドポイントを通じてアクセスを継続できます。ただし、Active Directory との統合やオプトインリージョンはサポートされていないため注意が必要です。
IAM Identity Center 初期設定手順
上記の注意を把握した上、IAM Identity Center 初期設定を行います。
インスタンス名は環境を識別するためのものであり、任意で設定できます。
注意点： インスタンス名は AWS access portal 上でユーザーに表示されるため、個人情報や機密情報を含めないようにしてください。また、環境を識別しやすい命名（例: dev / stg / prod）を付けることを推奨します。
任意のステップですが、アクセスURLを変更することができます。変更前はIdentity Store IDと同じアクセスURLになります。
「アイデンティティソース」欄内の[アクション] > [AWS access portal URL をカストマイズ]をクリックし、アクセスURLを設定します。
Delegated Administrator による Management Account 保護
なぜ Management Account へのアクセスを減らすべきか
Management Account は Organizations の頂点に位置し、すべてのメンバーアカウントに影響を与える操作が可能です。デフォルトでは、Identity Center の管理作業（ユーザーやグループのアサイン、Permission Set の管理）も Management Account から行う必要があります。これは最小権限の原則に反するリスクがあります。
Delegated Administrator の仕組み
IAM Identity Center では、Organizations のメンバーアカウントを Delegated Administrator（委任管理者） として登録することで、Management Account に直接アクセスすることなく大半の管理作業を実施できるようになります。
登録できるのは 1 アカウントのみ で、通常はセキュリティ専用 OU に所属するアカウント（例：Security Tooling Account）が選ばれます。
AWS Organizations
├── Management Account（IAM Identity Center インスタンスが常駐）
│ └── ← 直接アクセスを最小化したい
└── Security OU
└── Security Account ← Delegated Administrator として登録
└── ここから Permission Set・アサインを管理する
Delegated administration – AWS IAM Identity Center User Guide Getting started with IAM Identity Center delegated administration – AWS Security Blog
Delegated Administrator でできないこと
Delegated Administrator には意図的な制限があります。最も重要なのはManagement Account に対してプロビジョニングされた Permission Set は、Delegated Administrator からは変更できない
つまり、Management Account へのアクセス権限を管理する Permission Set は、必ず Management Account から操作しなければなりません。これによって、委任した管理者が Management Account の権限を勝手に変更することを防いでいます。
専用アカウントにDelegated Adminを登録する手順
Permission Set の設計
ポリシー種別の正しい理解
Permission Set には複数種類のポリシーを組み合わせて設定できます。それぞれの挙動の違いを正確に把握しておくことが、設計ミスを防ぐ鍵です。
| ポリシー種別 | 管理者 | アカウントへの事前作成 | 特徴 |
|---|---|---|---|
| AWS Managed Policy | AWS | 不要（全アカウントに存在） | AWS が管理・更新 |
| Customer Managed Policy | 利用者 | 必須 ⚠️ | 同名ポリシーを各アカウントで事前作成が必要 |
| Inline Policy | 利用者 | 不要（自動作成） | Permission Set 内に直接記述 |
| Permissions Boundary | 利用者 | CMP 使用時は必須 | 最大権限の上限を設定する |
Customer Managed Policy（CMP）の落とし穴
CMP を Permission Set に紐付ける場合、IAM Identity Center がアサインを行う前に、対象の全アカウントに同名・同パスの IAM ポリシーが存在する必要があります。これを忘れると、Permission Set のプロビジョニングが失敗します。
大規模な組織では、この事前作成を忘れがちです。CloudFormation StackSets や Service Catalog を使って、メンバーアカウントに CMP を事前デプロイするパイプラインを整備することを推奨します。
なお、ポリシー名は 大文字・小文字を区別しないという点も押さえておきましょう。
セッション時間の設計
Permission Set ごとにセッション時間を設定できます。
- デフォルト: 1 時間
- 最小値: 1 時間
- 最大値: 12 時間
IAM Identity Center は各アカウントに IAM ロールを自動作成し、そのロールの最大セッション時間を 12 時間 に設定します。Permission Set のセッション時間はその範囲内で制御されます。
Set session duration for AWS accounts – AWS IAM Identity Center User Guide
設計の考え方：
- 強い権限（AdministratorAccess など）ほどセッション時間を短く設定する
- 読み取り専用の Permission Set はやや長めでも許容される
- セキュリティポリシー上、Management Account へのアクセス Permission Set は最小（1 時間）を推奨
セッション時間を変更すると、その Permission Set がプロビジョニングされている 全アカウントが自動的に再プロビジョニング されます。大規模環境では変更のタイミングに注意が必要です。
Management Account 専用 Permission Set を作る理由
前述の Delegated Administrator の制約と合わせて、Management Account へのアクセスには 専用の Permission Set を用意する ことが強く推奨されています。
これにより、
- 管理権限を明確に分離できる
- Delegated Administrator による誤変更を防止できる（変更は Management Account からのみ可能）
- 監査ログで Management Account 操作を識別しやすくなる
Permission Set の作成手順
アクセスポータルにログインしますと、上記に付与した権限がありました！
Microsoft Entra ID（旧 Azure AD）や他のIdP連携の注意点
連携の全体像
Microsoft Entra ID と IAM Identity Center の連携は下記の 2 つのプロトコルで成り立っています。
- SAML 2.0: 認証（サインイン）のフロー
- SCIM 2.0: ユーザー・グループの自動プロビジョニング
注意点 1: Username の形式
Entra ID から SCIM でプロビジョニングされるユーザーの username は、UPN（User Principal Name）形式（例: user@example.com）になります。
一方で、IAM Identity Center 側で手動作成したユーザーや既存ユーザーの username と形式が一致しない場合、SAML ログイン時のユーザーマッピングに失敗する可能性があります。
特に、UPN（例: user@company.onmicrosoft.com）とメールアドレス（例: user@company.com）が異なる環境では注意が必要です。
デフォルトでは、SAML の NameID（ユーザー識別子）には user.userprincipalname が使用されますが、IAM Identity Center 側でメールアドレスを識別子としている場合、この不一致によりログインに失敗することがあります。
そのため、必要に応じて NameID のソース属性を user.mail に変更し、両者の形式を一致させることが重要です。
①
Ensure that your SCIM configuration in your IdP is using only a single attribute for matching with users in IAM Identity Center. For example, mapping username or userPrincipalName in the IdP to the userName attribute in SCIM for provisioning to IAM Identity Center will be correct and sufficient for most implementations.
②
Users can’t sign in when their user name is in UPN format
Users might not be able to sign in to the AWS access portal based on the format they use to enter in their user name on the sign in page. For the most part, users can sign in to the user portal using either their plain user name, their down-level logon name (DOMAIN\UserName) or their UPN logon name (UserName@Corp.Example.com). The exception to this is when IAM Identity Center is using a connected directory that has been enabled with MFA and the verification mode has been set to either Context-aware or Always-on. In this scenario, users must sign in with their down-level logon name (DOMAIN\UserName). For more information, see MFA for Identity Center directory users. For general information about user name formats used to sign in to Active Directory, see User Name Formats on the Microsoft documentation website.
なお、IAM Identity Center を新規構築する場合（既存ユーザーなし）は、user.userprincipalname のままでも動作上の問題はありません。ただし、ユーザー名が下記のようになります。
user@company.onmicrosoft.com
下記に比較を示します。新規構築の場合であっても、可読性の観点から user.userprincipalname ではなく user.mail に変更したほうが分かりやすいです。
| 新規構築の場合（既存ユーザーなし） | user.userprincipalname |
user.mail |
|---|---|---|
| 動作 | ✅ | ✅ |
| 表示例 | user@company.onmicrosoft.com |
user@company.com |
| 見やすさ | ❌ 読みにくい | ✅ メールアドレスと同じ |
注意点 2: MFA は外部 IdP では管理できない
IAM Identity Center の MFA 設定は、外部 IdP（Entra ID を含む）を使用している場合はサポートされていません。
MFA in IAM Identity Center is currently not supported for external identity providers.
Configure MFA in IAM Identity Center – AWS IAM Identity Center User Guide
Entra ID 連携時の MFA は Entra ID 側の条件付きアクセス（Conditional Access） で管理する必要があります。IAM Identity Center の MFA 設定画面で設定できると誤解しないよう注意が必要です。
注意点 3: ネストされたグループは非対応
Entra ID のプロビジョニングサービスは、ネストされたグループのメンバーを読み取れません。明示的にアサインされたグループの直接メンバーのみがプロビジョニングの対象です。
例えば下記のような構造：
Group-A（IAM Identity Center にアサイン）
└── Group-B（ネストされたグループ）
└── User-X
この場合、User-X は Group-B の直接メンバーですが、Group-A にはネストを通じて所属しているため、User-X は IAM Identity Center にプロビジョニングされません。
Entra ID のグループ構造を IAM Identity Center 向けに設計する際は、フラットな構造を維持するか、Dynamic Group を活用する必要があります。
注意点 4: 属性の削除は同期されない
Entra ID でユーザーの属性を削除した場合、その削除は IAM Identity Center に同期されません。これは Entra ID の既知の制限です。
空でない値への変更は同期されますが、属性の削除は反映されないため、ABAC（属性ベースのアクセス制御）を活用している場合は特に注意が必要です。
Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center – Considerations
なお、SCIM の仕様上は多値属性をサポートしていますが、IAM Identity Center では一部制限があります。
Microsoft Entra ID と IAM Identity Center の連携手順
Microsoft Entra ID と IAM Identity Center の連携手順については、下記をご参照ください。
セキュリティベストプラクティス総まとめ
Management Account の保護
| プラクティス | 理由 |
|---|---|
| Management Account へのアクセスは グループではなく個人ユーザー を直接アサイン | グループ管理者が IdP 側でメンバーを追加することで Management Account へのアクセスが意図せず広がることを防ぐ |
| Management Account 専用の Permission Set を作成 | Delegated Administrator が変更できないように保護する |
| Temporary Elevated Access を活用 | 必要なときだけ昇格権限を付与する |
外部 IdP との統合時
| プラクティス | 理由 |
|---|---|
| Delegated Administrator アカウントから Identity Store への書き込み操作を SCP で制限 | IdP（Entra ID）が source of truth であり、手動変更はリスク。IdP 側の SCIM サイクルで上書きされる |
| SCIM Bearer Token の発行を制限 | SCIM トークンが漏洩すると、メンバーアカウント管理者がグループやユーザーを操作できてしまう |
| Permission Set にタグを付けて特定アカウントの委任管理を分離 | タグとアカウントリストを組み合わせることで、きめ細かな委任管理が可能 |
Delegated administration – Limit IAM Identity Center identity store actions
Permission Set 設計
| プラクティス | 理由 |
|---|---|
| 最小権限の原則を Permission Set 設計に徹底 | 権限の過剰付与はすべてのアサインされたアカウントに影響する |
| セッション時間は必要最小限に | ロングセッションは認証情報の窃取リスクを高める |
| Customer Managed Policy はインフラとして事前デプロイ | アサイン失敗を防ぐ |
まとめ
IAM Identity Center は一見シンプルですが、正しく設計・運用するには多くの落とし穴があります。本記事で取り上げたポイントを整理すると
- 配置: Management Account 固定・Control Tower と同リージョン必須
- Delegated Administrator: Management Account アクセスを最小化する鍵。ただし Management Account 向け Permission Set の変更は委任不可
- Permission Set: CMP は事前作成が必須、セッション時間は権限強度に応じて設計する
- Entra ID 連携: MFA は Entra ID 側で管理、ネストグループ非対応、属性削除は同期されない
- セキュリティ: Management Account はグループではなく個人アサイン、SCP で Identity Store 書き込みを制限
これらの制約と設計パターンを事前に理解しておくことで、後から修正困難な設計ミスを防ぎ、セキュアで運用しやすい IAM Identity Center 環境を構築できます。
以上、御一読ありがとうございました。
本田 イーゴリ (記事一覧)
カスタマーサクセス部
・2024 Japan AWS Top Engineers (Security)
・AWS SAP, DOP, SCS, DBS, SAA, DVA, COA, CLF, ANS, AIF, MLS, MLA, DEA
・Azure AZ-900
・EC-Council CCSE
趣味：日本国内旅行(47都道府県制覇)・ドライブ・音楽
