AWS IAM Identity Center 完全ガイド v2.0

初心者から実務者向けの包括的解説

AWS IAM Identity Center（旧 AWS SSO） は、AWS Organizations 配下の全アカウントへのシングルサインオン（SSO）とワークフォース・アイデンティティ管理（WIM）を提供する、現代推奨の ID 基盤サービスです。既存の IdP（Okta、Azure AD、Active Directory）と SAML 2.0 / SCIM で統合し、一度のログインで複数の AWS アカウント・SaaS アプリケーション・AWS managed applications にアクセスできます。完全無料で、AWS Organizations の最小権限・ガバナンス・アクセス監査の要となるサービスです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： IAM Identity Center とは何か、なぜ IAM ユーザーより推奨されるのかを学びたい方
• 開発者向け： AWS CLI SSO プロファイル、Permission Set、Account Assignment の実装
• SRE / インフラ向け： マルチアカウント環境のアクセス権一元化、IdP 連携、SCIM プロビジョニング
• セキュリティ管理者向け： ワークフォース・アイデンティティの一元管理、監査、ABAC（属性ベース）による権限制御
• 意思決定者向け： Okta / Azure AD / Auth0 / Ping Identity との比較・投資判断

2026 年の IAM Identity Center エコシステム

• Trusted Identity Propagation： OAuth 2.0 による BI アプリケーション ↔ AWS Analytics（Redshift / QuickSight）の安全な ID 伝播
• SAML 2.0 / OIDC 統合の深化： Amazon Verified Access との連携、OpenID Connect（OIDC）メソッド対応
• 多リージョン対応： IAM Identity Center instance を複数リージョンにレプリケートして全リージョンでの一貫したアクセス管理
• SCIM 2.0 自動プロビジョニング： HR システムからの自動同期（入社・退職・部門異動），CloudFormation 対応強化
• Application Assignment 拡大： 30+ SaaS アプリケーション（Slack、Salesforce、GitHub Enterprise）の統合
• AI 駆動権限推奨： CloudTrail ベースの未使用権限検出と Permission Set の自動最適化提案

定義

AWS 公式による定義：

“AWS IAM Identity Center is the AWS solution for connecting your workforce users to AWS managed applications and other AWS resources.”

IAM Identity Center は ワークフォース・アイデンティティ管理（WIM）のための統合 SSO プラットフォーム です。

目次

1. 概要
2. IAM Identity Center が解決する課題
3. 主な特徴
4. アーキテクチャ
5. Identity Source（アイデンティティソース）
6. Permission Set（許可セット）
7. Account Assignment（アカウント割り当て）
8. Application Assignment（アプリケーション割り当て）
9. SAML 2.0 / OIDC フェデレーション
10. SCIM プロビジョニング
11. Trusted Identity Propagation
12. ABAC（属性ベースアクセス制御）
13. AWS CLI SSO プロファイル
14. IAM ユーザーとの比較
15. Organization Instance vs Account Instance
16. アクセスポータル
17. セキュリティ・監査
18. 他の類似ツールとの比較
19. クライアント・エコシステム
20. ベストプラクティス
21. トラブルシューティング
22. 2025-2026 最新動向
23. 学習リソース
24. 実装例・活用シーン
25. 導入ロードマップ
26. 実装チェックリスト
27. まとめ
28. 参考文献

概要

初心者向けメモ： IAM Identity Center は「AWS Organizations 管下の複数アカウントに対して、一度のログインで全員がアクセスできる仕組み」です。従来は各アカウントで個別に IAM ユーザーを作成・管理・削除していましたが、Identity Center は 組織の人事管理システムや Okta・Azure AD と連携 して、退職者のアクセスを 1 クリックで全アカウントから削除できます。

IAM Identity Center は以下を実現します。

IAM Identity Center が解決する課題

1. マルチアカウント IAM ユーザー管理の複雑性

課題： 50 アカウント環境では IAM ユーザーを個別に作成・管理・削除する工数が膨大。退職者処理、パスワードローテーション、アクセス権棚卸しが時間的・金銭的に負担

Identity Center の解決：

• IdP（Okta・Azure AD） --SCIM同期–> IAM Identity Center
• ↓
• 退職者を Okta で無効化 → Identity Center から自動削除 → 全 50 アカウントへのアクセス即座に失効

2. 長期 IAM アクセスキーの漏洩リスク

課題： IAM ユーザーのアクセスキーをスクリプト・環境変数に保存すると漏洩リスク大。ローテーション管理も複雑

