02-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

021-AWS IAM Identity Center

理論

AWSにおけるユーザー認証とアクセス管理の基本

クラウド環境でユーザー認証とアクセス管理は非常に重要です。AWSでは、ユーザーがどのようにAWSリソースにアクセスできるかを管理するために、いくつかのツールとサービスを提供しています。

1. AWS IAM（Identity and Access Management）とは？

AWS IAMは、AWSクラウドリソースへのアクセスを管理するためのサービスです。IAMを使うことで、どのユーザーやサービスがどのリソースにアクセスできるかを制御できます。IAMを活用することで、セキュリティを保ちながら、ユーザーやアプリケーションのアクセスをきめ細かく管理することができます。

主な機能：

ユーザーの管理: 会社の従業員やサービスに対して、AWSリソースへのアクセスを許可したり、制限したりします。

ポリシーの設定: どのリソースにアクセスできるかを定義するポリシー（JSON形式）を使ってアクセス権限を管理します。

ロールの設定: 特定の権限を一時的に付与するためのロールを設定し、サービスやユーザーに割り当てることができます。

2. IAMのアクセス管理方法

AWSでは、アクセス管理を行うために主に以下の3つの方法を利用します。

① ユーザー

ユーザーは、AWSリソースにアクセスする個々のエンティティです。IAMユーザーは、AWSアカウント内で認証されるために使用され、各ユーザーには固有のアクセス権限が設定されます。

② グループ

複数のIAMユーザーに同じ権限を一度に付与したい場合に使うのがIAMグループです。例えば、「開発チーム」や「マーケティングチーム」など、共通の役割を持つユーザーをグループにまとめ、そのグループにアクセス権を設定します。

③ ロール

ロールは、特定の権限を持った一時的な「役割」を定義するものです。IAMロールはユーザーやサービスが一時的にその権限を取得するために使用され、通常はAWSサービス間のアクセスに利用されます。

3. IAM機能-SAML 2.0とOpenID Connect (OIDC)

多くの企業では、AWSのようなクラウドサービスにアクセスする際に、シングルサインオン（SSO）を活用しています。SSOを使うと、ユーザーは一度のログインで複数のサービスにアクセスできるため、便利で安全です。

SAML 2.0: SAML（Security Assertion Markup Language）は、ユーザー認証情報を安全にやり取りするための標準的なプロトコルです。企業のオンプレミスシステム（例えばActive Directory）とAWSを統合して、AWSにアクセスするための認証を一元管理できます。

OpenID Connect (OIDC): OIDCは、主にウェブアプリケーションで使用される認証プロトコルで、GoogleやFacebookなどのサービスとも連携できます。AWSはOIDCをサポートしており、外部のIDプロバイダーを使ってAWSリソースへのアクセスを管理することができます。

4. AWS IAM Identity Center（AWS SSO）

AWS IAM Identity Center（AWS Single Sign-On）は、複数のAWSアカウントに対してシングルサインオン（SSO）を設定するためのサービスです。これを使うことで、ユーザーはAWSアカウントに個別にサインインする必要なく、1つのログインで複数のAWSサービスにアクセスできるようになります。

SCIM（System for Cross-domain Identity Management）: AWS SSOはSCIMをサポートしており、これを使うとユーザー情報の自動プロビジョニング（新しいユーザーの追加や削除）が可能になります。例えば、Active Directoryに新しいユーザーを追加した際、AWS SSOにも自動的にその情報が反映されます。

属性ベースアクセス制御（ABAC）: ABACは、ユーザーの属性（役職や部門など）に基づいてアクセス権限を決定する方法です。これにより、ユーザーがどのリソースにアクセスできるかを柔軟に設定できます。

5. クロスアカウントアクセス

AWSでは、複数のアカウントにまたがってアクセス権を設定することもあります。例えば、異なる部署やプロジェクトで異なるAWSアカウントを使用している場合に、クロスアカウントアクセスを設定することで、他のアカウントに対してアクセスを許可できます。

クロスアカウントアクセスは、特に大規模な企業や組織にとって便利で、安全に複数のアカウントをまたいでリソースを管理できます。

6. AWSリソースへのアクセス管理のベストプラクティス

最小権限の原則: ユーザーやサービスに必要最低限の権限だけを付与することで、セキュリティを強化します。

定期的なアクセスレビュー: 定期的にアクセス権限を見直し、不要な権限を削除することで、セキュリティを維持します。

