解説

STS の AssumeRole API に Policy パラメータとしてセッションポリシーを渡すと、既存のIAMロールの権限をさらに絞り込んだ一時認証情報を発行できます。テナントIDをプレフィックスとしたS3アクセス条件を含むセッションポリシーを渡すことで、そのリクエスト専用に権限が制限されます。アクセス制御をAWS基盤レベルで強制できるため、アプリケーションコードのバグによるデータ漏洩リスクを大幅に低減できます。セッションポリシーはロールの権限を拡張せず「絞り込む」のみという点が重要な特性です。 選択肢Aのアプリケーション層でのキー検証はコードのバグや例外処理の漏れで迂回されるリスクがあり、セキュリティ境界として不十分である。 選択肢Cのテナントごとに専用IAMロールを作成する方法はテナント数が増えると管理コストが爆発的に増加し、スケーラブルでない。 選択肢DのカスタムHTTPヘッダーはS3の認可機構でサポートされておらず、S3バケットポリシーの条件キーとして利用できない。