密钥管理基础：加密算法与密钥生命周期
聊密钥管理，得先想明白一件事——加密算法是公式，密钥才是那个决定结果的变量。我见过太多团队一上来就纠结选AES还是SM4，把密钥随便往配置文件里一塞就跑路了。结果呢？攻破的不是算法，是密钥本身。
这一节，我们把加密算法和密钥生命周期拆开揉碎。说白了，就是先搞清楚用什么工具，再搞明白怎么管好工具的核心——密钥。
对称加密与非对称加密——选哪个？
这里不背概念名称，咱们从使用场景的角度，看我整理的这张对比表：
| 维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1个（加解密共用） | 2个（公钥加密，私钥解密） |
| 典型算法 | AES-256, SM4, 3DES | RSA-2048, SM2, ECC |
| 处理速度 | 快（硬件加速后可达GB/s级） | 慢（RSA-2048每秒约几百次签名） |
| 密钥分发 | 困难（需要安全通道） | 容易（公钥可公开） |
| 适用场景 | 大数据量加密、存储加密、通信加密 | 数字签名、密钥交换、小数据加密 |
挑算法我很直接：数据加密优先用AES-256-GCM，因为带认证，能防篡改。数字签名必须用非对称，比如SM2或ECC。别自己拼密码学组合——我在项目里见过有人用AES-CTR拼HMAC，结果nonce重用直接门洞大开。
关键原则：对称加密解决性能，非对称加密解决信任。实际系统里，往往拿非对称加密去保护对称密钥，这样两头都占着。
密钥生存周期——从生到死的管理
密钥不是生成出来就能一直用到死的。我习惯把密钥生命周期分成六个阶段，每个阶段都有坑，我挨个踩过。
- 生成：用硬件随机数发生器，别用math.random()。
- 分发：通过安全信道传输，常用PKI或预置方式。
- 存储：加密后存储，密钥套密钥（KEK）方案。
- 使用：限制使用次数或时长，避免过度暴露。
- 轮换：定时或事件驱动更新密钥。
- 销毁：主动覆盖或物理销毁，防止残余恢复。
个人经验：我曾在项目中要求密钥每90天轮换一次。结果被运维骂惨了——因为旧的加密数据还用老密钥加密的，必须设计好过渡期。后来我改用版本化的密钥，轮换时新写用新密钥，旧读保留旧密钥，才稳住局面。
下面这张流程图，把六个阶段和它们之间的关系画清楚了：
你看，轮换是唯一能回到生成阶段的箭头，其他都是单向流。销毁则是终点，不可逆。
密钥存储方案——别放进代码里
我曾经接手过一个遗留系统，密钥直接硬编码在Python脚本的字符串里。审计时让我当场血压飙升。正确的做法：
- 使用HSM（硬件安全模块）或TEE（可信执行环境）
- 或使用密钥管理服务（KMS），比如云上的Vault、KMS
- 本地环境至少用操作系统密钥存储（如Keychain、DPAPI）
避坑指南：我曾经把密钥加密后存在数据库，但加密密钥本身存在配置文件中。这属于把锁挂门上但钥匙挂墙上的做法。正确的做法是使用分层密钥结构——主密钥（Master Key）由HSM保护，数据密钥由主密钥加密后存储。
密钥轮换策略——别太频繁也别太懒
轮换频率取决于算法和威胁模型。我总结了几种常见场景的推荐值：
| 场景 | 建议轮换周期 | 驱动方式 |
|---|---|---|
| 静态数据加密（AES-256） | 1~2年 | 时间驱动 |
| TLS会话密钥 | 每次会话 | 事件驱动 |
| JWT签名密钥 | 30~90天 | 时间+吊销事件 |
| 用户口令派生密钥 | 用户修改密码时 | 事件驱动 |
轮换不是简单换个密钥就完事。你得确保旧密钥留够时间，让所有用旧密钥加密的数据都能被解密。我建议引入密钥版本号，每个加密对象都标明用哪个版本密钥加密的。这样轮换时，旧版本依然可用，新数据才用新版本。
密钥销毁——别只delete file
很多人以为把密钥文件删了就完了。但文件系统只是标记为已删除，数据还在磁盘扇区里躺着。恰当的方式：
- 软件层面：写入随机数据覆盖原存储区域（多次覆盖）
- 硬件层面：HSM提供安全的密钥销毁命令
- 对于云KMS：直接调用DestroyKey API（注意有等待期）
小技巧：我习惯在密钥结构体中加一个active字段。销毁时先标记为inactive，等待一个冷却期（比如30天）再物理销毁。万一发现误判，还能紧急恢复。
嗯，加密算法和密钥生命周期，说白了就是一套从生成到销毁的规矩。规矩定好了，后面讲到数据分级和权限控制时，才有底气说“这个密钥管得住”。