Power BI 实现规划:Power BI 的数据丢失防护
备注
本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍,请参阅 Power BI 实施规划。
本文介绍与在 Power BI 中实现数据丢失防护 (DLP) 相关的规划活动。 本文面向:
- Power BI 管理员:负责监督组织中 Power BI 的管理员。 Power BI 管理员需要与信息安全团队和其他相关团队协作。
- 卓越中心、IT 和 BI 团队:负责在组织中监督 Power BI 的其他人。 他们可能需要与 Power BI 管理员、信息安全团队和其他相关团队协作。
重要
数据丢失防护 (DLP) 是组织范围内的一项重要工作。 它的范围和影响远远超过 Power BI 本身。 这种类型的计划需要资金支持、设定优先级和做好规划。 预期规划、使用和监督工作中涉及多个跨职能团队。
我们建议你遵循逐步的分阶段方法推出 Power BI 的 DLP。 有关应考虑的推出阶段类型的说明,请参阅 Power BI 的信息保护(推出阶段)。
DLP 的目的
数据丢失防护 (DLP) 是指保护组织数据的活动和做法。 DLP 的目标是降低数据泄露的风险,当与未经授权的人员共享敏感数据时,可能会发生数据泄露。 尽管负责任的用户行为是数据保护的关键部分,但 DLP 通常指自动执行的策略。
DLP 允许你:
- 在发生有风险的、无意或不当的敏感数据共享时,检测该行为并通知管理员。 具体而言,它允许以下操作:
- 通过自动化和信息改进 Power BI 租户的整体安全设置。
- 启用涉及敏感数据的分析用例。
- 向安全管理员提供审核信息。
- 向用户提供上下文通知。 具体而言,它允许以下操作:
- 帮助用户在其正常工作流程中做出正确的决策。
- 指导用户遵循数据分类和保护策略,而不会对其工作效率产生负面影响。
DLP 服务
一般来说,有两种不同的服务可以实现数据丢失防护。
- Power BI 的 Microsoft Purview DLP 策略
- Microsoft Defender for Cloud Apps
Power BI 的 Microsoft Purview DLP 策略
Power BI 的 DLP 策略在 Microsoft Purview 合规门户中设置。 它可以检测已发布到Power BI 服务高级工作区的语义模型中的敏感数据。
重要
有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意,Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。
有关详细信息,请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。
这种类型的 DLP 策略的目标是让用户了解并通知管理员敏感数据的存储位置。 DLP 策略可以根据敏感信息类型或敏感度标签生成用户通知和管理员警报。 例如,你可以确定信用卡信息或个人可识别信息 (PII) 是否存储在语义模型中。
注意
Power BI 的 DLP 是本文的重点。
Microsoft Defender for Cloud Apps
Microsoft Defender for Cloud Apps 是一种具有许多功能的工具。 可以在 Microsoft Defender for Cloud Apps(与 Microsoft Entra ID 集成)中设置的一些策略包括 DLP。 当某些用户活动发生时,这些策略可以阻止、记录或发出警报。 例如,当用户尝试从已分配有高度受限敏感度标签的 Power BI 服务下载报表时,下载操作将被阻止。
Defender for Cloud Apps for Power BI 一文介绍了如何使用 Defender for Cloud Apps 监视 Power BI 服务。 此文章的其余部分重点介绍了 Power BI 的 DLP。
重要
在 Microsoft Purview 合规门户中设置的 Power BI 的 DLP 策略只能应用于存储在 Power BI Premium 工作区中的内容。 但是,在 Defender for Cloud Apps 中设置的策略没有类似的 Power BI Premium 先决条件。 请注意,这两个工具集的功能、用途和可用操作有所不同。 为了达到最佳效果,我们建议你考虑同时使用这两个工具集。
Power BI 的 DLP 的先决条件
到目前为止,你应该已经完成了 Power BI 的信息保护一文中描述的组织级规划步骤。 在继续操作之前,你应该明确:
通常,在实现 DLP 之前,先实现信息保护(Power BI 的信息保护一文有所介绍)。 但是,这并不是使用 Power BI 的 DLP 的先决条件。 如果已发布敏感度标签,则可以将其与 Power BI 的 DLP 一起使用。 还可以将敏感信息类型与 Power BI 的 DLP 一起使用。 这两种类型在本文中均有描述。
关键决策和操作
DLP 策略的目的是根据规则和条件,对要保护的内容设置自动操作。 你需要就支持你的目标和要求的规则和条件做出一些决策。
在单个 DLP 策略中定义单独的规则的优点是,可以启用自定义警报或用户通知。
需要考虑 DLP 策略列表以及 DLP 策略规则的分层优先级。 优先级将影响第一次遇到策略时调用的策略。
注意
本部分并不是针对所有可能的应用程序的所有可能的 DLP 决策的详尽列表。 请务必与其他利益干系人和系统管理员共同商议,做出适合所有应用程序和用例的决策。 例如,我们建议你调查其他 DLP 策略,用于保护存储在 OneDrive 或 SharePoint 中的源文件和导出的文件。 这组文章仅重点介绍 Power BI 服务中的内容。
敏感数据的类型
在 Microsoft Purview 合规门户中设置的 Power BI 的 DLP 策略可以基于敏感度标签或敏感信息类型。
重要
虽然可以为 Power BI 中大多数类型的项分配敏感度标签,但本文中所述的 DLP 策略侧重于语义模型。 语义模型必须发布到高级工作区。
敏感度标签
可以使用敏感度标签对内容进行分类,范围为不太敏感到更加敏感。
调用 Power BI 的 DLP 策略时,敏感度标签规则会检查语义模型(已发布到 Power BI 服务)是否存在特定的敏感度标签。 如 Power BI 的信息保护一文所述,标签可由用户或自动化过程分配(例如继承的标签或默认标签)。
下面是有关何时可能基于敏感度标签创建 DLP 规则的一些示例。
- 法规符合性:你有一个为受特定法规要求约束的数据预留的敏感度标签。 当用户将该敏感度标签分配给 Power BI 服务中的语义模型时,你希望为安全管理员生成警报。
- 有关机密数据的内容创建者提醒:你有一个用于机密数据的敏感度标签。 当用户在 Power BI 服务的数据中心内查看语义模型详细信息页时,你希望生成用户通知。 例如,你可以提醒用户如何正确处理机密数据。
有关用户通知和警报的其他注意事项将在本文的下一部分中介绍。
清单 - 在考虑对敏感度标签规则的需求时,关键决策和操作包括:
- 验证信息保护的当前状态:确保组织中已部署敏感度标签,并且这些标签随时可供 DLP 策略使用。
- 基于敏感度标签编译 DLP 用例:确定哪些敏感度标签受益于 DLP 策略。 考虑你的目标、法规和内部要求。
- 根据敏感度标签确定 DLP 用例列表的优先级:与团队讨论首要任务。 确定项目计划中要优先考虑的项。
注意
DLP 策略通常是自动执行的。 但是,负责任的用户操作在保护数据方面也发挥着重要作用。
有关详细信息,请参阅 Power BI 的信息保护(数据分类和保护策略)。 它描述了一种内部治理策略,该策略提供了有关用户可以和不能对分配有特定敏感度标签的内容进行的操作的指导。
敏感信息类型
并非所有类型的数据都是相同的;某些类型的数据本质上比其他类型的数据更加敏感。 有许多不同的敏感信息类型 (SIT)。 根据你的行业和符合性要求,只有部分 SIT 适用于你的组织。
SIT 的一些常见示例包括:
- 护照号、社会保险号和驾照号
- 银行帐号和路由号
- 信用卡号和借记卡号
- 税标识号和身份证号
- 健康标识号和医疗信息
- 实际地址
- 帐户密钥、密码和数据库连接字符串
提示
如果敏感数据没有分析价值,问问自己它是否应该驻留在分析系统中。 我们建议你教导内容创建者,帮助他们就要在 Power BI 中存储哪些数据做出正确的决策。
SIT 是基于模式的分类器。 它们将使用正则表达式查找文本中的已知模式。
可以在 Microsoft Purview 合规门户中找到许多预配置的 SIT。 当它们满足你的要求时,你应使用预配置的 SIT 以节省时间。 考虑信用卡号预配置的 SIT:它会检测所有主要发卡机构的正确模式、确保校验和的有效性,并在接近信用卡号的范围内搜索相关关键字。
如果预配置的 SIT 不满足你的需求,或者你具有专有的数据模式,则可以创建自定义 SIT。 例如,可以创建自定义 SIT 以匹配员工 ID 号的模式。
设置 SIT 后,在上传或刷新语义模型时,将调用 Power BI 的 DLP 策略。 此时,敏感信息类型规则将检查语义模型(在 Power BI 服务中)是否存在敏感信息类型。
下面是有关何时可能基于敏感信息类型创建 DLP 规则的一些示例。
- 法规符合性:你有一种受法规要求约束的敏感信息类型。 当在 Power BI 服务的语义模型中检测到该类型的数据时,你希望为安全管理员生成警报。
- 内部要求:你有一个需要特殊处理的敏感信息类型。 为了满足内部要求,你希望在用户查看数据中心(在 Power BI 服务中)中的语义模型设置或语义模型详细信息页时生成用户通知。
清单 - 在考虑对敏感信息类型的需求时,关键决策和操作包括:
- 基于敏感信息类型编译 DLP 用例:确定哪些敏感信息类型受益于 DLP 策略。 考虑你的目标、法规和内部要求。
- 测试现有敏感信息类型:与信息安全团队合作,验证预配置的 SIT 是否满足你的需求。 使用测试数据确认正确检测到模式和关键字。
- 创建自定义敏感信息类型:如果适用,与信息安全团队合作创建 SIT,以便可以在 Power BI 的 DLP 中使用。
- 确定用例列表的优先级:与团队讨论首要任务。 确定项目计划中要优先考虑的项。
用户通知
使用敏感度标签和 SIT 确定 DLP 用例后,接下来应考虑当 DLP 规则匹配时会发生什么情况。 通常,它涉及用户通知。
DLP 策略的用户通知也称为策略提示。 当你想要在用户的正常工作过程中为他们提供更多的指导和意识时,它们非常有用。 如果用户通知具有以下属性,则用户更有可能读取和理解用户通知:
- 特定:将消息与规则关联可使消息更易于理解。
- 可操作:就用户需要执行什么操作或如何查找更多信息提供建议。
对于 Power BI 中的 DLP,用户通知将显示在语义模型设置中。 它们还会显示在数据中心的语义模型详细信息页顶部,如以下屏幕截图所示。 在本例中,通知显示:此数据包含信用卡。根据数据分类、保护和使用策略,Power BI 中不允许使用此类型的数据。
可以为每项 DLP 策略定义一条或多条规则。 每条规则可以有一个将向用户显示的不同策略提示。
考虑以下示例,了解如何定义 DLP 策略以检测 Power BI 服务的语义模型中存储的财务数据。 DLP 策略使用 SIT,并且具有两条规则。
- 规则 1:第一条规则检测信用卡号。 自定义策略提示文本显示:此数据包含信用卡号。根据数据分类和保护策略,Power BI 中不允许使用此类型的数据。
- 规则 2:第二条规则检测财务帐户。 自定义策略提示文本显示:此数据包含敏感的财务信息。它需要使用高度受限标签。有关存储财务数据时的要求,请参阅数据分类和保护策略。
规则 1 比规则 2 更紧急。 规则 1 旨在传达存在需要进行操作的问题。 第二条规则更具信息性。 对于紧急问题,最好设置警报。 下一部分将介绍管理员警报。
在确定用户应接收哪些通知时,我们建议你侧重于仅显示非常重要的通知。 如果策略通知过多,用户可能会不知所措。 结果就是一些通知可能会被忽略。
当用户认为某个问题是误报(识别错误)时,他们可以通过报告该问题来采取操作。 还可以允许用户覆盖策略。 这些功能旨在允许 Power BI 用户与管理 Power BI 的 DLP 的安全管理员之间的通信。
清单 - 考虑 DLP 用户通知时,关键决策和操作包括:
- 确定何时需要用户通知:对于要创建的每条 DLP 规则,确定是否需要自定义用户通知。
- 创建自定义策略提示:对于每个通知,定义应向用户显示哪些消息。 计划将消息关联到 DLP 规则,使其具有特定性和可操作性。
管理员警报
当想要在发生策略冲突的情况下跟踪事件时,警报对于某些 DLP 规则非常有用。 在定义 DLP 策略规则时,考虑是否应生成警报。
提示
警报旨在提醒管理员注意某些情况。 它们最适合打算主动调查和解决重要警报的情况。 可以在 Microsoft Purview 合规门户的活动资源管理器中找到所有 DPS 规则匹配项。
在以下情况下,警报非常有用:
- 想要通过 DLP 警报管理仪表板让安全和合规管理员知道发生了某些事情。 还可以选择向一组特定用户发送电子邮件。
- 想要查看发生的事件的更多详细信息。
- 想要将事件分配给某人进行调查。
- 想要管理事件的状态或向其添加注释。
- 想要查看针对同一用户的活动生成的其他警报。
每个警报都可以由严重性级别定义,该级别可以是低、中或高。 严重性级别有助于确定待处理警报的审查的优先级。
下面是有关如何使用警报的两个示例。
示例 1:你定义了一项 DLP 策略,用于检测 Power BI 服务的语义模型中存储的财务数据。 该 DLP 策略使用敏感信息类型。 它有两条规则。
- 规则 1:此规则检测信用卡号。 已启用警报,其严重性为高。 还生成了一封电子邮件。
- 规则 2:此规则检测财务帐户。 已启用警报,其严重性为高。
示例 2:你定义了一项 DLP 策略,在将“高度受限\执行委员会和董事会成员”敏感度标签分配给 Power BI 服务中的语义模型时将调用该策略。 它不会生成用户通知。 在这种情况下,你可能不希望生成警报,因为你只想记录发生的情况。 如果需要,可以从活动资源管理器获取更多信息。
当需要电子邮件警报时,我们建议你使用启用了邮件的安全组。 例如,可以使用名为“安全和隐私管理员警报”的组。
提示
请记住,每次上传或刷新语义模型时,都会检查 Power BI 的 DLP 规则。 这意味着每次刷新语义模型时都会生成警报。 定期或频繁的数据刷新可能会导致生成大量记录的事件和警报。
清单 - 在考虑管理员的 DLP 警报时,关键决策和操作包括:
- 确定何时需要警报:对于要创建的每项 DLP 规则,确定哪些情况需要使用警报。
- 阐明角色和职责:确定预期和生成警报时应采取的特定操作。
- 确定谁将接收警报:确定哪些安全和合规管理员将处理待处理警报。 确认将使用 Microsoft Purview 合规门户的每个管理员都满足权限和许可要求。
- 创建电子邮件组:如有必要,创建启用了邮件的新安全组,以处理警报。
范围内的工作区
在 Microsoft Purview 合规门户中设置的 Power BI 的 DLP 策略旨在面向语义模型。 具体而言,它支持扫描已发布到高级工作区的语义模型。
可以设置 DLP 策略以扫描所有高级工作区。 也可以选择包括或排除特定工作空间。 例如,你可能会排除某些被认为风险较低的开发或测试工作区(特别是在它们不包含实际生产数据时)。 或者,你可以为某些开发或测试工作区创建单独的策略。
提示
如果确定仅为 DLP 包括部分高级工作区,请考虑维护级别。 当包括所有高级工作区时,DLP 规则更易于维护。 如果确定仅包括部分高级工作区,请确保有一个审核过程,以便能够快速确定 DLP 策略中是否缺少新工作区。
有关工作区的详细信息,请参阅文章工作区规划。
清单 - 在考虑为 DLP 包括哪些工作区时,关键决策和操作包括:
- 确定哪些高级工作区应该应用 DLP:考虑 DLP 策略是应该影响所有 Power BI Premium 工作区,还是仅影响部分该工作区。
- 为工作区分配创建文档:如果适用,记录哪些工作区受 DLP 约束。 包括包含或排除工作区的条件和原因。
- 将 DLP 决策与工作区治理相关联:如果适用,更新工作区治理文档,以包括有关如何处理 DLP 的详细信息。
- 考虑其他重要文件位置:除了 Power BI 服务外,确定是否还需要创建其他 DLP 策略来保护 OneDrive 或 SharePoint 中存储的源文件和导出的文件。
许可要求
若要使用 DLP,有几个许可要求。 设置、管理和监视 DLP 的管理员需要 Microsoft Purview 信息保护许可证。 你可能已经拥有这些许可证,因为它们包含在某些许可套件中,例如 Microsoft 365 E5。 或者,可以将 Microsoft 365 E5 合规功能作为独立许可证进行购买。
此外,Power BI 的 DLP 策略需要 Power BI Premium。 使用高级容量或 Premium Per User (PPU) 许可证可以满足此许可要求。
提示
如果需要有关许可要求的说明,请联系 Microsoft 帐户团队。 请注意,Microsoft 365 E5 合规许可证包含其他 DLP 功能,这些功能不在本文的探讨范围内。
清单 - 评估 DLP 许可要求时,关键决策和操作包括:
- 查看产品许可要求:确保已查看 DLP 的所有许可要求。
- 查看高级许可要求:验证要为 DLP 配置的工作区是否为高级工作区。
- 购买其他许可证:如果适用,购买更多许可证以解锁要使用的功能。
- 分配许可证:向需要许可证的每个安全和合规管理员分配许可证。
用户文档和培训
在推出 Power BI 的 DLP 之前,我们建议你创建和发布用户文档。 集中式门户中的 SharePoint 页面或 Wiki 页面可以很好地工作,因为它易于维护。 上传到共享库或 Teams 网站的文档也是一种不错的解决方案。
文档的目标是实现无缝用户体验。 准备用户文档还将帮助你确保已考虑所有问题。
包括有关用户在遇到疑问或技术问题时应联系的人员的信息。 由于信息保护是一个组织范围的项目,因此通常由 IT 部门提供支持。
常见问题解答和示例对用户文档特别有用。
提示
有关详细信息,请参阅 Power BI 的信息保护(数据分类和保护策略)。 它介绍了创建数据分类和保护策略,以便用户了解使用敏感度标签可以和不能执行的操作方面的建议。
清单 - 准备用户文档和培训时,关键决策和操作包括:
- 更新内容创建者和使用者的文档:更新常见问题解答和示例,以包含有关 DLP 策略的相关指导。
- 发布如何获得帮助:确保用户知道在遇到意外情况或不理解的内容时如何获得帮助。
- 确定是否需要特定培训:创建或更新用户培训以包含有用的信息,尤其是在有监管要求的情况下。
用户支持
确认谁将负责用户支持非常重要。 DLP 通常由集中式 IT 支持人员提供支持。
你可能需要为支持人员创建指南(有时称为 runbook)。 可能还需要开展知识传递会议,以确保支持人员准备好响应支持请求。
清单 - 在准备用户支持功能时,关键决策和操作包括:
- 确定谁将提供用户支持:在定义角色和职责时,确保说明用户将如何获得与 DLP 有关的问题的帮助。
- 确保用户支持团队准备就绪:创建文档并开展知识传递会议,以确保支持人员已准备好支持 DLP。
- 团队之间进行通信:与支持团队以及 Power BI 管理员和卓越中心讨论用户通知和解决 DLP 警报的流程。 确保所有相关人员都对 Power BI 用户可能提出的问题做好了准备。
实现和测试汇总
做出决策并满足先决条件后,即可开始实现和测试 Power BI 的 DLP。
Power BI 的 DLP 策略在 Microsoft 365 管理中心的 Microsoft Purview 合规门户(以前称为 Microsoft 365 合规中心)中设置。
提示
在 Microsoft Purview 合规门户中设置 Power BI 的 DLP 的过程仅涉及一个步骤,而设置策略是两个步骤。 此过程与在 Microsoft Purview 合规门户中设置信息保护(Power BI 的信息保护一文中有所介绍)时不同。 在那种情况下,有两个单独的步骤用于设置标签并发布标签策略。 在这种情况下,DLP 的实现过程只有一个步骤。
以下清单包含端到端实现步骤的汇总列表。 许多步骤都有本文前面部分介绍过的其他详细信息。
清单 - 实现 Power BI 的 DLP 时,关键决策和操作包括:
- 验证当前状态和目标:确保你清楚了解用于 Power BI 的 DLP 的当前状态。 实现 DLP 的所有目标和要求都应明确并积极用于推动决策过程。
- 做出决策:查看和讨论需要的所有决策。 此任务应在设置生产环境中的任何内容之前进行。
- 查看许可要求:确保了解产品许可和用户许可要求。 如有必要,获取并分配更多的许可证。
- 发布用户文档:发布用户将需要的信息以回答问题和阐明预期。 为用户提供指导、沟通和培训,以便他们做好准备。
- 创建 DLP 策略:在 Microsoft Purview 合规门户中,创建并设置每项 DLP 策略。 请参阅之前为设置 DLP 规则所做的所有决策。
- 执行初始测试:执行一组初始测试,以验证一切已正确设置。 结合使用测试模式和一些示例数据来确定是否一切都按预期运行,同时尽量降低对用户的影响。 最初使用一小部分高级工作区。 在有权访问非生产租户时,考虑使用非生产租户。
- 收集用户反馈:获取有关流程和用户体验的反馈。 识别容易混淆的地方或具有敏感信息类型的意外结果以及其他技术问题。
- 继续迭代版本:逐步将更多高级工作区添加到 DLP 策略,直到它们全部都包含在内。
- 监视、优化和调整:经常投入资源以查看策略匹配警报和审核日志。 调查误报,并在必要时调整策略。
提示
出于规划目的,汇总了这些清单项。 有关这些清单项的更多详细信息,请参阅本文的前面部分。
有关初始推出之外的其他步骤,请参阅结合使用 Defender for Cloud Apps 和 Power BI。
持续监视
完成实现后,应考虑根据 DLP 策略的使用情况监视、强制实施和调整 DLP 策略。
Power BI 管理员与安全和合规管理员需要不时进行协作。 对于 Power BI 内容,有两个受众可进行监视。
- Power BI 管理员:每次 DLP 规则匹配时,都会记录 Power BI 活动日志中的条目。 Power BI 活动日志条目记录 DLP 事件的详细信息,包括用户、日期和时间、项名称、工作区和容量。 它还包括有关策略的信息,例如策略名称、规则名称、严重性和匹配条件。
- 安全和合规管理员:组织的安全和合规管理员通常会使用 Microsoft Purview 报表、警报和审核日志。
警告
不会实时监视 Power BI 的 DLP 策略,因为生成 DLP 日志和警报需要时间。 如果你的目标是实时强制实施,请参阅 Defender for Cloud Apps for Power BI(实时策略)。
清单 - 监视 Power BI 的 DLP 时,关键决策和操作包括:
- 验证角色和职责:确保你清楚谁负责哪些操作。 如果 Power BI 管理员或安全管理员将直接负责 DLP 监视的某些方面,请对他们进行教导并与之沟通。
- 创建或验证查看活动的过程:确保安全和合规管理员清楚定期查看活动资源管理器的期望。
- 创建或验证解决警报的过程:确保安全和合规管理员具备一个流程,用于在策略匹配时调查和解决 DLP 警报。
提示
有关审核的详细信息,请参阅审核 Power BI 的信息保护和数据丢失防护。
相关内容
在本系列的下一篇文章中,了解如何结合使用 Defender for Cloud Apps 和 Power BI。