📚 课程目录第4章 KMS核心功能

KMS核心功能：密钥创建、存储、使用、轮换、删除的完整流程

密钥管理，说白了就是管好钥匙——从造出来那把钥匙，到它最终报废。

KMS 把这过程拆成了五个核心环节：创建、存储、使用、轮换、删除。你想想看，哪一步出了问题，整个加密体系就可能变成摆设。

我个人习惯把这几个环节画成一个圆圈，因为很多场景下密钥是不断循环的。下面这张图，就是我平时给团队讲密钥生命周期时必用的框架。

1. 创建——从零开始造钥匙

KMS 创建密钥，其实包含两个动作：生成密钥材料和分配元数据。

我在项目中遇到过不少团队直接把主密钥（CMK）的创建参数写死到配置文件里，结果审计的时候发现所有生产环境的密钥居然都是用同一个种子生成的。那跟没有加密有什么区别？

创建时你要关注这几件事：

密钥规格——对称还是非对称？AES-256、RSA-2048、ECC P-256……选错规格后面改不了。
密钥用途——ENCRYPT_DECRYPT、SIGN_VERIFY，还是两者兼有？
密钥别名——我个人习惯用 alias/prod/payment-key 这种带环境的命名，方便区分。
初始启用状态——有些云服务默认创建后是“禁用”状态，记得检查。

我的技巧：创建时立刻挂上标签（Tag），比如 Environment、Owner、Expiration。否则三个月后你看一堆 key-xxxx 会抓狂。

用 AWS CLI 举例：

aws kms create-key \
  --key-spec SYMMETRIC_DEFAULT \
  --key-usage ENCRYPT_DECRYPT \
  --tags TagKey=Environment,TagValue=prod \
  --region us-east-1

2. 存储——钥匙放进保险柜

密钥存储，核心就一句话：密钥材料永不离开 HSM（硬件安全模块）。

云上的 KMS 服务，比如 AWS KMS、Azure Key Vault、阿里云 KMS，底层都是把密钥藏在 FIPS 140-2 Level 3 的 HSM 里。你看到 API 返回的 KeyId 只是一个引用，真正的明文肯本不会经过网络。

我曾经遇到一个客户，为了“优化性能”，把密钥下载到本地文件系统缓存。结果测试环境泄露，影响了整个灰度发布。嗯，数据加密最怕的就是“自己乱存”。

存储环节的几个原则：

永远用托管 HSM，别自己用软件模拟。
启用多区域副本（跨地域容灾）。
开启密钥删除保护（防止手误）。

3. 使用——拿钥匙开门

使用阶段才是 KMS 真正发挥价值的地方。你不需要自己实现加密算法，只需要调用 KMS API，传入密文或明文。

举个例子，加密数据库字段：

# 加密
aws kms encrypt \
  --key-id alias/prod/user-id-key \
  --plaintext fileb://plain.text \
  --output text \
  --query CiphertextBlob | base64 --decode > encrypted.enc

# 解密
aws kms decrypt \
  --ciphertext-blob fileb://encrypted.enc \
  --output text \
  --query Plaintext | base64 --decode > decrypted.txt

注意：加密时生成的 CiphertextBlob 里已经包含了密钥标识、加密算法等信息，你只管存。解密时 KMS 会自己判断用哪个密钥版本。

这里有个坑——请求频率限制。我遇到过生产环境突然爆发的加密操作导致 KMS 限流，返回 ThrottlingException。后来加上了本地缓存 + 指数退避重试才解决。

警告：不要把 KMS API 调用放在高并发热路径里。建议用本地加密密钥（DEK）做数据加密，KMS 只管加密 DEK。这就是经典的“信封加密”模式。

4. 轮换——定期换锁芯

密钥轮换，说白了就是给同一个密钥生成一个新版本。

轮换不改变密钥的 ID 和别名，但 CiphertextBlob 里会记录用的是哪个版本。KMS 解密时自动根据密文中的版本信息选取正确的密钥材料。

轮换策略我见过两种：

策略	实现方式	适用场景
自动轮换	KMS 每年自动生成新版本	合规要求严格，如 PCI DSS
手动轮换	调用 `create-key` 后再通过 `enable-key-rotation` 开启	需要自定义周期或特殊触发条件

我个人习惯：能用自动轮换就别手动。但有次项目里因为密钥用于签名验证，轮换后旧的签名数据需要保留，我就手动做了“双版本并行”方案——新版本签发，旧版本验证。代码里判断数据创建时间，自动选择对应的密钥版本。

曾经有位同学问我：“轮换后旧密文还能解密吗？” 答案是：能。只要旧版本还在（默认保留三个版本），KMS 就能解密。只有当你手动删除旧版本，那些密文才会变成死数据。

  关键点：轮换是“平滑”的，不会导致业务中断。但你得确保所有依赖此密钥的系统都能处理多个版本。

5. 删除——送钥匙进碎纸机

删除密钥是最后一个环节，也是最容易出事故的环节。

KMS 的删除流程通常分两步：计划删除 → 等待冷却期 → 实际删除。这个冷却期（7~30天）就是给你反悔用的。

我曾经有一次，打算清理一个测试密钥，结果不小心选错了环境，点了生产环境的删除。还好我提前开启了“密钥删除保护”，系统提示我必须先关闭保护。冷汗都出来了。

删除前必须确认：

所有已加密数据是否已经迁移到新密钥？
是否有正在进行的解密/签名操作？
对应 IAM 策略和资源引用是否已解除？

切记：密钥一旦删除，所有使用该密钥加密的数据都将永久无法解密。没有“找回来”的可能。我建议你即使在删除后也要保留备份（比如导出密钥材料的副本到安全的离线存储）。

删除命令示例（AWS）：

# 计划删除，等待7天
aws kms schedule-key-deletion \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --pending-window-in-days 7

# 取消删除（冷却期内）
aws kms cancel-key-deletion \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

从创建到删除，密钥生命周期的每一步都藏着细节。别小看这些基础操作——我见过太多安全事故，根源就是某个环节“我觉得没问题”。你想想看，密钥是数据加密的根基，根基都不稳，上层再漂亮的架构也是空中楼阁。