概要： 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、ロナルド・チャン、オリ・エドゥアル、アントン・フリッツ、イダン・シェインバーグ、ロン・ギルバーグ、サギフ・ハダヤ、ポール・インバー、イゴール・ウジビエフ、マイケル・ロス、ハイメ・タルキノ、Gennady Pats、Orion Lee、Yury Berezansky、Maya Shenhav、Romit Chattopadhyay、Yariv Maimon、 Bogdan Crivat
技術レビュー担当者: クリスティアン・ペチュレスク、アミール・ネッツ、セルゲイ・グンドロフ
適用対象: Power BI SaaS、Power BI Desktop、Power BI Premium、Power BI Embedded Analytics、Power BI Mobile。
注
このホワイト ペーパーを保存または印刷するには、ブラウザーから [印刷 ] を選択し、[ PDF として保存] を選択します。
イントロダクション
Power BI は、セルフサービス ビジネス インテリジェンス ダッシュボード、レポート、セマンティック モデル、視覚化を簡単かつ迅速に作成できる、Microsoft のオンライン ソフトウェア サービス (SaaS、またはサービスとしてのソフトウェア) です。 Power BI を使用すると、さまざまなデータ ソースに接続し、それらの接続のデータを結合して整形した後、他のユーザーと共有できるレポートとダッシュボードを作成できます。
世界は急速に変化しています。組織はデジタル変革を加速しており、リモート作業の大幅な増加、オンライン サービスに対する顧客の需要の増加、運用とビジネスの意思決定における高度なテクノロジの使用の増加が見られます。 そして、これらすべてがクラウドを利用しています。
クラウドへの移行がトリクルから洪水に変わり、それに伴う新しい公開された領域によって、より多くの企業が クラウド内のデータのセキュリティを確保する方法 と、 機密データが漏洩するのを防ぐためにどのようなエンドツーエンドの保護を利用できるか を尋ねています。また、多くの場合、企業で最も戦略的な情報の一部を処理する BI プラットフォームでは、これらの質問は 2 倍重要です。
何十年も前の BI セキュリティ モデル (オブジェクト レベルと行レベルのセキュリティ) の基礎は重要ですが、クラウド時代に必要なセキュリティの種類を提供するだけでは不十分です。 代わりに、組織はビジネス インテリジェンス データ用のクラウドネイティブの多層防御セキュリティ ソリューションを探す必要があります。
Power BI は、業界をリードする完全かつ密閉的なデータ保護を提供するように構築されました。 この製品は業界で最も高いセキュリティ分類を獲得しており、現在、多くの国家安全保障機関、金融機関、医療提供者が最も機密性の高い情報を預けています。
それはすべて基礎から始まります。 2000 年代初頭の大まかな期間の後、Microsoft はセキュリティの脆弱性に対処するために多大な投資を行い、次の数十年で、マシンオンチップ BIOS カーネルと同じくらい深く、エンド ユーザー エクスペリエンスまで拡張する強力なセキュリティ スタックを構築しました。 これらの深い投資は継続しており、現在、3,500 人以上の Microsoft エンジニアが Microsoft のセキュリティ スタックの構築と強化に取り組み、絶えず変化する脅威の状況に積極的に対処しています。 何十億ものコンピューター、数兆のログイン、数十億もの情報が Microsoft の保護に委託されているため、同社は現在、テクノロジ業界で最も高度なセキュリティ スタックを所有しており、悪意のあるアクターとの戦いのグローバル リーダーとして広く見られています。
Power BI は、この強力な基盤に基づいています。 Azure が世界で最も機密性の高いデータを提供および保護する権利を獲得したのと同じセキュリティ スタックを使用し、Microsoft 365 の最も高度な情報保護およびコンプライアンス ツールと統合されます。 その上で、多層セキュリティ対策を通じてセキュリティを実現し、クラウド時代の固有の課題に対処するように設計されたエンドツーエンドの保護を実現します。
機密性の高い資産を保護するためのエンド ツー エンドのソリューションを提供するために、製品チームは、複数の同時フロントで困難な顧客の懸念に対処する必要があります。
- 接続できるユーザー、接続先、接続方法を制御する方法接続を制御する方法
- データはどのように格納されますか?暗号化方法データにはどのようなコントロールがありますか?
- 機密データを制御および保護するにはどうすればよいですか?このデータが組織外に漏えいしないようにするにはどうすればよいですか?
- どのような操作を実行しているかを監査するにはどうすればよいですか?サービスに疑わしいアクティビティがある場合、迅速に対応するにはどうすればよいですか?
この記事では、これらすべての質問に対する包括的な回答を提供します。 サービス アーキテクチャの概要から始まり、システム内のメイン フローのしくみについて説明します。 次に、Power BI に対するユーザーの認証方法、データ接続の確立方法、および Power BI がサービスを介してデータを格納および移動する方法について説明します。 最後のセクションでは、サービス管理者として最も重要な資産を保護できるセキュリティ機能について説明します。
Power BI サービスは、 Microsoft Online Services の使用条件と Microsoft Enterprise のプライバシーに関する声明に準拠します。 データ処理の場所については、 Microsoft オンライン サービス条項 のデータ処理の場所に関する用語と 、データ保護補遺を参照してください。 コンプライアンス情報については、 Microsoft セキュリティ センター が Power BI の主要なリソースです。 Power BI チームは、お客様に最新のイノベーションと生産性を提供できるように努力しています。 Microsoft コンプライアンス オファリングの詳細を確認してください。
Power BI サービスは、セキュリティの保証とコンプライアンスの要件をサポートする厳密なセキュリティ プラクティスであるセキュリティ開発ライフサイクル (SDL) に従います。 SDL は、開発者がソフトウェアの脆弱性の数と重大度を低減しながら、開発コストを削減することで、より安全なソフトウェアを構築するために役立ちます。 詳細については、「 Microsoft セキュリティ開発ライフサイクル プラクティス」を参照してください。
Power BI アーキテクチャ
Power BI サービスは、Microsoft の クラウド コンピューティング プラットフォームである Azure 上に構築されています。 現在、Power BI は世界中の多くのデータセンターにデプロイされています。これらのデータセンターによって提供されるリージョン内のお客様が利用できるアクティブなデプロイは多数あり、アクティブなデプロイごとにバックアップとして機能するパッシブ デプロイの数は同じです。
Web フロントエンド クラスター (WFE)
Web フロントエンド クラスター (WFE) クラスターは、サイトの読み込み時に最初の HTML ページコンテンツをユーザーのブラウザーに提供し、ブラウザーでサイトをレンダリングするために使用される Azure Content Delivery Network (CDN) コンテンツへのポインターを提供します。
WFE クラスターは、 Azure App Service Environment で実行されている ASP.NET Web サイトで構成されます。 ユーザーが Power BI サービスに接続しようとすると、クライアントの DNS サービスが Azure Traffic Manager と通信して、Power BI デプロイで最も適切な (通常は最も近い) データセンターを見つける場合があります。 このプロセスの詳細については、「 Azure Traffic Manager のパフォーマンス トラフィック ルーティング方法」を参照してください。
*.js、*.css、イメージ ファイルなどの静的リソースは、ほとんどの場合、Azure CDN に格納され、ブラウザーによって直接取得されます。 ソブリン政府クラスターのデプロイメントはこの規則の例外です。コンプライアンス上の理由で、CDNは省略され、代わりに静的コンテンツのホスティングには準拠したリージョンにあるWFEクラスターが使用されます。
Power BI バックエンド クラスター
バックエンド クラスターは、Power BI で使用できるすべての機能のバックボーンです。 WFE および API クライアントによって使用される複数のサービス エンドポイントと、バックグラウンド作業サービス、データベース、キャッシュ、およびその他のさまざまなコンポーネントで構成されます。
バックエンドはほとんどの Azure リージョンで利用でき、利用可能になると新しいリージョンにデプロイされます。 1 つの Azure リージョンで 1 つ以上のバックエンド クラスターがホストされます。これにより、1 つのクラスターの垂直方向と水平方向のスケーリングの制限が使い果たされると、Power BI サービスの無制限の水平スケーリングが可能になります。
各バックエンド クラスターはステートフルであり、そのクラスターに割り当てられているすべてのテナントのすべてのデータをホストします。 特定のテナントのデータを含むクラスターは、テナントのホーム クラスターと呼ばれます。 認証されたユーザーのホーム クラスター情報は、グローバル サービスによって提供され、WFE によってテナントのホーム クラスターに要求をルーティングするために使用されます。
各バックエンド クラスターは、特定のタスク、SQL データベース、ストレージ アカウント、サービス バス、キャッシュなどのステートフル リソース、およびその他の必要なクラウド コンポーネントを実行するために調整された複数のサイズ変更可能なスケール セットに結合された複数の仮想マシンで構成されます。
テナントのメタデータとデータは、同じ Azure 地域のペアになっている Azure リージョンのセカンダリ バックエンド クラスターへのデータ レプリケーションを除き、クラスターの制限内に格納されます。 セカンダリ バックエンド クラスターは、リージョンの障害が発生した場合のフェールオーバー クラスターとして機能し、それ以外の場合はパッシブです。
バックエンド機能は、パブリック インターネットからアクセスできる 2 つのコンポーネントを除き、外部からアクセスできないクラスターの仮想ネットワーク内のさまざまなマシンで実行されているマイクロ サービスによって提供されます。
- ゲートウェイ サービス
- Azure API Management
Power BI Premium インフラストラクチャ
Power BI Premium は、高度な AI、ライセンスのないユーザーへの配布など、Premium Power BI 機能を必要とするサブスクライバー向けのサービスを提供します。お客様が Power BI Premium サブスクリプションにサインアップすると、Azure Resource Manager を使用して 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 クラスターで構成されます (最小値は 1 つです)。 ほとんどの Premium リソースはクラスター (コンピューティングなど) 内にカプセル化され、一般的なリージョン リソース (メタデータ ストレージなど) がいくつかあります。 Premium インフラストラクチャを使用すると、リージョン内で水平方向のスケーラビリティを実現する 2 つの方法があります。クラスター内のリソースを増やしたり、必要に応じて必要に応じてクラスターを追加したりできます (クラスター リソースが制限に近づいている場合)。
各クラスターのバックボーンは、 仮想マシン スケール セット と Azure Service Fabric によって管理されるコンピューティング リソースです。 仮想マシン スケール セットと Service Fabric を使用すると、Power BI Premium サービスとアプリケーションのデプロイ、管理、監視を拡大し、調整するにつれて、コンピューティング ノードを迅速かつ簡単に増加させることができます。
セキュリティで保護された信頼性の高いインフラストラクチャを確保するリソースが多数存在します。ロード バランサー、仮想ネットワーク、ネットワーク セキュリティ グループ、Service Bus、ストレージなどです。Power BI Premium に必要なすべてのシークレット、キー、証明書は、 Azure Key Vault によって排他的に管理されます。 すべての認証は、Microsoft Entra ID との統合によって排他的に行われます。
Power BI Premium インフラストラクチャに対するすべての要求は、最初にフロントエンド ノードに送信されます。外部接続に使用できるノードは 1 つだけです。 残りのリソースは、仮想ネットワークの背後に隠れています。 フロントエンド ノードは、要求の認証、処理、または適切なリソース (バックエンド ノードなど) への転送を行います。
バックエンド ノードは、ほとんどの Power BI Premium の機能を提供します。
Power BI Mobile
Power BI Mobile は、Android、iOS、Windows (UWP) の 3 つの主要なモバイル プラットフォーム向けに設計されたアプリのコレクションです。 Power BI Mobile アプリのセキュリティに関する考慮事項は、次の 2 つのカテゴリに分類されます。
- デバイスの通信
- デバイス上のアプリケーションとデータ
デバイス通信では、すべての Power BI Mobile アプリケーションが Power BI サービスと通信し、ブラウザーで使用されるのと同じ接続と認証シーケンスを使用します。これについては、このホワイト ペーパーで詳しく説明します。 iOS および Android 用の Power BI モバイル アプリケーションは、アプリケーション自体内でブラウザー セッションを起動します。一方、Windows モバイル アプリは、(サインイン プロセス用に) Power BI との通信チャネルを確立するブローカーを起動します。
次の表は、モバイル デバイス プラットフォームに基づく Power BI Mobile の証明書ベースの認証 (CBA) のサポートを示しています。
| CBA サポート | iOS | アンドロイド | ウィンドウズ |
|---|---|---|---|
| Power BI (サービスにサインイン) | サポートされています | サポートされています | サポートされていません |
| SSRS ADFS オンプレミス (SSRS サーバーに接続) | サポートされていません | サポートされています | サポートされていません |
| SSRS アプリ プロキシ | サポートされています | サポートされています | サポートされていません |
Power BI Mobile アプリは、Power BI サービスとアクティブに通信します。 テレメトリは、モバイル アプリの使用状況の統計情報と同様のデータを収集するために使用され、使用状況とアクティビティの監視に使用されるサービスに送信されます。顧客データはテレメトリと共に送信されません。
Power BI アプリケーションは、アプリの使用を容易にするデータをデバイスに格納します。
- Microsoft Entra ID と更新トークンは、業界標準のセキュリティ対策を使用して、デバイス上のセキュリティで保護されたメカニズムに格納されます。
- データと設定 (ユーザー構成のキーと値のペア) は、デバイス上のストレージにキャッシュされ、OS によって暗号化できます。 iOS では、これはユーザーがパスコードを設定したときに自動的に行われます。 Android では、これは設定で構成できます。 Windows では、BitLocker を使用して実現されます。
- Android および iOS アプリの場合、データと設定 (ユーザー構成のキーと値のペア) は、デバイス上のサンドボックス内のストレージと、アプリのみがアクセスできる内部ストレージにキャッシュされます。
- 位置情報は、ユーザーによって明示的に有効/無効化されます。 有効にすると、位置情報データはデバイスに保存されず、Microsoft とも共有されません。
- 通知は、ユーザーによって明示的に有効/無効化されます。 有効にした場合、Android と iOS では、通知の地理的なデータ所在地の要件はサポートされません。
データ暗号化は、モバイル デバイスとアプリケーション管理を提供するソフトウェア サービスである Microsoft Intune を介してファイル レベルの暗号化を適用することで強化できます。 Power BI Mobile が利用可能な 3 つのプラットフォームはすべて、Intune をサポートしています。 Intune を有効にして構成すると、モバイル デバイス上のデータが暗号化され、Power BI アプリケーション自体を SD カードにインストールすることはできません。 Microsoft Intune の詳細を確認します。
Windows アプリでは、 Windows 情報保護 (WIP) もサポートされています。
SSO を実装するために、トークン ベースの認証に関連するいくつかのセキュリティで保護されたストレージ値は、他の Microsoft ファースト パーティ アプリ (Microsoft Authenticator など) で使用でき、 Microsoft Authentication Library (MSAL) によって管理されます。
Power BI Mobile でキャッシュされたデータは、アプリが削除されたとき、ユーザーが Power BI Mobile からサインアウトしたとき、またはユーザーがサインインに失敗したとき (トークンの有効期限イベントやパスワードの変更後など) に削除されます。 データ キャッシュには、Power BI Mobile アプリから以前にアクセスしたダッシュボードとレポートが含まれています。
Power BI Mobile は、デバイス上の他のアプリケーション フォルダーやファイルにアクセスしません。
iOS および Android 用の Power BI アプリでは、Face ID、Touch ID、iOS のパスコード、Android 用の生体認証データ (指紋 ID) などの追加の ID を構成することで、データを保護できます。 追加の識別の詳細については、こちらを参照してください。
Power BI サービスへの認証
Power BI サービスに対するユーザー認証は、ユーザーのブラウザーと Power BI サービスまたは Power BI によって使用される Azure サービスとの間の一連の要求、応答、およびリダイレクトで構成されます。 このシーケンスでは、 Microsoft Entra 認証コード付与フローに従う Power BI でのユーザー認証のプロセスについて説明します。 組織のユーザー認証モデル (サインイン モデル) のオプションの詳細については、「 Microsoft 365 のサインイン モデルの選択」を参照してください。
認証シーケンス
Power BI サービスのユーザー認証シーケンスは、次の手順の説明に従って行われます。次の図に示します。
ユーザーは、アドレス バーに Power BI アドレスを入力するか、Power BI マーケティング ページ (https://powerbi.microsoft.com) から [サインイン] を選択して、ブラウザーから Power BI サービスへの接続を開始します。 接続は TLS と HTTPS を使用して確立され、以降のブラウザーと Power BI サービス間の通信はすべて HTTPS を使用します。
Azure Traffic Manager は、ユーザーの DNS レコードをチェックして、Power BI がデプロイされている最も適切な (通常は最も近い) データセンターを特定し、ユーザーの送信先となる WFE クラスターの IP アドレスで DNS に応答します。
WFE は、サインイン フローを開始するために必要な MSAL.js ライブラリ参照を含む HTML ページをブラウザー クライアントに返します。
ブラウザー クライアントは、WFE から受信した HTML ページを読み込み、ユーザーを Microsoft Online Services サインイン ページにリダイレクトします。
ユーザーが認証されると、サインイン ページによって、認証コードを使用してユーザーが Power BI WFE ページにリダイレクトされます。
ブラウザー クライアントは HTML ページを読み込み、認証コードを使用して Microsoft Entra ID からトークン (アクセス、ID、更新) を要求します。
ユーザーのテナント ID は、テナントとその Power BI バックエンド クラスターの場所の一覧を保持する Power BI グローバル サービスのクエリを実行するために、ブラウザー クライアントによって使用されます。 Power BI グローバル サービスは、ユーザーのテナントを含む Power BI バックエンド サービス クラスターを決定し、Power BI バックエンド クラスターの URL をクライアントに返します。
クライアントは、HTTP 要求の Authorization ヘッダーのアクセス トークンを使用して、Power BI バックエンド クラスター URL API と通信できるようになりました。 Microsoft Entra アクセス トークンには 、Microsoft Entra ポリシーに従って有効期限が設定され、現在のセッションを維持するために、ユーザーのブラウザーで Power BI クライアントは、有効期限が切れる前にアクセス トークンを更新するように定期的に要求します。
予期しないエラーが原因でクライアント側の認証が失敗するまれなケースでは、WFE でサーバー側認証の使用にフォールバックしようとします。 サーバー側認証フローの詳細については、 このドキュメントの最後にある質問と回答のセクション を参照してください。
データの保存場所
ドキュメントで特に明記されていない限り、Power BI は 、Microsoft Entra テナント が初めて Power BI サービスにサインアップしたときに割り当てられる Azure 地域に顧客データを格納します。 Microsoft Entra テナントには、組織とそのセキュリティに関連するユーザーとアプリケーションの ID、グループ、およびその他の関連情報が格納されます。
テナント データ ストレージに対する Azure geography の割り当ては、Microsoft Entra テナントセットアップの一部として選択された国またはリージョンを、Power BI デプロイが存在する最も適切な Azure 地域にマッピングすることによって行われます。 この決定が行われると、組織が複数地域デプロイを利用する場合を除き、すべての Power BI 顧客データがこの選択した Azure 地域 ( ホーム geo とも呼ばれます) に格納されます。
複数の地域 (複数地域)
一部の組織にはグローバル プレゼンスがあり、複数の Azure 地域で Power BI サービスが必要になる場合があります。 たとえば、ある企業が米国に本社を置いているだけでなく、オーストラリアなどの他の地理的地域でもビジネスを行う場合があります。 このような場合、ビジネスでは、ローカルの規制に準拠するために、特定の Power BI データをリモート リージョンに保存したままにする必要がある場合があります。 Power BI サービスのこの機能は、 複数地域と呼ばれます。
複数地域ワークスペースに割り当てられたクエリ実行レイヤー、クエリ キャッシュ、およびアーティファクト データはホストされ、リモート容量の Azure geography に残ります。 ただし、レポート構造などの一部の成果物メタデータは、テナントのホーム geo に保存されたままになる場合があります。 さらに、複数地域の Premium 容量でホストされているワークスペースの場合でも、一部のデータ転送と処理がテナントのホーム geo で引き続き発生する可能性があります。
複数の Azure 地域にまたがるデプロイの作成と管理の詳細については、「 Fabric の複数地域のサポートを構成する」を参照してください。
リージョンとデータセンター
Power BI サービスは、 Microsoft セキュリティ センターの説明に従って、特定の Azure 地域で利用できます。 データの格納場所と使用方法の詳細については、 Microsoft セキュリティ センターを参照してください。 保存時の顧客データの場所についてのコミットメントは、Microsoft Online Services 規約のデータ処理規約で指定されています。
Microsoft では、ソブリン エンティティ向けのデータセンターも提供しています。 国内/地域クラウドの Power BI サービスの可用性の詳細については、 Power BI の国内/地域クラウドに関する説明を参照してください。
データの処理
このセクションでは、顧客データの格納、処理、転送に関する Power BI データ処理のプラクティスについて説明します。
静止データ
Power BI では、次の 2 種類のプライマリ データ ストレージ リソースが使用されます。
- Azure Storage
- Azure SQL データベース
ほとんどのシナリオでは、Azure Storage を使用して Power BI 成果物のデータを保持し、Azure SQL データベースを使用して成果物メタデータを保持します。
Power BI によって保持されるすべてのデータは、Microsoft マネージド キーを使用して既定で暗号化されます。 Azure SQL データベースに格納されている顧客データは、 Azure SQL の Transparent Data Encryption (TDE) テクノロジを使用して完全に暗号化されます。 Azure Blob Storage に格納されている顧客データは、 Azure Storage 暗号化を使用して暗号化されます。
必要に応じて、組織は Power BI Premium を使用して独自のキーを使用して、セマンティック モデルにインポートされた保存データを暗号化できます。 このアプローチは、多くの場合、Bring Your Own Key (BYOK) と呼ばれます。 BYOK を使用すると、サービス オペレーターのエラーが発生した場合でも、顧客データが公開されないようにすることができます。透過的なサービス側暗号化を使用して簡単に実現することはできません。 詳細については、「Power BI で独自の暗号化キーを使用する」を参照してください。
Power BI セマンティック モデルでは、データ ソース データがサービスに保持されるかどうかを決定するさまざまなデータ ソース接続モードを使用できます。
| セマンティック モデル モード (種類) | Power BI で保持されるデータ |
|---|---|
| 輸入 | イエス |
| ダイレクトクエリ | いいえ |
| ライブコネクト | いいえ |
| 複合材料 | インポート データ ソースが含まれている場合 |
| ストリーミング | 永続化するように構成されている場合 |
使用されるセマンティック モデル モードに関係なく、Power BI は、クエリとレポートの読み込みパフォーマンスを最適化するために、取得したデータを一時的にキャッシュする場合があります。
処理中のデータ
データは、対話型シナリオの一部として 1 人以上のユーザーによってアクティブに使用されている場合、または更新などのバックグラウンド プロセスがこのデータに触れたときに処理中です。 Power BI は、アクティブに処理されたデータを 1 つ以上のサービス ワークロードのメモリ領域に読み込みます。 ワークロードに必要な機能を容易にするために、メモリ内の処理されたデータは暗号化されません。
転送中のデータ
Power BI では、すべての受信 HTTP トラフィックを TLS 1.2 以降を使用して暗号化する必要があります。 TLS 1.1 以下でサービスを使用しようとする要求はすべて拒否されます。
データ ソースへの認証
データ ソースに接続する場合、ユーザーはデータのコピーを Power BI にインポートするか、データ ソースに直接接続するかを選択できます。
インポートの場合、ユーザーはユーザーのサインインに基づいて接続を確立し、資格情報を使用してデータにアクセスします。 セマンティック モデルが Power BI サービスに発行されると、Power BI は常にこのユーザーの資格情報を使用してデータをインポートします。 データがインポートされると、レポートとダッシュボードでデータを表示しても、基になるデータ ソースにアクセスできなくなります。 Power BI では、選択したデータ ソースに対するシングル サインオン認証がサポートされています。 シングル サインオンを使用するように接続が構成されている場合は、セマンティック モデル所有者の資格情報を使用してデータ ソースに接続します。
データ ソースが事前構成済みの資格情報を使用して直接接続されている場合は、ユーザーがデータを表示するときに、事前構成済みの資格情報を使用してデータ ソースに接続します。 データ ソースがシングル サインオンを使用して直接接続されている場合、ユーザーがデータを表示するときに、現在のユーザーの資格情報を使用してデータ ソースに接続します。 シングル サインオンで使用する場合は、行レベル セキュリティ (RLS) またはオブジェクト レベル セキュリティ (OLS) をデータ ソースに実装できます。 これにより、ユーザーはアクセス権限を持つデータのみを表示できます。 クラウド内のデータ ソースへの接続の場合、Microsoft Entra 認証はシングル サインオンに使用されます。オンプレミス データ ソースの場合は、Kerberos、Security Assertion Markup Language (SAML)、および Microsoft Entra ID がサポートされています。
データ ソースが Azure Analysis Services またはオンプレミスの Analysis Services であり、RLS や OLS が構成されている場合、Power BI サービスはそのレベルのセキュリティを適用し、基になるデータにアクセスするための十分な資格情報を持っていないユーザー (ダッシュボード、レポート、またはその他のデータ成果物で使用されるクエリなど) には、十分な権限を持たないデータが表示されません。
Premium 機能
データフローアーキテクチャ
データフローを使用すると、多形データ ソースからデータを抽出し、データに対して変換ロジックを実行し、さまざまなレポート表示テクノロジで使用できるようにターゲット モデルに配置するバックエンド データ処理操作を構成できます。 ワークスペースにメンバー、共同作成者、管理者のいずれかのロールを持つユーザーは、データフローを作成する可能性があります。 ビューアー ロールのユーザーは、データフローによって処理されたデータを表示できますが、その構成に変更を加えない場合があります。 データフローが作成されると、ワークスペースのメンバー、共同作成者、または管理者が更新をスケジュールしたり、データフローの所有権を取得してデータフローを表示および編集したりできます。
構成された各データ ソースは、そのデータ ソースにアクセスするためのクライアント テクノロジにバインドされます。 アクセスに必要な資格情報の構造は、データ ソースの必要な実装の詳細と一致するように形成されます。 変換ロジックは、データの処理中に Power Query サービスによって適用されます。 Premium データフローの場合、Power Query サービスはバックエンド ノードで実行されます。 データは、クラウド ソースから直接、またはオンプレミスにインストールされているゲートウェイを介してプルされる場合があります。 クラウド ソースからサービスまたはゲートウェイに直接プルされた場合、トランスポートはクライアント テクノロジに固有の保護手法を使用します (該当する場合)。 ゲートウェイからクラウド サービスにデータが転送されると、暗号化されます。 上記の 転送中のデータ に関するセクションを参照してください。
お客様が指定したデータ ソースにアクセスするための資格情報が必要な場合、データフローの所有者/作成者は、作成時にそれらを提供します。 これらは、標準の製品全体の資格情報ストレージを使用して格納されます。 上記の データ ソースへの認証を 参照してください。 データの永続化とアクセスを最適化するためにユーザーが構成できるさまざまな方法があります。 既定では、データは Power BI 所有の保護されたストレージ アカウントに配置されます。 保存中にデータを保護するために、Blob Storage コンテナーでストレージ暗号化が有効になっています。 以下 の「保存データ」 を参照してください。 ただし、ユーザーは、自分の Azure サブスクリプションに関連付けられている独自のストレージ アカウントを構成できます。 その場合、Power BI サービス プリンシパルにそのストレージ アカウントへのアクセス権が付与され、更新中にデータが書き込まれる可能性があります。 この場合、ストレージ リソース所有者は、構成された Azure Data Lake Storage アカウントで暗号化を構成する必要があります。 データは常に暗号化を使用して Blob Storage に送信されます。
ストレージ アカウントへのアクセス時のパフォーマンスは、一部のデータにとって最適ではない可能性があるため、ユーザーは Power BI でホストされるコンピューティング エンジンを使用してパフォーマンスを向上させるオプションもあります。 この場合、データは、バックエンド Power BI システムによるアクセスを通じて DirectQuery で使用できる SQL データベースに冗長に格納されます。 データは常にファイル システムで暗号化されます。 ユーザーが SQL データベースに格納されているデータを暗号化するためのキーを提供した場合、そのキーは 2 倍の暗号化に使用されます。
DirectQuery を使用してクエリを実行する場合、暗号化されたトランスポート プロトコル HTTPS を使用して API にアクセスします。 DirectQuery のセカンダリまたは間接の使用はすべて、前に説明したのと同じアクセス制御によって制御されます。 データフローは常にワークスペースにバインドされるため、データへのアクセスは、そのワークスペース内のユーザーのロールによって常に制限されます。 ユーザーは、任意の方法でデータに対してクエリを実行できるようにするには、少なくとも読み取りアクセス権を持っている必要があります。
Power BI Desktop を使用してデータフロー内のデータにアクセスする場合は、まず Microsoft Entra ID を使用してユーザーを認証して、ユーザーがデータを表示するための十分な権限を持っているかどうかを判断する必要があります。 その場合、SaS キーが取得され、暗号化されたトランスポート プロトコル HTTPS を使用してストレージに直接アクセスするために使用されます。
パイプライン全体でデータを処理すると、Office 365 監査イベントが生成されます。 これらのイベントの一部は、セキュリティとプライバシーに関連する操作をキャプチャします。
改ページ対応レポート
ページ分割されたレポートは、印刷または共有することを想定してデザインされています。 ページ分割と呼ばれるのは、ページに適切に収まるように書式設定されているためです。 テーブルが複数のページにまたがる場合でも、テーブルのすべてのデータが表示されます。 レポートのページ レイアウトを正確に制御できます。
ページ分割されたレポートでは、Microsoft Visual Basic .NET で記述された豊富で強力な式がサポートされます。 式は、Power BI レポート ビルダーのページ分割されたレポート全体で、データの取得、計算、表示、グループ化、並べ替え、フィルター処理、パラメーター化、書式設定を行うために広く使用されています。
式は、.NET Framework のさまざまな機能にアクセスできるレポートの作成者によって作成されます。 ページ分割されたレポートの処理と実行は、サンドボックス内で実行されます。
ページ分割されたレポート定義 (.rdl) は Power BI に格納され、ページ分割されたレポートを発行またはレンダリングするには、「 Power BI サービスへの認証」の説明と同じ方法でユーザーが認証および承認する必要があります。
認証中に取得された Microsoft Entra トークンは、ブラウザーから Power BI Premium クラスターに直接通信するために使用されます。
Power BI Premium では、Power BI サービス ランタイムは、レポートのレンダリングごとに適切に分離された実行環境を提供します。 これには、表示されるレポートが同じ容量に割り当てられたワークスペースに属している場合が含まれます。
ページ分割されたレポートは、レポートのレンダリングの一部として、さまざまなデータ ソースにアクセスできます。 サンドボックスは、どのデータ ソースとも直接通信するのではなく、信頼されたプロセスと通信してデータを要求し、信頼されたプロセスによって必要な資格情報が接続に追加されます。 このようにして、サンドボックスは資格情報やシークレットにアクセスすることはありません。
Bing Maps や Azure Functions の呼び出しなどの機能をサポートするために、サンドボックスはインターネットにアクセスできます。
Power BI 埋め込み分析
独立系ソフトウェア ベンダー (ISV) とソリューション プロバイダーには、Web アプリケーションとポータルに Power BI 成果物を埋め込む主な 2 つのモードがあります。 組織に埋め込み 、 顧客のために埋め込みます。 成果物は、アプリケーションまたはポータルの IFrame に埋め込まれます。 IFrame は外部 Web アプリケーションまたはポータルからデータの読み取りまたは書き込みを行うことができません。IFrame との通信は、POST メッセージを使用して Power BI クライアント SDK を使用して行われます。
組織の埋め込みシナリオでは、Microsoft Entra ユーザーは、企業とIT部門によってカスタマイズされたポータルを通じて、独自の Power BI コンテンツにアクセスします。 RLS や OLS など、このホワイト ペーパーで説明されているすべての Power BI ポリシーと機能は、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 では、生成時に ISV によって指定されたとおりに、すべてのポリシー (アクセスや RLS など) が正確に適用されます。
埋め込みと自動化を有効にし、前述の埋め込みトークンを生成するために、Power BI は豊富な REST API のセットを公開します。 これらの Power BI REST API では、ユーザー委任 と サービス プリンシパル の Microsoft Entra による認証と承認の両方の方法がサポートされています。
Power BI 埋め込み分析とその REST API は、 サービス タグ や プライベート リンクなど、この記事で説明されているすべての Power BI ネットワーク分離機能をサポートします。
AI の機能
現在、Power BI では、現在、AI ビジュアルと AI エンリッチメントという 2 つの広範なカテゴリの AI 機能がサポートされています。 ビジュアル レベルの AI 機能には、主要なインフルエンサー、分解ツリー、スマート ストーリー、異常検出、R ビジュアル、Python ビジュアル、クラスタリング、予測、Q&A、Quick Insights などの機能が含まれます。AI エンリッチメント機能には、AutoML、Azure Machine Learning、CognitiveServices、R/Python 変換などの機能が含まれます。
上記の機能のほとんどは、現在、共有ワークスペースと Premium ワークスペースの両方でサポートされています。 ただし、AutoML と CognitiveService は、IP の制限により Premium ワークスペースでのみサポートされます。 現在、Power BI での AutoML 統合により、ユーザーはカスタム機械学習 (ML) モデル (予測、分類、回帰など) を構築してトレーニングし、それを適用して、Premium ワークスペースで定義されたデータフローにデータを読み込みながら予測を取得できます。 さらに、Power BI ユーザーは、TextAnalytics や ImageTagging などの複数の CognitiveServices API を適用して、Premium ワークスペースで定義されているデータフロー/セマンティック モデルにデータを読み込む前にデータを変換できます。
Premium AI エンリッチメント機能は、Power BI セマンティック モデルまたはデータフローによって使用されるデータ統合パイプラインで Power BI ユーザーが使用できるステートレス AI 関数/変換のコレクションとして最適に表示できます。 これらの関数は、Power BI サービスと Power BI Desktop の現在のデータフロー/セマンティック モデル作成環境からもアクセスできることに注意してください。 これらの AI 関数/変換は、常に Premium ワークスペース/容量で実行されます。 これらの関数は、AI 関数を使用している Power BI ユーザーに Microsoft Entra トークンを必要とするデータ ソースとして Power BI に表示されます。 これらの AI データ ソースは、独自のデータを表示せず、これらの関数/変換のみを提供するため、特別です。 実行中、これらの機能は、顧客のデータを送信するために他のサービスに送信呼び出しを行いません。 Premium シナリオを個別に見て、通信パターンとそれらに関連するセキュリティ関連の詳細を理解しましょう。
AutoML モデルのトレーニングと適用のために、Power BI は Azure AutoML SDK を使用し、顧客の Power BI 容量ですべてのトレーニングを実行します。 トレーニングイテレーション中に、Power BI は実験 Azure Machine Learning Service を呼び出して、現在のイテレーションに適したモデルとハイパーパラメーターを選択します。 この送信呼び出しでは、前のイテレーションからの関連する実験メタデータ (精度、ml アルゴリズム、アルゴリズム パラメーターなど) のみが送信されます。 AutoML トレーニングでは、ONNX モデルとトレーニング レポート データが生成され、データフローに保存されます。 その後、Power BI ユーザーはトレーニング済みの ML モデルを変換として適用し、スケジュールされた方法で ML モデルを運用化できます。 TextAnalytics API と ImageTagging API の場合、Power BI は CognitiveServices サービス API を直接呼び出すのではなく、内部 SDK を使用して Power BI Premium 容量で API を実行します。 現在、これらの API は、Power BI データフローとセマンティック モデルの両方でサポートされています。 Power BI Desktop でデータ モデルを作成している間、ユーザーは Premium Power BI ワークスペースにアクセスできる場合にのみこの機能にアクセスできます。 そのため、お客様は Microsoft Entra 資格情報の入力を求められます。
ネットワークの分離
このセクションでは、Power BI の高度なセキュリティ機能について説明します。 一部の機能には、特定のライセンス要件があります。 詳細については、以下のセクションを参照してください。
サービス タグ
サービス タグは、特定の Azure サービスからの IP アドレス プレフィックスのグループを表します。 ネットワーク セキュリティ規則に対する頻繁な更新の複雑さを最小限に抑えるのに役立ちます。 お客様は、サービス タグを使用して、 ネットワーク セキュリティ グループ または Azure Firewall でネットワーク アクセス制御を定義できます。 お客様は、セキュリティ規則を作成するときに、特定の IP アドレスの代わりにサービス タグを使用できます。 ルールの適切なソースまたは宛先 (API の場合) フィールドにサービス タグ名 ( PowerBI など) を指定することで、顧客は対応するサービスのトラフィックを許可または拒否できます。 Microsoft は、サービス タグに含まれるアドレス プレフィックスを管理し、アドレスの変更に合じてサービス タグを自動的に更新します。
Private Link の統合
Azure ネットワークには、Power BI が Azure Networking プライベート エンドポイント経由でセキュリティで保護されたアクセスを提供できるようにする Azure Private Link 機能が用意されています。 Azure Private Link とプライベート エンドポイントでは、データ トラフィックは Microsoft のバックボーン ネットワーク インフラストラクチャを使用してプライベートに送信されるため、データはインターネットを経由しません。
Private Link を使用すると、Power BI サービスのリソースに移動するときに、Power BI ユーザーが Microsoft プライベート ネットワーク バックボーンを使用できるようになります。
Power BI で Private Link を使用すると、次の利点があります。
- Private Link を使用すると、Azure クラウド ベースのリソースのプライベート エンドポイントに Azure バックボーン経由でトラフィックが確実に流れるようになります。
- オンプレミス アクセスなど、Azure ベース以外のインフラストラクチャからのネットワーク トラフィックの分離には、ExpressRoute または VPN を構成する必要があります。
詳細については、 Fabric への安全なアクセスに関するプライベート リンク を参照してください。
VNet 接続
Private Link 統合機能は Power BI への安全な受信接続を提供しますが、VNet 接続機能により、Power BI から VNet 内のデータ ソースへの安全な送信接続が可能になります。
VNet ゲートウェイ (Microsoft が管理) を使用すると、VNet に関連付けられているデータ ソースに接続するためのオンプレミス データ ゲートウェイのインストールと監視のオーバーヘッドが排除されます。 ただし、オンプレミスのデータ ゲートウェイと同様に、セキュリティとデータ ソースを管理する使い慣れたプロセスに従っています。
VNet ゲートウェイを使用して VNet 内のデータ ソースに接続されている Power BI レポートを操作する場合の概要を次に示します。
Power BI クラウド サービス (またはその他のサポートされているクラウド サービスのいずれか) がクエリを開始し、クエリ、データ ソースの詳細、資格情報を Power Platform VNet (PP VNet) サービスに送信します。
その後、PP VNet サービスは、VNet ゲートウェイを実行しているコンテナーをサブネットに安全に挿入します。 このコンテナーは、このサブネット内からアクセス可能なデータ サービスに接続できるようになりました。
その後、PP VNet サービスは、クエリ、データ ソースの詳細、資格情報を VNet ゲートウェイに送信します。
VNet ゲートウェイはクエリを取得し、それらの資格情報を使用してデータ ソースに接続します。
その後、クエリが実行のためにデータ ソースに送信されます。
実行後、結果は VNet ゲートウェイに送信され、PP VNet サービスはコンテナーから Power BI クラウド サービスにデータを安全にプッシュします。
サービス プリンシパル
Power BI では、サービス プリンシパルの使用がサポートされています。 Power BI の暗号化またはアクセスに使用されるサービス プリンシパル資格情報を Key Vault に格納し、適切なアクセス ポリシーをコンテナーに割り当て、アクセス許可を定期的に確認します。
詳細については、 サービス プリンシパルを使用した Premium ワークスペースとセマンティック モデルのタスクの自動化に関する ページを参照してください。
Power BI 用の Microsoft Purview
Microsoft Purview 情報保護
Power BI は、Microsoft Purview Information Protection と深く統合されています。 Microsoft Purview Information Protection を使用すると、組織は、Azure、Power BI、Office 全体で分類、ラベル付け、監査、コンプライアンスのための単一の統合ソリューションを使用できます。
Power BI で情報保護が有効になっている場合:
- 機密データは、Power BI サービスと Power BI Desktop の両方で、Office と Azure で使用されるのと同じ秘密度ラベルを使用して分類およびラベル付けできます。
- Power BI コンテンツを Excel、PowerPoint、PDF、Word、 または .pbix ファイルにエクスポートするときにガバナンス ポリシーを適用して、Power BI を離れた場合でもデータが確実に保護されるようにすることができます。
- Excel、Word、PowerPoint アプリケーションで行われるのと同じように、Power BI Desktop で .pbix ファイルを分類して保護するのは簡単です。 ファイルは、感度のレベルに応じて簡単にタグ付けできます。 さらに、ビジネス機密データが含まれている場合は暗号化でき、承認されたユーザーのみがこれらのファイルを編集できます。
- Excel ブックでは、Power BI に接続するときに秘密度ラベルが自動的に継承されるため、Power BI セマンティック モデルを Excel で分析するときにエンド ツー エンドの分類を維持し、保護を適用することができます。
- Power BI レポートとダッシュボードに適用される秘密度ラベルは、Power BI iOS および Android モバイル アプリに表示されます。
- 秘密度ラベルは、Power BI レポートが Teams、SharePoint、またはセキュリティで保護された Web サイトに埋め込まれている場合に保持されます。 これにより、組織は 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 のデータ損失防止ポリシー」を参照してください。
マイクロソフト ディフェンダー for Cloud Apps for Power BI
Microsoft Defender for Cloud Apps は、世界をリードするクラウド アクセス セキュリティ ブローカーの 1 つであり、クラウド アクセス セキュリティ ブローカー (CASB) 市場向けの Gartner のマジック クアドラントのリーダーとして名付けられています。 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 コントロールの使用」を参照してください。
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 の制約付き委任を使用して、ユーザーは偽装され、それぞれのデータ ソースに接続されます。 SAML は、SAP HANA データ ソースのゲートウェイでもサポートされています。 詳細については、 ゲートウェイのシングル サインオンの概要を参照してください。
データ ソースが Azure Analysis Services であるか、オンプレミスの Analysis Services で RLS や OLS が構成されている場合、Power BI サービスはそのレベルのセキュリティを適用し、基になるデータにアクセスするための十分な資格情報を持っていないユーザー (ダッシュボード、レポート、またはその他のデータ成果物で使用されるクエリなど) には、ユーザーに十分な権限がないデータが表示されません。
Power BI での RLS を使用して、特定のユーザーのデータ アクセスを制限できます。 フィルターは行レベルでデータ アクセスを制限し、ロール内でフィルターを定義できます。
OLS を使用して、機密性の高いテーブルまたは列をセキュリティで保護できます。 ただし、RLS とは異なり、OLS ではオブジェクト名とメタデータもセキュリティで保護されます。 これは、悪意のあるユーザーがそのようなオブジェクトの存在さえ検出するのを防ぐのに役立ちます。 Excel や Power BI などのレポート ツールを使用すると、セキュリティで保護されたテーブルと列がフィールド リストに隠されます。さらに、アクセス許可のないユーザーは、DAX やその他の方法を使用してセキュリティで保護されたメタデータ オブジェクトにアクセスできません。 適切なアクセス許可を持たないユーザーの観点からは、セキュリティで保護されたテーブルと列は存在しません。
OLS と RLS を組み合わせることで、レポートとセマンティック モデルに対するエンタープライズ レベルのセキュリティが強化され、必要なアクセス許可を持つユーザーのみが機密データを表示および操作できます。
データはどのように Power BI に転送されますか?
- Power BI によって要求および送信されるすべてのデータは、データ ソースから Power BI サービスに接続するために HTTPS を使用して転送中に暗号化されます (お客様が選択したデータ ソースが HTTPS をサポートしていない場合を除く)。 データ プロバイダーとのセキュリティで保護された接続が確立され、その接続が確立された後にのみ、データがネットワークを通過します。
Power BI はレポート、ダッシュボード、またはモデル データをどのようにキャッシュし、セキュリティで保護されますか?
- データ ソースにアクセスすると、Power BI サービスはデータ ソースへの認証で説明されているプロセスに従います。
クライアントは Web ページ データをローカルにキャッシュしますか?
- ブラウザー クライアントが Power BI にアクセスすると、Power BI Web サーバーによって Cache-Control ディレクティブが ストアなしに設定されます。 no-store ディレクティブは、ユーザーが表示している Web ページをキャッシュしないようにし、Web ページをクライアントのキャッシュ フォルダーに格納しないようにブラウザーに指示します。
ロールベースのセキュリティ、レポートまたはダッシュボードの共有、データ接続はどうなりますか? データ アクセス、ダッシュボードの表示、レポートアクセス、または更新の観点から、この機能はどのように機能しますか?
RLS 対応ではないデータ ソースの場合、ダッシュボード、レポート、またはデータ モデルが Power BI を介して他のユーザーと共有されている場合、そのデータは、共有されているユーザーが表示および操作できるようになります。 Power BI は、 データの元のソースに対してユーザーを再認証しません。データが Power BI にアップロードされると、ソース データに対して認証されたユーザーは、データを表示できる他のユーザーとグループを管理する責任を負います。
Analysis Services データ ソースなどの RLS 対応 データ ソースへのデータ接続が行われると、ダッシュボード データのみが Power BI にキャッシュされます。 RLS 対応データ ソースのデータを使用する Power BI でレポートまたはセマンティック モデルが表示またはアクセスされるたびに、Power BI サービスはデータ ソースにアクセスしてユーザーの資格情報に基づいてデータを取得し、十分なアクセス許可が存在する場合は、そのユーザーのレポートまたはデータ モデルにデータが読み込まれます。 認証に失敗すると、ユーザーにエラーが表示されます。
詳細については、「 データ ソースへの認証」を参照してください。
ユーザーは常に同じデータ ソースに接続します。その中には、ドメインの資格情報とは異なる資格情報が必要なものもあります。 データ接続を行うたびにこれらの資格情報を入力する必要を回避するにはどうすればよいですか。
- Power BI には Power BI Personal Gateway が用意されています。これは、ユーザーが複数の異なるデータ ソースの資格情報を作成し、その後それらの各データ ソースにアクセスするときにそれらの資格情報を自動的に使用できるようにする機能です。 詳細については、「 Power BI で個人用ゲートウェイを使用する」を参照してください。
オンプレミス データ ゲートウェイとパーソナル ゲートウェイで使用されるポートはどれですか? 接続のために許可する必要があるドメイン名はありますか?
- この質問に対する詳細な回答については、「 オンプレミス データ ゲートウェイの通信設定を調整する」を参照してください。
オンプレミス データ ゲートウェイを使用する場合、回復キーはどのように使用され、どこに格納されますか? セキュリティで保護された資格情報の管理について
ゲートウェイのインストールと構成中に、管理者はゲートウェイ 回復キーを入力します。 その 回復キー は、強力な AES 対称キーを生成するために使用されます。 RSA 非対称キーも同時に作成されます。
生成されたキー (RSA と AES) は、ローカル コンピューター上のファイルに格納されます。 そのファイルも暗号化されます。 ファイルの内容は、その特定の Windows マシンと、その特定のゲートウェイ サービス アカウントによってのみ復号化できます。
ユーザーが Power BI サービス UI でデータ ソースの資格情報を入力すると、資格情報はブラウザーの公開キーで暗号化されます。 ゲートウェイは RSA 秘密キーを使用して資格情報を復号化し、データが Power BI サービスに格納される前に AES 対称キーを使用して資格情報を再暗号化します。 このプロセスでは、Power BI サービスは暗号化されていないデータにアクセスすることはありません。
オンプレミス データ ゲートウェイで使用される通信プロトコルと、セキュリティ保護方法
ゲートウェイでは、次の 2 つの通信プロトコルがサポートされています。
AMQP 1.0 – TCP + TLS: このプロトコルでは、ポート 443、5671-5672、および 9350-9354 を送信通信用に開く必要があります。 このプロトコルは、通信オーバーヘッドが少ないため、推奨されます。
HTTPS – HTTPS + TLS 経由の WebSocket: このプロトコルはポート 443 のみを使用します。 WebSocket は、1 つの HTTP CONNECT メッセージによって開始されます。 チャネルが確立されると、通信は基本的に TCP+TLS になります。 オンプレミス ゲートウェイに関する記事で説明されている設定を変更することで、ゲートウェイにこのプロトコルの使用 を強制できます。
Power BI での Azure CDN の役割は何ですか?
前述のように、Power BI は Azure CDN を使用して、地理的ロケールに基づいて必要な静的コンテンツとファイルをユーザーに効率的に配布します。 さらに詳しく説明するために、Power BI サービスでは複数の CDN を使用して、必要な静的コンテンツとファイルをパブリック インターネット経由でユーザーに効率的に配布します。 これらの静的ファイルには、製品のダウンロード (Power BI Desktop、オンプレミス データ ゲートウェイ、さまざまな ISV からの 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 Maps と ESRI ビジュアルは、それらのサービスを使用するビジュアルのために Power BI サービスからデータを送信します。
テンプレート アプリの場合、Microsoft はギャラリーに項目を発行する前に、テンプレート アプリのセキュリティまたはプライバシーの評価を実行しますか?
- いいえ。 アプリの発行元はコンテンツを担当しますが、テンプレート アプリの発行元を信頼するかどうかを確認して判断するのはお客様の責任です。
顧客ネットワークの外部で情報を送信できるテンプレート アプリはありますか?
- はい。 発行元のプライバシー ポリシーを確認し、テンプレート アプリをテナントにインストールするかどうかを決定するのは、お客様の責任です。 発行元は、アプリの動作と機能について顧客に通知する責任を負います。
データ主権はどうですか? 特定の地域にあるデータセンターにテナントをプロビジョニングして、データが国や地域の国境を越えないようにすることはできますか?
特定の地域の一部のお客様は、国内/地域のクラウドにテナントを作成するオプションがあります。このクラウドでは、データの保存と処理が他のすべてのデータセンターとは別に保持されます。 個別のデータ トラスティが Microsoft に代わって国内または地域のクラウド Power BI サービスを運用するため、国内/地域クラウドのセキュリティの種類は少し異なります。
または、特定のリージョンにテナントを設定することもできます。 ただし、このようなテナントには、Microsoft とは別のデータ トラスティはありません。 国内/地域クラウドの価格は、一般公開されている商用 Power BI サービスとは異なります。 国内/地域クラウドの Power BI サービスの可用性の詳細については、 Power BI の国内/地域クラウドに関する説明を参照してください。
Power BI Premium サブスクリプションをお持ちのお客様に対して、Microsoft はどのように接続を処理しますか? これらの接続は、Premium 以外の Power BI サービス用に確立された接続とは異なりますか?
- Power BI Premium サブスクリプションをお持ちのお客様のために確立された接続は、 Microsoft Entra のビジネス間 (B2B) 承認プロセスを実装し、Microsoft Entra ID を使用してアクセス制御と承認を有効にします。 Power BI は、他の Microsoft Entra ユーザーと同様に、Power BI Premium サブスクライバーから Power BI Premium リソースへの接続を処理します。
WFE でのサーバー側認証のしくみ
- ユーザー認証シーケンスのサービス側認証は、次の手順で説明されているように行われます。これは、その後の画像に示されています。
ユーザーは、アドレス バーに Power BI アドレスを入力するか、Power BI マーケティング ページ (https://powerbi.microsoft.com) から [サインイン] を選択して、ブラウザーから Power BI サービスへの接続を開始します。 接続は TLS 1.2 と HTTPS を使用して確立され、以降のブラウザーと Power BI サービス間の通信はすべて HTTPS を使用します。
Azure Traffic Manager は、ユーザーの DNS レコードをチェックして、Power BI がデプロイされている最も適切な (通常は最も近い) データセンターを特定し、ユーザーの送信先となる WFE クラスターの IP アドレスで DNS に応答します。
WFE は、ユーザーを Microsoft Online Services のサインイン ページにリダイレクトします。
ユーザーが認証されると、サインイン ページは、認証コードを使用して、以前に決定された最も近い Power BI サービス WFE クラスターにユーザーをリダイレクトします。
WFE クラスターは、Microsoft Entra ID で確認し、認証コードを使用して Microsoft Entra セキュリティ トークンを取得します。 Microsoft Entra ID がユーザーの正常な認証を返し、Microsoft Entra セキュリティ トークンを返すと、WFE クラスターは Power BI グローバル サービスを参照します。このサービスは、テナントとその Power BI バックエンド クラスターの場所の一覧を保持し、ユーザーのテナントを含む Power BI バックエンド サービス クラスターを決定します。 WFE クラスターは、操作に必要なセッション、アクセス、およびルーティング情報を含むアプリケーション ページをユーザーのブラウザーに返します。
これで、クライアントのブラウザーが顧客データを要求すると、Authorization ヘッダーに Microsoft Entra アクセス トークンを含む要求がバックエンド クラスター アドレスに送信されます。 Power BI バックエンド クラスターは、Microsoft Entra アクセス トークンを読み取り、署名を検証して、要求の ID が有効であることを確認します。 Microsoft Entra アクセス トークンには 、Microsoft Entra ポリシーに従って有効期限が設定され、現在のセッションを維持するために、ユーザーのブラウザーで Power BI クライアントは、有効期限が切れる前にアクセス トークンを更新するように定期的に要求します。
その他のリソース
Power BI の詳細については、次のリソースを参照してください。