はじめに

この記事では、 AWS IAM Identity Center (以下、IIC ) について
初心者向けに以下を解説します。

IAM Identity Center とは何か
組織インスタンスとアカウントインスタンスの違い
各種機能
基本的な使い方（ハンズオン）

記事後半には、実際に有効化してみますので是非試してみてください。

AWS IAM Identity Center とは

以下２つを 一元管理できるサービス です。

「複数の AWS アカウント」「AWS マネージドアプリケーション」「外部アプリケーション」へのアクセス権限管理
「独自の IdP (Identity Center Directory)」or「外部 IdP と連携」によるユーザー管理

組織インスタンスとアカウントインスタンスの違い

IIC を有効化すると IIC インスタンスが作成されます。

インスタンスには 組織インスタンス と アカウントインスタンス があり、
アカウント種別によって作成有無が変わります。

	組織インスタンス	アカウントインスタンス
管理アカウント `※Organizations を有効化したアカウント`	〇	×
メンバーアカウント `※Organizations 配下のアカウント`	×	〇
スタンドアロンアカウント	×	〇

AWS としては 組織インスタンスの使用をベストプラクティス としています。
理由としては、IIC の一部機能が制限されるためです。（後述）

インスタンスは種別関係なく、アカウント毎に全リージョンで ** 1 つ** しか作成できません
Organizations 環境にて、管理アカウント側で組織インスタンスが存在する場合でも、条件を満たせばメンバーアカウント側にアカウントインスタンスを作成することは可能です

インスタンス種別による機能比較

IIC には以下に示す機能があります。
インスタンス種別により機能が制限されているのがわかります。
下記の制限を比較し、要件を満たせるのであればアカウントインスタンスの利用も考えられます。

「委任された管理者によるインスタンス管理」については、委任先のアカウントで、管理アカウントで可能な操作の一部が制限されるため△と記載しています

機能	管理アカウントの組織インスタンス	メンバーアカウント / スタンドアロンアカウントのアカウントインスタンス
ユーザーの管理	〇	〇
AWS マネージドアプリケーションへの SSO アクセス用アクセスポータル	〇	〇
OAuth 2.0 ( OIDC ) カスタマーマネージドアプリケーション	〇	〇
マルチアカウント権限	〇	×
AWS アカウントへの SSO アクセス用アクセスポータル	〇	×
SAML 2.0 カスタマーマネージドアプリケーション	〇	×
委任された管理者によるインスタンス管理	△	×

IDソースについて

インスタンスは、ID ソース( IdP )によりユーザー及びグループを管理します。
IdP として指定可能なのは以下の 2つです。

Identity Center Directory
Active Directory
外部 IdP

特に指定せずインスタンスを作成した場合は、デフォルトで IIC のインスタンス内部にもつ Identity Center Directory が IdP となります。

Active Directory に関して、SAMBA 4 ベースの Simple AD はサポートしていないことと、AWS Managed Microsoft AD を使用する場合は、インスタンスとリージョンを合わせる必要があります。

外部 IdP に関して、種類は割愛しますが以下のサイトに記載されている IdP が指定可能です。
SCIM プロトコルによる ID プロビジョニングと、SAML 2.0 プロトコルによるフェデレーションに対応可能であれば指定可能です。

アカウントインスタンスでも ID ソースとして外部 IdP を指定することは可能です

アプリケーションアクセスについて

IIC では、管理しているユーザー情報を用いて以下 2 つのアプリケーションへアクセスさせることが可能です。

AWS マネージドアプリケーション
カスタマーマネージドアプリケーション

AWS マネージドアプリケーション

Amazon Q Developer や Amazon QuickSight などの AWS サービスとして利用できるアプリケーションに対して、IIC のユーザー情報を用いてアクセス可能となります。
対応するアプリケーション一覧は以下の URL を参照してみてください。

上記 URL に記載のアプリケーションは「組織インスタンス」かつ「Identity Center Directory」であれば全てアクセス可能となります。
ただし以下の場合は、一部対象外となります。

アカウントインスタンスを利用
信頼できる ID の伝搬（つまり、IdP として Identity Center Directory 以外のものを利用する場合）

話は変わりますが、インスタンスを作成するリージョンと対象のアプリケーションのリージョンは一致させる必要があります。

多くの AWS マネージドアプリケーションは、IAM アイデンティティセンターが有効されているのと同じリージョンでのみ動作できます。

カスタマーマネージドアプリケーション

SalesForce や Slack などの外部アプリケーションを指します。
一覧が明記されている資料は見つけられませんでしたが、SAML 2.0 もしくは OAuth 2.0 に対応するアプリケーションが対象となります。

AWS IAM Identity Center を試してみよう

それでは実際に IIC を有効化していきましょう。

前提条件

前提条件は以下の通りです。

AWS Organizations が有効化されていること
メンバーアカウントが 1 つ以上存在すること
Organizations の全ての機能が有効化されていること

最終ゴール

今回はメンバーアカウントへのログインをゴールとします。
構成図としては以下の通りです。

実践

組織インスタンス作成

