OneLake 安全是一个基于角色的系统，决定谁可以访问 OneLake 中的数据，以及他们可以对这些数据采取哪些行动。 理解数据访问控制模型有助于你只授予用户所需的访问权限，从而保护敏感数据，同时让合适的人使用。
本文将解释 OneLake 安全角色的结构，它们如何与工作区和项目权限集成，OneLake 如何应用和解析对你数据的访问，以及需要注意的限制。
OneLake 安全角色
OneLake 安全采用基于角色的访问控制（RBAC）模型来管理 OneLake 中的数据访问。 在OneLake的安全体验中，每个角色包含以下组成部分：
- 权限： 角色对数据授予的权限，如读取或读写。
- 类型： 角色类型。 OneLake 安全仅支持授予角色，这些角色允许成员访问该角色中的数据。 它不支持用于撤销访问权限的拒绝角色。
- 角色中的数据： 角色授权访问的表、文件夹或模式。 你还可以在表上定义带有行级和列级安全性的数据访问。
- 角色成员：分配给该角色的 Microsoft Entra 身份，如用户、组或非用户身份。 如果你分配了一个 Microsoft Entra 组，OneLake 安全系统会将该角色授予该组的所有成员。
OneLake 安全采用默认拒绝模式，因此用户起始时无法访问数据，除非 OneLake 安全角色明确授予访问权限。 一些 Fabric 项目从默认角色开始，基于用户的工作区权限提供基本访问权限。
权限和支持的项目
OneLake 安全角色支持以下权限：
-
读： 允许用户从表读取数据并查看关联的表和列元数据。 用 SQL 术语来说，此权限等同于
VIEW_DEFINITION和SELECT。 欲了解更多信息，请参见 元数据安全性。 -
读写： 赋予用户读取和写入表或文件夹中数据的能力，并查看相关的表和列元数据。 用SQL术语来说，这个权限等价于
ALTER、DROPUPDATEINSERT和。 更多信息请参见 ReadWrite 权限。
你可以为以下 Fabric 项目创建 OneLake 安全角色：
| 织物物品 | 支持的权限 |
|---|---|
| Lakehouse | 读、读写 |
| Azure Databricks 镜像目录 | 读取 |
| 镜像数据库 | 读取 |
| 镜像目录 | 读取 |
ReadWrite 权限
使用ReadWrite权限，赋予只读用户对项目中特定数据的写权限。
ReadWrite 仅适用于对某个项具有“读取”权限的用户，例如具有工作区“查看者”角色的用户。 将读写分配给工作区管理员、成员或贡献者无效，因为这些工作区角色已经拥有写权限。
ReadWrite 包含了读取权限赋予的所有权限，并且还授予对所选对象及其内容的写入权限。 例如，对文件夹的读写权限会授予对该文件夹及其内的数据写入权限。
拥有可读写权限的用户可以执行以下操作：
- 创建、删除或重命名文件夹或表格。
- 上传或编辑文件。
- 创建、删除或重命名快捷方式。
用户可以通过 Spark 笔记本、OneLake 文件资源管理器或 OneLake API 执行写入操作。 由于 Fabric 仅支持单引擎写入数据，拥有 ReadWrite 权限的用户只能通过 OneLake 写入该数据。 所有查询引擎继续一致地强制执行读操作。
授予 ReadWrite 权限的 OneLake 安全角色不能包含行级安全（RLS）或列级安全（CLS）约束。
OneLake 安全性和工作区权限
工作区角色是OneLake中数据的第一个安全边界。 它们管理控制平面——创建和管理 Fabric 项目及权限——并应用到工作区中的所有项目。 关于各个工作区角色授予的具体 OneLake 权限，请参阅 使用工作区角色授予访问权限。 想了解更多关于工作区角色的信息，请参见 Fabric 中的工作区角色。
除了控制平面访问之外，工作区角色还可以通过 OneLake 安全默认角色授予对数据项的访问权限。 （默认角色仅适用于查看者，因为管理员、成员和贡献者角色通过写入权限拥有提升权限。）默认角色是 Fabric 在每次新增项目时自动创建的普通 OneLake 安全角色。 它为具有特定工作区或项权限的用户提供对该项目中数据的默认访问级别。 例如，Lakehouse 项具有 DefaultReader 角色，允许用户使用 ReadAll 权限查看 lakehouse 中的数据。 这种默认访问权限确保使用新创建物品的用户拥有基本权限。 所有默认角色都使用成员虚拟化功能，因此该角色的成员即为该工作区中拥有所需权限的任何用户。 例如，对 Lakehouse 具有 ReadAll 权限的所有用户。
下表显示了标准默认角色。 物品可能具有仅适用于该物品类型的专用默认角色。
| 织物物品 | 角色名称 | 已获得许可 | 分配的成员 |
|---|---|---|---|
| Lakehouse | DefaultReader |
读取 | 所有具有 ReadAll 权限的用户 |
| Azure Databricks 镜像目录 | DefaultReader |
读取 | 具有读取权限的所有用户 |
| 镜像目录 | DefaultReader |
读取 | 具有读取权限的所有用户 |
| 镜像数据库 | DefaultReader |
读取 | 所有具有 ReadAll 权限的用户 |
你可以修改或移除 Fabric 项目中的默认角色，以更改该成员组用户的访问权限。
引擎和用户访问数据
OneLake 安全性默认采用最小权限访问。 某些存储层操作无法强制执行RLS或CLS，因此当查询无法安全过滤时，OneLake会完全屏蔽查询，以避免暴露用户不被允许查看的数据。 查询是否被过滤或阻塞取决于访问路径——支持的查询引擎还是直接用户访问。
有关支持 RLS 和 CLS 筛选的引擎以及各自的要求，请参阅 读取受 OneLake 安全性保护的数据。
范围与执法
本部分详细介绍了 OneLake 安全角色如何授予对特定范围的访问权限、该访问是如何运作的，以及如何在多个角色和访问类型之间解决访问权限。
表级安全性
OneLake 将所有表表示为文件夹，但从 OneLake 安全和 Fabric 查询引擎的角度来看，并非所有文件夹都是表。 要成为有效的表，文件夹必须满足以下条件：
- 该文件夹位于某个项目的
Tables/目录中。 对于启用架构的项目，该文件夹还必须位于有效的架构文件夹中。 - 该文件夹包含一个
_delta_log文件夹，其中含有与表元数据对应的 JSON 文件。 - 该文件夹不包含任何子快捷方式。
如果你在某个表格上配置RLS或CLS，当该表格的文件夹不符合这些条件时，OneLake会拒绝访问。 没有RLS或CLS，OneLake会将不符合这些条件的文件夹视为文件夹，并应用文件夹级别的安全。
行级别和列级别安全性
在角色内，你可以使用行级安全和列级安全性来限制对表中特定行和列的访问。 有关每个控制的功能以及 OneLake 如何执行该控制的更多信息，请参见 OneLake 中的表、列和行级安全性。 有关RLS和CLS如何判断用户属于多个角色的信息，请参见 “评估多个OneLake安全角色”。
元数据安全性
OneLake 安全性的“读取”权限授予对表中数据和元数据的完全访问权限。 对于无权访问表的用户，数据永远不会公开。 该规则同样适用于列级安全，以及用户能否看到该表中的某列。 然而，OneLake 的安全机制并不保证表的元数据不可访问。 某些错误消息和使用场景中可能会显示列名。
文件夹权限继承与遍历
文件夹权限对层级结构有两个影响：
- 继承： 文件夹被授予的权限向下应用到其文件和子文件夹。
- 遍历与列表： 当用户对子项拥有权限时，OneLake 安全允许他们列出并遍历其父文件夹，以便发现并导航到可访问的数据。 遍历不会授予访问兄弟文件或文件夹的权限。
请考虑OneLake中湖畔别墅的以下层级结构：
Tables/
──── (empty folder)
Files/
────folder1
│ │ file11.txt
│ │
│ └───subfolder11
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
│
└───folder2
│ file21.txt
你创建一个角色 Role1，该角色授予对 subfolder11 的 读取 权限。 通过继承权限，该角色的成员可以读取 file111.txt 以及 subfolder111 中的所有内容。 成员可以查看并遍历 folder1 以到达 subfolder11，但他们看不到 file11.txt，因为它与 subfolder11 是同级项；他们也看不到 Tables，因为它与 Files 是同级项。
Files/
│
└───folder1
│ │
│ └───subfolder11 <-- READ
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
你创建另一个角色（Role2），该角色授予对 的 folder2 权限。 通过继承，成员可以阅读 file21.txt。 成员可以通过 folder2 和 Files 到达它，但他们看不到 folder1 或其任何子项。
Files/
│
└───folder2 <-- READ
│ file21.txt
对于快捷方式，行为略有不同。 指向外部数据源的快捷方式和文件夹的行为一样。 然而，通往其他OneLake地点的捷径有其特殊行为。 快捷方式的目标权限确定对某个 OneLake 快捷方式的访问权限。 在列出快捷方式时，OneLake 不会发起调用来检查目标的访问权限。 因此，当你列出目录时，OneLake 会返回所有内部快捷方式，无论你是否访问目标。 访问检查会在你尝试打开快捷方式时进行评估，然后你只看到你拥有所需权限的数据。
快捷方式
OneLake 的安全系统集成了捷径，以保护 OneLake 内外的数据安全。 快捷方式使用两种认证模式之一：
- 直通： 该快捷方式使用发起查询的用户身份访问目标。 直通模式是 OneLake 到 OneLake 快捷方式的默认设置。
- 委派： 该快捷方式使用配置好的连接身份或凭证来访问目标。 OneLake 到 OneLake 的快捷方式可以使用委派认证，而对外部系统的快捷方式也始终使用委派认证。
创建快捷方式需要对创建快捷方式的路径和目标路径的权限。 关于创建和访问每种快捷方式类型的要求，请参见 OneLake 快捷方式安全性。
透传快捷方式中的 OneLake 安全性
当用户通过 OneLake 之间的直通捷径访问数据时，OneLake 会利用呼叫用户的身份授权访问目标路径。 用户的有效访问受限于他们对捷径和目标路径的权限。
注意
查询引擎身份和快捷方式认证是两个独立的设置。 直通捷径通常使用呼叫用户的身份来访问目标。 然而，使用 Direct Lake over SQL 的 Power BI 语义模型和 SQL 分析端点的委托身份模式，使用了消费者项目或数据源的所有者身份。 这种行为不会改变快捷方式配置的认证模式。 对于端到端用户身份直通，可以使用 Direct Lake 而非 OneLake，或配置 SQL 分析端点使用用户身份访问模式。
你不能直接在 OneLake 到 OneLake 的快捷方式上设置 OneLake 安全权限。 包含快捷方式的文件夹权限与目标路径的权限合并。 如果目标项目支持 OneLake 安全，用户需要通过 OneLake 安全角色访问。 如果目标项目不支持 OneLake 安全，用户需要对目标项目获得 Fabric ReadAll 权限。 用户不需要对目标物品拥有 Fabric 读取权限，就能通过快捷方式访问其数据。
委派快捷方式中的 OneLake 安全性
委派捷径使用配置好的连接身份或凭证，而非调用用户的身份来访问目标。 OneLake 的安全限制了呼叫用户通过该连接能访问的内容。
委派的 OneLake 快捷方式
对于委派的 OneLake 到 OneLake 快捷方式，调用用户所看到的访问权限，是其对快捷方式路径的访问权限与已配置的连接标识对目标路径的访问权限的交集。 两条路径均支持列级安全（CLS）。 目标路径支持行级安全（RLS），但快捷路径上无法定义RLS。
委托的外部快捷方式
访问外部系统的捷径，如 ADLS、Amazon S3和Dataverse，则通过配置好的连接凭证访问外部源。 OneLake 安全性应用于该凭据授予的访问权限之上。
例如，假设 user1 创建了一个指向 Amazon S3 存储桶中某个文件夹的 lakehouse 快捷方式，而 user2 从 lakehouse 中访问该快捷方式。 用户2只有在配置的S3连接凭证能够访问源头且OneLake安全授权用户2访问捷径时，才能访问S3数据。
你可以授权OneLake对整个外部快捷方式或选定子路径的安全访问权限。 文件夹的权限会递归继承到其所有子文件夹，包括快捷方式内的文件夹。 通过另一个 OneLake 快捷方式进入外部快捷方式的用户，仍需获得对原始外部快捷方式应用的 OneLake 安全授权。
通过 Spark 或直接调用 OneLake API 访问外部快捷方式，也需要对包含该外部快捷方式的项目获得 Fabric 读取权限。 该权限对于安全解析与外部系统的连接至关重要。
评估多个OneLake安全角色
用户可以同时拥有多个 OneLake 安全角色。 OneLake将这些角色授予的访问权限合并为一个 有效角色，决定用户可访问的数据。 OneLake分阶段评估有效作用。
在每个角色内解决访问权限
OneLake 首先独立解析每个角色。 在角色内，用户只能访问三种安全组件允许的数据：
- 对象级安全（OLS）决定角色可以访问哪些表或文件夹。
- 行级安全（RLS）限制了角色可以访问给定表的哪些行。
- 列级安全（CLS）限制了角色能访问给定表的列。
由于这三个组成部分都适用，因此 OneLake 取三者的交集。 例如，如果 Role1 授予对 Table1 的访问权限，并限制其中的行和列，则 Role1 解析后的访问权限为：
Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS
交叉符号（∩）表示用户仅获得该角色中OLS、RLS和CLS允许的访问权限。
跨岗位合并访问权限
在解决每个角色后，OneLake 通过使用联合或最小限制模型将角色组合起来。 并集符号（∪）表示，任何角色授予的访问权限都会成为有效角色的一部分。 如果 Role1 授予对 TableA 的访问权限，Role2 授予对 TableB 的访问权限，那么属于这两个角色的用户都可以访问这两张表。
对于两个角色，有效角色为：
Effective role = Role1 ∪ Role2
当多个角色授予对同一表的访问权限时，行级安全规则会通过 OR 运算符进行组合。 例如，允许 city = 'Redmond' 和 city = 'New York' 的谓词会组合成 city = 'Redmond' OR city = 'New York'。
列级安全规则也按并集方式组合，但 SQL 分析端点除外。 在SQL分析端点中，CLS使用更严格的拒绝语义。 如果任何角色隐藏了某一列，端点就会阻止访问该列。 因此，端点与所有用户角色的CLS允许列表相交，而不是将它们合并为联合体。
重要
保留必须在同一岗位同时适用的RLS和CLS规则。 OneLake 不支持这样一种角色组合：两个角色对同一个表允许访问的列集合不同，且其中任一角色还对该表应用了 RLS。 例如，用户不能属于 Role1，允许列 c1 和 c2 及部分行，也不能属于 Role2，允许列 c2 和 c3。
合并快捷方式和目标访问权限
对于快捷方式而言，OneLake 会分别在快捷方式所在位置和快捷方式目标位置评估角色。 目标角色在快捷方式位置变为推断角色。 OneLake 随后将快捷角色的合并访问与推断目标角色的合并访问相交。 此步骤可防止从快捷方式位置继承的访问权限覆盖对目标的访问限制。
对于两个捷径角色和两个推断目标角色，有效访问为：
Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)
在此表达式中，ShortcutRole1 和 ShortcutRole2 是快捷方式位置处的角色。
InferredRole1 和 InferredRole2 分别是从捷径目标推断出的相应角色。 每个角色都会先根据其 OLS、RLS 和 CLS 组件进行解析，然后 OneLake 再将这些角色合并。
OneLake 安全限制
如果将 OneLake 安全性角色分配给 B2B 来宾用户，则必须 Microsoft Entra 外部 ID 中为 B2B 配置外部协作设置。 将访客用户访问设置为访客用户与成员拥有相同的访问权限（最包容性）。
如果将通讯组添加到 OneLake 安全性角色中，SQL 分析端点将无法解析该组的成员，因此无法实施访问控制。 因此，用户访问SQL分析端点时似乎不属于该角色。 Direct Lake 在 SQL 语义模型上也受此限制。
Spark 笔记本要求环境版本为 3.5 或更高版本，且使用 Fabric 运行时 1.3。
无架构 lakehouse 不支持对受 RLS 和 CLS 保护的表进行数据预览。 使用启用架构的湖屋，并采用 OneLake 安全性。
OneLake 的安全功能无法与 Azure Data Share 或 Purview Data Share 兼容。 有关详细信息，请参阅 Azure Data Share。
下表列出了 OneLake 安全角色的局限性。
方案 限制 每个 Fabric 项的 OneLake 安全性角色数量上限 每项 250 个角色（见注） 每个 OneLake 安全角色的成员人数上限 每个角色，500 个用户或用户组 每个 OneLake 安全角色的权限数量上限 每个角色 500 个权限 注意
你可以申请将每个项的角色数提高到 1,000。 若要请求增加，请联系 Azure Support。
潜伏期
对角色定义的更改需要大约 5 分钟才能应用。
在对 OneLake 安全角色中的用户组进行更改后，OneLake 大约在一个小时后才能在更新的用户组上应用该角色的权限。 某些 Fabric 引擎有自己的缓存层，因此可能需要额外的一小时才能更新所有系统中的访问。