Azure RBAC 内置角色详解：Key Vault Administrator、Reader、Crypto Officer
RBAC 角色这件事，说白了就是帮你定义“谁能在 Key Vault 上做什么”。我刚开始接触的时候，觉得角色名字太多容易混淆。后来带团队做了一次权限审计，才明白每个角色背后都有明确的权限边界。
Key Vault Administrator
这个角色是 Key Vault 里的超级管理员。它能控制管理平面，也能操作数据平面。你想想看，有了这个角色，你不仅能创建、删除保管库，还能管理密钥、机密和证书的生命周期。
核心权限清单（部分）：
- 管理平面： vaults/write, vaults/delete, vaults/read
- 数据平面（密钥）： keys/* 包括 create, delete, get, list, import, backup, restore, encrypt, decrypt, sign, verify, wrapKey, unwrapKey
- 数据平面（机密）： secrets/* 包括 set, delete, get, list, backup, restore
- 数据平面（证书）： certificates/* 包括 create, delete, get, list, update, import
我曾在一个项目中，客户把所有管理员都直接给了这个角色。后来我发现，其实很多人只需要管理密钥，并不需要动机密。我建议按实际工作拆分，后面会聊怎么选。
Key Vault Reader
这个角色最轻量。它只能读元数据——也就是你能看到保管库存在，能列出密钥、机密、证书的名字和属性，但拿不到实际值。说白了，就是“只读浏览员”。
| 权限项 | 说明 |
|---|---|
| vaults/read | 查看保管库基本信息 |
| keys/read | 列出密钥名称及属性，不能取值 |
| secrets/read | 列出机密名称及属性，不能获取机密值 |
| certificates/read | 列出证书名称及属性，不能下载私钥 |
我曾经遇到一个场景：安全审计人员只需要确认保管库是否存在、密钥是否过期。我给了他们 Reader 角色，完美解决问题。不要小看这个角色，它的价值在于最小权限原则。
Key Vault Crypto Officer
这个角色专注在密钥的数据平面操作，但不能管管理平面。它适合那些需要生成、导入、轮换、删除密钥，但不能改变保管库配置的人。
典型职责： 密钥轮换、密钥备份恢复、启用/禁用密钥版本。注意，它没有 keys/export 权限，所以不能导出私钥——这是安全设计。
我记得有一次，一个应用团队需要定期轮换加密密钥，但又不能让他们删除整个保管库。我给他们分配了 Crypto Officer，既满足了操作需求，又锁死了管理平面。嗯，这里要注意，Crypto Officer 虽然能删除密钥，但删除前一般要复核。
角色对比与选择建议
把三个角色放一起对比，你就能看出差异。
| 角色名称 | 管理平面 | 数据平面（密钥） | 数据平面（机密） | 数据平面（证书） | 典型人员 |
|---|---|---|---|---|---|
| Key Vault Administrator | 完全控制 | 完全控制 | 完全控制 | 完全控制 | 云安全管理员 |
| Key Vault Reader | 只读 | 只读元数据 | 只读元数据 | 只读元数据 | 审计员 |
| Key Vault Crypto Officer | 无 | 创建、删除、轮换、备份恢复，无导出 | 无 | 无 | 加密运维工程师 |
你看，Administrator 权限最大，但风险也高。我建议遵守最小权限原则：能用 Reader 就别给更多。能用 Crypto Officer 就别给 Administrator。我曾经在迁移时误给了管理员角色，结果某次误操作删除了整个保管库，还好有软删除救了一命。
# 查看角色定义（Azure CLI 示例）
az role definition list --name "Key Vault Administrator"
# 输出 JSON 中会包含 actions、dataActions 等字段
注意： 角色分配是作用域级别的。你可以把 Administrator 分配给订阅级别，也可以只分配给某个资源组或单个保管库。我建议精确到保管库级别，避免范围过大。
最后，用一张图总结这三个角色的关系与覆盖范围。
嗯，这一章讲的三个角色，你在实际项目中大概率都会用到。我个人的经验是：先给最少的，再按需扩展。别一上来就塞 Administrator，不然审计的时候你会很头疼。