通过

Power BI 实现计划：报表使用者安全性计划

  • 项目

备注

本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。

此安全性计划文章介绍面向只读使用者的策略。 重点介绍报表和应用的查看者权限，以及如何强制实施数据安全性。 主要面向以下对象：

  • Power BI 管理员：负责监督组织的 Power BI 的管理员。
  • 卓越中心、IT 和 BI 团队：还负责监督 Power BI 的团队。 他们可能需要与 Power BI 管理员、信息安全团队和其他相关团队协作。
  • 内容创建者和所有者：需要创建、发布、保护和管理其他用户使用的内容的自助式 BI 创建者。

本系列文章旨在详细阐述 Power BI 安全白皮书中的内容。 Power BI 安全白皮书侧重于身份验证、数据驻留和网络隔离等关键技术主题，本系列文章的主要目标则是介绍用于帮助规划安全和隐私的注意事项和决策。

在组织中，许多用户被分类为“使用者”。 使用者查看其他用户已创建和发布的内容。 使用者是本文的重点。 有关侧重于内容创建者和所有者的安全性计划，请参阅内容创建者安全性计划一文。

若要从本文得到最大收获，了解术语“共享”和“分发”在 Power BI 上下文中的含义会很有帮助。

“共享”是指一名用户授予另一名用户（或一组用户）对特定内容项的访问权限。 Power BI 服务中的共享功能范围仅限于一个项。 它往往发生在彼此了解并密切合作的个人之间。

“分发”是指将内容交付给其他用户（称为收件人）。 它通常涉及多个团队中的大量用户。 收件人可能没有显式请求内容，但公认他们需要该内容才能履行其职责。 使用分发的内容的接收方可能知道也可能不知道内容的原始创建者。 因此，作为一个概念，分发比共享更为正式。

与其他人交谈时，确定他们是在笼统地使用术语“共享”，还是按字面意思使用。 术语“共享”的使用可以用两种方式来解释。

  • 术语“共享”通常以与同事共享内容相关的笼统方式使用。 本文将介绍几种用于交付只读内容的技术。
  • “共享”也是 Power BI 中的一项特定功能。 此功能可授予用户或组对单个项的访问权限。 本文介绍了共享链接和直接访问共享。

重要

Power BI 管理员角色已重命名。 该角色的新名称为 Fabric 管理员。

面向只读使用者的策略

在 Power BI 服务中，使用者如果拥有以下两种权限，则可以查看报表或仪表板：

  • 查看包含可视化效果（例如报表或仪表板）的 Power BI 项目。
  • 读取基础数据（语义模型或其他源）。

可以使用不同的技术向使用者提供只读访问权限。 自助服务内容创建者使用的常用技术包括：

Power BI 应用和 Power BI 工作区查看者角色选项涉及管理一组项的权限。 这两种每项权限技术涉及管理单个项的权限。

提示

通常，对于大多数使用者而言，最佳做法是使用 Power BI 应用。 有时，工作区查看者角色也可能是合适的。 Power BI 应用和工作区查看者角色都允许管理许多项的权限，并应尽量使用。 管理单个项的权限可能十分繁琐、耗时且容易出错。 相比之下，管理一组项可减少维护并提高准确性。

查看某个项的安全性设置时，可能看到其权限满足以下条件之一：

  • 从工作区或应用继承。
  • 直接应用于项。

在以下屏幕截图中，显示报表的“直接访问”权限。 在此实例中，工作区管理员和成员角色分别分配给一个组。 报表将显示这些角色，因为报表级别的访问权限是从工作区继承的。 还有一位用户具有直接应用于报表的读取权限。

Power BI 服务中报表的直接访问权限的屏幕截图。

为只读使用者选择的策略可能有所不同。 它应基于单个解决方案、对解决方案管理者的偏好或使用者的需求。 本节的其余部分介绍何时考虑使用每种可用技术。

清单 - 在创建有关如何向只读使用者提供内容的策略时，关键决策和操作包括：

  • 评估面向只读使用者的现有策略：验证内容当前是如何分发和共享给使用者的。 确定是否有改进机会。
  • 确定面向只读使用者的策略：考虑针对使用应用权限、工作区角色或每项权限的首选项。 如果需要进行更改以满足这些首选项，请创建改进计划。

Power BI 应用权限

Power BI 应用向使用者提供报表、仪表板和工作簿的集合。 应用可为使用者提供最佳用户体验，因为：

  • 该应用的导航窗格提供简单且直观的用户体验。 与直接在工作区中访问内容相比，这是一种更好的体验。
  • 内容可以在应用的导航窗格中按逻辑组织成多个部分（这些部分类似于文件夹）。
  • 使用者只能访问已显式包含在应用中供其受众使用的特定项。
  • 可将指向其他信息、文档或其他内容的链接添加到其受众的导航窗格中。
  • 有一个内置的“请求访问”工作流。

注意

