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

[アーティクル]
08/01/2024

この記事では、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 を使用して完全に自動化できます。

前提条件

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

サービスプリンシパルを使用して Power BI コンテンツを埋め込む最初の 3 つの手順に従ってサービスプリンシパルを設定します。
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 を使用して、ワークスペースにプロファイルのアクセス許可を付与できます。

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

プロファイルは、それを作成したサービスプリンシパルに属し、そのサービスプリンシパルからのみ使用できます。
プロファイルの所有者は、作成後に変更することはできません。
プロファイルはスタンドアロンの 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 つの方法のいずれかを使用して顧客のデータを格納します。

顧客ごとに個別のデータベース
1 つのマルチテナントデータベース

どちらの場合も、最終的に 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"
    }
  ]
}

設計の側面

プロファイルベースのマルチテナントソリューションを設定する前に、次の問題を認識しておく必要があります。

スケーラビリティ
自動化と運用の複雑さ
Multi-Geo のニーズ
コスト効率
行レベルのセキュリティ

スケーラビリティ

顧客ごとにデータを個別のセマンティックモデルに分離することで、大規模なセマンティックモデルの必要性を最小限に抑えます。容量がオーバーロードになったら、未使用のセマンティックモデルを削除して、アクティブなセマンティックモデルのためにメモリを解放できます。この最適化は、単一の大規模なセマンティックモデルでは不可能です。複数のセマンティックモデルを使用することで、必要に応じて、複数の 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 を使用すると、ある部門のメンバーが同じ組織内の別部門のデータにアクセスできないようにすることができます。

考慮事項と制限事項

サービスプリンシパルプロファイルは、Analysis Services クライアントライブラリバージョン 16.0.139.27 以降を使用する場合は、Power BI REST API、Power BI .NET SDK、XMLA エンドポイントおよび表形式オブジェクトモデル (TOM) を介した場合のみサポートされます。 Power BI では、サービスプリンシパルプロファイルは、古いクライアントライブラリを使用した場合、XMLA エンドポイントまたは表形式オブジェクトモデル (TOM) のいずれを介した場合もサポートされていません。
サービスプリンシパルプロファイルは、ライブ接続モードの Azure Analysis Services (AAS) ではサポートされていません。
1 つのサービスプリンシパルが保有できるプロファイルの最大数は 100,000 です。

Power BI の容量の制限事項

各容量では、購入した SKU に従って、割り当てられているメモリと仮想コアのみを使用できます。各 SKU の推奨セマンティックモデルサイズについては、「Premium 大規模セマンティックモデル」を参照してください。
10 GB を超えるセマンティックモデルを使用するには、Premium 容量を使用し、大規模なセマンティックモデルの設定を有効にします。
容量に対して同時に実行できる更新の数については、リソースの管理と最適化に関する記事をご覧ください。

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

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

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 (サードパーティサイト) からアプリ所有データマルチテナントリポジトリをダウンロードしてください。

次の方法で共有

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

前提条件

プロファイルを作成する

プロファイルのアクセス許可

ワークスペースの作成

レポートとセマンティックモデルをインポートする

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

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

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

レポートの埋め込み

設計の側面

スケーラビリティ

自動化と運用の複雑さ

Multi-Geo のニーズ

コスト効率

行レベルのセキュリティ

考慮事項と制限事項

Power BI の容量の制限事項

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

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

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

データの分離

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

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

システムマネージド ID

例

フィードバック

その他のリソース

次の方法で共有

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

前提条件

プロファイルを作成する

プロファイルのアクセス許可

ワークスペースの作成

レポートとセマンティック モデルをインポートする

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

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

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

レポートの埋め込み

設計の側面

スケーラビリティ

自動化と運用の複雑さ

Multi-Geo のニーズ

コスト効率

行レベルのセキュリティ

考慮事項と制限事項

Power BI の容量の制限事項

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

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

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

データの分離

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

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

システム マネージド ID

例

関連するコンテンツ

フィードバック

その他のリソース

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

レポートとセマンティックモデルをインポートする

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

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

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

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

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

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

システムマネージド ID