ある企業は STS の AssumeRole を使ってマルチアカウント環境でアクセス管理をしています。セキュリティチームは「AssumeRole 呼び出し時に追加条件を付けてなりすまし攻撃（confused deputy problem）を防ぎたい」と要件を出しました。最も効果的な対策はどれですか？
- A. ロールに MFA 条件（aws:MultiFactorAuthPresent: true）を追加する
- B. ロールの Trust Policy に Condition として aws:SourceAccount または aws:SourceArn 条件キーを追加する
- C. ロールの Permission Boundary を設定して実行できるアクションを制限する
- D. AssumeRole の DurationSeconds を最小値（900 秒）に設定する
解答と解説を見る
正解: B
Confused Deputy 問題は、信頼された第三者サービスが悪意あるリクエストに乗っかって意図しないロールを引き受けてしまう攻撃パターンです。Trust Policy の Condition で aws:SourceAccount や aws:SourceArn を指定することで、「特定のアカウント・特定のリソースからの AssumeRole 要求のみ許可」と制限でき、この攻撃を防止できます。D の有効期間短縮は認証情報の有効時間を減らすだけで Confused Deputy を防ぎません。A の MFA 条件はヒューマンオペレーターには有効ですが、サービス間の自動 AssumeRole では適用できません。C の Permission Boundary は実行できる操作の上限を設定するものであり、Trust Policy の問題である Confused Deputy とは別の制御です。