IAM Identity Centerとフェデレーション

1. 従業員アクセスは「アイデンティティの場所」と「AWS権限」を分ける

企業ではすでにMicrosoft Entra ID、Okta、アクティブディレクトリなどで社員アイデンティティを管理していることがあります。

社員2,000人
×
AWSアカウント 50個
↓
各アカウントへIAM ユーザーを作成

とは考えません。まず次の順序で分解します。

アイデンティティはどこで管理する？
        ↓
どうAWSとフェデレーションする？
        ↓
どのAWSアカウントへ入れる？
        ↓
そこで何を許可する？

2. AWS IAM Identity Centerは従業員アクセスの中央管理ポイント

AWS IAM Identity Centerは、ワークフォースユーザーやグループについて、AWSアカウントやアプリケーションへのアクセスを中央管理するためのサービスです。

企業ユーザー
      │
      ▼
外部IdP
      │
      ▼
IAM Identity Center
      │
 ┌────┼────┐
 ▼    ▼    ▼
開発テスト本番
AWSアカウント

社員ごとに各AWSアカウントへIAMユーザーを作成せずにアクセスを管理できます。外部IDプロバイダーとしてMicrosoft Entra IDやOktaなどを接続することもできます。

3. まずIDソースを決める

AWS IAM Identity Centerでは、ユーザーやグループをどこで管理するかをIDソースとして選択します。

既存の企業IdPで社員アイデンティティをすでに一元管理しているなら、AWS用に別アイデンティティを大量作成するより、既存アイデンティティを接続する設計をまず評価します。

既存企業アイデンティティ
↓
外部IdP
↓
IAM Identity Center

AWS IAM Identity Centerの各インスタンスでは、1つのIDソースを選択します。

4. フェデレーションとは何か

フェデレーションは、AWS外部で管理しているアイデンティティを使用してAWSへアクセスさせる考え方です。

従業員
   │
   ▼
企業IdP
   │
   │ フェデレーション
   ▼
AWS

社員ごとにAWS専用の長期認証情報を作成する必要を減らせます。人アクセスでは、企業アイデンティティを起点に一時的な認証情報へつなげる設計を基本にします。

5. 外部IdPとSAML 2.0

外部IDプロバイダーをAWS IAM Identity Centerへ接続する場合、SAML 2.0を使用したアイデンティティフェデレーションを利用できます。

従業員
   │
   ▼
外部IdP
   │
   │ SAML 2.0
   ▼
IAM Identity Center

SAML 2.0は、IdPとサービス提供側の間でユーザーに関する情報を受け渡し、フェデレーションによるSSOを成立させるための標準です。

6. SAMLは「AWSで何を許可するか」を決めない

SAML
↓
誰として認証されたか
フェデレーションを成立させる

アクセス許可セット
↓
AWSアカウント内で
何を許可するか

例えばEntra IDでデータベース管理者グループに所属していることだけでは、RDSを変更できるとは決まりません。AWS側でそのユーザーまたはグループへ、対象AWSアカウントと適切なアクセス許可セットを割り当てる必要があります。

SAML 認証
≠
AWS 認可

7. SAMLはユーザー / グループ同期そのものではない

SAML 2.0はフェデレーションを担当しますが、外部IdP内のユーザーやグループ一覧をAWS IAM Identity Centerへ自動同期する仕組みそのものではありません。

外部IdPのユーザーやグループをAWS IAM Identity Centerへプロビジョニングする方法として、SCIMを利用できます。

SAML
→ 認証 / フェデレーション

SCIM
→ ユーザー / グループプロビジョニング

ここではSAMLとプロビジョニングの責任を混同しないことを押さえます。

8. アクセス権限はアクセス許可セットで定義する

AWS IAM Identity Centerでは、AWSアカウント内でユーザーやグループに与えるアクセスレベルをアクセス許可セット（権限セット）として定義します。

読み取り専用

開発者

データベース管理者

アクセス許可セットはAWS IAM Identity Centerに保存され、1つまたは複数のAWSアカウントへプロビジョニングできます。

9. アクセス許可セットそのものがIAMロールではない

例えばDeveloperAccessというアクセス許可セットを作成しただけで、人アイデンティティがIAMロールになったわけではありません。

アクセス許可セット
DeveloperAccess
        │
        │ 割り当て
        ▼
AWSアカウント A
AWSReservedSSO_...
IAMロール

アクセス許可セットをAWSアカウントへ割り当てると、AWS IAM Identity Centerはそのアカウントへ対応するIAMロールを作成・管理し、アクセス許可セットで指定した権限を反映します。

アクセス許可セット
→ AWS側アクセス定義

プロビジョニングされたIAMロール
→ 実際にアカウント内で利用されるロール

10. 割り当ては3つの要素で考える

AWSアカウントアクセスは次の組み合わせです。

誰に？
+
どのAWSアカウントへ？
+
どのアクセス許可セットで？

例えば同じ開発者 グループでも、アカウントごとに異なる権限を割り当てられます。

開発者 グループ
│
├─ 開発アカウント
│    → DeveloperAccess
│
└─ 本番アカウント
     → 読み取り専用

同じユーザー / グループだから、すべてのAWSアカウントで同じ権限になるわけではありません。

11. グループ単位でエンタープライズアクセスを管理する

社員数が多い場合、ユーザー1人ずつ大量のアカウント割り当てを管理すると運用負荷が高くなります。

開発者
セキュリティ監査担当者
データベース管理者

