Power BI 实现规划：Power BI 的信息保护

项目
03/23/2023

备注

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

本文介绍与在 Power BI 中实现信息保护相关的规划活动。本文面向：

Power BI 管理员：负责监督组织中 Power BI 的管理员。 Power BI 管理员需要与信息安全和其他相关团队协作。
卓越中心、IT 和 BI 团队：负责在组织中监督 Power BI 的其他人。他们可能需要与 Power BI 管理员、信息安全团队和其他相关团队协作。

重要

信息保护和数据丢失防护 (DLP) 是组织范围内的一项重要工作。它的范围和影响远远超过 Power BI 本身。这种类型的计划需要资金支持、设定优先级和做好规划。预期规划、使用和监督工作中涉及多个跨职能团队。

标记和分类活动超出了 Power BI 甚至数据资产的范围。本文中讨论的决策适用于整个组织的资产，包括文件和电子邮件，而不仅仅是 Power BI。本文介绍一般适用于标签和分类的主题，因为在 Power BI 中，做出正确的组织决策对于数据丢失防护的成功至关重要。

本文还包括有关定义敏感度标签结构的介绍性指南。从技术上说，敏感度标签结构是实现 Power BI 中敏感度标签的先决条件。本文中涵盖一些基本信息的目的是帮助你理解所涉及的内容。与 IT 部门合作规划和实现组织中的信息保护是至关重要的。

敏感度标签的用途

使用 Microsoft Purview 信息保护敏感度标签是为了对内容进行分类。将敏感度标签视为一种应用于项目、文件、站点或数据资产的标记。

使用信息保护有很多好处。对内容进行分类和标记有助于组织：

了解敏感数据所在的位置。
跟踪外部和内部合规性要求。
保护内容不受未经授权用户的侵害。
告知用户如何负责任地处理数据。
实现实时控制，降低数据泄露的风险。

有关信息保护的更多用例，请参阅信息保护和 DLP（常见用例）。

提示

请记住 Microsoft Purview 信息保护是一款产品。敏感度标签是该产品的特定功能。

敏感性标签是用明文表示的简短说明。从概念上讲，可以将敏感度标签视为一种标记。只能为每个项（例如，Power BI 服务中的 Power BI 语义模型—旧称为数据集）或每个文件（例如，Power BI Desktop 文件）分配一个标签。

标签有以下用途。

分类：它提供用于描述敏感度级别的分类。
用户教育和意识：它可帮助用户了解如何适当地处理内容。
：它构成了应用和执行策略和 DLP 的基础。

Power BI 信息保护的先决条件

到目前为止，你应该已经完成了组织级信息保护规划一文中描述的组织级规划步骤。在继续操作之前，你应该明确：

当前状态：组织中信息保护的当前状态。你应该了解 Microsoft Office 文件是否已经使用了敏感度标签。在这种情况下，添加 Power BI 的工作范围比首次向组织引入信息保护要小得多。
目标和要求：在组织中实施信息保护的战略目标。理解目标和需求将为实现工作提供指导。

如果组织未使用信息保护，则本节的其余部分将提供信息，帮助你与他人协作，将信息保护引入到组织中。

如果组织内正在积极使用信息保护，建议你使用本文来验证是否满足先决条件。如果敏感度标签正在使用中，那么推出阶段 1-4（在下一节中）中的大多数（或所有）活动将已经完成。

推出阶段

建议制定一个逐步推出的计划，以实现和测试信息保护。逐步推出计划的目标是让自己在进行过程中学习、调整和迭代。这样做的好处是，在早期阶段（更可能发生更改），受到影响的用户更少，直到最终将信息保护面向组织中的所有用户推出。

引进信息保护是一项重大的工作。如组织级信息保护规划一文中所述，如果你的组织已经为 Microsoft Office 文档实施了信息保护，那么便已经完成了其中许多任务。

本部分概述了我们建议你在逐步推出计划中包含的各个阶段。它应该能让你对相关步骤有一个大致了解。本文的其余部分介绍了最直接影响 Power BI 的关键方面的其他决策标准。

阶段 1：计划、决定、准备

在第一阶段，注重规划、决策和筹备活动。本文剩余的大部分内容都集中在这一第一阶段。

尽早明确初始测试将在何处进行。该选择将影响最初设置、发布和测试的位置。对于初始测试，你可能希望使用非生产租户（如果你有权访问）。

提示

大多数组织都可以访问一个租户，因此以孤立的方式探索新功能可能具有挑战性。对于那些拥有独立开发或测试租户的组织，我们建议在初始测试阶段使用它。有关管理租户以及如何创建试用租户以测试新功能的详细信息，请参阅租户设置。

阶段 2：设置支持用户资源

第二阶段包括为支持用户设置资源的步骤。资源包括数据分类和保护策略和自定义帮助页。

尽早发布一些用户文档很重要。让用户支持团队及早做好准备也很重要。

阶段 3：设置标签并发布

第三阶段侧重于定义敏感度标签。当做出了所有的决策后，设置就不困难也不耗时了。敏感度标签在 Microsoft 365 管理中心的 Microsoft Purview 合规门户中设置。

阶段 4：发布标签策略

在使用标签之前，必须将其作为标签策略的一部分发布。标签策略允许某些用户使用标签。标签策略在 Microsoft 365 管理中心的 Microsoft Purview 合规门户中发布。

注意

在此之前的一切都是为 Power BI 实现信息保护的先决条件。