本文中对应用的所有引用均指 Power BI 应用。 它与 Power Apps 的概念不同。 这也是一个与 Power BI 移动应用程序不同的概念。 本部分重点介绍组织应用而非模板应用。

可以为每个工作区都创建一个应用，作为分发部分或全部工作区内容的正式方式。 应用是一种在组织内广泛分发内容的好方法，尤其是对于你不认识或未密切协作的用户。

提示

有关使用 Power BI 应用进行广泛内容分发的详细信息，请参阅企业 BI 使用方案。 建议需要分发内容的内容创建者考虑将创建应用作为其首选。

你独立于工作区角色单独管理应用权限。 权限分离有两个好处。 它鼓励：

  • 向内容创建者授予工作区访问权限。 它包括积极协作处理内容的用户，如语义模型创建者、报表创建者和测试人员。
  • 向使用者授予应用权限。 与工作区权限不同，应用权限始终为只读（或无）。

所有具有工作区访问权限的用户都可以自动查看该应用（当已经为该工作区发布了 Power BI 应用时）。 由于此行为，可以在概念上将工作区角色视为由每个应用受众继承。 一些具有工作区访问权限的用户也可能会更新 Power BI 应用，具体取决于其分配的工作区角色。

提示

有关工作区访问权限的详细信息，请参阅内容创建者安全性计划一文。

在以下情况下，使用应用将内容分发给只读使用者是最佳选择：

  • 你希望用户只能查看对该受众可见的特定项（而不是基础工作区内的所有项）。
  • 你想要独立于工作区单独管理应用的只读权限。
  • 你希望只读用户的权限管理比每项权限更简单。
  • 你想要确保对使用者（当他们对基础语义模型具有只读权限时）强制实施行级别安全性。
  • 你想要确保使用者在重新发布应用之前无法查看新的和更改后的报表。

虽然在重新发布应用之前，该应用的用户确实看不到对报表和仪表板所做的更改，但有两个注意事项需要注意。

  • 即时语义模型更改：语义模型更改始终立即生效。 例如，如果对工作区中的语义模型引入了中断性变更，可能会无意中导致报表变得不稳定（即使它们尚未在应用中重新发布）。 可以通过两种方法降低这种风险：首先，在 Power BI Desktop（与工作区分离）中完成所有开发工作。 其次，使用单独的工作区进行开发和测试，以隔离生产应用。 （（可选）通过使用部署管道，可以对从开发到测试和生产的部署工作区内容实现更高级别的控制。）
  • 内容和权限一起发布：发布应用时，其权限会与内容同时发布。 例如，可以在工作区中报告尚未完成、未完全测试或未获批准的更改。 因此，不能仅仅为了更新权限而重新发布应用。 若要缓解此风险，请将应用权限分配给安全组，并在授予应用权限时使用安全组成员身份（而不是单个用户）。 避免仅仅为了应用权限更改而重新发布应用。

应用受众

Power BI 服务中的每个工作区只能有一个 Power BI 应用。 但你可以在该应用中创建一个或多个受众。 请考虑以下场景。

  • 你有五个销售报表，这些报表已分发给全球销售组织中的许多用户。
  • 在应用中为销售代表定义了一个受众。 此受众可以查看其中三个报表。
  • 在应用中为销售领导力团队定义了另一个受众。 此受众可以查看这五个报表，包括销售代表无法查看的两个报表。

此“组合和匹配”内容和受众的功能具有以下优势。

  • 某些报表可供多个受众查看。 因此，创建多个受众就消除了跨不同工作区复制内容的需要。
  • 某些报表应该仅供一个受众使用。 因此，该受众的内容可与其他相关内容驻留在同一工作区中。

以下屏幕截图显示一个包含两个受众的应用：“销售领导力”和“销售代表”。 “管理受众访问权限”窗格为两个安全组提供对“销售领导力”受众群体的访问权限：“销售领导力 - 北美”和“销售领导力 - 欧洲”。 “销售领导力”受众群体的屏幕截图中显示的“毛利率分析”报表不适用于“销售代表”受众群体。

Power BI 服务中应用受众设置的屏幕截图。

注意

有时会使用“受众群体”一词。 它不是对安全组使用的直接引用。 它包括将在 Power BI 应用中查看内容集合的目标受众成员。 虽然可以将单个用户分配给受众，但最佳做法是尽量分配安全组、Microsoft 365 组或通讯组。 有关详细信息，请参阅租户级安全性计划一文中的组使用策略。

管理应用权限时，可以在“直接访问”页上查看每个受众的成员。 还可以在“所有”受众下看到列出了工作区角色的用户。 无法从“直接访问”页更新应用权限。 而是必须重新发布应用。 但是，当应用存在打开的访问请求时，可以从“待定”页更新应用权限。

提示

使用应用受众的主要用例是为不同的用户组定义特定权限。 但是，可以在使用受众时发挥一些创意。 一个用户可以是多个受众的成员，每个受众都作为辅助菜单集显示给应用的查看者。 例如，可以创建名为“从此处开始”的受众，其中包含有关如何使用应用、与谁联系、如何提供反馈以及如何获取帮助的信息。 你也可以创建名为“KPI 定义”的受众，其中包含数据字典。 提供此类信息可以帮助新用户并改进解决方案采用工作。

