KMS 密钥层次总览
密钥分层不是个新概念，但在 KMS 里它几乎是整个体系的骨架。很多人一开始觉得“不就是多包几层吗”，真上了生产环境才发现，不分层的话，密钥轮换、权限隔离、合规审计全都会乱成一锅粥。我最早做的一个云存储项目，所有密钥都堆在一个“万能密钥”下，结果一次泄露就得全量重加密——那滋味可不好受。所以这一节我们认真聊聊：为什么要分层？三层结构怎么搭？
为什么需要分层？
先看一个反例：如果只有一个密钥，用它直接加密所有业务数据。
- 密钥轮换时，你得把所有数据都解密再重新加密——数据量一大，根本做不动。
- 权限没法细粒度控制：谁拿到这个密钥，谁就能看所有数据。
- 硬件安全模块（HSM）的每次加解密调用都贵，高频业务场景根本撑不住。
分层的核心动机就是解耦：把“保护密钥的密钥”和“真正加密数据的密钥”分开。这样一来，你可以在不触碰数据密钥的前提下，安全地轮换上层密钥；数据密钥可以被大量生成、短周期使用、用完就销毁；权限也能做到“上层密钥管理严格，下层数据密钥自动分发”。
一句话总结：分层让你用少量的根密钥保护大量的数据密钥，同时满足安全、性能、合规三个维度的需求。
三层密钥的职责
KMS 的标准分层通常包含三层：根密钥（Root Key）、密钥加密密钥（KEK）、数据密钥（DEK）。它们的关系就像保险柜、钥匙盒和日常钥匙：
| 层级 | 别名 | 存储位置 | 生命周期 | 核心操作 |
|---|---|---|---|---|
| 根密钥 | 主密钥 / Master Key | HSM 或专用安全区域 | 长达数年，极少轮换 | 仅用来加密/解密 KEK |
| 密钥加密密钥 | KEK / Key Encryption Key | KMS 服务数据库（加密存储） | 按月或季度轮换 | 加密/解密 DEK |
| 数据密钥 | DEK / Data Encryption Key | 与应用数据一起存储（加密态） | 按需生成，用后即弃 | 加密/解密业务数据 |
我个人习惯：根密钥放在 HSM 里，且操作必须经过多人审批。KEK 走定期轮换流程，用自动化脚本跑。DEK 则完全交给业务方自行生成——每份数据一个 DEK，泄密也只影响那一条记录。
流转关系：一个请求的生命
举个例子。你的应用要加密一段用户手机号。流程是这样的：
- 业务服务向 KMS 申请一个 DEK。
- KMS 用当前有效的 KEK 加密生成一个 DEK，返回 DEK 的明文和密文。
- 业务用 DEK 明文加密数据，然后把 DEK 密文和密文数据一起存到数据库。
- 解密时，业务用 DEK 密文向 KMS 请求解密，KMS 用 KEK 解开得到 DEK 明文，再用它解密数据。
- 整个过程中，根密钥只出现在步骤 2 和 4 的内部——当 KEK 本身也需要被保护时，KMS 用根密钥来加密 KEK。
为什么这样绕一圈？因为根密钥永远不出 HSM，连 KMS 服务本身都不能直接拿到。KEK 虽然存在数据库里，但它是被根密钥加密过的，泄露了也没用。DEK 完全透明，业务层知道它的明文，但生命周期极短。
注意：DEK 绝不能落盘明文。业务拿到后要立刻使用，使用完立即从内存中擦除。我曾经见过一个项目把 DEK 明文写进了日志，结果日志泄露导致全量数据可解密——教训啊。
SVG 结构图：三层密钥层次
下面的图展示了根密钥、KEK、DEK 以及它们如何保护数据和彼此：
实际项目中的分层要点
光有理论还不够，落地时有几个坑得特别留神：
- 根密钥的备份与恢复：根密钥丢了，所有 KEK 和 DEK 都废了。我在某金融客户那边见过 HSM 损坏导致业务中断两天的事故——根密钥必须做异地多副本备份，且每个副本都要有严格的访问控制。
- KEK 的版本管理：KEK 轮换时，旧版本的 KEK 不能立即删除，因为还有大量 DEK 是用旧 KEK 加密的。你得保留历史版本，并标记“仅用于解密”。我习惯用版本号 + 时间戳来标识每个 KEK。
- DEK 的存储格式：推荐将 DEK 密文与加密后的数据紧挨着存储（比如同一条记录的某个字段），这样解密时不需要额外查询。但注意格式要自描述——例如
key_id:version:ciphertext，方便后续自动判断用哪个 KEK 来解密。
一个小技巧：在业务代码里，让 KMS 返回的 DEK 密文带上一个固定的前缀标记（比如 kms:v1:）。这样数据库里存的数据一眼就能看出是加密过的，而且未来升级密钥格式时，通过前缀就能做兼容处理。