阶段 5：启用 Power BI 租户设置

Power BI 管理门户中有多个信息保护租户设置。在 Power BI 服务中启用信息保护需要这些设置。

重要

应在 Microsoft Purview 合规门户中设置和发布标签之后设置租户设置。

阶段 6：初始测试

在第六阶段，将执行初始测试，以验证一切行为是否符合预期。出于初始测试目的，应仅针对实现团队发布标签策略。

在此阶段，请务必测试：

Microsoft Office 文件
Power BI 服务中的 Power BI 项
Power BI Desktop 文件
从 Power BI 服务导出文件
配置中包含的其他范围，例如 Teams 网站或 SharePoint

请务必使用 Web 浏览器和常用移动设备检查功能和用户体验。相应地更新用户文档。

重要

即使只有少数团队成员被授权设置敏感度标签，所有用户也将能够看到分配给内容的标签。如果你使用的是生产租户，用户可能想知道为什么他们会在 Power BI 服务的工作区中看到分配给项的标签。准备好支持和响应用户问题。

阶段 7：收集用户反馈

这个阶段的目标是从一小部分关键用户那里获得反馈。反馈应指出混淆领域、标签结构未覆盖到的部分或技术问题。可能还会找到改进用户文档的理由。

为此，应向愿意提供反馈的一小部分用户发布（或重新发布）标签策略。

提示

请确保在项目计划中留出足够的时间。对于标签和标签策略的设置，产品文档建议等待 24 小时让更改生效。需要这个时间来确保所有更改都传播到相关的服务。

阶段 8：以迭代方式发布

实现阶段通常是一个迭代过程。

通常，初始目标是达到一种所有 Power BI 内容都分配了敏感度标签的状态。若要实现此目标，可以引入强制标签策略或默认标签策略。还可以使用信息保护管理 API 以编程方式设置或删除敏感度标签。

可以逐渐包含更多的用户组，直到囊括整个组织。此过程涉及将每个标签策略重新发布给越来越多的用户组。

在整个过程中，一定要优先为用户提供指导、沟通和培训，以便他们理解过程并明白自己需要做些什么。

阶段 9：监视、审核、调整、集成

初始推出后，还有其他步骤要执行。你应该有一个主要团队来监视信息保护活动，并随着时间的推移进行调整。应用标签后，你将能够评估它们的实用性并确定需要调整的区域。

审核信息的保护是多方面的。有关详细信息，请参阅审核 Power BI 的信息保护和数据丢失防护。

在设置信息保护方面的投资可以用于 Power BI 的 DLP 策略，这些策略是在 Microsoft Purview 合规门户中设置的。有关详细信息，包括 DLP 功能的说明，请参阅 Power BI 的数据丢失防护。

信息保护还可用于在 Microsoft Defender for Cloud Apps 中创建策略。有关详细信息，包括可能对你有帮助的功能的描述，请参阅适用于 Power BI 的 Defender for Cloud Apps。

清单 - 准备信息保护推出阶段时，关键决策和操作包括：

创建逐步推出计划：定义推出计划的阶段。阐明每个阶段的具体目标。
确定测试位置：确定可以执行初始测试的位置。为了尽量减少对用户的影响，请尽可能使用非生产租户。
创建项目计划：建立一个项目计划，包括所有的关键活动、估计的时间线以及将负责的人员。

敏感度标签结构

敏感度标签结构是实现 Power BI 中的敏感度标签的先决条件。本部分包含一些基本信息，可帮助你了解创建标签结构时所涉及的内容。

本部分并不是针对所有可能应用程序的所有可能的敏感度标签注意事项的详尽列表。相反，其重点是直接影响 Power BI 内容分类的注意事项和活动。请务必与其他利益干系人和系统管理员共同商议，做出适合所有应用程序和用例的决策。

实现信息保护的基础始于一组敏感度标签。最终目标是创建一组清晰明了的敏感度标签，供用户使用。

组织中使用的敏感度标签结构表示标签分类。它通常也称为数据类别分类法，因为目标是对数据进行分类。有时称为架构定义。

没有一个标准的或内置的标签集。每个组织必须定义和自定义一组标签，以满足其需求。达成一套正确的标签的过程需要广泛的协作。它需要经过深思熟虑的计划，以确保标签符合目标和要求。请记住，标签将不仅仅应用于 Power BI 内容。

提示

大多数组织首先会将标签分配给 Microsoft Office 文件。然后，它们演变为对其他内容（如 Power BI 项和文件）进行分类。

标签结构包括：

标签：标签构成层次结构。每个标签指示项、文件或数据资产的敏感度级别。建议创建 3 到 7 个标签。标签应该很少更改。
子标签：子标签指示特定标签内保护或范围的变化。通过将子标签包含在不同的标签策略中，可以将子标签范围限定为一组特定用户或涉及特定项目的用户。

提示

虽然子标签提供了灵活性，但只有在满足关键需求时才应该适度地使用它们。创建过多的子标签会增加管理。用户也会因为太多的选项而感到不知所措。

标签形成一个层次结构，从最不敏感的分类开始，到最敏感的分类。

有时 Power BI 内容包含跨多个标签的数据。例如，语义模型可能包含产品库存信息（常规内部使用）和当前季度销售数据（受限）。在选择将哪个标签分配给 Power BI 语义模型时，应该教用户应用限制性最高的标签。

提示

下一节介绍了数据分类和保护策略，可为用户提供有关何时使用每个标签的指导。

重要

