S3の転送時・保管時の暗号化

転送時の暗号化（in transit）

S3 の標準エンドポイントへの API アクセスは TLS（HTTPS） を用いるのが前提です。平文 HTTP はリージョンや設定によって利用可否が異なりますが、セキュリティ上のベストプラクティスは HTTPS です。試験では「通信路の保護」という文脈で CloudFront や VPC エンドポイントとセットで問われることもあります。

保管時の暗号化（at rest）の全体像

オブジェクトを S3 に置くときの暗号化は大きく サーバー側（SSE） と クライアント側 に分かれます。SSE は「S3 が受け取ったあとディスク上では暗号化された形で保持する」方式で、誰が鍵を管理するか が SSE-S3 / SSE-KMS / SSE-C の違いです。

SSE-S3

S3 が 独自に管理するルートキー を用いてオブジェクトを暗号化します。利用者は 暗号化を指定するヘッダ を付けるか、バケットの デフォルト暗号化 で SSE-S3 を指定する運用が一般的です。KMS の利用料やキーポリシーは不要で、最もシンプルなサーバー側暗号化です。

SSE-KMS

AWS KMS のキーを指定して暗号化します。データキーが KMS 経由で扱われるため、CloudTrail へのログや キーポリシー・IAM との連携 といった 統制・監査の要件 に応えやすい反面、KMS の API 利用に応じたコストやスロットルに注意が必要です。試験では「誰が復号できるかを KMS で細かく制御したい」シナリオで SSE-KMS が選ばれます。

SSE-C

暗号化鍵の素材を お客様が保持し、アップロード／ダウンロードのリクエストごとに HTTP ヘッダで鍵を渡す 方式です。S3 はその鍵で暗号化・復号を行いますが、鍵のライフサイクル管理はアプリケーション側に残るため運用負荷が高く、特殊なコンプライアンス要件など限定的な用途で検討されます。

クライアント側暗号化

オブジェクトを S3 に送る前にアプリケーション（または SDK）で暗号化します。S3 にはすでに ciphertext だけが届くため、S3 側の管理者でも平文を読めない 構成にしやすいです。代わりに 鍵の保管・ローテーション・失効 はすべてクライアント／アプリ側の責務になります。

整合性の確認

大容量転送では チェックサムやハッシュ で破損を検知する仕組みと組み合わせることがあります。署名付きリクエストのバージョンに応じて推奨ヘッダが変わる点は、実装・試験の両方で「公式ドキュメントの現行仕様」を確認するのが安全です。

関連トピック

KMS の一般論は「KMS, CloudHSM, ACM」のトピック、ストレージクラスは「S3ストレージクラス」を参照してください。