3. 核心功能对比：密钥存储与加密
密钥存储和加密，说白了就是 Secrets Manager 的“心脏”。你想想看，如果连存密钥的地方都不够安全，那管理机密还有什么意义？我个人习惯在评估一款产品时，先看它的加密体系够不够“硬”。
这章我们就来拆解一下，主流 Secrets Manager 在密钥存储和加密这块到底是怎么做的，有哪些坑需要避开。
3.1 密钥的“三明治”结构
几乎所有商业级的 Secrets Manager，都遵循一个类似“三明治”的结构——分层加密。我个人认为，理解这个结构是选型的基础。
- 第一层：主密钥——由 KMS 或 HSM 管理，永远不离开安全边界。
- 第二层：数据密钥——由主密钥加密后下发给应用，用于实际加密机密内容。
- 第三层：密文——用数据密钥加密后的结果，存储在服务端。
为什么要这么麻烦？直接存不行吗？嗯，这里要注意：如果所有机密都用同一个主密钥加密，一旦密钥泄露，全军覆没。分层加密可以做到“一次一密”，而且主密钥可以定期轮换，影响面极小。
核心原则：主密钥不动，数据密钥常换，密文随便存。
3.2 主流服务商的加密实现对比
我简单列个表，把你可能会遇到的几个主流产品放在一起看，差异就很明显了。
| 产品 | 加密引擎 | 主密钥类型 | 是否支持 HSM | 加密算法 |
|---|---|---|---|---|
| AWS Secrets Manager | AWS KMS (信封加密) | AWS 托管或客户自主管理 | 支持 (CloudHSM) | AES-256-GCM |
| Azure Key Vault | Azure Key Vault (HSM 池) | 软件保护或 HSM 保护 | 原生支持 (托管 HSM) | AES-256 / RSA-OAEP |
| GCP Secret Manager | Cloud KMS + 信封加密 | Google 托管或 CMEK | 支持 (Cloud HSM) | AES-256-GCM |
| HashiCorp Vault | Vault 内置加密 (Barrier) | 自管理 / 对接外部 KMS | 支持 (PKCS#11 / HSM) | AES-256-GCM / ChaCha20-Poly1305 |
| CyberArk Conjur | Conjur 内置加密 | 自管理 | 有限支持 | AES-256-CBC |
一个小技巧：如果合规要求必须用硬件加密（比如金融行业），优先看 Azure Key Vault 或 接了 HSM 的 AWS CloudHSM。我遇到过不少客户，一开始用软件保护，审计一来只能连夜迁移。
3.3 数据密钥的轮换策略
轮换密钥，听起来很简单，但不同产品的实现天差地别。我简单分了三类：
- 自动轮换：AWS Secrets Manager 可以直接设置周期（比如 30 天），它会自动生成新版本并保留旧版本。注意：自动轮换不保证旧版本立刻失效，你的应用可能还在用旧版。我曾经遇到过因为轮换后没更新缓存，导致业务中断半小时的案例。
- 手动轮换：GCP Secret Manager 和 Azure Key Vault 都支持手动创建新版本。你可以在应用里写逻辑去拿最新版本。
- 无版本轮换：一些轻量级工具（比如 Vault 的 KV 引擎）直接覆盖原值，不留历史。这适合非生产环境，但生产环境千万别这么干——出问题你连回滚的机会都没有。
我的建议：生产环境至少保留 2-3 个旧版本。轮换时先写新版本，等所有应用都切过去，再删旧版本。这叫“蓝绿轮换”。
3.4 加密算法的选择
目前行业标准是 AES-256-GCM，支持认证加密，能防篡改。我在项目中遇到过一个“坑”：
有同事选了 AES-256-CBC，结果忘了做 HMAC，机密内容被篡改了都不知道——虽然概率低，但合规审计不通过。
HashiCorp Vault 还支持 ChaCha20-Poly1305，这是谷歌和现代 CPU 都推荐的安全算法，性能更好，尤其适合移动端和边缘设备。如果你主要跑在 x86 服务器上，选 AES-256-GCM 就够了，不用纠结。
3.5 静态数据 vs 传输中数据
大多数 Secrets Manager 只负责“存”，不负责“传”——你想想看，机密从服务端拉到应用内存，这个过程中的安全谁来管？
- 静态加密：所有产品都默认做，加密存在磁盘上。
- 传输中加密：API 调用强制用 TLS 1.2+。有些产品（如 Vault）还支持 mTLS，双向认证，更安全。
- 内存加密：极少产品做。如果你有极高标准（比如防侧信道攻击），可能得自己动手：用 memguard 或 Libsodium 的加密内存区域。
避坑指南：我曾经见过一个部署，Secrets Manager 传过来的密钥被应用直接打印到日志里——加密再强也没用。记得在应用层做密钥的访问控制和缓存清理。
3.6 本地缓存与远程解密
每次取密钥都去远程调用，性能肯定扛不住。所以大多数产品都支持本地缓存。
- AWS / GCP / Azure：SDK 默认做缓存，TTL 可配。
- HashiCorp Vault：支持 client-side 缓存，也支持中间代理缓存（如 Vault Agent）。
- CyberArk：有本地缓存文件，但要注意文件权限。
不过缓存的代价是：一旦服务端轮换了密钥，客户端可能还在用旧的。我建议把缓存 TTL 设置成 5-10 分钟，既保证性能，又不至于“失联”太久。如果要求秒级响应，那你得考虑 Push 模式（比如 Vault 的动态密钥）。
3.7 小结
选 Secrets Manager 的时候，别光看加密算法有多强——那只是冰山一角。真正关键的，是密钥的生命周期管理：谁创建、谁使用、谁销毁、怎么审计。我个人的习惯是先画一个“密钥流转图”，把主密钥、数据密钥、密文的边界画清楚，再决定用哪家。