借助 OneLake 安全性，Microsoft Fabric 正在扩展组织如何跨工作负载管理和强制实施数据访问。 此新的安全框架使管理员能够更灵活地配置权限。 管理员可以 通过 OneLake 或 SQL 分析终结点中的 基于 SQL 的精细控制 在集中式治理之间进行选择。
SQL 分析终结点中的访问模式
使用 SQL 分析终结点时，所选访问模式确定如何强制实施数据安全性。 Fabric 支持两个不同的访问模型，每个模型提供不同的优势，具体取决于运营和合规性需求：
用户标识模式：使用 OneLake 角色和策略强制实施安全性。 在此模式下，SQL 分析终结点将已登录用户的标识传递给 OneLake，读取 访问权限完全由 OneLake 中定义的安全规则控制。 支持对表的 SQL 级权限，确保跨 Power BI、笔记本和 Lakehouse 等工具进行一致的治理。
委派标识模式：通过 SQL 提供完全控制。 在此模式下，SQL 分析终结点使用 工作区或项 所有者的标识连接到 OneLake， 并且安全性由数据库中定义的 SQL 权限独占管理 。 此模型支持传统安全方法，包括 GRANT、REVOKE、自定义角色、Row-Level 安全和动态数据掩码。
每个模式都支持不同的治理模型。 了解其含义对于在 Fabric 环境中选择正确的方法至关重要。
访问模式之间的比较
下面是一个清晰简洁的比较表，重点介绍在用户标识模式与委托标识模式下设置安全性的方式和位置 - 按对象类型和数据访问策略细分：
| 安全目标 | 用户标识模式 | 委派标识模式 |
|---|---|---|
| Tables | 访问由 OneLake 安全角色控制。 不允许使用 SQL GRANT/REVOKE 。 |
使用 SQL GRANT/REVOKE完全控制 。 |
| Views | 使用 SQL GRANT/REVOKE 分配权限。 | 使用 SQL GRANT/REVOKE 分配权限。 |
| 存储过程 | 使用 SQL GRANT EXECUTE 分配权限。 | 使用 SQL GRANT EXECUTE 分配权限。 |
| 函数 | 使用 SQL GRANT EXECUTE 分配权限。 | 使用 SQL GRANT EXECUTE 分配权限。 |
| 行级安全性 (RLS) | 在 OneLake UI 中定义为 OneLake 安全角色的一部分。 | 使用 SQL CREATE SECURITY POLICY 定义。 |
| Column-Level 安全性（CLS） | 在 OneLake UI 中定义为 OneLake 安全角色的一部分。 | 使用 SQL GRANT SELECT 和列列表进行定义。 |
| 动态数据掩码 （DDM） | OneLake 安全性不支持。 | 使用 SQL ALTER TABLE 和 MASKED 选项定义。 |
OneLake 安全性中的用户标识模式
在用户标识模式下，SQL 分析终结点使用 直通身份验证机制 来强制实施数据访问。 当用户连接到 SQL 分析终结点时，其 Entra ID 标识将传递到 OneLake，后者执行权限检查。 使用 OneLake Lakehouse 中定义的安全规则（而不是任何 SQL 级 GRANT 或 REVOKE 语句）评估针对表的所有读取作。
通过此模式可以集中管理安全性，确保跨所有 Fabric 体验（包括 Power BI、Notebook、Lakehouse 和 SQL 分析终结点）的一致强制实施。 它专为治理模型而设计，可在 OneLake 中定义一次访问权限，并在任何地方自动受到尊重。
在用户标识模式下：
表访问完全由 OneLake 安全性管理。 忽略表上的 SQL GRANT/REVOKE 语句。
RLS（Row-Level 安全性）、CLS（Column-Level 安全性）和 Object-Level 安全性均在 OneLake 体验中定义。
允许对非数据对象（如视图、存储过程和函数）使用 SQL 权限，从而灵活地定义自定义逻辑或面向用户的入口点来访问数据。
SQL 分析终结点不支持写入作。 所有写入都必须通过 Lakehouse UI 进行，并由工作区角色（管理员、成员、参与者）管理。
重要
SQL Analytics 终结点需要在 OneLake 安全角色中的项权限和成员之间进行一对一映射才能正确同步。 如果您授予某个身份对 OneLake 安全角色的访问权限，则该身份还需要对 Lakehouse 具有 Fabric 读取权限。 例如，如果用户将“user123@microsoft.com”分配给 OneLake 安全角色，则还必须将“user123@microsoft.com”分配给该 Lakehouse。
工作区角色行为
工作区级别具有 管理员、 成员或 参与者 角色的用户不受 OneLake 安全强制的约束。 这些角色具有提升的权限，将完全绕过 RLS、CLS 和 OLS 策略。 请遵循以下要求，确保遵守 OneLake 安全性：
在工作区中为用户分配 查看器 角色，或
使用 只读 权限与用户共享 Lakehouse 或 SQL 分析终结点。 只有具有只读访问权限的用户才能根据 OneLake 安全角色筛选其查询。
角色优先级：大多数宽松的访问获胜
如果用户属于 多个 OneLake 角色，则最宽松的角色定义其有效访问权限。 例如：
如果一个角色授予对表的完全访问权限，另一个角色应用 RLS 来限制行， 则不会强制实施 RLS。
更广泛的访问角色优先。 此行为可确保用户不会无意中被阻止，但需要仔细设计角色以避免冲突。 建议在强制实施行级或列级访问控制时保持限制和宽松的角色 相互排斥 。
有关详细信息，请参阅 OneLake 安全性 的数据访问控制模型 。
OneLake 和 SQL 分析终结点之间的安全同步
用户标识模式的关键组件是 安全同步服务。 此后台服务监视对 OneLake 中安全角色所做的更改，并确保这些更改反映在 SQL 分析终结点中。
安全同步服务负责以下各项：
检测对 OneLake 角色的更改，包括新角色、更新、用户分配和表更改。
将 OneLake 定义的策略（RLS、CLS、OLS）转换为等效的与 SQL 兼容的数据库角色结构。
确保正确验证来自其他 lakehouses 的 快捷方式对象 （来自其他 lakehouses 的表），以便遵守原始 OneLake 安全设置，即使在远程访问时也是如此。
此同步可确保 OneLake 安全定义具有权威性，无需手动 SQL 级干预来复制安全行为。 因为安全是集中实施的：
在此模式下，不能直接使用 T-SQL 定义 RLS、CLS 或 OLS。
你仍然可以使用 GRANT 或 EXECUTE 语句将 SQL 权限应用于视图、函数和存储过程。
安全同步错误和解决方法
| Scenario | 用户标识模式下的行为 | 委托模式下的行为 | 纠正措施 | 注释 |
|---|---|---|---|---|
| RLS 策略引用已删除或重命名的列 | 错误：*行级安全策略引用不再存在的列。*数据库在修复策略之前进入错误状态。 | 错误：列名列名<>无效 | 更新或删除一个或多个受影响的角色，或还原缺少的列。 | 需要在创建角色的 Lakehouse 中进行更新。 |
| CLS 策略引用已删除或重命名的列 | 错误：*列级安全策略引用不再存在的列。*数据库在修复策略之前进入错误状态。 | 错误：列名列名<>无效 | 更新或删除一个或多个受影响的角色，或还原缺少的列。 | 需要在创建角色的湖仓中进行更新。 |
| RLS/CLS 策略引用已删除或重命名的表 | 错误： 安全策略引用不再存在的表。 | 未显示任何错误;如果缺少表，则查询会以无提示方式失败。 | 更新或删除一个或多个受影响的角色，或还原缺少的表。 | 更新需要在创建角色的 Lakehouse 中进行。 |
| DDM （动态数据掩码） 策略引用已删除或重命名的列 | OneLake Security 不支持 DDM，必须通过 SQL 实现。 | 错误：列名列名<>无效 | 更新或删除一个或多个受影响的 DDM 规则，或还原缺少的列。 | 更新 SQL Analytics 终结点中的 DDM 策略。 |
| 系统错误（意外失败） | 错误： 发生意外的系统错误。重试或联系支持人员。 | 错误： 将表更改应用于 SQL 时发生内部错误。 | 重试作;如果问题仍然存在，请联系Microsoft支持部门。 | N/A |
| 用户对项目没有权限 | 错误： 用户对项目没有权限 | 错误： 用户对项目没有权限 | 向用户提供对项目的 objectID {objectID} 权限。 | 对象 ID 必须在 OneLake 安全角色成员和 Fabric 项目权限之间完全匹配。 如果将一个组添加到角色成员中，则必须授予该组 Fabric 读取权限。 将该组中的成员添加到项目并不算作直接匹配项。 |
| 不支持用户主体。 | 错误： 不支持用户主体。 | 错误： 不支持用户主体。 | 请从角色 DefaultReader 中删除用户 {username} | 如果用户不再是有效的 Entra ID，例如用户已离开组织或删除，则会发生此错误。 从角色中删除它们以解决此错误。 |
具有安全同步的快捷方式行为
OneLake 安全性在事实来源强制执行，因此安全同步会禁用涉及快捷方式的表和视图的所有权链。 这可确保始终评估并遵循源系统权限，即使对于来自另一个数据库的查询也是如此。
因此：
用户必须对快捷源（current Lakehouse 或 SQL 分析终结点）和数据实际驻留的目标具有有效的访问权限。
如果用户在任一端都缺少权限， 则查询将失败 并出现访问错误。
设计引用快捷方式的应用程序或视图时，请确保在快捷方式关系的 两端 正确配置角色分配。
此设计可跨 Lakehouse 边界保持安全完整性，但如果跨 Lakehouse 角色不一致，则会引入访问失败的情况。
OneLake 安全性中的委托模式
在 委派标识模式中，SQL 分析终结点使用今天存在于 Microsoft Fabric 中的相同 安全模型 。 安全和权限完全在 SQL 层进行管理， OneLake 角色或访问策略不会 强制实施表级访问。 当用户连接到 SQL 分析终结点并发出查询时：
SQL 根据 SQL 权限 （GRANT、REVOKE、RLS、CLS、DDM、角色等）验证访问权限。
如果查询获得授权，系统将继续访问 OneLake 中存储的数据。
此数据访问是使用 Lakehouse 或 SQL 分析终结点所有者（也称为 项帐户）的标识执行的。
在此模型中：
已登录用户不会传递到 OneLake。
所有强制访问都假定在 SQL 层进行处理。
项所有者负责在 OneLake 中拥有足够的权限来代表工作负荷读取基础文件。
由于这是委托模式，因此所有者的 SQL 权限与 OneLake 访问之间的任何不对齐都会导致查询失败。 此模式提供与以下功能完全兼容性：
所有对象级别的 SQL GRANT/REVOKE
SQL 定义的 Row-Level 安全性、 Column-Level 安全性和动态数据掩码
DBA 或应用程序使用的现有 T-SQL 工具和做法
如何更改 OneLake 访问模式
访问模式确定通过 SQL 分析终结点查询 OneLake 时如何对数据访问进行身份验证和强制执行。 可以使用以下步骤在用户标识模式和委派标识模式之间切换：
导航到 Fabric 工作区并打开 Lakehouse。 从右上角切换到 SQL 分析终结点。
在顶部导航中，转到“ 安全 ”选项卡，然后选择以下 OneLake 访问模式之一：
用户标识 - 使用登录用户的标识。 它强制实施 OneLake 角色。
委托标识 - 使用项所有者的标识;仅强制实施 SQL 权限。
此时会启动一个弹出窗口以确认你的选择。 选择 “是 ”以确认更改。
在模式之间切换时的注意事项
切换到用户标识模式
将忽略 SQL RLS、CLS 和表级权限。
必须为用户配置 OneLake 角色才能保持访问权限。
只有具有查看者权限或共享只读访问权限的用户才会受到 OneLake 安全性的约束。
现有 SQL 角色已删除，无法恢复。
切换到委派标识模式
不再应用 OneLake 角色和安全策略。
SQL 角色和安全策略变为活动状态。
项所有者必须具有有效的 OneLake 访问权限，否则所有查询可能失败。
局限性
仅适用于读者：OneLake 安全管理以 查看者身份访问数据的用户。 其他工作区角色（管理员成员或参与者）中的用户绕过 OneLake 安全并保留完全访问权限。
SQL 对象不继承所有权：快捷方式以表的形式显示在 SQL 分析终结点中。 直接或通过视图、存储过程和其他派生 SQL 对象访问这些表时，不会携带对象级所有权;在运行时检查所有权限，以防止绕过安全。
快捷方式更改触发验证停机时间：当快捷方式目标发生更改（例如重命名、URL 更新）时，数据库会在系统验证新目标时短暂进入 单用户模式 。 在此期间，查询被阻止，这些作相当快，但有时取决于不同的内部进程可能需要长达 5 分钟才能同步。
- 创建架构快捷方式可能会导致影响验证和延迟元数据同步的已知错误。
延迟的权限传播：权限更改不是即时的。 在安全模式（用户标识与委托）之间切换可能需要时间才能传播，然后才能生效，但需要不到 1 分钟的时间。
控制平面依赖项：权限不能应用于工作区控制平面中尚不存在的用户或组。 你要么需要共享源项，要么用户必须是查看器工作区角色的成员。 请注意，完全相同的对象 ID 必须位于这两个位置。 组和该组的成员并不算作匹配项。
大多数宽松的访问占上风：当用户属于多个组或角色时，遵循最宽松的有效权限 示例：如果用户同时通过一个角色和另一个角色授予 DENY，则 GRANT 优先。
委派模式限制：在委派模式下，如果源项具有不向项所有者授予完整表访问权限的 OneLake 安全策略，则快捷表上的元数据同步可能会失败。
DENY 行为：当多个角色应用于单个快捷表时，权限的交集遵循 SQL Server 语义：DENY 替代 GRANT。 这可能会导致意外的访问结果。
预期错误条件：用户在以下情况下可能会遇到错误：
已重命名或无效的快捷目标
- 示例：如果删除了表的源。
RLS （Row-Level 安全性） 配置错误
OneLake 不支持某些用于 RLS 筛选的表达式，它可能允许未经授权的数据访问。
删除筛选器表达式上使用的列会使 RLS 和元数据同步失效，直到 OneLake 安全面板上修复 RLS 为止。
对于公共预览版，我们仅支持单个表达式表。 目前不支持动态 RLS 和多表 RLS。
Column-Level 安全性（CLS）限制
CLS 的工作原理是维护列的允许列表。 如果删除或重命名允许的列，则 CLS 策略将变为无效。
当 CLS 无效时，在 OneLake 安全面板中修复 CLS 规则之前，将阻止元数据同步。
元数据或权限同步失败
- 如果表发生更改（如重命名列），则新对象上不会复制安全性，并且你会收到显示该列不存在的 UI 错误。
表重命名不会保留安全策略：如果 OneLake Security （OLS） 角色在架构级别上定义，则只要表名称不变，这些角色才会生效。 重命名表会中断关联，安全策略不会自动迁移。 这可能会导致意外的数据泄露，直到策略重新应用。
OneLake 安全角色的名称不能超过 124 个字符;否则，安全同步无法同步角色。
OneLake 安全角色在具有OLS_前缀的 SQL 分析终结点上传播。
不支持OLS_角色上的用户更改，并可能导致意外行为。
不支持邮箱启用的安全组和通讯组。
Lakehouse 的所有者必须是管理员、成员或贡献者工作区角色之一的成员；否则，安全性不会应用于 SQL 分析终结点。
Lakehouse 的所有者不能是安全同步工作的服务主体。