什么是基于 Azure 属性的访问控制（Azure ABAC）？

基于属性的访问控制 (ABAC) 是一种授权系统，它根据与访问请求的安全主体、资源和环境相关联的属性来定义访问。 使用 ABAC，可以基于属性授予对资源的安全主体访问权限。 Azure ABAC 是 Azure 中 ABAC 的实现。

什么是角色分配条件？

Azure 基于角色的访问控制（Azure RBAC） 是一种授权系统，可帮助你管理谁有权访问 Azure 资源、他们可以对这些资源执行的作以及他们有权访问的区域。 在大多数情况下，Azure RBAC 将使用角色定义和角色分配提供所需的访问管理。 但是，在某些情况下，你可能想要提供更精细的访问管理或简化数百个角色分配的管理。

Azure ABAC 构建在 Azure RBAC 之上，它在特定操作上下文中根据属性添加角色分配条件。 角色分配条件是一项额外的检查，你可以选择添加到角色分配，以提供更精细的访问控制。 条件会筛选出作为角色定义和角色分配的一部分授予的权限。 例如，为了读取对象，你可添加要求对象具有特定标记的条件。 你无法使用条件显式拒绝对特定资源的访问。

结合使用 Azure RBAC 和 Azure ABAC 可集成这两种访问控制模型的优势。 由于 Azure RBAC 与业务逻辑的紧密配合，Azure RBAC 更直接地实现，而 Azure ABAC 在某些关键方案中提供了更大的灵活性。 通过结合这两种方法，组织可以实现更复杂的授权级别。

为何使用条件？

使用角色分配条件有三个主要好处：

• 提供更精细的访问控制 - 角色分配使用包含操作和数据操作的角色定义来授予安全主体权限。 可以编写条件来筛选这些权限，以便进行更精细的访问控制。 您还可以向特定动作添加条件。 例如，只有在 Blob 被标记为 Project=Blue 时，才能向 John 授予对订阅中的 Blob 的读取访问权限。
• 帮助减少角色分配数 - 每个 Azure 订阅当前都有角色分配限制。 在某些情况下，需要数千个角色分配。 所有这些角色分配都必须进行管理。 在这些方案中，可以添加条件以显著减少角色分配。
• 使用具有特定业务含义的属性 - 条件允许在访问控制中使用具有特定业务含义的属性。 属性的一些示例包括项目名称、软件开发阶段和分类级别。 随着用户跨团队和项目移动，这些资源属性的值是动态的，更改。

条件示例

在某些情况下，可能需要向角色分配添加条件。 下面是一些示例。

• 读取访问标记为 Project=Cascade 的 Blob
• 新的 Blob 必须包含标记 Project=Cascade
• 现有的数据块必须标记至少一个项目密钥或程序密钥
• 现有 Blob 必须标记有一个 Project 键以及 Cascade、Baker 或 Skagit 值
• 在名为 blobs-example-container 的容器中读取、写入或删除 Blob
• 读取访问名为 blobs-example-container 且路径为 readonly 的容器中 Blob
• 写入访问名为 Contosocorp 且路径为 uploads/contoso 的容器中的 Blob
• 读取访问标记为 Program=Alpine 且路径为 logs 的 Blob
• 对带有标记 Project=Baker 的 Blob 的读取访问权限，并且用户具有匹配的属性 Project=Baker
• 在特定日期/时间范围内对 Blob 进行读取访问。
• 仅通过专用链接或从特定子网对 Blob 进行写入访问。

有关如何创建这些示例的详细信息，请参阅 Blob 存储的示例 Azure 角色分配条件。

可以在何处添加条件？

目前，可将条件添加到包含 Blob 存储或队列存储数据操作的内置或自定义角色分配。 在与角色分配相同的范围内添加条件。 与角色分配一样，必须具有 Microsoft.Authorization/roleAssignments/write 添加条件的权限。

下面是可在条件中使用的一些 blob 存储属性 。

• 帐户名
• blob 索引标记
• Blob 路径
• Blob 前缀
• 容器名称
• 加密范围名称
• 是当前版本
• 层次结构命名空间是否已启用
• 是专用链接
• 快照
• UTC 现在（协调世界时中的当前日期和时间）
• 版本标识符

条件是什么样的？

可以向新的或现有的角色分配添加条件。 下面是已在资源组范围分配给名为 Chandra 的用户的存储 Blob 数据读取者。 还添加了一个条件，仅允许使用标记 Project=Cascade 对 Blob 进行读取访问。

如果 Chandra 尝试读取没有 Project=Cascade 标记的 Blob，则访问将被阻止。

下面是条件在 Azure 门户中的呈现效果：

下面是代码中条件的样子：

(
    (
        !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
        AND NOT
        SubOperationMatches{'Blob.List'})
    )
    OR
    (
        @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
    )
)

有关条件格式的详细信息，请参阅 Azure 角色分配条件格式和语法。

条件功能的状态

下表列出了条件功能的状态：

条件和 Microsoft Entra PIM

你还可以使用 Microsoft Entra Privileged Identity Management (Microsoft Entra PIM) 为 Azure 资源的符合条件的角色分配添加条件。 使用 Microsoft Entra PIM 时，最终用户必须激活符合条件的角色分配，才能获得执行特定操作的权限。 使用 Microsoft Entra PIM 中的条件不仅可以限制用户使用细粒度条件访问资源，还可以使用 Microsoft Entra PIM 通过时间限制设置、审批工作流、审核线索等来保护资源。 有关详细信息，请查看在 Privileged Identity Management 中分配 Azure 资源角色。

术语

若要更好地了解 Azure RBAC 和 Azure ABAC，可以参考以下术语列表。

限制

下面是条件的一些限制。

已知问题

下面是条件的已知问题：

• 如果你使用 Microsoft Entra Privileged Identity Management (PIM) 和自定义安全属性，则添加条件时，“主体”不会出现在“属性源”中。

后续步骤

• Azure 角色分配条件常见问题解答
• Blob 存储的 Azure 角色分配条件示例
• 教程：使用 Azure 门户添加角色分配条件来限制对 Blob 的访问