Power BI 安全性技術白皮書

  • 發行項

摘要：Power BI 是 Microsoft 提供的線上軟體服務 (稱為 SaaS 或軟體即服務)，能讓您輕鬆快速地建立自助商業智慧儀表板、報表、語意模型 (先前稱為資料集) 和視覺效果。 使用 Power BI，您可以連線到許多不同的資料來源、結合與塑造來自這些連線的資料，然後建立與其他人共用的報表和儀表板。

作者：Yitzhak Kesselman、Paddy Osborne、Matt Neely、Tony Bencic、Srinivasan Turuvekere、Cristian Petculescu、Adi Regev、Naveen Sivaraj、Ben Glastein、Evgeny Tshiorny、Arthi Ramasubramanian Iyer、Sid Jayadevan、Ronald Chang、Ori Eduar、Anton Fritz、Idan Sheinberg、Ron Gilad、Sagiv Hadaya、Paul Inbar、Igor Uzhviev、Michael Roth、Jaime Tarquino、Gennady Pats、Orion Lee、Yury Berezansky、Maya Shenhav、Romit Chattopadhyay、Yariv Maimon、Bogdan Crivat

技術校閱：Cristian Petculescu、Amir Netz、Sergei Gundorov

適用於：Power BI SaaS、Power BI Desktop、Power BI Premium、Power BI 內嵌式分析、Power BI 行動版。

注意

您可選取瀏覽器的 [列印]，然後選取 [儲存為 PDF] 來儲存或列印本技術白皮書。

簡介

Power BI 是 Microsoft 提供的線上軟體服務 (稱為 SaaS 或軟體即服務)，能讓您輕鬆快速地建立自助商業智慧儀表板、報表、語意模型和視覺效果。 使用 Power BI，您可以連線到許多不同的資料來源、結合與塑造來自這些連線的資料，然後建立與其他人共用的報表和儀表板。

這個世界正在迅速變化；組織正在進行加速的數位轉型，且我們能看到遠端工作、對線上服務的客戶需求，以及在營運和商業決策中使用先進技術的程度皆大幅增加。 而這一切都是由雲端所提供。

隨著雲端轉換已成為趨勢，以及其所帶來的全新公開環境，有越來越多的公司都在詢問：「我位於雲端中的資料有多安全？」以及「有哪些端對端保護可防止我的敏感性資料外洩？」而對於經常需處理企業中一些最具策略性資訊的 BI 平台，這些問題也更加重要。

BI 安全性模型數十年來的基礎 (物件層級和資料列層級安全性) 雖然仍然很重要，但顯然已不足以提供雲端時代所需的安全性類型。 相反地，組織必須尋找雲端原生、多層式、深度防禦的安全性解決方案，以用於其商業智慧資料。

Power BI 的建置是為了針對資料提供領先業界且密不透風的完整保護。 此產品已贏得業界提供的最高安全性分類，且現今有許多國家安全機構、金融機構和健康照護提供者都將其最具敏感性的資訊委託給此產品。

而這一切都從基礎開始。 在歷經 2000 年代初期的艱難時期之後，Microsoft 做出大量投資來解決其安全性弱點，並在隨後幾十年間建置了一個強大的安全性堆疊，其向下深入電腦晶片中的 BIOS 核心，同時向上一路延伸到終端使用者體驗。 這些深度的投資仍在繼續，且目前有超過 3,500 名 Microsoft 工程師參與建置和增強 Microsoft 安全性堆疊的工作，並主動解決不斷變化的威脅環境。 隨著人們將數十億部電腦、數兆次登入，以及無數 ZB 的資訊交給 Microsoft 保護，該公司現在擁有科技產業最先進的安全性堆疊，且被廣泛視為打擊惡意執行者的全球領導者。

而 Power BI 便是以這個強大的基礎所建置。 其使用讓 Azure 獲得服務和保護全球最具敏感性資料之權利的相同安全性堆疊，並且與 Microsoft 365 最先進的資訊保護與合規性工具整合。 除此之外，其透過多層式安全性措施來提供安全性，進而產生專為應對雲端時代的獨特挑戰所設計的端對端保護。

為了提供用於保護敏感性資產的端對端解決方案，產品小組需要同時針對多個前線解決具挑戰性的客戶疑慮：

  • 「我們要如何控制可以連線的人員、其連線位置，以及其連線方式？」「我們要如何控制連線？」
  • 「資料的儲存方式為何？」「其加密方式為何？」「我對於自己的資料有哪些控制？」
  • 「我要如何控制及保護敏感性資料？」「我要如何確保此資料無法洩漏至組織外部？」
  • 「我要如何對有哪些人員進行哪些作業進行稽核？」「我要如何在服務上有可疑活動時快速回應？」

本文會提供上述所有問題的完整解答。 其會從服務結構的概觀開始，並說明系統主要流程的運作方式。 接著，其會繼續說明使用者如何向 Power BI 進行驗證、如何建立資料連線，以及 Power BI 如何儲存資料並在服務中加以移動。 最後一節將討論安全性功能，其能讓身為服務管理員的您保護自己最有價值的資產。

Power BI 服務受 Microsoft Online Services 條款和 Microsoft 隱私權聲明制約管轄。 如需資料處理的位置，請參閱 Microsoft 線上服務條款 (英文) 中的資料處理位置條款，以及資料保護增補合約 (英文)。 Microsoft 信任中心是 Power BI 有關合規性資訊的主要資源。 Power BI 小組致力於為客戶創造最新的創新和生產力。 深入了解 Microsoft 合規性供應項目中的合規性。

Power BI 服務遵循安全性開發生命週期 (SDL)，嚴格的安全性做法支援安全性保證與合規性需求。 SDL 可藉由降低軟體中弱點的數目和嚴重性來協助開發人員建置更安全的軟體，同時降低開發成本。 深入了解 Microsoft 安全性開發生命週期做法。

Power BI 結構

Power BI 服務是建置在 Microsoft 的雲端運算平台 Azure 之上。 Power BI 目前部署在世界各地的許多資料中心，向這些資料中心服務的客戶提供許多主動部署，以及作為每個主動部署備份使用之同等數目的被動部署。

WFE 和後端

Web 前端叢集 (WFE)

WFE 叢集能為使用者的瀏覽器在網站載入時提供初始的 HTML 頁面內容，以及用來在瀏覽器中轉譯網站的 CDN 內容。

WFE 叢集

WFE 叢集是由在 Azure App Service 環境中執行的 ASP.NET 網站所組成。 當使用者嘗試連線到 Power BI 服務時，用戶端的 DNS 服務可與 Azure 流量管理員通訊，以尋找具有 Power BI 部署的最適當 (通常是最接近的) 資料中心。 如需此流程的詳細資訊，請參閱適用於 Azure 流量管理員的效能流量路由方法。

靜態資源 (例如 *.js、*.css 和影像檔案) 大多會儲存在 Azure 內容傳遞網路 (CDN) 上，並由瀏覽器直接擷取。 請注意，此規則的例外狀況是主權政府叢集部署，且基於合規性考量，將會省略 CDN，並改為使用來自針對裝載靜態內容符合規範之區域的 WFE 叢集。

Power BI 後端叢集 (BE)

