集成 Direct Lake 安全性

Direct Lake 安全性可确保只有经过授权的用户才能查询 OneLake 中的 Delta 表。 可以通过工作区角色管理数据访问权限。 工作区参与者、成员和管理员可以读取 OneLake 中的数据。 还可以通过项级和计算权限授予对 OneLake 中的数据的访问权限。 第三个选项是利用 OneLake 安全性在所有 Fabric 计算引擎中强制实施基于角色的精细安全性。 本文介绍如何调整权限模型、选择单一登录（SSO）或固定标识，并利用对象级安全性（OLS）和行级安全性（RLS）。 在 OneLake 安全概述中了解详细信息。

关键概念和术语

本文假设你熟悉以下概念：

• Direct Lake 使用语义模型元数据中的共享 M 表达式，通过 Power Query 数据访问函数引用数据源：用于 OneLake 的 AzureStorage.DataLake 和用于 SQL 终结点的 Sql.Database。 但是，Direct Lake 不使用这些函数来读取源 Delta 表。 它直接通过 OneLake API 读取 Delta 表。
• 为了确保仅授权用户查询数据，Direct Lake 会检查有效标识的数据访问权限。 有效标识取决于数据连接配置。 默认情况下，Direct Lake 使用 SSO（Microsoft Entra ID），并使用查询语义模型的当前用户的标识。 还可以将 Direct Lake 模型绑定到显式云连接，以提供固定标识。
• 如果通过工作区角色授予数据访问权限，则只有参与者角色（或更高版本）的成员才能读取 OneLake 中的数据。 但是，工作区查看器在 OneLake 中没有 读取 权限。 不是工作区角色成员的查看者和用户可以通过项目权限、计算权限或 OneLake 安全角色的组合来获取 读取 访问权限。
• OneLake 安全性允许工作区管理员和工作区成员角色的成员为查看器角色中的用户定义基于角色的精细安全性。 指定具有显式 读取 权限的查看器或用户可以访问的表，并排除特定的行或列。 若要详细了解 OneLake 安全角色，请参阅 OneLake 中的表安全性、 OneLake 中的列级安全性以及 OneLake 中的 RLS。

连接配置

为 Direct Lake 模型配置与其他语义模型类型相同的数据连接。 有关详细信息，请参阅 Power BI 服务中的“连接到云数据源 ”。

由于 Direct Lake 仅连接到 Fabric 数据源，因此默认 SSO（Microsoft Entra ID）配置通常有效，因此无需将语义模型绑定到显式数据连接。 此方法可降低配置复杂性并降低管理开销。

使用 SSO（Microsoft Entra ID），Direct Lake 会检查查询语义模型的当前用户是否具有 对数据的读取 访问权限。 只有具有 读取 访问权限的用户才能查询数据。 以下屏幕截图显示了使用默认 SSO 配置的 Direct Lake 模型。

使用明确的数据连接与固定标识而非 SSO 时，Direct Lake 不要求每个用户对底层数据具有 读取 权限。 如果Microsoft Entra SSO 在数据连接中保持禁用状态，固定标识的权限将确定 Direct Lake 可以访问哪些数据。

身份验证要求

Direct Lake 模型使用 Microsoft Entra ID 身份验证。 在数据连接配置中，选择 OAuth 2.0、 服务主体或 工作区标识 作为身份验证方法。 其他方法（如密钥或 SAS 身份验证）可能出现在配置 UI 中，但 Direct Lake 模型不支持。

权限要求

SQL 终结点上的 Direct Lake 和 OneLake 上的 Direct Lake 的权限要求不同。 这 是 因为 在 SQL 终 端 点 上 的 Direct Lake 依 赖 于 目 标 数 据 源 的 SQL 分 析 终 端 点，而 在 OneLake 上 的 Direct Lake 则 使用 OneLake API 进行 权 限 检 查。

SQL 终结点上的 Direct Lake

