Power BI のセキュリティに関するホワイト ペーパー

  • [アーティクル]

概要: 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、Ronald Chang、Ori Eduar、Anton Fritz、Idan Sheinberg、Ron Gilad、Sagiv Hadaya、Paul Inbar、Igor Uzhviev、Michael Roth、Jaime Tarquino、Gennady Pats、Orion Lee、Yury Berezansky、Maya Shenhav、Romit Chattopadhyay、Yariv Maimon、Bogdan Crivat

技術校閲者: Cristian Petculescu、Amir Netz、Sergei Gundorov

適用対象: Power BI SaaS、Power BI Desktop、Power BI Premium、Power BI Embedded Analytics、Power BI Mobile。

注意

ブラウザーで [印刷] を選択し、[PDF として保存] を選択すると、このホワイト ペーパーを保存または印刷できます。

はじめに

Power BI は、Microsoft のオンライン ソフトウェア サービス (SaaS、サービスとしてのソフトウェア) オファリングであり、セルフサービスのビジネス インテリジェンス ダッシュボード、レポート、セマンティック モデル、視覚化を、簡単かつ迅速に作成することができます。 Power BI では、多くの異なるデータ ソースに接続し、それらの接続からのデータを組み合わせて整形した後、他のユーザーと共有できるレポートやダッシュボードを作成することができます。

世界は急速に変化しています。組織はデジタル変革を加速しており、リモートワークの大幅な増加、オンライン サービスに対する顧客の需要の増加、運用やビジネス上の意思決定での高度なテクノロジーの使用の増加が見られます。 これらのすべてでクラウドが利用されています。

クラウドへの移行は徐々に広まり、いたるところで見られるようになりました。新しい攻撃対象領域の出現に伴い、クラウド内のデータはどの程度安全なのか、機密データの漏洩を防ぐために利用できるエンド ツー エンドの保護にはどのようなものがあるか といった問題に関心を持つ企業がますます増加しています。企業内で最も戦略的な情報を処理することが多い BI プラットフォームにとって、これらの問題は二重の意味で重要です。

BI セキュリティ モデルの数十年前の基盤 (オブジェクト レベルと行レベルのセキュリティ) は依然として重要ですが、クラウド時代に必要な種類のセキュリティを提供するには明らかに不十分です。 代わりに、組織は、ビジネス インテリジェンス データ用のクラウドネイティブで複数階層の多層防御セキュリティ ソリューションを探す必要があります。

Power BI は、業界をリードする完全で密閉性の高いデータ保護を提供するように構築されています。 この製品は、業界で利用可能な最高のセキュリティ分類を獲得しており、現在、多くの国家安全保障機関、金融機関、および医療提供機関が、最も機密性の高い情報をこの製品に委ねています。

すべては基礎から始まります。 2000 年代初頭の厳しい時期以降、Microsoft は、セキュリティの脆弱性に対処するために大規模な投資を行い、その後数十年で、マシン オンチップ BIOS カーネルの深さから始まり、ユーザー エクスペリエンスにまで拡張される強力なセキュリティ スタックを構築しました。 これらの多大な投資は継続されており、現在 3,500 人を超える Microsoft エンジニアが、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 は現在、世界の多くのデータセンターにデプロイされています。リージョン内のお客様が利用できるようにデータセンターによって提供されている多数のアクティブなデプロイだけでなく、各アクティブなデプロイのバックアップとして提供されるパッシブなデプロイも同じくらい多く存在します。

WFE とバックエンド

Web フロントエンド クラスター (WFE)

WFE クラスターは、サイトの読み込み時に最初の HTML ページ コンテンツをユーザーのブラウザーに提供する、ブラウザーでサイトをレンダリングするために使用される CDN コンテンツへのポインターも提供します。

WEF クラスター

WFE クラスターは、Azure App Service Environment で実行されている ASP.NET Web サイトで構成されます。 ユーザーが Power BI サービスに接続しようとすると、クライアントの DNS サービスは Azure Traffic Manager と通信して、Power BI がデプロイされている最も適切な (通常は最も近い) データセンターを見つけます。 このプロセスの詳細については、Azure Traffic Manager のパフォーマンス トラフィック ルーティング方法に関するページを参照してください。

*.js、*.css、イメージ ファイルなどの静的リソースは、ほとんどの場合、Azure Content Delivery Network (CDN) に格納され、ブラウザーによって直接取得されます。 Sovereign Government クラスターのデプロイはこの規則の例外であり、コンプライアンス上の理由から、CDN を省略し、代わりに準拠リージョンの WFE クラスターを使用して静的コンテンツをホストすることに注意してください。

Power BI のバックエンド クラスター (BE)

バックエンド クラスターは、Power BI で使用できるすべての機能のバックボーンです。 これは、Web フロントエンドおよび API クライアントによって使用されるいくつかのサービス エンドポイントと、バックグラウンドで動作するサービス、データベース、キャッシュ、その他のさまざまなコンポーネントで構成されます。

バックエンドは、ほとんどの Azure リージョンで利用可能であり、新しいリージョンには、利用可能になった時点でデプロイされます。 1 つの Azure リージョンで 1 つ以上のバックエンド クラスターをホストします。これにより、1 つのクラスターの垂直および水平スケーリング制限に達すると、Power BI サービスは無制限に水平スケーリングを行うことができます。

各バックエンド クラスターはステートフルであり、そのクラスターに割り当てられているすべてのテナントのすべてのデータをホストします。 特定のテナントのデータを含むクラスターは、テナントのホーム クラスターと呼ばれます。 認証されたユーザーのホーム クラスター情報は、グローバル サービスによって提供され、テナントのホーム クラスターに要求をルーティングするために Web フロントエンドによって使用されます。