分配标签或子标签不会直接影响对 Power BI 服务中 Power BI 内容的访问。相反，标签提供了一个可以指导用户行为的有用类别。数据丢失防护策略也可以基于分配的标签。但是，对 Power BI 内容的访问管理方式没有任何改变，除非文件被加密。有关详细信息，请参阅加密保护的使用。

请谨慎使用创建的标签，因为一旦完成了初始测试阶段，就很难移除或删除标签。因为子标签可以（可选地）用于一组特定的用户，所以它们可以比标签更频繁地更改。

下面是定义标签结构的一些最佳做法。

使用直观、明确的术语：清晰度对于确保用户知道在对数据进行分类时选择什么非常重要。例如，拥有“绝密”标签和“高度机密”标签是模棱两可的。
创建逻辑分层顺序：标签的顺序对于使一切正常运行至关重要。请记住，列表中的最后一个标签最敏感。分层顺序，结合精心选择的术语，应具有逻辑性和直观性，便于用户使用。清晰的层次结构还将使策略更容易创建和维护。
只创建几个适用于整个组织的标签：有太多标签供用户选择会让人感到困惑。这也会导致标签选择的准确性降低。建议仅为初始集创建几个标签。
使用有意义的泛型名称：避免在标签名称中使用行业术语或首字母缩写词。例如，与其创建名为“个人身份信息”的标签，不如使用“高度受限”或“高度机密”等名称。
使用容易本地化为其他语言的术语：对于在多个国家/地区开展业务的全球性组织，选择在翻译成其他语言时不会混淆或模棱两可的标签术语很重要。

提示

如果你发现自己在为许多非常具体的标签做计划，那就退一步，重新评估你的方法。复杂性会导致用户混淆、采用率降低和信息保护效率降低。建议从一组初始标签开始（或使用已有的标签）。获得更多经验后，通过在需要时添加更具体的标签来谨慎地扩展标签集。

清单 - 规划敏感度标签结构时，关键决策和操作包括：

定义初始敏感度标签集：创建一组介于三到七个敏感度标签之间的初始集。确保它们对各种内容具有广泛的用途。在完成数据分类和保护策略时，计划循环访问初始列表。
确定是否需要子标签：确定是否需要对任何标签使用子标签。
验证标签术语的本地化：如果标签将翻译成其他语言，请让母语人士确认本地化标签传达了预期的含义。

敏感度标签 ID

敏感度标签范围限制标签的使用。虽然不能直接指定 Power BI，但可以将标签应用于各种范围。可能的范围包括：

项（例如发布到 Power BI 服务的项以及文件和电子邮件）
组和网站（例如 Teams 频道或 SharePoint 网站）
架构化数据资产（在 Purview 数据映射中注册的受支持源）

重要

不能仅用 Power BI 范围来定义敏感度标签。虽然有一些设置专门适用于 Power BI，但范围不在其中。项范围用于 Power BI 服务。敏感度标签的处理方式与 DLP 策略不同，后者在 Power BI 规划的数据丢失防护一文中进行了描述，因为可以专门为 Power BI 定义某些类型的 DLP 策略。如果打算在 Power BI 中使用从数据源继承的敏感度标签，则标签范围有特定要求。

与敏感度标签相关的事件记录在活动资源管理器中。当范围更广时，这些事件的记录详细信息将显着丰富。你还可以为保护更广泛的应用程序和服务中的数据做好更充分的准备。

在定义初始敏感度标签集时，请考虑使初始标签集可用于所有范围。这是因为当用户在不同的应用程序和服务中看到不同的标签时，他们可能会感到困惑。然而，随着时间的推移，你可能会发现更具体的子标签的用例。不过，从一组一致且简单的初始标签开始更安全。

标签范围是在设置标签时在 Microsoft Purview 合规门户中设置的。

清单 - 规划标签范围时，关键决策和操作包括：

确定标签范围：讨论并决定是否将每个初始标签应用于所有范围。
查看所有先决条件：调查要使用的每个范围所需的先决条件和必要的设置步骤。

使用加密保护

有多个选项可用于使用敏感度标签进行保护。

加密：加密设置适用于文件或电子邮件。例如，可以加密 Power BI Desktop 文件。
标记：指页眉、页脚和水印。标记对于 Microsoft Office 文件很有用，但在 Power BI 内容中没有显示。

提示

通常，当有人将标签称为“受保护”时，他们指的就是加密。仅对较高级别的标签（例如“受限”和“高度受限”）进行加密可能就足够了。

加密是一种对信息进行加密编码的方法。加密具有几个关键优势。

只有授权用户（例如，组织内的内部用户）才能打开、解密和读取受保护的文件。
即使文件被发送到组织外部或被重命名，加密仍然保留在受保护的文件中。
加密设置是从原始标记的内容中获得的。假设 Power BI 服务中的报表具有“高度受限”的敏感度标签。如果将其导出到支持的导出路径，标签将保持不变，并且对导出的文件应用加密。

Azure Rights Management Service (Azure RMS) 用于使用加密进行文件保护。要使用 Azure RMS 加密，必须满足一些重要的先决条件。

重要

需要考虑一个限制：脱机用户（没有 Internet 连接）无法打开加密的 Power BI Desktop 文件（或其他类型的受 Azure RMS 保护的文件）。这是因为 Azure RMS 必须同步验证用户是否有权打开、解密和查看文件内容。

加密标签的处理方式不同，具体取决于用户的工作位置。

