4、常见的 Secrets 存储方案：Vault、AWS Secrets Manager、Azure Key Vault
聊到 Secrets 的管理，第一步就是选一个靠谱的存储方案。市面上的选择不少，但真正经过大规模生产验证的，也就那么几个。我个人这些年做过的项目里，最常打交道的就是 HashiCorp Vault、AWS Secrets Manager 和 Azure Key Vault。说实话，没有一个万能钥匙，每个方案都有自己的脾气秉性。
选错了方案，后面审计日志都没法好好落地。你想想看，如果 Secrets 本身没法做细粒度访问审计，那咱们这门课后面讲的所有审计分析和告警都成了空谈。所以这一章，我把三个主流方案的架构特点、适用场景、以及我在项目中踩过的坑，一次性给你理清楚。
HashiCorp Vault——混合云时代的瑞士军刀
先聊 Vault。我个人用得最多的就是它。为什么？因为它不绑死在一个云上。你公司要是混合云架构，或者跨多家云，Vault 几乎是唯一的选择。
Vault 的核心思路是「动态 Secret」。说白了，它不是给你一把永不过期的钥匙，而是每次应用需要访问数据库时，Vault 动态生成一个临时凭据，用完就销毁。我在一个金融项目里遇到过，因为静态密码泄露导致整个生产库被拖，后来切到 Vault 的动态 Secret，就算攻击者拿到凭据，几分钟后也会自动失效。这个设计对审计日志的意义非常大——每一份凭据的生命周期都是可追溯的。
Vault 审计日志特点：
- 原生支持审计后端（文件、Syslog、Socket）
- 每条操作记录包含：时间戳、客户端IP、操作类型、路径、Secret 元数据
- 可以通过审计策略做细粒度过滤
不过 Vault 的运维门槛不低。它需要你维护一套高可用集群，存储后端（Consul、Raft、文件系统）也得你自己管。我曾经有个同事因为 Raft 节点分裂丢过数据……嗯，这里要提醒你：Vault 的存储后端建议选集成 Raft 的 HA 模式，单点文件存储千万别上生产。
AWS Secrets Manager——云原生玩家的首选
如果你全套跑在 AWS 上，那 Secrets Manager 就是最省心的选择。它跟 IAM、KMS、CloudTrail 深度集成，你几乎不需要额外搭建任何基础设施。
我最喜欢它的自动轮换功能。你只要定义一个 CloudFormation 模板或者 Lambda 函数，Secrets Manager 就会按你设定的周期自动换密。我有个项目里的 RDS 密码每 30 天轮换一次，审计日志里每个轮换事件都清清楚楚，合规审计直接拿日志交差，省了不少事。
一个小经验：
开启自动轮换后，一定要先测试 Lambda 的权限和网络连通性。我见过一次轮换脚本因为 VPC 没有 NAT 网关，导致连接超时，老密码直接被删了，应用全挂了。后来我们在轮换前加了心跳检查。
说到审计日志，Secrets Manager 本身不生产单独的审计日志，所有操作都记录在 CloudTrail 里。你需要通过 CloudTrail 事件来追踪谁在什么时候调用了 GetSecretValue、PutSecretValue。你在做审计日志分析时，要记得把 Secrets Manager 和 CloudTrail 的日志关联起来。
# 示例：通过 CloudTrail 查询 Secrets Manager 操作
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventSource,AttributeValue=secretsmanager.amazonaws.com \
--query 'Events[*].{Time:EventTime,User:Username,Event:EventName,Resource:Resources[0].ResourceName}' \
--output tableAzure Key Vault——微软生态的合规利器
Azure Key Vault 呢？如果你主打 Azure，它天然跟 Azure AD、Azure Policy、Azure Monitor 集成。它在合规性上做得特别细，支持软删除和清除保护，避免手滑把整个 Key Vault 连根拔掉。
我记得有一次做 PCI DSS 合规，审计要求所有 Secret 的访问都要记录访问者的身份、目的、时间。Key Vault 的日志直接通过 Azure Monitor 推送到 Log Analytics，查询起来非常顺手。而且它支持 RBAC，你可以精确到某个 Secret 的读写权限，审计日志里会带上调用者的 Object ID。
注意：
Azure Key Vault 有两种权限模型：访问策略和 RBAC。如果你用了访问策略，审计日志里只会出现 SPN 或用户主体名，不会显示细粒度的角色。我建议统一用 RBAC，审计日志的可读性和可审计性都更好。
不过 Key Vault 的局限性也很明显——它不直接支持动态 Secret 生成。你要实现类似 Vault 的动态数据库密码，得自己写 Logic App 或 Function 去轮换。对于已经上了 Azure 全栈的团队来说，这个额外的开发量还可以承受，但如果你的团队规模小，我建议先用托管方案，别一开始就上自定义轮换。
三者的关键对比
| 维度 | HashiCorp Vault | AWS Secrets Manager | Azure Key Vault |
|---|---|---|---|
| 部署模式 | 自托管或 HCP Cloud | 全托管 | 全托管 |
| 动态 Secret | ✅ 原生支持 | ❌ 仅静态 | ❌ 仅静态 |
| 自动轮换 | 需插件或外部调度 | ✅ 原生 Lambda 驱动 | 需自定义 |
| 审计日志集成 | 文件/Syslog/Socket | CloudTrail | Azure Monitor + Log Analytics |
| 运维复杂度 | 高 | 低 | 低 |
| 跨云/混合云支撑 | ✅ 强 | ❌ 限 AWS | ❌ 限 Azure |
总结一下选择逻辑：
- 如果你在多个云之间跑服务，或者需要动态 Secret，Vault 是唯一选项。但团队要有人能运维。
- 如果你全栈 AWS，Secrets Manager 最简单，配合 CloudTrail 做审计日志很顺畅。
- 如果你全栈 Azure，Key Vault 的合规能力最强，尤其是 RBAC 和软删除。