KMS 是什么？先别急，我们从一次事故说起
我第一次接触 KMS，是在一个金融项目的加密改造上。当时生产环境的数据加密密钥直接写死在代码里，结果某天运维误操作把配置文件打到了公开仓库……
嗯，后面的事儿我就不细说了。总之，那次之后我彻底明白了：密钥管理，不是“把密码记在脑子里”那么简单。
KMS——Key Management Service，说白了就是一个专门替你管密钥的保险柜。你不需要自己操心密钥怎么存、怎么轮换、怎么销毁，KMS 把这些脏活累活全包了。
但要注意：KMS 不是万能药。用不对地方，照样出大问题。我们先吃透最基础的概念。
密钥的类型：对称 vs 非对称
我见过不少刚入行的同学在这里犯晕。咱们一句话讲清楚：
| 密钥类型 | 用几把钥匙 | 典型用途 | 我踩过的坑 |
|---|---|---|---|
| 对称密钥 | 一把钥匙，既锁门又开门 | 数据加密、大文件加密 | 曾经把数据库的列加密密钥和传输密钥混用，结果审计时一团糟 |
| 非对称密钥 | 公钥锁门，私钥开门 | 数字签名、TLS 证书、密钥交换 | 有一次私钥权限开了只读，签名服务跑了一周才发现 |
我个人的习惯是：能用对称的绝不用非对称，除非必须要做签名或密钥交换。对称密钥速度快、开销小，但分发是老大难——这时候 KMS 的价值就出来了。
密钥层级：CMK 和 DEK 到底是什么关系？
你想想看，如果数据加密密钥直接由用户管理，那和写在文件里有啥区别？所以 KMS 引入了两层结构。
- CMK（客户主密钥）：
它是你的“根密钥”，存在 KMS 的硬件安全模块（HSM）里，永远不离开 KMS。
你无法导出 CMK 的明文，只能用它来加密/解密其他密钥。 - DEK（数据加密密钥）：
在本地生成，用来加密实际数据。
用法：先用 CMK 加密 DEK，然后把加密后的 DEK 和数据存在一起。解密时再调 KMS 解出 DEK 明文。
一句话记住：CMK 是管钥匙的钥匙，DEK 是管数据的钥匙。分开存，分开管，审计才有意义。
我曾经犯过的错：直接把 DEK 的明文存在配置中心，还觉得“没问题，反正 CMK 是安全的”。结果 DEK 被扫出来后，所有加密数据等于没加密。
正确做法：永远只存加密后的 DEK，需要使用时才临时解密到内存中，用完立刻清空。
正确做法：永远只存加密后的 DEK，需要使用时才临时解密到内存中，用完立刻清空。
密钥的生命周期管理：从生到死的每一步都不能省
为什么生命周期的概念这么重要？我在审计一个遗留系统时发现，6 年前的 CMK 仍然在服役，轮换策略从来没人执行过。你想想看，这意味着什么？
——如果那个 CMK 被攻破，所有历史数据都要遭殃。
一个标准的 KMS 密钥生命周期包括这几个阶段：
- 创建（创建）：指定密钥类型、用途，KMS 在 HSM 内部生成密钥材料。
- 启用（启用）：密钥进入可用状态，可以用于加密/解密操作。
- 禁用/计划删除（禁用/计划删除）：临时停用或设置一个等待期（通常 7-30 天）再真正删除。
- 轮换（轮换）：生成新密钥材料，但保留旧密钥用于解密历史数据。
- 销毁（销毁）：彻底删除密钥材料，一旦销毁就再也无法恢复数据。
我个人的建议：所有 CMK 都开启 自动轮换（1 年一次）。对于高频使用的 DEK，可以设置更短的轮换周期（比如 90 天）。
但记住：轮换的是密钥材料，不是密钥 ID——数据中存的加密 DEK 仍然需要旧密钥来解密。
但记住：轮换的是密钥材料，不是密钥 ID——数据中存的加密 DEK 仍然需要旧密钥来解密。
今晚就可以动手的实操
- 打开你的云控制台，找到 KMS 服务，看看当前环境中有没有“过期未轮换”的 CMK。
- 检查一下 DEK 的存储方式——是明文还是加密后的密文？
- 确认密钥的删除保护是否开启。如果没有，我建议先开启，万一误操作能留条后路。
一个顺手的小工具：如果你们用的云厂商没有提供密钥审计，可以用 SDK 写个脚本，每天扫描一遍所有密钥的创建时间、上次使用时间，超过 1 年未使用的 CMK 直接标记为“灰名单”。