ロールを活用: 必要に応じてIAMロールを使い、最小限の権限で一時的にアクセスを許可します。

結論

AWSにおけるユーザー認証とアクセス管理は、企業のセキュリティにとって非常に重要です。IAMを活用してアクセスを管理し、シングルサインオン（SSO）やクロスアカウントアクセスなどの機能を使うことで、安全かつ効率的にAWSリソースを管理することができます。適切な認証プロトコルやポリシー設定を活用し、最小権限の原則に基づいてアクセスを管理することが、セキュアなクラウド環境の維持に繋がります。

実践

参照元：

IAM Identity Centerを使って複数アカウント管理する。（その１：IAM Identity Centerでのログイン） - Qiita

はじめに仕事で初めてIAM Identity Centerを使う機会があり、使ってみたらマルチアカウントの管理が想像以上にやりやすかったので、紹介しようと思います。【次】IAM Identity…

https://qiita.com/sakai00kou/items/086a12caa69a78c18f61#comment-a6562b9fc03f61b9dfa7

IAM Identity Centerを使って複数アカウント管理する。（その１：IAM Identity Centerでのログイン）

IAM Identity Centerは、AWS Single Sign-Onの後継サービスで、AWS Organizationsを利用して複数アカウントを一元管理し、簡単にログイン操作を行えるようにするツールです。

特徴

AWS Organizations必須: IAM Identity CenterはAWS Organizationsが前提。

簡単な設定: 複雑な認証連携なしで、シンプルな構成の環境なら容易に導入可能。

利便性向上: ポータル画面から各アカウントに直接ログイン可能。スイッチロールやログインページの切り替えが不要。

メリット

IAM Identity Centerを使えば、複数アカウントを効率的に管理し、ログイン操作を簡略化できます。AWS Organizationsを使用している環境であれば、導入を検討する価値があります。

IAM Identity Centerの構成

AWS Organizationsで複数のアカウントを管理している場合、IAM Identity Centerを導入すると次のようなメリットがあります:

統一ポータルからのログイン: 各アカウントのログインページやスイッチロールを利用せず、IAM Identity Centerの専用ポータル画面から、直接複数のアカウントに簡単にアクセス可能。

効率化: アカウントごとの手動操作を省略し、スムーズな運用管理が実現。

IAM Identity Centerの設定

以下より実際にIAM Identity Centerの設定を行っていきます。

IAM Identity Centerの有効化

ルートアカウントにてIAM Identity Centerの画面から「有効にする」を選択するだけで有効化できます。

多要素認証の設定

IAM Identity Centerの「設定」 →「認証」→「多要素認証」の「設定」より多要素認証（MFA）の設定が行えます。

IAM Identity Center全体の設定となるため、ユーザごとに設定を変更することはできませんが、以下のようにサインイン時にMFA登録を要求することができるので、AWS OrganizationsのSCPやIAMロールで権限設定せずとも、簡単にログインユーザ全員にMFAを強制できるため、全体の統制を取るためにも有用です。

今回は以下のように「サインイン時にMFAデバイスを登録するよう要求する」を選択し、MFAを強制しようと思います。

ユーザとグループの作成

IAM Identity Centerのユーザ・グループを作成していきます。

IAM Identity Centerのユーザ・グループは、各アカウントで作成するIAMユーザ・グループとは異なるため、IAM Identity Centerでユーザ・グループを作成しても、各アカウント側にはIAMユーザ・グループは作成されません。

接続構成としてはIAM Identity Centerから各アカウントに内部的にスイッチロールで接続することで、各アカウント側にはユーザ・グループの作成は行われず、IAM Identity Centerで集中管理できるようになっているようです。

「IAM Identity Center」→「ユーザー」の「ユーザーを追加」からユーザを登録します。

ユーザの作成は、以下の項目が必須項目となるため、各ユーザごとにそれぞれ登録を行います。

また、必須項目以外にも、「お問い合わせ方法」、「ジョブ関連情報」、「アドレス」、「環境設定」、「追加の属性」をオプションとして登録できるため、必要に応じて登録を行い、「次へ」を選択します。

まだグループを作成していない場合、以下の画面からグループを作成できるので、「グループを作成」を選択して、グループを作成します。

別タブでグループ作成の画面が開くため、グループ名を指定し、「グループを作成」を選択します。

