Azure 密钥保管库提供了两个授权系统：Azure 基于角色的访问控制 (Azure RBAC)，以及访问策略模型。 Azure RBAC 是 Azure 密钥保管库的默认和推荐授权系统。 有关两种授权方法的比较，请参阅 Azure 基于角色的访问控制 (Azure RBAC) 与访问策略。
本文提供将密钥保管库从访问策略模型迁移到 Azure RBAC 模型所需的信息。
Azure 角色映射的访问策略
Azure RBAC 基于角色的访问控制有多个 Azure 内置角色，可将其分配给用户、组、服务主体和托管标识。 如果内置角色不能满足组织的特定需求，你可以创建自己的 Azure 自定义角色。
用于密钥、证书和机密访问管理的“密钥保管库”内置角色：
- Key Vault 管理员
- Key Vault 读取者
- 密钥保管库清除操作员
- Key Vault 证书管理人员
- 密钥保管库证书用户
- Key Vault 加密管理人员
- Key Vault 加密用户
- 密钥保管库加密服务加密用户
- 密钥保管库加密服务发布用户
- Key Vault 机密管理人员
- Key Vault 机密用户
有关现有内置角色的详细信息，请参阅 Azure 内置角色
可以通过单独选择的权限或预定义的权限模板来分配保管库访问策略。
访问策略预定义的权限模板：
- 密钥、机密、证书管理
- 密钥和机密管理
- 机密和证书管理
- 密钥管理
- 机密管理
- 证书管理
- SQL Server 连接器
- Azure Data Lake Storage 或 Azure 存储
- Azure 备份
- Exchange Online 客户密钥
- SharePoint Online 客户密钥
- Azure 信息 BYOK
Azure 角色映射的访问策略模板
| 访问策略模板 | 操作 | Azure 角色 |
|---|---|---|
| 密钥、机密、证书管理 | 密钥：所有操作 证书：所有操作 机密：所有操作 |
Key Vault 管理员 |
| 密钥和机密管理 | 密钥：所有操作 机密：所有操作 |
Key Vault 加密管理人员 Key Vault 机密管理人员 |
| 机密和证书管理 | 证书：所有操作 机密：所有操作 |
Key Vault 证书管理人员 Key Vault 机密管理人员 |
| 密钥管理 | 密钥：所有操作 | Key Vault 加密管理人员 |
| 机密管理 | 机密：所有操作 | Key Vault 机密管理人员 |
| 证书管理 | 证书：所有操作 | Key Vault 证书管理人员 |
| SQL Server 连接器 | 密钥：获取、列出、包装密钥、解包密钥 | 密钥保管库加密服务加密用户 |
| Azure Data Lake Storage 或 Azure 存储 | 密钥：获取、列出、解包密钥 | 空值 所需的自定义角色 |
| Azure 备份 | 密钥：获取、列出、备份 机密：获取、列出、备份 |
空值 所需的自定义角色 |
| Exchange Online 客户密钥 | 密钥：获取、列出、包装密钥、解包密钥 | 密钥保管库加密服务加密用户 |
| Exchange Online 客户密钥 | 密钥：获取、列出、包装密钥、解包密钥 | 密钥保管库加密服务加密用户 |
| Azure 信息 BYOK | 密钥：获取、解密、签名 | 空值 所需的自定义角色 |
分配范围映射
适用于 Key Vault 的 Azure RBAC 允许在以下范围内分配角色：
- 管理组
- 订阅
- 资源组
- Key Vault 资源
- 单个密钥、机密和证书
保管库访问策略权限模型限制为仅在 Key Vault 资源级别分配策略。
通常，最好每个应用程序都有一个密钥保管库，并在密钥保管库级别管理访问权限。 在某些情况下，在其他范围内管理访问权限可以简化访问管理。
基础结构、安全管理员和操作员：使用保管库访问策略在管理组、订阅或资源组级别管理密钥保管库组需要维护每个密钥保管库的策略。 Azure RBAC 允许在管理组、订阅或资源组范围创建一个角色分配。 该分配将应用于在同一范围创建的任何新的密钥保管库。 在这种情况下，建议将 Privileged Identity Management 与实时访问结合使用，而不是提供永久访问权限。
应用程序：在某些情况下，应用程序需要与其他应用程序共享机密。 如果使用保管库访问策略，则必须创建单独的密钥保管库，以避免提供对所有机密的访问权限。 Azure RBAC 允许针对单个机密分配角色，而不使用单个密钥保管库。
如何迁移
按照以下步骤将密钥保管库从访问策略迁移到 RBAC：
- 准备：确保你拥有适当的权限和应用程序的清单。
- 清单：记录所有现有的访问策略和权限。
- 创建 RBAC 角色：为每个安全主体分配适当的 RBAC 角色。
- 启用 RBAC：切换密钥保管库以使用 RBAC 权限模型。
- 验证：测试访问权限以确保所有应用程序和用户都保留适当的访问权限。
- 监视器：设置访问问题的监视和警报。
先决条件
在开始迁移之前，请确保具备：
所需权限：必须对密钥保管库具有以下权限：
-
Microsoft.Authorization/roleAssignments/write权限，包含在“所有者”和“用户访问管理员”角色中 -
Microsoft.KeyVault/vaults/write权限，包含在 Key Vault 贡献者角色中
注意
不支持经典订阅管理员角色（服务管理员和 Co-Administrator）。
-
应用程序和标识清单：列出访问密钥保管库的所有应用程序、服务和用户，并记录所有当前访问策略及其授予的权限。
清点当前访问策略
记录所有现有访问策略，指出安全主体（用户、组、服务主体）及其权限。
- Azure CLI
- Azure PowerShell
- Azure 门户
使用 Azure CLI az keyvault show 命令检索访问策略：
# List all current access policies
az keyvault show --name <vault-name> --resource-group <resource-group-name> --query properties.accessPolicies
创建等效的 RBAC 角色指派
对于具有访问策略的每个安全主体，请基于上面的映射表创建一个或多个 RBAC 角色分配。
- Azure CLI
- Azure PowerShell
- Azure 门户
使用 az role assignment create 命令授予相应的角色：
# Example for Key Vault Administrator role:
az role assignment create --role "Key Vault Administrator" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"
# Example for Key Vault Secrets Officer:
az role assignment create --role "Key Vault Secrets Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"
# Example for Key Vault Crypto Officer:
az role assignment create --role "Key Vault Crypto Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"
# Example for Key Vault Certificates Officer:
az role assignment create --role "Key Vault Certificates Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"
启用 RBAC 权限模型
创建所有必要的角色分配后，将保管库转换为使用 RBAC 权限模型。
- Azure CLI
- Azure PowerShell
- Azure 门户
使用 az keyvault update 命令启用 RBAC：
# Switch the vault to RBAC permission model
az keyvault update --name <vault-name> --resource-group <resource-group-name> --enable-rbac-authorization true
验证访问权限
测试访问保管库，以确保所有应用程序和用户仍然可以执行所需的操作。
- Azure CLI
- Azure PowerShell
- Azure 门户
使用以下命令测试访问权限：
# Try to list secrets to verify access
az keyvault secret list --vault-name <vault-name>
# Try to get a secret to verify access
az keyvault secret show --vault-name <vault-name> --name <secret-name>
设置监视和警报
迁移后，设置适当的监视以检测任何访问问题：
- Azure CLI
- Azure PowerShell
- Azure 门户
使用 az monitor diagnostic-settings create 命令：
# Enable diagnostics logging for Key Vault
az monitor diagnostic-settings create --resource <vault-id> --name KeyVaultLogs --logs "[{\"category\":\"AuditEvent\",\"enabled\":true}]" --workspace <log-analytics-workspace-id>
使用 Azure Policy 进行迁移治理
使用 Azure Policy 服务，可以跨保管库管理 RBAC 权限模型迁移。 可以创建自定义策略定义来审核现有密钥保管库，并强制所有新密钥保管库使用 Azure RBAC 权限模型。
为 Key Vault Azure RBAC 权限模型创建和分配策略定义
- 导航到策略资源
- 在 Azure Policy 页面左侧的“创作”下选择“分配”
- 选择页面顶部的 “分配策略 ”
- 输入以下信息：
- 通过选择订阅和资源组来定义策略的范围
- 选择策略定义：“[预览]：Azure Key Vault 应使用 RBAC 权限模型”
- 定义策略的所需效果（审核、拒绝或禁用）
- 通过查看和创建作业来完成工作分配
分配策略后，最长可能需要 24 小时才能完成扫描。 扫描完成后，可以在 Azure Policy 仪表板中看到符合性结果。
Azure RBAC 比较工具的访问策略
重要
此工具由 Azure 社区成员构建和维护，不提供正式的客户支持服务支持。 该工具按原样提供，不提供任何形式的保证。
PowerShell 工具，用于将密钥保管库访问策略与分配的 RBAC 角色进行比较，以帮助将访问策略迁移到 RBAC 权限模型。 该工具专用于在将现有密钥保管库迁移到 RBAC 权限模型时提供健全性检查，以确保具有基础数据操作的已分配角色将会涵盖现有的访问策略。
排查常见问题
- 角色分配延迟：角色分配可能需要几分钟才能传播。 在应用程序中实现重试逻辑。
- 恢复后丢失的角色分配：在经过软删除操作后恢复保管库时，不会保留角色分配。 必须在恢复后重新创建所有角色分配。
-
访问被拒绝错误：检查：
- 正确的角色在适当的范围内得到分配。
- 服务主体或托管标识具有所需的确切权限
- 网络访问规则未阻止连接
- 迁移后脚本失败：更新使用访问策略改用角色分配的任何脚本。