Identity Center の解決：

aws sso login --profile my-dev-account
→ 一時認証情報（デフォルト 1 時間） を発行、期限切れで自動無効化

3. IAM ポリシーの重複定義

課題： 各アカウントで同じ「ReadOnlyAccess」「PowerUserAccess」を個別に定義すると、更新・監査が複雑かつ不一貫

Identity Center の解決：

• Permission Set「DeveloperAccess」を一度定義
• → 全 50 アカウントに一括適用、更新も 1 箇所で完結

4. 監査ログが複数アカウントに分散

課題： 「誰が何をしたか」を把握するため全アカウントの CloudTrail をチェック必要

Identity Center の解決：

• IAM Identity Center ユーザー ID（実名）で CloudTrail に記録
• → セキュリティ監査・コンプライアンスレポートが統一形式で可能

主な特徴

1. Organization Instance（推奨）

AWS Organizations 管理アカウント
  ├── IAM Identity Center 有効化
  └── 全メンバーアカウントへのアクセス管理一元化
      ├── Permission Set 定義（全アカウント共通）
      ├── Account Assignment（ユーザー・グループ → ロール）
      └── Application Assignment（Slack・GitHub 等）

メリット：

• 複数アカウント管理が統一
• Trusted Identity Propagation 対応
• 複数リージョンへのレプリケーション対応

2. SAML 2.0 / OIDC フェデレーション

Okta・Azure AD・Ping Identity・Google Workspace などの IdP と連携し、既存の企業ディレクトリ ID を AWS アクセスに再利用できます。

3. Permission Set（許可セット）

許可セット = IAM ロール テンプレート

例：DeveloperAccess
  ├── AWS 管理ポリシー：PowerUserAccess
  ├── カスタムポリシー：特定 S3 バケット へのアクセス制限
  └── セッション時間：12 時間

このセットを：
  ├── Dev アカウント：開発者グループに割り当て
  ├── Staging アカウント：シニア開発者のみに割り当て
  └── Prod アカウント：権限管理者のみに割り当て

4. SCIM プロビジョニング

HR システム（Workday・SuccessFactors 等）
  ↓ SCIM 2.0 API
Okta / Azure AD
  ↓ SCIM 2.0 API
IAM Identity Center
  ├── ユーザー作成・更新・削除の自動化
  └── グループ メンバーシップの自動同期

効果：IAM Identity Center でユーザーを手動作成する不要。HR で退職処理 → Okta で無効化 → 全 AWS アクセス即座に失効

5. Trusted Identity Propagation

エンドユーザー
  ↓ （ IAM Identity Center ログイン ）
AWS QuickSight
  ↓ （OAuth 2.0 authorization code flow）
Amazon Redshift / Amazon Athena
  ↓ （ユーザー ID を含むトークン）
データベース認証
  └─ SELECT * FROM sales WHERE user_id = ${user_id}

メリット： BI 人が複数ログインせず、QuickSight での一度のログインで Redshift を安全にクエリ可能。CloudTrail では個々のデータアクセスがユーザー単位で記録される。

アーキテクチャ

graph TB
    IdP["External IdP<br/>Okta / Azure AD / Google Workspace<br/>SAML 2.0 / OIDC"]
    IDC["IAM Identity Center<br/>ワークフォース・アイデンティティ管理"]
    Portal["アクセスポータル<br/>https://xxx.awsapps.com/start"]
    
    PermSet["Permission Set<br/>DeveloperAccess / AdminAccess<br/>ReadOnlyAccess"]
    AA["Account Assignment<br/>User/Group → Account + Role"]
    AppA["Application Assignment<br/>Slack / Salesforce / GitHub"]
    
    AWS1["AWS Account 1<br/>Dev"]
    AWS2["AWS Account 2<br/>Staging"]
    AWS3["AWS Account 3<br/>Prod"]
    
    TIP["Trusted Identity<br/>Propagation<br/>QuickSight → Redshift"]
    
    IdP -->|SAML+SCIM| IDC
    IDC --> Portal
    Portal --> AA
    AA --> AWS1
    AA --> AWS2
    AA --> AWS3
    Portal --> AppA
    Portal --> TIP
    PermSet --> AA
    
    style IdP fill:#e1f5ff
    style IDC fill:#fff3e0
    style Portal fill:#f3e5f5
    style PermSet fill:#e8f5e9
    style TIP fill:#fce4ec

Identity Source（アイデンティティソース）

IAM Identity Center で利用可能なアイデンティティソース：

推奨： エンタープライズ環境では Okta + SCIM がベストプラクティス。SCIM で自動プロビジョニング（人事システム ↔ IdP ↔ IAM Identity Center）が 1 本線で実現できます。

Permission Set（許可セット）

Permission Set の構成

{
  "PermissionSetArn": "arn:aws:sso:::permissionSet/org/ps-abc123",
  "Name": "DeveloperAccess",
  "Description": "開発環境向け権限セット",
  "SessionDuration": "PT12H",
  "ManagedPolicies": [
    "arn:aws:iam::aws:policy/PowerUserAccess"
  ],
  "InlinePolicy": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": ["ec2:TerminateInstances", "rds:DeleteDBInstance"],
        "Resource": "*"
      }
    ]
  },
  "Tags": [
    {"Key": "env", "Value": "dev"},
    {"Key": "purpose", "Value": "development"}
  ]
}

Account Assignment の実行

# AWS CLI で Account Assignment を作成
aws sso-admin create-account-assignment \
  --instance-arn "arn:aws:sso:::instance/sso-abc123" \
  --target-id "123456789012" \
  --target-type "AWS_ACCOUNT" \
  --permission-set-arn "arn:aws:sso:::permissionSet/org/ps-abc123" \
  --principal-type "GROUP" \
  --principal-id "engineers-group-id"

# 結果：engineers-group の全メンバーが、123456789012 アカウントで DeveloperAccess ロール を取得

Application Assignment（アプリケーション割り当て）

IAM Identity Center ポータルから SaaS アプリケーションへの SSO を提供：

アクセスポータル
  ├── AWS Accounts
  │   ├── Dev Account (DeveloperAccess)
  │   ├── Staging Account (ReadOnlyAccess)
  │   └── Prod Account (no access)
  │
  ├── Slack
  │   └── Click → Slack に SAML SSO でログイン
  │
  ├── Salesforce
  │   └── Click → Salesforce に SAML SSO でログイン
  │
  ├── GitHub Enterprise
  │   └── Click → GitHub に OIDC でログイン
  │
  ├── Jira
  │   └── Click → Jira に SAML SSO でログイン
  │
  └── Amazon Redshift
      └── Click → Redshift クエリエディタへの一時認証情報発行

対応アプリケーション（30+）：

• Slack、Microsoft Teams、Zoom
• Salesforce、HubSpot、Marketo
• GitHub Enterprise、GitLab
• Jira、Atlassian Confluence
• AWS Redshift、AWS Lake Formation
• Figma、Datadog

SAML 2.0 / OIDC フェデレーション

SAML 2.0 フロー

sequenceDiagram
    User->>Browser: IAM Identity Center ポータル訪問
    Browser->>IDC: アクセス要求
    IDC->>IdP: SAML AuthRequest 発行
    IdP->>User: ログイン画面表示（MFA 要求可）
    User->>IdP: クレデンシャル入力
    IdP->>Browser: SAML Assertion（署名済み）返却
    Browser->>IDC: SAML Assertion 送信
    IDC->>IDC: Assertion 検証（署名確認）
    IDC->>Browser: セッションクッキー発行
    Browser->>AWS: AWS API 呼び出し（一時認証情報使用）
    AWS->>Browser: リソース返却

OIDC（OpenID Connect）フロー

IAM Identity Center ↔ OIDC Provider
  ├── Authorization Code Flow
  │   └── OAuth 2.1 準拠、リフレッシュトークン対応
  ├── ID Token（OIDC）
  │   └── ユーザー属性（email・name・groups）含む JWT
  └── Access Token（OAuth 2.0）
      └── AWS リソースアクセス用

SAML と OIDC の使い分け：

• SAML： Okta・Azure AD・Google Workspace など企業 IdP との統合に推奨
• OIDC： API・マイクロサービス・モダン SPA の認証に推奨

SCIM プロビジョニング

SCIM 2.0 API による自動同期

Workday（HR システム）
  ↓ API
Okta
  ├── ユーザー新規作成イベント
  ├── メール変更イベント
  ├── グループ追加イベント
  └── 退職フラグイベント
  ↓ SCIM 2.0 API (User Provisioning API)
IAM Identity Center
  ├── 新規ユーザー自動作成
  ├── グループ メンバーシップ自動更新
  └── 退職者 自動削除 → 全 AWS アカウントアクセス即座に失効

SCIM エンドポイント設定（例：Okta）

Okta Admin Console → IAM Identity Center アプリケーション
  └── Provisioning → SCIM Connection
      ├── SCIM 2.0 Base URL：https://scim.sso.${region}.amazonaws.com/
      ├── Authorization：Bearer ${scim_token}
      └── Okta → Target (IAM Identity Center)
          ├── Create Users ✓
          ├── Update User Attributes ✓
          ├── Deactivate Users ✓
          └── Sync Password ✗

効果：

• Workday での新規雇用 → Okta 同期（即日）
• Okta でグループ変更 → IAM Identity Center グループ更新（数分）
• 退職者処理 → Okta 無効化 → IAM Identity Center から削除 → 全 AWS アクセス失効（数分）

Trusted Identity Propagation

ユースケース：BI ツール ↔ AWS Analytics

ビジネスユーザー（営業部）
  ↓ IAM Identity Center でログイン
Amazon QuickSight
  ├── 営業ダッシュボード表示
  ├── Redshift クエリ実行（営業ユーザー権限で）
  │   └── SELECT * FROM sales WHERE region = 'APAC'
  └── CloudTrail には「営業ユーザー X が Redshift に接続」と記録

Trusted Identity Propagation の実装

IAM Identity Center
  ↓ Trusted Identity Propagation 有効化
  ├── ユーザーの email・groups 属性を JWT に含める
  ├── Amazon QuickSight が ID Token を受け取る
  └── QuickSight が User ID と権限を AWS Redshift へ伝播
      └── Redshift のテーブルレベルセキュリティ（RLS）と連携
          例：CREATE RLS POLICY sales_by_region
              WHERE region IN (current_user_id::text SPLIT BY ',')

セキュリティメリット：

• ID 委譲が OAuth 2.0 標準に準拠
• ユーザーパスワード・API キーが AWS に渡らない
• 監査ログが個々のユーザー ID で記録可能
• クロスアカウント・クロス組織間での安全な ID 伝播

ABAC（属性ベースアクセス制御）

ABAC ポリシーの例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/department": "engineering",
          "aws:PrincipalTag/environment": "dev",
          "aws:ResourceTag/environment": "dev"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:TerminateInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/department": "finance"
        }
      }
    }
  ]
}

IAM Identity Center での ABAC の利用

Permission Set 定義時に属性を指定：
  ├── department = engineering
  ├── environment = dev
  ├── cost-center = 12345
  └── project = data-pipeline

ユーザー・グループに属性を割り当て：
  ├── Okta → AWS Attribute Mapping
  ├── email → email
  ├── department（Okta グループ） → department
  └── manager（Okta 属性） → manager

結果：
  attribute ベース で Permission Set が動的に評価される
  → 部門異動時に Okta だけで AWS アクセスが自動更新

AWS CLI SSO プロファイル

AWS CLI v2 での SSO 設定

# 初回設定
aws configure sso
  ✓ SSO session name: my-org
  ✓ SSO start URL: https://my-org.awsapps.com/start
  ✓ SSO Region: us-east-1
  ✓ CLI default client Region: ap-northeast-1
  
  → ブラウザが開く → IAM Identity Center でログイン
  → ブラウザで承認 → CLI が一時認証情報を ~/.aws/sso/cache に保存

# ログイン（毎回）
aws sso login --profile my-org

# AWS リソース操作
aws s3 ls --profile my-org
aws ec2 describe-instances --profile my-org
aws rds describe-db-instances --profile my-org

~/.aws/config の内容

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile my-dev]
sso_session = my-org
sso_account_id = 111111111111
sso_role_name = DeveloperAccess
region = ap-northeast-1

[profile my-prod]
sso_session = my-org
sso_account_id = 222222222222
sso_role_name = ViewOnlyAccess
region = ap-northeast-1

一時認証情報の自動取得

aws sso login --profile my-dev
  ↓
IAM Identity Center ポータルでログイン（MFA 確認）
  ↓
ブラウザで承認
  ↓
~/.aws/sso/cache/my-org.json に一時認証情報が保存
  {
    "accessToken": "...",
    "expiresAt": "2026-04-27T10:30:00Z"
  }
  ↓
以後 aws cli で自動的に一時認証情報を使用
  → アクセスキー管理不要、セキュアで期限自動切れ

IAM ユーザーとの比較

Migration パス：IAM ユーザー → IAM Identity Center

Phase 1（0-3 ヶ月）：
  ├── IAM Identity Center の有効化
  ├── IdP（Okta / Azure AD）との SAML 連携
  └── パイロット：開発チーム（10-20 名）での Permission Set テスト

