3. 车队密钥架构设计：单租户 vs 多租户密钥隔离、密钥层级结构、密钥缓存策略
密钥架构设计，说白了就是回答三个问题：密钥归谁管？密钥怎么分层？密钥怎么快取？这三个问题没想清楚，车队规模一上来，要么安全出漏洞，要么性能崩盘。我见过不少团队，一开始图省事把所有密钥放一个桶里，结果审计的时候根本分不清哪个密钥是哪个车队的——那叫一个头疼。
3.1 单租户 vs 多租户密钥隔离
先聊最基础的选择：每个车队独享一套密钥，还是所有车队共享一套密钥？
| 维度 | 单租户隔离 | 多租户共享 |
|---|---|---|
| 密钥数量 | 随车队数线性增长 | 固定，不随车队数变化 |
| 隔离强度 | 物理/逻辑完全隔离 | 依赖权限策略控制 |
| 运维成本 | 高，需管理大量密钥 | 低，集中管理 |
| 性能开销 | 无锁竞争 | 高并发时可能争抢 |
| 合规审计 | 天然清晰 | 需额外标记追踪 |
我个人习惯：金融、医疗等强合规场景，必须上单租户。普通业务车队，用多租户+密钥标签就够了。我在项目中遇到过一家出行平台，一开始用多租户共享密钥，后来被审计要求整改——每个车队必须能独立轮换密钥。那一次迁移，光拆密钥就拆了两周。
核心原则：隔离不是非黑即白。你可以用「混合模式」——根密钥按租户隔离，数据密钥共享池化。既保安全，又控成本。
3.2 密钥层级结构
密钥不能平铺，必须分层。为什么？你想想看，如果所有数据都用同一个密钥加密，一旦密钥泄露，所有数据都得完蛋。分层之后，即使数据密钥泄露，根密钥还在，损失可控。
我常用的三层结构是这样的：
- 根密钥（Root Key）：存储在KMS硬件安全模块中，永不离开HSM。用于加密下级密钥。
- 密钥加密密钥（KEK）：由根密钥加密保护，用于加密数据密钥。可以按车队、按区域、按环境分发。
- 数据密钥（Data Key）：实际加密业务数据的密钥。明文只在内存中短暂存在，用完即销毁。
我的经验：KEK层是性价比最高的设计点。你可以为每个车队分配独立的KEK，但所有车队共用同一套根密钥。这样根密钥数量可控，车队间的密钥隔离又足够强。我曾经帮一个客户从平铺密钥重构为三层结构，密钥管理量从5000个降到了50个，运维效率提升了10倍。
3.3 密钥缓存策略
每次加解密都去KMS请求密钥？那性能肯定扛不住。KMS的API调用有频率限制，而且网络延迟摆在那。所以，缓存是必须的。
但缓存也有风险——密钥在缓存里过期了怎么办？被篡改了怎么办？
3.3.1 缓存什么
- KEK的密文：可以长期缓存，因为它本身就是加密状态。
- 数据密钥的明文：只能短期缓存，且必须放在安全内存中。
- 密钥的元数据：版本号、创建时间、轮换状态，可以缓存较长时间。
3.3.2 缓存多久
| 缓存对象 | 建议TTL | 说明 |
|---|---|---|
| KEK密文 | 24小时 | 密文不怕泄露，但需感知轮换 |
| 数据密钥明文 | 5-15分钟 | 越短越安全，但需平衡性能 |
| 密钥元数据 | 1小时 | 轮换时主动失效 |
我曾经踩过的坑：数据密钥明文缓存设了30分钟，结果密钥在KMS侧被轮换后，业务还在用旧密钥加密了20分钟的新数据。解密时全报错。后来我改成「缓存+版本号校验」——每次使用前先比对缓存中的密钥版本和KMS返回的最新版本，不一致就立即刷新。
3.3.3 缓存失效策略
不能只靠TTL过期，还得有主动失效机制。我推荐的做法：
- 轮换时推送失效事件：KMS侧密钥轮换后，通过消息队列通知所有缓存节点。
- 懒加载+版本校验：每次使用密钥时，先检查本地版本号是否与KMS一致。
- 预热机制：大规模轮换前，提前把新密钥分发到各节点缓存中。
一句话总结：密钥缓存不是「存多久」的问题，而是「怎么知道它失效了」的问题。主动失效+版本校验，比单纯缩短TTL靠谱得多。
3.4 架构决策清单
最后，给你一个我在实际项目中用的决策清单。每次设计车队密钥架构时，我都会过一遍：
- ☐ 每个车队是否需要独立的根密钥？—— 合规要求决定
- ☐ KEK是按车队划分还是按环境划分？—— 运维复杂度决定
- ☐ 数据密钥的缓存TTL设多少？—— 安全与性能的平衡
- ☐ 密钥轮换时，缓存如何同步失效？—— 必须有主动通知机制
- ☐ 是否支持密钥版本回溯？—— 解密历史数据时需要
嗯，这些想清楚了，密钥架构就不会出大问题。记住一点：架构设计不是一次性的，它要跟着车队规模一起成长。一开始用多租户共享，等车队多了再拆，完全没问题——只要你在设计之初就留好扩展接口。