IAM Identity Center — マルチアカウントSSO設計

IAM Identity Center（旧称 AWS SSO）は、AWS Organizations 配下の全アカウントに対する シングルサインオン (SSO) を提供するサービスです。 Long-lived なアクセスキーの廃止と属性ベースアクセス制御 (ABAC) の実現で中心的役割を担います。 本記事では Identity Center の設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

IAM Identity Center が解決する課題

従来のマルチアカウント運用では、各アカウントに IAM ユーザーを作成し、 アクセスキーを配布する必要がありました。これには以下の課題があります：

• アクセスキー漏洩リスク: Long-lived クレデンシャルは危険
• アカウント毎のユーザー管理: 管理工数が膨大
• 一貫性のない権限: アカウントごとに権限がバラバラ

Identity Center は Organizations と連携して一元的な SSO を提供します。

Identity Center の構成要素

要素	説明
Identity Store	Identity Center 組み込みのユーザーディレクトリ
外部 IdP	Active Directory, Okta, Entra ID などの外部認証プロバイダ
Permission Set	ロールに相当する権限テンプレート（アカウントにマッピング）
アカウント割当	ユーザー/グループ × Permission Set × アカウントの組み合わせ
SSO エンドポイント	ユーザーがログインするポータル URL

[ユーザー] → (SSO ログイン) → [Identity Center Portal]
                                  │
            ┌─────────────────────┼─────────────────────┐
            ▼                     ▼                     ▼
      アカウント A           アカウント B           アカウント C
      (Permission Set 1)     (Permission Set 2)     (Permission Set 3)

Permission Set の仕組み

Permission Set は「どの権限でアカウントにアクセスできるか」のテンプレートです。 アカウントに割り当てると、そのアカウント内に IAM ロールが自動作成 されます。

認証ソースの選択

Identity Center は 3 つの認証ソース から選べます。

認証ソース	説明	ユースケース
Identity Store	Identity Center 内蔵ディレクトリ	小規模・クラウドネイティブ
AWS Managed Microsoft AD	AWS 上の AD と連携	AD 活かす場合
外部 IdP (SAML 2.0)	Okta, Entra ID, Google Workspace 等	既存 IdP 活かす

SAP レベル：高度な設計シナリオ

属性ベースアクセス制御 (ABAC)

SAP では ABAC (Attribute-Based Access Control) の設計が重要論点です。 ABAC はユーザー/リソースの 属性 (タグ) に基づいて権限を動的に決定します。

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
      "aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
    }
  }
}

このポリシーでは、ユーザーの Project タグとリソースの Project タグが一致 すればアクセス許可。 新規プロジェクト追加時に Permission Set を増やさずに済むのが ABAC の強みです。

Permission Set 設計のベストプラクティス

SAP では Permission Set の粒度と命名規則 を設計します。

設計方針	内容	理由
ジョブ関数ベース	NetworkAdmin, DBAdmin, Developer 等	職務分掌 (SoD) の実現
環境別 Permission Set	ProdReadOnly, DevFullAccess	本番の誤操作防止
最小権限の原則	必要最小限のアクションのみ許可	セキュリティリスク低減
事前定義ポリシーの活用	AWS マネージドポリシーをベースに	メンテ負荷軽減

グループベースのアクセス割当

Identity Center は グループ単位でのアクセス割当 を推奨します。

グループ: NetworkAdmins
  └── Permission Set: NetworkAdmin
        ├── アカウント A (本番)
        └── アカウント B (開発)

ユーザー Alice → NetworkAdmins グループに所属 → A, B 両アカウントに NetworkAdmin 権限

外部 IdP との SAML 連携設計

SAP では 外部 IdP (Okta, Entra ID 等) との SAML 連携 を設計します。

• SCIM プロビジョニング: IdP 側のユーザー変更が Identity Center に自動同期
• 属性マッピング: IdP の属性 → Identity Center の属性 → ABAC 用タグ
• JIT (Just-In-Time) プロビジョニング: 初回ログイン時にユーザー作成

[Okta / Entra ID]
  ユーザー属性: department=Engineering, project=Alpha
       │ (SAML + SCIM)
       ▼
[IAM Identity Center]
  属性マッピング → PrincipalTag: department, project
       │ (ABAC ポリシー)
       ▼
[AWS アカウント] リソースタグ project=Alpha に一致すればアクセス許可

Control Tower との統合

AWS Control Tower は Identity Center を統合利用します。

• Control Tower のランディングゾーン構築時に Identity Center が自動有効化
• Control Tower が 事前定義の Permission Set を提供（AdministratorAccess, ReadOnly など）
• アカウントベンダー（Account Factory）が新規アカウントを Identity Center に自動登録

クロスアカウントアクセスとセッションポリシー

Identity Center は セッションポリシー (Session Policy) で セッション中の権限を動的に絞り込めます。

• ログイン時にセッションポリシーを適用 → 有効権限をさらに絞る
• ABAC の属性をセッションポリシーに反映 → 動的権限絞り込み
• 緊急対応時の一時権限昇格 (Break-Glass) 設計にも利用

監査とコンプライアンス

Identity Center のログは CloudTrail と S3 アクセスログ に記録されます。

監査要件	ログ先	設計論点
ログイン成功/失敗	CloudTrail (ConsoleLogin)	異常ログインのアラート
ロール Assume	CloudTrail (AssumeRole)	権限使用の追跡
ユーザー/グループ変更	CloudTrail + Identity Center API	変更履歴の保全
IdP SAML 認証	IdP 側ログ	二重ログ管理

制約とクォータ

項目	制約
Permission Set	クォータ拡張可能
ユーザー/グループ	Identity Store で管理
IdP 連携	SAML 2.0 のみ
Organizations 連携	必須（Identity Center は Organizations が前提）

まとめ

• SAA: Identity Center は Organizations 配下の SSO、Permission Set がロールのテンプレート、 外部 IdP は SAML 2.0 で連携、という基本を理解する。
• SAP: ABAC 設計、Permission Set の粒度、グループベース割当、SCIM プロビジョニング、 Control Tower 統合、監査設計が求められる。

次は クロスアカウント IAM ロール設計 で、アカウント間の権限委任を深掘りします。