Direct Lake 在 SQL 端点上的权限检查通过 SQL 分析接口进行，以确定尝试访问数据的有效身份是否具有必要的数据访问权限。 值得注意的是，有效标识不需要有权直接在 OneLake 中读取 Delta 表。 只需有对 Fabric 工件（例如 lakehouse）的读取访问权限，以及通过其 SQL 分析终结点对表的 SELECT 权限。 这是因为 Fabric 向语义模型授予读取 Delta 表和关联的 Parquet 文件所需的权限（将 列数据加载 到内存中）。 语义模型有权定期读取 SQL 分析终结点，以检查查询用户（或固定标识）可以访问的数据。

OneLake 上的 Direct Lake

OneLake 上的 Direct Lake 不使用 SQL 分析终结点进行权限检查。 它使用 OneLake Security。 启用 OneLake 安全后，OneLake 上的 Direct Lake 使用当前用户（或固定标识）解析 OneLake 安全角色，并在目标 Fabric 工件上强制实施 OLS 和 RLS。 如果未启用 OneLake 安全性，则 OneLake 上的 Direct Lake 要求有效标识对目标 Fabric 项目具有读取和 ReadAll 权限，才能访问 OneLake 中的 Delta 表。 有关读取和 ReadAll 权限的更多信息，请参阅 OneLake 安全概述文章中的“项目权限”部分。

Direct Lake 用户

以下方案列出了最低权限要求。

有关详细信息，请参阅 语义模型权限。

Direct Lake 所有者

除了有效的标识（当前用户或固定标识），Direct Lake 还要求语义模型所有者具有对源表的 读取 访问权限，以便 Direct Lake 可以将语义模型定义为数据刷新的一部分。 无论谁刷新 Direct Lake 模型，Direct Lake 都会检查所有者的权限，以确保允许模型访问数据。 所有者的数据访问权限要求与查询模型的用户相同。

如果语义模型所有者没有所需的数据访问权限，则 Direct Lake 在框架过程中引发以下错误： We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

源表快捷方式

快捷方式是 OneLake 实体，您可以将其添加到 Fabric Lakehouse 或其他 Fabric 实体，以指向内部或外部存储位置。 在 Direct Lake 模型中，通过快捷方式添加的 Delta 表在连接的 Fabric 工件中显示为本地表，因为在通过 OneLake API 访问数据时，快捷方式是透明的。

通过 Direct Lake 通过 SQL 终结点访问快捷方式时，Direct Lake 首先会验证有效标识（当前用户或固定标识）是否可以访问语义模型中的数据源表。 对于内部快捷方式，在该检查通过后，Direct Lake 使用数据源所有者的标识通过表的 Fabric 项目的快捷方式读取 Delta 表。 数据源所有者必须在目标 OneLake 位置具有访问权限。 对于外部快捷方式，数据源所有者还需要对托管 Delta 表的外部系统进行云连接的使用权限。 有关详细信息，请参阅 OneLake 快捷方式。

Direct Lake over OneLake 具有不同的权限要求，因为 SQL Analytics 终结点不涉及。 当用户通过内部快捷方式访问另一个 OneLake 位置的数据时，有效标识（当前用户或固定标识）必须在目标位置具有权限。 有效身份必须是参与者（或更高级别）、拥有读取和 ReadAll 权限，或者隶属于授予 读取 访问权限的 OneLake 安全角色。

对象级安全性 （OLS） 和行级安全性 （RLS）

OneLake 安全和 Direct Lake 模型都支持 OLS 和 RLS。 OLS 使项目所有者和管理员能够保护特定的表或列。 RLS 可用于根据筛选器限制行级别的数据访问。 可以在 OneLake Security、Direct Lake 模型或两个位置定义 OLS 和 RLS。

OneLake 上的 Direct Lake OLS/RLS 与 OneLake 安全 OLS/RLS

OneLake 上的 Direct Lake 通过解析有效身份的 OneLake 安全角色，并根据所定义的 OLS/RLS 规则，评估对 OLS/RLS 安全对象的访问。 OneLake 安全角色的处理方式与 Direct Lake 角色相同。 如果有效标识属于 OneLake Security 和 Direct Lake 的多个角色，Direct Lake 会首先将 OneLake Security 角色进行联合，然后将结果与 Direct Lake 角色进行相交。

此表列出了 OneLake 安全和 Direct Lake 规则冲突导致的常见故障排除情况。

OLS/RLS 范围差异

在 OneLake Security 中实施 OLS 和 RLS 可以将规则应用于所有计算引擎，并确保用户的统一访问控制。 这意味着，无论是计算引擎——Lakehouse、Warehouse、Semantic Model 还是其它工件——OneLake 的安全规则都会控制用户的数据访问。 相比之下，Direct Lake 语义模型中定义的 OLS/RLS 仅适用于该模型的范围。 其他计算引擎不应用这些 Direct Lake 安全规则，当用户通过其他路径访问数据时，这些规则可能会产生不同的结果。

OneLake OLS 和语义模型元数据

语义模型元数据包括表、列、关系和其他架构元素的定义。 具有 生成 或更高权限的用户可以通过 XML for Analysis（XMLA）和 REST API 查看模型元数据。 有关详细信息，请参阅 语义模型权限。

若要使用 OneLake OLS 保护 OneLake 中的敏感表和列名称，请记住，OneLake Security 仅适用于工作区查看器角色的成员。 OneLake OLS 不会阻止贡献者（或更高权限）工作区角色的成员发现受保护的表或列，因为他们已具有对所有工作区工件的写入权限。 对 Direct Lake 模型具有 生成 或更高权限的查看器角色的成员可以通过语义模型元数据发现敏感的架构信息。 这些更高特权的查看者仍然没有数据访问权限，但可以看到受保护的表和列存在。

Direct Lake 模型可能与源项目位于同一工作区或单独的工作区中。 通过项权限向同一工作区 内部版本 （或更高）中的查看器授予对 Direct Lake 模型的访问权限。 在单独的工作区中，用户可能是参与者（或更高）或拥有构建（或更高）项权限以访问模型元数据。

OneLake OLS 和 Git 集成

Git 集成使开发人员能够将其应用程序生命周期管理 （ALM） 进程集成到 Fabric 平台中。 Git 存储库保留工作区结构，包括所有受支持的项目。 开发人员可以完全了解 Git 存储库中所有项的元数据。 Direct Lake 模型元数据允许他们查看安全表或列是否存在，即使它们无权访问另一个工作区中的目标数据源。 有关详细信息，请参阅什么是 Microsoft Fabric Git 集成？

注意事项和限制

请考虑这些 Direct Lake 安全限制。

• 为工作区查看者角色分配 OneLake 安全角色，以授予对源 Fabric 项目的 读取 访问权限。 如果源项目具有另一个 Fabric 项目的快捷方式，则用户还需要对每个快捷方式的目标 Fabric 项目具有 读取 访问权限。
• 使用固定标识将用户与源 Fabric 项目隔离开来。 将 Direct Lake 模型绑定到云连接。 使 SSO 在云连接上保持禁用状态，以使用固定标识进行刷新和查询。
• 依赖于源工件上 Fabric OneLake 安全性的 Direct Lake 语义模型不支持备份操作。
• 如果源 Fabric 工件依赖于 OneLake 安全 RLS，则 Direct Lake 模型中不支持双向关系。
• 在公共预览版期间，OneLake 安全性仅支持单个表上的静态 RLS。
• 在公测阶段，OneLake 的安全性不支持动态定义或复杂的角色配置，例如在相关表之间组合多个 OLS 和 RLS 角色。
• 将 OneLake 安全 RLS 和 OLS 权限合并为每个用户的一个角色，而不是分配多个角色。
• 如果 OneLake 的安全配置发生更改（例如，由于目标工件的快捷方式更改），请刷新访问该工件的 OneLake 模型上的 Direct Lake。 如果启用了自动同步，服务通常会自动刷新它们。 否则，请手动刷新模型。
• 如果 Lakehouse 具有 OneLake 的安全保障：
  • 默认情况下，SQL 分析终结点是 Lakehouse 所有者的固定标识，因此 SQL 分析终结点 OneLake 安全性与所有者相同（没有限制）。 除非添加了额外的 SQL 粒度访问角色，否则 SQL 上的 Direct Lake 会继续使用 Direct Lake。
  • SQL 分析终结点可以更改为 SSO。 发生这种情况时，OneLake 安全角色将添加为 SQL 精细访问控制规则，并阻止用户直接在 SQL 分析终结点上编辑它们。 此时，SQL 上的 Direct Lake 会 100% 切换到 DirectQuery。