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 租使用者系統管理員帳戶，使用您在建立服務主體時所使用的相同安全組，在租使用者中建立配置檔。

管理員 入口網站切換的螢幕快照。

建立設定檔

您可以使用設定檔 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 設定檔 REST API 來取得其配置檔清單。 例如：

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

配置檔許可權

授與用戶許可權給 Power BI 專案的任何 API，也可以將設定檔許可權授與 Power BI 專案。 例如， 新增群組使用者 API 可用來將配置檔許可權授與工作區。

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

  • 配置文件屬於建立它的服務主體，而且只能由該服務主體使用。
  • 建立之後，就無法變更配置檔擁有者。
  • 配置檔不是獨立身分識別。 它需要服務主體 Microsoft Entra 令牌才能呼叫 Power BI REST API。

ISV 應用程式藉由在授權標頭中提供服務主體 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 來準備連線至客戶數據或範例數據的報表。 然後，您可以使用匯 入 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=

使用 數據集參數 來建立可連線到不同客戶數據源的語意模型。 然後，使用 更新參數 API 來定義語意模型所連線的客戶數據。

設定語意模型連接

ISV 通常會以下列兩種方式之一儲存其客戶的數據：

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

每個客戶的個別資料庫

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

  • 語意模型參數： 在連接詳細數據中建立具有 參數 的語意模型（例如 SQL 伺服器名稱、SQL 資料庫名稱）。 然後，將報表匯入客戶的工作區，並變更 參數 以符合客戶的資料庫詳細數據。

  • 更新數據源 API： 建立指向具有範例內容的數據源的 .pbix。 然後，將 .pbix 匯入客戶的工作區，並使用 Update Datasource 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。 Power BI 不支援透過 XMLA 端點或表格式物件模型 （TOM） 的服務主體設定檔。
  • 即時連線模式中的 Azure Analysis Services （AAS） 不支援服務主體配置檔。

Power BI 容量限制

  • 根據購買的 SKU，每個容量只能使用其配置的記憶體和 V 核心。 針對每個 SKU 的建議語意模型大小，請參考 進階版 大型語意模型。
  • 若要使用大於 10 GB 的語意模型，請使用 進階版 容量並啟用大型語意模型設定。
  • 如需可在容量上同時執行的重新整理次數，請參考 資源管理和優化。

管理服務主體

變更服務主體

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

刪除服務主體

警告

刪除服務主體時請非常小心。 您不想不小心遺失其所有相關聯配置文件的數據。

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

數據分隔

當數據以服務主體配置檔分隔時，配置檔與客戶之間的簡單對應可防止某個客戶看到另一個客戶的內容。 使用單 一服務主體時，服務主體 必須能夠存取所有配置檔中的所有不同工作區。

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

  • 人為錯誤或認證外泄不會造成多個租用戶的數據公開。
  • 您可以針對每個租用戶個別完成憑證輪替。

不過，使用多個服務主體會產生高管理成本。 只有在您需要額外的分隔時，才選取此路徑。 請記住，當您 產生內嵌令牌時，定義要顯示使用者之數據的組態，這是終端使用者看不到或變更的僅限後端程式。 使用租使用者特定配置檔要求內嵌令牌會產生該特定配置檔的內嵌令牌，這可讓您在取用時區分客戶。

一個報表，多個語意模型

一般而言，每個租使用者都有一個報表和一個語意模型。 如果您有數百份報表，您將有數百個語意模型。 有時候，您可能有一個報表格式，具有不同的語意模型（例如，不同的參數或連接詳細數據）。 每次您有新版本的報表時，都必須更新所有租使用者的所有報表。 雖然您可以將此自動化，但如果您只有一份報表，則更容易管理。 建立包含要內嵌之報表的工作區。 在工作階段運行時間期間，將報表系結至租使用者特定的語意模型。 如需詳細資訊，請參閱 動態系結 。

自訂和撰寫內容

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

系統受控識別

您可以使用使用者指派或系統指派的受控識別 來建立配置檔，而不是服務主體。 受控識別可減少秘密和憑證的需求。

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

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

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

範例

如需如何使用服務主體配置檔來管理具有 Power BI 和 App-Owns-Data 內嵌的多租用戶環境範例，請從 Power BI Dev Camp（第三方網站）下載應用程式擁有數據多租使用者存放庫。

相關內容