などのグループ単位でAWSアカウントアクセスを設計すると管理しやすくなります。異動時には、企業IdP側のグループメンバーシップ変更とプロビジョニングを起点にアクセス管理できます。

12. AWSアカウントアクセスでは一時的な認証情報を使う

AWS IAM Identity CenterからAWSアカウントへアクセスするとき、社員へ長期アクセスキーを標準配布する必要はありません。

従業員
↓
企業IdP
↓
IAM Identity Center
↓
割り当てられたアクセス許可セット
↓
IAMロールセッション
↓
一時的な認証情報

許可されたユーザーは、対象アカウントにプロビジョニングされたAWS IAM Identity Center管理のIAMロールを利用し、一時的な認証情報でAWSへアクセスします。

13. コンソールだけでなくCLIでも一時的な認証情報を使える

開発者がAWS CLIを利用する場合も、各開発者へ長期アクセスキーを手動発行する必要はありません。

AWS CLIはAWS IAM Identity Centerへのサインインを利用し、一時的な認証情報を取得・更新できます。

人 CLI アクセス
+
長期アクセスキーを避けたい
↓
IAM Identity Center
+
一時的な認証情報

重要なのはCLIコマンド暗記ではなく、人アクセスに長期認証情報を常用しない設計判断です。

14. セッションには有効期限がある

一時的な認証情報は永久に有効な認証情報ではありません。AWS IAM Identity Centerではアクセス許可セットごとにAWSアカウントセッション継続時間を設定できます。

現在は1時間がデフォルトで、1〜12時間の範囲で設定できます。

ただしSAP-C02では数値そのものより、AWS IAM Identity Centerの人アクセスは期限のあるロールセッションを利用することを優先して理解します。

15. 複数AWSアカウントを管理するなら組織インスタンス

現在AWS IAM Identity Centerには、組織インスタンスとアカウントインスタンスがあります。

複数AWSアカウントへの従業員アクセスをアクセス許可セットで管理する場合は、組織インスタンスを使用します。

アカウントインスタンスはアクセス許可セットをサポートせず、AWSアカウントアクセス管理には使用できません。多アカウント環境のアクセス許可セットを設計する場合は組織インスタンスと判断します。

16. IAMへ直接SAML フェデレーションする方式も存在する

SAML フェデレーションはAWS IAM Identity Centerだけの仕組みではありません。IAMへSAML IdPを登録し、AWS STSのAssumeRoleWithSAMLを利用してIAMロールへフェデレーションする方式もあります。

外部IdP
↓
SAMLアサーション
↓
AWS STS AssumeRoleWithSAML
↓
IAMロール
↓
一時的な認証情報

ただし、多数の従業員ユーザー、多数のAWSアカウント、中央アクセス管理が要件なら、AWS IAM Identity Centerを中心に設計することで管理ポイントを集約できます。

ここではAssumeRoleWithSAMLのAPI仕様やSAML ロールの細かな設定までは扱いません。

17. 要件から設計を選ぶ

18. 混同ポイント

• AWS IAM Identity Center = IAMユーザーの中央管理：従業員フェデレーションとAWSアカウントアクセスを中央管理します。
• 外部IdP = AWS権限を決定する場所：AWS側の権限はアクセス許可セットと割り当てで決まります。
• SAML = ユーザー / グループ同期：SAMLは認証 / フェデレーションを担当します。
• 権限セット = IAMユーザー：別の概念です。
• 権限セット = IAMロールそのもの：割り当てに応じて対象AWSアカウントへ対応IAMロールがプロビジョニングされます。
• AWS IAM Identity Center = 長期アクセスキーを配布するサービス：AWSアカウントアクセスでは一時的な認証情報を利用します。
• フェデレーション = 必ずAWS IAM Identity Center：IAMへの直接SAML フェデレーションも存在します。

19. SAP-C02判断フロー

人従業員アクセスが必要
        │
        ▼
既存企業アイデンティティがある？
        │
   ┌────┴─────┐
  はい      いいえ
   │           │
   ▼           ▼
外部AWS IAM Identity Center
IdP          ディレクトリなど
   │
   ▼
SAML 2.0
フェデレーション
   │
   ▼
IAM Identity Center
   │
   ▼
誰に？
ユーザー / グループ
   │
   ▼
どのAWSアカウントへ？
   │
   ▼
どのアクセス許可セット？
   │
   ▼
AWS IAM Identity Center管理
IAMロール
   │
   ▼
一時的な認証情報

20. まとめ

エンタープライズ従業員アクセス
↓
IDソースを決める

既存企業IdP
→ 外部IdPとして接続

SAML 2.0
→ 認証 / フェデレーション

IAM Identity Center
→ 従業員アクセスの中央管理

アクセス許可セット
→ AWSアカウント内のアクセスレベル

割り当て
→ ユーザー / グループ
   × AWSアカウント
   × アクセス許可セット

割り当て後
→ 対応IAMロールをプロビジョニング

人のアクセス
→ 一時的な認証情報

SAML
≠
ユーザー / グループプロビジョニング

マルチアカウント + アクセス許可セット
→ 組織インスタンス

最重要ポイントは、外部IdPで誰なのかを確認することと、AWSアカウント内で何を許可するかを分離し、その間をAWS IAM Identity Centerで中央管理することです。

21. 主要AWS公式資料

• AWS IAM Identity CenterのIDソース
• 外部IDプロバイダー
• SAML 2.0とSCIM
• アクセス許可セット
• 組織インスタンスとアカウントインスタンス
• IAMへのSAML 2.0 フェデレーション