Power BI 行级安全性（RLS）：完整教程

在Power BI 中，行级安全性（RLS）可根据筛选器控制用户可查看的数据行。该功能在多位用户共享同一报告、且需按其角色或部门获得个性化视图的场景中尤为有用。

在本教程中，我将带您深入、务实地理解 RLS，包括其静态与动态配置、动手实现步骤、企业级高级技巧，以及我总结的常见坑点与规避方法。我还会分享最佳实践，并将 RLS 与其他安全模型进行对比。

如果您刚开始使用 Power BI，建议先查看我们的Power BI 基础技能路径，帮助您掌握所需的核心技能。

什么是行级安全性？

行级安全性（RLS）是 Power BI 中的一项安全功能，基于查看报告的用户身份来限制其对表中行的访问。与为不同用户组复制多份报告不同，RLS 可在数据层应用筛选，从而使每位用户仅能看到其被允许查看的数据。

这对于保护数据机密性与完整性至关重要，尤其在涉及敏感或专有信息的场景中。RLS 在Power BI 数据模型内运行，确保未经授权的用户即便通过切片器或下钻等间接方式也无法访问受限数据。

角色与筛选器

RLS 的实现基于三个核心要素：

• 角色：具备已定义访问规则的逻辑分组。
• DAX 筛选器：用于确定各角色可访问哪些数据的表达式。
• 用户分配：配置哪些用户或用户组归属哪些角色。

这些要素协同工作，在返回结果前将每次查询与访问条件进行评估。

使用场景

RLS 可广泛适用于众多行业与场景，包括：

• 销售区域：销售经理仅查看其所属区域的业绩数据。
• 医疗健康：医生仅访问分配给其的病患记录。
• 多租户 SaaS：客户在共享仪表板中仅查看其组织的数据。

这种安全模型可在最小化数据集重复与运维开销的同时确保共享数据集的安全。

静态与动态 RLS 架构

行级安全性可分为两类：静态与动态。

我已在下表中概括二者差异：

提示：小型、固定的用户组可使用静态 RLS；增长型或大规模环境建议使用动态 RLS。

下面我将分别演示静态与动态的实现示例。

静态 RLS 的实现

静态 RLS 通过创建带有硬编码 DAX 筛选器的角色来实现。每个角色对应某一特定群体或分段，如地理区域或部门。

实现静态 RLS 的一般步骤如下：

1. 创建一个角色，例如命名为 "Region_East"。
2. 为该角色应用筛选器，如 [Region] = "East"。
3. 在 Power BI 服务中将特定用户分配给该角色。

动态 RLS 的实现

动态 RLS 通过将 USERNAME() 或 USERPRINCIPALNAME() 等函数与映射表结合，依据用户身份动态筛选数据。

实现动态 RLS 的一般步骤如下：

1. 创建一个将用户与访问级别关联的映射表，即安全表。该表应包含用户邮箱、其可访问的区域以及姓名等列。
2. 编写 DAX 筛选，如：[Region] = RELATED(UserRegion[Region])
3. 对该表应用筛选：UserRegion[Email] = USERPRINCIPALNAME()

在 Power BI Desktop 中设置行级安全性

下面通过一个简单的销售数据集，快速演示如何设置静态行级安全性。

1. 使用 Python 创建示例数据集

为测试 RLS，使用 Python 创建一个示例数据集：

import pandas as pd

data = {
    'Salesperson': ['Alice', 'Bob', 'Charlie', 'Alice', 'Bob', 'Charlie'],
    'Region': ['East', 'West', 'South', 'East', 'West', 'South'],
    'SalesAmount': [15000, 20000, 18000, 17000, 21000, 16000],
    'Email': ['[email protected]', '[email protected]', '[email protected]'] * 2,
    'Date': pd.date_range(start='2025-01-01', periods=6, freq='M')
}

sales_df = pd.DataFrame(data)
sales_df.to_csv('sample_sales_data.csv', index=False)技术支持

2. 导入至 Power BI 并创建参考可视化

1. 打开 Power BI Desktop。
2. 转到 Home > Get Data > Text/CSV。
3. 选择 sample_sales_data.csv 文件。

4. 将数据加载到模型中。

确保数据类型正确，并确认 Email 列与登录身份格式一致（通常为邮箱）。

5. 在 Power BI 中创建一个基本的堆积柱形图。将 Date 字段拖至 X 轴，将 SalesAmount 拖至 Y 轴。

您的图表应类似如下所示：

关于 Power BI 的更多用法，可参阅我们的速查表，如下图所示。

3. 创建角色

接下来，创建一些角色以定义不同角色可具备的权限。

1. 转到 Modeling > Manage Roles。

2. 点击 Create 并为角色命名，例如 SalesRegionStatic。
3. 选择相关的表。
4. 输入 DAX 筛选表达式：

[Email] = “[email protected]”技术支持

界面应类似如下：

5. 保存并关闭对话框。

如果更改已成功保存，将出现如下所示的绿色栏通知。

4. 测试角色

1. 转到 Modeling > View as Roles。

