限制对 Power BI 模型数据的访问
作为数据建模器，可以通过创建一个或多个角色来设置 RLS。 角色在模型中具有唯一的名称，通常包括一个或多个规则。 规则使用数据分析表达式 (DAX) 的筛选表达式来在模型表上强制实施筛选器。
注释
默认情况下，数据模型没有角色。 没有角色的数据模型意味着用户（有权查询数据模型）有权访问所有模型数据。
小窍门
可以定义不包含规则的角色。 在这种情况下，该角色提供对所有模型表的所有行的访问权限。 此角色设置适用于允许查看所有数据的管理员用户。
可以在 Power BI Desktop 中创建、验证和管理角色。 对于 Azure Analysis Services 或 SQL Server Analysis Services 模型，可以使用 SQL Server Data Tools （SSDT）创建、验证和管理角色。
还可以使用 SQL Server Management Studio（SSMS）或使用第三方工具（如 表格编辑器）创建和管理角色。
若要更好地了解 RLS 如何限制对数据的访问，请观看以下动画图像。
应用星型架构设计原则
建议应用 星型架构 设计原则来生成包含维度和事实数据表的模型。 通常，设置 Power BI 以强制实施筛选维度表的规则，从而允许 模型关系 有效地将这些筛选器传播到事实数据表。
下图是 Adventure Works 销售分析数据模型的模型关系图。 它显示了一个星型架构设计，其中包含一个名为“Sales”事实表。 其他表是支持按日期、销售区域、客户、经销商、订单、产品和销售人员分析销售度量值的维度表。 请注意连接所有表的模型关系。 这些关系将筛选器（直接或间接）传播到“Sales”表。
此模型设计支持本单元中提供的示例。
定义规则
规则表达式在行上下文中求值。 行上下文表示使用该行的列值为每个行计算表达式。 当表达式返回 TRUE 时，用户可以“查看”该行。
小窍门
若要了解有关行上下文的详细信息，请通过 向 Power BI Desktop 模型模块添加计算表和列 。 虽然本模块描述添加模型计算，但它包含一个介绍和描述行上下文的单元。
可以定义静态或动态的规则。
静态规则
静态规则使用引用常量的 DAX 表达式。
请考虑应用于 区域 表的以下规则，该规则限制对中西部销售额的数据访问。
'Region'[Region] = "Midwest"
以下步骤说明 Power BI 如何强制实施规则。 该方法：
筛选 区域 表，生成一个可见行（对于 Midwest）。
使用模型关系将 区域 表筛选器传播到 状态 表，从而生成 14 个可见行（中西部区域包含 14 个州）。
使用模型关系将 状态 表筛选器传播到 Sales 表，从而生成数千个可见行（属于中西部区域的州的销售事实）。
可以创建的最简单静态规则限制对所有表行的访问。 请考虑应用于 “销售详细信息 ”表的以下规则（模型关系图中未描述）。
FALSE()
此规则可确保用户无法访问任何表数据。 如果允许销售人员查看聚合的销售结果（来自 Sales 表），但不能查看订单级别详细信息，这可能很有用。
定义静态规则非常简单且有效。 当你需要创建少量区域时，请考虑使用它们，就像 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 表传播筛选器。
应用于 AppUser 表的以下规则限制对经过身份验证的用户的区域（s）的数据访问。
'AppUser'[UserName] = USERPRINCIPALNAME()
定义动态规则在模型表存储用户名值时简单且有效。 它们允许你强制实施数据驱动的 RLS 设计。 例如，当销售人员被添加到或从 AppUser 表中删除，或者被分配到不同的区域时，这种设计方法都能正常运作。
验证角色
创建角色时，请务必对其进行测试以确保应用正确的筛选器。 对于在 Power BI Desktop 中创建的数据模型，有一个 View as 函数，用于在强制执行不同的角色且传递不同用户名值的情况下查看报表。
设置角色映射
必须先在用户访问 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。
有关 Azure SQL 数据库 RLS 的信息，请参阅 行级别安全性。
注释
Power BI 服务不支持使用 SSO 身份验证从数据源引用 DirectQuery 表的计算表和计算列。
有关支持 SSO 的数据源的详细信息，请参阅 DirectQuery 源的单一登录（SSO）。