はじめに
どーも！shihopowerです！
今回は、「SSE-Cはデフォルト設定できない」 という話題について深掘りしていきます。
AWS SAP（Solutions Architect Professional）の対策をしていると、参考書や問題集でしれっと「SSE-Cはバケットのデフォルト暗号化として設定できない」という記述に出くわします。
…が、最初に読んだ私の感想は「で？それの何が大事なの？」「そもそもなんでできないの？」というちんぷんかんぷん状態でした。
そこでAWS公式ドキュメントを読み込んで整理してみたので、同じくモヤッとしているSAP受験者の方の参考になれば嬉しいです 🙌
目次
- SSE-Cがデフォルト設定できないとはどういうことか
- なぜSSE-Cはデフォルト設定できないのか
- SSE-S3、SSE-KMS、DSSE-KMSがデフォルト設定できる理由
- まとめ
1. SSE-Cがデフォルト設定できないとはどういうことか
そもそも「S3のデフォルト暗号化（default encryption）」とは、バケットにアップロードされる新規オブジェクトを、ユーザーが暗号化方式を指定しなくても自動で暗号化してくれる仕組みのことです。
設定はバケット単位で行い、PutBucketEncryption というAPIで構成します。
ここで指定できる暗号化方式は以下の3つです。
| 方式 | デフォルト設定 |
|---|---|
| SSE-S3（S3管理キー） | ✅ 可能（しかも自動で有効） |
| SSE-KMS（KMS管理キー） | ✅ 可能 |
| DSSE-KMS（二重KMS暗号化） | ✅ 可能 |
| SSE-C（顧客提供キー） | ❌ 不可 |
AWS公式ドキュメントにも、はっきりとこう書かれています。
Server-side encryption with customer-provided keys (SSE-C) is not supported for default encryption.
（SSE-Cはデフォルト暗号化ではサポートされていません）
— Configuring default encryption - Amazon S3 User Guide
つまり、「このバケットに入ってくるオブジェクトは全部SSE-Cで暗号化しといてね〜」というバケットレベルの自動設定は そもそも不可能 ということです。
SSE-Cを使いたい場合は、オブジェクトをPUT／GETするたびに、リクエストごとに暗号化キーを明示的に渡す必要があります。
2. なぜSSE-Cはデフォルト設定できないのか
理由はシンプルで、SSE-Cの仕組みそのものがバケットデフォルトと両立しないからです。
理由①：S3は暗号化キーを一切保存しない
SSE-Cの最大の特徴は、AWS側が顧客の暗号化キーを 絶対に保存しない ことです。
S3 never stores the encryption key when you use SSE-C. You must supply the encryption key every time you want anyone to download your SSE-C encrypted data from S3.
— Using server-side encryption with customer-provided keys (SSE-C)
オブジェクトをアップロードするときにキーを渡し、S3はそのキーで暗号化したらすぐにメモリから破棄します。ダウンロード時も同じキーを渡してもらって、復号したらまた破棄。
…ここまで読むと気づきますよね。
「デフォルト設定」とは、バケット側に暗号化情報を持たせておいて、ユーザーが何も指定しなくても自動で暗号化処理を走らせる仕組みです。
キーをS3に保存しないSSE-Cでは、そもそもバケット側に「自動で使うべき情報」を置いておけないのです。
理由②：SSE-Cはオブジェクト単位の暗号化方式である
これも公式ドキュメントが明言しています。
SSE-C is an object-level encryption method where you provide the encryption key to Amazon S3 with each object upload or download request. (中略) This means SSE-C is enabled on a per-object basis, not as a default bucket setting.
— Specifying server-side encryption with customer-provided keys (SSE-C)
SSE-Cは設計思想からして 「リクエストごと」「オブジェクトごと」 に有効化される方式であり、バケットというスコープで一括設定する性質のものではない、ということです。
補足：2026年4月以降、SSE-Cはさらに厳しくなった
ちなみに、2026年4月以降は「デフォルト設定できない」どころの話ではなくなりました。
Starting April 2026, SSE-C is disabled by default for all new general purpose buckets and existing buckets in accounts with no SSE-C encrypted objects.
— Using server-side encryption with customer-provided keys (SSE-C)
新規の汎用バケット、およびSSE-C暗号化オブジェクトを持たないアカウントの既存バケットでは、SSE-C自体がデフォルトで ブロック されるようになりました。
SSE-Cを使いたい場合は、PutBucketEncryption で BlockedEncryptionTypes を NONE に明示的に設定する必要があります。設定していない状態でSSE-C指定のPUTを投げると、HTTP 403 AccessDenied で弾かれます。
AWSがこの方向に舵を切った理由も公式に書かれています。
SSE-C requires you to provide the encryption key with every request, making it impractical to share access with other users, roles, or AWS services that operate on your data.
— Using server-side encryption with customer-provided keys (SSE-C)
要するに、リクエストごとにキーを渡す方式は他のAWSサービスや他ユーザーとの連携が著しく不便で、現代的なワークロードには合っていない、ということですね。
3. SSE-S3、SSE-KMS、DSSE-KMSがデフォルト設定できる理由
ここまで来ると、逆になぜ他の3方式はデフォルト設定できるのかも自然と見えてきます。
ポイントは 「暗号化キーをAWS側（S3 or KMS）が管理しているかどうか」 です。
SSE-S3：S3が完全にキーを管理
Each object is encrypted with a unique key. As an additional safeguard, SSE-S3 encrypts the key itself with a root key that it regularly rotates.
— Protecting data with server-side encryption
S3がオブジェクトごとに一意なキーを生成し、さらにそれをルートキーで暗号化＆定期ローテーションまでやってくれます。
ユーザーがキーを意識する必要が一切ないため、「バケットに入ってきたオブジェクトを全部S3が勝手に暗号化する」が成立します。
そして実は、全てのS3バケットはデフォルトでSSE-Sが有効になっています（2023年1月5日以降の仕様）。
SSE-KMS：KMSがキーを管理
Server-side encryption with AWS KMS keys (SSE-KMS) is provided through an integration of the AWS KMS service with Amazon S3. With AWS KMS, you have more control over your keys.
— Protecting data with server-side encryption
キーの実体はAWS KMSに保管されており、S3はバケットのデフォルト暗号化設定として「このKMSキーのARN／IDを使ってね」と参照情報だけ持っておけばOKです。
オブジェクトPUT時にはS3が裏でKMSを呼び出して暗号化処理を行うため、ユーザー側はリクエストごとにキーを渡す必要がありません。
DSSE-KMS：KMS＋S3で二重暗号化
Dual-layer server-side encryption with AWS KMS keys (DSSE-KMS) is similar to SSE-KMS, but DSSE-KMS applies two independent layers of AES-256 encryption instead of one layer: first using a AWS KMS data encryption key, then using a separate Amazon S3-managed encryption key.
— Protecting data with server-side encryption
仕組みはSSE-KMSとほぼ同じで、AES-256による暗号化を2層適用する点だけが違います。
キー管理はKMS＋S3が担うため、こちらもバケットデフォルトとして設定可能です。
4方式の比較まとめ
| 方式 | キー管理者 | リクエスト毎にキー指定 | デフォルト設定 |
|---|---|---|---|
| SSE-S3 | AWS（S3） | 不要 | ✅ |
| SSE-KMS | AWS（KMS）＋顧客 | 不要 | ✅ |
| DSSE-KMS | AWS（KMS＋S3）＋顧客 | 不要 | ✅ |
| SSE-C | 顧客 | 必須 | ❌ |
こうして並べると一目瞭然で、「キーをAWSが保持しているか／リクエストごとにキー指定が要るか」がデフォルト設定可否の分かれ目になっていることが分かります。
4. まとめ
- 「SSE-Cはデフォルト設定できない」とは、
PutBucketEncryptionのデフォルト暗号化方式としてSSE-Cを指定できない、ということ。 - 理由は、SSE-CはS3にキーを保存しない仕様であり、リクエストごと・オブジェクトごとに有効化される方式だから。バケットレベルで自動適用させる土俵にそもそも乗らない。
- 一方、SSE-S3／SSE-KMS／DSSE-KMSは キー管理をAWS側（S3 or KMS）が担うため、バケットデフォルト設定として成立する。
- さらに2026年4月以降、SSE-Cは新規バケットでデフォルトブロックされる仕様に。使うには明示的に解除する必要がある。
「SSE-Cはデフォルト設定できない」という一文の背景には、キー管理を誰がやるかという設計思想の違いが隠れていました。仕組みまで降りて理解しておくと、似たような選択肢が並んだときにも迷わず選べるようになるはずです。
最後まで読んでいただきありがとうございました！
それでは、よいAWSライフを！