限制对 Power BI 模型数据的访问

  • 14 分钟

作为数据建模师，你可以通过创建一个或多个角色来设置 RLS。 角色在模型中具有唯一的名称，通常包含一个或多个规则。 规则通过使用数据分析表达式 (DAX) 筛选器表达式对模型表强制执行筛选器。

注意

默认情况下，数据模型没有角色。 没有角色的数据模型意味着（有权查询数据模型的）用户有权访问所有模型数据。

提示

可以定义不包含规则的角色。 在这种情况下，角色提供对所有模型表的所有行的访问权限。 此角色设置适用于可查看所有数据的管理员用户。

在 Power BI Desktop 中创建、验证和管理角色。 对于 Azure Analysis Services 或 SQL Server Analysis Services 模型，可以使用 SQL Server Data Tools (SSDT) 创建、验证和管理角色。

也可以使用 SQL Server Management Studio (SSMS) 或使用第三方工具（例如 Tabular Editor）创建和管理角色。

若要更好地了解 RLS 如何限制对数据的访问，请观看以下动画。

Animated diagram demonstrates how row-level security works for two users who each have access to specific country data.

应用星型架构设计原则

建议应用星型架构设计原则来生成包含维度表和事实数据表的模型。 设置 Power BI 来强制实施筛选维度表的规则，使模型关系能够有效地将这些筛选器传播到事实数据表，这是很常见的做法。

下图是 Adventure Works 销售分析数据模型的模型图。 它显示了一个星型架构设计，其中包含一个名为“Sales”事实表。 其他表是支持按日期、销售地区、客户、经销商、订单、产品和销售人员分析销售度量的维度表。 请注意连接所有表的模型关系。 这些关系将筛选器（直接或间接）传播到“Sales”表。

Screenshot shows a Power B I Desktop model diagram comprising the tables and relationships as described in the previous paragraph.

此模型设计支持本单元中提供的示例。

定义规则

规则表达式在行上下文中求值。 行上下文表示使用该行的列值计算每一行的表达式。 当表达式返回 TRUE 时，用户可以“看到”该行。

提示

若要了解有关行上下文的详细信息，请参阅将计算表和列添加到 Power BI Desktop 模型模块。 虽然本模块描述添加模型计算，但它包含一个介绍和描述行上下文的单元。

可以定义静态规则或动态规则。

静态规则

静态规则使用引用常量的 DAX 表达式。

请考虑将以下规则应用于“区域”表，以限制对“中西部”销售额的数据访问。


'Region'[Region] = "Midwest"

以下步骤说明 Power BI 如何强制实施规则。 该方法：

  1. 筛选“区域”表，生成一个（针对“中西部”的）可见行。

  2. 使用模型关系将“区域”表筛选器传播到“州”表，生成 14 个可见行（“中西部”区域包含 14 个州）。

  3. 使用模型关系将“州”表筛选器传播到“销售额”表，生成数千个可见行（属于“中西部”区域的州的销售数据）。

可以创建的最简单静态规则限制对所有表行的访问。 请考虑将以下规则应用于“销售详细信息”表（模型关系图中未描述）。


FALSE()

此规则可确保用户无法访问任何表数据。 如果允许销售人员查看聚合销售额结果（通过“销售额”表），但不允许其查看订单级别详细信息，那么这很有用。

定义静态规则非常简单且有效。 如果只需要创建其中一些规则，请考虑使用它们，就像 Adventure Works 公司的示例中只有六个美国区域的情况一样。 但请注意缺点：设置静态规则可能涉及大量创建和设置工作。 它还要求在新区域载入时更新和重新发布数据集。

如果要设置许多规则，并且你预计将来将添加新规则，请考虑创建动态规则。

动态规则

动态规则使用特定的 DAX 函数，这些函数返回环境值（而不是常量）。 环境值从三个特定的 DAX 函数返回：

  • USERNAME 或 USERPRINCIPALNAME – 将已经过 Power BI 身份验证的用户作为文本值返回。

  • CUSTOMDATA - 返回在连接字符串中传递的 CustomData 属性。 使用连接字符串连接到数据集的非 Power BI 报表工具（例如 Microsoft Excel）可以设置此属性。

注意

请注意，当在 Power BI Desktop 中使用时，USERNAME 函数以 DOMAIN\username 格式返回用户。 但是，在 Power BI 服务中使用时，它返回用户的用户主体名称 (UPN) 格式，如 username@adventureworks.com。 或者，可以使用 USERPRINCIPALNAME 函数，它始终返回采用用户主体名称格式的用户。

请考虑修改后的模型设计，该设计现在包括（隐藏的）AppUser 表。 AppUser 表的每一行描述用户名和区域。 “Region”表的模型关系从 AppUser 表传播筛选器。

Image shows a revised model diagram that now includes the AppUser table. This table has two columns: Region and User Name.

应用于 AppUser 表的以下规则限制对经过身份验证的用户的区域的数据访问。


'AppUser'[UserName] = USERPRINCIPALNAME()

当模型表存储用户名值时，定义动态规则非常简单且有效。 它们允许你强制实施数据驱动的 RLS 设计。 例如，当销售人员添加到 AppUser 表或从该表中删除（或分配到不同区域）时，此设计方法有效。

验证角色

创建角色时，请务必测试这些角色，以确保它们应用正确的筛选器。 对于在 Power BI Desktop 中创建的数据模型，有一个 View as 函数，用于在强制执行不同的角色且传递不同用户名值的情况下查看报表。

Screenshot shows the Power B I Desktop Modeling ribbon. The “View as” command is highlighted.

设置角色映射

必须在用户访问 Power BI 内容之前设置角色映射。 角色映射涉及将 Microsoft Entra 安全对象分配给角色。 安全对象可以是用户帐户或安全组。

提示

如果可能，最好将角色映射到安全组。 这样，映射数量会减少，你可以将组成员身份管理委托给网络管理员。

对于 Power BI Desktop 开发的模型，角色映射通常在 Power BI 服务中完成。 对于 Azure Analysis Services 或 SQL Server Analysis Services 模型，角色映射通常在 SSMS 中完成。

有关设置 RLS 的详细信息，请参阅：

对 DirectQuery 源使用单一登录 (SSO)

当数据模型包含 DirectQuery 表并且其数据源支持 SSO 时，数据源可以强制实施数据权限。 这样，数据库将强制实施 RLS，而 Power BI 数据集和报表将遵循数据源安全性。

假设 Adventure Works 为其销售运营创建了一个 Azure SQL 数据库，该数据库与 Power BI 位于同一租户中。 该数据库强制实施 RLS 以控制对各个数据库表中的行的访问。 你可以创建一个无需角色即可连接到此数据库的 DirectQuery 模型，并将其发布到 Power BI 服务。 在 Power BI 服务中设置数据源凭据时，请启用 SSO。 当报表使用者打开 Power BI 报表时，Power BI 会将其标识传递给数据源。 然后，数据源根据报表使用者的标识强制实施 RLS。

Screenshot shows the data source credentials window with the S O option enabled.

有关 Azure SQL 数据库 RLS 的信息，请参阅行级安全性。

注意

Power BI 服务不支持使用 SSO 身份验证从数据源引用 DirectQuery 表的计算表和计算列。

有关支持 SSO 的数据源的详细信息，请参阅 DirectQuery 源的单一登录 (SSO)。