各バックエンド クラスターは、特定のタスク、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 Premium クライアントには、ユーザーのブラウザー、通常の Power BI バックエンド、XMLA クライアント経由の直接接続、ARM API などがあります。

Azure リージョン内の Power BI Premium インフラストラクチャは、複数の Power BI Premium クラスター (最小は 1 つ) で構成されます。 Premium リソースのほとんどはクラスター (コンピューティングなど) 内にカプセル化されており、一般的なリージョン リソース (メタデータ ストレージなど) がいくつかあります。 Premium インフラストラクチャでは、2 つの方法を使用して、リージョン内で水平スケーラビリティを実現することができます。クラスター内のリソースを増加するか、必要に応じてオンデマンドでクラスターを追加します (クラスター リソースが限界に近づいている場合)。

各クラスターのバックボーンは、Virtual Machine Scale Sets と Azure Service Fabric によって管理されるコンピューティング リソースです。 Virtual Machine Scale Sets と Service Fabric を使用すると、使用量の増加に合わせてコンピューティング ノードを迅速かつ容易に増加して、Power BI Premium サービスとアプリケーションのデプロイ、管理、監視を調整できます。

周囲には、ロード バランサー、仮想ネットワーク、ネットワーク セキュリティ グループ、サービス バス、ストレージなど、インフラストラクチャの安全性と信頼性を確保するリソースが多数あります。Power BI Premium に必要なすべてのシークレット、キー、証明書は、Azure Key Vault によって排他的に管理されます。 すべての認証は、Microsoft Entra ID (旧称 Azure Active Directory) との統合によってのみ行われます。

Power BI Premium インフラストラクチャに送信されるすべての要求は、最初にフロントエンド ノードに送信されます。これらは、外部接続に使用できる唯一のノードです。 残りのリソースは、仮想ネットワークの背後に隠されています。 フロントエンド ノードは、要求の認証、処理、または適切なリソース (バックエンド ノードなど) への転送を行います。

バックエンド ノードは、ほとんどの Power BI Premium 機能を提供します。

Power BI Mobile

Power BI Mobile は、3 つの主要なモバイル プラットフォーム (Android、iOS、Windows (UWP)) 用に設計されたアプリのコレクションです。 Power BI Mobile アプリのセキュリティに関する考慮事項は、次の 2 つのカテゴリに分類されます。

  • デバイスの通信
  • デバイス上のアプリケーションとデータ

デバイスの通信では、すべての Power BI Mobile アプリケーションは Power BI サービスと通信し、このホワイト ペーパーで既に詳しく説明したとおり、ブラウザーで使用されるものと同じ接続と認証シーケンスを使用します。 Power BI との通信チャンネルを確立するため、iOS と Android の Power BI Mobile アプリケーションはそのアプリケーション内でブラウザー セッションを開始し、Windows のモバイル アプリケーションはブローカーを起動します (サインイン プロセス用)。

次の表は、モバイル デバイス プラットフォームに基づく Power BI Mobile の証明書ベースの認証 (CBA) のサポートを示しています。

CBA サポート iOS Android Windows
Power BI (サービスにサインイン) サポートされています サポート対象 サポートされていません
SSRS ADFS オンプレミス (SSRS サーバーに接続) サポートされていません サポート対象 サポートしていません
SSRS アプリ プロキシ サポート対象 サポート対象 サポートされていません

Power BI Mobile アプリは、積極的に Power BI サービスと通信します。 テレメトリは、モバイル アプリの利用状況統計や同様のデータを収集するために使用されます。このデータは、使用状況とアクティビティの監視に使用されるサービスに送信されます。顧客データがテレメトリと共に送信されることはありません。

Power BI アプリケーションは、アプリの利用を支援するデバイス上にデータを格納します。

  • Microsoft Entra ID と更新トークンは、業界標準のセキュリティ対策を使用して、デバイス上の安全なメカニズム内に保存されます。
  • データと設定 (ユーザー構成のキーと値のペア) は、デバイス上のストレージにキャッシュされ、OS によって暗号化できます。 iOS では、ユーザーがパスコードを設定すると、これは自動的に行われます。 Android では、設定でこれを構成できます。 Windows では、BitLocker を使用して実現されます。
  • Android および iOS アプリの場合、データと設定 (ユーザー構成のキーと値のペア) は、デバイス上のサンドボックス内のストレージと、アプリからのみアクセスできる内部ストレージにキャッシュされます。 Windows アプリの場合、データにはユーザー (およびシステム管理者) のみがアクセスできます。
  • 位置情報は、ユーザーによって明示的に有効または無効にされます。 有効にすると、位置情報データはデバイスに保存されず、Microsoft とも共有されません。
  • 通知は、ユーザーによって明示的に有効または無効にされます。 有効にすると、Android と iOS では、通知の地理的なデータ所在地の要件はサポートされません。

データ暗号化は、Microsoft Intune (モバイル デバイスとアプリケーション管理を提供するソフトウェア サービス) を使用してファイル レベルの暗号化を適用することにより、強化することができます。 Power BI Mobile を利用できる 3 つのプラットフォームはすべて、Intune をサポートしています。 Intune を有効にして構成すると、モバイル デバイス上のデータが暗号化され、Power BI アプリケーション自体を SD カードにインストールすることができません。 詳細については、Microsoft Intune に関するページを参照してください。

Windows アプリでは、Windows Information Protection (WIP) もサポートされています。

SSO を実装するために、トークンベースの認証に関連するいくつかのセキュリティで保護されたストレージ値は、他の Microsoft ファースト パーティ アプリ (Microsoft Authenticator など) で使用でき、Microsoft 認証ライブラリ (MSAL) によって管理されます。

Power BI Mobile のキャッシュ データは、アプリが削除されたとき、ユーザーが Power BI Mobile からサインアウトしたとき、またはユーザーがサインインに失敗したとき (トークンの有効期限イベント後やパスワードの変更後など) に削除されます。 データ キャッシュには、以前 Power BI Mobile アプリからアクセスしたダッシュボードとレポートが含まれます。

Power BI Mobile は、デバイス上の他のアプリケーション フォルダーまたはファイルにアクセスしません。

iOS および Android 用の Power BI アプリでは、iOS の場合は Face ID、Touch ID、またはパスコードの入力、Android の場合は生体認証データ (指紋 ID) の入力など、追加の識別を構成することでデータを保護できます。 詳細については、追加の識別に関するページを参照してください。

Power BI サービスへの認証

Power BI サービスに対するユーザーの認証は、ユーザーのブラウザーと Power BI サービスまたは Power BI で使用される Azure サービスの間で行われる、一連の要求、応答、リダイレクトで構成されます。 そのシーケンスでは Power BI でのユーザー認証のプロセスが示されており、これは Microsoft Entra の認証コード許可フローに従います。 組織のユーザー認証モデル (サインイン モデル) のオプションについて詳しくは、Microsoft 365 のサインイン モデルの選択に関するブログを参照してください。

認証シーケンス