後端叢集是 Power BI 中所有可用功能的骨幹。 其是由 Web 前端和 API 用戶端所取用的數個服務端點，以及背景工作服務、資料庫、快取和其他各種元件所組成。

後端可在大部分的 Azure 區域中使用，而且會在可於新的區域中使用時部署到該區域。 單一 Azure 區域會裝載一或多個後端叢集，一旦單一叢集的垂直和水平調整限制用盡，就允許無限制地水平調整 Power BI 服務。

每個後端叢集都是具狀態的，且會裝載指派給該叢集之所有租用戶的所有資料。 包含特定租用戶資料的叢集稱為租用戶的主叢集。 已驗證之使用者的主叢集資訊是由全域服務提供，並由 Web 前端用來將要求路由傳送至租用戶的主叢集。

每個後端叢集都是由多部虛擬機器所組成，結合成多個可重新調整大小的擴展集，專門調整為執行特定工作、具狀態資源 (例如 SQL 資料庫)、儲存體帳戶、服務匯流排、快取和其他必要的雲端元件。

租用戶中繼資料和資料會儲存在叢集限制內，但是針對相同 Azure 地理位置中已配對 Azure 區域中的次要後端叢集的資料複寫除外。 次要後端叢集會在發生區域性中斷時作為容錯移轉叢集，而且在任何其他時間都是被動的。

後端功能是由在無法從外部存取之叢集虛擬網路內的不同電腦上執行的微服務提供服務，除了可從公用網際網路存取的兩個元件之外：

  • 閘道服務
  • Azure API 管理

後端叢集

Power BI Premium 基礎結構

Power BI Premium 為需要進階 Power BI 功能的訂閱者提供服務，例如進階 AI、散發給未授權的使用者等。當客戶註冊 Power BI Premium 訂用帳戶時，會透過 Azure Resource Manager 建立 Premium 容量。

Power BI Premium 容量是裝載於與一般 Power BI 後端無關的後端叢集中 (請參閱上述內容)。 這可為 Premium 供應項目提供更佳的隔離、資源配置、支援性、安全性隔離和可擴縮性。

下圖說明 Power BI Premium 基礎結構的結構：

Power BI Premium

Power BI Premium 基礎結構的連線可以透過許多方式完成，視使用者案例而定。 Power BI Premium 用戶端可以是使用者的瀏覽器、一般 Power BI 後端、透過 XMLA 用戶端的直接連線、ARM API 等。

Azure 區域中的 Power BI Premium 基礎結構是由多個 Power BI Premium 叢集所組成 (至少有一個)。 大部分的 Premium 資源會封裝在叢集內 (例如計算)，而且有一些常見的區域資源 (例如中繼資料儲存體)。 Premium 基礎結構允許以兩種方式在區域中達成水平可擴縮性：增加叢集內的資源，以及/或視需要新增更多叢集 (如果叢集資源接近其限制)。

每個叢集的骨幹都是由虛擬機器擴展集和 Azure Service Fabric 所管理的計算資源。 虛擬機器擴展集和 Service Fabric 可隨著使用量的增加快速且無痛地增加計算節點，並協調 Power BI Premium 服務和應用程式的部署、管理及監視。

有許多周邊資源可確保安全且可靠的基礎結構：負載平衡器、虛擬網路、網路安全性群組、服務匯流排、儲存體等。Power BI Premium 所需的任何祕密、金鑰和憑證都是由 Azure Key Vault 獨佔管理。 任何驗證都是透過與 Microsoft Entra ID (先前稱為 Azure Active Directory) 獨佔整合來完成的。

Power BI Premium 基礎結構收到的任何要求都會先移至前端節點，其是唯一可供外部連線使用的節點。 其餘的資源會隱藏在虛擬網路後面。 前端節點會驗證要求、處理要求，或將其轉送至適當的資源 (例如後端節點)。

後端節點提供大部分的 Power BI Premium 功能和特性。

Power BI 行動版

Power BI 行動版是專為下列三種主要行動裝置平台設計的應用程式集合：Android、iOS 和 Windows (UWP)。 Power BI 行動版應用程式的安全性考量分成兩類：

  • 裝置通訊
  • 裝置上的應用程式和資料

針對裝置通訊，所有 Power BI 行動版應用程式都會與 Power BI 服務通訊，並使用與瀏覽器相同的連線和驗證順序，其已於本技術白皮書稍早詳細說明。 適用於 iOS 和 Android 的 Power BI 行動版應用程式會在應用程式本身啟動瀏覽器工作階段，而 Windows 行動版應用程式則會啟動代理程式來與 Power BI 建立通訊通道 (以用於登入流程)。

下表根據行動裝置平台顯示適用於 Power BI 行動版的憑證型驗證 (CBA) 支援：

CBA 支援 iOS Android Windows
Power BI (登入服務) 支援 已支援 不支援
SSRS ADFS 內部部署 (連線到 SSRS 伺服器) 不支援 支援 不支援
SSRS App Proxy 支援 已支援 不支援

Power BI 行動版應用程式會主動與 Power BI 服務通訊。 遙測用於收集行動裝置應用程式使用量統計資料和類似資料，這些資料會傳輸至用於監視使用量和活動的服務；客戶資料不會與遙測資料一併傳送。

Power BI 應用程式會在裝置上儲存有助於使用應用程式的資料：

  • Microsoft Entra ID 和重新整理權杖使用業界標準安全性措施來以安全機制儲存在裝置上。
  • 資料和設定 (使用者設定的機碼值組) 會在裝置上的儲存體中快取，而且可由 OS 加密。 在 iOS 中，當使用者設定密碼時，系統就會自動完成此動作。 在 Android 中，這可以在設定中設定。 在 Windows 中，其是使用 BitLocker 來完成。
  • 針對 Android 和 iOS 應用程式，資料和設定 (使用者設定的機碼值組) 會在裝置上的儲存體中，以只能由應用程式存取的沙箱和內部儲存體的形式快取。 針對 Windows 應用程式，資料只能由使用者 (和系統管理員) 存取。
  • 地理位置由使用者明確啟用或停用。 若啟用，則不會將地理位置資料儲存在裝置上，也不會與 Microsoft 共用。
  • 通知由使用者明確啟用或停用。 如果已啟用，Android 和 iOS 便不支援針對通知的地理資料落地需求。

可以透過 Microsoft Intune 套用檔案層級加密來增強資料加密，其為提供行動裝置和應用程式管理的軟體服務。 提供 Power BI 行動版的三個平台都支援 Intune。 啟用和設定 Intune 後，便會對行動裝置上的資料進行加密，且 Power BI 應用程式本身不能安裝在 SD 記憶卡上。 深入了解 Microsoft Intune。

Windows 應用程式也支援 Windows 資訊保護 (WIP)。

為了實作 SSO，會將某些與權杖型驗證相關的安全儲存體值提供給其他 Microsoft 第一方應用程式 (例如 Microsoft Authenticator)，並由 Microsoft 驗證程式庫 (MSAL) 管理。

當移除應用程式、使用者登出 Power BI 行動版，或使用者登入失敗 (例如發生權杖到期事件或密碼變更之後) 時，就會刪除 Power BI 行動版快取資料。 資料快取包括先前從 Power BI 行動版應用程式存取的儀表板和報表。