应用权限选项

当创建（或重新发布）应用时，每个受众都有“管理受众访问权限”窗格。 在该窗格中，可以使用以下权限。

  • 授予针对对象的访问权限：对于每个受众，可以向单个用户和组授予访问权限。 当“将应用发布到整个组织”租户设置启用时，可以将应用发布到整个组织，并且该应用不会自动安装。 建议尽量将组分配给受众，因为添加或删除用户涉及重新发布应用。 具有工作区访问权限的每个人都自动有权查看或更新应用，具体取决于其工作区角色。
  • 语义模型权限：可以在发布应用时授予两种类型的语义模型权限：
    • 语义模型重新共享：启用后，将向应用用户授予与其他人重新共享基础语义模型的权限。 如果基础语义模型可以很容易地与任何人重新共享，启用此选项是有意义的。 建议先获得来自语义模型所有者的批准，然后再向应用受众授予重新共享权限。
    • 语义模型生成：启用后，将向应用用户授予对语义模型的生成权限。 利用生成权限，用户可以新建报表、从报表中导出基础数据等。 建议先获得来自语义模型所有者的批准，然后再向应用受众授予重新共享权限。

在发布应用时，用于添加语义模型“重新共享”或“生成”权限的功能很方便。 但是，建议考虑单独管理应用权限和语义模型权限。 原因如下。

  • 共享语义模型可能位于单独的工作区中：如果将语义模型发布到与应用不同的工作区，将需要直接管理其权限。 在发布应用时，用于添加“读取”、“生成”或“重新共享”权限的功能仅适用于与应用位于同一工作区的语义模型。 因此，建议你养成单独管理语义模型权限的习惯。
  • 语义模型权限是单独管理的：如果删除或更改某个应用的权限，则该操作只影响该应用。 它不会自动删除之前分配的任何语义模型权限。 这样，你就可以将应用权限和语义模型权限视为“分离”。 当语义模型权限发生更改或需要删除时，你需要独立于应用直接管理语义模型。
  • 应控制语义模型权限：通过应用授予语义模型权限，这将移除语义模型所有者的控制权。 授予“重新共享”权限取决于选择重新共享语义模型的用户的正确判断。 如果允许重新共享，则内部治理或安全准则可能变得更加难以管理。
  • 使用者和创作者具有不同的目标：通常，组织中的内容使用者比创作者要多得多。 根据最小特权原则，使用者只需要对基础语义模型的“读取”权限。 除非他们打算创建新报表，否则不需要“生成”权限。

提示

有关何时使用单独的数据工作区和报告工作区的详细信息，请参阅工作区级规划一文。

应用预安装权限

发布 Power BI 应用后，用户通常需要先安装该应用才能将其打开。 用户可以从 Power BI 服务的“应用”页或使用他们从其他用户收到的链接安装应用。 当他们被包含在应用的至少一个受众中时，他们将能够找到（并安装）该应用。

安装应用的另一种方法是将其推送给应用使用者。 它将预安装应用，使其自动显示在 Power BI 服务的“应用”页中。 此方法对使用者来说很方便，因为他们不需要查找和安装应用。 但是，预安装的应用可能会成为用户的烦恼，因为他们可能会受不了太多与其无关的应用。

将应用推送给最终用户租户设置控制谁可以自动安装应用。 建议使用此功能，因为它对用户来说很方便。 不过，还建议你让内容创建者了解何时使用它，以免过度使用。

提示

发布应用时，如果选择“自动安装应用”选项，则无法将受众设置为整个组织（如果已启用“将应用推送给最终用户”租户设置）。

清单 - 当为内容查看者创建使用应用的策略时，关键决策和操作包括：

  • 确定应用使用策略：定义针对如何使用应用的首选项。 确保它符合面向只读使用者的总体策略。
  • 决定谁可以将应用发布到整个组织：决定哪些报表创建者可以将应用发布到整个组织。 设置“将应用发布到整个组织”租户设置，以符合此决定。
  • 决定谁可以将应用推送给最终用户：决定哪些 Power BI 报表创建者可以预安装应用。 设置“将应用推送给最终用户”租户设置，以符合此决定。
  • 为内容创建者创建和发布指南：为内容创建者提供文档和培训。 包括有关如何最有效地使用应用的要求和首选项。
  • 确定如何处理应用访问请求：确保有一个流程能够及时分配联系人和处理应用访问请求。

工作区查看者角色

正如工作区规划一文中所述，工作区的主要目的是协作。 应向工作区协作者（例如语义模型创建者、报表创建者和测试人员）分配以下三个角色之一：参与者、成员或管理员。内容创建者安全性计划一文中介绍了这些角色。

可以将工作区“查看者”角色分配给使用者。 允许使用者直接在工作区中访问内容，对于密切协作的小型团队和非正式团队来说，这很有意义。

在以下情况下，允许使用者直接访问工作区内容是一个不错的选择：

  • 具有单独权限的应用的形式不是必需的。
  • 允许查看者查看存储在工作区中的所有项。
  • 你需要比每项权限更简单的权限管理。
  • 工作区用户还可以查看应用（当为工作区发布应用时）。
  • 目的是让查看者在将内容发布到应用之前对其进行审查。

下面是一些支持工作区查看者的建议。

  • 组织每个工作区中的内容，以便报表使用者可以轻松找到这些项，使其与安全性保持一致。 按主题领域或项目划分的工作区组织通常效果很好。
  • 将开发和测试内容与生产内容分开，以使查看者无法访问正在进行的工作项。
  • 如果预计有许多访问请求需要处理，请使用应用（或在适当的时候使用每项权限）。 工作区没有“请求访问”工作流。

清单 - 当为内容查看者创建使用工作区的策略时，关键决策和操作包括：

  • 确定使用工作区查看者角色的策略：定义针对如何使用使用者工作区的首选项。 确保它符合面向只读使用者的总体策略。
  • 为内容创建者创建和发布指南：为内容创建者提供文档和培训。 包括有关如何最有效地使用工作区权限的要求和首选项。

每项权限

单个项共享授予对单个项的权限。 经验不足的内容创建者通常使用此方法作为主要共享方法，因为共享命令在 Power BI 服务中突出显示。 因此，务必要让内容创建者了解不同的共享选项，包括何时使用应用权限而不是工作区角色。

在以下情况下，每项权限是一个不错的选择：

  • 你想要提供针对一个项（报表或仪表板）的只读访问权限。
  • 你不希望使用者查看发布到工作区的所有内容。
  • 你不希望使用者查看发布给应用受众的所有内容。

谨慎使用每项权限，因为共享会授予对单个项的“读取”权限。 在某种程度上，可以将每项权限视为对工作区角色或应用权限的替代。

提示

建议尽量使用应用权限。 接下来，考虑使用工作区角色来启用直接工作区访问。 最后，当满足上述条件时，请使用每项权限。 应用权限和工作区角色都指定内容集合（而不是单个项）的安全性，这是一种更好的安全做法。

使用每项权限共享多个项可能既繁琐又容易出错，特别是在与单个用户而不是组共享时。 考虑这种情况：你有 40 个报表，你已使用同事的个人用户帐户与其共享。 当一位同事调到另一个部门时，你需要撤销他们的访问权限，这将涉及对所有 40 个报表的编辑权限。

重要

不应经常从个人工作区共享内容。 个人工作区最适合非关键、非正式或临时的内容。 如果遇到内容创建者经常从他们的个人工作区共享重要或关键内容的情况，应该采取适当的措施将该内容移动到标准工作区。 有关详细信息，请参阅个人 BI 使用情况方案。

当共享单个项时，你拥有多个权限选项。

  • 重新共享权限：启用后，用户可以与其他用户共享项，包括其基础语义模型。 如果项可以很容易地与任何人共享，则授予此权限是有意义的。 它从管理项的人员或团队中移除控制权。 因此，它依赖于被授予“重新共享”权限的用户的正确判断。 但如果允许重新共享，则内部治理或安全准则可能变得更加难以管理。
  • 生成权限：启用后，将向用户授予对基础语义模型的生成权限。 利用生成权限，用户可以创建基于语义模型的新内容。 它还允许他们从报表等中导出基础数据。 内容创建者安全性计划一文中介绍了有关授予“生成”权限的注意事项。

如果内容与少数用户共享，对于非正式方案，报表和仪表板的每项权限很有意义。 让用户了解改为使用应用和工作区管理权限是个好主意，尤其是当他们与大量用户或团队外部的用户共享内容时。 重要的是要强调以下几点。

  • 确定哪些内容已与哪些用户共享变得更加困难，因为必须单独审查在每个报表和仪表板上的权限。
  • 在许多情况下，设置“重新共享”权限是因为用户体验默认启用此选项。 因此，存在将内容共享给比预期更广泛的用户的风险。 通过在共享时取消选中“允许收件人共享此报表”选项，可以避免出现这种结果。 以这种方式最大程度地减少过度共享是一个用户培训问题。 设置共享权限的内容创建者每次都应该考虑此选项。
  • 其他人可以立即查看对报表和仪表板的所有更改，如果内容正在修改，这可能会使用户感到困惑。 通过在应用中分发内容，或使用单独的工作区来隔离开发、测试和生产内容，可以减轻这种担忧。 有关详细信息，请参阅自助内容发布使用情况方案。
  • 当用户从其个人工作区共享内容并离开组织时，IT 通常会禁用其用户帐户。 在这种情况下，共享内容的所有接收者都将立即失去对该内容的访问权限。

有三种特定类型的共享：共享链接、直接访问共享和共享视图。

当共享单个项时，默认体验会生成共享链接。 有三种类型的共享链接。

  • 组织中的人员：在 Power BI 租户设置中启用后，此类共享链接是向组织中的每个人提供只读访问权限的一种直接方式。 但是，共享链接不适用于外部用户。 此选项最适合于任何人都可以查看内容，并且可以在整个组织内自由共享链接的情况。 除非通过“允许通过可共享链接向组织中的所有人授予访问权限”租户设置禁用，否则此类共享是默认的。
  • 具有现有访问权限的人：此选项不会创建新的共享链接。 它改为检索 URL，这样你就可以将其发送给已具有访问权限的人员。
  • 特定人员：此选项为特定用户或组生成共享链接。 建议在大多数时候使用此选项，因为它提供了特定访问权限。 如果通常与外部用户合作，则可以将这种类型的链接用于已存在于 Microsoft Entra ID 中的来宾用户。 有关创建来宾用户的计划邀请流程的详细信息，请参阅租户级安全性计划一文。

重要

建议考虑将允许通过可共享链接向组织中的所有人授予访问权限租户设置限制为组成员。 可以创建一个组名，如“向整个组织提供 BI 共享”，然后添加了解组织范围内共享含义的少量用户。 如果担心现有的组织范围内的链接，可以使用管理 API 查找已与整个组织共享的所有项。

共享链接会为项添加“读取”权限。 默认情况下选择“重新共享”权限。 还可以在创建共享链接的同时向基础语义模型添加“生成”权限。

提示

建议仅在报表使用者也是可能需要从基础语义模型创建报表、导出数据或创建复合模型的内容创建者时，才教内容创建者启用“生成”权限选项。

共享链接比直接访问共享更容易维护，尤其是在需要进行批量更改时。 如果向单个用户而不是组（这通常发生在自助服务用户负责管理权限时）授予了共享权限，这是一个显着的优势。 请考虑以下对比情况。

  • 共享链接：向 20 个单个用户授予了共享链接访问权限。 对链接进行一次更改，它将影响所有 20 个用户。
  • 直接访问：向 20 个人授予了对某个项的直接访问权限。 若要进行更改，必须修改所有 20 个用户权限。

每项直接访问权限

还可以使用“直接访问”获得每项权限。 直接访问涉及设置单个项的权限。 还可以确定从工作区角色派生的任何继承权限。

当授予用户直接访问权限时，他们将被授予对该项的“读取”权限。 默认情况下选择“重新共享”权限，并为基础语义模型选择“生成”权限。 建议仅在报表使用者也是可能需要从基础语义模型创建报表、导出数据或创建复合模型的内容创建者时，才教内容创建者启用“生成”权限。

提示

用户体验使得授予“重新共享”和“生成”权限非常简单，但进行共享的用户应始终验证是否需要这些权限。

共享视图

使用共享视图与其他用户共享经过筛选的报表透视图。 可使用共享链接或直接访问来发布共享视图。

共享视图是一个临时概念。 它们会在 180 天后自动过期。 因此，共享视图最适合非正式和临时共享方案。 确保用户了解此限制。

清单 - 在创建使用每项权限的策略时，关键决策和操作包括：

  • 使用共享功能的策略：定义关于如何使用每项权限的首选项。 确保它符合面向只读使用者的总体策略。
  • 决定谁可以将链接发布到整个组织：决定哪些报表创建者可以发布针对整个组织的链接。 设置“允许通过可共享链接向组织中的所有人授予访问权限”租户设置，以符合此决定。
  • 为内容创建者创建和发布指南：为内容创建者提供文档和培训，其中包括关于如何最有效地使用每项权限的要求和首选项。 确保他们清楚每项权限的优点和缺点。 包括有关何时使用共享链接以及何时使用直接访问共享的指南。

其他使用者查询技巧

使用者与 Power BI 交互的最常见方式是使用应用、工作区和每项权限（本文前面已介绍）。

使用者可以使用其他方法来查询 Power BI 数据。 以下每种查询方法都需要语义模型或数据市场“生成”权限。

  • 在 Excel 中分析：喜欢使用 Excel 的使用者可使用在 Excel 中分析来查询 Power BI 语义模型。 此功能是将数据导出到 Excel 的绝佳替代方法，因为数据不会重复。 通过与语义模型的实时连接，用户可以创建数据透视表、图表和切片器。 然后，他们可以将工作簿发布到 Power BI 服务中的工作区，这样使用者就可以将其打开并与之交互。
  • XMLA 终结点：使用者可以通过连接到 XMLA 终结点来查询语义模型。 符合 XMLA 标准的应用程序可以连接、查询和使用存储在高级工作区中的语义模型。 如果使用者想要将 Power BI 语义模型用作 Microsoft 生态系统外部的数据可视化工具的数据源，则此功能很有用。
  • 数据市场编辑器：使用者可以使用数据市场编辑器查询 Power BI 数据市场。 它是基于 Web 的可视化查询编辑器，用于创建无代码查询。 如果使用者偏好编写 SQL 查询，还有一个基于 Web 的 SQL 编辑器。 两个编辑器都查询作为 Power BI 数据市场（而不是内置语义模型）基础的托管 Azure SQL 数据库。
  • SQL 终结点：使用者可以使用 SQL 终结点查询 Power BI 数据市场。 他们可以使用 Azure Data Studio 或 SQL Server Management Studio (SSMS) 等工具来运行 SQL 查询。 SQL 终结点将查询定向到作为 Power BI 数据市场（而不是内置语义模型）基础的托管 Azure SQL 数据库。

