← AWSサービスの内部原理 コース
36. サーバーサイド暗号化の内部 — オブジェクトごとの鍵と、鍵を包む鍵
S3 のサーバーサイド暗号化を「オブジェクトごとの鍵」と「鍵を包む鍵」の二段構造で図解し、なぜその設計なのかを2つの理由から追います。
① 出発点:S3 は既定で全オブジェクトを AES-256 で暗号化する
アップロードされたオブジェクトデータ本体
暗号化されたデータ本体1つの鍵で暗号化も復号もする共通鍵暗号
オブジェクトメタデータ暗号化されない
- 対象は 2023年1月5日以降にアップロードされる新しいオブジェクトすべて
- 既定の方式は SSE-S3(Amazon S3 マネージドキー)。新規アップロードの暗号化はもう無効化できない
2023年1月5日以降、新規アップロードは追加料金・性能影響なしで自動的に暗号化され(既定は SSE-S3)、無効化はできない。中身は既に学んだ共通鍵暗号 AES-256(モードは AES-GCM)を機械的に適用しているだけで、S3 は魔法の箱ではない。
② エンベロープ暗号化:鍵が二段構えになっている
ルート鍵定期的にローテーション
鍵を暗号化するための鍵AES で暗号化
データ鍵オブジェクトごとに固有・包まれた状態で保存
データ本体あくまでデータ鍵で暗号化される
- ルート鍵がデータ本体を直接暗号化することはない——鍵の担当が二段に分かれている
各オブジェクトは固有のデータ鍵で AES 暗号化され、そのデータ鍵自体をルート鍵がさらに暗号化して(包んで)保存する。ルート鍵は「鍵を暗号化するための鍵」に徹し、データ本体に直接触れることはない。
③ 固有鍵の理由その1:漏えいの影響範囲(ブラスト半径)を最小化
データ鍵A漏えい!
データ鍵B無傷
データ鍵C無傷
オブジェクトA危険にさらされる
オブジェクトB安全
オブジェクトC安全
- もし全オブジェクトを1つの鍵で暗号化していたら、鍵1本の漏えい=バケット全体の崩壊
- DynamoDB 編のホットパーティション対策と同じ「分割して単位を小さく閉じ込める」発想
あるオブジェクトのデータ鍵が漏れても、危険なのはそのオブジェクト1個だけ。他は別々の鍵で守られているため無傷で、「1か所の問題を全体に波及させない」分割統治の発想そのもの。
④ 固有鍵の理由その2:ローテーションは「包み直し」だけで済む
新しいルート鍵
一切触らない
データ鍵鍵そのものは変わらない
データ本体元のデータ鍵で暗号化されたまま動かさない
- もし各オブジェクトを直接ルート鍵で暗号化していたら:ローテーションのたびに全オブジェクトを読み出し→復号→再暗号化→書き戻し。ペタバイト級では非現実的
ルート鍵を新しくするとき、再暗号化するのは包まれた小さなデータ鍵だけ。データ本体は元のデータ鍵で暗号化されたまま一切触れない——ポインタの張り替えでデータ移動を避けるのと同じ「間接化(indirection)」が鍵管理に効いている。
⑤ 4方式の違いは「鍵を誰が・どこで管理するか」
SSE-S3S3 がデータ鍵とルート鍵を管理(既定)
SSE-KMSルート鍵の管理を AWS KMS に委ねる
CloudTrail 追跡・ポリシー制御が可能DSSE-KMSKMS データ鍵+S3 管理鍵で AES-256 を2層
SSE-C顧客が鍵を提供。S3 は鍵を保存せず HMAC のみ保持
- 左の3方式はいずれも「データ鍵をルート鍵/KMS 鍵で包む」エンベロープ構造(KMS の内部は認証暗号を扱う将来の回で詳説)
- SSE-C は S3 が書き込み時の暗号化・読み出し時の復号を代行するが、鍵自体は保存しない
- 2026年4月以降、新規の汎用バケットと「SSE-C オブジェクトを1つも持たないアカウント」の既存バケットでは SSE-C は既定で無効(条件はアカウント単位)。使うには明示的な有効化が必要
SSE-S3・SSE-KMS・DSSE-KMS・SSE-C は相互排他で、データ本体を AES-256 で暗号化する点は共通。前3方式はエンベロープ構造を持つが、SSE-C だけは顧客が鍵を提供する別構造で、この枠組みが当てはまらない。