当エントリは弊社 AWS 事業本部による「AWS 入門ブログリレー 2024」の 38 日目のエントリです。
このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合いいただければ幸いです。
今回のテーマは「AWS IAM Identity Center」です。
AWS IAM Identity Center とは
AWS IAM Identity Center は複数の AWS アカウントおよびアプリケーションへのアクセスを提供するサービスです。追加料金無しで利用できます。
AWS IAM Identity Center には主に次の機能があり、ユーザーが AWS アカウントやアプリケーションにアクセスするためのポータルサイトも提供されます。
- アクセス管理
- 複数の AWS アカウントへのアクセス
- アプリケーションへのアクセス
- ID 管理（ユーザーの管理）
- 独自の ID ストアでユーザー管理
- Active Directory や 外部 ID プロバイダーとの連携
AWS Organizations 配下の AWS アカウントにアクセスするイメージ図です。AWS IAM Identity Center 内にユーザーを作成して管理します。IAM ユーザーとは異なり、専用の「AWS アクセスポータルサイト」経由でアクセスします。
さらに、SaaS へのアクセス設定を追加したイメージ図です。AWS Organizations 管理外の AWS アカウントを外部のアプリケーションとして追加することもできます。
AWS IAM Identity Center 内でユーザーを作成するのではなく、Microsoft Entra ID や Okta 等の外部の ID 製品のユーザー情報を利用することもできます。
AWS Organizations 環境以外での利用
以前は AWS Organizations の管理アカウントでのみ AWS IAM Identity Center を有効化できましたが、2023 年 11 月のアップデートにより単独の AWS アカウントでも有効化できるようになりました。ただし、単独のアカウントで有効化した場合は機能に制限があります。現時点では AWS アカウントへのアクセス機能は提供されておらず、 AWS IAM Identity Center と統合されている特定の AWS サービスへのアクセス機能が提供されています。
AWS IAM Identity Center を有効化した際はインスタンスが作成されて管理されるのですが、AWS Organizations 管理アカウントで有効化した場合は「組織インスタンス」、単独のアカウントで有効化した場合は「アカウントインスタンス」と呼ばれます。違いについては後で改めて記載します。
以降では、主要な機能の紹介と関連情報を記載します。
アクセス管理
AWS IAM Identity Center で管理できる次の対象について説明します。
- AWS アカウント（AWS Organizations 配下）
- SaaS / アプリケーション
- AWS アカウント（AWS Organizations 管理外）
- AWS マネージドアプリケーション
AWS アカウント（AWS Organizations 配下）へのアクセス
AWS IAM Identity Center は AWS Organizations と統合されており、AWS Organizations 配下のアカウントに対して、アクセス許可セット（権限）をユーザーに割り当てできます。
アクセス許可セットを割り当てられたユーザーは AWS アクセスポータル（下記画像）経由で AWS アカウントにアクセスできるようになります。複数の権限が割り当てられている場合は、アクセスする権限を選択します。黒塗りしている部分には AWS アカウント ID とルートユーザーのメールアドレス情報が表示されます。
アクセス設定には、大きく「AWS アカウント」「ユーザー・グループ」「アクセス許可セット（権限）」の 3 つの要素があります。アクセスさせたい AWS アカウントに対して、どのユーザー・グループにどのような権限を与えるか、を設定します。
1 つのアカウント111122223333に対して、Developerというグループに対して 2 つのアクセス許可セットを割り当てる例です。
アクセス許可セットを複数の対象に割り当てることもできます。
アクセス許可セットには次のポリシーを指定することができます。
- AWS マネージドポリシー（AWS 管理ポリシー）
- カスタマーマネージドポリシー（カスタマー管理ポリシー）
- インラインポリシー
- 許可の境界（Permissions boundary）
アクセス許可セットとして設定した内容は、アクセス先のアカウントでは IAM ロールとして作成されます（自動で作成され、ユーザーは変更できません）。そのことを意識しておくと AWS IAM と似た感覚で設定できると思います。ただし、AWS IAM とはインラインポリシーの利用シーンが異なります。
AWS IAM では、インラインポリシーはあまり使わないことが多いと思いますが、AWS IAM Identity Center ではインラインポリシーを使うことも比較的多いです。理由としては、カスタマー管理ポリシーを利用する場合は、アクセス先のアカウントにおいて事前にカスタマー管理ポリシー（IAM ポリシー）を作成しておく必要があるためです。インラインポリシーの場合は AWS IAM Identity Center のアカウントの操作だけで設定が完結します。
アクセス許可セットを作成してユーザーに割り当てるまでの流れは次のブログにキャプチャ付きで記載しています（一部、UI が古い箇所がありますが、流れは変わっていません）。
また、サービス名が変更される前の名称である AWS Single Sign-On 時代のブログですが、図解で説明している次のブログがイメージを掴むのに分かりやすいです。
SaaS / アプリケーションへのアクセス
SAML 2.0 または OAuth 2.0 を使用した ID フェデレーションをサポートする SaaS やアプリケーションへのアクセス設定を追加できます。
AWS 側で連携のために設定済みのアプリケーションのカタログから選択する方法とユーザーが手動で設定する方法があります。
カタログには、例えば Salesforce、Box、Microsoft 365 などがあります。下図はカタログの選択画面です。
ユーザーが手動で設定する場合は、OAuth 2.0 または SAML 2.0 を選択して設定します。
設定した SaaS やアプリケーションは AWS アクセスポータルにおいて「Applications」タブに表示されます。
AWS アカウント（AWS Organizations 管理外）
「SaaS / アプリケーションへのアクセス」に記載したアクセス先のカタログ の 1 つとして AWS アカウントがあります（下記画像）。これを利用することにより、AWS Organizations 管理外のアカウントでもアクセスする設定ができます。ただし、アクセス先の AWS アカウントの AWS IAM サービスにおいて SAML 連携用の ID プロバイダを作成して設定する必要があります。
AWS Organizations 管理外の AWS アカウントへのアクセス設定についても次のブログで流れを紹介しています（一部、UI が古い箇所がありますが、流れは変わっていません）。
AWS アクセスポータル上では AWS Organizations 配下のアカウントを選択する「Accounts」タブではなく、「Applications」タブに表示される点に注意が必要です。
AWS マネージドアプリケーション
AWS IAM Identity Center のユーザー情報を用いてアクセスするように統合できる AWS サービスがあります。統合できるサービスは AWS マネージドアプリケーション（AWS 管理対象アプリケーション）と呼ばれ、例えば次のサービスがあります。
- Amazon Athena SQL
- Amazon CodeCatalyst
- Amazon EMR on Amazon EC2
- Amazon EMR Studio
- Amazon Q Business
- Amazon Q Developer
- Amazon QuickSight
- Amazon Redshift
- Amazon S3 Access Grants
- AWS Deadline Cloud
- AWS Lake Formation
最新の対応状況や統合の制限事項は次の AWS ユーザーガイドのページで確認できます。
AWS managed applications - AWS IAM Identity Center
ID 管理（ユーザー管理）
AWS IAM Identity Center においてユーザーを管理する方法として、AWS IAM Identity Center 内で管理する方法と外部の ID 製品と連携して管理する方法があります。
- AWS IAM Identity Center 内で管理
- Identity Center ディレクトリ
- 外部の ID 製品と連携して管理
- Active Directory と連携
- 外部 ID プロバイダーと連携
Identity Center ディレクトリ
Identity Center ディレクトリは AWS IAM Identity Center 内で独自のユーザーやグループを作成する場合に利用します。デフォルト設定となっており、外部の ID 製品と連携しない場合は Identity Center ディレクトリを利用します。IAM ユーザーとは別のユーザーとして管理されます。
Active Directory と連携
Microsoft Active Directory (AD) と連携することができます。
連携にはいくつかのパターンがあり、AWS のサービス別資料に掲載されている内容が参考になります。ただし、引用しているサービス別資料の公開日は 2020 年 7 月となり、情報が古い可能性がある点には注意が必要です（資料上にも同様の注意文があります）。
（引用元）AWS アカウント シングルサインオンの設計と運用
外部 ID プロバイダーと連携
外部 ID プロバイダーとして SAML 2.0 を利用して ID 製品と連携できます。
次の製品は AWS ユーザーガイドにおいてチュートリアルページが用意されています。
例えば、Microsoft Entra ID と連携している場合において、AWS アカウントにアクセスする流れは下記となります。上段は Microsoft のマイアプリポータルからアクセスする場合であり、下段は AWS アクセスポータルの URL からアクセスする場合です。
外部 ID プロバイダーと連携した際は、認証は外部 ID プロバイダーで実施されます。ユーザーの連携方法は次の 2 つの方法があります。
- 自動プロビジョニング
- 手動プロビジョニング
自動プロビジョニングでは、外部 ID プロバイダーから SCIM プロトコルによりユーザーとその属性情報を AWS IAM Identity Center 側に同期します。AWS IAM Identity Center ではユーザーやグループの作成はできず、外部 ID プロバイダー側で管理する方法となります。
手動プロビジョニングでは、外部 ID プロバイダーのユーザーと同様の ID を持つユーザーを手動で AWS IAM Identity Center で作成する必要があります。グループは AWS IAM Identity Center 側で作成・管理できます。なお、外部 ID プロバイダーに存在しない ID のユーザーを作成しても認証できないため利用できません。
自動プロビジョニングを採用して外部 ID プロバイダー側で全てのユーザーとグループを一元的に管理する方法がシンプルですが、外部 ID プロバイダーを管理している部門が異なるなどの理由により AWS 側の管理者が自由に設定できない場合は、手動プロビジョニングを採用することで、外部 ID プロバイダー側の運用負荷を少なくできる場合もあります。
組織インスタンスとアカウントインスタンスの違い
AWS IAM Identity Center には AWS Organizations 管理アカウントで有効化した「組織インスタンス」と単独の AWS アカウントで有効化した「アカウントインスタンス」の 2 種類があります。違いをまとめた表は下記となります。引用元のユーザーガイドの文言や掲載順番を一部変えて記載しています。
| 機能 | 組織インスタンス（推奨） | アカウントインスタンス | 補足説明 |
|---|---|---|---|
| ユーザーの管理 | ◯ | ◯ | - |
| AWS マネージドアプリケーションアクセスのための AWS アクセスポータル | ◯ | ◯ | Amazon CodeCatalyst などの特定のアプリケーションのみ対応 |
| OAuth 2.0 (OIDC) のカスタマー管理アプリケーション | ◯ | ◯ | - |
| SAML 2.0 のカスタマー管理アプリケーション | ◯ | - | - |
| マルチアカウント権限 | ◯ | - | AWS Organizations 配下の AWS アカウントへのアクセス管理 |
| AWS アカウントアクセスのための AWS アクセスポータル | ◯ | - | AWS Organizations 配下の AWS アカウントへのアクセス管理 |
| 委任された管理者によるインスタンス管理 | ◯ | - | - |
（引用元）Manage organization and account instances of IAM Identity Center - AWS IAM Identity Center
アカウントインスタンスでも利用できる、AWS マネージドアプリケーションとして AWS IAM Identity Center との統合に対応しているサービスには次のユーザーガイドに記載されています。
AWS managed applications - AWS IAM Identity Center
アカウントインスタンスについては、組織インスタンスとの違いを述べつつ紹介している次のブログが理解に役立ちます。
なお、AWS Organizations の管理アカウントで AWS IAM Identity Center を有効化する際には、組織インスタンスとアカウントインスタンスのどちらを有効化するかを選択できます。下記画像は管理アカウントで AWS IAM Identity Center を有効化を実行した場合に表示される画面です。
組織インスタンス利用時の委任における制限
AWS Organizations 管理アカウントで AWS IAM Identity Center 有効化した場合（組織インスタンスの場合）は、他のアカウントへ委任ができます。委任することで管理アカウント以外でも設定できるようになります。
注意点として、委任先のアカウントでは AWS IAM Identity Center の全ての機能を利用することはできません。具体的には、管理アカウントへのアクセス許可セットの割り当てや管理アカウントに割り当てたアクセス許可セットを他のアカウントに割り当てできない等の制約があります。これは、委任先アカウントにおいて管理アカウントへのアクセスをコントロールできる状態を防ぐためにあると思われます。
上記のため、管理アカウントアクセスに割り当てるアクセス許可セットと管理アカウント以外に割り当てるアクセス許可セットを分ける場合が分けたほうが管理しやすいことが多いです。
次のブログが本内容の理解の参考になります。
AWS Control Tower との関係性
以前は、AWS Control Tower を利用するときには Control Tower が管理する AWS IAM Identity Center のユーザーやアクセス許可セットが作成されていましたが、2023 年 6 月のアップデートにより、これらの連携の有効化・無効化をユーザーが選択できるようになりました。
連携を有効にした場合は管理用のユーザーと共に次のドキュメントに記載のアクセス許可セットが作成されます。
AWS Control Tower の IAM Identity Center グループ - AWS Control Tower
連携を無効にしている場合は、Control Tower が AWS IAM Identity Center にユーザー等を作成することはありません。
Control Tower 側の設定で連携の有効・無効を途中で変更することもできます。次のブログは連携を有効から無効に変更した例です。
一時的なアクセス許可を提供するソリューション
AWS IAM Identity Center の機能として提供されているわけではありませんが、AWS Samples において一時的にアクセスを許可する仕組みを提供するソリューション「Temporary Elevated Access Management (TEAM) 」が公開されています。
Temporary Elevated Access Management (TEAM)
TEAM をデプロイして試してみたブログもあります。
検証環境
AWS IAM Identity Center の組織インスタンスは AWS Organizations 内に 1 つのみの作成となるため、検証環境を用意する方法としては、検証用の AWS Organizations を用意する方法があります。
AWS Control Tower を利用している環境では、Control Tower のアップデートの検証用に別の AWS Organizations を用意することもあり、その環境と併用で AWS IAM Identity Center の検証環境を用意する場合もあります。
（余談）AWS IAM Identity Center の略称
AWS IAM Identity Center の略し方は人によって異なっている状況です。
例えば、次のような略し方を見かけたことがあります。
- AWS IDC, IDC
- AWS IIC, IIC
- AWS SSO (サービス名変更前の AWS Single Sign-On の略称をそのまま利用しているパターン)
- IAM Identity Center
私は略さない、または、IAM Identity Center を利用することが多いです（口頭ではたまに噛みます）。
なお、AWS Samples で公開されている AWS IAM Identity Center で一時的なアクセス許可を提供するソリューションである「TEAM」では、IDC と略されています。
さいごに
複数の AWS アカウントおよびアプリケーションへのアクセスを提供する AWS IAM Identity Center について紹介しました。
前回の入門ブログは、旧称の AWS Single Sign-On 時代のブログだったため、AWS IAM Identity Center として改めて入門ブログを書き直しました。AWS IAM Identity Center は 2022 年 6 月に AWS Single Sign-On から名称が変更されています。名称変更後しばらくは「AWS IAM Identity Center (旧 AWS SSO)」のような記載を続けていましたが、個人的には AWS IAM Identity Center も定着してきており、括弧書きの旧名称はいらないのではないかと思っています。
以上、「AWS 入門ブログリレー 2024」の 38 日目のエントリ「AWS IAM Identity Center」編でした。このブログがどなたかのご参考になれば幸いです。
次回、2024/5/9 は弊社 トクヤマシュン による「AWS Proton」の予定です！
7