有关“生成”权限的详细信息，请参阅内容创建者安全性计划一文。

清单 - 在计划使用者将使用的查询方法时，关键决策和操作包括：

  • 为用户创建关于使用“在 Excel 中分析”的指南：为使用者提供关于通过 Excel 重用现有语义模型的最佳方式的文档和培训。
  • 为用户创建关于使用 XMLA 终结点的指南：为使用者提供关于通过 XMLA 终结点重用现有语义模型的最佳方式的文档和培训。
  • 为用户创建关于数据市场查询的指南：为使用者提供有关查询 Power BI 数据市场的可用方法的文档和培训。

使用者的请求访问工作流

共享内容时，一个用户将链接 (URL) 转发给另一个用户是很常见的。 如果收件人尝试查看内容并发现他们无权访问该内容，他们可以选择“请求访问”按钮。 此操作会启动请求访问工作流。 然后，系统会要求用户提供一条消息来解释他们需要访问权限的原因。

“请求访问”工作流适用于：

  • 访问 Power BI 应用。
  • 访问某个项，如报表或仪表板。
  • 对语义模型的访问权限 有关语义模型可发现时的请求访问工作流的详细信息，请参阅内容创建者安全性计划一文。

应用访问请求

可以通过两种方法来了解已为应用提交的待处理访问请求。

  • 电子邮件：应用联系人会收到电子邮件通知。 默认情况下，此联系人是应用发布者。 若要为关键应用提供更好的支持，建议将联系人设置为能够快速响应访问请求的组。
  • 管理权限菜单：工作区管理员和成员可以查看、批准或拒绝访问请求。 “管理权限”页位于“应用”页上，可为每个应用打开。 如果启用了“允许参与者更新此工作区的应用”设置，此功能也可供工作区参与者使用。

应用的待处理访问请求显示由用户提供的消息。 可以批准或拒绝每个待处理请求。 选择批准请求时，必须选择应用受众。

以下屏幕截图显示来自用户的待处理访问请求。 要批准该请求，必须选择两个应用受众之一：“销售代表”或“销售领导力”。

Power BI 服务中 Power BI 应用的待处理请求屏幕截图。

发布应用时，内容和权限将同时发布。 如前所述，不可能只发布应用权限而不更改内容。 但是，有一个例外：当批准待处理访问请求（例如上一个屏幕截图中显示的请求）时，如果没有在工作区中发布最新内容，则不会发生权限更改。

工作区访问请求

工作区访问权限由属于管理员角色或成员角色的用户授予。

尝试查看工作区的用户如果不是工作区角色的成员，则会收到“访问被拒绝”消息。 由于工作区没有内置的“请求访问”工作流，因此它们最适合密切协作的小型团队和非正式团队。 这就是 Power BI 应用更适合更大的团队和更广泛的内容分发方案的原因之一。

每项访问请求

可以通过两种方法来了解已为单个项（如报表）提交的待处理访问请求。

  • 电子邮件：项联系人会收到电子邮件通知。 若要为关键报表提供更好的支持，建议将联系人设置为能够快速响应访问请求的组。
  • 管理权限菜单：工作区管理员和成员可以访问每个项的“管理权限”页。 他们可以查看、批准或拒绝访问待处理请求。

使用组管理访问请求

当用户为 Power BI 项（如报表或语义模型）或 Power BI 应用提交请求访问表单时，会为单个用户提交该请求。 但是，许多大型组织需要使用组来遵守其内部安全策略。

建议尽量使用组（而不是个人）来保护内容。 有关组计划的详细信息，请参阅租户级安全性计划一文。

如果打算提供对组而不是单个用户的访问权限，则处理访问请求的内容所有者或管理员将需要通过多个步骤完成该请求：

  1. 拒绝 Power BI 中的待处理请求（因为它与单个用户相关联）。
  2. 根据当前流程将请求者添加到正确的组中。
  3. 通知请求者他们现在可以访问了。

提示

有关响应内容创建者的“生成”访问请求的信息，请参阅创建者的请求访问工作流。 它还包括有关使用表单访问请求的建议。

