选择并配置访问 Azure Blob 的适当方法

已完成

Azure 存储支持使用 Microsoft Entra ID 来授权请求 Blob 数据。 可以通过 Microsoft Entra ID 使用 Azure 基于角色的访问控制 (Azure RBAC) 授予对安全主体的访问权限,该安全主体可能是用户、组或应用程序服务主体。 安全主体由 Microsoft Entra ID 进行身份验证,以返回 OAuth 2.0 令牌。 然后可以使用令牌来授权对 Blob 服务发出请求。

使用 Microsoft Entra ID 进行授权适用于所有公共区域和国家/地区云中的所有常规用途和 Blob 存储帐户。 仅通过 Azure 资源管理器部署模型创建的存储帐户支持 Microsoft Entra 授权。

为了获得最佳安全性,Microsoft 建议尽可能使用 Microsoft Entra ID 和托管标识来授权针对 blob、队列和表数据的请求。 与共享密钥授权相比,使用 Microsoft Entra ID 和托管标识进行授权提供了更高的安全性和易用性。 要详细了解托管标识,请参阅什么是 Azure 资源托管标识。 有关如何为 .NET 应用程序启用和使用托管标识的示例,请参阅使用 .NET 对 Azure 资源的 Azure 托管应用进行身份验证

对于 Azure 外部托管的资源(例如本地应用程序),可以通过 Azure Arc 使用托管标识。例如,在已启用 Azure Arc 的服务器上运行的应用可以使用托管标识连接到 Azure 服务。 若要了解详细信息,请参阅使用已启用 Azure Arc 的服务器对 Azure 资源进行身份验证

对于使用共享访问签名 (SAS) 的场景,Microsoft 建议使用用户委派 SAS。 用户委派 SAS 通过 Microsoft Entra 凭据(而不是帐户密钥)进行保护。 若要了解共享访问签名,请参阅使用共享访问签名授予有限的数据访问权限。 有关如何通过 .NET 创建和使用用户委托 SAS 的示例,请参阅使用 .NET 为 blob 创建用户委托 SAS

Blob 的 Microsoft Entra ID 概述

当某个安全主体(用户、组或应用程序)尝试访问 Blob 资源时,除非该 Blob 可供匿名访问,否则请求必须获得授权。 如果使用 Microsoft Entra ID,访问资源流程需要两步:

  1. 首先,验证安全主体的身份并返回 OAuth 2.0 令牌。
  • 身份验证步骤要求应用程序在运行时请求 OAuth 2.0 访问令牌。 如果应用程序在 Azure 实体(如 Azure VM、虚拟机规模集或 Azure Functions 应用)中运行,则可以使用托管标识访问 Blob 数据。
  1. 接下来,将该令牌作为请求的一部分传递给 Blob 服务,服务将使用它来授权访问指定的资源。
  • 接下来,将该令牌作为请求的一部分传递给 Blob 服务,服务将使用它来授权访问指定的资源。

将 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 标识客户端库

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 中工作正常。

下表指出了在各种方案中授权访问数据的其他信息:

语言 .NET Java JavaScript Python Go
Microsoft Entra ID 授权概述 如何在 Azure 服务中对 .NET 应用程序进行身份验证 使用 Java 和 Azure 标识进行 Azure 身份验证 使用 Azure SDK 向 Azure 验证 JavaScript 应用的身份 使用 Azure SDK 向 Azure 验证 Python 应用的身份 空值
使用开发人员服务主体进行身份验证 使用服务主体在本地开发期间向 Azure 服务验证 .NET 应用的身份 使用服务主体进行 Azure 身份验证 使用服务主体向 Azure 服务验证 JS 应用的身份 在本地开发期间使用服务主体向 Azure 服务验证 Python 应用的身份 使用服务主体进行 Azure SDK for Go 身份验证
使用开发人员或用户帐户进行身份验证 在本地开发期间使用开发人员帐户对访问 Azure 服务的 .NET 应用进行身份验证 使用用户凭据进行 Azure 身份验证 使用开发帐户向 Azure 服务验证 JS 应用的身份 使用开发人员帐户在本地开发期间向 Azure 服务验证 Python 应用的身份 使用 Azure SDK for Go 进行 Azure 身份验证
从 Azure 托管的应用进行身份验证 使用 Azure SDK for .NET 对访问 Azure 资源的 Azure 托管应用进行身份验证 对 Azure 托管的 Java 应用程序进行身份验证 使用 Azure SDK for JavaScript 向 Azure 资源验证 Azure 托管 JavaScript 应用的身份 使用 Azure SDK for Python 向 Azure 资源验证 Azure 托管应用的身份 使用托管标识通过 Azure SDK for Go 进行身份验证
从本地应用进行身份验证 从本地托管的 .NET 应用向 Azure 资源进行身份验证 空值 向 Azure 资源验证本地 JavaScript 应用的身份 从本地托管的 Python 应用向 Azure 资源进行身份验证 空值
标识客户端库概述 适用于 .NET 的 Azure 标识客户端库 适用于 Java 的 Azure 标识客户端库 适用于 JavaScript 的 Azure 标识客户端库 适用于 Python 的 Azure 标识客户端库 适用于 Go 的 Azure 标识客户端库

