2. 密钥生命周期管理：生成、分发、使用、轮换、销毁

说实话，密钥管理这件事，很多人一上来就盯着“怎么轮换”，觉得只要定时把密钥换掉就万事大吉。我当年也是这么想的。直到有一次线上故障，排查到最后发现是因为旧密钥还没销毁，和新密钥同时生效，导致解密逻辑紊乱……嗯，那之后我才真正理解：密钥的每一个阶段，从诞生到死亡，都藏着坑。

这一章我们就系统地把密钥生命周期过一遍。我习惯用五个阶段来划分：生成 → 分发 → 使用 → 轮换 → 销毁。每个阶段都有它的边界变化，轮换正是中间的枢纽。

2.1 生成：起点决定了安全上限

密钥生成，说白了就是创造一把“锁的钥匙”。我见过不少团队直接用 openssl rand 随便一跑就上线了，运气好没事，运气不好就是灾难。为什么？因为随机数的质量直接决定了密钥的不可预测性。

我个人习惯遵循这些原则：

• 用硬件随机数或内核熵池，别用伪随机库（比如 rand()）
• 指定算法和长度：AES-256 用 32 字节，RSA 至少 2048 位
• 生成时记录元数据：谁生成的？什么时间？用于哪个环境？

# 推荐做法：用 /dev/urandom + openssl
openssl rand -base64 32 > secret.key
# 或更规范的做法：用 key 管理工具
gpg --gen-key --batch < keyparams.txt

2.2 分发：安全地送到目的地

密钥生成之后，怎么送到各个服务手里？这步最容易出问题。很多公司直接把密钥写在配置文件里，提交到 Git 仓库——我称之为“自杀式分发”。

实际项目中，分发要考虑三个维度：

1. 传输加密：用 TLS，或干脆走带外方式（U 盘、专用终端）
2. 授权控制：谁有权限拿到密钥？要用最小权限原则
3. 完整性校验：每次分发后校验哈希，确保没被篡改

分发方式	安全性	适用场景	我踩过的坑
文件传输 + TLS	中	内部服务间	证书过期导致传输失败
密钥管理服务 (KMS)	高	云原生、多环境	很少踩坑，推荐
带外手动拷贝	高	离线环境、初始引导	容易遗漏版本号

你想想看，如果一个密钥分发出去却不知道谁手里有副本，那跟把钥匙挂在门口有什么区别？

2.3 使用：别让密钥“裸奔”

密钥在使用阶段，最容易犯的错误是：明文常驻内存、日志泄露、权限过宽。我参与过一个审计，发现某服务的密钥竟然以环境变量的形式打印到了日志文件里——当时真是倒吸一口凉气。

规范的使用方式应该满足：

• 只在需要时加载到内存，用完及时擦除
• 不写入日志、异常栈、调试输出
• 区分“加密密钥”和“签名密钥”，用途别混
• 使用过程中定期检查密钥是否过期

2.4 轮换：边界变化的艺术

终于说到轮换了。这是本课程的核心，但这里我们先把它放在生命周期里看个全貌。轮换的本质是：用一个新密钥替换旧密钥，同时保证业务不中断。

轮换期间会出现一个“双密钥共存窗口”——旧密钥还在用，新密钥已经上线。这个窗口就是边界变化的体现。我习惯把这期间的密钥分为三个状态：

• 活跃 (Active)：当前主要使用的密钥
• 过渡 (Transitioning)：刚引入的新密钥，只用于加密新数据
• 废弃 (Deprecated)：旧密钥，只用于解密已有数据，不再加密

轮换的触发条件一般有三种：

1. 时间驱动——比如每 90 天强制换一次
2. 事件驱动——密钥泄露、人员变动、合规要求
3. 版本驱动——算法升级，比如从 RSA-2048 换成 ECDSA

2.5 销毁：干净利落地终结

密钥的终点不是轮换，是销毁。很多系统到了轮换这一步就停了，旧密钥一直躺在存储里。这很危险——攻击者如果拿到了旧密钥，依然能解密历史数据。

销毁分两个层面：

• 逻辑销毁：标记为不可用，从访问控制列表中移除
• 物理销毁：彻底从存储介质中删除或覆盖

我记得有一个项目用的是 HSM（硬件安全模块），销毁时直接调用了 HSM 提供的 deleteKey() API。但那个 API 只是软删除，密钥还能恢复。后来我们不得不手动触发 HSM 的安全擦除命令——那真是折腾了一整晚。

# 软件层面销毁示例（Linux）
shred -n 3 -z secret.key   # 覆盖三次后归零
rm secret.key              # 删除文件
# 对于 KMS 托管密钥，直接调用：aws kms schedule-key-deletion --key-id xxx --pending-window-in-days 7