选择并配置访问 Azure 队列的适当方法
Azure 存储支持使用 Microsoft Entra ID 来授权请求队列数据。 可以通过 Microsoft Entra ID 使用 Azure 基于角色的访问控制 (Azure RBAC) 授予对安全主体的访问权限，该安全主体可能是用户、组或应用程序服务主体。 安全主体由 Microsoft Entra ID 进行身份验证，以返回 OAuth 2.0 令牌。 然后可以使用令牌来授权对队列服务发出请求。
与共享密钥授权相比，使用 Microsoft Entra ID 进行授权提供了更高的安全性和易用性。 Microsoft 建议在可能的情况下对队列应用程序使用 Microsoft Entra 授权，以确保使用所需的最低权限进行访问。
可以针对所有公共区域和国家/地区云的所有常规用途存储帐户使用 Microsoft Entra ID 进行授权。 仅通过 Azure 资源管理器部署模型创建的存储帐户支持 Microsoft Entra 授权。
队列的 Microsoft Entra ID 概述
当安全主体（用户、组或应用程序）尝试访问队列资源时，除非该队列可供匿名访问，否则请求必须获得授权。 如果使用 Microsoft Entra ID，访问资源流程需要两步：
- 首先，验证安全主体的身份并返回 OAuth 2.0 令牌。 身份验证步骤要求应用程序在运行时请求 OAuth 2.0 访问令牌。 如果应用程序在 Azure 实体（如 Azure VM、虚拟机规模集或 Azure Functions 应用）中运行，则可以使用托管标识访问队列数据。
- 接下来，将该令牌作为请求的一部分传递给队列服务，服务将使用它来授权访问指定的资源。 授权步骤要求向发出请求的安全主体分配一个或多个 Azure RBAC 角色。
将 Microsoft Entra 帐户与门户、PowerShell 或 Azure CLI 配合使用
要了解如何使用 Microsoft Entra 帐户在 Azure 门户中访问数据，请参阅从 Azure 门户访问数据。 要了解如何使用 Microsoft Entra 帐户调用 Azure PowerShell 或 Azure CLI 命令，请参阅从 PowerShell 或 Azure CLI 访问数据。
使用 Microsoft Entra ID 在应用程序代码中授予访问权限
若要使用 Microsoft Entra ID 授权访问 Azure 存储，可以使用以下客户端库之一来获取 OAuth 2.0 令牌：
- 对于大多数开发方案，建议使用 Azure 标识客户端库。
- Microsoft 身份验证库 (MSAL) 可能适用于某些高级方案。
Azure 标识客户端库
Azure 标识客户端库借助 Azure SDK 简化了用于 Microsoft Entra ID 授权的 OAuth 2.0 访问令牌的获取过程。 适用于 .NET、Java、Python、JavaScript 和 Go 的最新版本的 Azure 存储客户端库与适用于每种对应语言的 Azure 标识库集成，提供了一种简单而安全的方法来获取用于授权 Azure 存储请求的访问令牌。
Azure 标识客户端库的优点在于，它使你可以使用相同的代码来获取访问令牌，无论你的应用程序是在开发环境中运行还是在 Azure 中运行。 Azure 标识客户端库返回安全主体的访问令牌。 当代码在 Azure 中运行时，安全主体可以是 Azure 资源的托管标识、服务主体或者用户或组。 在开发环境中，客户端库为用户主体或服务主体提供用于测试的访问令牌。
Azure 标识客户端库返回的访问令牌封装在令牌凭据中。 然后，可以使用该令牌凭据来获取服务客户端对象，以用于对 Azure 存储执行授权的操作。 获取访问令牌和令牌凭据的一种简单方法就是使用 Azure 标识客户端库提供的 DefaultAzureCredential 类。 DefaultAzureCredential 尝试通过按顺序试用几种不同的凭据类型来获取令牌凭据。 DefaultAzureCredential 在开发环境和 Azure 中工作正常。
下表指出了在各种方案中授权访问数据的其他信息：
Microsoft 身份验证库 (MSAL)
虽然 Microsoft 建议尽可能使用 Azure 标识客户端库，但 MSAL 库可能适合在某些高级方案中使用。
使用 MSAL 获取用于访问 Azure 存储的 OAuth 令牌时，需要提供 Microsoft Entra 资源 ID。 Microsoft Entra 资源 ID 指示受众可将向其颁发的令牌用于提供对 Azure 资源的访问权限。 在使用 Azure 存储时，资源 ID 可能特定于单个存储帐户，也可能适用于任何存储帐户。
提供特定于单个存储帐户和服务的资源 ID 时，资源 ID 用于获取令牌，以便仅授权对指定帐户和服务的请求。 下表列出了要用于资源 ID 的值，具体取决于正在使用的云。 将 <account-name> 替换为存储帐户的名称。
| 云 | 资源 ID |
|---|---|
| Azure 全球 | https://<account-name>.queue.core.windows.net |
| Azure Government | https://<account-name>.queue.core.usgovcloudapi.net |
| Azure 中国世纪互联 | https://<account-name>.queue.core.chinacloudapi.cn |
还可以提供适用于任何存储帐户的资源 ID，如下表所示。 对于所有公有云和主权云，此资源 ID 相同，用于获取令牌来授权对任何存储帐户的请求。
| 云 | 资源 ID |
|---|---|
| Azure 全球 Azure Government Azure 中国世纪互联 |
https://storage.azure.com/ |
分配 Azure 角色以授予访问权限
Microsoft Entra 通过 Azure RBAC 授权访问受保护的资源。 Azure 存储定义了一组内置 RBAC 角色，它们包含用于访问队列数据的通用权限集。 还可以定义自定义角色来访问队列数据。
Microsoft Entra 安全主体可以是用户、组、应用程序服务主体，也可以是 Azure 资源的托管标识。 分配给安全主体的 RBAC 角色决定该主体拥有的权限。
在某些情况下，可能需要启用对队列资源的精细访问权限，或在对存储资源进行大量角色分配时简化权限。 可以使用 Azure 基于属性的访问控制 (Azure ABAC) 来配置角色分配的条件。 可以将条件用于自定义角色，或选择内置角色。 有关使用 ABAC 为 Azure 存储资源配置条件的详细信息，请参阅使用 Azure 角色分配条件授权访问队列。
创建 Azure 存储帐户时，系统不会自动向你分配通过 Microsoft Entra ID 访问数据的权限。 你必须为自己显式分配用于访问队列存储的 Azure 角色。 可以在订阅、资源组、存储帐户或队列级别分配它。
资源范围
向安全主体分配 Azure RBAC 角色之前，请确定安全主体应具有的访问权限的范围。 最佳做法规定，始终最好只授予最小的可能范围。 在较广范围内中定义的 Azure RBAC 角色由其下的资源继承。
可在以下级别范围内限定对 Azure 队列资源的访问权限，从最小范围开始：
- 单个队列。 在此范围内，角色分配将应用于队列中的消息，以及队列属性和元数据。
- 存储帐户。 在此范围内，角色分配将应用于所有队列及其消息。
- 资源组。 在此范围内，角色分配适用于资源组内的所有存储帐户中的所有队列。
- 订阅。 在此范围内，角色分配适用于订阅中所有资源组内的所有存储帐户中的所有队列。
- 管理组。 在此范围内，角色分配将应用于管理组中所有订阅的所有资源组中的所有存储帐户中的所有队列。
用于队列的 Azure 内置角色
Azure RBAC 提供了多个内置角色，用于使用 Microsoft Entra ID 和 OAuth 授权访问队列数据。 某些角色可在 Azure 存储中提供数据资源权限，例如：
- 存储队列数据参与者：用来授予对 Azure 队列的读取/写入/删除权限。
- 存储队列数据读取者：用来授予对 Azure 队列的只读权限。
- 存储队列数据消息处理者：用来对 Azure 存储队列中的消息授予扫视、检索和删除权限。
- 存储队列数据消息发送者：用来对 Azure 存储队列中的消息授予添加权限。
只有为数据访问显式定义的角色才允许安全主体访问队列数据。 内置角色（例如所有者、参与者和存储帐户参与者）允许安全主体管理存储帐户，但不会通过 Microsoft Entra ID 提供对该帐户内队列数据的访问权限。 但是，如果角色包括 Microsoft.Storage/storageAccounts/listKeys/action，则分配了该角色的用户可以使用帐户访问密钥通过共享密钥授权来访问存储帐户中的数据。
Azure 角色分配最多需要 30 分钟时间来进行传播。
使用 Microsoft Entra 帐户访问数据
可以使用用户的 Microsoft Entra 帐户或使用帐户访问密钥（共享密钥授权）来授权通过 Azure 门户、PowerShell 或 Azure CLI 访问队列数据。
不建议使用共享密钥进行授权，因为它可能不太安全。 为获得最佳安全性，请禁用存储帐户的共享密钥授权，如阻止对 Azure 存储帐户进行共享密钥授权中所述。
对访问密钥和连接字符串的使用应限于不访问生产数据或敏感数据的初始概念证明应用或开发原型。 否则，在向 Azure 资源进行身份验证时，应始终优先使用 Azure SDK 中提供的基于令牌的身份验证类。
Microsoft 建议客户端使用 Microsoft Entra ID 或共享访问签名 (SAS) 来授权访问 Azure 存储中的数据。
通过 Azure 门户访问数据
Azure 门户可以使用 Microsoft Entra 帐户或帐户访问密钥来访问 Azure 存储帐户中的队列数据。 Azure 门户使用哪种授权方案取决于分配给你的 Azure 角色。
在尝试访问队列数据时，Azure 门户首先会检查你是否分配有包含 Microsoft.Storage/storageAccounts/listkeys/action 的 Azure 角色。 如果已分配有包含此操作的角色，则 Azure 门户将使用帐户密钥通过共享密钥授权来访问队列数据。 如果未分配有包含此操作的角色，则 Azure 门户会尝试使用你的 Microsoft Entra 帐户访问数据。
若要使用 Microsoft Entra 帐户通过 Azure 门户访问队列数据，需要拥有访问队列数据的权限，另外还需要拥有在 Azure 门户中浏览存储帐户资源的权限。 Azure 存储提供的内置角色授予对队列资源的访问权限，但不授予对存储帐户资源的权限。 出于此原因，访问门户还需要分配范围为存储帐户或更高级别的 Azure 资源管理器角色，例如读取者角色。 “读取者”角色授予限制性最高的权限，但也接受可授予存储帐户管理资源访问权限的其他 Azure 资源管理器角色。
通过 PowerShell 或 Azure CLI 访问数据
Azure CLI 和 PowerShell 支持使用 Microsoft Entra 凭据登录。 登录后，会话将在这些凭据下运行。 有关详细信息，请参阅以下文章之一：