第 3 章 密钥生命周期管理（生成、分发、轮换、撤销）
密钥管理这件事，说白了就是管好钥匙从出生到销毁的全程。我在很多项目里见过，大家只顾着把密钥生成出来，后面怎么分发、多久换一次、密钥泄露了怎么废掉，完全没想过。结果呢？等出了安全事故再追查，才发现密钥已经在外面流浪好几个月了。
这一章咱们把四个阶段拆开揉碎了讲。你跟着我的习惯走一遍，至少能避免80%的常见坑。
3.1 密钥生成
密钥生成不是随便调个API就完事了。我记得有一次帮客户复盘，他们用的RSA密钥是用Math.random()生成的……嗯，那组密钥我扫了一眼就知道：周期短、可预测，跟没加密一样。
核心原则：熵源要硬，算法要准，参数要合规。
- 熵源：生产环境必须用硬件安全模块（HSM）或操作系统提供的真随机数生成器（比如Linux的/dev/random）。别偷懒用伪随机。
- 算法：对称密钥用AES-256，非对称用RSA-4096或椭圆曲线（P-384以上）。国密场景用SM2/SM4。
- 参数：密钥长度、有效期、用途标签一定要打全。我习惯在生成时就把元数据写入密钥管理数据库，方便后续追溯。
小技巧：生成时顺带计算一个密钥指纹（SHA-256哈希），后面验证分发完整性的时候直接比对指纹就行，不用解密数据。
3.2 密钥分发
分发是密钥生命周期里最脆弱的环节。你想想看，密钥刚从安全环境生出来，就要通过网络或物理介质送到各个使用者手里——但凡中间被拦截一次，整个系统就完了。
我推荐的分发方式：
- 离线分发（物理隔离）——最安全，但只适合少量节点。我曾经给一个金融核心系统送过U盘，里面加密打包的密钥，专人护送，当面解锁。
- 在线分发——必须走TLS+双向证书认证。同时用密钥协商协议（比如ECDH）先建立一个临时通道，再传实际密钥。
- 混合分发：主密钥离线分，工作密钥在线轮换。
避坑：我曾经见过一个团队把密钥明文放在配置文件的JSON里，Git提交时忘了加.gitignore……结果密钥在公开仓库里躺了半年。记住：密钥永远不要以明文形式出现在任何持久化介质里，包括日志、数据库、代码仓库。
3.3 密钥轮换
轮换是为了降低单次泄露的损失。为什么？因为如果密钥一直不变，攻击者只要偷到一次就能一直用。我建议的轮换策略是：工作密钥每月轮换，主密钥每年轮换。当然，具体频率要看业务敏感度。
轮换的流程我一般分三步走：
- 生成新密钥——同时保留旧密钥用于解密历史数据。
- 切换加密操作——所有新数据用新密钥加密，旧数据继续用旧密钥解密。
- 渐进式重加密——后台任务慢慢把旧数据用新密钥重新加密，完成后淘汰旧密钥。
| 轮换策略 | 适用场景 | 风险点 |
|---|---|---|
| 全部立即切换 | 密钥泄露后 | 性能冲击大，需停机 |
| 渐进式重加密 | 常态化轮换 | 实现复杂，需跟踪状态 |
| 双密钥模式 | 高可用集群 | 管理成本翻倍 |
实战经验：我习惯在轮换前先跑一次“密钥使用审计”，看看哪些节点还在用旧密钥。否则你轮换完了，某个老服务还在用旧密钥加密，那新旧数据就混了。
3.4 密钥撤销
撤销是最后一关，却往往被忽略。密钥泄露了、员工离职了、设备退役了——都得立刻撤销。
撤销不是删掉就完事。你想想看，如果密钥被用来加密了历史数据，你删了它，那些数据就永远解不开了。正确的做法是：
- 标记为撤销（不立即删除）——将密钥状态置为“REVOKED”，写入证书撤销列表（CRL）或密钥管理系统的黑名单。
- 通知所有依赖方——通过消息队列或API推送变更事件。
- 重加密受影响数据——用新密钥把旧数据解密再加密，这一步走完才能安全删除旧密钥。
- 安全销毁——对HSM中的密钥调用销毁API，对软件密钥覆写三遍（全0、全1、随机）再释放内存。
别踩的坑：我曾经看过一个系统把撤销直接做成“物理删除”，结果历史数据全部报废。所以我现在坚持：撤销是逻辑动作，删除是最后一步。中间必须有缓冲期。
3.5 生命周期全景图
四个阶段不是孤立的——它们串成一个闭环。我把这个闭环画成了一张图，你扫一眼就能记住。
我每次看这个图都会在脑子里过一遍：生成时有没有打好标签？分发时有没有做完整性校验？轮换时有没有通知下游？撤销时有没有留缓冲？每一步都过一遍，基本上不会出大问题。
总结：密钥生命周期管理，本质上就是一套“出生→传递→换新→注销”的纪律。工具可以买，流程可以抄，但纪律得靠团队自己养成。我个人习惯每季度做一次密钥健康检查，把超过半年没轮换的密钥全部标红，然后逐个清理。别等到出了事再后悔。