Azure Data Lake Storage Gen2 中的访问控制模型Access control model in Azure Data Lake Storage Gen2

Data Lake Storage Gen2 支持以下授权机制:Data Lake Storage Gen2 supports the following authorization mechanisms:

  • 共享密钥授权Shared Key authorization
  • 共享访问签名 (SAS) 授权Shared access signature (SAS) authorization
  • 基于角色的访问控制 (Azure RBAC)Role-based access control (Azure RBAC)
  • 访问控制列表 (ACL)Access control lists (ACL)

共享密钥和 SAS 授权向用户(或应用程序)授予访问权限,不要求其在 Azure Active Directory (Azure AD) 中有标识。Shared Key and SAS authorization grants access to a user (or application) without requiring them to have an identity in Azure Active Directory (Azure AD). 使用这两种形式的身份验证时,Azure RBAC 和 ACL 不起作用。With these two forms of authentication, Azure RBAC and ACLs have no effect.

Azure RBAC 和 ACL 都要求用户(或应用程序)在 Azure AD 中有标识。Azure RBAC and ACL both require the user (or application) to have an identity in Azure AD. 使用 Azure RBAC,你可以授予对存储帐户数据的“粗粒度”访问权限(例如,对存储帐户中 所有 数据的读取或写入访问权限),而使用 ACL,你可以授予“细粒度”访问权限,例如,对特定目录或文件的写入访问权限。Azure RBAC lets you grant "coarse-grain" access to storage account data, such as read or write access to all of the data in a storage account, while ACLs let you grant "fine-grained" access, such as write access to a specific directory or file.

本文重点介绍 Azure RBAC 和 ACL,以及系统如何将它们一起评估,以便针对存储帐户资源做出授权决策。This article focuses on Azure RBAC and ACLs, and how the system evaluates them together to make authorization decisions for storage account resources.

基于角色的访问控制 (Azure RBAC)Role-based access control (Azure RBAC)

Azure RBAC 使用角色分配向安全主体应用权限集。Azure RBAC uses role assignments to apply sets of permissions to security principals. 安全主体是一个对象,表示在 Azure Active Directory (AD) 中定义的用户、组、服务主体或托管标识。A security principal is an object that represents a user, group, service principal, or managed identity that is defined in Azure Active Directory (AD). 权限集可以向安全主体授予“粗粒度”级别的访问权限,例如,对存储帐户中 所有 数据或容器中 所有 数据的读取或写入访问权限。A permission set can give a security principal a "coarse-grain" level of access such as read or write access to all of the data in a storage account or all of the data in a container.

以下角色允许安全主体访问存储帐户中的数据。The following roles permit a security principal to access data in a storage account.

角色Role 描述Description
存储 Blob 数据所有者Storage Blob Data Owner 对 Blob 存储容器和数据的完全访问权限。Full access to Blob storage containers and data. 此访问权限允许安全主体设置项的所有者,以及修改所有项的 ACL。This access permits the security principal to set the owner an item, and to modify the ACLs of all items.
存储 Blob 数据参与者Storage Blob Data Contributor 对 Blob 存储容器和 Blob 的读取、写入和删除访问权限。Read, write, and delete access to Blob storage containers and blobs. 此访问权限不允许安全主体设置项的所有权,但它可以修改安全主体拥有的项的 ACL。This access does not permit the security principal to set the ownership of an item, but it can modify the ACL of items that are owned by the security principal.
存储 Blob 数据读者Storage Blob Data Reader 读取和列出存储容器与 Blob。Read and list Blob storage containers and blobs.

所有者参与者读取者存储帐户参与者等角色允许安全主体管理存储帐户,但不提供对该帐户中数据的访问权限。Roles such as Owner, Contributor, Reader, and Storage Account Contributor permit a security principal to manage a storage account, but do not provide access to the data within that account. 但是,这些角色(读取者 除外)可以获取对存储密钥的访问权限,存储密钥可在各种客户端工具中用来访问数据。However, these roles (excluding Reader) can obtain access to the storage keys, which can be used in various client tools to access the data.

访问控制列表 (ACL)Access control lists (ACLs)

使用 ACL,你可以对目录和文件应用“更细粒度”的访问级别。ACLs give you the ability to apply "finer grain" level of access to directories and files. ACL 是一个包含一系列 ACL 条目的权限构造。An ACL is a permission construct that contains a series of ACL entries. 每个 ACL 条目都将安全主体与一个访问级别相关联。Each ACL entry associates security principal with an access level. 有关详细信息,请参阅 Azure Data Lake Storage Gen2 中的访问控制列表 (ACL)To learn more, see Access control lists (ACLs) in Azure Data Lake Storage Gen2.

权限是如何评估的How permissions are evaluated

在基于安全主体的授权过程中,将按以下顺序对权限进行评估。During security principal-based authorization, permissions are evaluated in the following order.

1️⃣  Azure 角色分配将首先进行评估,优先于任何 ACL 分配。   Azure role assignments are evaluated first and take priority over any ACL assignments.

2️⃣  如果根据 Azure 角色分配向操作完全授权,则根本不会评估 ACL。   If the operation is fully authorized based on Azure role assignment, then ACLs are not evaluated at all.

3️⃣  如果操作未完全获得授权,则会评估 ACL。   If the operation is not fully authorized, then ACLs are evaluated.

Data Lake Storage 权限流data lake storage permission flow

由于系统评估访问权限的方式,你 无法 使用 ACL 来 限制 已通过角色分配授予的访问权限。Because of the way that access permissions are evaluated by the system, you cannot use an ACL to restrict access that has already been granted by a role assignment. 这是因为系统会首先评估 Azure 角色分配,如果该分配授予了足够的访问权限,则会忽略 ACL。That's because the system evaluates Azure role assignments first, and if the assignment grants sufficient access permission, ACLs are ignored.

下图显示了这三个常见操作的权限流:列出目录内容、读取文件和写入文件。The following diagram shows the permission flow for three common operations: listing directory contents, reading a file, and writing a file.

Data Lake Storage 权限流示例data lake storage permission flow example

权限表:组合使用 Azure RBAC 和 ACLPermissions table: Combining Azure RBAC and ACL

下表显示了如何组合使用 Azure 角色和 ACL 条目,以便安全主体可以执行“操作”列中列出的操作。The following table shows you how to combine Azure roles and ACL entries so that a security principal can perform the operations listed in the Operation column. 此表显示的列代表虚构目录层次结构的每个级别。This table shows a column that represents each level of a fictitious directory hierarchy. 容器的根目录 (/)、名为 Oregon 的子目录、Oregon 目录的名为 Portland 的子目录以及 Portland 目录中名为 Data.txt 的文本文件分别对应一个列。There's a column for the root directory of the container (/), a subdirectory named Oregon, a subdirectory of the Oregon directory named Portland, and a text file in the Portland directory named Data.txt. 这些列中显示了授予权限所需的 ACL 条目的简短形式的表示形式。Appearing in those columns are short form representations of the ACL entry required to grant permissions. 如果某个 ACL 条目不是执行操作所必需的,则列中将显示 N/A(不适用)。N/A (Not applicable) appears in the column if an ACL entry is not required to perform the operation.

操作Operation 分配的 Azure 角色Assigned Azure role / Oregon/Oregon/ Portland/Portland/ Data.txtData.txt
Read Data.txtRead Data.txt 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader 不可用N/A 不可用N/A 不可用N/A 不可用N/A
NoneNone --X --X --X R--
Append to Data.txtAppend to Data.txt 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader --X --X --X -W-
NoneNone --X --X --X RW-
Delete Data.txtDelete Data.txt 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader --X --X -WX 不可用N/A
NoneNone --X --X -WX 不适用N/A
Create Data.txtCreate Data.txt 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader --X --X -WX 不可用N/A
NoneNone --X --X -WX 不适用N/A
List /List / 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader 不可用N/A 不可用N/A 不可用N/A 不可用N/A
NoneNone R-X 不适用N/A 不可用N/A 不适用N/A
List /Oregon/List /Oregon/ 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader 不可用N/A 不可用N/A 不可用N/A 不可用N/A
NoneNone --X R-X 不适用N/A 不适用N/A
List /Oregon/Portland/List /Oregon/Portland/ 存储 Blob 数据所有者Storage Blob Data Owner 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据参与者Storage Blob Data Contributor 不适用N/A 不可用N/A 不可用N/A 不适用N/A
存储 Blob 数据读取者Storage Blob Data Reader 不可用N/A 不可用N/A 不可用N/A 不可用N/A
NoneNone --X --X R-X 不适用N/A

备注

若要在 Azure 存储资源管理器中查看某个容器的内容,安全主体必须使用 Azure AD 登录到存储资源管理器,并且必须(至少)拥有对容器的根文件夹 (\) 的读取访问权限 (R--)。To view the contents of a container in Azure Storage Explorer, security principals must sign into Storage Explorer by using Azure AD, and (at a minimum) have read access (R--) to the root folder (\) of a container. 此权限级别允许安全主体列出根文件夹的内容。This level of permission does give them the ability to list the contents of the root folder. 如果不希望根文件夹的内容可见,可以向安全主体分配读取者角色。If you don't want the contents of the root folder to be visible, you can assign them Reader role. 使用该角色,安全主体将能够列出帐户中的容器,但不能列出容器内容。With that role, they'll be able to list the containers in the account, but not container contents. 然后,你可以使用 ACL 授予对特定目录和文件的访问权限。You can then grant access to specific directories and files by using ACLs.

安全组Security groups

始终将 Azure AD 安全组用作 ACL 条目中分配的主体。Always use Azure AD security groups as the assigned principal in an ACL entry. 拒绝直接分配各个用户或服务主体。Resist the opportunity to directly assign individual users or service principals. 使用此结构,你可以添加和删除用户或服务主体,不需要向整个目录结构重新应用 ACL。Using this structure will allow you to add and remove users or service principals without the need to reapply ACLs to an entire directory structure. 可以仅在适当的 Azure AD 安全组中添加或删除用户和服务主体。Instead, you can just add or remove users and service principals from the appropriate Azure AD security group.

