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

  • 7 分钟

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

与共享密钥授权相比，使用 Microsoft Entra ID 对针对 Azure 存储的请求进行授权提供了更高的安全性和易用性。 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 角色分配给安全主体。 Azure 存储提供了 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 标识客户端库

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

Microsoft Entra ID 通过 Azure 基于角色的访问控制 (Azure RBAC)授权访问受保护的资源。 Azure 存储定义了一组 Azure 内置角色，它们包含用于访问表数据的通用权限集。 还可以定义自定义角色来访问表数据。

将 Azure 角色分配到 Microsoft Entra 安全主体后，Azure 会向该安全主体授予对这些资源的访问权限。 Microsoft Entra 安全主体可以是用户、组、应用程序服务主体，也可以是 Azure 资源的托管标识。

资源范围

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

可在以下级别限定对 Azure 表资源的访问范围，从最小的范围开始：

  • 单个表。 在此范围内，角色分配应用于指定的表。
  • 存储帐户。 在此范围内，角色分配应用于帐户内的所有表。
  • 资源组。 在此范围内，角色分配应用于资源组中所有存储帐户内的所有表。
  • 订阅。 在此范围内，角色分配应用于订阅中所有资源组内的所有存储帐户中的所有表。
  • 管理组。 在此范围内，角色分配将应用于管理组中所有订阅的所有资源组中的所有存储帐户中的所有表。

有关 Azure RBAC 角色分配范围的详细信息，请参阅 了解 Azure RBAC 的范围。

适用于表的 Azure 内置角色

Azure RBAC 提供内置角色，用于使用 Microsoft Entra ID 和 OAuth 授权访问表数据。 提供针对 Azure 存储中表的权限的内置角色包括：

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

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

只有为数据访问显式定义的角色才允许安全主体访问表数据。 内置角色（例如所有者、参与者和存储帐户参与者）允许安全主体管理存储帐户，但不会通过 Microsoft Entra ID 提供对该帐户内表数据的访问权限。 但是，如果角色包括 Microsoft.Storage/storageAccounts/listKeys/action，则分配了该角色的用户可以使用帐户访问密钥通过共享密钥授权来访问存储帐户中的数据。

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

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

数据操作访问权限

若要详细了解有关调用特定表服务操作所需的权限，请参见用于调用数据操作所需的权限。