密钥管理基本概念
聊密钥管理之前，我想先问个问题：你公司的加密密钥都放在哪？
有人跟我说存数据库里，有人说写配置文件里，还有人干脆记在文本文件里往服务器上一丢。说实话，每次听到这些我都挺揪心的。密钥管理如果不搞清楚，加密体系就是纸糊的。
这一节我们就来梳理密钥管理的基础。我尽量用大白话讲清楚，让你听完就知道该怎么做。
密钥生命周期
密钥从生到死，得管好每一步。我习惯把它分成七个阶段：
- 密钥生成——不能在软件里拍脑袋产生，要用硬件随机数生成器
- 密钥分发——怎么安全送到使用方手里，这是最容易出问题的环节
- 密钥存储——存哪、存成什么样、谁来管读写权限
- 密钥使用——谁在用、用在哪、每次用是否要审计
- 密钥轮换——用久了就得换，不能一个密钥包打天下
- 密钥归档——退役的密钥不能直接删，得留着解密历史数据
- 密钥销毁——彻底清除密钥材料，让它无法恢复
核心原则：密钥生命周期中，存储和销毁是最容易被忽略的两环。我见过太多系统密钥明文躺着，销毁时只删了数据库记录，磁盘上的数据还在。这样的“销毁”等于没用。
密钥分类与层次结构
密钥不能只有一种，得分层。为什么？你想想看，如果所有数据都用同一把密钥加密，一旦密钥泄露，所有数据都得玩完。
我习惯把这套体系叫「密钥树」。大概是这么分的：
| 层级 | 名称 | 用途 | 典型存储位置 |
|---|---|---|---|
| 第0层 | 主密钥（MK） | 保护下层所有密钥 | HSM / TPM 硬件内部 |
| 第1层 | 密钥加密密钥（KEK） | 加密工作密钥 | HSM 或加密数据库 |
| 第2层 | 工作密钥（DEK） | 加密实际业务数据 | 内存中临时使用 |
这个分层结构有个好处：主密钥不动，下层密钥可以随便轮换。我在项目中遇到过，某次合规审查要求所有数据库加密密钥必须季度轮换。如果只有一层密钥，那等于要重加密全部数据，业务得停半天。但分了层之后，我们只需要用主密钥解密当前 KEK，再重新加密一份新 KEK 就行，数据本身不动。合规轻松通过。
密钥安全原则
有几个原则我得重点拎出来说。这些年踩过的坑，基本都是因为没守住这些底线。
- 密钥绝不离开硬件——主密钥从生成到销毁，生命周期全程在 HSM 内完成。不能导出，不能备份成文件。
- 最小权限原则——谁需要谁拿，用完之后立即清除。我曾经遇到过，测试团队拿生产密钥做压测，结果日志里把密钥内容打印出来了。嗯，那之后我们加了严格的访问审计。
- 密钥与数据分离存储——密钥存一个地方，加密数据存另一个地方。入侵者拿下数据库也拿不到密钥。
- 定期轮换——密钥用久了，被破解概率逐渐上升。轮换周期取决于你的安全等级标准。
- 密钥版本管理——每次轮换生成新版本，旧版本保留用以解密历史数据。但不能用来加密新数据。
警告：千万不要把密钥硬编码在代码里！我见过一个金融系统，居然把 AES 密钥写死在 Java class 常量池中。反编译后直接看到密钥——整个加密体系形同虚设。
密钥使用规范
密钥怎么用，也要有章法。我把常见使用场景整理一下：
- 数据加密：工作密钥加密数据，结果返回给应用
- 数据解密：应用传入密文和密钥ID，HSM 解密后返回明文
- 数字签名：私钥在 HSM 内签名，应用只拿签名值
- 密钥包装：用主密钥把工作密钥加密保护，方便传输和存储
这里面最容易被忽略的是「密钥包装」。有些团队觉得「我直接把工作密钥发给 HSM 不就行了？」其实不行。工作密钥在传输过程中要加密保护，这个过程就叫密钥包装。说白了，就是给密钥再加一道锁。
密钥轮换策略
轮换不是拍脑袋决定的。我一般遵循这样的策略：
| 密钥类型 | 建议轮换周期 | 轮换方式 |
|---|---|---|
| 主密钥（MK） | 1-2年 | HSM 内部生成新密钥对 |
| 密钥加密密钥（KEK） | 6-12个月 | 用新主密钥重新包装 |
| 工作密钥（DEK） | 3-6个月 | 重新加密数据 |
小技巧：如果你用 HSM，大部分设备都支持自动轮换策略。你只需要设置好周期，HSM 会自动完成。我建议你从季度轮换开始，根据审计结果再调整频率。
核心知识体系
下面这张图把密钥管理的基础结构串起来了。你可以把它当作一张导航地图，后续章节都会基于这个框架展开。
图上其实已经把本章的核心逻辑讲清楚了：密钥生命周期管好每个阶段，层次化结构降低风险，安全原则是红线，使用场景是具体落地。这些内容吃透了，后面的 KMS 集成和 HSM 实操环节你才不会发懵。
我个人建议你把这张图保存下来，后面讲到具体技术方案时，随时回来对照。你会发现每个方案无非是在这些基础概念上做的工程化落地。