从保管库访问策略迁移到 Azure 基于角色的访问控制(预览)权限模型Migrate from vault access policy to an Azure role-based access control (preview) permission model

保管库访问策略模型是内置于 Key Vault 中的现有授权系统,用于提供对密钥、机密和证书的访问权限。Vault access policy model is an existing authorization system built in Key Vault to provide access to keys, secrets, and certificates. 可以通过在 Key Vault 范围内将个人权限分配给安全主体(用户、组、服务主体、托管标识)来控制访问。You can control access by assigning individual permissions to security principal(user, group, service principal, managed identity) at Key Vault scope.

Azure 基于角色的访问控制 (Azure RBAC) 是在 Azure 资源管理器基础上构建的授权系统,针对 Azure 资源提供精细的访问权限管理。Azure role-based access control (Azure RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources. 用于 Key Vault 密钥、机密和证书访问管理的 Azure RBAC 当前提供公共预览版。Azure RBAC for Key Vault keys, secrets, and certificates access management is currently in Public Preview. 使用 Azure RBAC,你可以通过创建角色分配来控制对资源的访问,这些角色分配由三个元素组成:安全主体、角色定义(预定义的权限集)和范围(资源组或单个资源)。With Azure RBAC you control access to resources by creating roles assignments, which consists of three elements: security principal, role definition (predefined set of permissions), and scope (group of resources or individual resource). 有关详细信息,请参阅 Azure 基于角色的访问控制 (Azure RBAC)For more information, see Azure role-based access control (Azure RBAC).

在迁移到 Azure RBAC 之前,请务必了解其优点和限制。Before migrating to Azure RBAC, it's important to understand its benefits and limitations.

与保管库访问策略相比,Azure RBAC 密钥的优点是:Azure RBAC key benefits over vault access policies:

  • 为 Azure 资源提供统一的访问控制模型 - Azure 服务中的相同 APIProvides unified access control model for Azure resources - same API across Azure services
  • 针对管理员的集中式访问管理 - 在一个视图中管理所有 Azure 资源Centralized access management for administrators - manage all Azure resources in one view
  • Privileged Identity Management 集成以实现基于时间的访问控制Integrated with Privileged Identity Management for time-based access control
  • 拒绝分配 - 可以排除特定范围内的安全主体。Deny assignments - ability to exclude security principal at particular scope. 有关信息,请参阅了解 Azure 拒绝分配For information, see Understand Azure Deny Assignments

Azure RBAC 的缺点:Azure RBAC disadvantages:

  • 角色分配延迟 - 可能需要几分钟才能应用角色分配。Latency for role assignments - it can take several minutes for role assignment to be applied. 保管库访问策略会立即分配。Vault access policies are assigned instantly.
  • 角色分配数量有限 - 每个订阅 2000 个角色分配,每个 Key Vault 有 1024 个访问策略Limited number of role assignments - 2000 roles assignments per subscription versus 1024 access policies per Key Vault

Azure 角色映射的访问策略Access policies to Azure roles mapping

Azure RBAC 基于角色的访问控制有多个 Azure 内置角色,可将其分配给用户、组、服务主体和托管标识。Azure RBAC has several Azure built-in roles that you can assign to users, groups, service principals, and managed identities. 如果内置角色不能满足组织的特定需求,你可以创建自己的 Azure 自定义角色If the built-in roles don't meet the specific needs of your organization, you can create your own Azure custom roles.

用于密钥、证书和机密访问管理的 Key Vault 内置角色:Key Vault built-in roles for keys, certificates, and secrets access management:

  • 密钥保管库管理员(预览版)Key Vault Administrator (preview)
  • 密钥保管库读取者(预览版)Key Vault Reader (preview)
  • Key Vault 证书管理人员(预览版)Key Vault Certificate Officer (preview)
  • 密钥保管库加密管理人员(预览版)Key Vault Crypto Officer (preview)
  • 密钥保管库加密用户(预览版)Key Vault Crypto User (preview)
  • 密钥保管库机密管理人员(预览版)Key Vault Secrets Officer (preview)
  • 密钥保管库机密用户(预览版)Key Vault Secrets User (preview)

有关现有内置角色的详细信息,请参阅 Azure 内置角色For more information about existing built-in roles, see Azure built-in roles

可以通过单独选择的权限或预定义的权限模板来分配保管库访问策略。Vault access policies can be assigned with individually selected permissions or with predefined permission templates.

访问策略预定义的权限模板:Access policies predefined permission templates:

  • 密钥、机密、证书管理Key, Secret, Certificate Management
  • 密钥和机密管理Key & Secret Management
  • 机密和证书管理Secret & Certificate Management
  • 密钥管理Key Management
  • 机密管理Secret Management
  • 证书管理Certificate Management
  • SQL Server 连接器SQL Server Connector
  • Azure Data Lake Storage 或 Azure 存储Azure Data Lake Storage or Azure Storage
  • Azure 备份Azure Backup
  • Exchange Online 客户密钥Exchange Online Customer Key
  • SharePoint Online 客户密钥SharePoint Online Customer Key
  • Azure 信息 BYOKAzure Information BYOK

Azure 角色映射的访问策略模板Access policies templates to Azure roles mapping

访问策略模板Access policy template 操作Operations Azure 角色Azure role
密钥、机密、证书管理Key, Secret, Certificate Management 密钥:所有操作Keys: all operations
证书:所有操作Certificates: all operations
机密:所有操作Secrets: all operations
密钥保管库管理员(预览版)Key Vault Administrator (preview)
密钥和机密管理Key & Secret Management 密钥:所有操作Keys: all operations
机密:所有操作Secrets: all operations
密钥保管库加密管理人员(预览版)Key Vault Crypto Officer (preview)
密钥保管库机密管理人员(预览版)Key Vault Secrets Officer (preview)
机密和证书管理Secret & Certificate Management 证书:所有操作Certificates: all operations
机密:所有操作Secrets: all operations
密钥保管库证书管理人员(预览版)Key Vault Certificates Officer (preview)
密钥保管库机密管理人员(预览版)Key Vault Secrets Officer (preview)
密钥管理Key Management 密钥:所有操作Keys: all operations 密钥保管库加密管理人员(预览版)Key Vault Crypto Officer (preview)
机密管理Secret Management 机密:所有操作Secrets: all operations 密钥保管库机密管理人员(预览版)Key Vault Secrets Officer (preview)
证书管理Certificate Management 证书:所有操作Certificates: all operations 密钥保管库证书管理人员(预览版)Key Vault Certificates Officer (preview)
SQL Server 连接器SQL Server Connector 密钥:获取、列出、包装密钥、解包密钥Keys: get, list, wrap key, unwrap key 密钥保管库加密服务加密(预览版)Key Vault Crypto Service Encryption (preview)
Azure Data Lake Storage 或 Azure 存储Azure Data Lake Storage or Azure Storage 密钥:获取、列出、解包密钥Keys: get, list, unwrap key 空值N/A
所需的自定义角色Custom role required
Azure 备份Azure Backup 密钥:获取、列出、备份Keys: get, list, backup
证书:获取、列出、备份Certificate: get, list, backup
空值N/A
所需的自定义角色Custom role required
Exchange Online 客户密钥Exchange Online Customer Key 密钥:获取、列出、包装密钥、解包密钥Keys: get, list, wrap key, unwrap key 密钥保管库加密服务加密(预览版)Key Vault Crypto Service Encryption (preview)
Exchange Online 客户密钥Exchange Online Customer Key 密钥:获取、列出、包装密钥、解包密钥Keys: get, list, wrap key, unwrap key 密钥保管库加密服务加密(预览版)Key Vault Crypto Service Encryption (preview)
Azure 信息 BYOKAzure Information BYOK 密钥:获取、解密、签名Keys: get, decrypt, sign 空值N/A
所需的自定义角色Custom role required

分配范围映射Assignment scopes mapping

适用于 Key Vault 的 Azure RBAC 允许在以下范围内分配角色:Azure RBAC for Key Vault allows roles assignment at following scopes:

  • 管理组Management group
  • 订阅Subscription
  • 资源组Resource group
  • Key Vault 资源Key Vault resource
  • 单个密钥、机密和证书Individual key, secret, and certificate

保管库访问策略权限模型限制为仅在 Key Vault 资源级别分配策略。Vault access policy permission model is limited to assign policy only at Key Vault resource level, which

通常,最好每个应用程序都有一个密钥保管库,并在密钥保管库级别管理访问权限。In general, it's best practice to have one key vault per application and manage access at key vault level. 在某些情况下,在其他范围内管理访问权限可以简化访问管理。There are scenarios when managing access at other scopes can simplify access management.

  • **基础结构、安全管理员和操作员:使用保管库访问策略在管理组、订阅或资源组级别管理密钥保管库组需要维护每个密钥保管库的策略。**Infrastructure, security administrators and operators: managing group of key vaults at management group, subscription or resource group level with vault access policies requires maintaining policies for each key vault. Azure RBAC 允许在管理组、订阅或资源组范围创建一个角色分配。Azure RBAC allows creating one role assignment at management group, subscription, or resource group. 该分配将应用于在同一范围创建的任何新的密钥保管库。That assignment will apply to any new key vaults created under the same scope. 在这种情况下,建议将 Privileged Identity Management 与实时访问结合使用,而不是提供永久访问权限。In this scenario, it's recommended to use Privileged Identity Management with just-in time access over providing permanent access.

  • **应用程序:在某些情况下,应用程序需要与其他应用程序共享机密。**Applications: there are scenarios when application would need to share secret with other application. 如果使用保管库访问策略,则必须创建单独的密钥保管库,以避免提供对所有机密的访问权限。Using vault access polices separate key vault had to be created to avoid giving access to all secrets. Azure RBAC 允许针对单个机密分配角色,而不使用单个密钥保管库。Azure RBAC allows assign role with scope for individual secret instead using single key vault.

将保管库访问策略迁移到 Azure RBAC 的步骤Vault access policy to Azure RBAC migration steps

Azure RBAC 和保管库访问策略权限模型之间存在很多差异。There are many differences between Azure RBAC and vault access policy permission model. 为了避免迁移过程中出现中断,建议执行以下步骤。In order, to avoid outages during migration, below steps are recommended.

  1. 识别并分配角色:根据上面的映射表标识内置角色并根据需要创建自定义角色。Identify and assign roles: identify built-in roles based on mapping table above and create custom roles when needed. 根据范围映射指南,在范围内分配角色。Assign roles at scopes, based on scopes mapping guidance. 有关如何将角色分配到密钥保管库的详细信息,请参阅通过 Azure 基于角色的访问控制(预览)提供对 Key Vault 的访问权限For more information on how to assign roles to key vault, see Provide access to Key Vault with an Azure role-based access control (preview)
  2. 验证角色分配:Azure RBAC 中的角色分配可能需要几分钟才能传播。Validate roles assignment: role assignments in Azure RBAC can take several minutes to propagate. 有关如何检查角色分配的指南,请参阅列出范围内的角色分配For guide how to check role assignments, see List roles assignments at scope
  3. 在密钥保管库上配置监视和警报:请务必启用日志记录并针对拒绝访问异常设置警报。Configure monitoring and alerting on key vault: it's important to enable logging and setup alerting for access denied exceptions. 有关详细信息,请参阅 Azure Key Vault 的监视和警报For more information, see Monitoring and alerting for Azure Key Vault
  4. 在 Key Vault 上设置 Azure 基于角色的访问控制权限模型:启用 Azure RBAC 权限模型将使所有现有的访问策略失效。Set Azure role-based access control permission model on Key Vault: enabling Azure RBAC permission model will invalidate all existing access policies. 如果出现错误,则可以在所有现有访问策略保持不变的情况下切换回权限模型。If an error, permission model can be switched back with all existing access policies remaining untouched.

备注

启用 Azure RBAC 权限模型后,尝试更新访问策略的所有脚本都将失败。When Azure RBAC permission model is enabled, all scripts which attempt to update access policies will fail. 请务必更新这些脚本以使用 Azure RBAC。It is important to update those scripts to use Azure RBAC.

疑难解答Troubleshooting

  • 几分钟后角色分配不起作用 - 在某些情况下,角色分配可能需要更长时间。Role assignment not working after several minutes - there are situations when role assignments can take longer. 在代码中编写重试逻辑来处理这些情况是非常重要的。It's important to write retry logic in code to cover those cases.
  • 删除(软删除)并恢复 Key Vault 时角色分配消失 - 所有 Azure 服务中的软删除功能当前都受到此限制。Role assignments disappeared when Key Vault was deleted (soft-delete) and recovered - it's currently a limitation of soft-delete feature across all Azure services. 在恢复后,需要重新创建所有角色分配。It's required to recreate all role assignments after recovery.

了解更多Learn more