あなたの会社（アカウントA）はサードパーティのクラウドセキュリティ監視サービス（Vendor B）を契約しました。Vendor Bはアカウント AのCloudTrailログとGuardDutyの検出結果を定期取得するため、アカウントAのIAMロールをAssumeRoleする必要があります。Vendor Bは同じ仕組みで数百社の顧客にサービスを提供しており、顧客ごとに同一のVendor B AWSアカウントIDが使われています。 この構成で発生し得るセキュリティリスクと、それを防ぐための最も適切な対策はどれですか？
Vendor Bが複数顧客のアカウントへアクセスできる立場にある場合、悪意ある第三者がVendor BのAWSアカウントIDのみを知ることで、他顧客のロールを不正にAssumeRoleできてしまう「混乱した代理人問題（Confused Deputy Problem）」が発生します。sts:ExternalId は顧客ごとに異なる秘密の識別子を信頼ポリシーに組み込むことで、正当な顧客からの要求のみを受け付けるようにします。これにより、Vendor BのAWSアカウントIDが同じであっても、外部IDが異なれば他顧客のロールはAssumeRoleできません。 選択肢A の Vendor B の AWSアカウントIDが将来変更される可能性を考慮し、信頼ポリシーの Principal を定期的に自動検証・更新する Lambda 関数を実装するは、根本的な混乱した代理人問題を解決せず、運用コストが増加するだけです。 選択肢C の Vendor B のIAMロールに aws:MultiFactorAuthPresent 条件を追加し、Vendor B のオペレーターが毎回MFAを入力してからAssumeRoleするよう要求するは、システム間の自動連携（machine-to-machine）には適用困難であり、混乱した代理人問題も解決しません。 選択肢D の Vendor B のIAMロールに ReadOnlyAccess 管理ポリシーのみをアタッチし、Vendor B 側での追加制限に委ねることで責任を分担するは、要件によっては過剰権限となる可能性があり、ExternalIdによる認証強化も行われないため不十分です。