Phase 2（3-6 ヶ月）：
  ├── SCIM プロビジョニング設定
  ├── 本番環境での Permission Set デプロイ
  └── 既存 IAM ユーザーと IAM Identity Center の並行運用

Phase 3（6-12 ヶ月）：
  ├── AWS CLI SSO プロファイルへの移行
  ├── 既存アクセスキーの廃止
  └── IAM ユーザー完全削除（Permission Boundary で制御）

Organization Instance vs Account Instance

アクセスポータル

ユーザーポータル（https://xxx.awsapps.com/start）

┌─────────────────────────────────────┐
│        IAM Identity Center Portal   │
│      User: john.doe@example.com     │
└─────────────────────────────────────┘
│ AWS Accounts                         │ Applications
├─────────────────────────────────────┼──────────────
│ Dev Account                         │ Slack
│  └─ DeveloperAccess (12 hours)      │  🔗 Sign in
│                                     │
│ Staging Account                     │ Salesforce
│  └─ ReadOnlyAccess (1 hour)         │  🔗 Sign in
│                                     │
│ Prod Account                        │ GitHub Enterprise
│  └─ (no access)                     │  🔗 Sign in
│                                     │
└─────────────────────────────────────┴──────────────

ポータルのカスタマイズ

# AWS CLI で ポータル設定を更新
aws identitystore create-user \
  --identity-store-id d-1234567890 \
  --user-name john.doe \
  --given-name John \
  --family-name Doe \
  --user-type PERSON \
  --emails Value=john.doe@example.com,Type=WORK,Primary=true

セキュリティ・監査

CloudTrail での監査ログ

{
  "eventSource": "sso.amazonaws.com",
  "eventName": "ListAccountsForProvider",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDAI2ZEX3ZGKRX4G72PK",
    "arn": "arn:aws:iam::111111111111:user/john.doe",
    "accountId": "111111111111"
  },
  "eventTime": "2026-04-26T10:15:00Z",
  "sourceIPAddress": "203.0.113.45",
  "userAgent": "aws-cli/2.13.0"
}

Access Analyzer との統合

IAM Access Analyzer で Permission Set に対して：
  ├── 過剰な権限の検出
  ├── 不要なアクションの特定
  └── 最小権限化の提案

例：DeveloperAccess Permission Set
  現在：PowerUserAccess（200+ アクション許可）
  提案：S3・EC2・RDS のみ に絞る（15 アクション）
  → 権限最小化で セキュリティスコア向上

他の類似ツールとの比較

AWS 環境での推奨：

• AWS のみ → IAM Identity Center
• AWS + Okta / Azure AD → IAM Identity Center + IdP（SAML 連携）
• SaaS 多数・マルチクラウド → Okta（Okta が IAM Identity Center へ SCIM で連携）

クライアント・エコシステム

AWS CLI / SDK

# boto3 で一時認証情報を自動取得
import boto3
from botocore import session

# IAM Identity Center 経由で認証
session = session.Session(profile_name='my-dev')
s3 = session.create_client('s3')
response = s3.list_buckets()
print(response['Buckets'])

IDE・エディタプラグイン

• VS Code AWS Toolkit： IAM Identity Center プロファイルをダイレクト選択
• JetBrains IDE： Okta 連携でシームレスな AWS アクセス
• IntelliJ IDEA： CloudFormation / IaC リソース管理

IaC（Infrastructure as Code）

# Terraform で IAM Identity Center リソース管理
resource "aws_ssoadmin_permission_set" "developer" {
  name             = "DeveloperAccess"
  instance_arn     = data.aws_ssoadmin_instances.this.arns[0]
  session_duration = "PT12H"
}

resource "aws_ssoadmin_permission_set_inline_policy" "developer" {
  inline_policy      = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["ec2:Describe*", "s3:GetObject"]
        Resource = "*"
      }
    ]
  })
  instance_arn       = data.aws_ssoadmin_instances.this.arns[0]
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
}

ベストプラクティス

✅ 推奨パターン

1. Organization Instance で一元管理

   Organization 管理アカウント
     ├── IAM Identity Center 有効化
     └── 全メンバーアカウントへのアクセス一元管理
   

2. IdP + SCIM 自動プロビジョニング

   HR System → Okta → IAM Identity Center → AWS Accounts
   （人事異動が AWS アクセスに自動反映）
   

3. Permission Set による権限の標準化

   DeveloperAccess / AdminAccess / ReadOnlyAccess
   → 全アカウント・全チームで一貫した権限管理
   

