変更要約: 軸B網羅: ガバナンス/セキュリティ/EUC 関連サービスのカタログ節(s4)を追加
1.2クロスアカウントアクセスと ID 連携
複数アカウント間の安全なアクセス——クロスアカウント IAM ロール、IAM Identity Center（SSO）、SAML/OIDC フェデレーション、Resource Access Manager（RAM）——を理解します。最小権限で組織横断のアクセスを設計します。
複数アカウントでは、ロールの引き受け（AssumeRole）とID の一元化が鍵です。長期キーを配らず、一時的な認証情報で安全にアクセスします。
1.2.1クロスアカウントと ID 連携
- クロスアカウント IAM ロール：別アカウントのロールを sts:AssumeRole で引き受け、一時認証情報で操作する。信頼ポリシーで誰が引き受け可能かを定義。
- IAM Identity Center（旧 AWS SSO）：複数アカウント/アプリへのシングルサインオンと許可セットを一元管理する。
- フェデレーション：企業の IdP（SAML 2.0/OIDC）と連携し、既存 ID で AWS にアクセスする。
- Resource Access Manager（RAM）：VPC サブネットや Transit Gateway などのリソースをアカウント間で共有する。
「複数アカウント＋既存企業 ID への SSO＝IAM Identity Center」「別アカウントのロールを引き受け＝sts:AssumeRole＋信頼ポリシー」「リソース共有（サブネット等）＝AWS RAM」「外部 IdP 連携＝SAML/OIDC フェデレーション」 は SAP-C02 で頻出です。長期アクセスキーの配布は避け、一時認証情報を使うのが鉄則です。
クロスアカウントロールには信頼ポリシー（誰が引き受け可能か）と許可ポリシー（何ができるか）の2つが必要です。外部委託先には外部 ID（ExternalId）条件で「混乱した代理問題」を防ぎます。
組織横断のアクセスは「人間」と「ワークロード」で設計が分かれます。人間は IAM Identity Center に外部 IdP（SAML 2.0 / SCIM でのユーザー同期）を接続し、許可セット（ジョブ機能別の権限テンプレ）を OU/アカウントへ割り当ててポータルから SSO。ワークロード/クロスアカウントは IAM ロール を sts:AssumeRole で引き受け、信頼ポリシー（誰が引き受け可能か）＋許可ポリシー（何ができるか）の二本立て。長期アクセスキーは配らず一時認証情報を使い、EC2/Lambda 等は インスタンスプロファイル/実行ロール で資格情報レス。外部 SaaS など第三者には ExternalId で「混乱した代理（confused deputy）」を防ぎ、aws:PrincipalOrgID 条件で組織内に限定できます。きめ細かな委譲には permissions boundary（付与可能な上限）や ABAC（タグベース認可）。リソース共有は AWS RAM（サブネット・Transit Gateway・Route 53 Resolver ルール・カタログ等を共有）。ID の一元化（Identity Center）＋一時認証（AssumeRole）＋最小権限が鉄則です。
| 要件 | 使うもの | ポイント |
|---|---|---|
| 人間のSSO（複数アカウント） | IAM Identity Center＋許可セット | 外部 IdP を SAML/SCIM で連携 |
| 別アカウントへのアクセス | クロスアカウント IAM ロール | AssumeRole＋信頼/許可ポリシー |
| 第三者の引き受け | ExternalId 条件 | 混乱した代理を防止 |
| リソース共有 | AWS RAM | サブネット/TGW 等を共有 |
シナリオ： 外部の監視ベンダーに、自社アカウントの読み取り専用アクセスを安全に与えたい。→ クロスアカウント IAM ロールを作り、信頼ポリシーでベンダーのアカウントを許可しつつ ExternalId 条件を付与（混乱した代理を防止）、許可ポリシーは読み取り専用に限定。長期キーは渡さず、ベンダーは AssumeRole で一時認証情報を得ます。
FAQ： Q. 人間のアクセスとワークロードのアクセスは何で分ける？ → A. 人間は IAM Identity Center（SSO＋許可セット）、ワークロード/クロスアカウントは IAM ロールの AssumeRole。どちらも一時認証情報。Q. ExternalId は何のため？ → A. 第三者にロールを引き受けさせる際の「混乱した代理」攻撃を防ぐ合言葉です。
ひっかけ： 「別アカウント連携のため長期アクセスキーを相手に渡す」は誤りです。クロスアカウントは AssumeRole＋信頼ポリシーで一時認証情報を使うのが鉄則。また「複数アカウントの人間アクセスにアカウントごとの IAM ユーザーを作る」も誤り（IAM Identity Center で一元化する）。
1.2.2この節のまとめ
- クロスアカウント＝AssumeRole＋信頼ポリシー（一時認証情報）
- 一元 ID＝IAM Identity Center／外部 IdP＝SAML/OIDC／共有＝RAM
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 従業員が既存の社内 ID で、複数の AWS アカウントにシングルサインオンできるようにしたい。何を使いますか？
Q2. アカウント A のアプリが、アカウント B のリソースに一時的な認証情報で安全にアクセスする標準的な方法はどれですか？
Q3. 中央のネットワークアカウントで作成した VPC サブネットを、他のメンバーアカウントと共有して使わせたい。何を使いますか？