第4章 密钥管理基础：生成、存储、分发、轮换、销毁
密钥管理，说白了就是加密体系的命根子。你算法选得再强，密钥一旦泄露，一切归零。我在企业做落地项目时，最怕听到的一句话就是：“密钥我们放配置文件里了。”——听到这种话，我就知道后面得踩坑了。
这一章我们不讲空理论，就聊五个实操环节：生成、存储、分发、轮换、销毁。每个环节都有血泪教训，我帮你一一梳理清楚。
4.1 密钥生成：别用随机数糊弄自己
密钥生成是起点，也是很多人忽视的地方。你以为调用一下Math.random()就行？那可不行。Java里你用SecureRandom，Go里用crypto/rand，Python里用os.urandom，必须用密码学安全的伪随机数生成器（CSPRNG）。
rand()）生成的密钥，枚举成本极低。我在某次代码审计中见过一个 IoT 项目用 rand() 生成 AES-256 密钥，相当于锁了个纸糊的门。
另一个常见问题是密钥长度。看看这张表，你心里就有数了：
| 算法 | 推荐最小长度 | 备注 |
|---|---|---|
| AES | 256 bits | 128 bits 可接受（合规保守选256） |
| RSA | 2048 bits | 4096 bits 更安全但性能开销大 |
| ECDSA / ECDH | 256 bits (P-256) | 等效 RSA 3072 |
| HMAC | 256 bits | 至少与对称密钥等长 |
生成时最好设定密钥用途标签。举个例子，你用 KMS 或 HSM 生成密钥时，加上purpose: data-encryption、purpose: signing，别一把钥匙开所有锁。我曾经遇到过客户把签名密钥和加密密钥混用，后来签名密钥泄露，所有加密数据都得重来。
4.2 密钥存储：别放代码里，别放 GitHub 上
存储是翻车重灾区。我把常见错误列出来，你看看中了几条：
- 硬编码在源代码里——我见过把密钥写进配置文件还提交到 Git 仓库的
- 放到环境变量里就算完事——环境变量能被
ps aux或者子进程泄露 - 用对称加密加密密钥后把解密密钥放在同一台机器——这叫"把钥匙放在锁旁边"
正确的做法分三级：
- 硬件安全模块（HSM）：金融、政务等高安全场景首选。密钥物理隔离，永不离开硬件。
- 云 KMS（Key Management Service）：AES/HMAC 密钥由 KMS 生成，应用程序只拿密文或调用 API 加解密。我个人推荐这种方式，性价比高。
- 密钥派生（key derivation）：通过主密钥派生出工作密钥，主密钥存储在 HSM/KMS 中。
chmod 600 限制权限，并启用文件系统加密（LUKS 或 BitLocker）。但记住，这只是临时方案。
我参与过的一个电商项目，早期他们用 Kubernetes Secret 存数据库密码——Secret 默认 Base64 编码，根本不是加密。后来我们切到 AWS KMS + Secrets Manager，才算真正管住了钥匙。
4.3 密钥分发：安全的“快递”怎么走
分发的核心是：确保密钥在传输过程中不被窃取，且到达的是对的人。常见的分发方式有：
- 离线分发：运维人员用 U 盘送密钥——适合高密级，但操作成本高
- 公钥加密传输：用接收方的公钥加密密钥后通过网络传输
- Diffie-Hellman 密钥交换：双方在线协商出会话密钥，中间人攻击还需 PKI 验证
- KMS 跨区域复制：云上场景，由云服务商保障传输安全
嗯，这里要注意：分发过程中必须记录审计日志。谁在什么时间、向哪个目标分发了哪把密钥，都要留下痕迹。我曾在金融项目里因为缺失分发日志，出事之后根本追溯不了，全靠人工复盘，浪费了两周时间。
4.4 密钥轮换：别等到“过期”再换
为什么需要轮换？因为密钥用久了，被破解或泄露的风险累积。想想看，你同一把钥匙用十年，总比用一年更容易被复制，对吧？
轮换策略通常有两种：
- 强制轮换：定期（如每90天）生成新密钥，旧密钥保留解密能力但不再用于加密。
- 事件驱动轮换：发生安全事件（如员工离职、疑似泄露）时立即轮换。
我建议在实际项目里结合两者。比如公司规定每半年轮换一次，但如果发现某个密钥被异常读取，立刻手动触发轮换。
代码上怎么做轮换？给你一个伪代码示例：
# 轮换工作密钥的工作流
1. 生成新密钥 new_key_id = KMS.create_key()
2. 重新加密所有活跃数据对象：
for obj in active_data:
obj.decrypt_with(old_key_id)
obj.encrypt_with(new_key_id)
3. 更新上下文指向新密钥：
data_key_context = new_key_id
4. 禁用旧密钥的加密权限（保留解密权限）
5. 记录审计日志：key_rotation_event {old_key_id, new_key_id, timestamp}
实际业务中你可能没法一次性重加密所有数据（比如PB级别的对象存储）。那就可以采用“双缓存”模式：新数据用新密钥加密，旧数据访问时“按需重加密”。我做过一个消息队列的密钥轮换，就是用了延迟重加密，避免了停机窗口。
4.5 密钥销毁：彻底消失才算结束
销毁听起来简单——删文件不就行了？不，磁盘删除只是标记。要真正“物理销毁”：
- 软件删除：使用
shred（Linux）或cipher /w（Windows）覆写多次 - HSM 销毁：调用 HSM 的
deleteKey()接口，真正的硬件级删除 - KMS 销毁：设置排期删除（AWS 默认等待 7-30 天），期间仍可恢复
- 物理销毁：用碎纸机切掉存密钥的 HSM 卡片或硬盘
制定销毁策略时，建议给每个密钥设定生命周期：
| 密钥状态 | 描述 | 操作限制 |
|---|---|---|
| 活跃（Active） | 正用于加密和解密 | 正常使用 |
| 降级（Deprecated） | 不再用于加密，仅解密旧数据 | 只能解密，禁止加密 |
| 待销毁（Pending Destroy） | 等待排期删除 | 可恢复，不可使用 |
| 已销毁（Destroyed） | 物理或逻辑删除 | 不可逆 |
全景图：密钥管理五环节
下面这张图把五个环节串起来，帮你建立整体视角：
你看，这个生命周期不是一根直线——销毁之后你可能需要生成新密钥，形成闭环。实际落地中，这五个环节往往需要自动化工具串起来，而不是靠人手工操作。我建议尽可能用 KMS + 定时任务来自动轮换和归档。