第3章 密钥存储安全模型：对称加密、非对称加密、密钥分层结构
这一章我们聊聊密钥存储的安全模型。说实话，这是整个KMS里最容易踩坑的地方。我见过不少团队，密钥管理做得很用心，但存储模型没选对，最后还是出了问题。别急，我们一步步拆开看。
3.1 对称加密 vs 非对称加密
先理清这两个基础概念。对称加密，就是加密和解密用同一把密钥。打个比方：你有一把锁，自己手里还有一把能开它的钥匙。别人想看你锁在箱子里的东西，你得把钥匙也给他。非对称加密呢？你发一把公钥出去，大家都能用它加密东西，但只有你手里的私钥才能解密。说白了，公钥是锁，私钥是开锁的钥匙，但这两把钥匙长得可不一样。
我在项目中遇到过一个典型的场景：公司内部要做日志加密。起初大家觉得对称加密效率高、实现简单，就直接用了AES-256-GCM。结果密钥轮换的时候出了问题——所有用同一把密钥加密的旧日志都要跟着重新加密，数据量太大了，一跑就是几十个小时。后来我建议改用非对称加密：公钥给日志采集端，私钥只留在安全区域。再也不需要批量重新加密了。
两者该怎么选？我习惯用一个简单的判断表：
| 对比项 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1把（共享密钥） | 2把（公钥+私钥） |
| 加解密速度 | 快（硬件加速支持好） | 慢（通常慢100-1000倍） |
| 密钥分发难度 | 高（需要安全通道） | 低（公钥可公开） |
| 典型算法 | AES, SM4, ChaCha20 | RSA, ECC, SM2 |
| 适用场景 | 大量数据加密、存储加密 | 数字签名、密钥交换、小数据加密 |
我曾经在一个项目里直接用了RSA加密大文件——加解密过程慢到让用户崩溃。后来把RSA挪去加密AES密钥（也就是DEK），真正的数据用AES加密，速度一下就上来了。记住，非对称加密不适合大块数据。
3.2 密钥分层结构：KEK 与 DEK
这一节才是重点。有经验的同学可能听过“密钥分层”，但你真的理解它为什么能大幅提升安全性吗？
先看定义：
- KEK（Key Encryption Key）——主密钥，用来加密其他密钥。通常存储在HSM或安全硬件里，极少被调用。
- DEK（Data Encryption Key）——数据加密密钥，真正用来加密业务数据的键值。它本身以密文形式存储，只有用KEK才能解密出明文DEK。
为什么非得分两层？你想想看，如果所有数据都直接用一把主密钥加密，那主密钥一旦暴露，所有数据就全完了。而且主密钥轮换时，所有数据都要重新解密再加密——这就像搬家时把整栋楼换锁，每次都要撬门换锁芯，不现实。分层之后，主密钥只负责保护DEK，数据量小，轮换成本很低。DEK可以随时生成、随时轮换，互不影响。
我个人习惯用“保险柜里放钥匙盒”来类比：KEK是保险柜的主密码，DEK是钥匙盒里的小钥匙。数据是柜子里的文件。你要取文件，先开保险柜（KEK解密DEK），再拿出小钥匙开门（DEK解密数据）。小钥匙丢了可以换，保险柜密码变了也不影响小钥匙。
3.3 分层模型的实际落地
在KMS场景里，分层结构几乎是标配。AWS KMS、Azure Key Vault，甚至你们公司内部的自研KMS，底层都是这个逻辑。我参与过的一个金融项目里，客户要求每个业务模块用不同的DEK，但所有DEK都统一由同一个KEK保护。KEK存在专用HSM里，每次调用都需要多管理员授权。这样既做到了密钥隔离，又控制了管理员权限。
下面这张图把对称/非对称加密和分层结构的关系画清楚了：
分层模型把密钥的存储与使用分离开来。KEK 永远不出安全硬件，DEK 可以随时生成、随时废弃。这就是为什么 AWS KMS 能支持每秒百万级加密请求，而主密钥却几乎没有被暴露的机会。
3.4 什么时候该用哪一层？
我归纳了一份简单的决策清单，平时写方案时经常参考：
- 保护少量关键密钥（如根证书私钥） → 直接用非对称加密，私钥放在HSM里。
- 保护大量业务数据 → 采用分层结构：用非对称或对称的KEK保护DEK，DEK用对称算法加密数据。
- 需要密钥轮换 → 分层结构最省心，只要重新加密DEK即可，不用动数据。
- 跨组织或跨系统分发密钥 → 用非对称加密交换KEK，后续用对称密钥做批量加密。
在KMS配置里，我会把KEK的别名写成“kek-{env}-{region}”，DEK则用UUID命名，方便审计追溯。以前有次排障，同事把所有密钥都叫“key1”“key2”，查日志时差点崩溃——嗯，从那以后我强制命名规范。
3.5 避坑指南
讲几个真实教训，希望你能避开：
- 不要把KEK和DEK放在同一个数据库里。 我见过有团队把所有密钥一股脑塞进同一个表，权限也不区分。一旦撞库，两层保护形同虚设。
- 不要存储明文DEK。 每次使用DEK时，都必须通过KEK解密得到明文，用完立刻释放。我在代码审查时经常看到有人把解密后的DEK塞进全局变量——这就是安全漏洞。
- 注意密钥缓存策略。 解密DEK是有性能开销的，但缓存太多又会增加泄露风险。一般建议在内存中缓存最近使用的DEK，设置TTL（比如5分钟），过期后重新从KMS获取。
好了，这章就到这里。密钥安全模型是基础中的基础，但真正用对、用好，需要反复实践。下一章我们会深入KMS的密钥生命周期管理——轮换、销毁、归档，这些操作在分层模型下会变得非常清晰。
好了，这章就到这里。密钥安全模型是基础中的基础，但真正用对、用好，需要反复实践。希望你在实际项目中能把这套模型用扎实。