4. ABAC で属性ベースの動的制御

   department: engineering → dev アカウントアクセス許可
   department: finance → prod アカウントアクセス拒否
   

5. AWS CLI SSO で長期キーを廃止

   aws sso login → 一時認証情報（1 時間）
   → スクリプト・アプリケーション での安全な認証
   

6. CloudTrail で個別ユーザーレベルの監査

   CloudTrail ログに IAM Identity Center ユーザー名が記録
   → コンプライアンス・インシデント調査が容易
   

❌ アンチパターン

1. 個別 IAM ユーザー作成（非推奨）

   ❌ 各アカウントで手動作成・削除・パスワード管理
   ✓ IAM Identity Center + IdP 一元管理へ移行
   

2. IAM ユーザーの長期アクセスキーをスクリプト内に保存

   ❌ export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
   ✓ aws sso login → 一時認証情報（期限切れ自動）
   

3. Permission Set 未利用（ポリシー個別管理）

   ❌ 各アカウントで AdministratorAccess / ReadOnlyAccess を個別定義
   ✓ Permission Set で一度定義 → 全アカウント共通適用
   

4. リージョン単一でのデプロイ

   ❌ IAM Identity Center を us-east-1 のみ有効化
   ✓ 複数リージョンへレプリケーション（DR・レイテンシ対策）
   

5. 監査ログを無視

   ❌ CloudTrail ログを記録するだけで分析しない
   ✓ CloudTrail Lake / Athena で定期的にレポート（アノマリー検出）
   

トラブルシューティング

2025-2026 最新動向

1. Trusted Identity Propagation の強化

BI アプリケーション ↔ AWS Analytics の統合が深化

• Amazon QuickSight ↔ Redshift / Athena への native 統合
• OAuth 2.1（Bearer Token）によるトークンベース認証
• 行レベルセキュリティ（RLS）と組み合わせた細粒度制御

2. 多リージョン IAM Identity Center

複数リージョンへのレプリケーション対応

• グローバルエンタープライズの地理的冗長性確保
• 各リージョンでの一貫したアクセス管理
• DR（Disaster Recovery）シナリオでの可用性向上

3. AI 駆動の権限推奨・最適化

CloudTrail データベース + AI による自動分析

• 未使用権限の自動検出 → Permission Set の簡潔化提案
• 異常なアクセスパターンの自動検知
• セキュリティスコア の自動算出・改善提案

4. ABAC（属性ベース）の拡充

Permission Set における属性マッピングの詳細化

• department / cost-center / project / environment などの属性で動的に権限割り当て
• 部門異動時の自動アクセス更新

5. Application Assignment の拡大

40+ SaaS アプリケーションとの SAML / OIDC ネイティブ統合

• Slack / Salesforce / GitHub / Figma のワンクリック SSO
• OIDC プロバイダとしての IAM Identity Center

学習リソース

公式ドキュメント

1. AWS IAM Identity Center User Guide

   • https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
   • Permission Set、Account Assignment、SCIM プロビジョニング

2. Trusted Identity Propagation Overview

   • https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-overview.html
   • OAuth 2.0、BI アプリケーション統合

3. AWS IAM Identity Center Identity Sources

   • https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-sources.html
   • SAML / OIDC / SCIM 統合ガイド

ベストプラクティス・ブログ

1. AWS Security Blog - IAM Identity Center

   • Trusted Identity Propagation 実装ガイド
   • Permission Set 設計パターン

2. AWS Verified Access Integration with IAM Identity Center

   • Amazon Verified Access × IAM Identity Center
   • ゼロトラストセキュリティ実装

3. CloudQuery Blog - IAM Identity Center 2026 ガイド

   • https://www.cloudquery.io/blog/aws-identity-center-guide
   • 最新機能・SCIM プロビジョニング・ABAC 実装

オンライン研修・動画

• AWS re:Invent セッション：IAM Identity Center（毎年更新）
• AWS Learning - SSO コース：無料オンライン教材
• Okta + AWS IAM Identity Center ウェビナー：SCIM 実装デモ

オープンソース・ツール

1. Keycloak

   • OIDC / SAML サーバの OSS 実装
   • テスト・開発環境での Identity Provider デプロイ

2. MSAL（Microsoft Authentication Library）

   • Azure AD との統合ライブラリ
   • マイクロソフト環境との統合

実装例・活用シーン

シーン 1：100 人エンジニア組織での IAM Identity Center 導入

