SAAセキュアなアーキテクチャの設計
ある企業は、サードパーティのSaaS型監視サービスにAWSアカウント内のリソースの読み取りアクセスを許可する必要があります。このSaaSベンダーは複数の顧客を同一のベンダーAWSアカウントから管理しています。「混乱した代理（confused deputy）」問題を防ぎ、最も安全にアクセスを委任する方法はどれですか。
Aベンダーアカウントを信頼するIAMロールを作成し、信頼ポリシーのsts:AssumeRoleにベンダーが発行した一意のExternalIDをsts:ExternalId条件として設定する
✓ 正解
ベンダーアカウントを信頼するIAMロールにsts:ExternalId条件を設定すると、ベンダーは顧客ごとの一意なIDを提示しないとロールを引き受けられず、他顧客のコンテキストでの悪用を防ぐ混乱した代理対策になります。
B読み取り権限を持つIAMユーザーを作成し、そのアクセスキーとシークレットキーをベンダーに共有して、定期的にローテーションする
長期的なアクセスキーの共有は漏洩リスクが高く一時認証情報も使えないAWSのアンチパターンです。混乱した代理問題への対策にもならず、最も安全な委任方法とは言えません。
Cベンダーアカウントを信頼するIAMロールを作成し、ExternalIDを設定せずに広範な読み取り権限を付与してAssumeRoleを許可する
ExternalIDを設定しないクロスアカウントロールは、共有ベンダーアカウントが悪用された際に他顧客のリソースへアクセスされる混乱した代理のリスクが残るため、安全な委任にはなりません。
DS3バケットポリシーでベンダーアカウントのルートユーザーにアクセスを許可し、ベンダーが直接リソースを参照できるようにする
S3バケットポリシーでの許可はS3に限定され、求められる広範なリソースの読み取りアクセスに対応できません。ルートユーザーへの許可も過剰権限で、混乱した代理問題も解決しません。
解説
サードパーティへのクロスアカウントアクセスでは、ベンダーアカウントを信頼するIAMロールを作成し、信頼ポリシーにベンダー発行の一意なExternalIDをsts:ExternalId条件として設定します。これにより、ベンダーが他顧客のコンテキストで誤ってロールを引き受ける「混乱した代理」問題を防止できます。
選択肢Bの長期的なアクセスキーの共有は、漏洩リスクが高く一時認証情報も使えないアンチパターンで、混乱した代理問題も解決しません。
選択肢CのExternalIDを設定しない構成は、共有ベンダーアカウントが悪用された場合に他顧客のリソースへアクセスされる混乱した代理のリスクが残ります。
選択肢Dのバケットポリシーでルートユーザーを許可する方式はS3に限定され広範なリソース読み取りに対応せず、ルートレベルの許可も過剰です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →