Power BI Embedded 中多租用戶應用程式的服務主體設定檔

  • 發行項

本文章說明 ISV 或其他具有許多客戶的任何 Power BI Embedded 應用程式擁有者，如何使用服務主體設定檔，在 Power BI「為您的客戶內嵌」解決方案中，對應和管理每個客戶的資料。 ISV 可以利用服務主體設定檔組建可調整的應用程式，以加強客戶資料隔離效果，並在客戶之間建立更嚴密的安全性界限。 本文章探討此解決方案的優點和限制。

注意

Power BI 中的「租用戶」一詞，有時是指 Microsoft Entra 租用戶。 不過，在本文中，我們使用「多組織用戶管理」一詞來描述一個解決方案，其透過軟體應用程式的單一執行個體，服務需要實體和邏輯資料分隔的多個客戶或組織 (租用戶)。 例如，Power BI 應用程式建立器可以為每個客戶 (或租用戶) 配置單獨的工作區，如下所示。 這些客戶不一定是 Microsoft Entra 租用戶，因此請不要將我們在此處使用的字詞「多租用戶應用程式」與 Microsoft Entra 多租用戶應用程式混淆。

「服務主體設定檔」是由服務主體所建立的設定檔。 ISV 應用程式會使用服務主體設定檔呼叫 Power BI API，如本文所述。

ISV 應用程式服務主體為每個客戶或租用戶建立不同的 Power BI 設定檔。 當客戶前往 ISV 應用程式時，應用程式會使用對應的設定檔來產生內嵌權杖，以在瀏覽器中轉譯報表。

使用服務主體設定檔，可讓 ISV 應用程式在單一 Power BI 租用戶上代管多個客戶。 每個設定檔分別代表 Power BI 中的一個客戶。 換句話說，每個設定檔都會建立並管理一個特定客戶資料的 Power BI 內容。

SP 設定檔和多組織用戶管理圖表。

注意

本文的對象是想要使用服務主體設定檔來設定多租用戶應用程式的組織。 如果您的組織已經有支援多組織用戶管理的應用程式，而您想要移轉至服務主體設定檔模型，請參閱移轉至服務主體設定檔模型。

設定 Power BI 內容包括下列步驟：

上述所有步驟都可以使用 Power BI REST API 完全自動化。

必要條件

在建立服務主體設定檔前，您必須先：

  • 依照使用服務主體內嵌 Power BI 內容的前三個步驟設定服務主體。
  • 從 Power BI 租用戶系統管理員帳戶，啟用在租用戶中建立設定檔的功能，並使用建立服務主體時使用的相同安全性群组。

系統管理員入口網站切換設定的螢幕擷取畫面。

建立設定檔

您可以使用Profiles REST API 建立、更新和刪除設定檔。

例如，若要建立設定檔：

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

服務主體也可以呼叫 GET Profiles REST API，以取得其設定檔的清單。 例如：

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

設定檔權限

任何可將使用者權限授與 Power BI 項目的 API，也都可將設定檔權限授與 Power BI 項目。 例如，Add Group User API 可用來將設定檔權限授與工作區。

使用設定檔時，請務必了解下列幾點：

  • 設定檔屬於加以建立的服務主體，且只有該服務主體能使用。
  • 建立之後，就無法變更設定檔擁有者。
  • 設定檔不是獨立身分識別。 其需要服務主體 Microsoft Entra 權杖，才能呼叫 Power BI REST API。

ISV 應用程式在 Authorization 標頭中提供服務主體 Microsoft Entra 權杖、在 X-PowerBI-Profile-Id 標頭中提供設定檔識別碼，藉此呼叫 Power BI REST API。 例如：

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

建立工作區

Power BI 工作區 用來代管 Power BI 項目，例如報表和語意模型。

每個設定檔都需要：

  • 建立至少一個 Power BI 工作區

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • 將存取權限授與工作區。 服務主體設定檔必須具有工作區的系統管理員存取權。

  • 將工作區指派給容量

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