Power BI 行動版不會存取裝置上的其他應用程式資料夾或檔案。

適用於 iOS 和 Android 的 Power BI 應用程式可讓您藉由設定其他識別碼來保護資料，例如針對 iOS 提供 Face ID、Touch ID 或密碼，以及針對 Android 提供生物特徵辨識資料 (指紋識別碼)。 深入了解其他識別碼。

對 Power BI 服務進行驗證

Power BI 服務的使用者驗證包含一系列的要求、回應，並在使用者的瀏覽器和 Power BI 服務或 Power BI 所使用的 Azure 服務之間重新導向。 該順序描述 Power BI 中使用者驗證的流程，其遵循 Microsoft Entra 驗證碼授與流程。 如需組織使用者驗證模型 (登入模型) 選項的詳細資訊，請參閱選擇 Microsoft 365 的登入模型 (英文)。

驗證順序

Power BI 服務的使用者驗證順序會依照下列步驟中所述進行，並透過後續影像加以描繪。

  1. 使用者會從瀏覽器起始對 Power BI 服務的連線，方法是在網址列中輸入 Power BI 位址，或從 Power BI 行銷頁面 (https://powerbi.microsoft.com) 選取 [登入]。 連線是使用 TLS 和 HTTPS 來建立，而瀏覽器和 Power BI 服務之間所有後續的通訊則使用 HTTPS。

  2. Azure 流量管理員會檢查使用者的 DNS 記錄，以判斷已部署 Power BI 的最適當 (通常是最接近的) 資料中心，並以應傳送使用者之目標 WFE 叢集的 IP 位址來回應 DNS。

  3. WFE 接著會將 HTML 頁面傳回瀏覽器用戶端，其中包含起始登入流程所需的 MSAL.js 程式庫參考。

  4. 瀏覽器用戶端會載入從 WFE 接收的 HTML 頁面，並將使用者重新導向至 Microsoft Online Services 登入頁面。

  5. 使用者通過驗證之後，登入頁面會搭配驗證碼將使用者重新導向回到 Power BI WFE 頁面。

  6. 瀏覽器用戶端會載入 HTML 頁面，並使用驗證碼從 Microsoft Entra ID 要求權杖 (存取、識別碼、重新整理)。

  7. 瀏覽器用戶端會使用使用者的租用戶識別碼來查詢 Power BI 全域服務，其能維護租用戶及其 Power BI 後端叢集位置的清單。 Power BI 全域服務會決定哪些 Power BI 後端服務叢集包含使用者的租用戶，並將 Power BI 後端叢集 URL 傳回用戶端。

  8. 用戶端現在可以在 HTTP 要求的授權標頭中使用存取權杖，與 Power BI 後端叢集 URL API 通訊。 Microsoft Entra 存取權杖將具有根據 Microsoft Entra 原則設定的到期日，而為了維護目前的工作階段，使用者瀏覽器中的 Power BI 用戶端將會定期要求來在存取權杖到期之前加以更新。

說明用戶端驗證順序的圖表。

在用戶端驗證因非預期的錯誤而失敗的罕見情況下，程式碼會嘗試回復為在 WFE 中使用伺服器端驗證。 如需伺服器端驗證流程的詳細資料，請參閱本文件結尾的問答小節。

資料落地

除非文件中另有說明，否則 Power BI 會將客戶資料儲存在 Azure 地理位置中，其是在 Microsoft Entra 租用戶首次註冊 Power BI 服務時指派。 Microsoft Entra 租用戶會裝載使用者和應用程式身分識別、群組，以及其他與組織和其安全性相關的資訊。

您可以將在 Microsoft Entra 租用戶設定過程中選取的國家或地區，對應至最適合存在 Power BI 部署的 Azure 地理位置，藉此為租用戶資料儲存體指派 Azure 地理位置。 做出此判定之後，所有 Power BI 客戶資料都會儲存在這個選取的 Azure 地理位置 (也稱為「主地理位置」) 中，但組織會利用多地理位置部署的情況除外。

多地理位置 (Multi-Geo)

某些組織是遍及全球的，而且可能需要位於多個 Azure 地理位置的 Power BI 服務。 例如，某個企業的總部可能設立在美國，但也可能在其他地理區域做生意，例如澳洲。 在這種情況下，該企業可能會需要將某些 Power BI 資料以待用形式儲存在遠端區域中，以符合當地法規。 Power BI 服務的這項功能稱為「多地理位置」。

指派給多地理位置工作區的查詢執行層、查詢快取和成品資料會裝載並保留在遠端容量 Azure 地理位置中。 不過，某些成品中繼資料 (例如報表結構) 可能仍會以待用形式儲存在租用戶的主地理位置中。 此外，某些資料傳輸和處理仍可能會在租用戶的主地理位置中發生，即使是裝載在多地理位置 Premium 容量中的工作區也相同。

如需建立和管理跨越多個 Azure 地理位置之 Power BI 部署的詳細資訊，請參閱設定 Power BI Premium 的多地理位置支援。

區域和資料中心

Power BI 服務可在特定的 Azure 地理位置中提供，如 Microsoft 信任中心中所述。 如需資料儲存位置和使用方式的詳細資訊，請參閱 Microsoft 信任中心。 Microsoft 線上服務條款的資料處理條款會指定客戶待用資料的相關位置。

Microsoft 也為主權實體提供資料中心。 如需國家/地區雲端的 Power BI 服務可用性詳細資訊，請參閱 Power BI 國家/地區雲端。

資料處理

本節概述 Power BI 在儲存、處理及傳輸客戶資料時的資料處理做法。

待用資料

Power BI 使用兩種主要資料儲存體資源類型：

  • Azure 儲存體
  • Azure SQL Database

在大部分情況下，Azure 儲存體會用來保存 Power BI 成品的資料，而 Azure SQL 資料庫則用來保存成品中繼資料。

Power BI 所保存的所有資料預設都會使用 Microsoft 管理的金鑰來加密。 儲存在 Azure SQL 資料庫中的客戶資料會使用 Azure SQL 的透明資料加密 (TDE) 技術來完整加密。 儲存在 Azure Blob 儲存體中的客戶資料會使用 Azure 儲存體加密來加密。

或者，組織可以利用 Power BI Premium，使用自己的金鑰來對匯入語意模型的待用資料進行加密。 這種方法通常稱為攜帶您自己的金鑰 (BYOK)。 使用 BYOK 有助於確保即使在發生服務操作員錯誤的情況下客戶資料也不會公開，這在使用透明伺服器端加密的情況下是無法輕易達成的。 如需詳細資訊，請參閱攜帶您自己的加密金鑰以用於 Power BI。

Power BI 語意模型允許使用各種資料來源連線模式，以判斷資料來源資料是否保存在服務中。

語意模型模式 (種類) 保存在 Power BI 中的資料
Import Yes
DirectQuery No
Live connect No
複合 如果包含匯入資料來源
串流 如果設定為保存

不論使用的語意模型模式為何，Power BI 都可能會暫時快取任何所擷取的資料，以將查詢和報表載入效能最佳化。

處理中的資料

當有一或多個使用者作為某個互動式案例的一部分主動使用資料時，或當某個背景處理序 (例如重新整理) 觸及此資料時，便代表資料處於處理狀態。 Power BI 會將正在主動處理的資料載入一或多個服務工作負載的記憶體空間內。 為了促成工作負載所需的功能，記憶體中已處理的資料並不會加密。

傳輸中資料

Power BI 要求使用 TLS 1.2 或更新版本來對所有連入 HTTP 流量進行加密。 嘗試搭配 TLS 1.1 或更低版本使用服務的任何要求都會被拒絕。

針對資料來源進行驗證

連線到資料來源時，使用者可以選擇將資料複本匯入 Power BI，或直接連線到資料來源。

在匯入的情況下，使用者會根據該使用者的登入建立連線，並使用認證來存取資料。 在語意模型發佈至 Power BI 服務之後，Power BI 一律會使用該使用者的認證來匯入資料。 匯入資料之後，檢視報表和儀表板中的資料並不會存取底層資料來源。 Power BI 支援針對所選取的資料來源進行單一登入驗證。 如果連線設定為使用單一登入，便會使用語意模型擁有者的認證來連線到資料來源。

如果使用預先設定的認證直接連線到資料來源，則當任何使用者檢視資料時，都會使用預先設定的認證來連線到資料來源。 如果使用單一登入直接連線到資料來源，則當使用者檢視資料時，會使用目前使用者的認證來連線到資料來源。 搭配單一登入使用時，可以在資料來源上實作資料列層級安全性 (RLS) 和/或物件層級安全性 (OLS)。 這可讓使用者只檢視他們有權存取的資料。 當連線目的地是雲端中的資料來源時，會針對單一登入使用 Microsoft Entra 驗證；針對內部部署資料來源，支援使用 Kerberos、安全性聲明標記語言 (SAML) 和 Microsoft Entra ID。

如果資料來源是 Azure Analysis Services 或內部部署 Analysis Services，且已設定 RLS 和/或 OLS，則 Power BI 服務會套用該資料列層級安全性，且沒有足夠認證以存取底層資料 (其可能是用於儀表板、報表或其他資料成品中的查詢) 的使用者，將不會看到他們沒有足夠權限存取的資料。

進階功能

資料流程結構

資料流程可讓使用者設定後端資料處理作業，以從多型態的資料來源擷取資料，針對該資料執行轉換邏輯，然後將其置於目標模型中，以用於各種報告呈現技術。 在工作區中具有成員、參與者或管理員角色的任何使用者，都可以建立資料流程。 具有檢視者角色的使用者可以檢視資料流程所處理的資料，但不可對其組合做出變更。 撰寫資料流程之後，工作區的任何成員、參與者或管理員都可以藉由取得資料流程的擁有權來安排重新整理，以及檢視和編輯資料流程。

每個設定的資料來源都會繫結至某個用戶端技術以存取該資料來源。 會形成存取其所需的認證結構，以符合資料來源的必要實作詳細資料。 轉換邏輯會在資料傳輸期間由 Power Query 服務套用。 針對進階資料流程，Power Query 服務會在後端節點中執行。 資料可以直接從雲端來源提取，或是透過安裝在內部部署的閘道提取。 從雲端來源直接提取到服務或閘道時，如果適用，傳輸會使用特定於用戶端技術的保護方法。 將資料從閘道傳輸到雲端服務時，會將其加密。 請參閱上面的傳輸中的資料一節。

當客戶指定的資料來源需要認證才能存取時，資料流程的擁有者/建立者會在撰寫期間加以提供。 會使用標準全產品認證儲存體來加以儲存。 請參閱上面的針對資料來源進行驗證一節。 有數種方式可以讓使用者進行設定來將資料持續性和存取最佳化。 根據預設，資料會置於由 Power BI 擁有並保護的儲存體帳戶中。 會在 Blob 儲存體容器上啟用儲存體加密，以在資料待用時加以保護。 請參閱下方的待用資料一節。 不過，使用者可以設定與其與 Azure 訂用帳戶相關聯的儲存體帳戶。 這樣做時，會向 Power BI 服務主體授與該儲存體帳戶的存取權，以便其在重新整理期間將資料寫入該處。 在此情況下，儲存體資源擁有者需負責在設定的 ADLS 儲存體帳戶上設定加密。 資料一律會使用加密傳輸至 Blob 儲存體。

由於存取儲存體帳戶時某些資料的效能可能較低，因此使用者也可以選擇使用 Power BI 裝載的計算引擎來提升效能。 在此情況下，資料會以備援方式儲存在 SQL 資料庫中，其可供 DirectQuery 透過後端 Power BI 系統的存取來加以使用。 檔案系統上的資料一律會加密。 如果使用者提供金鑰來對儲存在 SQL 資料庫中的資料進行加密，該金鑰也將用來對其進行雙重加密。

使用 DirectQuery 進行查詢時，會使用加密的傳輸通訊協定 HTTPS 來存取 API。 對 DirectQuery 的所有次要或間接使用，都是由先前所述的相同存取控制所控制。 由於資料流程一律會繫結至工作區，因此對資料的存取一律會受到使用者在該工作區中的角色所限制。 使用者必須至少有讀取權限，才能透過任何方式查詢資料。

當使用 Power BI Desktop 來存取資料流程中的資料時，必須先使用 Microsoft Entra ID 來驗證使用者，以判斷使用者是否有足夠的權限來檢視資料。 如果是，則會取得 SaS 金鑰，並用來透過加密的傳輸通訊協定 HTTPS 直接存取儲存體。

整個管線中的資料處理都會發出 Office 365 稽核事件。 其中有些事件會擷取安全性和隱私權相關作業。

分頁報表

編頁報表是設計用來進行列印或共用。 這些報表之所以稱為「編頁」，因為已將其格式化，可適當地符合頁面。 即使資料表跨越多個頁面，它們也會在資料表中顯示所有資料。 您可以完全控制其報表的頁面配置。

編頁報表支援以 Microsoft Visual Basic .NET 撰寫之豐富且功能強大的運算式。 在整個 Power BI Report Builder 的編頁報表中會廣泛利用運算式來擷取、計算、顯示、分組、排序、篩選、參數化和格式化資料。

運算式是由報表的作者所建立，可存取 .NET Framework 的各種功能。 編頁報表的處理和執行是在沙箱內執行。

編頁報表定義 (.rdl) 會儲存在 Power BI 中，且若要發佈和/或轉譯編頁報表，使用者必須以和上面的對 Power BI 服務進行驗證一節中所述相同的方式進行驗證和授權。

在驗證期間取得的 Microsoft Entra 權杖是用來直接從瀏覽器向 Power BI Premium 叢集進行通訊。

在 Power BI Premium 中，Power BI 服務執行階段會為每個報表轉譯提供適當的隔離執行環境。 這包括所轉譯的報表屬於指派給相同容量之工作區的情況。

在報表轉譯過程中，編頁報表可以存取一組廣泛的資料來源。 沙箱不會直接與任何資料來源通訊，而是會與受信任的處理序通訊以要求資料，然後該受信任的處理序會將必要的認證附加至連線。 如此一來，沙箱就一律無法存取任何認證或祕密。

為了支援 Bing 地圖服務之類的功能，或是對 Azure Functions 進行呼叫，沙箱必須要能存取網際網路。

Power BI 內嵌式分析

獨立軟體廠商 (ISV) 和解決方案提供者有兩種主要模式可在其 Web 應用程式和入口網站中內嵌 Power BI 成品：為組織內嵌和為客戶內嵌。 成品是內嵌在應用程式或入口網站的 IFrame 中。 IFrame 不允許從外部 Web 應用程式或入口網站讀取或寫入資料，而與 IFrame 的通訊是使用 Power BI 用戶端 SDK 搭配 POST 訊息來完成。

在為組織內嵌案例中，Microsoft Entra 使用者會透過由其企業和 IT 自訂的入口網站存取自己的 Power BI 內容。 本技術白皮書所述的所有 Power BI 原則和功能 (例如資料列層級安全性 (RLS) 和物件層級安全性 (OLS))，都會個別自動套用至所有使用者，不論他們是透過 Power BI 入口網站還是透過自訂入口網站來存取 Power BI。

在為客戶內嵌案例中，ISV 通常擁有 Power BI 租用戶和 Power BI 項目 (儀表板、報表、語意模型等)。 ISV 後端服務有責任驗證其終端使用者，並決定該終端使用者適合哪些成品及哪些存取層級。 ISV 原則決策會在 Power BI 產生的內嵌權杖中加密，並傳遞至 ISV 後端，以根據 ISV 的商業邏輯進一步散發給終端使用者。 使用瀏覽器或其他用戶端應用程式的終端使用者並無法解密或修改內嵌權杖。 Power BI 用戶端 API 之類的用戶端 SDK 會自動將加密的內嵌權杖以 Authorization: EmbedToken 標頭的形式附加至 Power BI 要求。 根據此標頭，Power BI 會強制執行所有原則 (例如存取或 RLS)，如同 ISV 在產生期間所指定的一樣。

為了啟用內嵌和自動化，以及產生上述的內嵌權杖，Power BI 會公開一組豐富的 REST API。 這些 Power BI REST API 同時支援使用者委派和服務主體 Microsoft Entra 驗證和授權方法。

Power BI 內嵌式分析及其 REST API 支援本文所述的所有 Power BI 網路隔離功能：例如，服務標籤和 Private Link。

AI 功能

Power BI 目前產品中支援兩大類的 AI 功能：AI 視覺效果和 AI 擴充。 視覺效果層級 AI 功能包括關鍵影響因素、分解樹狀結構、智慧型敘事、異常偵測、R 視覺效果、Python 視覺效果、叢集、預測、問與答、快速見解等功能。AI 擴充功能包括 AutoML、Azure Machine Learning、CognitiveServices、R/Python 轉換等功能。

目前共用和 Premium 工作區都支援上述大部分功能。 不過，因為 IP 限制，只有 Premium 工作區才支援 AutoML 和 CognitiveServices。 目前，透過 Power BI 中的 AutoML 整合，使用者可以建置和定型自訂 ML 模型 (例如預測、分類、迴歸等) 並加以套用，以在將資料載入 Premium 工作區中定義的資料流程時取得預測。 此外，Power BI 使用者可以套用數個 CognitiveServices API (例如 TextAnalytics 和 ImageTagging)，以在將資料載入 Premium 工作區中定義的資料流程/語意模型之前先加以轉換。

Premium AI 擴充功能最適合視為無狀態 AI 函式/轉換的集合，可讓 Power BI 使用者在其由 Power BI 語意模型或資料流程使用的資料整合管線中使用。 請注意，也可以從 Power BI 服務和 Power BI Desktop 中目前的資料流程/語意模型撰寫環境中存取這些函式。 這些 AI 函式/轉換一律會在 Premium 工作區/容量中執行。 這些函式會以資料來源的形式呈現在 Power BI 中，而使用 AI 函式的 Power BI 使用者將需要 Microsoft Entra 權杖。 這些 AI 資料來源很特別，因為其不會呈現自己的任何資料，而只會提供這些函式/轉換。 在執行期間，這些功能不會對其他服務發出任何輸出呼叫以傳輸客戶的資料。 讓我們查看個別的 Premium 案例，以了解通訊模式和與其相關的安全性相關詳細資料。

為了定型和套用 AutoML 模型，Power BI 會使用 Azure AutoML SDK，並在客戶的 Power BI 容量中執行所有定型。 在定型反覆項目期間，Power BI 會呼叫實驗 Azure Machine Learning 服務，以選取適合目前反覆項目的模型和超參數。 在此輸出呼叫中，只會傳送先前反覆項目的相關實驗中繼資料 (例如正確性、ML 演算法、演算法參數等)。 AutoML 定型會產生 ONNX 模型和定型報表資料，其接著會儲存在資料流程中。 稍後，Power BI 使用者可以將已定型的 ML 模型套用為轉換，以依排程將 ML 模型運作化。 針對 TextAnalytics 和 ImageTagging API，Power BI 不會直接呼叫 CognitiveServices 服務 API，而是使用內部 SDK 在 Power BI Premium 容量中執行 API。 目前，Power BI 資料流程和語意模型都支援這些 API。 在 Power BI Desktop 中撰寫資料模型時，使用者只能在其能夠存取 Premium Power BI 工作區時，才能存取此功能。 因此，系統會提示客戶提供其 Microsoft Entra 認證。

網路隔離

本節概述 Power BI 中的進階安全性功能。 某些功能具有特定的授權需求。 如需詳細資料，請參閱下列各節。

服務標籤

服務標籤代表來自指定 Azure 服務的一組 IP 位址首碼。 這有助於將網路安全性規則頻繁更新的複雜度降到最低。 客戶可以使用服務標籤，在網路安全性群組或 Azure 防火牆上定義網路存取控制。 客戶可以在建立安全性規則時，使用服務標籤來取代特定 IP 位址。 藉由在規則 (針對 API) 的適當來源或目的地欄位中指定服務標籤名稱 (例如 PowerBI)，客戶就可以允許或拒絕對應服務的流量。 Microsoft 會管理服務標籤包含的位址前置詞，並隨著位址變更自動更新服務標籤。

Azure 網路提供 Azure Private Link 功能，其能讓 Power BI 透過 Azure 網路私人端點提供安全存取。 使用 Azure Private Link 和私人端點時，會使用 Microsoft 的骨幹網路基礎結構私下傳送資料流量，因此資料不會周遊網際網路。

Private Link 可確保 Power BI 使用者在進入 Power BI 服務的資源時，會使用 Microsoft 私人網路骨幹。

搭配 Power BI 使用 Private Link 可提供下列優點：

  • Private Link 可確保流量會透過 Azure 骨幹傳送至 Azure 雲端式資源的私人端點。
  • 網路流量與非 Azure 型基礎結構 (例如內部部署存取) 的隔離，將會要求客戶設定 ExpressRoute 或虛擬私人網路 (VPN)。

如需其他資訊，請參閱使用私人連結存取 Power BI。

VNet 連線

雖然 Private Link 整合功能提供對 Power BI 的安全輸入連線，但 VNet 連線功能可允許從 Power BI 到 VNet 內資料來源的安全輸出連線。

VNet 閘道 (受 Microsoft 管理) 可消除安裝和監視內部部署資料閘道的額外負荷，以連線至與 VNet 相關聯的資料來源。 不過，其仍遵循與內部部署資料閘道同樣令人感到熟悉的安全性和資料來源管理程序。

以下是當您使用 VNet 閘道與連線至 VNet 內資料來源的 Power BI 報表互動時所會發生之情況的概觀：

  1. Power BI 雲端服務 (或其他一項支援的雲端服務) 會啟動查詢，並將查詢、資料來源詳細資料和認證傳送至 Power Platform VNet 服務 (PP VNet)。

  2. 接著，PP VNet 服務會將執行 VNet 閘道的容器安全地插入子網路。 現在，該容器可連線至可從此子網路內存取的資料服務。

  3. PP VNet 服務接著會將查詢、資料來源詳細資料和認證傳送至 VNet 閘道。

  4. VNet 閘道會收到查詢，並使用那些認證來連線到資料來源。

  5. 然後將查詢傳送到資料來源以用於執行。

  6. 執行後，結果會傳送至 VNet 閘道，且 PP VNet 服務會將資料從容器安全地推送至 Power BI 雲端服務。

服務主體

Power BI 支援使用服務主體。 在 Key Vault 中儲存用於加密或存取 Power BI 的任何服務主體認證，將適當的存取原則指派給保存庫，並定期檢閱存取權限。

如需其他詳細資料，請參閱使用服務主體將 Premium 工作區與語意模型工作自動化。

適用於 Power BI 的 Microsoft Purview

Microsoft Purview 資訊保護

Power BI 與 Microsoft Purview 資訊保護緊密整合。 Microsoft Purview 資訊保護可讓組織擁有單一的整合式解決方案，以跨 Azure、Power BI 和 Office 進行分類、標記、稽核與規範遵循。

在 Power BI 中啟用資訊保護時：

  • 敏感性資料 (無論是在 Power BI 服務和 Power BI Desktop 中) 可以使用 Office 和 Azure 中使用的相同敏感度標籤來分類和標記。
  • 當 Power BI 內容匯出至 Excel、PowerPoint、PDF、Word 或 .pbix 檔案時，可以強制執行治理原則，以協助確保資料能受到保護，即使離開 Power BI 也一樣。
  • 在 Power BI Desktop 中分類及保護 .pbix 檔案很簡單，就像是在 Excel、Word 和 PowerPoint 應用程式中一樣。 檔案可以根據其敏感度輕鬆加以標記。 此外，如果其包含商務機密資料，則可進行加密，以確保只有授權的使用者才能編輯這些檔案。
  • Excel 活頁簿會在連線到 Power BI 時自動繼承敏感度標籤 (預覽)，以便在 Excel 中分析 Power BI 語意模型時維持端對端分類並套用保護。
  • Power BI iOS 和 Android 行動裝置應用程式中會顯示套用至 Power BI 報表和儀表板的敏感度標籤。
  • 當 Power BI 報表內嵌在 Teams、SharePoint 或安全的網站時，敏感度標籤會持續存在。 這有助於組織在內嵌 Power BI 內容時，於匯出時維護分類和保護。
  • 在 Power BI 服務中建立新內容時，標籤繼承可確保在 Power BI 服務中套用至語意模型或資料超市的標籤，都會套用至以那些語意模型和資料超市為基礎所建立的新內容上方。
  • Power BI 管理員掃描 API 可以擷取 Power BI 項目的敏感度標籤，讓 Power BI 和 InfoSec 管理員可以監視 Power BI 服務中的標記並產生執行報表。
  • Power BI 管理員 API 可讓中央小組以程式設計方式將敏感度標籤套用至 Power BI 服務中的內容。
  • 中央小組可以建立強制標籤原則，以強制在 Power BI 中新增或編輯的內容上套用標籤。
  • 中央小組可以建立預設標籤原則，以確保敏感度標籤會套用至所有新的或變更的 Power BI 內容。
  • Power BI 服務中的自動下游敏感度標記可確保當套用或變更語意模型或資料超市上的標籤時，連線至該語意模型或資料超市的所有下游內容都會自動套用或變更該標籤。

如需詳細資訊，請參閱 Power BI 中的敏感度標籤。

適用於 Power BI 的 Microsoft Purview 資料外洩防護 (DLP) 原則

Microsoft Purview 的 DLP 原則可協助組織降低 Power BI 敏感性商務資料外洩的風險。 DLP 原則可協助其符合政府或產業法規的合規性需求，例如 GDPR (歐盟的一般資料保護規定) 或 CCPA (加州消費者隱私權法案)，並確保其在 Power BI 中的資料受控。

設定適用於 Power BI 的 DLP 原則時：

  • 原則中指定之工作區內的所有語意模型都會由原則評估。
  • 您可以偵測敏感性資料何時上傳到 Premium 容量。 DLP 原則可以偵測：
    • 敏感度標籤。
    • 敏感性資訊類型。 支援超過 260 種類型。 敏感性資訊類型偵測需仰賴 Microsoft Purview 內容掃描。
  • 當您遇到已識別為敏感性的語意模型時，您可以看到可協助您了解應該如何執行的自訂原則提示。
  • 如果您是語意模型擁有者，且有合理的理由這麼做，則可以覆寫原則，並防止系統將您的語意模型識別為「敏感性」。
  • 如果您是語意模型擁有者，且認為某個敏感性資訊類型是誤判的，則可以回報原則有問題。
  • 您可以叫用自動風險降低功能，例如對安全性管理員發出警示。

如需詳細資訊，請參閱適用於 Fabric Power BI 的資料外洩防護原則。

適用於 Power BI 的 Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps 是世界領先的雲端存取安全性代理程式之一，被 Gartner 提名為雲端存取安全性代理程式 (CASB) 市場魔力象限 (Magic Quadrant) 的領導者。 Defender for Cloud Apps 是用來保護對雲端應用程式的使用。 其可讓組織即時監視和控制具風險的 Power BI 工作階段，例如當使用者從非受控裝置存取時。 安全性管理員可以定義原則來控制使用者動作，例如下載具有敏感性資訊的報表。

透過使用 Defender for Cloud Apps，組織可以取得下列 DLP 功能：

  • 設定即時控制措施，以在 Power BI 中對風險性使用者工作階段進行強制執行。 例如，如果使用者從其國家或地區外部連線到 Power BI，則可以由 Defender for Cloud Apps 即時控制措施監視工作階段，而且可以立即封鎖具風險的動作，例如下載以「高度保密」敏感度標籤的資料。
  • 使用 Defender for Cloud Apps 活動記錄來調查 Power BI 使用者活動。 Defender for Cloud Apps 活動記錄包括在 Office 365 稽核記錄中擷取的 Power BI 活動，其中包含所有使用者和管理員活動的相關資訊，以及套用、變更和移除標籤等相關活動的敏感度標籤資訊。 管理員可以利用 Defender for Cloud Apps 進階篩選和快速動作，進行有效的問題調查。
  • 建立自訂原則以針對 Power BI 中的可疑使用者活動發出警示。 Defender for Cloud Apps 活動原則功能可用來定義您自己的自訂規則，以協助您偵測偏離常規的使用者行為，甚至能在情況太過危險時自動採取行動。
  • 使用 Defender for Cloud Apps 內建異常偵測。 Defender for Cloud Apps 異常偵測原則提供現成的使用者行為分析和機器學習服務，讓您從一開始就準備好在雲端環境中執行進階威脅偵測。 當異常偵測原則識別到可疑行為時，其會觸發安全性警示。
  • Defender for Cloud Apps 入口網站中的 Power BI 管理員角色。 Defender for Cloud Apps 提供應用程式特定的管理員角色，可用來僅授與 Power BI 管理員存取入口網站中 Power BI 相關資料所需的權限，例如警示、有風險的使用者、活動記錄和其他 Power BI 相關資訊。

如需其他詳細資料，請參閱在 Power BI 中使用 Microsoft Defender for Cloud Apps 控制措施。

預覽安全性功能

本節列出計畫於 2021 年 3 月發行的功能。 因為本主題列出的功能可能尚未發行，因此交貨時程表可能會變更，且預計的功能可能會於 2021 年 3 月之後發行，或可能完全不會發行。 如需預覽的詳細資訊，請檢閱線上服務條款 (英文)。

攜帶您自己的 Log Analytics (BYOLA)

攜帶您自己的 Log Analytics 可在 Power BI 與 Azure Log Analytics 之間進行整合。 此整合包括 Azure Log Analytics 的進階分析引擎、互動式查詢語言，以及內建的機器學習建構。

Power BI 安全性問答

下列問題是 Power BI 常見的安全性問題和回答。 這些內容根據其新增至本技術白皮書的時間進行排序，以便在文件更新時供您快速找出新問題和回答。 最新的問題會新增至此清單的結尾。

使用 Power BI 時，使用者如何連線至資料來源並存取？

  • Power BI 會針對雲端認證或透過個人閘道的連線負責為每個使用者管理資料來源的認證。 內部部署資料閘道所管理的資料來源可以跨企業共用，而且閘道管理員可以管理這些資料來源的權限。設定語意模型時，允許使用者從其個人存放區選取認證，或透過內部部署資料閘道來使用共用認證。

    在匯入案例中，使用者會根據該使用者的登入建立連線，並使用認證來存取資料。 在語意模型發佈至 Power BI 服務之後，Power BI 一律會使用該使用者的認證來匯入資料。 匯入資料之後，檢視報表和儀表板中的資料並不會存取底層資料來源。 Power BI 支援針對所選取的資料來源進行單一登入驗證。 如果連線設定為使用單一登入，便會使用語意模型擁有者的認證來連線到資料來源。

    對於與 DirectQuery 連線的報表，資料來源會直接使用預先設定的認證來連線，預先設定的認證會在任何使用者檢視資料時連線到資料來源。 如果使用單一登入直接連線到資料來源，則當使用者檢視資料時，會使用目前使用者的認證來連線到資料來源。 搭配單一登入使用時，可以在資料來源上實作資料列層級安全性 (RLS) 和/或物件層級安全性 (OLS)，而且這可讓使用者檢視其具有存取權限的資料。 當連線目的地是雲端中的資料來源時，會針對單一登入使用 Microsoft Entra 驗證；針對內部部署資料來源，支援使用 Kerberos、SAML 和 Microsoft Entra ID。

    使用 Kerberos 連線時，使用者的 UPN 會傳遞至閘道，而且透過使用 Kerberos 限制委派，使用者會模擬並連線到個別的資料來源。 SAP Hana 資料來源的閘道也支援 SAML。 如需詳細資訊，請參閱適用於閘道的單一登入概觀。

    如果資料來源是 Azure Analysis Services 或內部部署 Analysis Services，且已設定資料列層級安全性 (RLS) 和/或物件層級安全性 (OLS)，則 Power BI 服務會套用該資料列層級安全性，且沒有足夠認證以存取底層資料 (其可能是用於儀表板、報表或其他資料成品中的查詢) 的使用者，將不會看到其沒有足夠權限存取的資料。

    搭配 Power BI 的資料列層級安全性可用以限制指定使用者的資料存取。 篩選會限制資料列層級的資料存取，您可以在角色中定義篩選。

    物件層級安全性 (OLS) 可用以保護敏感性資料表或資料行。 不過，與資料列層級安全性不同，物件層級安全性也會保護物件名稱和中繼資料。 這有助於防止惡意使用者，使其甚至無法探索到這類物件的存在。 使用 Excel 或 Power BI 等報告工具時，受保護的資料表和資料行會在欄位清單中遮蔽，此外，沒有權限的使用者並無法透過 DAX 或任何其他方法存取受保護的中繼資料物件。 從沒有適當存取權限之使用者的觀點來看，受保護的資料表和資料行根本不存在。

    物件層級安全性在搭配資料列層級安全性使用的情況下，可在報表和語意模型上啟用增強的企業級安全性，確保只有具備必要權限的使用者才能檢視敏感性資料並與其互動。

Power BI 如何傳輸資料？

  • Power BI 要求和傳輸的所有資料都會在傳輸期間使用 HTTPS 進行加密 (除非客戶選擇的資料來源不支援 HTTPS)，以從資料來源連線到 Power BI 服務。 會建立與資料提供者之間的安全連線，且唯有在建立該連線後，資料才能周遊網路。

Power BI 如何快取報表、儀表板或模型資料，且其是否安全？

用戶端是在本機快取網頁資料嗎？

  • 瀏覽器用戶端存取 Power BI 時，Power BI Web 伺服器會將 Cache-Control 指示詞設定為 no-store。 no-store 指示詞會指示瀏覽器不快取使用者正在檢視的網頁，而不是將網頁儲存在用戶端的快取資料夾中。

角色型安全性、共用報表或儀表板和資料連線呢？ 資料存取、儀表板檢視、報表存取或重新整理如何運作？

  • 針對已啟用非角色層級安全性 (RLS) 的資料來源，如果透過 Power BI 與其他使用者共用儀表板、報表或資料模型，則該資料即可供與其共用的使用者檢視和互動。 Power BI「不會」針對資料的原始來源重新驗證使用者；資料一旦上傳至 Power BI 後，對來源資料進行驗證的使用者需負責管理哪些其他使用者和群組可以檢視資料。

    當與支援 RLS 的資料來源 (例如 Analysis Services 資料來源) 建立資料連線時，只有儀表板資料會在 Power BI 中快取。 每次在 Power BI 中檢視或存取使用支援 RLS 之資料來源資料的報表或語意模型時，Power BI 服務都會存取資料來源，根據使用者的認證來取得資料；如果有足夠的權限，則資料會為載入至該使用者的報表或資料模型中。 如果驗證失敗，使用者會看到錯誤。

    如需詳細資訊，請參閱本文件稍早所述的針對資料來源進行驗證一節。

我們的使用者一律會連線至相同的資料來源，其中有些需要不同於其網域認證的認證。 要如何避免在每次進行資料連線都必須輸入這些認證？

內部部署資料閘道和個人閘道使用哪些連接埠？ 是否有任何需要允許進行連線的網域名稱？

使用內部部署資料閘道時，修復金鑰會如何使用並儲存於何處？ 安全認證管理呢？

  • 在閘道安裝和設定期間，系統管理員會鍵入閘道修復金鑰。 該修復金鑰會用來產生強式 AES 對稱金鑰。 也會同時建立 RSA 非對稱金鑰。

    這些產生的金鑰 (RSA 和 AES) 會儲存在本機電腦上的檔案中。 此外，該檔案也會受到加密。 只有該特定的 Windows 電腦，以及該特定的閘道服務帳戶，才能解密該檔案的內容。

    當使用者在 Power BI 服務 UI 中輸入資料來源認證時，認證會使用瀏覽器中的公開金鑰進行加密。 閘道會使用 RSA 私密金鑰將認證解密，並使用 AES 對稱金鑰將其重新加密，再將資料儲存至 Power BI 服務。 使用此程序，Power BI 服務永遠無法存取未加密的資料。

內部部署資料閘道會使用哪些通訊協定？如何確保安全？

  • 閘道支援下列兩種通訊協定：

    • AMQP 1.0 – TCP + TLS：此通訊協定需要開啟連接埠 443、5671-5672 和 9350-9354，以便進行連出通訊。 此通訊協定為優先選項，因為具有較低的通訊額外負荷。

    • HTTPS – 透過 HTTPS + TLS 的 WebSocket：此通訊協定只會使用連接埠 443。 WebSocket 由單一 HTTP 連線訊息啟動。 一旦建立通道後，通訊本質上為 TCP + TLS。 您可以修改內部部署閘道一文中所述的設定，強制閘道使用此通訊協定。

Power BI 中 Azure CDN 的角色是什麼？

  • 如前所述，Power BI 會使用 Azure 內容傳遞網路 (CDN)，根據地理位置地區設定有效率地將必要的靜態內容和檔案散發給使用者。 為了探索進一步的詳細資料，Power BI 服務會使用多個 CDN，透過公用網際網路有效率地將必要的靜態內容和檔案散發給使用者。 這些靜態檔案包括產品下載 (例如 Power BI Desktop、內部部署資料閘道，或來自不同獨立服務提供者的 Power BI 應用程式)、用來起始及建立任何與 Power BI 服務後續連線的瀏覽器設定檔，以及初始的安全 Power BI 登入頁面。

    根據初始連線至 Power BI 服務期間提供的資訊，使用者瀏覽器會連絡指定的 Azure CDN (對某些檔案則是 WFE) 下載指定通用檔案的集合，其為啟用瀏覽器與 Power BI 服務互動所需的檔案。 瀏覽器頁面接著會在 Power BI 服務瀏覽器工作階段期間包括 Microsoft Entra 權杖、工作階段資訊、相關聯的後端叢集位置，以及從 Azure CDN 和 WFE 叢集下載的檔案集合。

針對 Power BI 視覺效果，Microsoft 是否會在將項目發佈至資源庫之前，先對自訂視覺效果程式碼執行任何安全性或隱私權評定？

  • 否。 客戶應負責檢閱自訂視覺效果程式碼，並判斷程式碼是否可靠。 因為所有自訂視覺效果程式碼都會在沙箱環境內執行，所以自訂視覺效果中的不當程式碼並不會對 Power BI 服務的其他部分造成影響。

有其他 Power BI 視覺效果會在客戶網路外傳送資訊嗎？

  • 是。 Bing 地圖服務和 ESRI 視覺效果會因使用這些服務的視覺效果而在 Power BI 服務外傳輸資料。

針對範本應用程式，Microsoft 是否會在將項目發佈至資源庫之前，先對範本應用程式執行任何安全性或隱私權評定？

  • 否。 應用程式發行者需為內容負責，而客戶則需負責檢閱並判斷是否應信任範本應用程式發行者。

是否有可以在客戶網路外部傳送資訊的範本應用程式？

  • 是。 客戶有責任檢閱發行者的隱私權原則，並判斷是否要在租用戶上安裝範本應用程式。 發行者需負責通知客戶應用程式的行為和功能。

資料主權呢？ 我們是否能在位於特定地理位置的資料中心佈建租用戶，來確保資料不會離開國家或地區邊界？

  • 特定地理位置中的某些客戶可選擇在國家/地區雲端中建立租用戶，其中的資料儲存體和處理會與所有其他資料中心分開。 因為有獨立的資料信任者代表 Microsoft 負責運作國家/地區雲端 Power BI 服務，所以國家/地區雲端的安全性類型稍有不同。

    或者，客戶也可以在特定區域中設定租用戶。 不過，這類租用戶沒有與 Microsoft 不同的資料信任者。 國家/地區雲端和正式運作之商用 Power BI 服務的定價不同。 如需國家/地區雲端的 Power BI 服務可用性詳細資訊，請參閱 Power BI 國家/地區雲端。

Microsoft 如何為具有 Power BI Premium 訂用帳戶的客戶處理連線？ 那些連線是否與為非 Premium Power BI 服務建立的連線有所不同？

  • 為具有 Power BI Premium 訂用帳戶的客戶建立的連線會實作 Microsoft Entra 企業對企業 (B2B) 授權流程，以使用 Microsoft Entra ID 來啟用存取控制和授權。 Power BI 處理從 Power BI Premium 訂閱者到 Power BI Premium 資源之連線的方式，與其處理任何其他 Microsoft Entra 使用者的方式無異。

伺服器端驗證如何在 WFE 中運作？

  • 使用者驗證順序服務端驗證會依照下列步驟中所述進行，並透過後續影像加以描繪。

  1. 使用者會從瀏覽器起始對 Power BI 服務的連線，方法是在網址列中輸入 Power BI 位址，或從 Power BI 行銷頁面 (https://powerbi.microsoft.com) 選取 [登入]。 連線是使用 TLS 1.2 和 HTTPS 來建立，而瀏覽器和 Power BI 服務之間所有後續的通訊則使用 HTTPS。

  2. Azure 流量管理員會檢查使用者的 DNS 記錄，以判斷已部署 Power BI 的最適當 (通常是最接近的) 資料中心，並以應傳送使用者之目標 WFE 叢集的 IP 位址來回應 DNS。

  3. 然後，WFE 會將使用者重新導向至 Microsoft Online Services 登入頁面。

  4. 使用者通過驗證之後，登入頁面會搭配驗證碼將使用者重新導向至先前所判斷最接近的 Power BI 服務 WFE 叢集。

  5. WFE 叢集會向 Microsoft Entra ID 確認，以使用驗證碼取得 Microsoft Entra 安全性權杖。 當 Microsoft Entra ID 傳回使用者成功驗證及 Microsoft Entra 安全性權杖時，WFE 叢集會諮詢 Power BI 全域服務，其能維護租用戶及其 Power BI 後端叢集位置的清單，並判斷哪一個 Power BI 後端服務叢集包含使用者的租用戶。 然後，WFE 叢集會將應用程式頁面傳回使用者的瀏覽器，其中包含其作業所需的工作階段、存取和路由資訊。

  6. 現在，當用戶端的瀏覽器需要客戶資料時，其會在授權標頭中包含 Microsoft Entra 存取權杖的情況下，將要求傳送至後端叢集位址。 Power BI 後端叢集會讀取 Microsoft Entra 存取權杖並驗證簽章，以確保要求的身分識別有效。 Microsoft Entra 存取權杖將具有根據 Microsoft Entra 原則設定的到期日，而為了維護目前的工作階段，使用者瀏覽器中的 Power BI 用戶端將會定期要求來在存取權杖到期之前加以更新。

顯示 WFE 驗證順序的圖表。

其他資源

如需更多有關 Power BI 的資訊，請參閱以下資源。