現状：
  100 人 × 10 アカウント = 1,000 IAM ユーザー
  退職時に 10 アカウント個別削除 → 工数 2-3 日

IAM Identity Center 導入後：
  ├── Okta に 100 人登録
  ├── IAM Identity Center に SCIM で同期
  ├── Okta グループで権限管理：
  │   ├── engineers-group → DeveloperAccess (dev・staging)
  │   ├── devops-group → AdminAccess (prod・platform)
  │   └── interns-group → ReadOnlyAccess (all)
  └── Permission Set で AWS アクセス一元管理
  
  退職者処理：Okta で無効化 → 全 10 アカウントアクセス即座に失効（5 分）

シーン 2：BI チームでの Trusted Identity Propagation

営業チーム（30 名）が Redshift データにアクセス：

従来：
  SQL ユーザーの作成（Redshift） → 名前・パスワード管理 → 権限設定
  月次：クエリログ分析→ユーザーの操作追跡が複雑

IAM Identity Center + Trusted Identity Propagation：
  営業チーム → IAM Identity Center ログイン（一度）
           → QuickSight ダッシュボード表示
           → QuickSight が Redshift に SQL ユーザーの ID を伝播
           → Redshift の RLS ポリシーで営業地域のデータのみ表示

  CloudTrail：「営業ユーザー X が Redshift に接続」→ ユーザー単位の監査可能

シーン 3：ABAC による環境・部門別アクセス制御

組織構成：
  ├── dev 部門（エンジニア 20 名）
  ├── ops 部門（運用・セキュリティ 5 名）
  └── finance 部門（財務・監査 3 名）

環境：dev / staging / prod

ABAC ポリシー設定：
  {
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalTag/department": "dev",
        "aws:ResourceTag/environment": "${aws:PrincipalTag/env}"
      }
    }
  }

結果：
  dev 部門 → dev 環境のインスタンスのみアクセス可
  ops 部門 → environment タグが管理者のため全環境アクセス可
  finance 部門 → department タグが finance のため全リソースアクセス不可
  
部門異動時：
  Okta でグループを変更 → SCIM で IAM Identity Center に同期 → タグ自動更新 → AWS アクセスが自動変更

導入ロードマップ

Phase 1：準備・評価（0-1 ヶ月）

Week 1-2：
  ☐ IAM Identity Center（Organization Instance）有効化
  ☐ IdP 選定：Okta / Azure AD / Google Workspace のいずれか
  ☐ SCIM エンドポイント（IAM Identity Center）確認
  ☐ パイロットユーザー（10-20 名）選定

Week 3-4：
  ☐ IdP with IAM Identity Center 統合テスト（SAML / SCIM）
  ☐ Permission Set 設計：DeveloperAccess / AdminAccess / ReadOnlyAccess
  ☐ Account Assignment テスト（パイロットチーム）
  ☐ AWS CLI SSO プロファイル設定テスト

Phase 2：パイロット・展開（1-3 ヶ月）

Month 2：
  ☐ パイロット グループ（開発チーム）への Permission Set 割り当て
  ☐ SCIM プロビジョニング 本運用開始（Okta → IAM Identity Center）
  ☐ CloudTrail ログの確認・分析
  ☐ ユーザーフィードバック収集

Month 3：
  ☐ 本番環境への Permission Set デプロイ
  ☐ 既存 IAM ユーザーと IAM Identity Center の並行運用
  ☐ Permission Set の微調整

Phase 3：全社展開・最適化（3-6 ヶ月）

Month 4-5：
  ☐ 全チーム（100+ 名）への IAM Identity Center 移行
  ☐ AWS CLI SSO への全面切り替え（アクセスキー廃止）
  ☐ ABAC ポリシー導入（department / environment タグベース）
  ☐ 監査ログレポート自動化（月次）

Month 6：
  ☐ Trusted Identity Propagation 本運用開始（BI・アナリティクス）
  ☐ Permission Set の定期レビュー・最適化
  ☐ Access Analyzer で未使用権限検出・削除
  ☐ セキュリティスコアカード（月次）の CISO 報告

実装チェックリスト

セットアップ チェックリスト

• [ ] AWS Organizations が有効化されている
• [ ] Organization 管理アカウントで IAM Identity Center を有効化
• [ ] IdP（Okta / Azure AD）との SAML 2.0 連携完了
• [ ] IAM Identity Center SCIM エンドポイント確認
• [ ] SCIM トークン生成・IdP 側に設定
• [ ] Permission Set 3 種類最低限度：DeveloperAccess / AdminAccess / ReadOnlyAccess
• [ ] Account Assignment テスト完了（パイロットユーザー）
• [ ] アクセスポータル（https://xxx.awsapps.com/start）動作確認
• [ ] Application Assignment テスト（Slack / GitHub 等）