グループを作成したら、ユーザ作成画面に戻り、リロードボタンを選択すると作成したグループが表示されるので、グループ名を選択し、「次へ」進みます。

確認画面で問題なければ「ユーザーを追加」でユーザ作成します。

作成後、登録ユーザに以下のようなメールが届くため、「Accept invitation」を選択します。

「Accept invitation」を選択することで、初期パスワード設定画面が開くため、各ユーザ側でパスワード設定してもらいます。

ちなみに、ユーザ作成時、「このユーザーと共有できるワンタイムパスワードを生成します。」を選択した場合は以下のような画面が表示されます。

ただし、IAM Identity Centerからのメール検証が必要となるため、その場合はユーザの詳細画面から「Eメール検証リンクを送信」で検証を行います。

許可セットとは

許可セットは、IAMユーザやグループに割り当てるIAMポリシーと同等の機能を持ちつつ、以下の特徴があります:

複数アカウントに対応: 1つの許可セットで複数アカウントにポリシーを適用可能。各アカウントで個別にポリシーを作成する必要がありません。

複数の許可セット割り当て: ユーザやグループに複数の許可セットを付与可能。

例: 通常はリードオンリー権限、作業時のみフルアクセス権限を使用。

IAMロールと許可セットは似ていますが、用途と管理方法に違いがあります。

主な違い

特徴	IAMロール	許可セット
適用対象	ユーザに割り当て	グループやアカウントに割り当て
ユースケース	特定のサービスやアカウント内リソースへのアクセス許可	AWS Organizations環境で複数アカウントにまたがる簡単な権限付与
操作性	手動でIAMロールをスイッチする必要がある	IAM Identity Centerのポータルから簡単にアカウント切り替えが可能

簡単に言うと:

これにより、権限設定の集約管理が可能となり、設定忘れやミスを防ぎつつ、運用の効率化を図れます。

許可セットの作成

「マルチアカウント許可」→「許可セット」より「許可セットを作成」を選択し、許可セットを設定していきます。

許可セットのポリシー

許可セットには以下の2種類があります：

AWSマネージドポリシー: 用途ごとに事前定義されたポリシーを選択可能（例: AdministratorAccess）。

カスタム許可セット: 独自のポリシーを細かく作成可能。

今回は、「AdministratorAccess」という事前定義された許可セットを選択して進めます。

許可セットの設定

設定内容: 許可セット名やセッション期間を設定します。

リレー状態の設定:

リレー状態の設定とは、ユーザがIAM Identity Centerポータルから各AWSアカウントにログインした際、最初に表示される画面を指定する機能です。
通常: AWSマネジメントコンソールのトップ画面に遷移。
カスタマイズ: 特定の画面（例: 請求画面）を直接表示したい場合はURLを指定可能。

後の手順で使おうと思うので、同じように「ReadOnlyAccess」の許可セットも作っておきます。

AWSアカウントとの結びつけ手順

ユーザ・グループ、許可セットの作成

先に作成済みのユーザ・グループ、許可セットを使用。

結びつけ手順

「マルチアカウント許可」→「AWSアカウント」を選択。

結びつけたいAWSアカウントを選び、「ユーザーまたはグループを割り当て」をクリック。

これにより、対象ユーザやグループに指定した許可セットを適用できます。

結びつけるユーザ、またはグループを選択できるので、任意のユーザもしくはグループを選択し、「次へ」を選択します。

結びつける許可セットを選択します。

下の画面のあと、確認画面が表示されるため、「送信」を選択することで、ユーザ・グループ、許可セットとAWSアカウントの結びつけができます。

「AWSアカウント」の画面に戻ると、どのアカウントにどの許可セットが割り当てられているかが確認できるので、想定の許可セットが割り当てられているかはこちらから確認します。

また、割り当てられたユーザ・グループは、少し分かりづらいですが、「マルチアカウント許可」→「AWSアカウント」→任意のアカウントの詳細画面→「ユーザーとグループ」タブから確認できます。

MFAデバイスの登録

初期パスワード設定時に送付されたメールアドレスに記載されているURLにアクセスすることでIAM Identity Centerのログイン画面が開きます。

また先程の設定よりMFA登録を要求するようにしていると、以下のようにMFAデバイス登録が促され、登録しないと先に進めないため、全ユーザにMFAを強制することができます。

IAM Identity Centerへのログイン手順

MFAデバイス登録後: IAM Identity Centerにログインします。