有多种不同的方法可用来设置组。There are many different ways to set up groups. 例如,假设你有一个名为 /LogData 的目录,该目录包含服务器生成的日志数据。For example, imagine that you have a directory named /LogData which holds log data that is generated by your server. Azure 数据工厂 (ADF) 将数据引入到该文件夹中。Azure Data Factory (ADF) ingests data into that folder. 服务工程团队中的特定用户将上传日志并管理此文件夹的其他用户,而各个 Databricks 群集将分析来自该文件夹的日志。Specific users from the service engineering team will upload logs and manage other users of this folder, and various Databricks clusters will analyze logs from that folder.

若要启用这些活动,可以创建一个 LogsWriter 组和一个 LogsReader 组。To enable these activities, you could create a LogsWriter group and a LogsReader group. 然后,可以按如下所示分配权限:Then, you could assign permissions as follows:

  • LogsWriter 组添加到 /LogData 目录的具有 rwx 权限的 ACL。Add the LogsWriter group to the ACL of the /LogData directory with rwx permissions.
  • LogsReader 组添加到 /LogData 目录的具有 r-x 权限的 ACL。Add the LogsReader group to the ACL of the /LogData directory with r-x permissions.
  • LogsWriters 组添加用于 ADF 的服务主体对象或托管服务标识 (MSI)。Add the service principal object or Managed Service Identity (MSI) for ADF to the LogsWriters group.
  • 将服务工程团队中的用户添加到 LogsWriter 组。Add users in the service engineering team to the LogsWriter group.
  • 将 Databricks 的服务主体对象或 MSI 添加到 LogsReader 组。Add the service principal object or MSI for Databricks to the LogsReader group.

如果服务工程团队中的用户离开了公司,则只需将其从 LogsWriter 组中删除即可。If a user in the service engineering team leaves the company, you could just remove them from the LogsWriter group. 如果未将该用户添加到组中,而是为该用户添加了专用 ACL 条目,则必须从 /LogData 目录中删除此 ACL 条目。If you did not add that user to a group, but instead, you added a dedicated ACL entry for that user, you would have to remove that ACL entry from the /LogData directory. 还必须从 /LogData 目录的整个目录层次结构中的所有子目录和文件中删除此条目。You would also have to remove the entry from all subdirectories and files in the entire directory hierarchy of the /LogData directory.

若要创建组并添加成员,请参阅使用 Azure Active Directory 创建基本组并添加成员To create a group and add members, see Create a basic group and add members using Azure Active Directory.

对 Azure 角色分配和 ACL 条目的限制Limits on Azure role assignments and ACL entries

通过使用组,你不太可能超出每个订阅的角色分配的最大数量,以及每个文件或目录的 ACL 条目的最大数量。By using groups, you're less likely to exceed the maximum number of role assignments per subscription and the maximum number of ACL entries per file or directory. 下表介绍了这些限制。The following table describes these limits.

机制Mechanism 范围Scope 限制Limits 支持的权限级别Supported level of permission
Azure RBACAzure RBAC 存储帐户、容器。Storage accounts, containers.
在订阅或资源组级别进行跨资源 Azure 角色分配。Cross resource Azure role assignments at subscription or resource group level.
一个订阅中 2000 个 Azure 角色分配2000 Azure role assignments in a subscription Azure 角色(内置或自定义)Azure roles (built-in or custom)
ACLACL 目录、文件Directory, file 每个文件和每个目录有 32 个 ACL 条目(实际上是 28 个 ACL 条目)。32 ACL entries (effectively 28 ACL entries) per file and per directory. 访问 ACL 和默认 ACL 都有自己的 32 个 ACL 条目的限制。Access and default ACLs each have their own 32 ACL entry limit. ACL 权限ACL permission

共享密钥和共享访问签名 (SAS) 授权Shared Key and Shared Access Signature (SAS) authorization

Azure Data Lake Storage Gen2 还支持使用共享密钥SAS 方法进行身份验证。Azure Data Lake Storage Gen2 also supports Shared Key and SAS methods for authentication. 这两种身份验证方法的特点是没有与调用方关联的标识,因此不能执行基于安全主体权限的身份验证。A characteristic of these authentication methods is that no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

就共享密钥这一种方法而言,调用方有效地获得了“超级用户”访问权限,这意味着对所有资源上所有操作(包括数据操作、设置所有者的操作和更改 ACL 的操作)的完全访问权限。In the case of Shared Key, the caller effectively gains 'super-user' access, meaning full access to all operations on all resources including data, setting owner, and changing ACLs.

SAS 令牌本身就包含允许的权限。SAS tokens include allowed permissions as part of the token. 它包含的权限有效地应用到所有授权决策,但不执行额外的 ACL 检查。The permissions included in the SAS token are effectively applied to all authorization decisions, but no additional ACL checks are performed.

后续步骤Next steps

若要详细了解访问控制列表,请参阅 Azure Data Lake Storage Gen2 中的访问控制列表 (ACL)To learn more about access control lists, see Access control lists (ACLs) in Azure Data Lake Storage Gen2.