まずは管理アカウントにて IIC を有効化します。
リージョンは東京リージョンとします。
AdministratorAccess 権限を持った IAM ユーザーで作業していきます。

IIC サービスページにて「有効にする」を選択します。

適切なリージョンかを確認されるため、問題なければ「有効にする」を選択します。

数秒待つと、無事組織インスタンス作成完了メッセージが表示されます。

余談ですが、IIC が使用するサービスリンクロールが、組織インスタンス作成に伴って管理アカウント及びメンバーアカウントに作成されていました

ユーザー and グループ作成

続いてユーザーとグループを作成していきます。
後ほど作成する許可セットは、ユーザーもしくはグループに紐づけることができます。
そのためグループの作成は任意ですが、今回は作成したいと思います。

ここで言うユーザーとグループは、IAM ユーザーと IAM グループとは全く別物であるので混同しないようにご注意ください
そのためIAM サービスページでは確認できません
あくまで IdP で管理しているユーザーとグループになります
ちなみに、IIC ではユーザーのことをワークフォースユーザーと言います (グループはそのままの呼び名です)

まずグループから作成したいと思います。
サービスページ左ペインの「グループ」を選択します。

「グループを作成」を選択します。

「グループ名」に任意の名前を入力し「グループを作成」を選択します。

これでグループの作成は完了です。

続いてユーザーを作成していきます。
サービスページ左ペインの「ユーザー」を選択します。

「ユーザーを追加」を選択します。

プライマリ情報の各種項目を入力します。
こちらの項目は全て必須です。

その他の情報は任意のため今回は割愛し「次へ」を選択します。

今回はグループに追加するので、対象のグループにチェックを入れて「次へ」を選択します。

最終チェック画面にて問題なければ「ユーザーを追加」を選択します。

完了すると、ユーザー作成時に入力した E メールアドレスへ Invitation が届くため「Accept invitation」を選択します。

新規パスワード登録画面が開くため、パスワードを入力し「新しいパスワードを設定」を選択します。

成功するとログイン画面が表示されますが、一旦次の作業に進みたいと思います。

許可セット作成

続いて許可セットを作成していきます。
サービスページ左ペインの「許可セット」を選択します。

「許可セットを作成」を選択します。

許可セットのタイプには以下 2つがあります。

事前定義された許可セット
カスタム許可セット

今回は「事前定義された許可セット」を選択し「AdministratorAccess」にチェックを入れて「次へ」を選択します。

許可セットは、後の工程で実施する割り当てのタイミングで、メンバーアカウント側に IAM ロールを作成します
「事前定義された許可セット」は、AWS マネージドポリシーのみを使う場合選択します
「カスタム許可セット」は、AWS マネージドポリシーだけでなく、メンバーアカウント側のカスタマーマネージドポリシーを使いたい場合選択します

許可セットの詳細を入力します。
各項目は以下の通りです。
各項目を入力したら「次へ」を選択します。

項目	概要
許可セット名	● アクセスポータルに表示される名前 ● 「アカウント識別子-権限識別子」などにするとわかりやすいと思います
説明	● 許可セットの説明
セッション時間	● 許可セットで AWS アカウントにログインした際のセッション維持時間
リレー状態	● デフォルトではログイン先 AWS アカウントのホーム画面に切り替わるところを、本項目に指定したサービスページURLに直接切り替わる ● 例えば、許可セットがEC2サービスページで作業する用途の権限の場合は `https://console.aws.amazon.com/ec2/` などとすることで直接サービスページに遷移できる

最終チェック画面にて問題なければ「作成」を選択します。

作成完了のメッセージが表示されれば完了です。
また、プロビジョニングステータスが「プロビジョニングされていません」とありますが、こちらは次の工程であるアカウントへの割り当てを実施していないことを意味します。

アカウントへのユーザー/グループ及び許可セットの割り当て

最後に、アカウントへのユーザー/グループ及び許可セットの割り当てを実施します。
これは「どのユーザー or グループが」「どの権限セットを使って」「どのアカウントにログインさせるか」の設定を意味します。

サービスページ左ペインの「AWS アカウント」を選択します。

選択すると、Organizations で管理している OU 及びアカウント一覧が表示されます。
対象のアカウントにチェックを入れて「ユーザーまたはグループの割り当て」を選択します。

まず、ユーザーもしくはグループを選択します。
今回はグループ単位で割り当てたいので、対象のグループにチェックを入れて「次へ」を選択します。

続いて、許可セットを選択します。
作成済みの許可セットが表示されるので、割り当てたい許可セットにチェックを入れて「次へ」を選択します。

最終チェック画面にて問題なければ「送信」を選択します。

作成完了のメッセージが表示されれば完了です。

許可セットを見てみると「プロビジョニング済み」と変わっていますね。

余談ですが、許可セットを割り当てたタイミングで、割り当てたメンバーアカウント側に IAM ロールが作成されています
つまり、許可セットで指定した情報から、割り当てたメンバーアカウント側に IAM ロールを作成し、その IAM ロールにメンバーアカウント側の IAM ポリシーを割り当てていることになります