SAA / SAP 攻略ナビ
ホーム アイデンティティ・アクセス管理

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

IAM Identity Center (旧 AWS SSO) によるマルチアカウントSSO、Permission Set、属性ベースアクセス制御 (ABAC)、IdP 連携を SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: アイデンティティ・アクセス管理

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 を提供します。

SAA レベル：基礎概念

IAM Identity Center の核心は 「Organizations 配下の全アカウントに SSO を一元提供」 です。 ユーザーは 1 回のログインで、権限のあるすべての AWS アカウントにスイッチできます。 Long-lived アクセスキーを廃止し、一時クレデンシャルで安全にアクセス可能です。 SAA では「マルチアカウント SSO の標準」として押さえます。

Identity Center の構成要素

要素説明
Identity StoreIdentity Center 組み込みのユーザーディレクトリ
外部 IdPActive 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 ロールが自動作成 されます。

SAA 試験のポイント

Permission Set をアカウントに割り当てると、アカウント内に対応する IAM ロールが自動作成 されます。 ユーザーは SSO 経由でこのロールに AssumeRole する形でアクセスします。 「Permission Set = ロールのテンプレート」と覚えると分かりやすいです。

認証ソースの選択

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

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

SAA 頻出

外部 IdP との連携は SAML 2.0 を使います。 Okta や Entra ID などの既存 IdP がある場合、ユーザー管理を IdP に一本化できます。 「IdP 連携 = SAML 2.0」は SAA の定番知識です。

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

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

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

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

ABAC を使うと、ユーザー属性（部署、プロジェクト、コストセンター）と リソース属性（タグ）が一致する場合のみアクセス許可 という動的権限を実現できます。 新しいプロジェクトやチームが追加されても Permission Set を追加せずに済むため、 大規模組織での管理工数が劇的に減ります。

{
  "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 SetProdReadOnly, DevFullAccess本番の誤操作防止
最小権限の原則必要最小限のアクションのみ許可セキュリティリスク低減
事前定義ポリシーの活用AWS マネージドポリシーをベースにメンテ負荷軽減

Permission Set 設計の落とし穴

Permission Set はアカウントごとにロールを自動作成 するため、 Permission Set を増やしすぎると 各アカウントのロール数がクォータ (1000) に達する リスクがあります。 「ジョブ関数ベースで共通化」し、濫造を避けるのが SAP の定石です。

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

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

グループ: NetworkAdmins └── Permission Set: NetworkAdmin ├── アカウント A (本番) └── アカウント B (開発) ユーザー Alice → NetworkAdmins グループに所属 → A, B 両アカウントに NetworkAdmin 権限

グループ設計の要点

ユーザー単位ではなくグループ単位で権限を割り当てる のがベストプラクティスです。 ユーザーの入退社時はグループ所属の追加/削除だけで済み、Permission Set の再割当不要。 これが SAP の運用効率化の核心です。

外部 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 に一致すればアクセス許可

SCIM の活用

SCIM (Cross-domain Identity Management) を有効化すると、IdP 側でユーザーを無効化するだけで AWS アクセスも即座に無効化されます。退職者のアクセス残存リスクを防ぐため SAP では SCIM が必須です。

Control Tower との統合

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

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

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

Control Tower + Identity Center の組み合わせが AWS 推奨のマルチアカウント SSO 標準 です。 Control Tower がベースラインを提供し、Identity Center が認証・認可を担うことで、 「ガバナンスと SSO の一貫性」を実現します。この統合アーキテクチャを設計できるかが SAP の論点です。

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

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

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

セッションポリシーの制約

セッションポリシーは 権限を絞ることしかできません（拡張不可）。 Permission Set で許可されていないアクションをセッションポリシーで許可することはできません。 「絞込み専用」である点を SAP では押さえます。

監査とコンプライアンス

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

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

監査設計の要点

Identity Center 経由のアクセスは CloudTrail の AssumeRoleWithSAML / AssumeRole イベントで追跡します。 ログ集約アカウント（Audit アカウント）に CloudTrail を集約し、 異常アクセスを GuardDuty / Security Hub で検知する構成が SAP の標準です。

制約とクォータ

項目制約
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 ロール設計 で、アカウント間の権限委任を深掘りします。

関連記事