利用条件和自定义安全属性优化 Azure 角色分配的管理

Azure 基于角色的访问控制（Azure RBAC）对每个订阅的角色分配有限制。如果需要创建数百甚至数千个 Azure 角色分配，可能会遇到此限制。管理数百或数千个角色分配可能很困难。根据你的方案，你也许能够减少角色分配的数量，并更轻松地管理访问权限。

本文介绍了一种使用 Azure 基于属性的访问控制（Azure ABAC）条件和 Microsoft Entra 自定义安全属性为主体扩展角色分配管理的解决方案。

示例方案

请考虑一家名为 Contoso 的公司，其中包含数千个想要设置以下配置的客户：

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

此配置可能需要在一个订阅中分配 256,000 个存储 Blob 数据所有者角色，这远远超出了角色分配的限制。如果不是不可能的，那么如此多的角色分配将很难维护。

展示包含数千个角色分配的关系图。

示例解决方案

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

图示显示一个角色分配和一个条件。

下面是使此解决方案正常工作的条件中的表达式：

  @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 角色分配条件。

后续步骤

Last updated on 2026-02-26

Compartir a través de