Tip
Power BI Dataflow Gen1 現在處於舊版狀態，不會再投資新功能。 對於具備 Fabric 存取權的高級用戶， Dataflow Gen2 是推薦的路徑，提供效能、規模、可靠性、功能性及內建 AI 的提升。 Pro/PPU 客戶可以繼續使用 Gen1，因為 Gen2 在這類情境下的指引正在演進中。 請參閱從 Dataflow Gen1 升級到 Dataflow Gen2 以獲得升級指引。
網狀架構數據流 和 Power Platform資料流 Microsoft 365個服務，可讓用戶輕鬆地跨數百個支持的數據源連線、擷取、移動及轉換數據。 數據流會以稱為 Power Query Online 的基礎服務為基礎，此服務會將數據行動引擎 （Mashup Engine） 裝載為雲端服務。 根據預設，連線源自此雲端位置，且對因特網的存取不受限制。 因此，使用數據流來存取和移動敏感數據時，組織應該考慮策略來阻止內部人員意外或惡意數據外流。 本文概述已知的風險因素和保護措施的最佳做法。
考慮事項
任意程式代碼執行
數據流 ETL 作業是透過以稱為 Power Query M 的語言撰寫的程式所定義。在預設組態中，Mashup 引擎會在雲端、租用戶網路界限之外，以及不受限制的因特網存取來執行這些程式。 用戶可以撰寫程式來連接多個數據來源，在獲得同意的情況下，允許數據在這些來源之間流動。
可存取敏感數據的受信任使用者，可以撰寫程式，將數據推送至不受信任的數據存放區。 由於 Mashup 引擎完全在雲端中執行，因此不會通過公司防火牆和 Proxy 伺服器。 因此，它不受這些網路可能強制執行的任何數據外洩防護 （DLP） 原則所約束。 由於存取點位於公用因特網上，數據可以前往使用者可存取的任何目的地，無論是透過驗證或匿名存取。 以下是這些程式可外洩敏感數據的一些範例：
- 匿名 Web 要求：藉由使用 Web.Contents，用戶可以在要求的本文中提出具有敏感數據的 Web 要求。
- 跨數據來源篩選與連結：可以利用敏感數據作為條件來篩選或連結到其他不受信任的數據來源。 具體來說，數據可以以查詢字串或參數的形式移至不受信任的數據源。
- 輸出目的地：藉由使用 Fabric 數據流，使用者可以指定其查詢的輸出目的地，藉此將數據傳輸到支持的數據接收清單，其中包括 Azure SQL 資料庫和數據倉儲、Fabric Lakehouses、Warehouses 和 KQL 資料庫。
跨租戶資料傳輸
Mashup 引擎需要在建立連接之前明確定義數據源。 資料來源會繫結至具有種類和路徑索引鍵的程式（例如 ， SQL;contoso.database.windows.net。 此系結可讓您的組織根據數據源路徑進行篩選，以控管允許的數據源。 不過，有一些數據源在所有連線中的路徑都是相同的，數據僅由已登入使用者的 OAuth 認證所屬租戶來分割。 此情境會建立數據外流的風險因素，當使用者登入到安全性較高的租戶和安全性較低的租戶之間轉移數據時。 一般而言，資料外洩可以透過兩種方式來完成：
- 輸出：較高安全性租戶中的受信任使用者定義該環境中的數據流，並將輸出目的地建立至允許的數據匯入，但會使用來自較低安全性租戶的帳戶向數據匯入進行驗證。
- 輸入：在較低安全性租戶中的使用者定義了一個數據流，從較高安全性租戶中的敏感資料來源讀取數據。 您可以使用較高安全性租使用者中的受信任帳戶，針對敏感數據來源進行驗證，即可達成此定義。
建議最佳做法
DLP 原則可以在各種 OSI 層運作。 一般而言，數據越敏感，必須套用原則的層級越低。 較低層級的通訊協定通常成本較高，實作較昂貴、擴展較困難，且運行較為複雜。 例如，具有較低治理需求的組織可能只需要套用應用層原則。 不過，某些處理高度敏感資料的組織與實體可能需要採取極端措施，例如實體隔離措施。 我們建議處理敏感數據的組織採用應用程式和網路層級原則的組合，以防止內部威脅。
網路隔離
建議您隔離包含敏感數據的所有數據存放區，只允許從選取的網路進行存取。 此隔離限制必須在網路層或較低層級定義及運作。 例如，第 3 層防火牆、網路安全組 （NSG） 和 Azure Private Link 是可使用的機制範例。 不過，Microsoft Entra ID 中的位置型條件式存取原則會在應用層運作，因此視為此用途不足。
這些網路隔離原則必須阻礙數據流的雲端執行引擎到敏感數據存放區的視線（因為雲端引擎是在公用因特網上執行）。 資料流程與這些資料存放區的連線需強制自允許網路之一起始，方法是將連線綁定至內部部署資料閘道或 VNet 資料閘道。 數據流的重要執行特性是雲端式評估與閘道型評估永遠不會混合。 如果數據流需要存取網路隔離的數據存放區（因此系結至閘道），則所有數據存取都必須流經網關。 此外，由於網關實際上位於使用者租使用者所控制的網路中，因此它們符合防火牆和 DLP 保護解決方案等網路層級限制。 這些限制讓閘道環境與任何公司管理的裝置一樣安全且安全，並降低與雲端環境中任意程式代碼執行相關聯的風險。
值得注意的是，網路隔離必須套用至可能包含敏感數據的所有數據存放區。 請考慮使用者建立數據流以將數據從商務用 OneDrive 讀取到 Power BI 的範例。 然後使用者稍後會建立鏈接數據流，將 Power BI 中的數據轉換成下游實體。 在此案例中，僅將商務用 OneDrive 隔離至信任的網路就不足。 由於敏感數據可能也位於Power BI內，因此請務必啟用私人連結並停用Power BI的公用因特網存取，以隔離這類數據。 深入瞭解使用私人端點保護對 Power BI 的存取。
強制閘道執行
將敏感數據存放區隔離至所選網路的目標，是強制存取來源回到信任的網路，以便用來控管受管理裝置的現有原則，以控管數據流中的數據移動。 在某些情況下，完整的網路隔離解決方案可能需要時間來開發、測試及部署。 或者，您可以提交數據流支援票證，以應用一項關閉 Mashup 引擎的整個租戶原則。 此原則會影響使用 Power Query Online Mashup 引擎的所有查詢評估。 受影響的功能包括：
- 網狀架構數據流
- Power Platform 資料流
- Azure Data Factory 整頓數據流
- Dynamics 365 中的數據流（Customer Insights、Intelligent Order Management 等等）
- 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 標識碼提供：
- 只允許Microsoft Entra ID 驗證。 從資料存放區移除匿名和使用者名稱/密碼驗證配置。
- 使用位置原則只允許從受管理的裝置登入受保護的租使用者。 深入瞭解。
- 使用 Microsoft Entra ID 租使用者限制禁止來自受控裝置的未知租使用者登入。 使用租使用者限制來管理 SaaS 應用程式的存取權。 深入瞭解。
此方法將租戶的敏感數據存放區的存取限制為一組已管理的裝置，這些裝置不允許登入另一個租戶，從而在租戶之間有效地隔離數據移動。
藍圖
下列清單包含一些目前計劃協助組織更妥善管理 Fabric 中的數據外泄風險的功能：
- 數據源 連線允許清單：允許 Fabric 租戶管理員控制可在租戶中使用的連接器類型，以及連接器可以連接的具體端點。
- 聯機使用狀況稽核：支持追蹤連線建立、更新、刪除和使用量的稽核記錄。