セキュリティ チェックリスト

• [ ] IAM Identity Center で MFA 必須化
• [ ] Permission Set に Permission Boundary 設定（過度な権限チェック）
• [ ] CloudTrail ログ有効化・長期保存（90 日以上）
• [ ] CloudTrail Lake または Athena で ログ分析
• [ ] IAM Access Analyzer で外部アクセス検出有効化
• [ ] Trusted Identity Propagation でのトークン署名検証
• [ ] SCIM トークンの定期ローテーション（3-6 ヶ月）
• [ ] リージョン間レプリケーション での冗長性確保

運用 チェックリスト

• [ ] 月次：Permission Set 権限レビュー（Okta との差異確認）
• [ ] 月次：CloudTrail ログ分析・レポート作成
• [ ] 四半期：セキュリティスコアカード の CISO 報告
• [ ] 四半期：Permission Set の AWS managed policy バージョン更新
• [ ] 半年：ABAC ポリシーの効果測定
• [ ] 年次：Trusted Identity Propagation 実装の監査

まとめ

IAM Identity Center は AWS Organizations 環境における ID 管理の標準となるサービス です。以下に要点をまとめます。

主要機能

1. マルチアカウント SSO：複数 AWS アカウントへの統一ログイン
2. IdP 統合：Okta・Azure AD との SAML 2.0 / OIDC / SCIM ネイティブ連携
3. Permission Set：複数アカウント共通の職種別ロール一元管理
4. SCIM プロビジョニング：HR システムからのユーザー自動同期
5. Trusted Identity Propagation：BI アプリケーション ↔ AWS Analytics への安全な ID 伝播
6. ABAC：属性ベースの動的アクセス制御（部門異動時の自動更新）
7. AWS CLI SSO：一時認証情報での長期キー廃止

導入メリット

• コスト削減：IAM ユーザー管理工数 70%+ 削減（自動プロビジョニング）
• セキュリティ向上：一時認証情報・CloudTrail 個別ユーザー記録・ABAC
• コンプライアンス：統一された監査ログ・アクセス証拠資料の自動生成
• ユーザー体験：シングルサインオン・複数 SaaS アプリのワンクリック SSO

推奨される採用判断

• 複数 AWS アカウント環境（2+ アカウント） → 必須
• 100+ エンジニア組織 → 最高優先度
• IdP（Okta・Azure AD）をすでに導入 → 即座に連携すべき
• セキュリティ・コンプライアンス要件が厳しい業界 → ABAC + Trusted Identity Propagation での実装推奨

IAM Identity Center は シンプルで強力で無料 です。AWS Organizations を使用している場合、IAM ユーザー管理からの移行は セキュリティ・コンプライアンス・運用効率の最大化 をもたらす投資です。

参考文献

AWS 公式ドキュメント

1. AWS IAM Identity Center User Guide

   • https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

2. Trusted Identity Propagation

   • https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-overview.html
   • https://aws.amazon.com/blogs/security/how-to-implement-trusted-identity-propagation-for-applications-protected-by-amazon-cognito/

3. AWS Verified Access Integration

   • https://aws.amazon.com/blogs/networking-and-content-delivery/aws-verified-access-integration-with-aws-iam-identity-center-and-saml-2-0-identity-providers/

4. IAM Identity Center SAML Integration Guide

   • https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-user-provisioning.html

ベンダー・OSS リソース

1. Okta IAM Identity Center Guide

   • https://www.okta.com

2. Microsoft Entra ID（Azure AD）

   • https://learn.microsoft.com/en-us/entra/

3. Keycloak - OpenID Connect & SAML Server

   • https://www.keycloak.org/

4. Ping Identity

   • https://www.pingidentity.com/

クラウドセキュリティ・ベストプラクティス

1. AWS Security Best Practices

   • https://aws.github.io/aws-security-services-best-practices/

2. OASIS - SAML 2.0 Specification

   • https://wiki.oasis-open.org/security

3. OAuth 2.1 Authorization Framework

   • https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1

4. SCIM 2.0（System for Cross-domain Identity Management）

   • https://tools.ietf.org/html/rfc7644

最終更新：2026-04-26 バージョン：v2.0