深入了解 Power BI 工作區。

匯入報表和語意模型

使用 Power BI Desktop 準備連線至客戶資料或範例資料的報表。 然後，您可以使用 Import API，將內容匯入已建立的工作區。

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

使用資料集參數建立可連線到不同客戶資料來源的語意模型。 然後，使用 Update Parameters API 定義語意模型要連線到哪個客戶資料。

設定語意模型的連線

ISV 通常以下列兩種方式之一儲存其客戶的資料：

不論是哪一種情況，最終都應該在 Power BI 中使用單一租用戶語意模型 (每個客戶一個語意模型)。

每個客戶各一個資料庫

如果 ISV 應用程式有每個客戶的個別資料庫，請在 Power BI 中建立單一租用戶語意模型。 為每個語意模型提供指向其對應資料庫的連線詳細資料。 使用下列其中一種方法，以避免使用不同的連線詳細資料建立多個相同的報表：

  • 語意模型參數：使用連線詳細資料中的參數 (例如 SQL 伺服器名稱、SQL 資料庫名稱) 建立語意模型。 然後，將報表匯入客戶的工作區，並變更參數以符合客戶的資料庫詳細資料。

  • 更新資料來源 API：建立 .pbix，指向具有範例內容的資料來源。 然後，將 .pbix 匯入客戶的工作區，並使用更新資料來源 API 變更連線詳細資料。

一個多租用戶資料庫

如果 ISV 應用程式為其所有客戶使用一個資料庫，請將客戶分隔成 Power BI 中的不同語意模型，如下所示：

使用僅擷取相關客戶資料的參數建立報表。 然後，將報表匯入客戶的工作區，並將參數變更為僅擷取相關客戶資料。

內嵌報表

設定完成之後，您可以使用內嵌權杖，將客戶報表和其他項目內嵌至您的應用程式。

當客戶前往您的應用程式時，請使用對應的設定檔呼叫 GenerateToken API。 使用產生的內嵌權杖，在客戶的瀏覽器中內嵌報表或其他項目。

產生內嵌權杖：

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

設計層面

在設定以設定檔為基礎的多租用戶解決方案之前，您應該注意下列問題：

延展性

將資料分隔成每個客戶的個別語意模型，可以將大型語意模型的需求降到最低。 當容量超載時，可以收回未使用的語意模型，以釋放記憶體給使用中的語意模型。 單一大型語意模型不可能進行這樣的最佳化。 透過使用多個語意模型，您還可以在必要時，將租用戶分隔成多個 Power BI 容量。

如果沒有設定檔，服務主體最多只能建立 1,000 個工作區。 為克服此一限制，服務主體可以建立多個設定檔，而每個設定檔可以存取/建立最多 1,000 個工作區。 有了多個設定檔，ISV 應用程式就可以使用相異的邏輯容器來隔離每個客戶的內容。

一旦服務主體設定檔具有工作區的存取權，就可以移除其父代服務主體對該工作區的存取權，以避免可擴縮性問題。

即使有這些優點，您仍應考慮應用程式可能的縮放規模。 例如，設定檔可以存取的工作區項目數目有限。 目前，設定檔的限制與一般使用者相同。 如果 ISV 應用程式可讓終端使用者儲存其內嵌報表的個人化副本，客戶的設定檔將可以存取其所有使用者建立的全部報表。 此模型最終可能超過限制。

自動化與操作複雜度

使用以 Power BI 設定檔為基礎的分隔，您可能需要管理數百或數千個項目。 因此，務必要定義應用程式生命週期管理中經常發生的流程，並確保您擁有正確的工具集，以大規模執行這些作業。 這些作業包括：

  • 新增新的租用戶
  • 更新部分或全部租用戶的報表
  • 更新部分或全部租用戶的語意模型結構描述
  • 針對特定租用戶的未計劃自訂項目
  • 語意模型重新整理的頻率

例如，為新租用戶建立設定檔和工作區是一項常見的工作，可以使用 Power BI REST API 完全自動化。

多重異地複寫需求

Power BI Embedded 的多地理位置支援意味著，使用 Power BI Embedded 組建應用程式以將分析內嵌到應用中的 ISV 和組織，現在可以在全世界不同區域部署其資料。 若要支援不同區域中的不同客戶，請將客戶的工作區指派給所需區域中的容量。 此工作是一項簡單的作業，不會產生額外成本。 不過，如果您有客戶需要來自多個區域的資料，租用戶設定檔應該將所有項目複製到指派給不同區域容量的多個工作區。 此複製可能會增加成本和管理複雜度。

基於合規性考慮，您可能仍想要在不同的區域中建立多個 Power BI 租用戶。 深入了解多地理位置。

成本效益

使用 Power BI Embedded 的應用程式開發人員需要購買 Power BI Embedded 容量。 以設定檔為基礎的分隔模型適用於容量，因為：

  • 您可以獨立指派給容量的最小物件是工作區 (例如，您無法指派報表)。 透過按設定檔分隔客戶，您可以取得不同的工作區，每個客戶一個。 如此一來，您就可以彈性地根據每個客戶的效能需求進行管理，並透過縮放規模來最佳化容量使用率。 例如，您可以在一個單獨的容量中管理具有高容量和波動性的大型和重要客戶，以確保一致的服務等級，同時將較小的客戶分組到另一個容量中，以最佳化成本。

  • 分隔工作區還意味著在租用戶之間分隔語意模型，讓資料模型位於較小的區塊中，而不是單個大型語意模型。 這些較小的模型可提高容量管理記憶體使用量的效率。 未使用的小型語意模型，可在處於非使用狀態一段時間後收回，以維持良好的效能。

購買容量時，請考慮並行重新整理的數目上限，因為當您有多個語意模型時，重新整理流程可能需要額外的容量。

低層級安全性

本文章說明如何使用設定檔為每個客戶建立個別的語意模型。 或者，ISV 應用程式可以將所有客戶的資料儲存在一個大型語意模型中，並使用列層級安全性 (RLS) 來保護每個客戶的資料。 對於擁有相對較少客戶和中小型語意模型的 ISV 來說，這種方法相當方便，因為：

  • 只有一個報表和一個語意模型需要維護
  • 可簡化新客戶的上線流程

不過，在使用 RLS 之前，請確保您了解其限制。 全部客戶的所有資料都在一個大型 Power BI 語意模型中。 此語意模型會在單一容量中執行，並具有自己的縮放和其他限制。

即使您使用服務主體設定檔來分隔客戶的資料，您仍然可以在單一客戶的語意模型中使用 RLS，讓不同的群組存取資料的不同部分。 例如，您可以使用 RLS，防止某個部門的成員存取相同組織中另一個部門的資料。

考量與限制

  • 服務主體設定檔僅透過 Power BI REST API、Power BI .NET SDK 支援；當使用 Analysis Services 用戶端程式庫版本 16.0.139.27 或更高版本時，透過 XMLA 端點和表格物件模型 (TOM) 支援。 服務主體設定檔不透過用戶端程式庫版本較舊的 XMLA 端點和表格物件模型 (TOM)，在 Power BI 中支援。
  • Azure Analysis Services (AAS) 在即時連線模式中不支援服務主體設定檔。
  • 單一服務主體可以擁有的最大配置檔是 100,000。

Power BI 容量限制

管理服務主體

變更服務主體

在 Power BI 中，設定檔屬於加以建立的服務主體。 這表示，設定檔無法與其他主體共用。 基於此限制，如果出於任何原因想要變更服務主體，您必須重新建立所有設定檔，並為其提供相關工作區的存取權。 ISV 應用程式通常需要儲存設定檔識別碼與客戶識別碼之間的對應，才能在需要時挑選正確的設定檔。 如果您變更服務主體並重新建立設定檔，識別碼也會變更，因此您可能需要更新 ISV 應用程式資料庫中的對應。