Power BI サービスのユーザー認証シーケンスは、以下で説明する順序で行われます。説明の後に、これを図で示します。

  1. ユーザーは、ブラウザーでアドレス バーに Power BI のアドレスを入力するか、または Power BI のマーケティング ページ (https://powerbi.microsoft.com) で [サインイン] を選択して、ブラウザーから Power BI サービスへの接続を開始します。 接続は TLS と HTTPS を使用して確立され、それ以降にブラウザーと Power BI サービスの間で行われるすべての通信には HTTPS が使用されます。

  2. Azure Traffic Manager では、ユーザーの DNS レコードを調べて、Power BI がデプロイされている最も適切な (通常は最も近い) データセンターを決定し、ユーザーの送信先となる WFE クラスターの IP アドレスで DNS に応答します。

  3. 次に、WFE からブラウザー クライアントに HTML ページが返されます。このページには、サインイン フローを開始するために必要な MSAL.js ライブラリ参照が含まれています。

  4. ブラウザー クライアントでは、WFE から受信した HTML ページを読み込み、ユーザーを Microsoft Online Services サインイン ページにリダイレクトします。

  5. ユーザーは、認証された後、認証コードを使用してサインイン ページから Power BI WFE ページにリダイレクトされます。

  6. ブラウザー クライアントは HTML ページを読み込み、認証コードを使用して Microsoft Entra ID にトークン (アクセス、ID、更新) を要求します。

  7. ユーザーのテナント ID は、Power BI グローバル サービスに対してクエリを実行するためにブラウザー クライアントによって使用されます。Power BI グローバル サービスには、テナントとその Power BI バックエンド クラスターの場所の一覧が保持されています。 Power BI グローバル サービスは、ユーザーのテナントを含む Power BI バックエンド サービス クラスターを特定し、Power BI バックエンド クラスターの URL をクライアントに返します。

  8. クライアントは、HTTP 要求の Authorization ヘッダーのアクセス トークンを使用して、Power BI バックエンド クラスター URL API と通信できるようになりました。 Microsoft Entra アクセス トークンには、Microsoft Entra ポリシーに従って設定された有効期限があり、現在のセッションを維持するために、ユーザーのブラウザーの Power BI クライアントは、アクセス トークンの有効期限が切れる前にそれを更新するための要求を定期的に行います。

クライアント認証シーケンスを示す図。

まれですが、予期しないエラーが原因でクライアント側の認証が失敗した場合、コードは、WFE でサーバー側の認証を使用してフォールバックを試みます。 サーバー側の認証フローの詳細については、このドキュメントの最後にある「質問と回答」セクションを参照してください。

データの保存場所

ドキュメント内で特に明記されていない限り、Power BI は、Microsoft Entra テナントが初めて Power BI サービスにサインアップしたときに割り当てられる Azure 地域に顧客データを保存します。 Microsoft Entra テナントは、組織とそのセキュリティに関連するユーザーおよびアプリケーション ID、グループ、その他の関連情報を格納します。

テナント データ ストレージに対する Azure 地域の割り当ては、Microsoft Entra テナントのセットアップの一部として選択された国またはリージョンを、Power BI デプロイが存在する最も適切な Azure 地域にマッピングすることによって行われます。 この決定が行われると、組織が複数地域のデプロイを利用する場合を除き、すべての Power BI 顧客データはこの選択された Azure 地域 ("ホーム geo" とも呼ばれます) に格納されます。

複数地域 (Multi-Geo)

一部の組織は、グローバル プレゼンスを持ち、複数の Azure 地域で Power BI サービスを必要とする場合があります。 たとえば、企業は米国に本社を置き、オーストラリアなどの他の地理的な地域でもビジネスを行う場合があります。 このような場合、企業は、現地の規制に準拠するために、特定の Power BI データをリモート リージョンに保存しておくことが必要な場合があります。 Power BI サービスのこの機能は、Multi-Geo と呼ばれます。

Multi-Geo ワークスペースに割り当てられたクエリ実行レイヤー、クエリ キャッシュ、成果物データは、リモート容量の Azure 地域でホストされ、そこに残ります。 ただし、レポート構造などの一部の成果物メタデータは、テナントのホーム geo に保存されたままになる場合があります。 さらに、Multi-Geo Premium 容量でホストされているワークスペースであっても、一部のデータ転送と処理がテナントのホーム geo で引き続き発生する可能性があります。

複数の Azure 地域にまたがる Power BI デプロイの作成と管理の詳細については、「Power BI Premium の Multi-Geo のサポートを構成する」を参照してください。

リージョンとデータセンター

Microsoft トラスト センターで説明されているように、Power BI サービスは特定の Azure 地域で使用できます。 データが格納されている場所とその使用方法の詳細については、Microsoft セキュリティ センターを参照してください。 保存時の顧客データの場所に関するコミットメントは、Microsoft オンライン サービス条件のデータ処理の場所の使用条件で規定されています。

Microsoft は、ソブリン エンティティ向けのデータセンターも提供しています。 国/地域内クラウドで利用可能な Power BI サービスについて詳しくは、Power BI 国/地域内クラウドに関する記事をご覧ください。

データ処理

このセクションでは、顧客データの格納、処理、転送に関する Power BI のデータ処理方法について説明します。

保存データ

Power BI では、次の 2 種類のプライマリ データ ストレージ リソースが使用されます。

  • Azure Storage
  • Azure SQL Databases

ほとんどのシナリオでは、Azure Storage を使用して Power BI 成果物のデータを保持し、Azure SQL Database を使用して成果物メタデータを保持します。

Power BI によって保持されるすべてのデータは、既定で Microsoft マネージド キーを使用して暗号化されます。 Azure SQL Database に格納される顧客データは、Azure SQL の Transparent Data Encryption (TDE) テクノロジを使用して完全に暗号化されます。 Azure BLOB ストレージに格納される顧客データは、Azure Storage 暗号化を使用して暗号化されます。

必要に応じて、組織で Power BI Premium を利用して、セマンティック モデルにインポートされる保存データを暗号化するために独自のキーを使用できます。 このアプローチは多くの場合、Bring Your Own Key (BYOK) と説明されます。 BYOK を利用すると、サービス オペレーターのエラーが発生した場合でも、顧客データが公開されないようにすることができます。これは、透過的なサービス側の暗号化では、簡単に実現できません。 詳細については、「Power BI で独自の暗号化キーを使用する」を参照してください。

Power BI セマンティック モデルでは、さまざまなデータ ソース接続モードを使用でき、それに応じて、データ ソースのデータがサービス内で保持されるかどうかが決まります。

セマンティック モデル モード (種類) Power BI で保持されるデータ
[インポート] はい
DirectQuery いいえ
ライブ接続 いいえ
Composite インポート データ ソースが含まれている場合
ストリーム 保持するように構成されている場合

使用されるセマンティック モデル モードに関係なく、Power BI では、クエリとレポートの読み込みパフォーマンスを最適化するために、取得したデータを一時的にキャッシュする場合があります。

処理中のデータ

データは、対話型シナリオの一部として 1 人以上のユーザーによってアクティブに使用されている場合、または更新などのバックグラウンド プロセスでこのデータにアクセスしている場合、処理中です。 Power BI では、アクティブに処理されたデータを 1 つ以上のサービス ワークロードのメモリ空間に読み込みます。 ワークロードに必要な機能を容易にするために、メモリ内の処理されたデータは暗号化されません。

転送中のデータ

Power BI では、TLS 1.2 以降を使用してすべての受信 HTTP トラフィックを暗号化する必要があります。 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 ストレージ コンテナーで有効化されます。 以下の「保存データ」を参照してください。 ただし、ユーザーは、独自の Azure サブスクリプションに関連付けられている独自のストレージ アカウントを構成できます。 その場合、Power BI サービス プリンシパルには、更新中にそこにデータを書き込めるように、そのストレージ アカウントへのアクセス権が付与されます。 この場合、ストレージ リソース所有者は、構成された ADLS ストレージ アカウントで暗号化を構成する責任があります。 データは常に、暗号化を使用して BLOB ストレージに送信されます。

ストレージ アカウントにアクセスするときのパフォーマンスは、一部のデータに対して最適ではない場合があるため、ユーザーは Power BI でホストされるコンピューティング エンジンを使用してパフォーマンスを向上させることができます。 この場合、データは、バックエンドの Power BI システムによるアクセスを介して DirectQuery で使用できる SQL データベースに冗長に格納されます。 データは常にファイル システムで暗号化されます。 ユーザーが SQL データベースに格納されているデータを暗号化するためのキーを提供した場合、そのキーを使用してデータが二重に暗号化されます。

DirectQuery を使用してクエリを実行する場合、暗号化されたトランスポート プロトコル HTTPS を使用して API にアクセスします。 DirectQuery の二次的または間接的な使用はすべて、前に説明したものと同じアクセス制御によって制御されます。 データフローは常にワークスペースにバインドされるため、データへのアクセスは常に、そのワークスペース内のユーザーのロールによって制限されます。 ユーザーは、任意の方法でデータに対してクエリを実行できるように、少なくとも読み取りアクセス権を持っている必要があります。

Power BI Desktop がデータフロー内のデータへのアクセスに使用される場合、ユーザーがデータを表示する十分な権限を持っているかどうかを判断するために、Power BI Desktop は最初に Microsoft Entra ID を使用してユーザーを認証する必要があります。 その場合、SaS キーが取得され、暗号化されたトランスポート プロトコル HTTPS を使用してストレージに直接アクセスするために使用されます。

パイプライン全体のデータの処理によって、Office 365 監査イベントが生成されます。 これらのイベントの一部では、セキュリティおよびプライバシー関連の操作がキャプチャされます。

ページ分割されたレポート

ページ分割されたレポートは、印刷または共有することを想定してデザインされています。 これらは、1 ページにちょうど収まるように設定されているため "ページ分割された" と呼ばれます。 テーブルが複数のページにまたがる場合でも、テーブルのすべてのデータが表示されます。 レポートのページ レイアウトを正確に制御できます。

ページ分割されたレポートでは、Microsoft Visual Basic .NET で記述された豊富で強力な式がサポートされています。 式は、Power BI Report Builder のページ分割されたレポート全体で、データの取得、計算、表示、グループ化、並べ替え、フィルター処理、パラメーター化、および書式設定を行うために広く使用されます。

式は、.NET フレームワークのさまざまな機能にアクセスできるレポートの作成者によって作成されます。 ページ分割されたレポートの処理と実行は、サンドボックス内で行われます。

ページ分割されたレポート定義 (.rdl) は Power BI に格納され、ページ分割されたレポートを発行またはレンダリングするには、ユーザーが、上記の「Power BI サービスへの認証」セクションで説明したものと同じ方法で認証と承認を行う必要があります。

認証中に取得された Microsoft Entra トークンは、ブラウザーから Power BI Premium クラスターに直接通信するために使用されます。

Power BI Premium では、Power BI サービス ランタイムによって、レポートのレンダリングごとに適切に分離された実行環境が提供されます。 これには、レンダリングされるレポートが、同じ容量に割り当てられたワークスペースに属している場合が含まれます。

ページ分割されたレポートは、レポートのレンダリングの一部として、幅広いデータ ソースセットにアクセスできます。 サンドボックスでは、どのデータ ソースとも直接通信するのではなく、信頼されたプロセスと通信してデータを要求します。その後、信頼されたプロセスによって、必要な資格情報が接続に追加されます。 このように、サンドボックスは資格情報やシークレットにアクセスすることはありません。

Bing マップや Azure Functions の呼び出しなどの機能をサポートするために、サンドボックスはインターネットにアクセスできます。

Power BI 埋め込み分析

独立系ソフトウェア ベンダー (ISV) とソリューション プロバイダーには、Web アプリケーションとポータルに Power BI 成果物を埋め込むモードとして、主に 組織向けの埋め込みと顧客向けの埋め込みの 2 つがあります。 成果物は、アプリケーションまたはポータルの IFrame に埋め込まれます。 IFrame は、外部 Web アプリケーションまたはポータルからのデータの読み取りまたは書き込みを許可されておらず、IFrame との通信は、Power BI クライアント SDK を使用し、POST メッセージを使用して行われます。

組織向けの埋め込みシナリオでは、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 ネットワーク分離機能 (サービス タグ、Azure Private Link など) をサポートしています。

AI 機能

現在、Power BI では、AI ビジュアルと AI エンリッチメントという 2 つの広範なカテゴリの AI 機能を製品内でサポートしています。 視覚エフェクト レベルの AI 機能には、主要なインフルエンサー、分解ツリー、スマート説明、異常検出、R 視覚エフェクト、Python 視覚エフェクト、クラスタリング、予測、Q&A、クイック分析情報などの機能が含まれます。AI エンリッチメント機能には、AutoML、Azure Machine Learning、Cognitive Services、R/Python 変換などの機能が含まれます。

上記の機能の多くは、現在、Shared と Premium の両方のワークスペースでサポートされています。 ただし、IP の制限により、AutoML と CognitiveServices は 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 サービスを呼び出して、現在のイテレーションに適したモデルとハイパーパラメーターを選択します。 この送信呼び出しでは、前のイテレーションからの関連する実験メタデータ (正確性、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 が行い、アドレスが変化するとサービス タグは自動的に更新されます。

Azure ネットワークは Azure Private Link 機能を備えています。これにより、Power BI で Azure Networking プライベート エンドポイントを経由して安全なアクセスを提供できるようになります。 Azure Private Link およびプライベート エンドポイントを使用すると、Microsoft のバックボーン ネットワーク インフラストラクチャを使用してデータ トラフィックがプライベートに送信されるため、データはインターネットを経由しません。

Azure Private Link を使用すると、Power BI ユーザーが Power BI サービス内のリソースにアクセスするとき、Microsoft プライベート ネットワーク バックボーンが使用されるようになります。

Power BI で Azure Private Link を使用すると、次のような利点があります。

  • Azure Private Link を使用すると、トラフィックが Azure バックボーン経由で Azure クラウドベースのリソース用のプライベート エンドポイントに流れるようになります。
  • オンプレミスのアクセスなど、Azure 以外をベースにしたインフラストラクチャからのネットワーク トラフィック分離の場合、お客様は、ExpressRoute または仮想プライベート ネットワーク (VPN) を構成する必要があります。

詳細については、Power BI にアクセスするためのプライベート リンクに関するページを参照してください。

VNet 接続 (プレビュー - 近日公開予定)

Private Link 統合機能を使用すると、Power BI への安全な受信接続が提供されますが、Power BI から VNet 内のデータ ソースへの安全な送信接続は、VNet 接続機能によって実現されます。

VNet ゲートウェイ (Microsoft マネージド) を使用すると、VNet に関連付けられているデータ ソースに接続するためのオンプレミス データ ゲートウェイのインストールと監視のオーバーヘッドが排除されます。 ただし、オンプレミス データ ゲートウェイの場合と同様に、セキュリティとデータ ソースを管理する使い慣れたプロセスに従います。

VNet ゲートウェイを使用して VNet 内のデータ ソースに接続されている Power BI レポートを操作するときに発生する処理の概要を次に示します。

  1. Power BI クラウド サービス (またはサポートされている他のクラウド サービスの 1 つ) によってクエリが開始され、クエリ、データ ソースの詳細、資格情報が Power Platform VNet サービス (PP VNet) に送信されます。

  2. 次に、PP VNet サービスによって、VNet ゲートウェイを実行しているコンテナーがサブネットに安全に挿入されます。 このコンテナーは、このサブネット内からアクセスできるデータ サービスに接続できるようになります。

  3. 次に、PP VNet サービスによって、クエリ、データ ソースの詳細、資格情報が VNet ゲートウェイに送信されます。

  4. VNet ゲートウェイでクエリが取得され、それらの資格情報を使用してデータ ソースに接続されます。

  5. その後、クエリはデータ ソースに送信されて実行されます。

  6. 実行後、結果は VNet ゲートウェイに送信され、PP VNet サービスによってコンテナーから Power BI クラウド サービスにデータが安全にプッシュされます。

この機能は、近日中にパブリック プレビューで利用できるようになります。

サービス プリンシパル

Power BI では、サービス プリンシパルの使用がサポートされています。 Key Vault での Power BI の暗号化または Power BI へのアクセスに使用されるサービス プリンシパルの資格情報を格納し、適切なアクセス ポリシーをコンテナーに割り当てて、定期的にアクセス許可を確認します。

詳細については、「サービス プリンシパルを使用して Premium ワークスペースとセマンティック モデルのタスクを自動化する」を参照してください。

Microsoft Purview for Power BI

Microsoft Purview Information Protection

Power BI は Microsoft Purview 情報保護 {0} と緊密に統合されています。 Microsoft Purview 情報保護を使用すると、組織は Azure、Power BI、Office 全体で分類、ラベル付け、監査、コンプライアンスのためのソリューションを 1 つに統合できます。

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 (プレビュー) に接続すると自動的に秘密度ラベルを継承するため、Excel で Power BI セマンティック モデルを分析するときにエンド ツー エンドの分類を維持し、保護を適用することができます。
  • 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 コンテンツ スキャンに依存します。
  • 機密性の高いセマンティック モデルが検出された場合、必要な対処方法を理解するのに役立つ、カスタマイズされたポリシー ヒントを確認できます。
  • セマンティック モデル所有者は、正当な理由がある場合、ポリシーをオーバーライドし、セマンティック モデルが "機密" として識別されないようにすることができます。
  • セマンティック モデル所有者は、機密情報の種類が誤って識別されたという結論に達した場合、ポリシーに関する問題を報告できます。
  • セキュリティ管理者へのアラートなどの自動リスク軽減策を呼び出すことができます。

詳細については、「Power BI のデータ損失防止ポリシー」を参照してください。

Microsoft Defender 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 の制御の使用」を参照してください。

セキュリティ機能のプレビュー

このセクションでは、2021 年 3 月までのリリース予定の機能の一覧を示します。 このトピックでは、まだリリースされていない可能性がある機能の一覧を示しているため、提供スケジュールは変更される可能性があります。また、予定されている機能は、2021 年 3 月より後にリリースされるか、まったくリリースされない可能性があります。 プレビューの詳細については、オンライン サービス条件を確認してください。

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics を使用すると、Power BI と Azure Log Analytics を統合できます。 この統合には、Azure Log Analytics の高度な分析エンジン、対話型クエリ言語、組み込みの機械学習コンストラクトが含まれます。

Power BI のセキュリティに関する質問と回答

以下に示すのは、Power BI に関する一般的なセキュリティの質問と回答です。 これらは、このホワイト ペーパーに追加された日時を基準に並べられており、このペーパーが更新されたときに新しい質問と回答をすばやく見つけることができます。 最新の質問は、このリストの末尾に追加されます。

ユーザーが Power BI を使用しているとき、データ ソースにどのように接続、アクセスするのですか?

  • Power BI は、クラウド資格情報または個人用ゲートウェイを介した接続のために、各ユーザーのデータ ソースに対する資格情報を管理します。 オンプレミス データ ゲートウェイによって管理されるデータ ソースは企業全体で共有でき、これらのデータ ソースへのアクセス許可はゲートウェイ管理者が管理できます。セマンティック モデルを構成する場合、ユーザーは個人用ストアから資格情報を選択することも、オンプレミス データ ゲートウェイを使用して共有資格情報を使用することもできます。

    インポートの場合、ユーザーはユーザーのサインインに基づいて接続を確立し、資格情報を使用してデータにアクセスします。 セマンティック モデルが Power BI サービスに発行されると、Power BI では常にこのユーザーの資格情報を使用してデータがインポートされます。 データがインポートされると、レポートやダッシュボードでデータを表示しても、基になるデータ ソースにアクセスすることはありません。 Power BI では、選択されたデータ ソースに対するシングル サインオン認証がサポートされています。 シングル サインオンを使用するように接続が構成されている場合、セマンティック モデル所有者の資格情報を使用してデータ ソースに接続します。

    DirectQuery に接続されているレポートの場合、データ ソースは、事前に構成された資格情報を使用して直接接続されます。事前に構成された資格情報は、ユーザーがデータを表示するときにデータ ソースに接続するために使用されます。 データ ソースが、シングル サインオンを使用して直接接続されている場合、ユーザーがデータを表示するときに、現在の資格情報を使用してデータ ソースに接続します。 シングル サインオンで使用する場合、行レベル セキュリティ (RLS) またはオブジェクト レベル セキュリティ (OLS) をデータ ソースに実装できます。これにより、ユーザーは、アクセス権限を持つデータを表示できます。 接続がクラウド内のデータ ソースに対するものである場合、シングル サインオンには Microsoft Entra ID 認証が使用されます。オンプレミス データ ソースに対しては、Kerberos、SAML、Microsoft Entra ID がサポートされています。

    Kerberos で接続すると、ユーザーの UPN がゲートウェイに渡され、ユーザーは、Kerberos の制約付き委任を使用して偽装され、それぞれのデータ ソースに接続されます。 SAML は、SAP HANA データソース用ゲートウェイでもサポートされています。 詳細については、ゲートウェイ用シングル サインオンの概要に関するページを参照してください。

    データ ソースが Azure Analysis Services またはオンプレミスの Analysis Services であり、行レベル セキュリティ (RLS) やオブジェクト レベル セキュリティ (OLS) が構成されている場合、Power BI サービスではその行レベルのセキュリティが適用され、基になるデータ (ダッシュボード、レポート、またはその他のデータ成果物で使用されるクエリである可能性があります) にアクセスするための十分な資格情報を持っていないユーザーには、十分な特権を持たないデータが表示されません。

    Power BI で行レベル セキュリティ を使用すると、特定のユーザーのデータ アクセスを制限できます。 フィルターを使用すると、データ アクセスが行レベルで制限されます。フィルターは、ロール内で定義できます。

    オブジェクト レベル セキュリティ (OLS) を使用すると、機密性の高いテーブルまたは列をセキュリティで保護することができます。 ただし、行レベル セキュリティとは異なり、オブジェクト レベル セキュリティでは、オブジェクト名とメタデータもセキュリティで保護されます。 これにより、悪意のあるユーザーがそのようなオブジェクトの有無さえも検出できないようにすることができます。 Excel や Power BI などのレポート作成ツールを使用する場合、セキュリティで保護されたテーブルと列はフィールド リストに表示されません。また、アクセス許可のないユーザーは、DAX やその他の方法を使用して、セキュリティで保護されたメタデータ オブジェクトにアクセスすることはできません。 適切なアクセス許可を持たないユーザーから見ると、セキュリティで保護されたテーブルと列は存在しません。

    オブジェクト レベル セキュリティと行レベル セキュリティを組み合わせて使用すると、レポートとセマンティック モデルのエンタープライズ レベルのセキュリティが強化され、必要なアクセス許可を持つユーザーのみが機密データを表示および操作できるようになります。

データはどのように Power BI に転送されるのですか?

  • Power BI によって要求および送信されるすべてのデータは、転送中に HTTPS を使用して暗号化され (お客様が選択したデータ ソースで HTTPS がサポートされていない場合を除く)、データ ソースから Power BI サービスに接続されます。 データ プロバイダーによって安全な接続が確立され、一度接続が確立されれば、データがネットワーク上を通過します。

Power BI はどのようにレポート、ダッシュボード、モデル データをキャッシュするのですか? また、それは安全ですか?

  • データ ソースにアクセスする際、Power BI サービスでは、このドキュメントの前述の「データ ソースへの認証」セクションで概説したプロセスに従います。

クライアントは Web ページ データをローカルにキャッシュしますか?

  • ブラウザー クライアントが Power BI にアクセスすると、Power BI Web サーバーは Cache-Control ディレクティブを no-storeに設定します。 no-store ディレクティブはブラウザーに対して、ユーザーが表示中の Web ページをキャッシュしないよう、またクライアントのキャッシュ フォルダーにその Web ページを保存しないよう、指示します。

ロールベース セキュリティ、レポートやダッシュボードの共有、データ接続について教えてください。 データ アクセス、ダッシュボード表示、レポート アクセスまたは更新において、どのように機能しますか?

  • ロールレベル セキュリティ (RLS) 以外が有効なデータ ソースの場合、ダッシュボード、レポート、またはデータ モデルが他のユーザーと Power BI を介して共有されている場合、そのデータは表示と対話処理のために共有されているユーザーが利用可能となります。 Power BI はデータの元のソースに対するユーザーの再認証を行いません。データが一度 Power BI にアップロードされたら、ソース データに対して認証されているユーザーが、どのユーザーとグループがそのデータを表示可能であるかを管理する責任があります。

    RLS 対応のデータ ソース (Analysis Services データ ソースなど) に対してデータ接続が行われた場合、ダッシュボード データのみが Power BI 内にキャッシュされます。 RLS 対応のデータ ソースからのデータを使用する Power BI でレポートまたはセマンティック モデルが表示またはアクセスされるたびに、Power BI サービスはそのデータ ソースにアクセスし、ユーザーの資格情報に基づいてデータを取得します。十分なアクセス許可がある場合は、データがそのユーザーのレポートまたはデータ モデルに読み込まれます。 認証に失敗した場合、エラーが表示されます。

    詳細については、このドキュメントで既に説明した「データソースへの認証」セクションを参照してください。

私たちのユーザーは同じデータ ソースに常に接続しています。そのなかには、ドメイン資格情報とは異なる資格情報が必要なものがあります。 データに接続するたびにこのような資格情報を入力することを避けるためには、どうしたらいいでしょうか?

  • Power BI が提供する Power BI Personal Gateway という機能を使用すると、ユーザーは複数の異なるデータ ソースに対する資格情報を作成し、それらのデータ ソースにアクセスするときにその資格情報を自動的に使用することができるようになります。 詳細については、Power BI Personal Gatewayに関する記事を参照してください。

オンプレミス データ ゲートウェイと個人用ゲートウェイで使用されるポートは何ですか? 接続のために許可する必要があるドメイン名はありますか?

オンプレミス データ ゲートウェイを使用している場合、回復キーはどのように使用され、どこに格納されるのですか? また、安全な資格情報管理について教えてください。

  • ゲートウェイのインストールと構成中に、管理者はゲートウェイの回復キーを入力します。 その回復キーは、強力な 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 – WebSockets over HTTPS + TLS: このプロトコルでは、ポート 443 のみが使用されます。 WebSocket は、1 つの HTTP CONNECT メッセージによって開始されます。 一度チャンネルが確立されると、通信は基本的に TCP+TLS となります。 オンプレミス ゲートウェイに関する記事で説明されている設定を変更して、ゲートウェイでこのプロトコルを使用するように強制することができます。

Power BI での Azure CDN の役割は何ですか?

  • 前述したとおり、Power BI は Azure Content Delivery Network (CDN) を使用して、必要な静的コンテンツとファイルを地理的なロケールに基づいてユーザーに効率的に配布します。 さらに詳細な処理のため、Power BI サービスは複数の CDN を使用して、必要な静的コンテンツとファイルをパブリック インターネット経由でユーザーに効率的に配布します。 これらの静的ファイルには、製品ダウンロード (Power BI Desktop、オンプレミス データ ゲートウェイ、さまざまな独立系サービス プロバイダーから提供される 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 地図と ESRI ビジュアルは、これらのサービスを使用するビジュアルに関して、Power BI サービスの外部にデータを送信します。

テンプレート アプリの場合、Microsoft では、ギャラリーにアイテムを発行する前に、テンプレート アプリに対してセキュリティまたはプライバシーの評価を行いますか?

  • いいえ。 アプリの発行元はコンテンツに対して責任を負いますが、テンプレート アプリの発行元を確認して信頼できるかどうかを判断するのはお客様の責任です。

自社のネットワークの外部に情報を送信できるテンプレート アプリはありますか?

  • はい。 発行元のプライバシー ポリシーを確認し、テンプレート アプリをテナントにインストールするかどうかを決定するのは、お客様の責任です。 発行元は、アプリの動作と機能について顧客に通知する責任があります。

データ主権について教えてください。 特定の地域にあるデータ センター内のテナントを、データが国境またはリージョン境界を超えないようにプロビジョニングすることはできますか?

  • 特定の地域の一部のお客様には、データ ストレージと処理が他のすべてのデータセンターから分離されている国/地域内クラウドにテナントを作成できるオプションが用意されています。 国/地域内クラウドには若干異なる種類のセキュリティが適用されています。別のデータ トラスティが、国/地域内クラウド Power BI サービスを Microsoft の代理で運営するためです。

    または、お客様は特定のリージョンにテナントを設定することもできます。 ただし、このようなテナントには、Microsoft とは別のデータ トラスティはありません。 国/地域内クラウドの価格は、一般の商用 Power BI サービスと異なります。 国/地域内クラウドで利用可能な Power BI サービスについて詳しくは、Power BI 国/地域内クラウドに関する記事をご覧ください。

Power BI Premium サブスクリプションをお持ちのお客様に対して、Microsoft は接続をどのように扱いますか? これらの接続は、Premium 以外の Power BI サービス用に確立されたものとは異なるのでしょうか?

  • Power BI Premium サブスクリプションをお持ちのお客様に対して確立された接続は、アクセスの制御と認可を可能とする Microsoft Entra ID を使用して、Microsoft Entra 企業間取引 (B2B) 認可プロセスを実装します。 Power BI は、その他の Microsoft Entra ユーザーの場合と同様に、Power BI Premium サブスクライバーから Power BI Premium リソースへの接続を処理します。

サーバー側認証は、WFE でどのように機能しますか?

  • ユーザー認証シーケンスのサービス側認証は、以下で説明する順序で行われます。説明の後に、これを図で示します。

  1. ユーザーは、ブラウザーでアドレス バーに Power BI のアドレスを入力するか、または Power BI のマーケティング ページ (https://powerbi.microsoft.com) で [サインイン] を選択して、ブラウザーから Power BI サービスへの接続を開始します。 接続は TLS 1.2 と HTTPS を使用して確立され、それ以降にブラウザーと Power BI サービスの間で行われるすべての通信には HTTPS が使用されます。

  2. Azure Traffic Manager では、ユーザーの DNS レコードを調べて、Power BI がデプロイされている最も適切な (通常は最も近い) データセンターを決定し、ユーザーの送信先となる WFE クラスターの IP アドレスで DNS に応答します。

  3. 次に、WFE で、ユーザーが Microsoft Online Services のサインイン ページにリダイレクトされます。

  4. ユーザーは、認証された後、サインイン ページから、前に決定された最も近い Power BI サービスの WFE クラスターにリダイレクトされます。

  5. WFE クラスターは、認証コードを使用することで Microsoft Entra ID との確認を行い、Microsoft Entra セキュリティ トークンを取得します。 Microsoft Entra ID が、成功したユーザーの認証を返し Microsoft Entra セキュリティ トークンを返すと、WFE クラスターは、テナントとその Power BI バックエンド クラスターの場所の一覧を保持している Power BI グローバル サービスに問い合わせを行い、どの Power BI バックエンド サービス クラスターがユーザーのテナントを含んでいるかを特定します。 次に、WFE クラスターでは、操作に必要なセッション、アクセス、ルーティング情報を使用して、アプリケーション ページをユーザーのブラウザーに返します。

  6. これで、クライアントのブラウザーは、顧客データを要求する際に、Authorization ヘッダーに Microsoft Entra アクセス トークンを含む要求をバックエンド クラスター アドレスに送信するようになります。 Power BI バックエンド クラスターは、Microsoft Entra アクセス トークンを読み取り、署名を検証して、要求の ID が有効であることを確認します。 Microsoft Entra アクセス トークンには、Microsoft Entra ポリシーに従って設定された有効期限があり、現在のセッションを維持するために、ユーザーのブラウザーの Power BI クライアントは、アクセス トークンの有効期限が切れる前にそれを更新するための要求を定期的に行います。

WFE 認証シーケンスを示す図。

その他のリソース

Power BI に関する詳細については、次のリソースを参照してください。