ポータル画面表示: 各アカウントと許可セットが表示されます。

操作手順:

アクセスしたいアカウントを選択。

許可ポリシーの「Management Console」をクリック。

対象のAWSマネジメントコンソールに遷移。

表示内容

許可セットに基づき、ユーザ・グループごとに表示が異なります。

例: AdministratorAccessやReadOnlyAccessが割り当てられたアカウントのみ表示される。
現在ログインしているユーザーは二つのアカウントに対して指定した許可セットでアクセスできます。

おわりに

今回は、IAM Identity Centerの基本設定からユーザログインまでを解説しました。

これにより、複数アカウントのユーザ・グループ設定やIAMポリシーの管理を効率化でき、スイッチロールによるアカウント間移動が簡素化されることをお伝えしました。

次回は、コマンドライン操作について詳しく解説します。

IAM Identity Centerを使って複数アカウント管理する。（その２：CLIでのアクセスと管理の委任）

はじめに

前回はIAM Identity Centerの基本設定とAWSマネジメントコンソールへのログインまで行ったので、今回はCLIでのアクセス方法とIAM Identity Center管理の委任についてまとめてみようと思います。

CLIアクセスについて

IAM Identity Centerで作成したユーザのCLIアクセスは、期限付きセッショントークンによる認証方式を使用します。

CLIアクセスに必要な情報は、IAM Identity Centerにログイン後、

「Command line or programmatic access」を選択することで表示されます。

これにより、以下の利点があります：

ユーザごとのクレデンシャル情報を個別に作成・配布する必要がなくなる。

クレデンシャル情報の定期的な変更作業が不要になる。

CLIアクセスの設定方法

各アカウントおよび許可セットで「Command line or programmatic access」を選択すると、以下の情報が表示されます。この情報をコピーして使用できます。

表示される情報：

アクセスキーID
シークレットアクセスキー
セッショントークン（期限付き）

これらの情報を使って、次の方法でコマンドを実行できます：

コンソールに貼り付け：直接コマンドラインで使用。

~/.aws/credentialsに記載：プロファイルを設定し、profileを指定してコマンドを実行。

これにより、選択したアカウントと権限でコマンドが実行できます。

セッショントークンの保持期間とアクセス方法

セッショントークンの保持期間は、許可セットの「セッション期間」から設定できます。デフォルトは1時間で、最長12時間まで延長可能です。

保持期間が満了するとコマンドが失敗し、再度ポータル画面にアクセスして新しいトークン情報をコピーする必要があります。

ただし、ポータルから毎回トークンをコピーするのは手間がかかるため、アクセスキーとシークレットアクセスキーを使った管理に戻る可能性もあります。

そのため、CLIアクセスを効率的に利用する方法も用意されています。

前提条件

AWS CLIでIAM Identity Centerを使うためには、AWS CLI v2が必要です。

AWS CLI v2を使用していない場合は、以下のリンクから最新バージョンに更新してください：

Installing or updating the latest version of the AWS CLI

aws configure ssoによるトークンの更新

ポータル画面からトークン情報を手動でコピーする方法の他に、AWS CLIを使ってトークンを更新する方法もあります。

AWSユーザガイドにて紹介されている2種類の方法は、以下の通りです：

手動更新: トークンが満了した際に手動で更新する方法。

自動更新（推奨構成）: トークンが満了した際に自動で更新される方法。

今回は自動更新（推奨構成）を紹介します。

SSOトークンプロバイダ構成の設定

AWS CLI v2を使用して、aws configure sso コマンドでSSOトークンプロバイダ構成を設定します。

プロファイルの構成

aws configure sso を実行すると、以下の入力項目が表示されます。適切な情報を入力してください。

注意: AWS CLI v2が古いバージョンの場合、SSO session nameが表示されないことがあります。最新バージョンに更新してください。

入力項目:

SSO session name (Recommended): 任意のセッション名

SSO start URL: SSOポータルの開始URL（例:https://xxxxxxxxxx.awsapps.com/start#）

SSO region: リージョン（例: ap-northeast-1）

SSO registration scopes: 固定値 sso:account:access

設定例:

項目	設定	備考
SSO session name	AdministratorAccessCLI	任意のセッション名
SSO start URL	`https://x-xxxxxxxxxx.awsapps.com/start#`	ポータル画面からコピーしたURL
SSO region	ap-northeast-1	使用するリージョン
SSO registration scopes	sso:account:access	ユーザガイド通りの固定値

