SSE-C とクライアント側暗号化の違いを完全理解
AWS認定試験(SAA)では、「暗号化」と「鍵の管理場所」に関する問題が非常に多く出題されます。
問題の要点
クラウドに保存されているすべてのデータを
オンプレミスに保存された暗号化キーを使用して
保管時は常に暗号化する必要がある
ポイントはここ
- 鍵は AWS に置いてはいけない
- 鍵はオンプレミス管理
- 保存時は常に暗号化(at-rest encryption)
【問題】
ある企業のセキュリティチームは、クラウドに保存されているすべてのデータを、オンプレミスに保存された暗号化キーを使用して、保管時は常に暗号化する必要があります。これらの要件を満たす暗号化オプションはどれですか。 (2 つ選択)
A) Amazon S3 で管理された暗号キー (SSE-S3) でサーバー側の暗号化を使用する。
B) AWS KMS で管理された暗号化キー (SSE-KMS) でサーバー側の暗号化を使用する。
C) 顧客提供の暗号化キー (SSE-C) でサーバー側の暗号化を使用する。
D) クライアント側の暗号化を使用して、保存時の暗号化を行う。
E) Amazon S3 イベントによって呼び出される AWS Lambda 関数を使用し、顧客のキーを使用してデータを
ここから先は答えと解説が出ますのでまずは考えて見てください。
【正解】
- C) SSE-C
- D) クライアント側暗号化
なぜこの2つなのか、構造から解説します。
暗号化方式の全体整理
S3の暗号化方式まとめ
| 方式 | 鍵の管理者 | 鍵の保存場所 | 今回の要件適合 |
|---|---|---|---|
| SSE-S3 | AWS | AWS | ❌ |
| SSE-KMS | AWS | AWS | ❌ |
| SSE-C | 顧客 | オンプレ | ✅ |
| Client-Side | 顧客 | オンプレ | ✅ |
✅ C) SSE-C(顧客提供キー)
仕組み
SSE-C は Server-Side Encryption with Customer-provided keys の略です。
構成図
オンプレミス
│
│ 暗号化キー保持
│
▼
アプリケーション
│
│ PUTリクエスト時に鍵を同時送信
▼
Amazon S3
│
│ サーバー側で暗号化
│ 鍵は保存しない
▼
暗号化オブジェクト保存
特徴
- 鍵は AWS に保存されない
- GET時にも同じ鍵を渡す必要あり
- AWS側は鍵を保持しない
👉 「鍵は常にオンプレにある」条件を満たす
✅ D) クライアント側暗号化
仕組み
S3にアップロードする前に暗号化する方式です。
構成図
オンプレミス
│
│ 暗号化キー保持
│
▼
アプリケーション
│
│ ローカルで暗号化
▼
暗号化済データ
│
▼
Amazon S3
│
│ そのまま保存(AWSは中身を知らない)
▼
保存完了
特徴
- AWS は暗号化処理に関与しない
- AWSは鍵を一切知らない
- セキュリティは最強
👉 要件を完全に満たす
なぜ他は不正解なのか
❌ A) SSE-S3
→S3が鍵管理
・鍵は AWS 管理
・オンプレミス鍵ではない👉 要件違反
❌ B) SSE-KMS
→AWS KMS が鍵管理
・鍵は AWS 管理
・オンプレ保存ではない👉 要件違反
❌ E) Lambdaで後から暗号化
→S3保存 → Lambda → 再暗号化
・一時的に平文保存される可能性
・常に暗号化されているとは言えない
・構成が複雑👉 最小労力ではない
SAA試験での見抜き方
問題文にこれがあれば即判断できます:
| キーワード | 選ぶもの |
|---|---|
| オンプレ鍵 | SSE-C or Client-Side |
| AWSが鍵管理 | SSE-S3 / KMS |
| 常に暗号化 | Lambda後処理は除外 |
SSE-C と Client-Side の違い
| 比較項目 | SSE-C | Client-Side |
|---|---|---|
| 暗号化場所 | S3サーバー | クライアント |
| AWSが鍵を知るか | 知らない | 知らない |
| 実装の簡単さ | やや簡単 | 実装負荷高め |
| セキュリティ | 高い | 最高 |
まとめ
今回の要件は
「オンプレミス鍵を使用」
「保管時常に暗号化」
この2つが条件でした。
それを満たすのは:
✅ SSE-C
✅ クライアント側暗号化
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK