Azure Data Lake Storage 中的访问控制模型
Data Lake Storage 支持以下授权机制：
- 共享密钥授权
- 共享访问签名 (SAS) 授权
- 基于角色的访问控制 (Azure RBAC)
- 基于属性的访问控制 (Azure ABAC)
- 访问控制列表 (ACL)
共享密钥、帐户 SAS 和服务 SAS 授权向用户（或应用程序）授予访问权限，而不要求其在 Microsoft Entra ID 中有标识。 使用这些身份验证形式时，Azure RBAC、Azure ABAC 和 ACL 不起作用。 ACL 可以应用于用户委托的 SAS 令牌，因为这些令牌使用 Microsoft Entra 凭证进行保护。 请参阅共享密钥和 SAS 授权。
Azure RBAC 和 ACL 都要求用户（或应用程序）在 Microsoft Entra ID 中有标识。 通过 Azure RBAC，你可以授予对存储帐户数据的“粗略”访问权限，例如对存储帐户中所有数据的读取或写入访问权限。 通过 Azure ABAC，你可以通过添加条件来细化 RBAC 角色分配。 例如，你可以授予对存储帐户中具有特定标记的所有数据对象的读取或写入访问权限。 通过 ACL，你可以授予“精细”访问权限，例如对特定目录或文件的写入访问权限。
本文重点介绍了 Azure RBAC、ABAC 和 ACL，以及系统如何将它们一起评估，以便针对存储帐户资源做出授权决策。
基于角色的访问控制 (Azure RBAC)
Azure RBAC 使用角色分配向安全主体应用权限集。 安全主体是一个对象，表示在 Microsoft Entra ID 中定义的用户、组、服务主体或托管标识。 权限集可以向安全主体授予“粗粒度”级别的访问权限，例如，对存储帐户中所有数据或容器中所有数据的读取或写入访问权限。
以下角色允许安全主体访问存储帐户中的数据。
| 角色 | 描述 |
|---|---|
| 存储 Blob 数据所有者 | 对 Blob 存储容器和数据的完全访问权限。 此访问权限允许安全主体设置项的所有者，以及修改所有项的 ACL。 |
| 存储 Blob 数据参与者 | 对 Blob 存储容器和 Blob 的读取、写入和删除访问权限。 此访问权限不允许安全主体设置项的所有权，但它可以修改安全主体拥有的项的 ACL。 |
| 存储 Blob 数据读者 | 读取和列出存储容器与 Blob。 |
所有者、参与者、读取者和存储帐户参与者等角色允许安全主体管理存储帐户，但不提供对该帐户中数据的访问权限。 但是，这些角色（读取者除外）可以获取对存储密钥的访问权限，存储密钥可在各种客户端工具中用来访问数据。
基于属性的访问控制 (Azure ABAC)
Azure ABAC 构建在 Azure RBAC 之上，它在特定操作上下文中根据属性添加角色分配条件。 角色分配条件是一项额外检查，你可选择将其添加到角色分配中，来提供更精细的访问控制。 你无法使用条件显式拒绝对特定资源的访问。
有关使用 Azure ABAC 控制对 Azure 存储空间的访问的详细信息，请参阅使用 Azure 角色分配条件授予对 Azure Blob 存储的访问权限。
访问控制列表 (ACL)
使用 ACL，你可以对目录和文件应用“更细粒度”的访问级别。 ACL 是一个包含一系列 ACL 条目的权限构造。 每个 ACL 条目都将安全主体与一个访问级别相关联。 若要详细了解，请参阅 Azure Data Lake Storage 中的访问控制列表 (ACL)。
权限是如何评估的
在基于安全主体的授权过程中，将如下图所示对权限进行评估。
- Azure 确定是否存在针对主体的角色分配。
- 如果存在角色分配，则接下来将评估角色分配条件 (2)。
- 否则，接下来将评估 ACL (4)。
- Azure 确定是否存在任何 ABAC 角色分配条件。
- 如果不存在任何条件，则授予访问权限。
- 如果条件存在，则评估它们是否与请求 (3) 匹配。
- Azure 确定所有 ABAC 角色分配条件是否与请求的属性匹配。
- 如果全部匹配，则授予访问权限。
- 如果其中至少一个条件不匹配，则接下来评估 ACL (4)。
- 如果在评估角色分配和条件后尚未显式授予访问权限，则评估 ACL。
- 如果 ACL 允许请求的访问级别，则授予访问权限。
- 否则，则拒绝访问。
重要
由于系统评估访问权限的方式，你无法使用 ACL 来限制已通过角色分配和其条件授予的访问权限。 这是因为系统会首先评估 Azure 角色分配和条件，如果这种分配授予了足够的访问权限，则会忽略 ACL。
下图显示了这三个常见操作的权限流：列出目录内容、读取文件和写入文件。
权限表：组合 Azure RBAC、ABAC 和 ACL
下表显示了如何组合使用 Azure 角色、条件和 ACL 条目，以便安全主体可以执行“操作”列中列出的操作。 此表显示的列代表虚构目录层次结构的每个级别。 容器的根目录 (/)、名为 Oregon 的子目录、Oregon 目录的名为 Portland 的子目录以及 Portland 目录中名为 Data.txt 的文本文件分别对应一个列。 这些列中显示了授予权限所需的 ACL 条目的简短形式的表示形式。 如果某个 ACL 条目不是执行操作所必需的，则列中将显示 N/A（不适用）。
| 操作 | 分配的 Azure 角色（有或无条件） | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Read Data.txt | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | 不适用 | 不可用 | 不可用 | 不可用 | |
| None | --X |
--X |
--X |
R-- |
|
| Append to Data.txt | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | --X |
--X |
--X |
-W- |
|
| None | --X |
--X |
--X |
RW- |
|
| Delete Data.txt | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | --X |
--X |
-WX |
不可用 | |
| None | --X |
--X |
-WX |
空值 | |
| 创建/更新 Data.txt | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | --X |
--X |
-WX |
不可用 | |
| None | --X |
--X |
-WX |
不适用 | |
| List / | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | 不适用 | 不可用 | 不可用 | 不可用 | |
| None | R-X |
不适用 | 不可用 | 不适用 | |
| List /Oregon/ | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | 不适用 | 不可用 | 不可用 | 不可用 | |
| None | --X |
R-X |
不适用 | 不适用 | |
| List /Oregon/Portland/ | 存储 Blob 数据所有者 | 不适用 | 不可用 | 不可用 | 不适用 |
| 存储 Blob 数据参与者 | 不适用 | 不可用 | 不可用 | 不适用 | |
| 存储 Blob 数据读取者 | 不适用 | 不可用 | 不可用 | 不可用 | |
| None | --X |
--X |
R-X |
不适用 |
注意
若要在 Azure 存储资源管理器中查看容器的内容，安全主体必须使用 Microsoft Entra ID 登录到存储资源管理器，并且（至少）对容器的根文件夹 (\) 具有读取访问权限 (R--)。 此权限级别允许安全主体列出根文件夹的内容。 如果不希望根文件夹的内容可见，可以向安全主体分配读取者角色。 使用该角色，安全主体将能够列出帐户中的容器，但不能列出容器内容。 然后，你可以使用 ACL 授予对特定目录和文件的访问权限。
安全组
始终将Microsoft Entra 安全组用作 ACL 条目中分配的主体。 拒绝直接分配各个用户或服务主体。 使用此结构，你可以添加和删除用户或服务主体，不需要向整个目录结构重新应用 ACL。 可以仅在适当的 Microsoft Entra 安全组中添加或删除用户和服务主体。
有多种不同的方法可用来设置组。 例如，假设你有一个名为 /LogData 的目录，该目录包含服务器生成的日志数据。 Azure 数据工厂 (ADF) 将数据引入到该文件夹中。 服务工程团队中的特定用户将上传日志并管理此文件夹的其他用户，而各个 Databricks 群集将分析来自该文件夹的日志。
若要启用这些活动，可以创建一个 LogsWriter 组和一个 LogsReader 组。 然后，可以按如下所示分配权限：
- 将
LogsWriter组添加到 /LogData 目录的具有rwx权限的 ACL。 - 将
LogsReader组添加到 /LogData 目录的具有r-x权限的 ACL。 - 向
LogsWriters组添加用于 ADF 的服务主体对象或托管服务标识 (MSI)。 - 将服务工程团队中的用户添加到
LogsWriter组。 - 将 Databricks 的服务主体对象或 MSI 添加到
LogsReader组。
如果服务工程团队中的用户离开了公司，则只需将其从 LogsWriter 组中删除即可。 如果未将该用户添加到组中，而是为该用户添加了专用 ACL 条目，则必须从 /LogData 目录中删除此 ACL 条目。 还必须从 /LogData 目录的整个目录层次结构中的所有子目录和文件中删除此条目。
要创建组并添加成员，请参阅使用 Microsoft Entra ID 创建基本组并添加成员。
对 Azure 角色分配和 ACL 条目的限制
通过使用组，你不太可能超出每个订阅的角色分配的最大数量，以及每个文件或目录的 ACL 条目的最大数量。 下表介绍了这些限制。
| 机制 | 范围 | 限制 | 支持的权限级别 |
|---|---|---|---|
| Azure RBAC | 存储帐户、容器。 在订阅或资源组级别进行跨资源 Azure 角色分配。 |
一个订阅中 4000 个 Azure 角色分配 | Azure 角色（内置或自定义） |
| ACL | 目录、文件 | 每个文件和每个目录有 32 个 ACL 条目（实际上是 28 个 ACL 条目）。 访问 ACL 和默认 ACL 都有自己的 32 个 ACL 条目的限制。 | ACL 权限 |
共享密钥和共享访问签名 (SAS) 授权
Azure Data Lake Storage 还支持使用共享密钥和 SAS 方法进行身份验证。
就共享密钥这一种方法而言，调用方有效地获得了“超级用户”访问权限，这意味着对所有资源上所有操作（包括数据操作、设置所有者的操作和更改 ACL 的操作）的完全访问权限。 ACL 不适用于使用共享密钥授权的用户，因为没有标识与调用方关联，因此无法执行基于安全主体权限的授权。 共享访问签名 (SAS) 令牌也是如此，除非使用用户委托的 SAS 令牌。 在这种情况下，只要使用可选参数 suoid，Azure 存储才会对对象 ID 执行 POSIX ACL 检查，然后才授权该操作。 若要了解详细信息，请参阅构造用户委派 SAS。
后续步骤
若要了解有关访问控制列表的详细信息，请参阅 Azure Data Lake Storage 中的访问控制列表 (ACL)。