変更要約: SCS-C02 第4章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
4.2フェデレーションとクロスアカウントアクセス
一時認証とフェデレーション——IAM ロール（AssumeRole）、SAML/OIDC フェデレーション、IAM Identity Center、外部 ID（ExternalId）、STS——を理解します。長期キーを排し安全に委任します。
安全なアクセスは一時認証情報で実現します。長期キーを配らず、ロールの引き受けやフェデレーションを使います。
4.2.1一時認証とフェデレーション
- AssumeRole/STS：ロールを引き受け、一時認証情報で動作（長期キー不要）。
- SAML/OIDC フェデレーション：企業 IdP の既存 ID で AWS にアクセスする。
- IAM Identity Center：複数アカウントへの SSO と許可セットを一元管理。
- 信頼ポリシー/ExternalId：誰が引き受け可能かを定義。外部委託先は ExternalId で混乱した代理問題を防ぐ。
「一時認証情報＝AssumeRole/STS（長期キー禁止）」「企業 ID 連携＝SAML/OIDC フェデレーション」「複数アカウント SSO＝IAM Identity Center」「外部委託先＝ExternalId で混乱した代理問題を防ぐ」 は SCS-C02 で頻出です。クロスアカウントロールは信頼ポリシー（誰が）と許可ポリシー（何を）の両方が必要です。
SCS-C02 のフェデレーション設計は「長期キーを排し、一時認証情報で安全に委任する」ことを問います。STS が発行する一時認証情報は有効期限が短く、漏洩時の被害を限定します。クロスアカウントロールは、引き受けられる側に信頼ポリシー（誰が AssumeRole できるか＝Principal）と許可ポリシー（何ができるか）の両方を設定し、引き受ける側には sts:AssumeRole の許可が必要です。企業 ID 連携は、SAML 2.0 を使う SAML フェデレーション（AD FS 等）、Web/モバイルや GitHub Actions 等の OIDC フェデレーション（AssumeRoleWithWebIdentity）で、IdP の ID に IAM ロールをマッピングします。マルチアカウントの人間アクセスは IAM Identity Center が定番で、外部 IdP（Entra ID/Okta 等）と連携し、許可セットでアカウント横断のアクセスを一元管理します（アカウントごとに IAM ユーザーを作らない）。第三者（SaaS ベンダー等）にロールを渡す場合は、信頼ポリシーに ExternalId 条件を加えて混乱した代理（confused deputy）問題——攻撃者が別顧客になりすましてベンダー経由でアクセスする——を防ぎます。原則として人間にもサービスにも長期 IAM ユーザー/アクセスキーを配らず、ロール引き受けやフェデレーションで一時認証にします。設計の要は、STS 一時認証＋信頼/許可ポリシーの二段、企業 ID は SAML/OIDC、人の SSO は Identity Center、第三者は ExternalId、を正しく使い分けることです。
| シナリオ | 手段 | 要点 |
|---|---|---|
| アカウント間アクセス | AssumeRole（信頼＋許可） | 一時認証・長期キー不要 |
| 企業 ID で AWS 利用 | SAML / OIDC フェデレーション | IdP の ID にロールをマップ |
| 複数アカウントの人 SSO | IAM Identity Center | 許可セット・外部 IdP 連携 |
| 外部委託先へ委任 | ExternalId 条件 | 混乱した代理問題を防ぐ |
シナリオ：監視 SaaS ベンダーに、自社アカウントの読み取りロールを引き受けさせたい。なりすましは防ぎたい。→ ベンダー用のクロスアカウントロールを作り、信頼ポリシーでベンダーのアカウントを Principal に、かつ ExternalId 条件（ベンダーが各顧客に発行する一意の ID）を必須化。これで他顧客になりすました第三者がこのロールを引き受けられず、混乱した代理問題を防げます。許可ポリシーは読み取り専用に最小化し、STS の一時認証で動作します。
FAQ：SAML フェデレーションと IAM Identity Center はどう違う？ SAML フェデレーションは IAM に IdP を登録しロールにマッピングする従来方式で、個別に構成します。IAM Identity Center は複数アカウント/アプリへの SSO と許可セットを一元管理するマネージドな仕組みで、外部 IdP 連携も容易です。新規のマルチアカウント環境では Identity Center が推奨されます。どちらも長期キーを排し一時認証にする点は共通です。
ひっかけ：クロスアカウントアクセスのために「相手アカウントの長期アクセスキーを自分のアカウントに保存」するのは誤り——漏洩リスクが高くアンチパターンです。正解はロールを AssumeRole で引き受ける（一時認証）。また外部 SaaS にロールを渡すのに ExternalId を付けないと、混乱した代理問題で他顧客になりすました攻撃者にアクセスされる恐れがあります。
4.2.2この節のまとめ
- 一時認証＝AssumeRole/STS／企業 ID＝SAML/OIDC
- SSO＝IAM Identity Center／外部委託＝ExternalId
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. アカウント A のアプリがアカウント B のリソースに、長期キーを持たず安全にアクセスしたい。何を使いますか？
Q2. 外部の委託先にクロスアカウントロールを渡す際、混乱した代理問題を防ぎたい。何を条件に加えますか？
Q3. 従業員が既存の社内 ID で複数 AWS アカウントへ SSO できるようにしたい。何を使いますか？