在 Power BI 服务中：加密设置对 Power BI 服务中的用户访问没有直接影响。标准 Power BI 权限（例如工作区角色、应用权限或共享权限）控制 Power BI 服务中的用户访问。敏感度标签不会影响对 Power BI 服务中内容的访问。
Power BI Desktop 文件：可以将加密标签分配给 Power BI Desktop 文件。从 Power BI 服务导出标签时也会保留该标签。只有授权用户才能打开、解密和查看文件。
导出的文件：从 Power BI 服务导出的 Microsoft Excel、Microsoft PowerPoint 和 PDF 文件保留其敏感度标签，包括加密保护。对于受支持的文件格式，只有经过授权的用户才能打开、解密和查看文件。

重要

用户必须了解 Power BI 服务和文件之间的区别，因为它们很容易混淆。建议提供常见问题解答文档以及示例，以帮助用户了解差异。

若要打开受保护的 Power BI Desktop 文件或导出的文件，用户必须满足以下条件。

Internet 连接：用户必须连接到 Internet。与 Azure RMS 通信需要有效的 Internet 连接。
RMS 权限：用户必须拥有 RMS 权限，这些权限在标签中（而不是在标签策略中）定义。 RMS 权限允许授权用户解密、打开和查看支持的文件格式。
允许的用户：必须在标签策略中指定用户或组。通常，仅需要为内容创建者和所有者分配授权用户，以便他们可以应用标签。但是，在使用加密保护时，还有另一个要求。必须在标签策略中指定每个需要打开受保护文件的用户。此要求意味着更多用户可能需要信息保护许可。

提示

“允许工作区管理员覆盖自动应用的敏感度标签”这一租户设置使工作区管理员能够更改自动应用的标签，即使该标签启用了保护（加密）。当自动分配或继承标签，但工作区管理员不是授权用户时，此功能特别有用。

设置标签时，在 Microsoft Purview 合规门户中设置标签保护。

清单 - 规划使用标签加密时，关键决策和操作包括：

确定应加密哪些标签：对于每个敏感度标签，决定是否应该对其进行加密（保护）。仔细考虑所涉及的限制。
标识每个标签的 RMS 权限：确定访问加密文件并与之交互的用户权限。为每个敏感度标签创建用户和组的映射，以帮助规划过程。
查看和解决 RMS 加密先决条件：确保满足使用 Azure RMS 加密的技术先决条件。
计划对加密进行彻底测试：由于 Office 文件和 Power BI 文件之间存在差异，请确保完成整个测试阶段。
包含在用户文档和培训中：确保在文档和培训中包含有关用户对分配了加密敏感度标签的文件应采取操作的指导。
通过支持团队进行知识转移：制定具体计划，与支持团队开展知识转移会议。由于加密的复杂性，他们很可能会收到用户的提问。

从数据源继承标签

从受支持的数据源（如 Azure Synapse Analytics、Azure SQL 数据库或 Excel 文件）导入数据时，Power BI 语义模型可以选择继承应用于源数据的敏感度标签。继承有助于：

促进标签的一致性。
减少分配标签时的用户工作量。
降低用户访问敏感数据以及向未经授权的用户共享敏感数据的风险，因为未标记这些数据。

提示

敏感度标签有两种类型的继承。 下游继承是指自动从其 Power BI 语义模型继承标签的下游项（如报表）。但是，本部分的重点是上游继承。上游继承是指 Power BI 语义模型从语义模型上游的数据源继承标签。

考虑一个示例，其中组织对“高度受限”敏感度标签的工作定义包括财务帐号。由于财务帐号存储在 Azure SQL 数据库中，因此已将“高度受限”敏感度标签分配给该源。将 Azure SQL 数据库中的数据导入 Power BI 时，目的是让语义模型继承标签。

可以通过不同的方式将敏感度标签分配给受支持的数据源。

数据发现和分类：可以扫描受支持的数据库来标识可能包含敏感数据的列。根据扫描结果，可以应用部分或全部标签建议。 Azure SQL 数据库、Azure SQL 托管实例和 Azure Synapse Analytics 等数据库支持数据发现和分类。本地 SQL Server 数据库支持 SQL 数据发现和分类。
手动分配：可以将敏感度标签分配给 Excel 文件。还可以手动为 Azure SQL 数据库或 SQL Server 中的数据库列分配标签。
Microsoft Purview 中的自动标记：可以将敏感度标签应用到在 Microsoft Purview 数据映射中注册为资产的受支持数据源。

警告

有关如何向数据源分配敏感度标签的详细信息不在本文探讨的范围内。与 Power BI 中对继承的支持有关的技术功能正在不断发展。建议进行技术概念验证，以验证目标、易用性以及功能是否满足要求。

仅当启用“将来自数据源的敏感度标签应用于这些数据源在 Power BI 中的数据”这一租户设置时，才会发生继承。有关租户设置的详细信息，请参阅本文后面的 Power BI 租户设置部分。

提示

需要熟悉继承行为。请务必在测试计划中包括各种情况。

清单 - 规划从数据源继承标签时，关键决策和操作包括：

确定 Power BI 是否应从数据源继承标签：确定 Power BI 是否应继承这些标签。计划启用租户设置以允许此功能。
查看技术先决条件：确定是否需要采取额外的步骤将敏感度标签分配给数据源。
测试标签继承功能：完成技术概念证明，以测试继承的工作原理。验证该功能在各种情况下是否按预期工作。
包含在用户文档中：确保将有关标签继承的信息添加到提供给用户的指南中。在用户文档中包含实际的示例。

