TL Terralien
Security, Identity, and Compliance

IAM Identity Center

複数AWSアカウントとAWS管理アプリへの人間のワークフォースSSO。生成AI文脈での本体は、サインインしたIDをアプリ側の認可にそのまま渡す「trusted identity propagation」です。

  • B｜実装まわり
  • D2 実装と統合
  • D3 安全性・セキュリティ・ガバナンス

最終更新: 2026年8月18日

ひとことで言うと

社員証1枚方式です。1回のサインインで複数のAWSアカウントとAWS管理アプリケーションに入れます。

要するに、社員証にその場の権限が書き込まれる仕組みです。ただの入館証（誰であるか）で終わらず、生成AIアプリ（Amazon Quickなど）がその社員証のID・所属グループの情報をそのまま別のAWSサービス（Amazon Redshiftなど）に渡し、渡された側がその情報で「この人にどこまで見せるか」を判断します。これが trusted identity propagation（信頼できるID伝播）です。

なぜ生まれたか

Identity Center が無いと受け皿
アカウントごとにIAMユーザー・フェデレーション証明書を個別管理1点の連携（既存ディレクトリを1回接続すれば全アカウントで共有）
アプリのサービスロールが全ユーザー共通で、誰が何を見たか個人単位で追えないtrusted identity propagationでCloudTrail・サービスログにユーザー単位の記録
アプリごとに認可ロジックを作り直すユーザーの属性（部門等）をそのままAWS管理アプリ側の認可に伝える

Identity Center自体は「サインインの一元化」が主目的ですが、生成AIの文脈で効くのはその先、つまりサインインした個人のIDが、データにアクセスする瞬間まで保たれる設計です。

何に使うか

用途使い方関連ドメイン
複数AWSアカウントへのワークフォースSSOorganization instanceで一元管理・permission setsを配布D2
AWS管理アプリへの統一IDKiro・Amazon Quickなどが共通のユーザー/グループ情報を参照D2
trusted identity propagationクライアントアプリが受け取ったIDをそのまま下流のAWSサービスに引き継ぐD2・D3
監査個々のAWSサービスのログ・CloudTrailにユーザー識別子が記録されるD3

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
生成AIアプリで、ユーザーごとに閲覧できるデータ範囲を制限したいが、アプリのサービスロールは全ユーザー共通ユーザーの属性で下流の認可を決めたい → trusted identity propagationアプリ内でユーザーIDを条件分岐するコードを自前で書く
誰が生成AIアプリ経由でどのデータにアクセスしたか個人単位で監査したいユーザー識別子をログに残したい → Identity Center連携＋サービス側ログ／CloudTrailアプリのアクセスログをアプリ側だけで独自に保存する
エージェントやLambdaなど、人間以外の主体を認証したいIdentity Centerはワークフォース（人間）向け → 主役ではない、機械間はIAMロールIdentity Centerでエージェント用のユーザーを作成する
複数AWSアカウントに散らばるBedrock環境へ社員をサインインさせたいorganization instanceでアカウントを横断管理アカウントごとにIAMユーザーを作って個別配布する

trusted identity propagationは「Identity Center側の設定」と「連携先AWSサービス側の設定」の両方が要ります。片方だけでは伝播しません。

実務でどう使うか

  • organization instanceがベストプラクティス。 account instanceは特定のAWS管理アプリの単独デプロイ向けで、複数アカウント管理はできません
  • trusted identity propagationは対応しているAWSサービス間でしか成立しません。 独自に構築したアプリケーションを組み込みたい場合は、信頼されたトークン発行者（trusted token issuer）として認証プロバイダを別途Identity Centerに接続する必要があります
  • エージェントやバッチ処理など、サインインする人間がいない経路には別の仕組みが要ります。 Identity Centerはワークフォースの認証が前提で、機械間の呼び出しは対象外です

account instanceは特定のAWS管理アプリの単独デプロイ向けで、複数アカウントの一元管理はできません。本番でワークフォースのマルチアカウントアクセスを設計するなら、原則としてorganization instanceを選びます。

取り違えやすいもの

迷う相手切り分けの一言
Amazon CognitoIdentity Centerは社内ワークフォースのAWSアカウント/管理アプリ向けSSO。Cognitoは自社アプリの一般エンドユーザー向け認証
IAMIdentity Centerは人間のサインイン方法。IAMはサインイン後に何ができるか（ロール・ポリシー）を決める側
IAM Access AnalyzerIdentity Centerはアクセスを発行する側。Access Analyzerは発行された・使われなかったアクセスを事後検査する側

想起チェック

Q1. trusted identity propagationが解決する問題を一言で言うと？

アプリのサービスロールが全ユーザー共通でも、実際にデータへアクセスする下流のAWSサービス側で、個々のユーザーの属性に基づいた認可・監査ができるようにすることです。

Q2. IAM Identity CenterとAmazon Cognitoを分ける基準は？

対象がワークフォース（社内・複数AWSアカウント）か、コンシューマ（自社アプリのエンドユーザー）かです。生成AIアプリの利用者が一般ユーザーならCognito、社内の業務利用者ならIdentity Centerに寄ります。

出典（AWS公式）