清单 - 计划“请求访问”工作流时，关键决策和操作包括：

  • 确定应由谁来处理应用访问请求：确保有一个流程能够及时处理应用访问请求。 确保分配了应用联系人以支持该过程。
  • 确定应由谁来处理每项请求：确保有一个流程能够及时处理访问请求。 确保为每个项分配了联系人以支持该过程。
  • 包括在针对内容创建者的文档和培训中：确保内容创建者了解如何及时处理访问请求。 让他们知道在应该使用组（而不是单个用户）时如何处理请求。
  • 包括在文档和培训中：包括有关内容创建者如何有效管理访问请求的指南。 还包括有关使用者在其访问请求消息中包含哪些信息的指南。

基于使用者标识强制实施数据安全性

可通过强制实施数据安全性来计划创建更少的语义模型和报表。 目标是根据查看内容的用户的标识强制实施数据安全性。

例如，假设你可以与所有销售人员（使用者）共享一个销售报表，并且知道每个销售人员只能看到其所在地区的销售结果。 通过这种方法，可以避免为每个区域创建单独报表的复杂性，这些报表需要与来自相应销售区域的销售人员共享。

一些组织对认可（认证或升级）的语义模型或数据市场具有特定要求。 对于将被广泛使用的数据，可能需要使用数据安全性。

可通过多种方式实现数据安全性。

  • Power BI 语义模型：作为 Power BI 数据创建者，可以强制实施行级别安全性 (RLS) 和对象级安全性 (OLS)。 RLS 涉及定义用于筛选数据模型行的角色和规则，而 OLS 限制对特定表或列的访问权限。 定义的这些 RLS 和 OLS 规则不适用于存储在语义模型外部的引用，例如切片器和筛选器选择。 本部分将在下文进一步介绍 RLS 和 OLS 技术。
  • Analysis Services：实时连接语义模型可以连接到由 Azure Analysis Services (AAS) 或 SQL Server Analysis Services (SSAS) 托管的远程数据模型。 远程模型可以基于使用者标识强制实施 RLS 或 OLS。
  • 数据源：某些数据源（例如 Azure SQL 数据库）可以强制实施 RLS。 在这种情况下，Power BI 模型可以利用现有安全性，而不是重新定义它。 如果源代码中定义的 RLS 很复杂，该方法可能具有显着优势。 可在 Power BI 服务中开发和发布 DirectQuery 模型，并设置语义模型的数据源凭据，以启用单一登录 (SSO)。 当报表使用者打开报表时，Power BI 会将其标识传递给数据源。 然后，数据源根据报表使用者的标识强制实施 RLS。 有关 Azure SQL 数据库 RLS 的详细信息，请参阅本文。

注意

源系统（如 Azure SQL 数据库）也可以使用视图等方法来缩小用户可查看的范围。 虽然这是一种有效的方法，但它与本部分的重点无关。

行级别安全性

行级别安全性 (RLS) 允许数据建模者限制对数据子集的访问。 它通常用于确保某些报表使用者看不到特定数据，例如其他销售区域的销售结果。

提示

如果你发现有人创建了多个数据模型来支持不同的使用者群体，请检查 RLS 是否会满足其要求。 通常最好是创建、测试和维护一个数据模型，而不是创建多个数据模型。

请保持谨慎，因为如果 Power BI 报表引用配置了 RLS 的行，则将显示与已删除或非现有字段相同的消息。 在这些用户看来，该报表似乎已损坏。

设置 RLS 有两个步骤：规则和角色映射。

RLS 规则

对于语义模型，数据建模者可以通过创建一个或多个角色在 Power BI Desktop 中设置 RLS。 角色在模型中具有唯一的名称，通常包含一个或多个规则。 规则通过使用数据分析表达式 (DAX) 筛选器表达式对模型表强制执行筛选器。 默认情况下，模型没有角色。

重要

没有角色的模型意味着（有权查询数据模型的）用户有权访问所有模型数据。

规则表达式在行上下文中求值。 行上下文意味着使用该行的列值针对每一行计算表达式。 当表达式返回 TRUE 时，用户可以看到该行。 可以定义静态规则或动态规则。

  • 静态规则：使用引用常量的 DAX 表达式，例如 [Region] = "Midwest"。
  • 动态规则：使用特定的 DAX 函数，这些函数返回环境值（而不是常量）。 环境值从三个特定的 DAX 函数返回：USERNAME、USERPRINCIPALNAME 和 CUSTOMDATA。 当模型表存储用户名值时，定义动态规则非常简单且有效。 它们允许你强制实施数据驱动的 RLS 设计。

RLS 角色映射

将模型发布到 Power BI 服务后，必须在用户访问相关报表之前设置角色映射。 角色映射涉及将 Microsoft Entra 安全对象分配给角色。 安全对象可以是用户帐户或安全组。

如果可能，最好将角色映射到安全组。 这样，映射就会更少，并且组成员管理可以由组的所有者来处理。

建议向内容创建者提供来自 Microsoft Entra 的安全帐户信息。 一种选择是使用与 Microsoft Entra ID 保持同步的数据创建数据流。 这样，内容创建者就可以集成数据流数据，以生成数据驱动的语义模型。

提示

可以定义没有规则的角色。 在这种情况下，角色提供对所有模型表的所有行的访问权限。 如果允许管理员或用户查看模型中的所有数据，则设置此类角色是合适的。