Microsoft 身份验证库 (MSAL)

虽然 Microsoft 建议尽可能使用 Azure 标识客户端库,但 MSAL 库可能适合在某些高级方案中使用。 有关详细信息,请参阅了解 MSAL

使用 MSAL 获取用于访问 Azure 存储的 OAuth 令牌时,需要提供 Microsoft Entra 资源 ID。 Microsoft Entra 资源 ID 指示受众可将向其颁发的令牌用于提供对 Azure 资源的访问权限。 在使用 Azure 存储时,资源 ID 可能特定于单个存储帐户,也可能适用于任何存储帐户。

提供特定于单个存储帐户和服务的资源 ID 时,资源 ID 用于获取令牌,以便仅授权对指定帐户和服务的请求。 下表列出了要用于资源 ID 的值的示例,这些值取决于你所使用的云。 将 <account-name> 替换为存储帐户的名称。

资源 ID
Azure 全球 example: account-name.blob.core.windows.net
Azure Government example: account-name.blob.core.usgovcloudapi.net
Azure 中国世纪互联 example: account-name.blob.core.chinacloudapi.cn

还可以提供适用于任何存储帐户的资源 ID,如下表所示。 对于所有公有云和主权云,此资源 ID 相同,用于获取令牌来授权对任何存储帐户的请求。

资源 ID
Azure 全球
Azure Government
Azure 中国世纪互联
example: storage.azure.com

分配 Azure 角色以授予访问权限

Microsoft Entra 通过 Azure RBAC 授权访问受保护的资源。 Azure 存储定义了一组内置的 RBAC 角色,它们包含用于访问 Blob 数据的通用权限集。 还可以定义自定义角色来访问 Blob 数据。 若要详细了解如何分配 Azure 角色用于访问 Blob,请参阅分配用于访问 Blob 数据的 Azure 角色

Microsoft Entra 安全主体可以是用户、组、应用程序服务主体,也可以是 Azure 资源的托管标识。 分配给安全主体的 RBAC 角色决定了该主体对特定资源拥有的权限。 若要详细了解如何分配 Azure 角色用于访问 Blob,请参阅分配用于访问 Blob 数据的 Azure 角色

在某些情况下,可能需要启用对 Blob 资源的精细访问权限,或者在存储资源存在大量角色分配时简化权限。 可以使用 Azure 基于属性的访问控制 (Azure ABAC) 来配置角色分配的条件。 可以将条件用于自定义角色,或选择内置角色。 有关使用 ABAC 为 Azure 存储资源配置条件的详细信息,请参阅使用 Azure 角色分配条件来授权访问 Blob(预览版)。 有关 Blob 数据操作支持的条件的详细信息,请参阅 Azure 存储中 Azure 角色分配条件的操作和属性(预览版)

创建 Azure 存储帐户时,系统不会自动向你分配通过 Microsoft Entra ID 访问数据的权限。 你必须为自己显式分配一个 Azure 角色以访问 Blob 存储。 可以在订阅、资源组、存储帐户、容器级别分配该角色。

资源范围

向安全主体分配 Azure RBAC 角色之前,请确定安全主体应具有的访问权限的范围。 最佳做法规定,始终最好只授予最小的可能范围。 在较广范围内中定义的 Azure RBAC 角色由其下的资源继承。

可在以下级别范围内限定对 Azure Blob 资源的访问权限,从最小范围开始:

  • 单个容器。 在此范围内,角色分配将应用于容器中的所有 blob,以及容器属性和元数据。
  • 存储帐户。 在此范围内,角色分配将应用于所有容器及其 blob。
  • 资源组。 在此范围内,角色分配适用于资源组内的所有存储帐户中的所有容器。
  • 订阅。 在此范围内,角色分配适用于订阅中所有资源组内的所有存储帐户中的所有容器。
  • 管理组。 在此范围内,角色分配将应用于管理组中所有订阅的所有资源组中的所有存储帐户中的所有容器。

用于 Blob 的 Azure 内置角色

