在 Azure 基于角色的访问控制 (Azure RBAC) 中,若要授予对 Azure 资源的访问权限,需要分配 Azure 角色。 例如,如果用户需要在订阅中创建和管理网站,则要分配“网站参与者”角色。
分配 Azure 角色以授予对 Azure 资源的访问权限是一项常见任务。 作为管理员,你可能会收到很多请求,要求授予你想要委托给其他用户的访问权限。 但是,你需要确保委托人只具有执行其工作所需的权限。 本文介绍一种将角色分配管理委托给组织中其他用户的更安全的方法。
为什么要委托角色分配管理?
以下是你可能希望将角色分配管理委托给其他用户的一些原因:
- 你收到在组织中分配角色的多个请求。
- 用户无法等待所需的角色分配。
- 各自部门、团队或项目中的用户更了解谁需要访问权限。
- 用户有权创建 Azure 资源,但需要额外的角色分配才能充分使用该资源。 例如:
- 如果没有虚拟机管理员登录或虚拟机用户登录角色,有权创建虚拟机的用户也无法立即登录虚拟机。 如果用户可以为自己分配登录角色,则无需跟踪管理员来为其分配登录角色,效率会更高。
- 开发人员有权创建 Azure Kubernetes 服务 (AKS) 群集和 Azure 容器注册表 (ACR),但需要将 AcrPull 角色分配给托管标识,以便可以从 ACR 拉取映像。 如果开发人员可以为自己分配 AcrPull 角色,则无需跟踪管理员来为其分配角色,效率会更高。
目前如何委托角色分配管理
所有者和用户访问管理员角色是内置角色,允许用户创建角色分配。 拥有这些角色的用户可以决定谁可以拥有订阅中任何资源的写入、读取和删除权限。 若要将角色分配管理委托给其他用户,可以将“所有者”或“用户访问管理员”角色分配给某个用户。
下图显示了 Alice 如何将角色分配职责委托给 Dara。 有关具体步骤,请参阅将用户分配为 Azure 订阅的管理员。
- Alice 将“用户访问管理员”角色分配给 Dara。
- Dara 现在可以将任何角色分配给同一范围的任何用户、组或服务主体。
目前的委派方法存在哪些问题?
以下是目前将角色分配管理委托给组织中的其他用户所使用的方法存在的主要问题。
- 委托人在角色分配范围内具有无限制的访问权限。 这违反了最低权限原则,使你面临更广泛的攻击面。
- 委托人可以将任何角色分配给其范围内的任何用户,包括自己。
- 委托人可以将“所有者”或“用户访问管理员”角色分配给其他用户,该用户又可将角色分配给另外的用户。
更安全的方法是限制委托人创建角色分配的权限,而不是分配“所有者”或“用户访问管理员”角色。
更安全的方法: 根据条件委托角色分配管理
根据条件委托角色分配管理是限制用户可以创建的角色分配的一种方法。 在前面的示例中,Alice 可以允许 Dara 代表她创建一些角色分配,但并非所有角色分配。 例如,Alice 可以限制 Dara 能够分配的角色,还可以限制 Dara 能够分配角色的主体。 这种有条件的委派有时称为约束委派,是使用 Azure 基于属性的访问控制 (Azure ABAC) 条件实现的。
以下视频提供了关于根据条件委托角色分配管理的概述。
为什么要根据条件委托角色分配管理?
以下是根据条件将角色分配管理委托给其他用户更安全的一些原因:
- 可以限制允许委托人创建的角色分配。
- 可以阻止委托人允许其他用户分配角色。
- 可以强制遵守组织的最低权限策略。
- 无需向服务帐户授予完全权限即可自动管理 Azure 资源。
条件示例
假设 Alice 是拥有订阅的“用户访问管理员”角色的管理员。 Alice 希望授予 Dara 为特定组分配特定角色的权限。 Alice 不希望 Dara 拥有任何其他角色分配权限。 下图显示了 Alice 如何根据条件将角色分配职责委托给 Dara。
- Alice 将“基于角色的访问控制管理员”角色分配给 Dara。 Alice 附加了条件,使 Dara 只能向“市场营销和销售”组分配“备份参与者”或“备份读取者”角色。
- Dara 现在可以向“市场营销和销售”组分配“备份参与者”或“备份读取者”角色。
- 如果 Dara 尝试分配其他角色或将任何角色分配给其他主体(例如用户或托管标识),角色分配将失败。
基于角色的访问控制管理员角色
基于角色的访问控制管理员角色是一个内置角色,专为将角色分配管理委托给其他用户而设计。 该角色拥有的权限比用户访问管理员少,遵循最低权限最佳做法。 “基于角色的访问控制管理员”角色具有以下权限:
- 创建指定范围的角色分配
- 删除指定范围的角色分配
- 读取除密码外的所有类型的资源
- 创建和更新支持票证
限制角色分配的方法
以下是通过条件限制角色分配的方法。 你还可以将这些条件组合在一起,以适应你的方案。
如何根据条件委托角色分配管理
若要根据条件委托角色分配管理,可以像目前一样分配角色,但还要向角色分配添加条件。
确定委托人所需的权限
- 委托人可以分配哪些角色?
- 委托人可以向哪些类型的主体分配角色?
- 委托人可以向哪些主体分配角色?
- 委托人是否可以删除任何角色分配?
开始新的角色分配
选择基于角色的访问控制管理员角色
可以选择包含 Microsoft.Authorization/roleAssignments/write
操作的任何角色,但“基于角色的访问控制管理员”的权限较少。
选择委托人
选择要将角色分配管理委托给的用户。
添加条件
可以通过多种方法添加条件。 例如,可以使用 Azure 门户中的条件模板、Azure 门户中的高级条件编辑器、Azure PowerShell、Azure CLI、Bicep 或 REST API。
New-AzRoleAssignment
$roleDefinitionId = "f58310d9-a9f6-439a-9e8d-f62e7b41a168"
$principalId = "<principalId>"
$scope = "/subscriptions/<subscriptionId>"
$condition = "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
$conditionVersion = "2.0"
New-AzRoleAssignment -ObjectId $principalId -Scope $scope -RoleDefinitionId $roleDefinitionId -Condition $condition -ConditionVersion $conditionVersion
az role assignment create
set roleDefinitionId="f58310d9-a9f6-439a-9e8d-f62e7b41a168"
set principalId="{principalId}"
set principalType="User"
set scope="/subscriptions/{subscriptionId}"
set condition="((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
set conditionVersion="2.0"
az role assignment create --assignee-object-id %principalId% --assignee-principal-type %principalType% --scope %scope% --role %roleDefinitionId% --condition %condition% --condition-version %conditionVersion%
param roleDefinitionResourceId string
param principalId string
param condition string
targetScope = 'subscription'
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
name: guid(subscription().id, principalId, roleDefinitionResourceId)
properties: {
roleDefinitionId: roleDefinitionResourceId
principalId: principalId
principalType: 'User'
condition: condition
conditionVersion:'2.0'
}
}
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"roleDefinitionResourceId": {
"value": "providers/Microsoft.Authorization/roleDefinitions/f58310d9-a9f6-439a-9e8d-f62e7b41a168"
},
"principalId": {
"value": "{principalId}"
},
"condition": {
"value": "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))"
}
}
}
角色分配 - 创建
PUT https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleAssignments/f58310d9-a9f6-439a-9e8d-f62e7b41a168?api-version=2020-04-01-Preview
{
"properties": {
"roleDefinitionId": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/f58310d9-a9f6-439a-9e8d-f62e7b41a168",
"principalId": "{principalId}",
"condition": "((!(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})) OR (@Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'})) AND ((!(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})) OR (@Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {5e467623-bb1f-42f4-a55d-6e525e11384b, a795c7a0-d4a2-40c1-ae25-d81f01202912} AND @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}))",
"conditionVersion": "2.0"
}
}
根据条件将角色分配给委托人
指定条件后,完成角色分配。
联系委托人
告知委托人他们现在可以根据条件分配角色。
具有条件的内置角色
Key Vault 数据访问管理员和虚拟机数据访问管理员(预览版)角色已具有限制角色分配的内置条件。
Key Vault 数据访问管理员角色可以管理对 Key Vault 机密、证书和密钥的访问。 此角色专门侧重于访问控制,而无需分配特权角色,例如“所有者”或“用户访问管理员”角色。 此角色可以更好地分离各种方案的职责,例如管理跨数据服务的静态加密,以进一步遵守最低权限原则。 条件将角色分配限制为以下 Azure Key Vault 角色:
若要进一步限制“Key Vault 数据访问管理员”角色分配,可以自行添加条件来限制主体类型(用户、组或服务主体)或可以分配 Key Vault 角色的特定主体。
已知问题
以下是与根据条件委托角色分配管理相关的已知问题:
许可要求
此功能免费使用,并且包括在你的 Azure 订阅中。
后续步骤