はじめに
この記事では、 AWS IAM Identity Center (以下、IdC) について
初心者向けに以下を解説します。
- IAM Identity Centerとは何か
- 組織インスタンスとアカウントインスタンスの違い
- 各種機能
- 基本的な使い方（ハンズオン）
記事後半には、実際に有効化してみますので是非試してみてください。
AWS IAM Identity Center とは
以下２つを 一元管理できるサービス です。
- 「複数のAWSアカウント」「AWSマネージドアプリケーション」「外部アプリケーション」へのアクセス権限管理
- 「独自のIdP (Identity Center Directory)」or「外部IdPと連携」によるユーザー管理
組織インスタンスとアカウントインスタンスの違い
IdC を有効化するとIdCインスタンスが作成されます。
インスタンスには 組織インスタンス と アカウントインスタンス があり、
アカウント種別によって作成有無が変わります。
| 組織インスタンス | アカウントインスタンス | |
|---|---|---|
管理アカウント ※Organizations を有効化したアカウント
|
〇 | × |
メンバーアカウント ※Organizations 配下のアカウント
|
× | 〇 |
| スタンドアロンアカウント | × | 〇 |
AWS としては 組織インスタンスの使用をベストプラクティス としています。
理由としては、IdC の一部機能が制限されるためです。（後述）
- インスタンスは種別関係なく、アカウント毎に全リージョンで 1つ しか作成できません
- Organizations 環境にて、管理アカウント側で組織インスタンスが存在する場合でも、条件を満たせばメンバーアカウント側にアカウントインスタンスを作成することは可能です
インスタンス種別による機能比較
IdC には以下に示す機能があります。
インスタンス種別により機能が制限されているのがわかります。
下記の制限を比較し、要件を満たせるのであればアカウントインスタンスの利用も考えられます。
「委任された管理者によるインスタンス管理」については、委任先のアカウントで、管理アカウントで可能な操作の一部が制限されるため△と記載しています
| 機能 | 管理アカウントの 組織インスタンス |
メンバーアカウント / スタンドアロンアカウントの アカウントインスタンス |
|---|---|---|
| ユーザーの管理 | 〇 | 〇 |
| AWS マネージドアプリケーションへの SSOアクセス用アクセスポータル |
〇 | 〇 |
| OAuth2.0 (OIDC) カスタマーマネージドアプリケーション | 〇 | 〇 |
| マルチアカウント権限 | 〇 | × |
| AWS アカウントへの SSOアクセス用アクセスポータル |
〇 | × |
| SAML 2.0 カスタマーマネージドアプリケーション | 〇 | × |
| 委任された管理者によるインスタンス管理 | △ | × |
IDソースについて
インスタンスは、ID ソース( IdP )によりユーザー及びグループを管理します。
IdP として指定可能なのは以下の 2つ です。
- Identity Center Directory
- Active Directory
- 外部IdP
特に指定せずインスタンスを作成した場合は、デフォルトで Identity Center Directory が IdP となります。
Active Directory に関して、SAMBA4 ベースの Simple AD はサポートしていないことと、AWS Managed Microsoft AD を使用する場合は、インスタンスとリージョンを合わせる必要があります。
外部 IdP に関して、種類は割愛しますが以下のサイトに記載されている IdP が指定可能です。
SCIM プロトコルによる ID プロビジョニングと、SAML 2.0 プロトコルによるフェデレーションに対応可能であれば指定可能です。
アカウントインスタンスでも ID ソースとして外部 IdP を指定することは可能です
アプリケーションアクセスについて
IdC では、管理しているユーザー情報を用いて以下 2つ のアプリケーションへアクセスさせることが可能です。
- AWS マネージドアプリケーション
- カスタマーマネージドアプリケーション
AWS マネージドアプリケーション
Amazon Q Developer や Amazon QuickSight などの AWS サービスとして利用できるアプリケーションに対して、IdC のユーザー情報を用いてアクセス可能となります。
対応するアプリケーション一覧は以下の URL を参照してみてください。
上記 URL に記載のアプリケーションは「組織インスタンス」かつ「Identity Center Directory」であれば全てアクセス可能となります。
ただし以下の場合は、一部対象外となります。
- アカウントインスタンスを利用
- 信頼できる ID の伝搬（つまり、IdP としてIdentity Center Directory 以外のものを利用する場合）
話は変わりますが、インスタンスを作成するリージョンと対象のアプリケーションのリージョンは一致させる必要があります。
多くの AWS マネージドアプリケーションは、IAM アイデンティティセンターが有効されているのと同じリージョンでのみ動作できます。
カスタマーマネージドアプリケーション
SalesForce や Slack などの外部アプリケーションを指します。
一覧が明記されている資料は見つけられませんでしたが、SAML 2.0 もしくは OAuth 2.0 に対応するアプリケーションが対象となります。
AWS IAM Identity Center を試してみよう
それでは実際に IdC を有効化していきましょう。
前提条件
前提条件は以下の通りです。
- AWS Organizations が有効化されていること
- メンバーアカウントが 1つ 以上存在すること
- Organizations の全ての機能が有効化されていること
最終ゴール
今回はメンバーアカウントへのログインをゴールとします。
構成図としては以下の通りです。
実践
組織インスタンス作成
まずは管理アカウントにて IdC を有効化します。
リージョンは東京リージョンとします。
AdministratorAccess 権限を持った IAM ユーザーで作業していきます。
IdC サービスページにて「有効にする」を選択します。
適切なリージョンかを確認されるため、問題なければ「有効にする」を選択します。
数秒待つと、無事組織インスタンス作成完了メッセージが表示されます。
余談ですが、IdC が使用するサービスリンクロールが、組織インスタンス作成に伴って管理アカウント及びメンバーアカウントに作成されていました
ユーザー and グループ作成
続いてユーザーとグループを作成していきます。
後ほど作成する許可セットは、ユーザー もしくは グループに紐づけることができます。
そのためグループの作成は任意ですが、今回は作成したいと思います。
- ここで言うユーザーとグループは、IAM ユーザー と IAM グループとは全く別物であるので混同しないようにご注意ください
- そのためIAM サービスでは確認できません
- あくまで IdC で管理しているユーザーとグループになります
まずグループから作成したいと思います。
サービスページ左ペインの「グループ」を選択します。
「グループを作成」を選択します。
「グループ名」に任意の名前を入力し「グループを作成」を選択します。
これでグループの作成は完了です。
続いてユーザーを作成していきます。
サービスページ左ペインの「ユーザー」を選択します。
「ユーザーを追加」を選択します。
プライマリ情報の各種項目を入力します。
こちらの項目は全て必須です。
その他の情報は任意のため今回は割愛し「次へ」を選択します。
今回はグループに追加するので、対象のグループにチェックを入れて「次へ」を選択します。
最終チェック画面にて問題なければ「ユーザーを追加」を選択します。
完了すると、ユーザー作成時に入力した 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 ポリシーを割り当てていることになります
ログイン確認
準備が整ったので、メンバーアカウントにログインしていきたいと思います。
サービスページ左ペインの「設定」を選択します。
画面下部「アイデンティティソース」タブ内に「AWS access portal URL」リンクがあるのでクリックします。
クリックすると、ユーザー名及びパスワードが聞かれるので、前工程で登録したユーザー名及びパスワードを入力して進みます。
進むと、初回は MFA 登録が求められます。
これは IdC のデフォルト設定にて、MFA 登録を必須としているためです。
(もちろん変更可能ですが今回は割愛します)
MFA の登録が完了すると、アクセスポータルが表示されます。
アクセスポータルには、ログインしたユーザーに紐づけられた「アカウント×許可セット」が一覧で表示されます。
ログインしたい AWS アカウントの許可セットを選択します。
選択すると、別タブで AWS アカウントのマネジメントコンソールが表示されました。
画面右上には「許可セット名/ユーザー名」で表示されます。
ここからもわかるように、許可セット名は大事ですね。
おわりに
今回は AWS IAM Identity Center について基本的な内容をまとめました。
個人で利用する機会は少ないかもしれませんが、企業では利用する場合が多いと思います。
IdC の利用は無料のため、個人学習でも積極的に使っていくといざというときに役立つと思います！
🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。