入力が完了した後、AWS CLIがインターネットブラウザを開いてSSO認証画面を表示します。そこで「Allow」を選択して認証を完了させます。

インターネットブラウザが開けない場合は、AWS CLIのコマンド結果で表示されている以下のURLにアクセスし、記載されているコードを入力することで関連付けます。

AWS CLIに戻ると関連付けられているアカウントが対話式で選択できるようになるため、上下ボタンでアクセスしたいアカウントを選択してEnterを押します。

続いて関連付けられている許可セットの選択を行います。

デフォルトリージョン、アウトプットフォーマット、任意のプロファイル名の指定を行い実行。

aws configure ssoコマンドの設定完了後、~/.aws/configに以下のような設定情報が作成されます。

上記設定後に表示される実行例のように、--profile [CLIプロファイル名]を指定することで、指定したプロファイルの権限でコマンドを実行できます。

コマンド実行例

他のアカウント用プロファイルへの切り替え方法は、以下のように--profileオプションを使用します。

プロファイル切り替えコマンド:

複数プロファイル作成:

これにより、IAM Identity Centerで設定したプロファイルを切り替えて使用できます。

実運用時のプロファイル構成例

実際に、2つの方法を使った例を挙げてみましょう。

1. `-profile`オプションを毎回指定する方法

この方法では、AWS CLIで実行するたびに--profileオプションを使って接続先アカウントを指定します。

例:

プロファイルAでS3バケットを一覧表示

プロファイルBでEC2インスタンスを確認

ここでは、毎回--profileを指定しなければならず、複数のアカウントを切り替えるたびに手動でオプションを変更する必要があります。

2. 作業用CLIプロファイルを設定し、`aws configure sso`で切り替える方法

この方法では、一度作業用CLIプロファイルを設定しておけば、その後は簡単にアカウントを切り替えることができます。

ステップ:

作業用プロファイルの設定:

これにより、作業用プロファイルが設定され、アカウントを選択するためのプロンプトが表示されます。

プロンプトでアカウントを選択: プロンプトが開き、矢印キーを使って接続したいアカウントを選択し、Enterを押します。

アカウント切り替え後、再度aws configure ssoで切り替え:

このコマンドを実行するだけで、再度簡単にアカウントを切り替えることができます。--profileオプションを毎回指定する手間が省けます。

結果:

最初に作業用プロファイルを設定しておくと、後は簡単にアカウント間の切り替えが可能で、複数のアカウントで操作する際の効率が良くなります。

セッショントークンの期限が切れた場合、以下のコマンドでアクセスを再開できます。

トークンの更新

インターネットブラウザで認証を行い、新しいトークンが取得されます。

明示的にログアウト

ログアウトし、クライアント側のキャッシュされているトークン情報も削除されます。

IAM Identity Centerの管理の委任

IAM Identity Centerはデフォルトでルートアカウントで管理されますが、ベストプラクティスではルートアカウントでの管理は最小限にすることが推奨されます。

他のメンバーアカウントに管理権限を委任することができ、ルートアカウントの使用を制限することができます。

委任設定により、セキュリティを向上させ、運用効率を高めることができます。

委任の設定

委任の設定自体は非常に簡単で、「IAM Identity Center」の「設定」→「管理」タブの「アカウントを登録」から行います。

委任するメンバーアカウント選択画面が表示されるため、委任するメンバーアカウントを選択して、「アカウントを登録」を実行することでIAM Identity Centerの管理を委任することができます。

上記画面の注意書きにも記載されている通り、ルートアカウントに対する許可セットの管理やIAM Identity Center自体の削除などは、今まで通りルートアカウントで行う必要がありますが、委任することでルートアカウントからIAM Identity Centerの管理を分離することができます。

おわりに

今回はCLIでのアクセス方法とIAM Identity Centerの管理委任方法について説明しました。

セッショントークンの再認証手間はありますが、永続的なアクセスキーを配布せずにアクセスできる点は管理者にとって大きなメリットです。

IAM Identity Centerの委任により、役割が明確になり、アカウント数が多いシステムではユーザ管理用アカウントを用意するのも効果的です。

次回は外部AWSアカウントに対してIAM Identity CenterからSAMLアクセスを行う方法を試す予定です。

