你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Data Lake Storage Gen2 中的访问控制和 data lake 配置

本文可帮助你评估和了解 Azure Data Lake 存储 Gen2 中的访问控制机制。 这些机制包括 Azure 基于角色的访问控制 (RBAC) 和访问控制列表 (ACL)。 学习内容：

• 如何评估 Azure RBAC 与 ACL 之间的访问
• 如何使用其中一种或两种机制配置访问控制
• 如何将访问控制机制应用于 Data Lake 实现模式

你需要具备存储容器、安全组、Azure RBAC 和 ACL 的基本知识。 为了限定讨论登录区域范围，我们引用了原始、扩充和特选区域的通用数据湖结构。

可以将本文档与数据访问管理配合使用。

使用内置的 Azure RBAC 角色

Azure 存储提供两个访问层：“服务管理”和“数据”。 可以通过服务管理层访问订阅和存储帐户。 通过数据层访问容器、Blob 和其他数据资源。 例如，若要从 Azure 获取存储帐户的列表，可向管理终结点发送请求。 如果需要存储帐户中文件系统、文件夹或文件的列表，可将请求发送到服务终结点。

角色可以包含对管理或数据访问层的权限。 读取者角色授予对管理层资源的只读访问权限，但不授予对数据的读取访问权限。

所有者、参与者、读者和存储帐户参与者等角色允许安全主体管理存储帐户。 但是，它们不提供对该帐户中的数据的访问权限。 只有为数据访问显式定义的角色才允许安全主体访问数据。 这些角色（读取者除外）可以访问存储密钥以访问数据。

内置管理角色

以下是内置管理角色。

• 所有者：管理所有内容，包括对资源的访问权限。 此角色提供密钥访问权限。
• 参与者：管理除资源访问权限以外的所有内容。 此角色提供密钥访问权限。
• 存储帐户参与者：完全管理存储帐户。 此角色提供密钥访问权限。
• 读者：读取和列出资源。 此角色不提供密钥访问权限。

内置数据角色

下面是内置数据角色。

• 存储 Blob 数据所有者：完全访问 Azure 存储 blob 容器和数据，包括设置所有权和管理 POSIX 访问控制。
• 存储 Blob 数据参与者：读取、写入和删除 Azure 存储容器与 Blob。
• 存储 Blob 数据读取者：读取和列出 Azure 存储容器与 Blob。

存储 Blob 数据所有者是一个超级用户角色，已授予对所有可变操作的完全访问权限。 这些操作包括设置目录或文件的所有者，以及非所有者的目录和文件的 ACL。 超级用户访问是唯一获准的更改资源所有者的方式。

注意

Azure RBAC 分配最多可能需要五分钟时间来传播并生效。

如何评估访问权限

在基于安全主体的授权期间，系统按以下顺序评估权限。 有关详细信息，请参阅下图。

• 首先评估 Azure RBAC，并优先于任何 ACL 分配。
• 如果操作是基于 RBAC 完全授权，则完全不会评估 ACL。
• 如果操作未完全获得授权，则会评估 ACL。

有关详细信息，请参阅如何评估权限。

注意

此权限模型仅适用于 Azure Data Lake Storage。 它不适用于未启用分层命名空间的常规用途或 Blob 存储。 此描述不包括共享密钥和 SAS 身份验证方法。 它还排除了向安全主体分配存储 Blob 数据所有者内置角色的方案，该角色提供超级用户访问。 设置为 allowSharedKeyAccess false，以便通过标识审核访问权限。

有关给定操作需要哪些基于 ACL 的权限的详细信息，请参阅 Azure Data Lake Storage Gen2 中的访问控制列表。

注意

• 访问控制列表仅适用于同一租户中的安全主体，包括来宾用户。
• 任何有权附加到群集的用户都可以创建 Azure Databricks 装入点。 使用服务主体凭据或 Microsoft Entra 直通选项配置装入点。 创建时，不会评估权限。 操作使用装入点时，将评估权限。 可以附加到群集的任何用户都可以尝试使用装入点。
• 当用户在 Azure Databricks 或 Azure Synapse Analytics 中创建表定义时，他们需要对基础数据具有读取访问权限。

配置对 Azure Data Lake Storage 的访问权限

使用 Azure RBAC、ACL 或两者的组合在 Azure Data Lake 存储中设置访问控制。

仅使用 Azure RBAC 配置访问权限

如果容器级访问控制足够，Azure RBAC 分配提供了一种简单的管理方法来保护数据。 建议对大量受限数据资产或需要精细访问控制的位置使用访问控制列表。

仅使用 ACL 配置访问权限

以下是针对云规模分析的访问控制列表配置建议。

将访问控制条目分配给安全组，而不是单个用户或服务主体。 有关详细信息，请参阅使用安全组与单个用户。

在组中添加或删除用户时，无需更新 Data Lake 存储。 此外，使用组可以减少超过每个文件或文件夹 ACL 32 个访问控制条目的可能性。 在四个默认条目之后，只有 28 个剩余条目用于权限分配。

即使使用组，目录树的顶层也可能有许多访问控制条目。 当需要不同组的精细权限时，会出现这种情况。

使用 Azure RBAC 和访问控制列表配置访问权限

存储 Blob 数据参与者和存储 Blob 数据读取者权限提供对数据而非存储帐户的访问权限。 可以在存储帐户级别或容器级别授予访问权限。 如果分配存储 Blob 数据参与者，则 ACL 不能用于管理访问权限。 在分配存储 Blob 数据读取器的位置，可以使用 ACL 授予提升的写入权限。 有关详细信息，请参阅如何评估访问权限。

这种方法有利于以下场景：大多数用户需要读取权限，只有少数用户需要写入权限。 数据湖区域可能是不同的存储帐户，数据资产可能是不同的容器。 数据湖区域可以用容器表示，数据资产可以用文件夹表示。

嵌套访问控制列表组方法

嵌套 ACL 组有两种方法。

选项 1：父执行组

在创建文件和文件夹之前，先从父组开始。 在容器级别向该组分配默认 ACL 和访问 ACL 的运行权限。 然后将需要数据访问权限的组添加到父组。

警告

建议不要使用递归删除模式，而是使用 选项 2：访问控制列表其他条目。

此方法称为嵌套组。 成员组继承父组的权限，而父组向所有成员组提供全局运行权限。 成员组不需要运行权限，因为这些权限是继承的。 更多的嵌套可能会提供更大的灵活性和灵活性。 将代表团队或自动化作业的安全组添加到数据访问读取者组和写入者组。

选项 2：访问控制列表的其他条目

推荐的方法是使用在容器或根中设置的 ACL 其他条目。 指定默认值并访问 ACL，如以下屏幕所示。 这种方法确保从根到最低级别的路径的每个部分都具有运行权限。

此运行权限向下传播到任何添加的子文件夹。 权限将传播到预期访问组需要读取和运行权限的深度。 该级别位于链的最低部分，如以下屏幕所示。 这种方法授予组读取数据的访问权限。 该方法同样适用于写访问。

推荐的数据湖区域安全性

对于每个 Data Lake 区域，建议使用以下安全模式：

• “原始”应仅允许使用安全主体名称 (SNS) 来访问数据。
• “扩充”应仅允许使用安全主体名称 (SNS) 来访问数据。
• 特选应允许使用安全主体名称 (SPN) 和用户主体名称 (UPN) 进行访问。

使用 Microsoft Entra 安全组的示例方案

有多种不同的方法可用来设置组。 例如，假设你有一个名为保存 /LogData 服务器生成的日志数据的目录。 Azure 数据工厂将数据引入到该文件夹中。 服务工程团队的特定用户上传日志并管理此文件夹的其他用户。 Azure Databricks 分析和数据科学工作区群集可以分析该文件夹中的日志。

若要启用这些活动，请创建一个 LogsWriter 组和一个 LogsReader 组。 分配以下权限：

• 将 LogsWriter 组添加到 /LogData 目录的具有 rwx 权限的 ACL。
• 将 LogsReader 组添加到 /LogData 目录的具有 r-x 权限的 ACL。
• 向 LogsWriters 组添加用于数据工厂的服务主体对象或托管服务标识 (MSI)。
• 将服务工程团队中的用户添加到 LogsWriter 组。
• 为 Microsoft Entra 直通配置 Azure Databricks 到 Azure Data Lake Store。

如果服务工程团队中的用户转移到其他团队，只需从 LogsWriter 组中删除该用户。

如果未将该用户添加到组，而是为该用户添加了专用 ACL 条目，则需要从 /LogData 目录中删除该 ACL 条目。 还需要从目录的整个目录层次结构 /LogData 中的所有子目录和文件中删除条目。

Azure Synapse Analytics 数据访问控制

若要部署 Azure Synapse 工作区，需要 Azure Data Lake 存储 Gen2 帐户。 Azure Synapse Analytics 将主存储帐户用于多个集成方案，并将数据存储在容器中。 该容器包括 Apache Spark 表和应用程序日志，位于名为 /synapse/{workspaceName} 的文件夹中。 工作区还使用容器来管理安装的库。

在通过 Azure 门户部署工作区期间，提供现有存储帐户或创建一个新帐户。 提供的存储帐户是工作区的主存储帐户。 部署过程使用“存储 Blob 数据参与者”角色授予对指定 Data Lake Storage Gen2 帐户的工作区身份访问权限。

如果在Azure 门户外部部署工作区，请手动将 Azure Synapse Analytics 工作区标识添加到 存储 Blob 数据参与者角色。 建议在容器级别存储 Blob 数据参与者分配角色，以遵循最低特权原则。

通过作业运行管道、工作流和笔记本时，它们使用工作区标识权限上下文。 如果任何作业读取或写入工作区主存储，则工作区标识使用通过“存储 Blog 数据参与者”授予的读/写权限。

当用户登录到工作区以运行脚本或进行开发时，用户的上下文权限允许对主存储进行读/写访问。

使用访问控制列表的 Azure Synapse Analytics 细粒度数据访问控制

设置 Data Lake 访问控制时，某些组织需要精细级别访问。 他们可能有组织中的某些组看不到的敏感数据。 Azure RBAC 仅允许在存储帐户和容器级别读取或写入。 使用 ACL，可以在文件夹和文件级别设置精细的访问控制，以允许对特定组的数据子集进行读取/写入。

使用 Spark 表时的注意事项

在 Spark 池中使用 Apache Spark 表时，它会创建一个仓库文件夹。 该文件夹位于工作区主存储中容器的根目录中：

synapse/workspaces/{workspaceName}/warehouse

如果你计划在 Azure Synapse Spark 池中创建 Apache Spark 表，请为运行创建 Spark 表的命令的组授予对仓库文件夹的写入权限。 如果命令在管道中通过触发的作业运行，请向工作区 MSI 授予写入权限。

此示例创建一个 Spark 表：

df.write.saveAsTable("table01")

有关详细信息，请参阅如何为 Synapse 工作区设置访问控制。

Azure Data Lake 访问权限摘要

没有一种管理数据湖访问的方法适合所有人。 数据湖的一个主要好处是提供对数据的无摩擦访问。 在实践中，不同的组织希望对其数据进行不同级别的治理和控制。 一些组织有一个集中的团队，在严格的内部控制下管理访问权限并预配组。 其他组织更灵活，并且具有分散控制。 选择符合治理级别的方法。 你的选择不应在获取数据访问权限时造成不必要的延迟或冲突。

后续步骤

• 在 Azure 的云规模分析中使用 Azure Databricks