适用于 SQL 分析终结点的 OneLake 安全性（预览版）

借助 OneLake 安全性，Microsoft Fabric 正在扩展组织管理和强制执行跨工作负荷的数据访问的方法。 此新的安全框架使管理员能够更灵活地配置权限。 管理员可以选择通过 OneLake 实现集中式治理，或在 SQL 分析终结点中进行基于 SQL 的精细控制。

SQL 分析端点中的访问模式

使用 SQL 分析终结点时，所选access模式确定如何强制执行数据安全性。 Fabric 支持两种独特的访问模式，每种模式根据您的运营和合规性需求提供不同的优势。

• 用户标识模式：使用 OneLake 角色和策略强制实施安全性。 在此模式下，SQL 分析终结点将已登录用户的标识传递给 OneLake，读取access完全受 OneLake 中定义的安全规则的约束。 支持对表的 SQL 级权限，确保跨 Power BI、笔记本和 Lakehouse 等工具进行一致的治理。

• 委派标识模式：通过 SQL 提供完全控制。 在此模式下，SQL 分析终结点使用 工作区或项 所有者的标识连接到 OneLake， 并且安全性由数据库中定义的 SQL 权限独占管理 。 此模型支持传统安全方法，包括 GRANT、REVOKE、自定义角色、Row-Level 安全和动态数据掩码。

每个模式都支持不同的治理模型。 了解其含义对于在 Fabric 环境中选择正确的方法至关重要。

访问模式之间的比较

下面是一个清晰简洁的对比表，重点介绍在用户身份模式与委托身份模式下设置安全性的方式，并按对象类型和数据访问策略进行分解。

OneLake 安全性中的用户标识模式

在用户标识模式下，SQL 分析终结点使用直通身份验证机制强制实施数据访问。 当用户连接到 SQL 分析终结点时，其 Entra ID 标识将传递到 OneLake，后者执行权限检查。 所有针对表的读取操作均根据 OneLake Lakehouse 中定义的安全规则进行评估，而不是依据任何 SQL 级 GRANT 或 REVOKE 语句。

通过此模式可以集中管理安全性，确保跨所有 Fabric 体验（包括 Power BI、Notebook、Lakehouse 和 SQL 分析终结点）的一致强制实施。 它专为治理框架而设计，其中访问权限应在 OneLake 中定义一次，并在各处自动生效。

在用户标识模式下：

• 表访问完全受 OneLake 安全性的管控。 忽略表上的 SQL GRANT/REVOKE 语句。

• RLS（行级安全性）、CLS（列级安全性）和 OLS（对象级安全性）均在 OneLake 体验中定义。

• 允许对非数据对象（如视图、存储过程和函数）使用 SQL 权限，从而灵活地定义自定义逻辑或面向用户的入口点来访问数据。

• SQL 分析端点不支持写操作。 所有写入都必须通过 Fabric 门户中的 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 权限应用于视图、函数和存储过程。

安全同步错误和解决方法

具有安全同步的快捷方式行为

OneLake 安全性在数据源处强制执行，因此安全同步会禁用涉及快捷方式的表和视图的所有权链式访问。 这可确保始终评估并遵循源系统权限，即使对于来自另一个数据库的查询也是如此。

因此：

• 用户必须在快捷方式的源（当前的Lakehouse或SQL 分析终结点）和数据物理驻留的目标位置上都具有有效的访问权限。

• 如果用户在任一端都缺少权限，查询将失败并出现访问错误。

• 设计引用快捷方式的应用程序或视图时，请确保在快捷方式关系的 两端 正确配置角色分配。

此设计可在 Lakehouse 边界内保持安全完整性，但如果跨 Lakehouse 的角色不一致，可能会引发访问故障的情况。

OneLake 安全性中的委托模式

在 Delegated Identity Mode 中，SQL 分析终结点在 Microsoft Fabric 中使用相同的安全模型。 安全性和权限完全在 SQL 层进行管理，而表级访问不适用于 OneLake 角色或访问策略。 当用户连接到 SQL 分析终结点并发出查询时：

• SQL 根据 SQL 权限（GRANT、REVOKE、RLS、CLS、DDM、角色等）验证访问权限。

• 如果查询获得授权，系统会继续access存储在 OneLake 中的数据。

• 此数据访问是使用 Lakehouse 或 SQL analytics 终结点所有者的 身份（也称为 item account）来执行。

在此模型中：

• 已登录用户不会传递到 OneLake。

• 假定所有访问控制都在 SQL 层处理。

• 项所有者负责在 OneLake 中拥有足够的权限来代表工作负荷读取基础文件。

由于这是委托模式，因此所有者的 SQL 权限与 OneLake access之间的任何不对齐都会导致查询失败。 此模式提供与以下功能完全兼容性：

• 所有对象级别的 SQL GRANT/REVOKE

• SQL 定义的 行级安全性、列级安全性和 动态数据掩码

• DBA 或应用程序使用的现有 T-SQL 工具和做法

如何更改 OneLake 访问模式

访问模式确定通过 SQL 分析终结点查询 OneLake 时，如何对数据访问进行身份验证和强制执行。 可以使用以下步骤在用户标识模式和委派标识模式之间切换：

1. 导航到 Fabric 工作区并打开 Lakehouse。 从右上角，从 lakehouse 切换到 SQL 分析终结点。

