Power BI Embedded でのマルチテナント アプリ用のサービス プリンシパル プロファイル

  • [アーティクル]

この記事では、ISV またはその他の複数顧客の Power BI Embedded アプリの所有者が、サービス プリンシパル プロファイルを使用して、Power BI の "顧客向け埋め込み" ソリューションの一部として各顧客のデータをマップおよび管理する方法について説明します。 サービス プリンシパル プロファイルを使用すると、ISV は、顧客データの分離を改善し、顧客間のより厳格なセキュリティ境界を確立するスケーラブルなアプリケーションを構築できます。 この記事では、このソリューションの利点と制限事項について説明します。

Note

Power BI の "テナント" という単語は、Microsoft Entra テナントのことを指す場合があります。 ただし、この記事では、"マルチテナント" という用語を使って、ソフトウェア アプリケーションの 1 つのインスタンスがデータの物理的および論理的な分離を必要とする複数の顧客または組織 (テナント) にサービスを提供するソリューションについて説明します。 たとえば、Power BI アプリ ビルダーでは、次に示すように、顧客 (またはテナント) ごとに個別のワークスペースを割り当てることができます。 これらの顧客は Microsoft Entra テナントではない場合があるので、ここで使う "マルチテナント アプリケーション" という用語と、Microsoft Entra のマルチテナント アプリケーションを混同しないようにしてください。

"サービス プリンシパル プロファイル" とは、サービス プリンシパルによって作成されるプロファイルです。 この記事で説明するように、ISV アプリでは、サービス プリンシパル プロファイルを使用して Power BI API を呼び出します。

ISV アプリケーションの サービス プリンシパルによって、顧客ごと、またはテナントごとに異なる Power BI プロファイルが作成されます。 顧客が ISV アプリにアクセスすると、そのアプリでは、対応するプロファイルを使用して、ブラウザーでレポートを表示するために使用される埋め込みトークンが生成されます。

サービス プリンシパル プロファイルを使用すると、ISV アプリから、単一の Power BI テナントで複数顧客をホストできます。 Power BI の各プロファイルは 1 顧客を表します。 つまり、プロファイルごとに、特定の 1 顧客のデータの Power BI コンテンツが作成および管理されます。

SP プロファイルとマルチテナントの図。

注意

この記事は、サービス プリンシパル プロファイルを使用してマルチテナント アプリを設定する組織を対象としています。 組織にマルチテナントをサポートするアプリが既にあり、サービス プリンシパル プロファイル モデルに移行する場合は、サービス プリンシパル プロファイル モデルへの移行に関する記事をご覧ください。

Power BI コンテンツの設定は、次の手順で行います。

上記のすべての手順は、Power BI REST API を使用して完全に自動化できます。

前提条件

サービス プリンシパル プロファイルを作成する前に、次のことを行う必要があります。

管理ポータルの切り替えのスクリーンショット。

プロファイルを作成する

プロファイルは、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 を使用して、ワークスペースにプロファイルのアクセス許可を付与できます。

プロファイルを使用する場合は、次の点を理解することが重要です。

  • プロファイルは、それを作成したサービス プリンシパルに属し、そのサービス プリンシパルからのみ使用できます。
  • プロファイルの所有者は、作成後に変更することはできません。
  • プロファイルはスタンドアロンの ID ではありません。 Power BI REST API を呼び出すには、サービス プリンシパルの Microsoft Entra トークンが必要です。

ISV アプリから、サービス プリンシパルの Microsoft Entra トークンを Authorization ヘッダーに、プロファイル ID を 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 の項目をホストするために使用されます。

プロファイルごとに、次のことを行う必要があります。

  • 少なくとも 1 つの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 パラメーター API を使用して、セマンティック モデルから接続する顧客のデータを定義します。

セマンティック モデルの接続を設定する

ISV は通常、次の 2 つの方法のいずれかを使用して顧客のデータを格納します。

どちらの場合も、最終的に Power BI で単一テナント セマンティック モデル (顧客ごとに 1 つのセマンティック モデル) が必要です。

顧客ごとに個別のデータベース

ISV アプリケーションに顧客ごとに個別のデータベースがある場合は、Power BI で単一テナント セマンティック モデルを作成します。 各セマンティック モデルに、対応するデータベースを指す接続の詳細を指定します。 次のいずれかの方法を使用して、接続の詳細が異なる同一のレポートを複数作成しないようにします。

  • セマンティック モデル パラメーター: 接続の詳細 (SQL サーバー名、SQL データベース名など) にパラメーターを指定してセマンティック モデルを作成します。 次に、レポートを顧客のワークスペースにインポートし、顧客のデータベースの詳細に合わせてパラメーターを変更します。

  • Update Datasource API: サンプル コンテンツを含むデータ ソースを指す .pbix を作成します。 次に、.pbix を顧客のワークスペースにインポートし、Update Datasource API を使用して接続の詳細を変更します。

1 つのマルチテナント データベース

