基于属性的访问控制 (ABAC) 是一种授权策略，它根据与访问请求相关的属性（例如安全主体、资源、环境和请求本身）定义访问级别。 使用 ABAC，可以根据 Azure 角色分配条件授予安全主体对资源的访问权限。
重要
Azure 基于属性的访问控制 (Azure ABAC) 已正式发布 (GA)，用于使用标准和高级存储帐户性能层中的 request、resource、environment 和 principal 属性控制对 Azure Blob 存储、Azure Data Lake Storage Gen2 和 Azure 队列的访问。 目前，“容器元数据”资源属性和“列出 Blob 操作的所含内容”请求属性处于预览状态。 有关 Azure 存储 ABAC 的完整功能状态信息，请参阅 Azure 存储中条件功能的状态。
有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款，请参阅 Azure 预览版的补充使用条款。
可以使用 Microsoft Entra ID (Microsoft Entra ID) 通过 Azure RBAC 来授权对 Azure 存储资源的请求。 Azure RBAC 可帮助你通过使用角色定义和角色分配定义谁有权访问资源以及他们可对这些资源执行哪些操作，来管理对资源的访问。 Azure 存储定义了一组 Azure 内置角色，它们包含用于访问 Azure 存储数据的通用权限集。 还可以定义具有选定权限集的自定义角色。 Azure 存储支持存储帐户和 Blob 容器或队列的角色分配。
Azure ABAC 构建在 Azure RBAC 基础之上，它在特定操作上下文中添加了角色分配条件。 角色分配条件是在为针对存储资源的操作授权时评估的附加检查。 此条件表达为谓词，该谓词使用与下列其中任何一项关联的属性：
- 请求授权的安全主体
- 请求访问的资源
- 请求参数
- 请求的来源环境
使用角色分配条件的好处如下：
- 启用对资源的更精细访问 - 例如，如果你想要向某个用户授予在特定队列中速览消息的访问权限，可以使用速览消息 DataAction 和队列名称存储属性。
- 减少必须创建和管理的角色分配数量 - 为此，可对某个安全组使用通用角色分配，然后使用一个条件来限制该组中各个成员的访问权限，该条件会对主体的属性与所要访问的特定资源（例如队列）的属性进行匹配。
- 使用具有业务含义的属性来表达访问控制规则 - 例如，可以使用代表项目名称、业务应用程序、组织职能或分类级别的属性来表达条件。
使用条件的弊端是在整个组织中使用属性时需要结构化且一致的分类。 必须保护属性以防止访问权限被恶意利用。 此外，必须认真设计并评审条件的影响。
可以针对 DataActions 配置角色分配条件以实现这些目标。 可以将条件用于自定义角色，或选择内置角色。 请注意，不支持通过存储资源提供程序为管理操作使用条件。
可以向内置角色或自定义角色添加条件。 可对其使用角色分配条件的内置角色包括：
可对自定义角色使用条件，但前提是该角色包含支持条件的操作。
Azure 角色分配条件格式允许在条件中使用 @Principal、@Resource 或 @Request 属性。 @Principal 属性是主体（例如用户、企业应用程序（服务主体）或托管标识）上的自定义安全属性。 @Resource 属性是指正在访问的存储资源（例如存储帐户或队列）的现有属性。 @Request 属性是指存储操作请求中包含的属性或参数。
Azure RBAC 目前支持在一个订阅中创建 2,000 个角色分配。 如果需要创建数千个 Azure 角色分配，可能会遇到此限制。 管理数百甚至数千个角色分配可能很有难度。 在某些情况下，可以使用条件来减少存储帐户上的角色分配数量，使其更易于管理。 可以使用主体的条件和 Microsoft Entra ID 自定义安全属性来调整角色分配的管理。