2. 选择我们先前创建的 SalesRegionStatic 角色。

3. 查看按该身份筛选后的报告可视化。

如下面的图片所示，图表已被筛选为仅显示邮箱为“[email protected]”的数据。

这有助于在部署前进行本地验证。

在 Power BI 服务中分配用户与管理角色

在 Power BI Desktop 中设置并测试好 RLS 角色后，下一步将报告发布到 Power BI 服务。这样您就可以为各角色分配特定用户或安全组，确保在共享报告时强制执行访问控制。

1. 将报告发布到 Power BI 服务

1. 在 Power BI Desktop 中，点击 Home > Publish > To Power BI。
2. 在 Power BI 服务中选择目标工作区。

3. 发布后，登录 Power BI 服务： https://app.powerbi.com。

以下是我在网页版 Power BI 服务中的界面示例。

发布是配置 RLS 角色分配的前提条件，因为在 Power BI Desktop 中定义的角色会随数据集一同发布。

2. 访问安全设置

1. 为相关语义模型选择“更多选项”。点击数据集旁的省略号（...），选择 Security。
2. 您将看到在 Power BI Desktop 中定义的角色列表。

在此处，可为每个角色分配用户或 Azure Active Directory（AAD）组。

3. 分配个人用户与安全组

要分配用户，请在目标角色下的文本框中输入其完整邮箱地址，按回车并点击 Add。

要分配 AAD 组，请使用组名（如 Sales_Region_East 或 Finance_Team）。请确保该组已在 Azure Active Directory 中定义并维护。

4. 验证已分配的访问

在分配用户或组后，请花时间验证相应群体是否看到正确的数据。

每个人仅能看到由与其角色关联的 DAX 表达式筛选后的数据。用户不会直接收到角色分配通知，因此您可能需要在验证完成后再沟通访问说明。

5. 在 Power BI 服务中测试角色分配

1. 在同一页面，点击先前定义的 RLS 名称，点开省略号（...），然后选择 Test as role。

2. Power BI 将打开报告的只读版本，仅显示所选角色被允许的数据。

对于动态 RLS，您还可以模拟特定用户的视图：

• 点击 Test as role。
• 输入某位用户的邮箱以模拟其体验。

这有助于确保您的动态筛选（例如基于 USERPRINCIPALNAME()）运行正常。

高级实现技巧

通过一些高级技巧，您可以将 RLS 更深入地集成进 Power BI 的工作流。以下是值得注意的做法：

1. 安全组集成

使用 Azure Active Directory（AAD）安全组，可将访问权限赋予整个用户组，而非单个用户。

这在员工经常加入或离开团队的企业环境中尤为实用，因为它免去了在 Power BI 中手动更新权限的工作。

2. 复杂数据模型的考量

在构建大规模数据模型时，需确保 RLS 不会干扰关系及筛选传播。

一些建议如下：

• 采用星型架构，避免复杂连接。
• 除非必要，尽量少用双向关系。
• 避免产生歧义的关系，以免导致错误筛选。
• 通过减少在重度筛选表中的计算列来优化性能。

3. 混合方法

混合方法将静态与动态技术相结合。

例如，您可以定义静态角色以授予某业务单元的访问权限，并在该角色内基于个人邮箱或用户名应用动态筛选。此法可实现分层且灵活的安全逻辑。

4. 对象级安全（OLS）

对象级安全可对特定角色隐藏整张表或某些列。它与 RLS 互补，提供额外的数据保护层。OLS 可用于薪酬或医疗等敏感字段。

测试与验证策略

1. Desktop 测试

Power BI Desktop 提供“View as”角色功能来模拟不同用户视图。该功能帮助报表开发者在发布前验证行级安全逻辑是否正常工作。

如何在 Power BI Desktop 中测试 RLS：

1. 点击 Modeling 选项卡。
2. 在功能区选择 View as。
3. 选择您配置的角色（如 SalesRegionStatic）。
4. 如使用动态 RLS，可选填测试用户名/邮箱。
5. 点击 OK 并检查可视化的筛选情况。

这会模拟分配到该角色的用户查看报告时的效果。对依赖 USERPRINCIPALNAME() 等 DAX 函数的动态 RLS 测试尤为有用。

2. 服务端测试

发布到 Power BI 服务后，应在云端环境再次测试 RLS 以确保准确性。

如何在 Power BI 服务中测试 RLS：

1. 在工作区中导航到数据集。
2. 点击数据集旁的 ... > Security。
3. 选择一个角色 > 点击 Test as role。
4. 使用“Test as specific user”选项来模拟动态 RLS 筛选。

这样可确保对真实用户的筛选表现符合预期。

3. 关键验证提示

在验证时，可考虑使用测试账号或服务身份来模拟真实使用。还应定期审查关键可视对象（如表格与图表）上的所有筛选。

务必彻底检查切片器、穿透式分析（drillthrough）与书签，确保不会泄露未授权数据。

常见陷阱与解决方案

实施 RLS 可能会遇到一些问题，以下是常见问题及其解决方法。

