📚 课程目录第4章 AWS S3 SSE-KMS 架构

AWS S3 SSE-KMS 架构：密钥层级、加密上下文与数据密钥生成

说实话，SSE-KMS 刚上手的时候，不少人会被那一堆缩写绕晕。

CMK、DEK、加密上下文……到底谁管谁？

我个人习惯先理清它们的层级关系，再看数据密钥是怎么从 KMS 里“生”出来的。

KMS 密钥层级：三把锁的关系

你想想看，AWS KMS 里头，最核心的就是客户主密钥（CMK）。

CMK 是一把永远不出 KMS 服务的顶级密钥。你在 KMS 控制台创建的就是它。

然后，每次 S3 要加密一个对象，KMS 会临时生成一个数据密钥（DEK）。

DEK 才是真正用来加密对象的密钥。用完就丢。

我在项目中遇到过有人试图直接拿 CMK 去加密文件——那是不行的。

CMK 只干两件事：生成 DEK，以及对 DEK 本身加密。

密钥层级	位置	生命周期	作用
客户主密钥（CMK）	KMS 服务内部	持久化（除非你删除或禁用）	生成并加密 DEK
明文数据密钥（Plaintext DEK）	返回给 S3 后驻留内存	仅用于单次加密/解密操作	使用 AES-256 直接加密 S3 对象
密文数据密钥（Ciphertext DEK）	随 S3 对象一起存储（元数据中）	与对象生命周期一致	解密时由 KMS 解密后还原出明文 DEK
加密上下文	KMS API 调用时传递	随 API 请求传递，不持久化	绑定加密操作到特定上下文，提供额外认证数据

我的一点经验：CMK 的轮换最好开启自动轮换，一年一次。这样就算有人拿到了旧 DEK，也解不开新数据。

加密上下文：一把看不见的锁

加密上下文（Encryption Context）是 KMS 里一个很巧妙的设计。

它本质上是 K-V 对，你在生成 DEK 时传给 KMS，KMS 会把它当成额外认证数据，参与对 DEK 的加密。

简单说：如果加密和解密时传的加密上下文不一样，KMS 会拒绝解密。

我在项目中见过一个坑：有人上传对象时传了加密上下文 {"department":"finance"}，但下载时忘了传——结果解密失败。嗯，S3 控制台默认不带这个参数，如果你是 API 调的，要注意。

警告：加密上下文本身不加密，它只是以明文形式参与 KMS 的加密过程。不要在里面放敏感数据！

我个人习惯把 bucket 名称和 object key 放进加密上下文，比如：

{
  "service": "s3",
  "bucket": "my-corp-data",
  "object-key": "reports/2025/q1.xlsx"
}

这样即使密文被复制到别的 bucket，解密也会失败——因为它绑定了原上下文。

数据密钥生成流程：一步步拆解

好了，现在我们把 CMK、DEK、加密上下文串起来，看一次完整的生成流程。你可以配合下面的流程图看。

流程其实不复杂：

你上传对象时指定 SSE-KMS，S3 调用 KMS 的 GenerateDataKey API，同时带上加密上下文。
KMS 校验你的 CMK 权限，然后用 CMK 加密一个随机生成的 DEK，返回两个版本：明文 DEK 和 密文 DEK。
S3 用明文 DEK（内存中）加密对象正文，然后立即丢弃明文 DEK。
S3 把密文 DEK 存储在对象的元数据中（x-amz-ciphertext-key），加密上下文则不存储——这一点常被误解。

核心点：加密上下文必须由你在解密时重新传入。S3 不自动保存它。如果你通过 API 解密，记得传相同的 K-V 对；如果用 S3 控制台下载，它会自动从发起请求的环境推断上下文（通常是空的），所以控制台下可能解密失败。

实践中的关键配置

下面是我常用的一个 Python 代码片段，用 boto3 上传对象并指定加密上下文：

import boto3

s3 = boto3.client('s3')
kms_key_id = 'alias/my-key'

encryption_context = {
    'service': 's3',
    'bucket': 'my-data-bucket',
    'object-key': 'confidential/report.xlsx'
}

s3.put_object(
    Bucket='my-data-bucket',
    Key='confidential/report.xlsx',
    Body=b'...',
    ServerSideEncryption='aws:kms',
    SSEKMSKeyId=kms_key_id,
    SSEKMSEncryptionContext=encryption_context  # 注意：参数名是 SSEKMSEncryptionContext
)

避坑提醒：我曾经在写自动化脚本时忘记传 SSEKMSEncryptionContext，结果 S3 自动用了一个空字符串作为上下文。后来解密时怎么都过不了——因为你得传一模一样的空字符串才行，但手动传空对象又容易踩 API 兼容性问题。建议：要么统一用上下文，要么全不用，别混着来。

解密时，boto3 的 get_object 会自动从请求中获取加密上下文。但如果你用底层 KMS Decrypt 手动解密密文 DEK，必须显式传入相同的上下文：

kms = boto3.client('kms')
response = kms.decrypt(
    CiphertextBlob=ciphertext_dek,
    EncryptionContext={
        'service': 's3',
        'bucket': 'my-data-bucket',
        'object-key': 'confidential/report.xlsx'
    }
)
plaintext_dek = response['Plaintext']

嗯，这就是整个 SSE-KMS 的密钥架构。弄懂了这三层，后面的实战配置基本上就是填参数的事。