2. 在顶部导航中，转到 Security 选项卡，然后选择以下 OneLake 访问模式之一：

   • 用户标识 - 使用登录用户的标识。 它管理实施 OneLake 角色。

   • 委托标识 - 使用项所有者的标识;仅强制实施 SQL 权限。

3. 此时会启动一个弹出窗口以确认你的选择。 选择 “是 ”以确认更改。

在模式之间切换时的注意事项

切换到用户标识模式

• 将忽略 SQL RLS、CLS 和表级权限。

• 必须为用户配置 OneLake 角色以维持访问权限。

• 只有具有查看者权限或共享只读访问权限的用户才会受 OneLake 安全性的管理。

• 现有 SQL 角色已删除，无法恢复。

切换到委派标识模式

• 不再应用 OneLake 角色和安全策略。

• SQL 角色和安全策略变为活动状态。

• 项目所有者必须具有有效的 OneLake 访问权限，否则所有查询都可能失败。

故障排除

在 用户的标识模式下 ，可以通过 UX 验证安全同步结果。 打开 SQL Analytics 终结点，展开资源管理器中的“安全”文件夹，然后选择“数据库角色”（自定义）。 如果同步成功，你将看到带有“ols_”前缀的角色。 例如，“ols_TestRole”。 具有“ols_{alphanumericString}_rolename”的角色名称是跨快捷方式传播的其他 lakehouse 的角色。

常见安全同步错误的修复

• 如果任何角色引用已删除的表，安全同步将失败。 从角色中删除这些表，然后重新尝试安全同步。

• SPN 不能是湖屋的所有者。 确保父 Lakehouse 项由某个用户帐户拥有。

• 需要向 Lakehouse 授予所有 OneLake 安全角色成员的 Fabric 读取 权限，以便安全同步才能识别用户或组。

局限性

• 仅适用于读取者：OneLake 安全控制以 查看者身份访问数据的用户。 在其他工作区角色（管理员、成员或参与者）中的用户将绕过 OneLake 安全性，保留完整的访问权限。

• SQL 对象不继承所有权：快捷方式以表的形式显示在 SQL 分析终结点中。 直接或通过视图、存储过程和其他派生 SQL 对象访问这些表时，不会携带对象级所有权;在运行时检查所有权限，以防止绕过安全。

• 快捷方式更改触发验证停机时间：当快捷方式目标发生更改（例如重命名、URL 更新）时，数据库会在系统验证新目标时短暂进入 单用户模式 。 在此期间，查询被阻止。这些操作相当快，但有时取决于某些不同的内部流程，最多需要长达 5 分钟才能同步。

  • 创建架构快捷方式可能会导致影响验证和延迟元数据同步的已知错误。

• 延迟的权限传播：权限更改不是即时的。 在安全模式（用户标识与委托）之间切换可能需要时间才能传播，然后才能生效，但需要不到 1 分钟的时间。

• 控制平面依赖项：权限不能应用于工作区控制平面中尚不存在的用户或组。 你要么需要共享源项，要么用户必须是查看器工作区角色的成员。 请注意，完全相同的对象 ID 必须位于这两个位置。 组和该组的成员并不算作匹配项。

• 最宽松的访问权限占优：当用户属于多个组或角色时，将会采用最宽松的有效权限。示例：如果一个用户通过一个角色被拒绝权限（DENY），而通过另一个角色被授予权限（GRANT），那么授予权限（GRANT）将优先。

• Delegated 模式限制：如果源项具有不向项所有者授予完整表访问权限的 OneLake 安全策略，则快捷表上的元数据同步可能会失败。

• DENY 行为：当多个角色应用于单个快捷方式表时，权限的交集遵循 SQL Server 语义：DENY 替代 GRANT。 这可能会导致意外的访问结果。

• 预期错误条件：用户在以下情况下可能会遇到错误：

  • 已重命名或无效的快捷方式目标

    • 示例：如果删除了表的源。

  • RLS（行级安全性）配置错误

    • OneLake 不支持某些用于 RLS 筛选的表达式，这可能导致未经授权的数据访问。

    • 删除用于筛选器表达式的列后，RLS 会失效，元数据同步也会过时，直到在 OneLake 安全面板上修复 RLS 为止。

    • 对于公共预览版，我们仅支持单个表达式表。 目前不支持动态 RLS 和多表 RLS。

  • 列级安全性（CLS）限制

    • CLS 的工作原理是维护列的允许列表。 如果删除或重命名允许的列，则 CLS 策略将变为无效。

    • CLS 无效时，在 OneLake 安全面板中修复 CLS 规则之前，将阻止元数据同步。

  • 元数据或权限同步失败

    • 如果表发生更改（如重命名列），则新对象上不会复制安全性，并且你会收到显示该列不存在的 UI 错误。

• 表重命名不会保留安全策略：如果在架构级别定义了 OneLake 安全（OLS）角色，则只要表名称不变，这些角色才会生效。 重命名表会中断关联，安全策略不会自动迁移。 这可能会导致意外的数据泄露，直到策略重新应用。

• OneLake 安全角色的名称不能超过 124 个字符;否则，安全同步无法同步角色。

• 不支持OLS_角色上的用户更改，并可能导致意外行为。

• 不支持邮箱启用的安全组和通讯组。

• Lakehouse 的所有者必须是管理员、成员或贡献者工作区角色之一的成员；否则，安全性不会应用于 SQL 分析终结点。

• Lakehouse 的所有者不能是安全同步工作的服务主体。

相关内容

• 保护 OneLake 中的数据的最佳做法
• OneLake 安全访问控制模型