构造数据流 和 Power Platform 数据流 Microsoft 365 服务，使用户能够跨数百个受支持的数据源轻松连接、提取、移动和转换数据。 数据流基于名为 Power Query Online 的基础服务构建，该服务将数据移动引擎（Mashup 引擎）作为云服务托管。 默认情况下，连接源自此云位置，并且对 Internet 的访问不受限制。 因此，使用数据流访问和移动敏感数据时，组织应考虑策略来阻止内部人员意外或恶意数据外泄。 本文概述了有关安全措施的已知风险因素和最佳做法。
注意事项
任意代码执行
数据流 ETL 作业是通过用名为 Power Query M 的语言编写的程序定义的。在默认配置中，Mashup 引擎在云中、租户网络边界外部以及不受限制的 Internet 访问中执行这些程序。 用户可以创作连接到多个数据源的程序，并在同意后允许数据在这些源之间流动。
有权访问敏感数据的受信任用户可以创作一个程序，以将数据推送到不受信任的数据存储。 由于 Mashup 引擎完全在云中运行，因此它不会通过企业防火墙和代理服务器。 因此，它不受这些网络可能强制执行的任何数据丢失防护（DLP）策略的约束。 由于访问点位于公共 Internet 上，因此数据可以通过身份验证或匿名访问前往用户有权访问的任何目标。 下面是这些程序可以外泄敏感数据的方法的一些示例：
- 匿名 Web 请求：通过使用 Web.Contents，用户可以在请求正文中使用敏感数据发出 Web 请求。
- 跨数据源筛选和联接：敏感数据可用作针对另一个不受信任的数据源的筛选或联接条件。 具体而言，数据可以以查询字符串或参数的形式前往不受信任的数据源。
- 输出目标：通过使用 Fabric 数据流，用户可以为其查询指定输出目标，从而将数据传输到受支持的数据接收器列表，其中包括 Azure SQL 数据库和数据仓库、Fabric Lakehouses、Warehouses 和 KQL 数据库。
跨租户数据移动
Mashup 引擎要求在建立连接之前显式定义数据源。 数据源绑定到具有种类和路径键的程序（例如 SQL;contoso.database.windows.net）。 通过基于数据源路径进行筛选，此绑定为组织提供了管理允许哪些数据源的机会。 但是，在某些数据源中，路径在所有连接中都是通用的，并且数据仅按已登录用户的 OAuth 凭据的租户进行分段。 此方案为数据外泄创建一个风险因素，其中用户登录到更高的安全租户和较低的安全租户，并在它们之间移动数据。 可以通过两种方式通常完成数据外泄：
- 出口：在较高安全性租户中，受信任用户定义环境中的数据流，并为允许的数据接收器创建输出目标，但使用来自较低安全性租户的帐户对数据接收器进行身份验证。
- 输入：较低安全租户中的用户定义了一个数据流，从较高安全租户中的敏感数据源读取数据。 可以通过使用较高安全租户中受信任的帐户对敏感数据源进行身份验证来实现此定义。
建议的最佳做法
DLP 策略可以在各种 OSI 层上运行。 通常，数据越敏感，必须应用策略的层越低。 较低层协议的实现成本通常更高，缩放难度更高，作难度更大。 例如，治理要求较低的组织可能只需要应用应用程序层策略。 但是，某些组织和实体处理高度敏感数据可能需要采取极端措施，例如物理隔离。 我们建议处理敏感数据的组织使用应用程序和网络级策略的组合来防范内部威胁。
网络隔离
建议隔离包含敏感数据的所有数据存储，以仅允许从所选网络进行访问。 必须在网络层或更低层定义和作此隔离限制。 例如，第 3 层防火墙、网络安全组（NSG）和 Azure 专用链接是可以使用的机制的良好示例。 但是，Microsoft Entra ID 中基于位置的条件访问策略在应用程序层运行，并被视为不足以实现此目的。
这些网络隔离策略必须阻碍数据流的云执行引擎到敏感数据存储的视线（因为云引擎在公共 Internet 上运行）。 然后，通过将连接绑定到本地数据网关或 VNet 数据网关，强制数据流与这些数据存储的连接源自其中一个允许的网络。 数据流的一个重要执行特征是，从不混合基于云的评估和基于网关的评估。 如果数据流需要访问网络隔离数据存储（因此绑定到网关），则需要所有数据访问才能流经网关。 此外，由于网关在物理上驻留在用户租户控制的网络中，因此它们符合防火墙和 DLP 保护解决方案等网络级别限制。 这些限制使网关环境与任何公司托管设备一样安全，并缓解与云环境中任意代码执行相关的风险。
值得注意的是，网络隔离必须应用于可能包含敏感数据的所有数据存储。 请考虑用户创建数据流以将数据从 OneDrive for Business 读取到 Power BI 的示例。 然后，用户随后会创建链接数据流，将 Power BI 中的数据转换为下游实体。 在此方案中，仅将 OneDrive for Business 隔离到受信任的网络是不够的。 由于敏感数据可能也驻留在 Power BI 中，因此必须通过启用专用链接并禁用 Power BI 的公共 Internet 访问来隔离此类数据。 详细了解如何使用专用终结点保护对 Power BI 的访问。
强制网关执行
将敏感数据存储隔离到所选网络的目标是确保访问起源于受信任的网络，从而利用现有的托管设备管理策略来控制数据流中的数据流动。 在某些情况下，完整的网络隔离解决方案可能需要一些时间来开发、测试和部署。 或者，您可以提交数据流支持工单，以申请一个在整个租户范围内关闭 Mashup 引擎的策略。 此策略会影响使用 Power Query Online Mashup 引擎的所有查询评估。 受影响的功能包括：
- Fabric 数据流
- Power Platform 数据流
- Azure 数据工厂整理数据流
- Dynamics 365 中的数据流（Customer Insights、Intelligent Order Management 等）
- Power BI 数据市场
- Power BI 从 SharePoint 快速导入
应用策略后，所有基于云的执行都失败并出现以下错误： Cloud evaluation request denied based on tenant policies. Please use a data gateway and try again. 此错误有效地强制租户中的所有查询评估在网关上发生，而无需首先推出完整的网络隔离解决方案。 请注意，策略应用于整个租户，而不是工作负荷的子集。 此策略意味着现有工作负荷会立即失败，并需要手动干预以转换为在网关上运行。 应用此策略的组织还应确保其网关群集中有足够的容量来容纳其所有工作负荷。
租户隔离
对于大多数软件即服务（SaaS）层数据存储（如 Fabric Lakehouse 和 Power Platform Dataverse），通常有一个多租户终结点，一个与该终结点通信以获取数据访问权限。 这些终结点在服务的所有用户中很常见，因此很难仅使用网络（第 3 层）隔离技术来隔离和保护这些终结点。 此类数据存储的建议方法是使用第 7 层策略，通常由 Microsoft Entra ID 提供：
- 仅允许Microsoft Entra ID 身份验证。 从数据存储中删除匿名和用户名/密码身份验证方案。
- 使用位置策略仅允许从托管设备登录到受保护的租户。 了解详细信息。
- 使用 Microsoft Entra ID 租户限制禁止来自托管设备的未知租户登录。 使用租户限制来管理对 SaaS 应用的访问权限。 了解详细信息。
此方法将对租户敏感数据存储的访问限制在一组托管设备上，并确保这些设备不允许登录其他租户，从而有效地隔离跨租户的数据流动。
路线图
以下列表包含当前计划帮助组织更好地管理 Fabric 中的数据外泄风险的一些功能：
- 数据源连接允许列表：允许 Fabric 租户管理员控制可在租户中使用的连接器类型，连接器可以连接到的终结点。
- 连接使用情况审核：支持审核跟踪连接创建、更新、删除和使用情况的审核日志。