IAM Identity Centerを使って複数アカウント管理する。（その３：外部AWSアカウントへのSAML）

IAM Identity CenterからのSAML接続について

IAM Identity CenterはSAML2.0を使用したIDフェデレーションをサポートし、SAML対応のサービスプロバイダと連携可能です。

これにより、IAM Identity Centerの認証情報を使って、ポータル画面から外部サービスプロバイダに接続できます。

今回は、組織外のAWSアカウントに対してIAM Identity CenterからSAML接続を試みます。

接続構成:

外部AWSアカウントを持っていないため、メンバーアカウントを外部アカウントとして扱い、ルートアカウントからSAML接続を試みる。

自組織の設定と外部AWSアカウントの設定を交互に行う。自組織の作業は「自組織」、外部AWSアカウント側の作業は「外部組織」と区別して進める。

メンバーアカウントはIAM Identity Centerから接続できないように設定を変更し、ルートアカウントで管理を戻した。

この流れで、組織内での設定を外部AWSアカウントと連携させる方法について進めています。

アプリケーションの追加（自組織）

IAM Identity Centerに外部組織用のアプリケーションを追加するため、「IAM Identity Center」→「アプリケーション割り当て」→「アプリケーション」から「アプリケーションを追加」を選択して設定していきます。

「カスタムアプリケーション」と「事前統合アプリケーション」があるので、「事前統合アプリケーション」から「External AWS Account」を選択して「次」に進みます。

任意のアプリケーションの表示名を指定します。

また、「ステップバイステップの手順を表示」を選択すると、設定手順が表示されるため、設定時に開いておくと良いかと思います

「IAM Identity Centerメタデータ」の項目より、後ほど外部組織側設定で使用する「IAM Identity Center SAMLメタデータファイル」をダウンロードしておきます。

「アプリケーションのプロパティ」と「アプリケーションメタデータ」は今回の場合、デフォルトで問題ないので、そのまま「送信」を選択します。

「ユーザーを割り当て」を選択して、外部組織にアクセスさせたいユーザ・グループを選択します。

IDプロバイダの追加（外部組織）

外部組織側のアカウントに移り、IAM Identity Centerからの認証を受け付けるIDプロバイダの設定を行っていきます。

「IAM」→「アクセス管理」→「IDプロバイダ」の「プロバイダを追加」より設定を行っていきます。

IDプロバイダ（Identity Provider）: 認証情報を提供するサービス。IAM Identity Centerや外部の認証システム（例えば、Active DirectoryやGoogle Workspace）などがこれに該当します。

サービスプロバイダ（Service Provider）: ユーザーがアクセスしたいリソースやシステム。AWSアカウントや外部アプリケーションがサービスプロバイダです。

IAM Identity Centerからの認証を行う場合、IDプロバイダとしてIAM Identity Centerを使用してユーザーの認証を行い、その後ユーザーはアクセスしたいAWSリソース（サービスプロバイダ）にアクセスできるようになります。

以下表、図のように設定を行い、「プロバイダを追加」を選択。

以下のように概要画面が表示されるため、後ほどIAM Identity Center側作業で必要となるARNを控えて「ロールの割り当て」でIDプロバイダと結びつけるIAMロールを作成します。

IAMロールの作成（外部組織）

前手順に引き続き、設定を行っていきます。

「新しいロールを作成」を選択し、「次へ」進みます。

以下表、図のように設定を行い、「次のステップ：アクセス権限」を選択。

項目	設定
信頼されたエンティティの種類を選択	SAML 2.0 フェデレーション
SAMLプロバイダー	IdentityCenterSAML（先程作成したIDプロバイダ）
ㅤ	プログラムによるアクセスとAWSマネジメントコンソールによるアクセスを許可する
属性	SAML:aud
値	https://signin.aws.amazon.com/saml
条件	なし

IAM Identity Centerからのアクセス時に適用したいポリシーを選択して「次のステップ：タグ」を選択。

タグ設定は今回は特に設定せず次へ進み、ロール名の指定を行い、「ロールの作成」で作成します。

作成後、IAM Identity Center側の設定で必要となるIAMロールのARNを控えておきます。

属性マッピングの設定（自組織）

再度、IAM Identity Centerの設定画面に戻り、「IAM Identity Center」→「アプリケーション割り当て」→「アプリケーション」の「設定済み」タブから先程作成したアプリケーション名を選択します。

