Power BI 行级别安全性 (RLS)
Power BI 行级别安全性 (RLS) 可用于限制给定用户的数据访问。 筛选器限制行级别的数据访问,你可以定义角色中的筛选器。 在 Power BI 服务中,有权访问工作区的用户可以访问该工作区中的语义模型。 RLS 仅限制具有“查看者”权限的用户的数据访问。 它不适用于管理员、成员或参与者。
你可以使用 Power BI 为导入到 Power BI 的数据模型配置 RLS。 还可在使用 DirectQuery(如 SQL Server)的语义模型上配置 RLS。 对于 Analysis Services 或 Azure Analysis Services 实时连接,可以在模型中配置行级安全性,而不是在 Power BI 中配置。 实时连接语义模型不会显示安全选项。
在 Power BI Desktop 中定义角色和规则
你可以在 Power BI Desktop 中定义角色和规则。 使用此编辑器,可以在使用默认下拉接口和 DAX 接口之间切换。 当你发布到 Power BI 时,还将发布角色定义。
定义安全角色的步骤:
将数据导入 Power BI Desktop 报表,或配置 DirectQuery 连接。
注意
不能在 Power BI Desktop 中为 Analysis Services 实时连接定义角色。 需要在 Analysis Services 模型中执行此操作。
从“建模”选项卡中,选择“管理角色” 。
在“管理角色”窗口中,选择“新建”以创建新角色。
在“角色”下,提供角色的名称,然后按 Enter。
注意
不能使用逗号定义角色,例如
London,ParisRole
。在“选择表”下,选择要对其应用行级别安全筛选器的表。
在“筛选数据”下,使用默认编辑器定义角色。 创建的表达式返回 true 或 false 值。
注意
并非所有 Power BI 中支持的行级别安全筛选器都可以使用默认编辑器进行定义。 限制包括目前只能使用 DAX 定义的表达式,包括 username() 或 userprincipalname() 等动态规则。 要使用这些筛选器定义角色,请切换为使用 DAX 编辑器。
可以选择“切换到 DAX 编辑器”以切换为使用 DAX 编辑器定义角色。 DAX 表达式返回值 true 或 false。 例如:
[Entity ID] = “Value”
。 DAX 编辑器具有公式自动完成功能 (IntelliSense)。 可以选择表达式框上方的选中标记来验证表达式和表达式框上方的 X 按钮来还原更改。注意
可以在此表达式内使用 username()。 请注意,username() 在 Power BI Desktop 中采用“域\用户名”格式。 在 Power BI 服务和 Power BI 报表服务器中,采用用户的用户主体名称 (UPN) 格式。 此外,在此表达式框中,即使使用的区域设置通常使用分号分隔符(例如,法语或德语),也要使用逗号分隔 DAX 函数参数。
可以通过选择“切换到默认编辑器”切换回默认编辑器。 切换接口时,任一编辑器界面中所做的全部更改都将保留(如果可行)。 使用无法在默认编辑器中定义的 DAX 编辑器定义角色时,如果尝试切换到默认编辑器,系统将提示你切换编辑器可能会导致某些信息丢失。 若要保留此信息,请选择“取消”,然后仅在 DAX 编辑器中继续编辑此角色。
注意
在此表达式框中,即使使用的区域设置通常使用分号分隔符(例如,法语或德语),也要使用逗号分隔 DAX 函数参数。
选择“保存”。
无法在 Power BI Desktop 中将用户分配到角色。 在 Power BI 服务中分配用户。 通过使用 username() 或 userprincipalname() DAX 函数并配置好正确的关系,则可以启用 Power BI Desktop 中的动态安全。
默认情况下,行级别安全性筛选采用单双向筛选器,无需考虑关系是设置为单向还是双向。 通过选择关系并勾选“在两个方向上应用安全筛选器”复选框,可手动启用具有行级别安全性的双向交叉筛选。 请注意,如果一个表参与多个双向关系,你只能为其中一个关系选择此选项。 如果你还在服务器级别实现了动态行级别安全性,则选择此选项,其中行级别安全性基于用户名或登录 ID。
有关详细信息,请参阅在 Power BI 中使用 DirectQuery 的双向交叉筛选和保护表格 BI 语义模型技术文章。
管理模型上的安全性
若要管理语义模型的安全性,请打开在 Fabric 中保存语义模型的工作区,并执行以下步骤:
在 Fabric 中,选择语义模型的“更多选项”菜单。 将鼠标悬停在语义模型名称上时,会显示此菜单。
选择“安全”。
选择“安全性”将转到“行级别安全性”页面,在此可为创建的角色添加成员。 参与者(和更高的工作区角色)将参阅“安全性”,并且可以将用户分配到角色。
使用成员
添加成员
在 Power BI 服务中,可通过键入电子邮件地址、用户姓名或安全组,向角色添加成员。 不能添加在 Power BI 中创建的组。 可将成员添加到组织的外部。
可以使用下面的组设置行级别安全性。
- 分发组
- 启用邮件的组
- Microsoft Entra 安全组
请注意,Microsoft 365 组不受支持,并且无法将其添加到任何角色。
你还可以通过角色名称或“成员”旁边的括号内的数字看到有多少成员属于该角色。
移除成员
你可以通过选择成员名称旁的 X 来移除成员。
验证 Power BI 服务中的角色
你可以通过测试角色来验证所定义的角色是否在 Power BI 服务中正常工作。
- 选择该角色旁边的“更多选项”(...)。
- 选择“以角色身份测试”。
你将被重定向到使用此语义模型从 Power BI Desktop 发布的报表(如果存在)。 仪表板不可用于使用“以角色身份测试”选项进行测试。
在页眉中,将显示正在应用的角色。 通过选择“目前的查看身份为”来测试其他角色、角色组合或特定人员。 在这里,你将看到与要测试的个人或角色相关的重要权限详细信息。 有关权限如何与 RLS 交互的详细信息,请参阅 RLS 用户体验。
通过选择页面页眉中的“查看”来测试连接到语义模型的其他报表。 你只能测试与语义模型位于同一工作区中的报表。
选择“返回到行级安全性”以返回到正常查看。
注意
“以角色身份测试”功能不适用于已启用单一登录 (SSO) 的 DirectQuery 模型。 此外,并非报表的所有方面都可以在“以角色身份测试”功能中进行验证,包括问答可视化效果、快速见解可视化效果和 Copilot。
使用 username() 或 userprincipalname() DAX 函数
可在数据集内利用 DAX 函数 username() 或 userprincipalname()。 可在 Power BI Desktop 中的表达式内使用它们。 将在 Power BI 服务内使用你发布的模型。
在 Power BI Desktop 中,username() 将返回采用域\用户格式的用户,userprincipalname() 将返回采用 user@contoso.com 格式的用户。
在 Power BI 服务中,username() 和 userprincipalname() 都将返回用户的用户主体名称 (UPN)。 这看起来类似于电子邮件地址。
在 Power BI 中使用带有 RLS 的工作区
如果将 Power BI Desktop 报表发布到 Power BI 服务中的工作区,RLS 角色将应用于分配有工作区“查看者”角色的成员。 即使向“查看者”提供语义模型生成权限,也仍将应用 RLS。 例如,如果具有生成权限的查看者使用在 Excel 中分析,则其对数据的查看会受到 RLS 的限制。 分配有“管理员”、“成员”或“参与者”的工作区成员具有语义模型编辑权限,因此 RLS 不会应用于这些成员。 如果希望 RLS 应用于工作区中的人员,则只能为他们分配“查看者”角色。 详细了解工作区中的角色。
注意事项和限制
可以看到云模型上针对行级别安全性的当前限制如下:
- 如果你以前在 Power BI 服务中定义了角色和规则,则必须在 Power BI Desktop 中重新创建它们。
- 只能在使用 Power BI Desktop 创建的语义模型上定义 RLS。 若想为使用 Excel 创建的语义模型启用 RLS,首先必须将你的文件转换为 Power BI Desktop (PBIX) 文件。 了解详细信息。
- 无法将服务主体添加到 RLS 角色。 因此,RLS 不适用于将服务主体作为最终有效标识的应用。
- 仅支持导入和 DirectQuery 连接。 在本地模型上处理到 Analysis Services 的实时连接。
- “以角色身份测试/以角色身份查看”功能不适用于已启用单一登录 (SSO) 的 DirectQuery 模型。
- “以角色身份测试”/“以角色身份查看”功能仅显示来自语义模型工作区的报表。
- “以角色身份测试”/“以角色身份查看”功能不适用于分页报表。
请记住,如果 Power BI 报表引用配置了 RLS 的行,则将显示与已删除或非现有字段相同的消息。 在这些用户看来,该报表似乎已损坏。
FAQ
问:如果我以前在 Power BI 服务中为数据集创建了角色和规则会怎么样? 如果我不执行任何操作,它们是否仍会起作用?
答:否,视觉对象将不会正确呈现。 你需要在 Power BI Desktop 中重新创建角色和规则,然后发布到 Power BI 服务。
问:我是否可以为 Analysis Services 数据源创建这些角色?
答:是,前提是你已将数据导入 Power BI Desktop 中。 如果你正在使用实时连接,那么你无法配置 Power BI 服务中的 RLS。 可在 Analysis Services 本地模型中定义 RLS。
问:我能使用 RLS 限制用户可以访问的列或度量值吗?
答:不能,如果用户有权访问特定数据行,那么他们可以查看该行的所有数据列。 若要限制对列和列元数据的访问,请考虑使用对象级安全性。
问:RLS 是否允许我隐藏详细的数据,但提供对在视觉对象中汇总的数据的访问权限?
答:否,你可以保护单个数据行,但用户始终可以查看详细信息或汇总的数据。
问:我的数据源已经定义了安全角色(例如 SQL Server 角色或 SAP BW 角色)。 这些角色与 RLS 之间有什么关系?
答:答案取决于要导入数据还是使用 DirectQuery。 如果要将数据导入 Power BI 数据集中,则不会使用数据源中的安全角色。 在这种情况下,应定义 RLS 以对在 Power BI 中进行连接的用户强制实施安全规则。 如果使用 DirectQuery,则使用数据源中的安全角色。 当用户打开报表时,Power BI 将查询发送到基础数据源,该数据源根据用户凭据将安全规则应用于数据。
问:一个用户是否可以属于多个角色?
答:一个用户可以属于多个角色,并且这些角色可以累加。 例如,如果一个用户同时属于“销售”和“营销”角色,则他们可以查看这两个角色的数据。
相关内容
- 使用 Power BI Desktop 行级别安全性 (RLS) 限制数据访问
- Power BI Desktop 中的行级别安全性 (RLS) 指南
- Power BI 实现计划:报表使用者安全性计划
- 适用于 ISV 的嵌入式方案的 RLS
是否有任何问题? 尝试咨询 Power BI 社区建议? 提出改进 Power BI 的想法