RLS 用户体验

除了标准的 Power BI 权限之外，一些组织还选择有意将 RLS 用作次要安全层。 考虑以下场景：与整个组织共享指向报表的链接。 查看报表的任何用户都必须映射到 RLS 角色才能查看该报表中的数据。 如果他们没有映射到 RLS 角色，将看不到任何数据。

RLS 的存在改变了使用者的默认体验。

  • 未为语义模型定义 RLS 时：对语义模型至少具有读取权限的创建者和使用者可以查看语义模型中的所有数据。
  • 在语义模型上定义 RLS 时：对语义模型仅具有读取权限的创建者和使用者将只能查看被允许查看的数据（基于其 RLS 角色映射）。

注意

一些组织强制实施 RLS 作为附加的安全层，尤其是在涉及敏感数据时。 因此，可以选择要求对经过认证的语义模型使用 RLS。 在验证语义模型之前，可通过内部审查和批准过程来满足该要求。

当用户在工作区或应用中查看报表时，可能会（或者可能不会）根据其语义模型权限强制实施 RLS。 因此，如果必须强制实施 RLS，内容使用者和创建者只拥有对基础语义模型的读取权限，这一点至关重要。

下面是用于确定 RLS 是否被强制实施的权限规则。

  • 用户对语义模型具有读取权限：已为用户强制实施 RLS。
  • 用户对语义模型具有读取和生成权限：已为用户强制实施 RLS。
  • 用户对语义模型具有写入权限：并未对用户强制实施 RLS，这意味着他们可以看到语义模型中的所有数据。 写入权限提供用于编辑语义模型的功能。 可通过以下两种方式之一授予该权限：

提示

有关如何使用单独工作区以便 RLS 适用于内容创建者的详细信息，请参阅托管自助式 BI 使用情况方案。

有关 RLS 的详细信息，请参阅限制对 Power BI 模型数据的访问权限。

适用于数据市场的 RLS

Power BI 数据市场也可以强制实施 RLS。 但是，实现是不同的。

主要区别在于，适用于数据市场的 RLS 是在 Power BI 服务（而不是在 Power BI Desktop）中设置的。

另一个区别是，数据市场在与该数据市场关联的语义模型和托管的 Azure SQL 数据库上强制实施 RLS。 在两个层上强制实施 RLS 提供了一致性和灵活性。 不管用户查询数据的方式如何（无论是通过连接到语义模型还是托管的 Azure SQL 数据库），都将应用相同的 RLS 筛选器。

有关详细信息，请参阅适用于数据市场的 RLS。

对象级安全性

对象级安全性 (OLS) 允许数据建模者限制对特定表和列及其元数据的访问。 通常使用 OLS 来确保敏感列（如员工工资）对某些用户不可见。 虽然不可能限制对度量值的访问，但任何引用受限制列的度量值本身都将受到限制。

以员工表为例。 它包含存储员工姓名和电话号码以及工资的列。 你可使用 OLS 来确保只有某些用户（如高级人力资源人员）才能看到工资值。 对于那些看不到工资值的用户，就好像该列不存在一样。

请注意，如果 Power BI 报表视觉对象包括工资，则无法访问该字段的用户将收到错误消息。 此消息将告知他们该对象不存在。 在这些用户看来，该报表似乎已损坏。

注意

还可以在数据模型中定义透视图。 透视图定义了模型对象的可查看子集，以帮助为报表创建者提供特定的焦点。 透视图不用于限制对模型对象的访问。 即使某个表或列对用户不可见，他们也仍可以查询该表或列。 因此，将透视图视为一种用户便利性，而不是一项安全功能。

Power BI Desktop 目前没有用于设置 OLS 的接口。 可以使用表格编辑器（用于创建、维护和管理模型的第三方工具）。 有关详细信息，请参阅高级数据模型管理使用情况方案。

有关 OLS 的详细信息，请参阅限制对 Power BI 模型对象的访问权限。

清单 - 计划 RLS 和 OLS 时，关键决策和操作包括：

  • 确定使用 RLS 的策略：请考虑你打算使用行级别安全性的用例和目的。
  • 确定使用 OLS 的策略：请考虑你打算使用对象级别安全性的用例和目的。
  • 考虑有关认证内容的要求：如果你有一个经过认证语义模型所需的过程，请确定是否包括有关使用 RLS 或 OLS 的任何特定要求。
  • 创建和发布用户指南：为用户创建文档，其中包括有关使用 RLS 和 OLS 的要求和首选项。 介绍如何获取用户映射信息（如果它存在于一个集中位置）。
  • 更新培训材料：在用户培训材料中包括有关 RLS 和 OLS 的要求和首选项的关键信息。 提供示例，供用户了解何时适合使用任一数据安全方法。

相关内容

在本系列的下一篇文章中，了解负责创建语义模型、数据流、数据市场、报表或仪表板的内容创建者的安全性计划。