已发布的标签策略

定义敏感度标签后，可以将标签添加到一个或多个标签策略。标签策略就是发布标签以便使用它的方式。它定义哪些标签可供哪组授权用户使用。还有其他设置，例如默认标签和强制标签。

当需要针对不同的用户集时，使用多个标签策略会很有帮助。可以定义一次敏感度标签，然后将其包含在一个或多个标签策略中。

提示

在 Microsoft Purview 合规门户中发布包含标签的标签策略之前，将无法使用敏感度标签。

授权的用户和组

创建标签策略时，必须选择一个或多个用户或组。标签策略决定哪些用户可以使用标签。该策略允许用户将该标签分配给特定内容，例如 Power BI Desktop 文件、Excel 文件或发布到 Power BI 服务的项。

建议尽可能使授权用户和组保持简单。一个好的经验法则是为所有用户发布主标签。有时，适合将子标签分配给用户子集，或者将其限定为范围。

建议尽可能分配组而不是个人。组的使用简化了策略的管理并减少了重新发布的频率，

警告

标签的授权用户和组不同于为受保护（加密）标签分配给 Azure RMS 的用户。如果用户在打开加密文件时遇到问题，请调查特定用户和组的加密权限（在标签配置中设置，而不是在标签策略中设置）。在大多数情况下，建议你为两者分配相同的用户。这种一致性将避免混淆并减少支持票证。

发布标签策略时，会在 Microsoft Purview 合规门户中设置授权用户和组。

清单 - 在标签策略中规划授权用户和组时，关键决策和操作包括：

确定哪些标签适用于所有用户：讨论并决定哪些敏感度标签应该可供所有用户使用。
确定哪些子标签适用于用户子集：讨论并决定是否有任何子标签可供一组特定的用户或组使用。
确定是否需要任何新组：确定是否需要创建任何新的 Microsoft Entra ID（以前称为 Azure Active Directory）组来支持授权用户和组。
创建规划文档：如果授权用户到敏感度标签的映射比较复杂，可以为每个标签策略创建用户和组的映射。

Power BI 内容的默认标签

创建标签策略时，可以选择默认标签。例如，可以将“常规内部使用”标签设置为默认标签。此设置会影响在 Power BI Desktop 或 Power BI 服务中创建的新 Power BI 项。

可以在标签策略中专门为 Power BI 内容设置默认标签，它与其他项是分开的。大多数信息保护决策和设置适用范围更广。但是，默认标签设置（以及接下来描述的强制标签设置）仅适用于 Power BI。

提示

虽然可以设置不同的默认标签（用于 Power BI 和非 Power BI 内容），但请考虑这是否是用户的最佳选择。

在发布标签策略之后，新的默认标签策略将应用于创建或编辑的内容，理解这一点非常重要。它不会以追溯方式将默认标签分配给现有内容。 Power BI 管理员可以使用信息保护 API 批量设置敏感度标签，以确保将现有内容分配给默认敏感度标签。

发布标签策略时，会在 Microsoft Purview 合规门户中设置默认标签选项。

清单 - 规划是否应用 Power BI 内容的默认标签时，关键决策和操作包括：

确定是否指定默认标签：讨论并确定默认标签是否合适。如果是，请确定哪个标签最适合作为默认标签。
包含在用户文档中：如有必要，请确保在提供给用户的指南中提及有关默认标签的信息。目的是让用户了解如何确定默认标签是否合适，或者是否应该更改它。

强制标签 Power BI 内容

数据分类是一项常见的监管要求。若要满足此要求，可以选择要求用户标记所有 Power BI 内容。此强制标签要求在用户创建或编辑 Power BI 内容时生效。

可以选择实现强制标签、默认标签（在前一节中描述过），或两者兼而有之。应考虑以下几点。

强制标签策略确保标签不会为空
强制标签策略要求用户选择标签应是什么
强制标签策略可防止用户完全删除标签
默认标签策略对用户的干扰较小，因为它不需要用户采取行动
默认标签策略可能会导致内容被错误标记，因为用户没有明确做出选择
同时启用默认标签策略和强制标签策略可以提供互补优势

提示

如果选择实现强制标签，建议也实现默认标签。

可以专门为 Power BI 内容设置强制标签策略。大多数信息保护设置适用范围更广。但是，强制标签设置（和默认标签设置）仅适用于 Power BI。

提示

强制标签策略不适用于服务主体或 API。

发布标签策略时，会在 Microsoft Purview 合规门户中设置强制标签选项。

清单 - 规划是否需要强制标记 Power BI 内容时，关键决策和操作包括：

确定标签是否为强制：讨论并决定是否有必要使用强制标签。
包含在用户文档中：如有必要，请确保将有关强制标签的信息添加到为用户提供的指南中。目标是让用户了解预期内容。

许可要求

必须有特定许可才能使用敏感度标签。

以下角色需要 Microsoft Purview 信息保护许可证：

管理员：将设置、管理和监督标签的管理员。
用户：负责向内容应用标签的内容创建者和所有者。用户还包括需要解密、打开和查看受保护（加密）文件的人员。

你可能已经拥有这些功能，因为它们包含在许可套件中，例如 Microsoft 365 E5。或者，可以将 Microsoft 365 E5 合规功能作为独立许可证进行购买。

