DVAセキュリティ
AWSパートナー企業（アカウントID: 111111111111）が複数の顧客企業のAWSリソースを管理するSaaSサービスを提供しています。ある顧客（アカウントID: 222222222222）が自社アカウントにクロスアカウントIAMロールを作成し、パートナー企業のアプリケーションがSTS AssumeRoleでそのロールを引き受けます。悪意ある第三者がパートナー企業のアカウントIDを入手してロールを不正に引き受けようとする「混乱した代理人（Confused Deputy）攻撃」を防ぐための最もセキュアな方法はどれですか？
A顧客アカウントのロールのトラストポリシーで、パートナー企業の特定のIAMユーザーARN（Amazon Resource Name：AWSリソースを一意に識別する名前）のみをPrincipalとして指定する
特定のIAMユーザーARNをPrincipalとして指定することでアクセス元を限定できますが、そのユーザーが侵害された場合に悪用されるリスクが残り、Confused Deputy攻撃の防止にはExternalIdの使用がAWSの推奨アプローチです。
B顧客アカウントのロールのトラストポリシーにConditionとしてsts:ExternalId条件キーを追加し、パートナー企業と顧客ごとに固有の外部ID（ExternalId）をAssumeRole呼び出し時に要求する
✓ 正解
sts:ExternalIdを顧客ごとに固有の秘密値として設定することで、アカウントIDを知っているだけではAssumeRoleできなくなります。悪意ある第三者はExternalIdを知ることができないため、Confused Deputy攻撃を根本的に防止できるAWSの推奨セキュリティパターンです。
Cパートナー企業と顧客企業の両アカウントをAWS Organizationsの同一組織（OU：Organizational Unit）に所属させ、SCPで制御する
AWS OrganizationsとSCPは同一組織内のアカウントに対する制御には有効ですが、パートナーと顧客が別組織に属する一般的なSaaSクロスアカウントシナリオでは適用できないため、この要件には対応できません。
Dパートナー企業のアプリケーションにハードウェアMFA（Multi-Factor Authentication：多要素認証）デバイスを設定し、トラストポリシーのConditionにaws:MultiFactorAuthPresentを追加する
ハードウェアMFAは人間のオペレーターが手動でAssumeRoleを実行するシナリオには有効ですが、アプリケーションが自動的にAssumeRoleを呼び出すSaaSシナリオでは実装が困難であり、Confused Deputy攻撃の防止策としては不適切です。
解説
混乱した代理人（Confused Deputy）攻撃では、悪意ある第三者がパートナー企業のアカウントIDを知るだけで顧客のロールを不正に引き受けようとします。sts:ExternalIdは顧客ごとに固有の秘密値をパートナーと顧客間で事前に取り決めてトラストポリシーのConditionに設定する仕組みです。AssumeRole呼び出し時に正しいExternalIdを提示できなければロールを引き受けられないため、アカウントIDを入手した第三者による不正アクセスを防止できます。これはクロスアカウントSaaSアクセスにおけるAWSの推奨セキュリティパターンです。
選択肢Aの特定IAMユーザーARNをPrincipalに指定する方法はアクセス元を限定しますが、そのユーザーが侵害された場合のリスクが残り、ExternalIdほど強固なConfused Deputy対策にはなりません。
選択肢CのAWS Organizations＋SCPは同一組織内のアカウント管理には有効ですが、パートナーと顧客が別組織に属するクロスアカウントSaaSシナリオでは適用できません。
選択肢DのハードウェアMFAは人間のオペレーターが手動操作する場合には有効ですが、アプリケーションが自動的にAssumeRoleを呼び出すシナリオでは実装が困難であり、Confused Deputy攻撃の防止策としては不適切です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →