SOAネットワークとコンテンツ配信
ある企業は S3 バケットに保存した機密コンテンツを CloudFront 経由で配信しており、OAI（Origin Access Identity）を使用してバケットへの直接アクセスを制限しています。セキュリティ監査の結果、以下の 2 つの変更を行うよう指示されました。
① S3 バケットの暗号化を SSE-S3 から顧客管理 KMS キー（SSE-KMS）に変更する
② OAI は非推奨のため、よりセキュアな認証方式へ移行する
両方の要件を最も適切に満たす対応はどれですか？
AOAI をそのまま維持し、KMS キーポリシーに OAI プリンシパルへの kms:Decrypt および kms:GenerateDataKey 権限を追加して S3 バケットを SSE-KMS に変更する
OAIはSSE-KMS暗号化されたS3オブジェクトへのアクセスをサポートしないため、S3をSSE-KMSに変更するとCloudFrontからの配信が失敗する。また非推奨のOAIを維持するため「よりセキュアな方式へ移行」の要件も満たさない。
BOAI を OAC（Origin Access Control）に移行し、KMS キーポリシーで CloudFront サービスプリンシパルへの kms:Decrypt 権限を許可したうえで S3 バケットを SSE-KMS に変更する
✓ 正解
OACはAWSが推奨するOAIの後継方式でSSE-KMS暗号化S3オブジェクトへのアクセスをサポートする。KMSキーポリシーでCloudFrontサービスプリンシパルにkms:Decryptを付与することで両方の要件を同時に満たせる。
CCloudFront ディストリビューションにフィールドレベル暗号化を追加設定し、エッジで KMS キーを使用してコンテンツを暗号化することで S3 側の暗号化方式変更を回避する
フィールドレベル暗号化はCloudFrontがエッジでHTTPSレスポンスの特定フィールドを追加暗号化する機能であり、S3バケット全体をSSE-KMSに変更するというサーバーサイド暗号化要件とは目的が根本的に異なる。
DLambda@Edge の Origin Request トリガーを使用して S3 オブジェクト取得時に AWS SDK で KMS 復号処理を実装し、OAI 設定と S3 の暗号化方式は現状を維持する
Lambda@EdgeでKMS復号処理を実装しても、OAIはSSE-KMS暗号化S3オブジェクトをサポートしないためS3へのアクセス自体が失敗する。また不必要な複雑性とレイテンシオーバーヘッドが発生し両要件を満たせない。
解説
OAC（Origin Access Control）は OAI の後継として AWS が推奨するアクセス制御方式です。CloudFront サービスプリンシパル（cloudfront.amazonaws.com）による SigV4 署名で S3 へのリクエストを認証するため、SSE-KMS 暗号化された S3 オブジェクトへのアクセスをサポートします。KMS キーポリシーで CloudFront サービスプリンシパルに kms:Decrypt 権限を付与し、aws:SourceArn 条件で特定ディストリビューションに限定することも可能です。
選択肢AのOAIはSSE-KMS暗号化されたS3オブジェクトへのアクセスをサポートしないため、S3をSSE-KMSに変更するとCloudFrontからのコンテンツ配信が機能しなくなる。また非推奨のOAIを維持するため「よりセキュアな方式へ移行」の要件も満たさない。
選択肢CのフィールドレベルHTTPS暗号化はCloudFrontがエッジで特定のHTTPSフォームフィールドを追加暗号化する機能であり、S3バケット全体をSSE-KMSで暗号化するというサーバーサイド暗号化要件とは目的が異なる。
選択肢DのLambda@Edgeでの復号処理実装は不必要な複雑性とパフォーマンスオーバーヘッドを生む。さらにOAIはSSE-KMSをサポートしないため、Lambda@Edgeを用いても根本的なアクセス問題は解消されない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →