企業でAWSを利用する場合、社員一人ひとりにAWSアカウントやIAMユーザーを作成して管理する方法では、ユーザー数が増えるほど運用が複雑になります。
例えば、社員が100人いる企業でAWSを利用する場合、入社・異動・退職のたびにAWS側のユーザーや権限を変更していては、管理者の負担が大きくなります。
そこで活用されるのがAWS IAM Identity Centerです。
IAM Identity Centerを利用すると、企業がすでに利用しているActive Directory（AD）などのユーザー情報を利用してAWSへシングルサインオン（SSO）できるようになります。
さらに、AWS Organizationsと組み合わせることで、複数のAWSアカウントに対するユーザーやグループのアクセス権限を一元的に管理できます。
本記事では、AWS初心者向けにIAM Identity Centerの基本から、Active Directoryとの連携、認証の流れ、権限管理の仕組みまでを図解しながら解説します。
この記事でわかること
- AWS IAM Identity Centerとは何か
- 旧AWS Single Sign-On（AWS SSO）との関係
- Active Directoryとは何か
- IAM Identity CenterとActive Directoryを連携する理由
- AWS Managed Microsoft ADとオンプレミスActive Directoryの違い
- AD Connectorとは何か
- Active DirectoryからAWSへログインする仕組み
- IAM Identity CenterとIAMの違い
AWS IAM Identity Centerとは？
AWS IAM Identity Centerは、企業のユーザーやグループに対して、AWSアカウントやAWSアプリケーションへのアクセスを一元的に管理するためのサービスです。
以前はAWS Single Sign-On（AWS SSO）という名称でしたが、現在はAWS IAM Identity Centerという名称に変更されています。
IAM Identity Centerでは、ユーザーやグループに対して、AWS Organizationsで管理している複数のAWSアカウントへのアクセス権限を割り当てることができます。
例えば、次のような企業環境を考えてみましょう。
- 本番環境用AWSアカウント
- 開発環境用AWSアカウント
- 検証環境用AWSアカウント
- ログ管理用AWSアカウント
IAM Identity Centerを利用すると、社員の所属するグループに応じて、それぞれのAWSアカウントへのアクセス権限を設定できます。
| ユーザー・グループ | アクセス先 | 付与する権限 |
|---|---|---|
| 開発部 | 開発アカウント | 開発者権限 |
| 運用部 | 本番アカウント | 運用管理者権限 |
| 監査部 | 全アカウント | 読み取り専用 |
このように、ユーザー単位だけでなくグループ単位でアクセス権限を割り当てられることが、IAM Identity Centerの大きな特徴です。
IAM Identity CenterとAWS SSOの関係
IAM Identity Centerについて調べていると、「AWS SSO」という名称を見かけることがあります。
これは別のサービスではありません。
AWS Single Sign-On（AWS SSO）が現在のAWS IAM Identity Centerです。
| 以前の名称 | 現在の名称 |
|---|---|
| AWS Single Sign-On（AWS SSO） | AWS IAM Identity Center |
そのため、古いAWS教材や過去の記事では「AWS SSO」と書かれている場合があります。
なぜActive Directoryと連携するのか？
企業では、すでにActive Directoryを利用して社員のアカウントを管理しているケースが数多くあります。
例えば、社員がWindows PCへログインするときに利用するユーザー名やパスワードをActive Directoryで管理している企業があります。
このような企業がAWSを導入するたびに、AWS側へ別のユーザーアカウントを作成すると、ユーザー管理が二重になってしまいます。
そこで、IAM Identity CenterとActive Directoryを連携します。
Active DirectoryをIAM Identity Centerのアイデンティティソースとして利用することで、既存の企業ユーザーやグループをAWSへのアクセス管理に利用できます。
AWS公式ドキュメントでも、既存のActive Directoryを利用している場合、そのディレクトリをIAM Identity Centerへ接続し、ADユーザーやグループへAWSアカウントやアプリケーションへのアクセス権を割り当てる方法が案内されています。
Active Directoryとは？
Active Directory（AD）は、Microsoftが提供する企業向けのディレクトリサービスです。
企業では、社員のユーザーアカウントやグループ、コンピューターなどを集中管理するために利用されています。
例えば、次のような情報を管理できます。
| 管理対象 | 例 |
|---|---|
| ユーザー | 田中さん、佐藤さん |
| グループ | 開発部、運用部、営業部 |
| コンピューター | 社員PC、サーバー |
| 認証情報 | ユーザー名、パスワード |
つまり、Active Directoryは「会社の社員アカウントを管理する基盤」と考えると分かりやすいでしょう。
IAM Identity Centerのアイデンティティソースとは？
IAM Identity Centerでは、「どこでユーザーやグループを管理するのか」をアイデンティティソースとして設定します。
現在のIAM Identity Centerでは、主に次の3つの選択肢があります。
| アイデンティティソース | 概要 |
|---|---|
| IAM Identity Centerディレクトリ | IAM Identity Center内でユーザー・グループを管理 |
| Active Directory | 既存のActive Directoryを利用 |
| 外部IdP | Microsoft Entra ID、Oktaなどを利用 |
つまり、IAM Identity Center自体が必ずユーザーを管理するわけではありません。
企業ですでにActive Directoryを利用している場合は、Active Directoryをアイデンティティソースとして接続することができます。
Active Directoryとの連携方法
Active DirectoryをIAM Identity Centerへ接続する場合、大きく次のような構成があります。
- 既存のオンプレミスActive Directoryを利用する
- AWS Managed Microsoft ADを利用する
- AD Connectorを利用して既存のActive Directoryへ接続する
ここで重要なのが、AWS Managed Microsoft ADとAD Connectorは同じものではないという点です。
AWS Managed Microsoft ADとは？
AWS Managed Microsoft ADは、AWS上で提供されるマネージド型のMicrosoft Active Directoryです。
AWSがActive Directoryのインフラ運用を管理するため、企業側でドメインコントローラーをAWS上に構築・運用する負担を軽減できます。
AWS Directory Serviceのサービスの一つとして提供されています。
| 項目 | AWS Managed Microsoft AD |
|---|---|
| ADの場所 | AWS上 |
| 運用 | AWSがマネージドサービスとして提供 |
| Active Directory | Microsoft ADを利用 |
| 利用例 | AWS上の企業システム・IAM Identity Centerなど |
AD Connectorとは？
AD Connectorは、既存のActive DirectoryをAWSのサービスから利用するためのプロキシとして機能するサービスです。
重要なのは、AD Connector自体が新しいActive Directoryを作るわけではないということです。
既存のオンプレミスActive Directoryをそのまま利用し、AWS側のサービスと既存ADとの接続を提供します。
AWS公式ドキュメントでも、AD Connectorでは既存の企業Active Directoryへ接続し、ディレクトリデータ自体はドメインコントローラー側に残ると説明されています。
| 項目 | AWS Managed Microsoft AD | AD Connector |
|---|---|---|
| ADの管理場所 | AWS | 既存のActive Directory |
| 新しいADを構築 | 〇 | × |
| 既存ADを利用 | △（信頼関係などを利用可能） | 〇 |
| 主な役割 | AWS上のマネージドAD | 既存ADへの接続 |
Active DirectoryとIAM Identity Centerの全体像
ここまでの内容を一度整理しましょう。
企業のActive DirectoryをIAM Identity Centerへ接続すると、次のような関係になります。
- 社員のユーザー情報をActive Directoryで管理する
- Directory Serviceを介してActive DirectoryとIAM Identity Centerを接続する
- ADのユーザーやグループ情報をIAM Identity Centerのアイデンティティストアへ同期する
- IAM Identity CenterでAWSアカウントへのアクセス権限を割り当てる
- ユーザーがAWSアクセスポータルへサインインする
- 割り当てられたAWSアカウントやロールへアクセスする
このように、「ユーザー管理」と「AWSへのアクセス権限管理」を分離できることが大きなメリットです。
Active DirectoryのパスワードはIAM Identity Centerへ同期されるのか？
ここは非常に重要なポイントです。
Active DirectoryをIAM Identity Centerのアイデンティティソースとして利用した場合、Active Directoryのパスワード情報そのものがIAM Identity Centerへ同期されるわけではありません。
AWS公式ドキュメントでは、Active Directoryからユーザー・グループ・メンバーシップなどの情報がIAM Identity Centerのアイデンティティストアへ同期される一方、パスワード情報は同期されず、認証はソースとなるActive Directoryに対して直接行われると説明されています。
重要ポイント
ユーザー情報・グループ情報はIAM Identity Center側へ同期されるが、パスワード情報は同期されない。
認証そのものはActive Directoryを利用して行われます。
Active DirectoryのユーザーがAWSへログインする流れ
ここからは、実際にActive Directoryで管理されている社員が、IAM Identity Centerを利用してAWSへログインする流れを確認していきましょう。
企業環境では、ユーザー認証とAWSのアクセス権限を別々に管理することが重要です。
IAM Identity Centerを利用すると、次のような流れでAWSへアクセスできます。
- 社員がAWSアクセスポータルへアクセスする
- Active Directoryの認証情報を利用してログインする
- IAM Identity Centerがユーザーを認証する
- ユーザーに割り当てられているAWSアカウントを表示する
- ユーザーがアクセスするAWSアカウントを選択する
- 利用するPermission Set（アクセス許可セット）を選択する
- Permission Setに対応するIAMロールを引き受ける
- 付与された権限の範囲内でAWSサービスを利用する
この流れを理解すると、IAM Identity Centerが単なる「ログイン画面」ではなく、ユーザー認証とAWSアカウントへのアクセス権限を仲介するサービスであることが分かります。
AWSアクセスポータルとは？
IAM Identity Centerを利用するユーザーは、通常のAWS Management Consoleへ直接ログインするのではなく、AWSアクセスポータルからアクセスします。
AWSアクセスポータルは、ユーザーがアクセスを許可されているAWSアカウントやアプリケーションを一覧から選択できる入口です。
AWS公式ドキュメントでは、AWSアクセスポータルからユーザーがAWSアカウントを選択し、そのアカウントに割り当てられたロールを選択してAWS Management Consoleへアクセスする仕組みが説明されています。
ポイント
AWSアクセスポータルは、通常のAWS Management Consoleとは異なります。
- AWSアクセスポータル：ユーザーがアクセス先のAWSアカウントやロールを選択する入口
- AWS Management Console：EC2、S3、VPCなどのAWSサービスを操作する管理画面
Permission Set（アクセス許可セット）とは？
IAM Identity Centerを理解するうえで、非常に重要なのがPermission Set（アクセス許可セット）です。
Permission Setは、ユーザーやグループがAWSアカウント内でどのような操作を許可されるのかを定義するテンプレートです。
例えば、次のようなPermission Setを作成できます。
| Permission Set | 想定ユーザー | 権限の例 |
|---|---|---|
| Administrator | AWS管理者 | AWSリソースを幅広く管理 |
| PowerUser | 開発者 | 幅広いAWSサービスを利用 |
| ReadOnly | 監査担当者 | AWSリソースの参照 |
| NetworkAdministrator | ネットワーク担当者 | VPCなどのネットワーク管理 |
Permission Setには、AWS管理ポリシーやカスタマー管理ポリシー、インラインポリシーなどを設定できます。
つまり、Permission Setは「AWSアカウントで何ができるのかを定義した権限セット」と考えると分かりやすいでしょう。
Permission SetとIAMポリシーの関係
ここで注意したいのが、Permission SetとIAMポリシーは同じものではないという点です。
Permission Setは、ユーザーやグループにAWSアカウントへのアクセス権限を割り当てるための仕組みです。
その中にIAMポリシーを指定することで、実際に許可されるAWS操作を定義します。
イメージとしては、次のように考えると分かりやすいでしょう。
Permission Set
「このユーザー・グループを、このAWSアカウントで、このレベルの権限で利用させる」
↓
IAMポリシー
「その権限で、具体的にどのAWS API操作を許可するか」
AWS公式ドキュメントでも、Permission Setは1つ以上のIAMポリシーをまとめて定義するテンプレートとして説明されています。
Permission SetをAWSアカウントへ割り当てる
Permission Setを作成しただけでは、すぐにユーザーがAWSアカウントへアクセスできるわけではありません。
ユーザーまたはグループとAWSアカウントを関連付け、そのうえでPermission Setを割り当てる必要があります。
例えば、次のような企業を考えてみましょう。
| ADグループ | AWSアカウント | Permission Set |
|---|---|---|
| 開発部 | 開発環境 | PowerUser |
| 開発部 | 本番環境 | ReadOnly |
| 運用部 | 本番環境 | Administrator |
| 監査部 | 本番環境 | ReadOnly |
このようにすると、同じ社員であっても、アクセスするAWSアカウントによって異なる権限を与えることができます。
💼 実務ではこう使われる
例えば開発者に「開発環境では幅広い操作を許可するが、本番環境では参照だけ許可する」という設計ができます。
これにより、開発者が誤って本番環境のリソースを変更してしまうリスクを低減できます。
なぜグループ単位で権限を割り当てるのか？
IAM Identity Centerでは、ユーザー一人ひとりに個別の権限を設定することもできます。
しかし、企業環境ではグループ単位で権限を割り当てる方法が推奨されます。
例えば、社員が100人いる企業で、全員に個別に権限を設定すると管理が非常に大変です。
そこで、Active Directoryのグループを利用します。
| ADグループ | Permission Set | AWSアカウント |
|---|---|---|
| AWS-Developers | PowerUser | 開発アカウント |
| AWS-Operations | Administrator | 本番アカウント |
| AWS-Auditors | ReadOnly | 全アカウント |
社員が異動した場合も、Active Directory側の所属グループを変更することで、AWSへのアクセス権限を変更できます。
AWS公式ドキュメントでも、個々のユーザーではなくグループへアクセス権限を割り当てることで、権限管理を簡素化する方法が推奨されています。
Permission Setを割り当てるとIAMロールが作成される
ここがSAA試験で特に重要なポイントです。
IAM Identity CenterでPermission SetをAWSアカウントへ割り当てると、対象AWSアカウントにはIAM Identity Centerが管理するIAMロールが作成されます。
つまり、Permission SetそのものがAWSサービスを操作しているわけではありません。
Permission Setに定義されたポリシーをもとにIAMロールが作成され、そのIAMロールをユーザーが引き受けることでAWSリソースを操作します。
AWS公式ドキュメントでは、Permission SetをAWSアカウントへ割り当てると、各アカウントに対応するIAMロールが作成され、Permission Setに指定されたポリシーがそのロールへアタッチされる仕組みが説明されています。
📌 SAA試験で重要
Permission Set → IAMロール → AWSリソース
この関係を覚えておきましょう。
Permission Setを割り当てることで、対象AWSアカウントにIAM Identity Centerが管理するIAMロールが作成されます。
「AWSReservedSSO_」から始まるIAMロールとは？
AWSアカウントのIAMロール一覧を確認すると、次のような名前のロールを見かけることがあります。
AWSReservedSSO_Administrator_1234567890abcdefこれは、IAM Identity Centerによって作成・管理されるIAMロールです。
IAM Identity CenterでPermission SetをAWSアカウントへ割り当てると、このようなIAMロールが作成されます。
そのため、IAM Identity Centerを利用しているAWSアカウントでこのロールを見つけても、通常のIAMユーザーが手動で作成したロールとは区別して考える必要があります。
覚えておきたいポイント
AWSReservedSSO_で始まるロールは、IAM Identity Centerによって作成・管理されるIAMロールです。
AWS Organizationsとの連携
IAM Identity Centerの大きなメリットの一つが、AWS Organizationsと連携して複数のAWSアカウントを一元管理できることです。
企業では、AWSアカウントを1つだけ利用するとは限りません。
例えば、次のように環境ごとにAWSアカウントを分けることがあります。
- 管理アカウント
- 本番環境アカウント
- 開発環境アカウント
- 検証環境アカウント
- ログ管理アカウント
- セキュリティアカウント
AWS Organizationsを利用すると、これらのAWSアカウントを組織としてまとめて管理できます。
さらにIAM Identity Centerを利用することで、ユーザーやグループに対して複数のAWSアカウントへのアクセス権限を一元的に割り当てられます。
複数AWSアカウントを一元管理するイメージ
例えば、次のような構成を考えてみましょう。
| ユーザーグループ | 開発アカウント | 本番アカウント | 監査アカウント |
|---|---|---|---|
| 開発部 | PowerUser | ReadOnly | ReadOnly |
| 運用部 | Administrator | Administrator | ReadOnly |
| 監査部 | ReadOnly | ReadOnly | ReadOnly |
このような権限設計により、「誰が」「どのAWSアカウントへ」「どの程度の権限でアクセスできるのか」を整理できます。
IAM Identity Centerでは、ユーザーやグループに対してAWSアカウントとPermission Setを組み合わせて割り当てることで、このようなアクセス制御を実現します。
最小権限の原則を適用する
IAM Identity Centerを利用する場合も、基本的なセキュリティ原則である最小権限の原則（Principle of Least Privilege）が重要です。
「とりあえずAdministratorAccessを付与する」という設計は避け、ユーザーが実際に必要とする操作だけを許可することが望ましいです。
例えば、監査担当者がAWSリソースの状態を確認するだけであれば、管理者権限を与える必要はありません。
| 担当者 | 必要な操作 | 適した権限 |
|---|---|---|
| 監査担当 | リソースを確認する | ReadOnly |
| 開発者 | 開発環境を操作する | 必要な開発権限 |
| 運用担当 | 本番環境を管理する | 必要な管理権限 |
AWS公式ドキュメントでも、必要以上の権限を付与せず、利用目的に応じてより制限されたPermission Setを作成することが推奨されています。
認証と認可を分けて考える
IAM Identity Centerを理解するためには、認証（Authentication）と認可（Authorization）を分けて考えることが重要です。
| 用語 | 意味 | この構成で担当するもの |
|---|---|---|
| 認証 | 「あなたは誰ですか？」 | Active Directoryなど |
| 認可 | 「あなたは何をしてよいですか？」 | IAM Identity Center / Permission Set / IAMロール |
例えば、社員がActive Directoryのアカウントとパスワードでログインできたとしても、それだけで全AWSアカウントを自由に操作できるわけではありません。
IAM Identity Center側で、そのユーザーまたはグループにどのAWSアカウントへのアクセスを許可するのか、さらにどのPermission Setを利用できるのかを設定する必要があります。
IAM Identity Centerを利用したアクセスの全体フロー
ここまでの内容を、実際のアクセスフローとして整理します。
Active Directory
社員のユーザー・グループを管理します。
IAM Identity Center
ADをアイデンティティソースとして利用し、ユーザーやグループをAWSへのアクセス管理に利用します。
AWS Organizations
複数のAWSアカウントを組織として管理します。
Permission Set
ユーザーやグループがAWSアカウントで利用できる権限を定義します。
IAMロール
Permission Setをもとに、対象AWSアカウント内にIAM Identity Center管理のロールが作成されます。
AWSリソース
ユーザーはIAMロールの権限範囲内でEC2、S3、RDS、VPCなどのAWSサービスを操作します。
IAM Identity CenterとIAMは何が違う？
ここまで読んで、「IAM Identity CenterとIAMはどちらもAWSのアクセス権限を管理するサービスなのでは？」と疑問に思った方もいるでしょう。
実際、両者には共通する部分がありますが、対象とするユーザーや管理方法が異なります。
| 項目 | AWS IAM | AWS IAM Identity Center |
|---|---|---|
| 主な対象 | AWSリソース・AWSアカウントのアクセス管理 | 企業のユーザー・グループ |
| 主な用途 | IAMユーザー・IAMロール・ポリシーによるアクセス制御 | 複数AWSアカウントへのSSO |
| ユーザー管理 | IAMユーザーなど | IAM Identity Centerユーザー・外部IdPなど |
| 複数AWSアカウント | アカウントごとに管理 | AWS Organizationsと連携して一元管理 |
| 企業のSSO | 主目的ではない | 主要な用途 |
AWS公式ドキュメントでも、IAMユーザーは個々のAWSアカウント内のユーザーとして扱われる一方、IAM Identity Centerは組織内の複数AWSアカウントで利用するワークフォースユーザーを管理する仕組みとして整理されています。
IAMユーザーを大量に作る方法との違い
例えば、AWSアカウントを10個運用している企業で、100人の社員それぞれにIAMユーザーを作成するとどうなるでしょうか。
単純計算でも、AWSアカウントごとにユーザーを管理する必要があり、アカウント数や社員数が増えるほど管理が複雑になります。
さらに、社員の異動や退職が発生するたびに、それぞれのAWSアカウントで権限を変更する必要があります。
IAM Identity Centerを利用すれば、ユーザーやグループへのアクセス権限を中央で管理し、複数のAWSアカウントへ割り当てることができます。
AWS OrganizationsとIAM Identity Centerを組み合わせることで、各AWSアカウントへ個別にIAMユーザーを作成する運用から、組織全体での一元的なアクセス管理へ移行できます。
💼 実務ではこう考える
「人がAWSコンソールへログインする」という用途では、まずIAM Identity CenterによるSSOを検討します。
一方、AWSリソースそのものに権限を与える場合はIAMロールやIAMポリシーを利用します。
IAM Identity CenterではIAMユーザーを作らないの？
ここも混同しやすいポイントです。
IAM Identity Centerを利用してAWSアカウントへアクセスするユーザーについて、通常のIAMユーザーをAWSアカウントごとに作成する必要はありません。
IAM Identity Centerでは、ユーザーやグループへPermission Setを割り当て、そのPermission SetをもとにIAM Identity Center管理のIAMロールを対象AWSアカウントへ作成します。
ユーザーはそのIAMロールを利用してAWSリソースへアクセスします。
| 方式 | ユーザー管理 | AWSアカウントへのアクセス |
|---|---|---|
| IAMユーザー | AWSアカウントごとにIAMユーザーを管理 | IAMユーザーの権限を利用 |
| IAM Identity Center | Identity Centerや外部IdPで管理 | Permission Set → IAMロール |
📌 SAA試験ポイント
「社員がAWS Management Consoleへログインするために、大量のIAMユーザーを作成する」という設計が出てきた場合、IAM Identity CenterによるSSOが適切か検討します。
IAMユーザーは長期的な認証情報を持つため、人間のユーザー管理ではIAM Identity CenterやIAMロールを利用する設計が重要になります。
Active Directory・IAM Identity Center・IAMの役割分担
ここまでの内容を、3つのサービス・仕組みに分けて整理してみましょう。
| 仕組み | 担当する役割 |
|---|---|
| Active Directory | 企業ユーザー・グループの管理、ユーザー認証 |
| IAM Identity Center | AWSへのSSO、AWSアカウントへのアクセス管理 |
| Permission Set | AWSアカウント内で必要な権限を定義 |
| IAMロール | 実際にAWSリソースへアクセスするための権限主体 |
| IAMポリシー | 具体的なAWS API操作の許可・拒否を定義 |
この役割分担を理解すると、IAM Identity Centerの仕組みがかなり分かりやすくなります。
一言で覚えるなら
- Active Directory：社員を管理する
- IAM Identity Center：社員をAWSへ入れる
- Permission Set：AWSでの権限を決める
- IAMロール：その権限でAWSを操作する
- IAMポリシー：具体的な操作内容を決める
SAML 2.0とは？
Active Directoryや外部の認証基盤とAWSを連携する際には、SAML 2.0という用語が登場します。
SAML（Security Assertion Markup Language）は、異なるシステム間で認証情報を連携するための標準規格です。
簡単に言えば、
「このユーザーは認証済みのユーザーです」
という情報を、認証を担当するシステムからサービス側へ安全に伝えるために利用されます。
IAM Identity CenterではSAML 2.0を利用した外部IdPとのフェデレーションに対応しています。
AWS公式ドキュメントでは、IAM Identity CenterがSAML 2.0による認証フェデレーションをサポートしており、外部IdPの既存認証情報を利用してAWSアクセスポータルへSSOできる仕組みが説明されています。
IdPとSPとは？
SAMLを理解するときに、IdPとSPという言葉がよく登場します。
| 用語 | 正式名称 | 役割 |
|---|---|---|
| IdP | Identity Provider | ユーザーを認証する側 |
| SP | Service Provider | 認証されたユーザーにサービスを提供する側 |
例えば企業がMicrosoft Entra IDなどの外部IdPを利用している場合、そのIdPで認証されたユーザーがIAM Identity Centerを経由してAWSへアクセスする構成を作ることができます。
この場合、ユーザーの認証を企業側のIdPで行い、AWS側ではその認証結果を利用してSSOを実現します。
SCIMとは？
SAMLとセットで覚えておきたいのがSCIM（System for Cross-domain Identity Management）です。
SCIMは、ユーザーやグループなどのID情報をシステム間でプロビジョニングするための標準規格です。
ここで、SAMLとSCIMの役割を分けて考えることが重要です。
| 技術 | 主な役割 |
|---|---|
| SAML 2.0 | ユーザー認証・SSO |
| SCIM | ユーザー・グループ情報のプロビジョニング |
例えば、企業のIdPで新しい社員が登録された場合、SCIMを利用してIAM Identity Centerへユーザー情報を自動的にプロビジョニングできます。
逆に社員が退職した場合には、IdP側のユーザー削除をIAM Identity Centerへ反映し、AWSへのアクセスを停止する運用も可能です。
AWS公式ドキュメントでは、IAM Identity CenterがSCIM v2.0をサポートし、ユーザーの作成・更新・削除などをIdPと同期できる仕組みが説明されています。
📌 SAA試験対策
SAML＝認証・SSO
SCIM＝ユーザー・グループ情報のプロビジョニング
この組み合わせは非常に重要です。
Active Directoryと外部IdPは同じもの？
ここまでActive Directoryについて説明してきましたが、企業によってはActive Directoryではなく、Microsoft Entra IDやOktaなどのクラウド型IdPを利用している場合があります。
IAM Identity Centerでは、こうした外部IdPとの連携にも対応しています。
| 環境 | 認証基盤の例 | IAM Identity Centerとの連携 |
|---|---|---|
| オンプレミス中心 | Active Directory | Directory Serviceなどを利用 |
| AWS上のAD | AWS Managed Microsoft AD | 直接連携可能 |
| クラウドIdP | Microsoft Entra ID | SAML / SCIM |
| クラウドIdP | Okta | SAML / SCIM |
そのため、「IAM Identity Center＝Active Directory専用のサービス」と考えてはいけません。
IAM Identity Centerは、企業の既存のアイデンティティ基盤とAWSを接続するための中心的な仕組みとして利用できます。
企業環境での代表的な構成
ここまでの内容を、企業でよくある構成として整理します。
例えば、オンプレミスにActive Directoryが存在し、AWS側に複数のAWSアカウントが存在する企業では、次のような構成が考えられます。
- Active Directoryで社員とグループを管理
- Directory Serviceを利用してAWS側からActive Directoryへ接続
- IAM Identity Centerを有効化
- Active Directoryをアイデンティティソースとして設定
- AWS Organizationsで複数AWSアカウントを管理
- ADグループへAWSアカウントとPermission Setを割り当てる
- 社員がAWSアクセスポータルへログイン
- 対象AWSアカウントとロールを選択
- IAM Identity Centerが管理するIAMロールを利用してAWSリソースへアクセス
この構成にすることで、社員の入社・異動・退職に伴うAWSアクセス権限の管理を効率化できます。
退職者のAWSアクセスを停止する場合
IAM Identity CenterとActive Directoryを連携するメリットは、退職者のアクセス制御にもあります。
例えば社員が退職した場合、Active Directory側でユーザーを無効化すると、そのユーザーによる認証を停止できます。
さらに外部IdPとの連携でSCIMを利用している場合には、ユーザーの削除や無効化をIAM Identity Center側へ反映させることもできます。
これにより、AWSアカウントごとに退職者のIAMユーザーを探して削除するような運用を減らせます。
💼 実務で重要な考え方
企業のID管理では、「人事異動や退職によってユーザーの所属・状態が変化したとき、それをAWSへどのように反映するか」が重要です。
IAM Identity Centerを既存のID基盤と連携することで、AWSのアクセス権限を組織のユーザー管理と連動させやすくなります。
SAAで混同しやすいポイント
① IAM Identity CenterとIAMは同じではない
IAM Identity Centerは企業ユーザーのAWSへのSSOアクセスを一元管理するサービスです。
IAMはAWSリソースへのアクセス制御を提供するサービスであり、IAMユーザー、IAMロール、IAMポリシーなどを管理します。
② Permission SetとIAMロールは同じではない
Permission SetはIAM Identity Center側で管理する権限のテンプレートです。
AWSアカウントへPermission Setを割り当てると、それに対応するIAM Identity Center管理のIAMロールが対象アカウントに作成されます。
③ SAMLとSCIMを混同しない
SAMLは主に認証・SSO、SCIMはユーザー・グループ情報のプロビジョニングに利用します。
④ Active DirectoryとAWS Managed Microsoft ADを混同しない
AWS Managed Microsoft ADはAWSが提供するマネージド型のMicrosoft Active Directoryです。
一方、既存のオンプレミスActive DirectoryをAWSから利用する場合には、AD Connectorなどを利用する構成があります。
⑤ IAM Identity Centerは「AWSアカウントそのもの」を作るサービスではない
AWSアカウントの作成・組織管理を担当するのはAWS Organizationsです。
IAM Identity Centerは、Organizationsで管理されているAWSアカウントに対して、ユーザーやグループのアクセス権限を一元的に割り当てる役割を担います。
IAM Identity Center・Organizations・Active Directoryの違い
| サービス・仕組み | 主な役割 |
|---|---|
| Active Directory | 企業ユーザー・グループの管理、認証 |
| AWS IAM Identity Center | AWSへのSSOとアクセス権限の一元管理 |
| AWS Organizations | 複数AWSアカウントの組織管理 |
| Permission Set | AWSアカウント内での権限を定義 |
| AWS IAM | AWSリソースへのアクセス制御 |
IAM Identity Centerの仕組みを一枚で整理
最後に、この記事で解説した内容を一つの流れにまとめます。
まとめ
AWS IAM Identity Centerは、企業のユーザーが複数のAWSアカウントへ安全かつ効率的にアクセスするための重要なサービスです。
Active Directoryなどの既存の認証基盤と連携することで、社員のユーザー情報を活用しながらAWSへのSSOを実現できます。
特に重要なのは、次の関係です。
Active Directory
↓
IAM Identity Center
↓
AWS Organizations
↓
Permission Set
↓
IAMロール
↓
AWSリソース
また、SAA試験では「SAML＝認証・SSO」「SCIM＝ユーザー・グループ情報のプロビジョニング」という違いも押さえておきましょう。
IAM Identity Center、IAM、Active Directory、AWS Organizationsはそれぞれ役割が異なります。
「誰を管理するのか」「どのAWSアカウントへアクセスできるのか」「そのアカウントで何ができるのか」を分けて考えると、企業向けAWS認証・認可の仕組みを理解しやすくなります。