将在 Power BI 服务或 Power BI Desktop 中应用和管理敏感度标签的用户还需要 Power BI Pro 或 Premium Per User (PPU) 许可证。

提示

如果需要有关许可要求的说明，请联系 Microsoft 帐户团队。请注意，Microsoft 365 E5 合规许可证包含的其他功能不在本文探讨的范围内。

清单 - 评估敏感度标签的许可要求时，关键决策和操作包括：

查看产品许可要求：确保查看所有许可要求。
查看用户许可要求：验证希望分配标签的所有用户是否都具有 Power BI Pro 或 PPU 许可证。
购买其他许可证：如果适用，请购买更多许可证以解锁你打算使用的功能。
分配许可证：向将分配、更新或管理敏感度标签的每个用户分配许可证。向将与加密文件交互的每个用户分配许可证。

Power BI 租户设置

有几个 Power BI 租户设置与信息保护相关。

重要

在满足所有先决条件之前，不应设置用于信息保护的 Power BI 租户设置。标签和标签策略应在 Microsoft Purview 合规门户中设置和发布。在此之前，你还处于决策过程中。在设置租户设置之前，应首先确定如何使用一部分用户测试功能的过程。然后，你可以决定如何逐步推出。

可应用标签的用户

你应该决定允许谁将敏感度标签应用于 Power BI 内容。该决策将决定如何设置允许用户为内容应用敏感度标签租户设置。

通常是在正常工作流中分配标签的内容创建者或所有者。最简单的方法是启用此租户设置，该设置允许所有 Power BI 用户应用标签。在这种情况下，标准工作区角色将决定谁可以编辑 Power BI 服务中的项（包括应用标签）。可以使用活动日志来跟踪用户何时分配或更改标签。

数据源中的标签

你应该决定是否要从 Power BI 上游的受支持数据源继承敏感度标签。例如，如果已使用高度受限敏感度标签定义 Azure SQL 数据库中的列，则从该源导入数据的 Power BI 语义模型将继承该标签。

如果决定启用从上游数据源继承，请在 Power BI 中设置“将来自数据源的敏感度标签应用于其数据”租户设置。建议计划启用数据源标签的继承以提高一致性并减少工作量。

下游内容的标签

应确定敏感度标签是否应由下游内容继承。例如，如果 Power BI 语义模型的敏感度标签为高度受限，则所有下游报表都将从语义模型继承此标签。

如果决定启用下游内容的继承，请设置“自动将敏感度标签应用于下游内容”租户设置。建议计划启用下游内容的继承，以提高一致性并减少工作量。

工作区管理员替代

此设置适用于自动应用的标签（例如应用默认标签或自动继承标签时）。当标签具有保护设置时，Power BI 仅允许授权用户更改标签。此设置使工作区管理员能够更改自动应用的标签，即使标签上有保护设置。

如果决定允许标签更新，请设置“允许工作区管理员覆盖自动应用的敏感度标签”租户设置。此设置适用于整个组织（而不是单个组）。它允许工作区管理员更改自动应用的标签。

建议你考虑允许 Power BI 工作区管理员更新标签。可以使用活动日志在分配或更改标签时进行跟踪。

应决定是否可以与组织中的每个人共享受保护（加密）的内容。

如果决定禁止共享受保护的内容，请设置“限制通过链接与组织中的所有人共享包含受保护标签的内容”租户设置。此设置适用于整个组织（而不是单个组）。

强烈建议计划启用此租户设置以禁止共享受保护的内容。启用该设置后，将禁止与整个组织共享更敏感内容（由定义了加密的标签定义）的操作。通过启用此设置，可以减少数据泄露的可能性。

重要

有一个类似的租户设置，名为“允许通过可共享的链接向组织中的所有人员授予访问权限”。虽然名称相似，但用途不同。它定义了哪些组可以为整个组织创建共享链接，而不考虑敏感度标签。在大多数情况下，建议在组织中限制此功能。有关详细信息，请参阅报告使用者安全性计划一文。

支持的导出文件类型

在 Power BI 管理门户中，有许多导出和共享租户设置。在大多数情况下，建议向所有（或大多数）用户提供导出数据的功能，以免限制用户的工作效率。

但是，当无法对输出格式实施信息保护时，高度管制的行业可能需要限制导出。在将内容导出到受支持的文件路径时，在 Power BI 服务中应用的敏感度标签会随之一起导出。它包括 Excel、PowerPoint、PDF 和 Power BI Desktop 文件。由于导出的文件会保留敏感度标签，因而为这些受支持的文件格式留有保护优势（加密，以防止未经授权的用户打开文件）。

警告

从 Power BI Desktop 导出到 PDF 文件时，不会为导出的文件保留保护。建议你教内容创建者从 Power BI 服务导出以实现最大的信息保护。

并非所有导出格式都支持信息保护。 Power BI 租户设置中可能会禁用不受支持的格式，例如 .csv、.xml、.mhtml 或 .png 文件（使用 ExportToFile API 时可用）。

提示

建议你仅在必须满足特定法规要求时才限制导出功能。在典型情况下，建议使用 Power BI 活动日志来确定哪些用户正在执行导出。然后，你可以向这些用户传授更高效且更安全的替代方法。

清单 - 在 Power BI 管理门户中规划租户设置的设置方式时，关键决策和操作包括：

