SAA-032
外部のSaaS監視ベンダーに対し、自社AWSアカウントのリソースを読み取る権限を委譲する必要があります。ベンダーはベンダー自身のAWSアカウントからAPIを呼び出します。混乱した代理人（confused deputy）問題を防ぎながらアクセスを委譲する構成として、最も適したものはどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：C. ベンダーのAWSアカウントを信頼するIAMロールを作成し、信頼ポリシーのCondition句でsts:ExternalIdにベンダーが発行した一意の値を要求する
解説
サードパーティへのクロスアカウントアクセスでは、IAMロールの信頼ポリシーにsts:ExternalIdのCondition句を加えるのがAWSの推奨です。External IDを知らない第三者は、ベンダーのアカウント経由であってもロールを引き受けられないため、混乱した代理人問題を防げます。
選択肢ごとの解説
A. 対象リソースごとにリソースベースポリシーを追加し、ベンダーのAWSアカウントに読み取りを許可する
リソースベースポリシーで許可できるのはS3バケットやKMSキーなど一部のサービスに限られ、読み取り対象が増えるたびに個別追加が必要になります。運用が破綻しやすく、External IDによる保護もありません。
B. ベンダー専用のIAMユーザーを作成してReadOnlyAccessをアタッチし、発行したアクセスキーをベンダーへ共有して90日ごとにローテーションする
長期のアクセスキーを外部組織へ渡す方式は、漏洩時の影響範囲が大きく、失効も手動になります。ローテーションを行っても、クロスアカウントではIAMロールによる一時的な認証情報が推奨されます。
C. ベンダーのAWSアカウントを信頼するIAMロールを作成し、信頼ポリシーのCondition句でsts:ExternalIdにベンダーが発行した一意の値を要求する
正解です。ベンダーが発行するExternal IDを信頼ポリシーのConditionで必須にすることで、混乱した代理人問題を構造的に防げます。
D. ベンダーのAWSアカウントIDのみを信頼するIAMロールを作成し、ReadOnlyAccessをアタッチする
ロールを使う点は正しいですが、External IDがないとベンダーが他の顧客用に持つ権限と取り違えて自社リソースを操作してしまう混乱した代理人問題を防げません。要件を満たしていません。
実務での使いどころ
AWS アカウントをまたいだ権限委譲は、IAM ユーザーとアクセスキーの共有ではなく、IAM ロールと AWS STS の AssumeRole で行うのが原則である。委譲する側（自社）がロールを作り、信頼ポリシーの Principal に相手のアカウント ID やロール ARN を書く。相手は AssumeRole を呼んで一時的な認証情報を取得し、その有効期限が切れれば自動的に権限が消える。長期のアクセスキーを外部へ渡す方式と比べ、漏洩時の露出時間が短く、信頼ポリシーを消すだけで即座に遮断できる点が大きい。 サードパーティ SaaS のように「1 つのベンダーが多数の顧客アカウントに対して同じ仕組みでアクセスする」ケースでは、混乱した代理人（confused deputy）問題が発生しうる。ベンダーが顧客 A のロール ARN を誤って（あるいは攻撃者に誘導されて）指定すると、顧客 A の意図しない操作が行われてしまう。これを防ぐために、信頼ポリシーに Condition で sts:ExternalId を要求する。External ID はベンダーが顧客ごとに発行する一意の文字列で、秘密情報ではなく「取り違え防止のための識別子」として機能する。加えて、委譲する権限は ReadOnlyAccess のようなマネージドポリシーそのままではなく、必要な API に絞ったカスタムポリシーにするのが望ましい。 SAA-C03 では「外部ベンダー」「他社アカウント」「confused deputy」「External ID」というキーワードが登場したら、IAM ロール + sts:ExternalId が正解になる。誤答には IAM ユーザーのアクセスキー共有、ルートユーザーの認証情報共有、条件なしのクロスアカウントロールが並ぶ。自社の複数アカウント間（AWS Organizations 配下）であれば External ID は不要で、代わりに SCP や aws:PrincipalOrgID 条件を使うという区別も押さえておきたい。