4、访问策略：基于 Azure RBAC 的访问控制、传统 Vault 访问策略、权限分配最佳实践
谈到 Key Vault 的权限管理，你可能会想：不就是给个权限嘛，有什么好纠结的？
我刚开始接触时也这么觉得。直到一次线上事故——有人给了一个应用太宽泛的权限，结果误删了一堆证书。嗯，从那天起，我每次设计访问策略都会多花十分钟仔细想想。
4.1 传统 Vault 访问策略（Vault Access Policy）
这是早期的权限模型。说白了，你在 Key Vault 资源上直接绑一个策略对象。
每个策略可以指定主体（用户、组、服务主体）和允许的操作（比如 get、list、delete）。
用 Azure CLI 设置一个传统策略的例子：
az keyvault set-policy \
--name myVault \
--object-id "user-object-id" \
--secret-permissions get list \
--key-permissions get list \
--certificate-permissions get list你想想看，这种方式简单直接。但问题也很明显：
- 管理分散：每个 Vault 各自维护自己的策略，没法统一控管。
- 数量限制：一个 Vault 最多只能绑定 1024 条策略。大企业可能不够用。
- 粒度有限：只能控制到 get/list/delete 这一级，没法细到“只能读某个特定密钥版本”。
我记得有个客户，他们每个环境（开发、测试、生产）有单独的 Vault，但权限模型一模一样。结果每次新增应用，运维得手动改三个地方的策略……后来全部迁移到 RBAC 了。
4.2 基于 Azure RBAC 的访问控制
现在 Azure 推荐用 RBAC 来控制 Key Vault 的访问。本质上，你是在 Azure 资源管理层面管理权限，而不是 Vault 内部。
RBAC 有内置角色，比如：
| 角色名称 | 作用域 | 典型能干啥 |
|---|---|---|
| Key Vault 读者 | 订阅/资源组/Vault | 列出密钥、秘密、证书，但不能读取值 |
| Key Vault 机密用户 | Vault 或单个机密 | 读取机密的值（适合运行时应用） |
| Key Vault 管理员 | Vault / 管理组 | 所有数据操作 + 管理策略（适合运维团队） |
用 Azure CLI 给一个应用分配“机密用户”角色：
az role assignment create \
--assignee "sp-object-id" \
--role "Key Vault Secrets User" \
--scope "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/myVault"好处很明显：
- 统一管理：所有 Azure 资源共用一套 RBAC 体系，可以继承管理组权限。
- 精细作用域：可以精确到单个密钥、秘密或证书版本（预览功能）。
- 条件访问：支持 Azure AD 条件策略，比如要求 MFA 才能访问。
我曾经在项目中遇到过一个问题：两个模型混用。团队里部分人用传统策略，部分人用 RBAC。结果有个应用明明在 RBAC 里给了读者权限，却在传统策略里被拒绝了。Azure 会同时检查两个模型，任何一个拒绝都会导致拒绝。所以千万别混着用。
4.3 权限分配最佳实践
搞清楚了两种方式，那具体怎么选？我总结了几条：
- 新项目统一用 RBAC。除非你还在用不支持 RBAC 的旧 SDK 或 PowerShell 模块。
- 遵循最小权限原则。给应用只分配它需要的操作。比如只读密钥列表的应用，给个“Key Vault Reader”就够了，别给“Key Vault Secrets Officer”。
- 用托管标识代替直接分配。应用跑在 Azure VM 或 App Service 上时，用系统/用户分配托管标识。这样不需要手动管理服务主体的密钥。
- 定期审计。用 Azure Policy 和活动日志检查谁拿到了超出预期的权限。我每季度会跑一次脚本，把 Key Vault 的所有角色分配导出到 CSV 里审查。
有个小技巧：当你使用 RBAC 时，Key Vault 传统策略界面会灰掉，但里面还可能残留旧的策略。迁移完成后，建议手动清空传统策略，避免后续混淆。
最后说一个贴士：权限分配不是一次性的。随着业务变化，某些应用可能不再需要某个机密，或者需要换角色。我记得有次审查发现，一个测试应用居然在生产 Vault 上还有“删除”权限，赶紧撤销了。所以——定期检查权限，就像定期换牙刷一样，养成了习惯就不觉得麻烦了。