刪除服務主體

警告

刪除服務主體時要格外小心。 您不會想不小心遺失其所有相關設定檔的資料。

如果您刪除使用中目錄裡的服務主體，將會刪除其在 Power BI 中的所有設定檔。 不過，Power BI 不會立即刪除內容，因此租用戶系統管理員仍然可以存取工作區。 刪除實際執行系統所使用的服務主體時請小心，特別是當您在 Power BI 中使用該服務主體建立設定檔時。 如果您確實刪除已建立設定檔的服務主體，請注意您必須重新建立所有設定檔、為新設定檔提供相關工作區的存取權，以及更新 ISV 應用程式資料庫中的設定檔識別碼。

資料分隔

當資料以服務主體設定檔分隔時，設定檔與客戶之間的簡易對應能夠防止某個客戶看到另一個客戶的內容。 使用單一服務主體時，該服務主體必須能夠存取所有設定檔中的全部不同工作區。

若要新增額外的分隔，請將個別的服務主體指派給每個租用戶，而不是讓單個服務主體使用不同的設定檔存取多個工作區。 指派個別的服務主體有數個優點，包括：

  • 人為錯誤或認證外洩不會造成多個租用戶的資料遭到公開。
  • 可以為每個租用戶個別完成憑證變換。

但是，使用多個服務主體會產生高管理成本。 請在需要額外的分隔時，再選取此途徑。 請記住，向終端使用者顯示的資料設定是在產生內嵌權杖時定義的，這是終端使用者無法查看或變更的純後端流程。 使用租用戶專屬設定檔要求內嵌權杖，将為該特定設定檔產生內嵌權杖，從而在使用過程中實現客戶分隔。

一個報表，多個語意模型

一般而言，每個租用戶都有一個報表和一個語意模型。 如果您有數百份報表，您將有數百個語意模型。 有時候，您可能有一個報表格式，具有不同的語意模型 (例如，不同的參數或連線詳細資料)。 每次您有新版本的報表時，都必須更新所有租用戶的全部報表。 雖然您可以將此自動化，但如果您只有一份報表則會更容易管理。 請建立一個包含要內嵌之報表的工作區。 在工作執行階段期間，將報表繫結至租用戶專屬的語意模型。 如需其他詳細資料，請參閱動態繫結。

自訂和製作內容

當您建立內容時，請仔細考量誰有權限編輯內容。 如果您允許每個租用戶中的多個使用者編輯，則很容易超過語意模型限制。 如果您決定為使用者提供編輯功能，請密切監視內容的產生，並視需要擴大。 基於相同原因，我們不建議將這項功能用於內容個人化，因為這樣每個使用者可以對報表進行小幅度變更，並自行儲存。 如果 ISV 應用程式允許內容個人化，請考量為使用者專屬內容引進工作區資料保留原則。 當使用者換到新職位、離開公司或停止使用平台時，資料保留原則可讓您更輕鬆地刪除內容。

系統受控識別

若不使用服務主體，您可以使用使用者指派或系統指派的受控識別建立設定檔。 受控識別可減少祕密和憑證的需求。

使用系統受控識別時請小心，因為：

  • 如果系統指派的受控識別意外關閉，您將失去設定檔的存取權。 這種狀況與刪除服務主體的情況類似。
  • 系統指派的受控識別會連線到 Azure 中的資源 (Web 應用程式)。 如果您刪除資源，將會刪除身分識別。
  • 使用多個資源 (不同區域中的不同 Web 應用程式) 會導致需要個別管理多個身分識別 (每個身分識別都有自己的設定檔)。

基於上述考量，建議您使用使用者指派的受控識別。

範例

如需範例，以了解如何使用服務主體設定檔管理具有 Power BI 和應用程式擁有資料內嵌的多租用戶環境，請從 Power BI Dev Camp (第三方網站) 下載應用程式擁有資料多租用戶存放庫。

相關內容