确定哪些用户可以应用敏感度标签：讨论并决定是否所有用户（基于标准 Power BI 安全性）都可以为 Power BI 内容分配敏感度标签，还是仅由特定的用户组分配。
确定是否应从上游数据源继承标签：讨论并决定是否应将来自数据源的标签自动应用于使用数据源的 Power BI 内容。
确定是否应由下游项继承标签：讨论并决定是否应将分配给现有 Power BI 语义模型的标签自动应用于相关内容。
确定 Power BI 工作区管理员是否可以替代标签：讨论并决定让工作区管理员能够更改自动分配的受保护标签是否合适。
确定是否可以与整个组织共享受保护的内容：讨论并决定当受保护（加密）标签已分配给 Power BI 服务中的项时，是否可以为“组织中的人员”创建共享链接。
确定启用哪些导出格式：确定将影响可用导出格式的监管要求。讨论并决定用户是否能够使用 Power BI 服务中的所有导出格式。当导出格式不支持信息保护时，确定是否需要在租户设置中禁用某些格式。

数据分类和保护策略

设置标签结构和发布标签策略是必要的第一步。但是，要帮助组织成功地对数据进行分类和保护，还有很多工作要做。请务必向用户提供指导，告诉他们可以对已分配给特定标签的内容做些什么，不能做什么，这一点非常重要。数据分类和保护策略在此便有用武之地。你可以将其视为标签准则。

注意

数据分类和保护策略是一种内部治理策略。你可以用别的名字来称呼它。重要的是创建并提供给用户的文档，以便他们知道如何有效地使用标签。由于标签策略是 Microsoft Purview 合规门户中的特定页面，因此请尽量避免使用相同的名称调用内部治理策略。

建议在决策过程中迭代地创建数据分类和保护策略。这意味着在设置敏感度标签时，一切都已明确定义。

以下是你可能包含在数据分类和保护策略中的一些关键信息。

标签的描述：在标签名称之外，提供标签的完整描述。描述应清晰而简短。以下是一些示例描述：
- 常规内部用途 - 用于专用、内部、业务数据
- 受限 - 用于敏感的业务数据，如果这些数据被泄露会造成损害或受制于监管或合规性要求
示例：提供示例以帮助说明何时使用标签。下面是一些示例：
- 常规内部用途 - 适用于大多数内部通信、非敏感数据支持数据、调查响应、评论、评级和不精确位置数据
- 受限 - 用于个人身份信息 (PII)，如姓名、地址、电话、电子邮件、政府 ID 号码、种族或民族。包括供应商和合作伙伴合同、非公开财务数据、员工和人力资源 (HR) 数据。还包括专有信息、知识产权和精确位置数据。
需要标签：说明是否必须为所有新的和更改的内容分配标签。
默认标签：描述此标签是否是自动应用于新内容的默认标签。
访问限制：说明是否允许内部和/或外部用户查看分配给此标签的内容的附加信息。下面是一些示例：
- 所有用户，包括内部用户、外部用户和签署了有效保密协议 (NDA) 的第三方都可以访问此信息。
- 只有内部用户可以访问此信息。合作伙伴、供应商、承包商或第三方不能访问，无论 NDA 或保密协议的状态如何。
- 对信息的内部访问基于作业角色授权。
加密要求：描述是否需要对静态和传输中的数据进行加密。此信息将与敏感度标签的设置方式关联，并将影响可能为文件 (RMS) 加密实施的保护策略。
允许下载和/或离线访问：描述是否允许离线访问。它还可以定义是否允许在组织设备或个人设备上下载。
如何申请例外：描述用户是否可以申请标准策略的例外，以及如何做到这一点。
审核频率：指定合规性评审的频率。更敏感的标签应该涉及更频繁和更彻底的审核过程。
其他元数据：数据策略需要更多元数据，例如策略所有者、审批者和生效日期。

提示

在创建数据分类和保护策略时，重点是使其成为用户的直接参考。它应该尽可能短和清晰。如果它太复杂，用户就不会总是花时间去理解它。

一种自动实施策略（例如数据分类和保护策略）的方法是使用 Microsoft Entra 使用条款。设置使用条款策略后，用户需要先确认策略，然后才能获得首次访问 Power BI 服务的权限。也可以定期征求一次同意，例如每 12 个月一次。

清单 - 规划内部策略以管理对敏感度标签的使用预期时，关键决策和操作包括：

创建数据分类和保护策略：对于结构中的每个敏感度标签，创建一个集中式策略文档。该文档应定义对每个标签分配的内容可以或无法执行哪些操作。
就数据分类和保护策略达成共识：确保你组建的团队中所有必要的人员都同意这些规定。
考虑如何处理策略的例外：高度分散的组织应考虑是否会出现例外情况。尽管最好有一个标准化的数据分类和保护策略，但要决定在提出新请求时如何处理例外。
考虑在何处查找内部策略：考虑应发布数据分类和保护策略的位置。确保所有用户都可以轻松访问它。在发布标签策略时，计划将其包含在自定义帮助页上。

用户文档和培训

在推出信息保护功能之前，建议为用户创建和发布指导文档。文档的目标是实现无缝用户体验。为用户准备指南也将帮助确保已充分考虑到所有内容。

可以将指南作为敏感度标签的自定义帮助页的一部分发布。集中式门户中的 SharePoint 页面或 Wiki 页面可以很好地工作，因为它易于维护。上传到共享库或 Teams 网站的文档也是一种不错的方法。发布标签策略时，自定义帮助页的 URL 在 Microsoft Purview 合规门户中指定。

提示

自定义帮助页是一个重要资源。在各种应用程序和服务中都提供了指向它的链接。

用户文档应包含前面所述的数据分类和保护策略。该内部策略针对所有用户。感兴趣的用户包括需要了解其他用户分配的标签的含义的内容创建者和使用者。

除了数据分类和保护策略外，建议为内容创建者和所有者准备以下指南：

查看标签：有关每个标签的含义的信息。将每个标签与数据分类和保护策略相关联。
分配标签：有关如何分配和管理标签的指导。包括他们需要知道的信息，例如强制标签、默认标签以及标签继承的工作原理。
工作流：有关如何在其正常工作流中分配和查看标签的建议。一旦开发开始，就可以在 Power BI Desktop 中分配标签，从而在开发过程中保护原始 Power BI Desktop 文件。
情况通知：了解用户可能收到的系统生成的通知。例如，SharePoint 网站被分配到某个敏感度标签，但单个文件已被分配到更敏感（更高）的标签。分配更高标签的用户将收到一封电子邮件通知，指出分配给文件的标签与存储文件的站点不兼容。

包括有关用户如有疑问或技术问题时应联系的人员的信息。由于信息保护是一个组织范围的项目，因此通常由 IT 部门提供支持。

常见问题解答和示例对用户文档特别有用。

提示

一些监管要求包括特定的培训内容。

清单 - 准备用户文档和培训时，关键决策和操作包括：

确定要包括哪些信息：确定应包含哪些信息，以便所有相关受众了解在代表组织保护数据时自己需要做些什么。
发布自定义帮助页：创建和发布自定义帮助页。包括有关以常见问题解答和示例形式标记的指南。包含用于访问数据分类和保护策略的链接。
发布数据分类和保护策略：发布策略文档，该文档定义了对分配给每个标签的内容究竟可以做什么或不可以做什么。
确定是否需要特定培训：创建或更新用户培训以包含有用的信息，尤其是在有监管要求的情况下。

用户支持

确认谁将负责用户支持非常重要。敏感度标签通常由集中式 IT 技术支持提供支持。

你可能需要为支持人员创建指南（有时称为 runbook）。可能还需要开展知识传递会议，以确保支持人员准备好响应支持请求。

清单 - 准备用户支持函数时，关键决策和操作包括：

确定谁将提供用户支持：在定义角色和职责时，请确保包括用户将如何在与信息保护相关的问题上获得帮助。
确保用户支持团队准备就绪：创建文档并开展知识转移会议，以确保技术支持已准备好支持信息保护。强调可能让用户感到困惑的复杂方面，例如加密保护。
团队之间的沟通：与支持团队以及 Power BI 管理员和卓越中心讨论流程和期望。确保所有相关人员都对 Power BI 用户可能提出的问题做好了准备。

实现摘要

在做出决定并满足先决条件后，就可以根据逐步推出计划开始实施信息保护了。

以下清单包含端到端实现步骤的汇总列表。许多步骤都有本文前几节中介绍过的其他详细信息。

清单 - 实施信息保护时，关键决策和操作包括：

验证当前状态和目标：确保你清楚了解组织中信息保护的当前状态。实施信息保护的所有目标和要求都应明确并积极用于推动决策过程。
做出决策：审查和讨论所有需要的决定。此任务应在设置生产环境中的任何内容之前进行。
查看许可要求：确保了解产品许可和用户许可要求。如有必要，获取并分配更多的许可证。
发布用户文档：发布数据分类和保护策略。创建自定义帮助页，其中包含用户所需的相关信息。
准备支持团队：举办知识转移会议，以确保支持团队准备好处理用户的问题。
创建敏感度标签：在 Microsoft Purview 合规门户中设置每个敏感度标签。
发布敏感度标签策略：在 Microsoft Purview 合规门户中创建和发布标签策略。首先在一小群用户中进行测试。
设置 Power BI 租户设置：在 Power BI 管理门户中，设置信息保护租户设置。
执行初始测试：执行一组初始测试，以验证一切正常工作。使用非生产租户进行初始测试（如果可用）。
收集用户反馈：将标签策略发布给一小部分愿意测试功能的用户。获取有关流程和用户体验的反馈。
继续迭代版本：将标签策略发布到其他用户组。加入更多用户组，直到囊括整个组织。

提示

出于规划目的，汇总了这些清单项。有关这些清单项的更多详细信息，请参阅本文前面几节。

持续监视

完成实施后，应该将注意力集中在监视和优化敏感度标签上。

Power BI 管理员和安全与合规性管理员需要不时协作。对于 Power BI 内容，有两个受众关注监视。

Power BI 管理员：每次分配或更改敏感度标签时，都会记录 Power BI 活动日志中的条目。活动日志条目记录事件的详细信息，包括用户、日期和时间、项名称、工作区和容量。其他活动日志事件（例如查看报表时）将包括分配给项的敏感度标签 ID。
安全性和合规性管理员：组织的安全性和合规性管理员通常会使用 Microsoft Purview 报表、警报和审核日志。

清单 - 监视信息保护时，关键决策和操作包括：

验证角色和职责：确保你清楚谁对哪些行为负责。如果 Power BI 管理员或安全管理员将直接负责某些方面的工作，请对他们进行教育并与其沟通。
创建或验证查看活动的过程：确保安全性和合规性管理员明确定期查看活动资源管理器的期望。

提示

有关审核的详细信息，请参阅审核 Power BI 的信息保护和数据丢失防护。

在本系列的下一篇文章中，了解 Power BI 的数据丢失防护。