アクション」から「属性マッピングを編集」を選択します。

下記の図の１行目と２行目はデフォルトで記載されているため、新たに３行目を追加し、以下のように設定します。

また、以下表２列目のValue値の書式についてはarn:aws:iam::[ACCOUNTID]:saml-provider/[SAMLPROVIDERNAME],arn:aws:iam:: [ACCOUNTID]:role/[ROLENAME]となり、先程控えたIDプロバイダのARNとIAMロールのARNを結合したものを記載します。

アプリケーションのユーザー属性	この文字列値またはIAM Identity Centerのユーザー属性にマッピング	形式	備考
Subject	${user:email}	persistent	デフォルトで入力済み
https://aws.amazon.com/SAML/Attributes/RoleSessionName	${user:email}	unspecified	デフォルトで入力済み
https://aws.amazon.com/SAML/Attributes/Role	arn:aws:iam::xxxxxxxxxxxx:saml-provider/IdentityCenterSAML,arn:aws:iam::xxxxxxxxxxxx:role/IdentityCenterSAML-Role	unspecified	ステップバイステップ手順に書式記載あり

IAM Identity Centerからのログイン（自組織）

上記までの手順を実施することで、IAM Identity Centerのポータル画面に外部組織へログインするためのアプリケーションが表示されるようになっているため、表示されているアプリケーションを選択することで外部組織のAWSアカウントにログインできるようになります。

まとめ

自組織（A組織）の設定:

自組織の IAM Identity Center で Aアプリケーション を作成します。

Aユーザー を Aアプリケーション に関連付けます。このアプリケーションは、他組織（B組織）のリソースにアクセスするために必要な認証情報を持つ役割を果たします。

他組織（B組織）の設定:

B組織で Bロール を作成し、アクセス権限（ポリシー）を設定します。

このロールには、B組織のリソースへのアクセス権限が含まれており、アクセスするために必要な認証を Aアプリケーション に委譲します。

信頼関係の設定:

B組織の IAM で、Aアプリケーション からの認証を受け入れるための信頼関係を設定します。具体的には、B組織の IAMロール に対して Aアプリケーション からの SAML 認証を受け付ける設定を行います。

これにより、A組織の IAM Identity Center が提供する認証を通じて、AユーザーがB組織のリソースにアクセスするためのロールを付与されます。

Aユーザーのアクセス:

AユーザーがAアプリケーションを通じて認証されると、その認証情報をもとにB組織の Bロール を取得します。

B組織で設定した権限に基づき、AユーザーはB組織のリソースにアクセスできるようになります。

このように、Aユーザーが自組織の IAM Identity Center を使って認証し、他組織のロールにアクセスする設定が完了します。この設定により、ユーザーはB組織のリソースにアクセスできますが、B組織のロールの認証と権限はA組織の IAM Identity Center によって管理されます。

IAM Identity Centerを使って複数アカウント管理する。（その４：GHECへのSAML）

前提条件

GitHubでSAML認証を使用するには、以下の条件が必要です：

*GitHub Enterprise Cloud（GHEC）**を利用していること

GitHub Organizationを構成していること

そのため、個人向けのフリープランやTeamプランではSAML認証は利用できません。もし検証したい場合は、Enterpriseトライアルを利用して機能を確認することをおすすめします。

今回の記事は、Organizationの認証にSAMLを使用する前提で進めます。

接続構成

今回の設定手順では、GitHub Enterpriseプランを使用し、Organizationが構成されている前提で進めます。

設定の流れは前回の外部AWSアカウント接続時と似ていますが、今回は外部組織がGitHubです。

自組織側（IAM Identity Center）で設定を行い、外部組織（GitHub）との接続用アプリケーションを作成し、接続設定を行う流れです。

構成イメージは前回と同様に、**自組織（IAM Identity Center）と外部組織（GitHub）**の接続設定として説明します。

SAMLメタデータの取得（外部組織）

外部組織（GitHub）での設定において、SAMLメタデータを取得するために、前回の自組織側のアプリケーション設定時に指定した「アプリケーションACS URL」と「アプリケーションSAML対象者」に対応するSPメタデータをダウンロードします。

メタデータのURLは次の形式で提供されます：

https://github.com/orgs/ORGANIZATION/saml/metadata

（ORGANIZATIONは自分のOrganization名）

このURLにアクセスし、表示されたXMLファイルをページ保存などでダウンロードしておきます。