限制对 Power BI 模型对象的访问

已完成

作为数据建模师,你可以考虑限制用户对 Power BI 模型对象的访问。 对象级安全性 (OLS) 可以限制对特定表和列及其元数据的访问。 通常,你会应用 OLS 来保护用于存储敏感数据(例如员工个人数据)的安全对象。

当 Power BI 强制实施 OLS 时,它不仅会限制对表和列的访问,而且还可以保护元数据。 保护元数据时,无法使用动态管理视图 (DMV) 来检索有关受保护表和列的信息。

重要

表格模型可以使用透视图来隐藏表和列(及其他对象)。 透视图定义了模型对象的可查看子集,以帮助为报表作者提供特定的焦点。 透视图旨在降低模型的复杂性,并帮助报表作者找到所需的资源。 但是,透视图不是一项安全功能,因为它们不会保护对象。 即使某个表或列对用户不可见,他们也仍可以查询该表或列。

我们以 Adventure Works 为例。 该组织有一个名为 DimEmployee 的数据仓库维度表。 该表包含存储了员工姓名、电话、电子邮件地址和工资的列。 虽然一般报表使用者可以查看员工姓名和联系详细信息,但必须禁止他们查看工资值。 只能允许高级人力资源职员查看工资值。 因此,数据建模师使用了 OLS 将工资列的访问权限授予特定的人力资源职员。

屏幕截图显示了 Employee 表的模型图视图,其中包括受限的 Salary 列。

OLS 是从 Azure Analysis Services (AAS) 和 SQL Server Analysis Services (SSAS) 继承的一项功能。 Power BI Premium 中提供了该功能,目的是与迁移到 Power BI 的模型后向兼容。 出于此原因,无法在 Power BI Desktop 中完全设置 OLS。

设置 OLS

若要设置 OLS,首先需要创建角色。 可以像设置 RLS 那样在 Power BI Desktop 中创建角色。 接下来,需要将 OLS 规则添加到角色。 Power BI Desktop 不支持此功能,因此你需要采用不同的方法。

使用 XML for Analysis (XMLA) 终结点将 OLS 规则添加到 Power BI Desktop 模型。 XMLA 终结点随 Power BI Premium 一起提供,它们提供对 Power BI 服务中 Analysis Services 引擎的访问。 读/写终结点支持数据集管理、应用程序生命周期管理、高级数据建模,等等。 可以使用表格模型脚本语言 (TMSL)PowerShell SqlServer 模块等支持 XMLA 终结点的 API 来编写脚本。 或者,可以使用客户端工具,例如 SSMS。 还可以选择使用第三方工具,例如 Tabular Editor,它是一个用于创建、维护和管理模型的开源工具。

默认情况下,所有模型表和列不受限制。 可将它们设置为“无”或“读取”。 如果设置为“无”,则与角色关联的用户无法访问该对象。 如果设置为“读取”,则与角色关联的用户可以访问该对象。 限制特定的列时,请确保表未设置为“无”。

添加 OLS 规则后,可将模型发布到 Power BI 服务。 对 RLS 使用相同的过程,以将帐户和安全组映射到角色。

注意事项

在 Power BI 报表中,当用户无权访问某个表或列时,他们会收到错误消息。 该消息指出该对象不存在。

屏幕截图显示了当报表视觉对象试图查询受限列时 Power BI Desktop 错误消息。

请认真考虑 OLS 是否为适合你的项目的解决方案。 当用户打开某个查询受限对象(为用户查询)的 Power BI 报表时,错误消息可能会令人感到困惑,导致体验受到负面影响。 在用户看来,该报表似乎已损坏。 更好的方法可能是根据不同的报表使用者要求单独创建一组模型或报表。

限制

实施 OLS 时需要注意一些限制。

不能在同一个角色中混用 RLS 和 OLS。 如果需要在同一个模型中应用 RLS 和 OLS,请单独创建专用于每种类型的角色。 此外,如果表级安全性破坏了关系链,则不能设置表级安全性。 例如,如果表 A 与 B、表 B 与 C 之间存在关系,则不能保护表 B。如果表 B 受保护,则对表 A 的查询不能传递表 A 与 B 以及表 B 与 C 之间的关系。在这种情况下,可以在表 A 与 C 之间设置单独的关系。

示意图显示了上一段中描述的关系示例。

但是,引用受保护列的模型关系将起作用,前提是该列的表不受保护。

最后,虽然无法保护度量,但引用受保护对象的度量自动受到限制。

有关详细信息,请参阅对象级安全性