あなたの会社はAWSリソースを顧客に代わって管理するマルチテナントSaaSサービスを提供しています。各顧客は自社のAWSアカウントにIAMロールを作成し、あなたの会社のAWSアカウント（ID: 111122223333）を信頼するよう設定します。あなたの会社はそのロールをAssumeRoleして顧客リソースを管理します。セキュリティ監査で「混乱した代理（Confused Deputy）攻撃※」のリスクが指摘されました。この脆弱性を防ぐための最も適切な対策はどれですか？ ※混乱した代理攻撃：権限を持つサービス（代理）が、悪意ある第三者の指示により、意図しない別テナントのリソースにアクセスしてしまう問題。
混乱した代理攻撃は、悪意ある顧客が他の顧客のロールARNをSaaSプロバイダーに渡し、SaaSプロバイダーに別顧客のロールをAssumeRoleさせることで成立します。これを防ぐのが `sts:ExternalId` です。 SaaSプロバイダーは各顧客に一意のExternalId（推測不能なUUIDなど）を発行し、顧客のロール信頼ポリシーにその値を条件として設定させます。SaaSプロバイダー側はAssumeRole時に顧客固有のExternalIdを必ず指定することで、悪意ある第三者が別顧客のロールARNを指定しても、ExternalIdが一致しないためAssumeRoleが失敗します。これはAWSが公式に推奨するクロスアカウントアクセスにおけるConfused Deputy対策の標準パターンです。 選択肢Bは誤りです。MFA条件はサービス間のプログラム的なAssumeRoleには適用できません。自動化フローでMFAトークンをリアルタイムに入力することは現実的でないためです。 選択肢Cは誤りです。パーミッションバウンダリは権限昇格防止に有効ですが、異なる顧客のロールを誤ってAssumeRoleするテナント混同問題を防ぐことはできません。 選択肢Dは誤りです。IAM Identity Centerはシングルサインオンに適していますが、マルチテナントSaaSがプログラム的に各顧客アカウントを自動管理するユースケースには設計上不向きです。