ISV アプリケーションですべての顧客に対して 1 つのデータベースを使用する場合は、次のように 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 を使用して完全に自動化できます。

Multi-Geo のニーズ

Power BI Embedded の Multi-Geo のサポートにより、Power BI Embedded を使用して分析をアプリに組み込むアプリケーションをビルドする ISV や組織が、データを世界中の異なるリージョンにデプロイできるようになりました。 異なるリージョンで異なる顧客をサポートするには、顧客のワークスペースを目的のリージョンの容量に割り当てます。 このタスクは、追加コストを伴わないシンプルな操作です。 しかしながら、複数のリージョンのデータを必要とする顧客がいる場合は、そのテナント プロファイルで、異なるリージョンの容量に割り当てられている複数のワークスペースにすべてのアイテムを複製する必要があります。 この重複によって、コストと管理の両方で複雑さが増す可能性があります。

コンプライアンス上の理由から、複数の Power BI テナントを異なるリージョンに作成することもできます。 詳細については、Multi-Geo に関する記事をご覧ください。

コスト効率

Power BI Embedded を使用するアプリケーション開発者は、Power BI Embedded の容量を購入する必要があります。 プロファイルベースの分離モデルは、次の理由により、容量に適しています。

  • 容量に個別に割り当てることができる最小のオブジェクトは、ワークスペースです (たとえば、レポートを割り当てることはできません)。 顧客をプロファイル別に分離することによって、顧客ごとに 1 つずつ、異なるワークスペースを取得できます。 こうすることで、パフォーマンスのニーズに応じて各顧客を柔軟に管理でき、スケールアップまたはスケールダウンによって容量使用率を最適化できます。 たとえば、量が多く、変動しやすい大規模な重要顧客は別個の容量で管理して一貫したサービス レベルを保証する一方、小規模な顧客は別の容量にグループ化してコストを最適化できます。

  • ワークスペースを分離するということは、セマンティック モデルをテナント間で分離することにより、データ モデルを、単一の大規模なセマンティック モデルではなく、小さなチャンクにできるということでもあります。 これらの小さなモデルにより、容量でメモリ使用量をより効率的に管理できます。 使用されていない小規模なセマンティック モデルは、良好なパフォーマンスを維持するために、非アクティブな状態が一定期間続くと削除できます。

複数のセマンティック モデルがある場合、更新プロセスで追加の容量が必要になることがあるので、容量を購入する際には、並列更新の数に対する制限を考慮してください。

行レベルのセキュリティ

この記事では、プロファイルを使用して、顧客ごとに個別のセマンティック モデルを作成する方法について説明します。 または、ISV アプリケーションで、すべての顧客のデータを 1 つの大規模なセマンティック モデルに格納し、行レベルのセキュリティ (RLS) を使用して各顧客のデータを保護することもできます。 このアプローチは、次の理由により、顧客が比較的少数で、小規模から中規模のセマンティック モデルを持つ ISV にとって都合が良い可能性があります。

  • 保持するレポートとセマンティック モデルが 1 つだけである
  • 新規顧客のオンボード プロセスを簡略化できる

ただし、RLS を使用する前に、制限事項を理解しておく必要があります。 すべての顧客のすべてのデータが、1 つの大きな Power BI セマンティック モデルに含まれます。 このセマンティック モデルは、独自のスケーリングやその他の制限がある単一の容量で実行されます。

サービス プリンシパル プロファイルを使用して顧客のデータを分離する場合でも、単一の顧客のセマンティック モデル内で引き続き RLS を使用して、データの異なる部分へのアクセス権を異なるグループに付与することができます。 たとえば、RLS を使用すると、ある部門のメンバーが同じ組織内の別部門のデータにアクセスできないようにすることができます。

考慮事項と制限事項

  • サービス プリンシパル プロファイルは、Power BI REST API と Power BI .NET SDK を介した場合のみサポートされます。 Power BI では、サービス プリンシパル プロファイルは、XMLA エンドポイントおよび表形式オブジェクト モデル (TOM) のいずれを介した場合もサポートされていません。
  • サービス プリンシパル プロファイルは、ライブ接続モードの Azure Analysis Services (AAS) ではサポートされていません。

Power BI の容量の制限事項

サービス プリンシパルを管理する

サービス プリンシパルの変更

Power BI では、プロファイルは、それを作成したサービス プリンシパルに属しています。 つまり、プロファイルを他のプリンシパルと共有することはできません。 この制限により、何らかの理由でサービス プリンシパルを変更する場合は、すべてのプロファイルを再作成し、関連するワークスペースへのアクセスを新しいプロファイルに提供する必要があります。 多くの場合、ISV アプリケーションで、必要に応じて適切なプロファイルを選択するために、プロファイル ID と顧客 ID の間のマッピングを保存する必要があります。 サービス プリンシパルを変更してプロファイルを再作成すると、ID も変更されるため、場合により、ISV アプリケーション データベースのマッピングを更新する必要があります。

サービス プリンシパルの削除

警告