1. 发布后问题

发布到 Power BI 服务后，部分用户发现 RLS 与在 Power BI Desktop 中的表现不一致。

解决方案：

• 在修改角色或筛选器后，确保重新发布报告。
• 确认 USERPRINCIPALNAME() 使用的邮箱与数据集中登录域格式一致。

2. 工作区角色冲突

具有某些工作区角色（Admin、Member）的用户可能会无意间绕过 RLS。

解决方案：

• 将用户在工作区中设为 Viewer 以强制执行 RLS 规则。
• 除非出于内容开发需要，避免授予 Contributor/Admin 权限。

3. DAX 函数限制

误用 USERNAME() 与 USERPRINCIPALNAME() 等 DAX 函数是常见坑点：

• USERNAME() 在 Desktop 测试时可能返回本地账户名而非邮箱。
• 为与云端身份行为保持一致，建议使用 USERPRINCIPALNAME()。

提示：

• 添加包含示例邮箱的参考表，便于本地测试。
• 在 DAX 中使用条件逻辑或默认值，避免筛选失败。

4. DirectQuery 与 SSO 挑战

将动态 RLS 用于 DirectQuery 源时需格外注意，尤其与单点登录（SSO）搭配使用时。

常见问题：

• 网关配置不当会阻断用户模拟。
• 若 SPN 配置错误，使用 Kerberos 的 SSO 设置可能失败。

解决方案：

• 参考 Microsoft 关于 Power BI 网关 SSO 的文档。
• 与 IT 与基础设施团队密切协作，启用 Kerberos 委派。

为公开访问移除或禁用 RLS

某些情况下需要临时（如演示或开放式仪表板）或永久（如与外部方共享数据）移除 RLS。这时需谨慎设置可见性，以防出现意外泄露。

在 Power BI Desktop 中禁用 RLS

禁用 RLS 的步骤：

1. 在 Power BI Desktop 中打开报告。
2. 导航至 Modeling > Manage Roles。
3. 选择并删除所有角色，或禁用其筛选。
4. 保存并重新将数据集发布到 Power BI 服务。

移除后，若无其他安全措施，所有用户均可访问完整数据集。

在无 RLS 情况下的安全共享

若 RLS 不可行或非必要，可采用以下做法维持数据安全：

• 使用数据集级权限：仅与受信用户共享数据集或报告，并合理使用工作区权限（Viewer、Contributor）。
• 避免“发布到 Web”：“Publish to Web” 会移除所有安全控制。请改用“Embed for organization”或 Power BI Embedded 进行安全的类公开共享。

移除 RLS 并不意味着移除全部安全性。请利用 Power BI 服务中的其他访问控制与共享功能，确保负责任地传播数据。

企业部署最佳实践

要在企业范围内成功部署行级安全性，需要周密规划、可扩展架构与恰当治理。以下从不同维度概述 RLS 实施的成熟做法。

1. 数据建模

良好的数据模型有助于构建高效且易维护的 RLS 配置。

建议：

• 遵循星型架构，明确事实表与维表之间的关系。
• 避免不必要的双向关系，以免引入筛选歧义。

2. 角色管理

集中且一致地管理 RLS 角色，有助于减少错误并提升协作。

建议：

• 维护角色定义文档，记录 RLS 逻辑与 DAX 表达式。
• 使用具描述性的角色名称（如“Region_East_Sales”）以避免混淆。

3. 性能优化

RLS 可能影响报告性能，尤其在筛选复杂或数据量庞大时。

建议：

• 尽可能通过汇总表进行预聚合。
• 在 RLS 逻辑中尽量少用计算列。
• 在源系统中使用索引与优化查询以支持 DirectQuery 场景。

RLS 与其他安全模型对比

现在将行级安全性（RLS）与其他安全功能（尤其是对象级安全 OLS）做一对比。

1. 细粒度与使用场景

RLS 可对数据的单行实施访问控制，适合按用户身份、地域、部门或业务单元进行筛选。相对地，OLS 控制对整张表或某些列的访问，适用于隐藏敏感的财务或人力信息（如薪资列）。

2. 实施方式与动态适配

RLS 可在 Power BI Desktop 内通过角色上的 DAX 筛选轻松实现，规则可为静态（硬编码）或动态（基于用户的逻辑）。OLS 则通过 Tabular Editor 或 XMLA 端点进行配置，且需要高级容量工作区或在 Analysis Services 中托管的 Power BI 数据集。

我将对比要点汇总在下表：

结论

总之，Power BI 中的行级安全性（RLS）是确保平台内数据治理的关键手段。它使组织能够在单一报告或仪表板中提供个性化且安全的分析体验，而不牺牲底层数据的机密性或完整性。

安全性在数据管理与治理中的重要性与日俱增，这也是使用 Power BI 时的重要方面。若需更深入的 Power BI 资料，请查看我们的Power BI 资产部署与维护课程或Power BI 报表课程。若想延伸阅读，亦可参考我们的Power BI 层级与Power BI 仪表板指南。