SAAセキュアなアーキテクチャの設計
あるSaaS企業（AWSアカウントID: 111122223333）が複数の顧客企業のAWSアカウントへクロスアカウントアクセスを行いコスト最適化レポートを提供しています。SaaS企業のアカウントIDが第三者に漏洩した場合でも、その第三者が顧客のIAMロールを不正に引き受けられないよう「混乱した代理人（Confused Deputy）」攻撃を防ぐ必要があります。最もセキュアなアクセス委任方法はどれですか？
A顧客アカウントにIAMユーザーを作成してアクセスキーを発行し、SaaS企業に安全なチャネルで共有して長期クレデンシャルでアクセスさせる
IAMユーザーのアクセスキーは長期クレデンシャルであり、外部のSaaS企業に共有することで漏洩リスクが高まります。IAMロールによる一時認証情報を使うアプローチと比べてセキュリティが劣り、AWSのベストプラクティスに反します。
B顧客がIAMロールを作成し、TrustPolicyのPrincipalにSaaS企業のアカウントIDを設定し、ConditionでSaaS企業固有のExternalIdを必須とする
✓ 正解
External IDはSaaS企業と顧客間だけで共有する秘密のトークンです。TrustPolicyのConditionにaws:ExternalIdを必須とすることで、アカウントIDを知るだけではAssumeRoleが実行できなくなり、Confused Deputy攻撃を防止できます。
C顧客アカウントとSaaS企業アカウントを同一のAWS Organizations組織に招待し、組織内アクセスとしてSCPで権限範囲を制御する
顧客アカウントをSaaS企業のAWS Organizations組織に参加させると、顧客は組織管理下に入り独立性を失います。このアプローチは現実の商用SaaSシナリオでは顧客に受け入れられず、実用的ではありません。
D顧客がIAMロールを作成しPrincipalにSaaS企業のアカウントIDを指定し、IPアドレスConditionでSaaS企業の既知IPからのみ引き受けを許可する
IPアドレスCondition（aws:SourceIp）は固定IPを持たないシステムには適用が難しく、IPスプーフィングへの耐性も低いです。また、External IDのようにアカウント単位での委任の正当性を証明する仕組みとして設計されていません。
解説
クロスアカウントアクセスでは、SaaS企業のアカウントIDをPrincipalに指定した信頼ポリシーを持つIAMロールを顧客が作成するのが基本パターンです。しかしアカウントIDだけでは、IDを知った第三者がAssumeRoleを実行できてしまう「混乱した代理人（Confused Deputy）」攻撃が成立します。External ID（外部ID）は顧客とSaaS企業の間だけで共有する秘密の文字列であり、TrustPolicyのConditionとしてaws:ExternalIdを必須とすることで、アカウントIDを知るだけではAssumeRoleを実行できなくなり、攻撃を防止できます。各顧客に異なるExternal IDを割り当てることで、顧客間の誤った引き受けも防げます。
選択肢AのIAMアクセスキーは長期クレデンシャルを外部に渡すことになり、ローテーション管理の運用負荷があるうえ漏洩リスクも高く、IAMロールを使った一時認証情報の方式と比べてセキュリティが劣ります。
選択肢CのAWS Organizations同一組織への招待は顧客アカウントをSaaS企業の組織管理下に置くことを意味し、顧客の独立性を損なう現実的でないアプローチです。
選択肢DのIPアドレスConditionはSaaS企業が固定IPを持たない場合に適用が困難であり、IPスプーフィングへの耐性も低いためConfused Deputy攻撃への有効な対策にはなりません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →