DVAセキュリティ
バックエンドサービスがSTS AssumeRoleで共通の処理ロール（S3フルアクセスのIAM管理ポリシーを持つ）を引き受けて処理を実行しています。このセッション中は特定バケット「audit-logs」へのオブジェクト書き込み（s3:PutObject）のみを許可し、他のバケット操作を制限したい要件があります。コードとインフラの変更を最小限に抑える方法はどれですか？
AAssumeRole APIのPolicyパラメータにセッションポリシーを指定し、audit-logsバケットへのPutObjectのみ許可するJSONを渡す
✓ 正解
AssumeRoleのPolicyパラメータ（セッションポリシー）はセッション単位で権限を追加制限します。ロール自体を変更せずに呼び出し時の引数で制御でき、インフラ変更不要で要件を満たします。
BIAMロールのインラインポリシーをAssumeRole直前にUpdateRolePolicyで更新し、処理完了後に元のポリシーに戻す
ポリシーの動的更新は並行実行時に競合リスクがあり、変更が全セッションに影響します。IAM APIのスロットリングも懸念され、最小限の変更とは言えません。
CIAMロールの信頼ポリシーのConditionにS3バケット名を指定してセッション中の操作を特定バケットに制限する
信頼ポリシーはAssumeRoleを許可する主体（Principal）とその条件を制御するものです。セッション中のS3バケット操作を絞り込む用途には使用できません。
D専用のIAMロールを新規作成してaudit-logsバケットへのPutObjectのみを許可するポリシーをアタッチして使用する
新規IAMロールの作成は要件を満たしますが、インフラ変更が必要で「最小限の変更」という要件に反します。セッションポリシーによるアプローチが最適です。
解説
STS AssumeRole APIのPolicyパラメータ（セッションポリシー）を使用すると、引き受けたロールの権限をそのセッションのみで追加制限できます。セッションポリシーはロールのアイデンティティポリシーとの積（AND）として評価され、どちらにも許可されている操作のみが有効になります。IAMロール自体を変更せず、呼び出し時のパラメータとして権限を絞り込めるため、変更が最小限で済みます。
選択肢BのUpdateRolePolicyによる動的なポリシー更新は、並行リクエストがある場合に競合が発生するリスクがあり、頻繁なIAM API呼び出しはスロットリングの原因にもなります。ロール変更は全セッションに影響します。
選択肢CのIAMロール信頼ポリシーは「誰がロールを引き受けられるか」を制御するものであり、セッション中のS3操作を細かく制限することはできません。
選択肢Dの新しいIAMロール作成は機能しますが、インフラの追加作業が必要で「最小限の変更」という要件に反します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →