使用条件和自定义安全属性调整 Azure 角色分配的管理

Artículo
03/15/2024

Azure 基于角色的访问控制 (Azure RBAC) 具有每个订阅的角色分配数限制。如果需要创建数百甚至数千个 Azure 角色分配，可能会遇到此限制。管理数百甚至数千个角色分配可能很有难度。你可以根据自己的方案，减少角色分配的数量并更轻松地管理访问权限。

本文介绍使用 Azure 基于属性的访问控制 (Azure ABAC) 条件和主体的 Microsoft Entra 自定义安全属性来缩放 Azure 角色分配的管理解决方案。

示例方案

假设有一家名为 Contoso 的公司，它的数千个客户想要设置以下配置：

出于安全和性能原因，将客户数据分布在 128 个存储帐户中。
将 2,000 个容器添加到每个存储帐户，在该存储帐户中，每个客户有一个容器。
由唯一的 Microsoft Entra 服务主体表示每个客户。
允许每个客户访问其自己容器中的对象，但不能访问其他容器中的对象。

此配置可能在订阅中需要 256,000 个存储 Blob 数据所有者角色分配，这远远超出了角色分配数限制。这么多的角色分配很难维护，甚至根本无法维护。

Diagram showing thousands for role assignments.

示例解决方案

若要以可维护的方式处理这种方案，一种方法是使用角色分配条件。下图显示了使用条件将 256,000 个角色分配减少为一个角色分配的解决方案。角色分配处于较高的资源组范围，而条件有助于控制对容器的访问。条件将检查容器名称是否与客户服务主体上的自定义安全属性相匹配。

Diagram showing one role assignment and a condition.

下面是使该解决方案起作用的条件中的表达式：

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

完整条件如下所示。可将操作列表调整为只包含所需的操作。

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

为何要使用此解决方案？

可以使用多种访问控制机制来提供对数据平面资源的访问。

访问密钥是提供对数据平面资源的访问的常用方式。访问密钥向拥有该访问密钥的任何人提供读取、写入和删除权限。这意味着，如果攻击者可以获取你的访问密钥，则他们就能访问你的敏感数据。访问密钥没有标识绑定且没有过期时间，存储它们会带来安全风险。

类似于访问密钥，共享访问签名 (SAS) 令牌也没有标识绑定，但会定期过期。缺少标识绑定意味着它们与访问密钥一样存在安全风险。必须管理过期时间，以确保客户端不会出错。 SAS 令牌需要通过额外的代码进行日常管理和操作，这对于 DevOps 团队而言可能是很大的开销。

Azure RBAC 提供集中的精细访问控制。 Azure RBAC 具有可降低安全风险的标识绑定。使用条件，可以潜在地调整角色分配的管理并使访问控制更易于维护，因为访问是基于灵活且动态的属性进行的。

下面是此解决方案的一些优势：

集中式访问控制
更易于维护
不依赖于访问密钥或 SAS 令牌
不需要管理每个对象的访问权限
可能会改善安全态势

你是否可以使用此解决方案？

如果你的方案与此类似，请按照以下步骤确定你是否可以使用此解决方案。

步骤 1：确定是否满足先决条件

若要使用此解决方案，必须具备：

多个具有 Blob 存储数据操作的内置或自定义角色分配。其中包括以下内置角色：

步骤 2：确定可以在条件中使用的属性

你可以在自己的条件中使用多个属性，例如：

容器名称
Blob 路径
blob 索引标记 [键]
blob 索引标记 [键中的值]

你还可以为用户、企业应用程序和托管标识定义自己的自定义安全属性。

有关详细信息，请参阅 Azure 角色分配条件格式和语法以及什么是 Microsoft Entra ID 中的自定义安全属性？。

步骤 3：创建较高范围的条件

创建一个或多个使用较高范围的条件的角色分配来管理访问权限。有关详细信息，请参阅使用 Azure 门户添加或编辑 Azure 角色分配条件。

Compartir a través de