Azure Key Vault 核心概念与架构
好，我们开始聊 Azure Key Vault。说实话，我第一次接触它的时候，觉得这玩意儿不就是个密码本吗？后来被现实狠狠教育了一回——那次我把数据库连接字符串直接写死在配置里，结果代码库被扫出高危漏洞……嗯，从那以后，我再也不敢小看密钥管理这件事了。
Key Vault 本质上是一个安全的“保险箱”。但它不是你把钥匙放进去就完事的那种。它提供了三层隔离：管理平面（控制谁可以碰这个 vault）、数据平面（控制谁可以读写里面的 secret、key、certificate），以及网络平面（控制从哪个 IP 或 VNet 能访问）。我个人习惯把这三层想象成大楼的门禁、保险柜的密码锁、以及专线电梯——缺一不可。
Secret 的存储与版本管理
说白了，Secret 就是 Key Vault 里最常用的东西——连接字符串、、密码，啥都往里塞。但你想想看，如果每次更新都覆盖旧的，回滚就完蛋了。所以 Key Vault 为每个 Secret 保留了版本号。每次 set 操作都会生成一个新版本，而且旧版本默认仍然可读。
关键行为：调用 GetSecret 不指定版本时，返回当前版本（latest）。指定旧版本的 URI 仍然可以获取历史值，直到你主动删除该版本。
我在项目里遇到过这样一种情况：CI/CD 流水线每次部署都调用 SetSecret 更新同一个名称的 secret，结果产生了上百个版本，每个月多花了几十块钱的存储费。嗯，这其实是个坑——版本数没有上限，但每个版本都会产生费用。我建议定期清理老旧版本，只保留最后 N 个。
创建 Secret 有几种方式：
- Azure CLI：
az keyvault secret set --vault-name MyVault --name MySecret --value "my-value" - Azure PowerShell：
Set-AzKeyVaultSecret -VaultName MyVault -Name MySecret -SecretValue (ConvertTo-SecureString "my-value" -AsPlainText -Force) - REST API：
PUT /secrets/{secret-name}?api-version=7.4 - Azure SDK (.NET / Java / Python / JS)
我的小技巧：尽量把 secret 的 content-type 设置清楚，比如 application/x-www-form-urlencoded 或 text/plain。虽然不影响功能，但后期维护时一看就知道这是什么东西。
访问策略管理：别再用“全部权限”了
Access Policy 是传统做法——你在 vault 上绑定一个 Azure AD 用户/组/服务主体，然后勾选“Get”、“List”、“Set”、“Delete”等权限。听起来简单，但实际用起来很容易失控。我曾经在一个项目里看到有人给整个开发团队赋予了“所有密钥权限”，结果实习生不小心删除了生产环境的加密 key……嗯，那一天我深刻理解了“最小权限原则”不是一句口号。
现在微软推荐的是RBAC 方式（Azure 基于角色的访问控制）。你可以在 Key Vault 的“访问控制 (IAM)”里分配内置角色，比如“Key Vault Secrets User”（只能读，不能写）和“Key Vault Secrets Officer”（读写加管理）。
| 对比项 | Access Policy（传统） | RBAC（推荐） |
|---|---|---|
| 管理范围 | 仅单个 vault | 订阅/资源组/vault，可继承 |
| 权限粒度 | 细到 Get/List/Set/Delete 等操作 | 内置角色 + 自定义角色（支持通配符） |
| 维护成本 | 每个 vault 单独配置，容易遗漏 | 一次分配，多处生效 |
| 审计跟踪 | 需额外配合诊断日志 | Azure Activity Log 直接记录 |
不过注意：RBAC 和 Access Policy 是互斥的（除了 Azure RBAC 数据平面预览期间有共存期）。你在创建 vault 时可以选择“访问策略方式”还是“RBAC 方式”，后面要改的话只能重建。所以我建议一开始就用 RBAC 模式——除非你有很老的托管应用只能走传统策略。
软删除与清除保护
这是个救命的功能。默认从 2020 年起，所有新创建的 Key Vault 都强制启用软删除。什么意思？你删掉一个 secret 或者整个 vault，它不会立刻消失，而是进入“软删除状态”，保留 90 天。这 90 天内你可以恢复，完全免费。
为什么说救命？我记得有一次在生产环境上，同事不小心用 PowerShell 脚本批量清理了所有 secret……当时所有人脸都白了。幸好软删除开着，我们通过 az keyvault secret list-deleted 找到了所有被删的 secret，然后一个个 az keyvault secret recover 恢复回来。整个过程大概用了 15 分钟，没造成任何业务影响。
注意：软删除只是“延迟删除”，并不等于备份。如果你在 90 天内没有恢复，secret 会被永久清除。此外，软删除期间你仍然不能使用相同的 secret 名称创建新版本——那会提示冲突。你必须先恢复或彻底清除旧版本。
清除保护（Purge Protection）是软删除的加强版。启用之后，即使在软删除状态下，任何人（包括管理员）都不能手动清除（purge）这些资源。只能等保留期自然结束。这个功能适合合规要求严格的场景——比如金融、医疗。我建议所有生产环境都打开它，哪怕你觉得“我们不会犯错的”——嗯，每个犯过错的人都这么想过。
启用方式很简单：创建 vault 时加上 --enable-purge-protection true；对于已有 vault，可以通过 Azure CLI 更新：
az keyvault update --name MyVault --enable-purge-protection true
或者你偷懒，直接在 Azure Portal 里打开“启用清除保护”开关。反正一旦打开就不能关闭——你确定要打开？对，就是这个意思。
经验之谈：开启清除保护后，az keyvault purge 命令会直接报错。如果你真的想“物理删除”一个 vault，只能在软删除状态等待 90 天。所以测试环境慎用，否则你可能需要等三个月才能彻底释放资源配额。
一个小结
Azure Key Vault 的核心设计其实挺清晰：一个 vault 就是一个安全边界，里面放 secret、key、certificate，通过 Azure AD + RBAC 或访问策略来控制谁能读谁不能读，最后用软删除兜底。你只要记住：默认启用软删除，优先用 RBAC，定期清理老旧版本，基本上不会翻车。
下回我们聊聊 AWS Secrets Manager，看看云巨头们在这个领域的思路有什么不同——嗯，先卖个关子。