第4章 主密钥（CMK）的概念与生命周期
说实话，很多团队一开始接触KMS时，最搞不清的就是「主密钥」到底是个什么角色。你想想看，一个加密系统里既有数据密钥，又有主密钥，还有HSM里的密钥，是不是很容易绕晕？
我个人的习惯是把主密钥（CMK）理解成「钥匙串上的那把总钥匙」。它不直接加密你的业务数据，而是用来保护其他密钥——这就是所谓的密钥层次结构。没有它，下层所有密钥的安全性都是空中楼阁。
4.1 什么是主密钥（CMK）
主密钥，全称 Customer Master Key，本质上是一个对称密钥，长度通常为256位（AES-256）或128位。它存在于KMS服务内部，用户永远无法直接拿到它的明文。
它的职责只有两件：
- 加密/解密数据密钥（DEK）——这才是真正加密你文件、数据库、对象存储的密钥。
- 作为密钥层次结构的根——你可以用CMK派生多个版本，或者用它包装其他密钥。
举个例子，你在云上存储一个文件，流程是：CMK → 加密生成 DEK → DEK 加密文件。这跟家里门禁系统一样，总控卡（CMK）不直接开门，而是授权临时卡（DEK）去开门。
4.2 CMK 的生命周期
很多人在项目里只关心「怎么创建CMK」，却忽略了后续的轮换、归档和销毁。我曾经在某个金融项目里，就因为没及时轮换主密钥，导致安全审计被挂了红灯……从那以后我每次设计KMS方案，都会把生命周期每个阶段都画清楚。
4.3 各阶段详解
4.3.1 创建
创建CMK时，你必须指定它的类型和保护方式。常见选项：
- 对称 CMK（AES-256）——最常用，用于加密DEK。
- 非对称 CMK（RSA 2048/4096、ECC）——用于数字签名或密钥交换。
- HSM 保护——密钥材料存储在硬件安全模块内，物理隔离。
举个例子，用AWS KMS创建对称CMK的调用：
// AWS CLI 示例
aws kms create-key \
--key-spec SYMMETRIC_DEFAULT \
--description "我的主密钥-文件加密" \
--key-usage ENCRYPT_DECRYPT实际项目中，我习惯把CMK的别名（Alias）绑到业务模块上，比如prod/users-encryption-key。这样后续轮换时，应用程序只需要引用别名，不用改代码。
4.3.2 激活与禁用
创建完后，CMK默认是启用状态。但有时候你需要临时禁用它——比如怀疑密钥被泄露，或者要暂停某个业务的加密操作。
嗯，这里要注意：禁用CMK后，所有基于该CMK生成的DEK仍然可以解密（因为KMS保存了密钥历史），但不能执行新的加密操作。这跟直接删除密钥不同，算是一种安全熔断机制。
4.3.3 使用（加密/解密）
这是CMK最核心的日常工作。你需要理解两个基本操作：
- GenerateDataKey – KMS内部生成一个DEK，并用CMK加密后返回给你（密文+明文DEK）。你用明文DEK加密业务数据，然后丢弃它。
- Decrypt – 将加密后的DEK密文传给KMS，KMS用CMK解密，返回明文DEK。
说白了，你的业务代码永远不会直接碰CMK的明文。连HSM里的密钥材料，你也不能导出。
// 生成数据密钥（伪代码）
response = kms.generate_data_key(
KeyId='alias/prod-users-encryption-key',
KeySpec='AES_256'
)
plaintext_dek = response['Plaintext'] // 立即使用，用完清除
ciphertext_dek = response['CiphertextBlob'] // 存储到元数据4.3.4 轮换
轮换就是生成一个新的密钥版本，但保留旧版本。KMS会自动维护版本间的继承关系。有两种轮换方式：
| 轮换类型 | 说明 | 适用场景 |
|---|---|---|
| 自动轮换 | KMS定期自动创建新版本（如每年一次） | 合规要求严格，人力不足 |
| 手动轮换 | 调用 CreateKey + 更新别名指向新密钥 | 需要精确控制轮换窗口 |
我曾经吃过一个亏：在自动轮换开启后，没注意旧版本仍然可以被解密。审计报告上显示「已销毁的密钥版本仍在产生解密操作」——其实是因为轮换不会自动禁用旧版本。所以后来我加了一条规则：轮换时同步把旧版本的禁用策略打开。
4.3.5 归档与销毁
归档的CMK处于禁用且不可用状态，但不会立即删除。这是为了给你留一个后悔期。
销毁是不可逆操作。一旦CMK被调度删除，KMS会等待一个等待期（通常是7-30天），然后才真正删除密钥材料。为什么不立即销毁？想想看，如果还有数据是用这个CMK加密的，销毁后那些数据就永远解不开了。
- 确认所有使用该CMK加密的数据已重新加密（用新CMK）
- 检查是否有备份或存档文件引用了该CMK
- 通知所有相关团队，确保没有遗留的定时任务
- 在非生产环境先演练一遍
4.4 生命周期各阶段对比
我整理了一张速查表，方便你在设计时对照：
| 阶段 | 能否加密？ | 能否解密？ | 能否轮换？ | 是否可逆？ |
|---|---|---|---|---|
| 创建（启用） | ✅ | ✅ | ✅ | - |
| 禁用 | ❌ | ✅（已有密文） | ❌ | ✅ 可重新启用 |
| 归档 | ❌ | ❌ | ❌ | ✅ 可恢复（未删除前） |
| 计划删除（等待期） | ❌ | ❌ | ❌ | ✅ 可取消删除 |
| 已销毁 | - | - | - | ❌ 永久不可恢复 |
最后多说一句：CMK的生命周期管理，其实是在安全和可用性之间做权衡。你轮换得太频繁，运维成本高；太久不轮换，风险累积。我的做法是：对核心业务CMK强制一年一轮换，并用自动化脚本检查轮换状态。嗯，安全这件事，永远都是「预防」比「救火」轻松得多。