サービス プリンシパルを削除する場合は十分に注意してください。 関連するすべてのプロファイルのデータを誤って失わないようにするためです。

Active Directory 内のサービス プリンシパルを削除すると、Power BI 内のすべてのプロファイルが削除されます。 ただし、Power BI によってコンテンツが即座に削除されるわけではないため、テナント管理者は引き続きワークスペースにアクセスできます。 実稼働システムで使用されているサービス プリンシパルを削除する場合、特に Power BI でこのサービス プリンシパルを使用してプロファイルを作成した場合は注意してください。 プロファイルが作成されたサービス プリンシパルを削除する場合は、すべてのプロファイルを再作成し、関連するワークスペースへのアクセスを新しいプロファイルに提供し、ISV アプリケーション データベースのプロファイル ID を更新する必要があることに注意してください。

データの分離

サービス プリンシパル プロファイルによってデータが分離されている場合、プロファイルと顧客の間のシンプルなマッピングによって、ある顧客が別の顧客のコンテンツを表示できないようにできます。 単一の "サービス プリンシパル" を使用するには、サービス プリンシパルがすべてのプロファイル内のすべての異なるワークスペースにアクセスできる必要があります。

さらに分離を追加するには、単一のサービス プリンシパルが異なるプロファイルを使用して複数のワークスペースにアクセスするのではなく、各テナントに個別のサービス プリンシパルを割り当てます。 個別のサービス プリンシパルの割り当てには、次のようないくつかの利点があります。

  • 人為的なエラーや資格情報の漏洩によって、複数テナントのデータが流出することがありません。
  • 証明書のローテーションをテナントごとに個別に行うことができます。

ただし、複数のサービス プリンシパルを使用すると、管理コストは高くなります。 このパスは、追加の分離が必要な場合にのみ選択してください。 エンド ユーザーに表示するデータの構成は、エンド ユーザーが表示または変更できないバックエンドのみのプロセスである、埋め込みトークンを生成するときに定義されることに注意してください。 テナント固有のプロファイルを使用して埋め込みトークンを要求すると、その特定のプロファイルに対して埋め込みトークンが生成されます。これにより、顧客の使用量が分離されます。

1 つのレポート、複数のセマンティック モデル

一般に、テナントごとに 1 つのレポートと 1 つのセマンティック モデルがあります。 数百のレポートがある場合は、セマンティック モデルも数百になります。 場合によっては、レポート形式は 1 つで、セマンティック モデルが異なる (たとえば、パラメーターや接続の詳細が異なる) ことがあります。 新しいバージョンのレポートが作成されるたびに、すべてのテナントに対してすべてのレポートを更新する必要があります。 これを自動化することもできますが、レポートのコピーを 1 つだけ用意すれば、管理が容易になります。 埋め込むレポートを含むワークスペースを作成します。 セッション ランタイム中、レポートをテナント固有のセマンティック モデルにバインドします。 詳細については、動的バインドに関する記事をご覧ください。

コンテンツのカスタマイズと作成

コンテンツを作成するときは、だれに編集するアクセス許可を与えるかを慎重に検討してください。 各テナントで複数のユーザーに編集を許可すると、セマンティック モデルの制限を超えやすくなります。 ユーザーに編集機能を提供することを決定した場合は、そのコンテンツ生成を注意深く監視し、必要に応じてスケールアップします。 同じ理由から、この機能は、各ユーザーがレポートを少し変更して自分用に保存できる、コンテンツのカスタマイズには使用しないことをお勧めします。 ISV アプリケーションでコンテンツのカスタマイズが許可されている場合は、ユーザー固有のコンテンツに対してワークスペースの保持ポリシーを導入することを検討してください。 リテンション ポリシーを使用すると、ユーザーが新しい場所に移動したり、退社したり、プラットフォームの使用を停止したりしたときに、コンテンツを簡単に削除できます。

システム マネージド ID

サービス プリンシパルの代わりに、ユーザー割り当てまたはシステム割り当てのマネージド ID を使用してプロファイルを作成できます。 マネージド ID により、シークレットと証明書の必要性が軽減されます。

システム マネージド ID を使用する場合は、次の理由から、注意が必要です。

  • システム割り当てマネージド ID が誤って無効にされると、プロファイルにアクセスできなくなります。 この状況は、サービス プリンシパルを削除した場合と似ています。
  • システム割り当てマネージド ID は、Azure (Web アプリ) のリソースに接続されています。 リソースを削除すると、ID が削除されます。
  • 複数のリソース (異なるリージョンの異なる Web アプリ) を使用すると、複数の ID を個別に管理する必要があります (各 ID には独自のプロファイルがあります)。

上記の考慮事項により、ユーザー割り当てマネージド ID を使用することをお勧めします。

例

Power BI と App-Owns-Data 埋め込みでサービス プリンシパル プロファイルを使ってマルチテナント環境を管理する方法の例については、Power BI Dev Camp (サード パーティ サイト) からアプリ所有データ マルチテナント リポジトリをダウンロードしてください。

関連するコンテンツ