Azure RBAC 提供了多个内置角色,用于使用 Microsoft Entra ID 和 OAuth 授权访问 Blob 数据。 某些角色可在 Azure 存储中提供数据资源权限,例如:

若要了解如何将 Azure 内置角色分配给安全主体,请参阅分配用于访问 Blob 数据的 Azure 角色。 若要了解如何列出 Azure RBAC 角色及其权限,请参阅列出 Azure 角色定义

有关如何为 Azure 存储定义内置角色的详细信息,请参阅了解角色定义。 若要了解如何创建 Azure 自定义角色,请参阅 Azure 自定义角色

只有为数据访问显式定义的角色才允许安全主体访问 Blob 数据。 内置角色(例如所有者参与者存储帐户参与者)允许安全主体管理存储帐户,但不会通过 Microsoft Entra ID 提供对该帐户内 Blob 数据的访问权限。 但是,如果角色包括 Microsoft.Storage/storageAccounts/listKeys/action,则分配了该角色的用户可以使用帐户访问密钥通过共享密钥授权来访问存储帐户中的数据。 有关详细信息,请参阅选择如何在 Azure 门户中授予对 blob 数据的访问权限

要详细了解数据服务和管理服务的 Azure 存储的 Azure 内置角色,请参阅 Azure RBAC 的 Azure 内置角色的“存储”部分。 此外,若要了解 Azure 中提供权限的不同类型的角色,请参阅 Azure 角色和 Microsoft Entra 角色、经典订阅管理员角色

Azure 角色分配最多需要 30 分钟时间来进行传播。

数据操作访问权限

若要详细了解有关调用特定 Blob 服务操作所需的权限,请参阅用于调用数据操作的权限

使用 Microsoft Entra 帐户访问数据

如需通过 Azure 门户、PowerShell 或 Azure CLI 访问 Blob 数据,可以使用用户的 Microsoft Entra 帐户或使用帐户访问密钥(共享密钥授权)来进行授权

不建议使用共享密钥进行授权,因为它可能不太安全。 为获得最佳安全性,请禁用存储帐户的共享密钥授权,如阻止对 Azure 存储帐户进行共享密钥授权中所述。

对访问密钥和连接字符串的使用应限于不访问生产数据或敏感数据的初始概念证明应用或开发原型。 否则,在向 Azure 资源进行身份验证时,应始终优先使用 Azure SDK 中提供的基于令牌的身份验证类。

Microsoft 建议客户端使用 Microsoft Entra ID 或共享访问签名 (SAS) 来授权访问 Azure 存储中的数据。 要了解详细信息,请参阅授权数据访问操作

通过 Azure 门户访问数据

Azure 门户可以使用 Microsoft Entra 帐户或帐户访问密钥来访问 Azure 存储帐户中的 Blob 数据。 Azure 门户使用哪种授权方案取决于分配给你的 Azure 角色。

当你尝试访问 Blob 数据时,Azure 门户首先会检查你是否分配有一个包含 Microsoft.Storage/storageAccounts/listkeys/action 的 Azure 角色。 如果已分配有包含此操作的角色,则 Azure 门户将使用帐户密钥通过共享密钥授权来访问 Blob 数据。 如果未分配有包含此操作的角色,则 Azure 门户会尝试使用你的 Microsoft Entra 帐户访问数据。

要使用 Microsoft Entra 帐户通过 Azure 门户访问 Blob 数据,需要拥有访问 Blob 数据的权限,另外还需要拥有在 Azure 门户中浏览存储帐户资源的权限。 Azure 存储提供的内置角色授予对 Blob 资源的访问权限,但不授予对存储帐户资源的权限。 出于此原因,访问门户还需要分配范围为存储帐户或更高级别的 Azure 资源管理器角色,例如读取者角色。 “读取者”角色授予限制性最高的权限,但也接受可授予存储帐户管理资源访问权限的其他 Azure 资源管理器角色。 要详细了解如何分配权限,使用户能够使用 Microsoft Entra 帐户在 Azure 门户中访问数据,请参阅分配用于访问 Blob 数据的 Azure 角色

当你导航到容器时,Azure 门户会指示当前正在使用哪种授权方案。 有关在门户中访问数据的详细信息,请参阅选择如何在 Azure 门户中授权访问 Blob 数据

通过 PowerShell 或 Azure CLI 访问数据

Azure CLI 和 PowerShell 支持使用 Microsoft Entra 凭据登录。 登录后,会话将在这些凭据下运行。

功能支持

启用 Data Lake Storage Gen2、网络文件系统 (NFS) 3.0 协议或 SSH 文件传输协议 (SFTP) 可能会影响对此功能的支持。