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、ロナルド・チャン、オリ・エドゥアル、アントン・フリッツ、イダン・シェインバーグ、ロン・ギラド、サギフ・ハダヤ、ポール・インバー、イゴール・ウジビエフ、マイケル・ロス、ハイメ・タルキーノ、ゲンナディ・パッツ、オリオン・リー、ユーリー・ベレザンスキー、マヤ・シェナヴ、ロム・チャトパハイ、ヤリヴ・マイモン、 Bogdan Crivat

技術レビュー担当者: クリスティアン・ペトキュレスク、アミール・ネッツ、セルゲイ・グンドロフ

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

Note

このホワイト ペーパーを保存または印刷するには、ブラウザーから [印刷 ] を選択し、[ 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 Online Services の条項 のデータ処理の場所に関する用語と 、データ保護補遺を参照してください。 コンプライアンスについては、Microsoft セキュリティ センターが Power BI に関する主要なリソースです。 Power BI チームは、お客様に最新の技術革新と生産性を届けようと懸命に取り組んでいます。 Microsoft コンプライアンス オファリングのコンプライアンスの詳細について説明します。

Power BI サービスは、セキュリティの保証とコンプライアンスの要件をサポートする厳格なセキュリティ プラクティスであるセキュリティ開発ライフサイクル (SDL) に従います。 SDL は、開発コストを削減しながら、ソフトウェアの脆弱性の数と重大度を減らすことで、開発者がより安全なソフトウェアを構築するのに役立ちます。 詳細については、 Microsoft セキュリティ開発ライフサイクル プラクティスを参照してください

Power BI アーキテクチャ

Power BI サービスは、Microsoft のクラウド コンピューティング プラットフォームである Azure 上に構築されています。 Power BI は現在、世界の多くのデータセンターにデプロイされています。リージョン内のお客様が利用できるようにデータセンターによって提供されている多数のアクティブなデプロイだけでなく、各アクティブなデプロイのバックアップとして提供されるパッシブなデプロイも同じくらい多く存在します。

The WFE and Back End

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

WFE クラスターは、サイトの読み込み時にユーザーのブラウザーに初期 HTML ページコンテンツを提供し、Azure Active Directory (Azure AD) を使用してクライアントを認証し、Power BI バックエンド サービスへの後続のクライアント接続用のトークンを提供して、Power BIの初期接続と認証プロセスを管理します。

The WEF Cluster

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

ユーザーに割り当てられた WFE クラスターは、ログインと認証シーケンス (この記事で後述) を管理し、認証が成功するとAzure ADアクセス トークンを取得します。 WFE クラスター内の ASP.NET コンポーネントは、トークンを解析して、ユーザーが属している組織を特定し、Power BI グローバル サービスを参照します。 WFE は、組織のテナントを収容するバックエンド クラスターをブラウザーに指定します。 ユーザーが認証されると、顧客データに対する後続のクライアント対話がバックエンドまたはプレミアム クラスターで直接行われ、WFE はそれらの要求の仲介者になることはありません。

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

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

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

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

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

各バックエンド クラスターは、特定のタスク、SQL データベース、ストレージ アカウント、Service Bus、キャッシュ、その他の必要なクラウド コンポーネントなどのステートフル リソースを実行するために調整された、複数の仮想マシンを複数のサイズ変更可能スケール セットに組み合わせて構成されます。

テナントのメタデータとデータは、同じ Azure 地域のペアになっている Azure リージョンのセカンダリ バックエンド クラスターへのデータ レプリケーションを除き、クラスターの制限内に格納されます。 セカンダリ バックエンド クラスターは、リージョンの障害が発生した場合のフェールオーバー クラスターとして機能し、それ以外の場合はパッシブです。

バックエンド機能は、パブリック インターネットからアクセスできる 2 つのコンポーネントを除き、外部からアクセスできないクラスターの仮想ネットワーク内のさまざまなマシンで実行されているマイクロ サービスによって提供されます。

  • ゲートウェイ サービス
  • Azure API Management

The back-end cluster

Power BI Premium インフラストラクチャ

Power BI Premiumでは、データフロー、ページ分割されたレポート、AI などのプレミアム Power BI機能を必要とするサブスクライバー向けのサービスが提供されます。顧客がPower BI Premium サブスクリプションにサインアップすると、Azure Resource Managerを使用してプレミアム容量が作成されます。

Power BI Premium容量は、通常のPower BI バックエンドとは独立したバックエンド クラスターでホストされます (上記を参照)。 これにより、プレミアム オファリングの分離、リソースの割り当て、サポート可能性、セキュリティの分離、スケーラビリティが向上します。

次の図は、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)。 プレミアム リソースの大部分はクラスター内にカプセル化され (コンピューティングなど)、一般的なリージョン リソース (メタデータ ストレージなど) がいくつかあります。 プレミアムインフラストラクチャを使用すると、リージョン内で水平方向のスケーラビリティを実現する 2 つの方法が可能になります。クラスター内のリソースを増やしたり、必要に応じて必要に応じてクラスターを追加したりできます (クラスター リソースが制限に近づいている場合)。

各クラスターのバックボーンは、仮想マシン スケール セットAzure Service Fabricによって管理されるコンピューティング リソースです。 仮想マシン スケール セットとService Fabricを使用すると、Power BI Premium サービスとアプリケーションのデプロイ、管理、監視の使用量の増加と調整に合わせて、コンピューティング ノードの迅速かつ痛みのない増加が可能になります。

ロード バランサー、仮想ネットワーク、ネットワーク セキュリティ グループ、Service Bus、ストレージなど、セキュリティで保護された信頼性の高いインフラストラクチャを確保する多くのリソースが周囲にあります。Power BI Premiumに必要なすべてのシークレット、キー、証明書は、Azure Key Vaultによって排他的に管理されます。 すべての認証は、Azure ADとの統合によって排他的に行われます。

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 Android Windows
Power BI (サービスにサインイン) サポートされています サポートされています サポートされていません
SSRS ADFS オンプレミス (SSRS サーバーに接続) サポートされていません サポートされています サポートされていません
SSRS アプリ プロキシ サポートされています サポートされています サポートされていません

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

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

  • Azure ADトークンと更新トークンは、業界標準のセキュリティ対策を使用して、デバイス上のセキュリティで保護されたメカニズムに格納されます。
  • データと設定 (ユーザー構成のキーと値のペア) は、デバイス上のストレージにキャッシュされ、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 など) で使用でき、Azure Active Directory認証ライブラリ (ADAL) SDK によって管理されます。

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 サービスの間で行われる、一連の要求、応答、リダイレクトで構成されます。 このシーケンスでは、Azure Active Directoryの認証コード付与フローに従う、Power BIでのユーザー認証のプロセスについて説明します。 組織のユーザー認証モデル (サインイン モデル) のオプションの詳細については、「Microsoft 365のサインイン モデルの選択」を参照してください。

認証シーケンス

Power BI サービスのユーザー認証シーケンスは、次の手順で説明されているように発生します。これは、その後の画像に示されています。

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

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

  3. WFE は、ユーザーを Microsoft Online Services ログイン ページにリダイレクトします。

  4. ユーザーが認証されると、ログイン ページは、認証コードを使用して WFE クラスター Power BI サービス以前に決定された最も近いユーザーにユーザーをリダイレクトします。

  5. WFE クラスターは、認証コードを使用してAzure ADセキュリティ トークンを取得するために、Azure AD サービスと確認します。 Azure ADがユーザーの認証に成功し、Azure ADセキュリティ トークンを返すと、WFE クラスターは Power BI グローバル サービスを参照します。このサービスは、テナントとそのPower BIバックエンド クラスターの場所の一覧を保持し、ユーザーのテナントを含むバックエンド サービス クラスター Power BI決定します。 WFE クラスターは、操作に必要なセッション、アクセス、およびルーティング情報を含むアプリケーション ページをユーザーのブラウザーに返します。

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

Authentication sequence

データの保存場所

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

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

複数の地域 (複数地域)

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

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

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

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

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

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

データ処理

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

保存データ

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

  • Azure Storage
  • Azure SQL Databases

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

Power BIによって保持されるすべてのデータは、Microsoft マネージド キーを使用して既定で暗号化されます。 Azure SQL Database に格納されている顧客データは、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に保持されるデータ
[インポート] はい
直接クエリ No
ライブ接続 No
Composite インポート データ ソースが含まれている場合
ストリーミング 永続化するように構成されている場合

使用されるデータセット モードに関係なく、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) をデータ ソースに実装できます。 これにより、ユーザーはアクセス権限を持つデータのみを表示できます。 クラウド内のデータ ソースへの接続では、シングル サインオンにAzure AD認証が使用されます。オンプレミス データ ソースの場合は、Kerberos、Security Assertion Markup Language (SAML)、およびAzure ADがサポートされます。

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

Premium 機能

データフローアーキテクチャ

データフローを使用すると、多形データ ソースからデータを抽出し、データに対して変換ロジックを実行し、さまざまなレポートプレゼンテーション テクノロジで使用するためにターゲット モデルに配置するバックエンド データ処理操作を構成できます。 ワークスペースにメンバー、共同作成者、または管理者ロールを持つユーザーは、データフローを作成できます。 ビューアー ロールのユーザーは、データフローによって処理されたデータを表示できますが、その構成を変更することはできません。 データフローが作成されると、ワークスペースのメンバー、共同作成者、または管理者は、更新をスケジュールし、データフローの所有権を取得してデータフローを表示および編集できます。

構成された各データ ソースは、そのデータ ソースにアクセスするためのクライアント テクノロジにバインドされます。 アクセスに必要な資格情報の構造は、データ ソースの必要な実装の詳細と一致するように形成されます。 変換ロジックは、データの処理中Power Queryサービスによって適用されます。 Premium データフローの場合、Power Query サービスはバックエンド ノードで実行されます。 データは、クラウド ソースから直接、またはオンプレミスにインストールされているゲートウェイを介してプルできます。 クラウド ソースからサービスまたはゲートウェイに直接プルされると、必要に応じて、トランスポートはクライアント テクノロジに固有の保護手法を使用します。 ゲートウェイからクラウド サービスにデータが転送されると、データは暗号化されます。 上記の 「処理中のデータ」 セクションを参照してください。

お客様が指定したデータ ソースにアクセスするための資格情報が必要な場合、データフローの所有者/作成者は、作成時にそれらを提供します。 これらは、標準の製品全体の資格情報ストレージを使用して格納されます。 上記の「 データ ソースへの認証」セクションを 参照してください。 ユーザーがデータの永続化とアクセスを最適化するように構成できるさまざまな方法があります。 既定では、データはPower BI所有および保護されたストレージ アカウントに配置されます。 Storage暗号化は、保存中にデータを保護するために Blob Storage コンテナーで有効になります。 以下の「 保存データ」 セクションを参照してください。 ただし、ユーザーは、独自の Azure サブスクリプションに関連付けられている独自のストレージ アカウントを構成できます。 その場合、Power BI サービス プリンシパルにはそのストレージ アカウントへのアクセス権が付与され、更新中にそこにデータが書き込まれる可能性があります。 この場合、ストレージ リソース所有者は、構成された ADLS ストレージ アカウントで暗号化を構成します。 データは常に暗号化を使用して BLOB ストレージに送信されます。

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

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

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

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

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

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

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

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

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

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

プレミアム Gen1 の場合、テナントの容量ごとに 1 つのサンドボックスが存在し、容量に割り当てられたワークスペースによって共有されます。

Paginated reports Gen 1

プレミアム Gen2 では、レポートのレンダリングの 1 つごとに個別および排他的なエフェメラル サンドボックスが作成され、ユーザー間の分離レベルが高くなります。

Paginated reports Gen 2

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

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

Power BI 埋め込み分析

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

組織の埋め込みシナリオでは、Azure ADユーザーは、企業と ID によってカスタマイズされたポータルを使用して、独自の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 は、暗号化された埋め込みトークンを承認: EmbedToken ヘッダーとしてPower BI要求に自動的に追加します。 このヘッダーに基づいて、Power BIはすべてのポリシー (アクセスや RLS など) を、生成時に ISV で指定されたとおりに正確に適用します。

埋め込みと自動化を有効にし、上記の埋め込みトークンを生成するために、Power BIは豊富な REST API のセットを公開します。 これらのPower BI REST API は、ユーザー委任サービス プリンシパルAzure AD認証と承認の両方の方法をサポートします。

Power BI埋め込み分析とその REST API は、この記事で説明されているすべてのPower BIネットワーク分離機能 (サービス タグプライベート リンクなど) をサポートします。

AI の機能

現在、Power BIでは、現在、AI ビジュアルと AI エンリッチメントという 2 つの広範なカテゴリの AI 機能がサポートされています。 ビジュアル レベルの AI 機能には、キー インフルエンサー、分解ツリー、スマート ストーリー、異常検出、R ビジュアル、Python ビジュアル、クラスタリング、予測、QA&、Quick-Insightsなどの機能が含まれます。AI エンリッチメント機能には、AutoML、AzureML、CognitiveServices、R/Python 変換などの機能が含まれます。

上記の機能のほとんどは、現在、共有ワークスペースと プレミアム ワークスペースの両方でサポートされています。 ただし、AutoML と CognitiveService は、IP 制限のため、プレミアム ワークスペースでのみサポートされます。 現在、Power BIでの AutoML 統合により、ユーザーはカスタム ML モデル (予測、分類、回帰など) を構築してトレーニングし、それを適用して、プレミアム ワークスペースで定義されたデータフローにデータを読み込みながら予測を取得できます。 さらに、Power BIユーザーは、TextAnalytics や ImageTagging などの複数の CognitiveServices API を適用して、データを変換してから、プレミアム ワークスペースで定義されたデータフロー/データセットにデータを読み込むことができます。

プレミアム AI エンリッチメント機能は、Power BIデータセットまたはデータフローによって使用されるデータ統合パイプラインでPower BIユーザーが使用できるステートレス AI 関数/変換のコレクションとして最適と見なすことができます。 これらの関数は、Power BI サービスとPower BI Desktopの現在のデータフロー/データセット作成環境からもアクセスできることに注意してください。 これらの AI 関数/変換は、常にプレミアムワークスペース/容量で実行されます。 これらの関数は、AI 関数を使用しているPower BI ユーザーに対してAzure AD トークンを必要とするデータ ソースとしてPower BIに表示されます。 これらの AI データ ソースは、独自のデータを表示せず、これらの関数/変換のみを提供するため、特別です。 実行中、これらの機能は、顧客のデータを送信するために他のサービスへの送信呼び出しを行いません。 プレミアムシナリオを個別に見て、通信パターンとその関連するセキュリティ関連の詳細を理解しましょう。

AutoML モデルのトレーニングと適用のために、Power BIは Azure AutoML SDK を使用し、顧客のPower BI容量ですべてのトレーニングを実行します。 トレーニングイテレーション中に、Power BIは実験 AzureML サービスを呼び出して、現在のイテレーションに適したモデルとハイパーパラメーターを選択します。 この送信呼び出しでは、前のイテレーションからの関連する実験メタデータ (精度、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でデータセットを作成しているときに、ユーザーはプレミアム Power BI ワークスペースにアクセスできる場合にのみ、この機能にアクセスできます。 そのため、お客様はAzure AD資格情報の入力を求められます。

ネットワークの分離

このセクションでは、Power BIの高度なセキュリティ機能について説明します。 一部の機能には、特定のライセンス要件があります。 詳細については、以下のセクションを参照してください。

サービス タグ

サービス タグは、指定された Azure サービスからの IP アドレス プレフィックスのグループを表します。 これは、ネットワーク セキュリティ規則に対する頻繁な更新の複雑さを最小限に抑えるのに役立ちます。 お客様は、サービス タグを使用して、ネットワーク セキュリティ グループまたはAzure Firewallのネットワーク アクセス制御を定義できます。 お客様は、セキュリティ 規則を作成するときに、特定の IP アドレスの代わりにサービス タグを使用できます。 ルールの適切な送信元または宛先 (API の場合) フィールドにサービス タグ名 (など PowerBI) を指定することで、顧客は対応するサービスのトラフィックを許可または拒否できます。 サービス タグに含まれるアドレス プレフィックスの管理は Microsoft が行い、アドレスが変化するとサービス タグは自動的に更新されます。

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

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

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

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

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

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

Private Link統合機能はPower BIへの安全な受信接続を提供しますが、VNet 接続機能により、Power BIから VNet 内のデータ ソースへの安全な送信接続が可能になります。

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

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

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

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

  3. その後、PP VNet サービスは、クエリ、データ ソースの詳細、および資格情報を VNet ゲートウェイに送信します。

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

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

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

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

サービス プリンシパル

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

詳細については、「サービス プリンシパルを使用してプレミアムワークスペースとデータセット タスクを自動化する」を参照してください。

データ損失防止 (DLP)

秘密度ラベルのMicrosoft 365

Power BIは、Microsoft Information Protection (MIP) 秘密度ラベルと緊密に統合されており、組織は、Office スイート全体で DLP ポリシー管理、監査、コンプライアンスのための統合ソリューションを 1 つ持つことができます。

Power BIで秘密度ラベルが有効になっている場合:

  • 機密データは、Power BI サービスとPower BI Desktopの両方で、Officeと Azure Purview で使用されるのと同じ使い慣れたMicrosoft Information Protection秘密度ラベルを使用して分類およびラベル付けできます。
  • Power BIコンテンツがExcel、PowerPoint、PDF、または .pbix ファイルにエクスポートされた場合でも、ガバナンス ポリシーを適用して、Power BIを離れた場合でもデータを確実に保護することができます。
  • .pbix ファイルは、DESKTOP の .pbix ファイルに MIP ラベルが適用されるときに、MIP ラベル ポリシーに従って暗号化できます。これにより、承認されたユーザーのみがこのファイルを編集できるようになります。
  • .pbix ファイルは、Excel、Word、PowerPoint ファイルで行われるのと同じように、簡単に分類して保護できます。 2 回クリックするだけで、秘密度のレベルに応じてファイルにタグを付けることができ、さらに、ビジネス機密データが含まれている場合は暗号化できます。
  • 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は、承認されたユーザーのみが、Power BI サービスの保護設定でラベルを変更または削除できることを確認します。
  • 近日対応予定:
    • POWER BI管理 API を使用して MIP ラベルを適用し、中央のチームがPower BI サービス内のコンテンツにプログラムでラベルを付けることができるようになりました。
    • 管理者は、Power BI サービス (プレビュー) で必須のラベル ポリシーを使用して、新しいコンテンツまたは編集されたコンテンツにラベルを適用することができます。
    • Power BI サービス内のダウンストリーム成果物の自動ラベル付け。 データセットのラベルが適用または変更されると、この成果物に接続されているすべてのダウンストリーム コンテンツにラベルが自動的に適用されます。

詳細については、Power BIのMicrosoft Information Protection秘密度ラベルのドキュメントを参照してください。

Power BIのMicrosoft Defender for Cloud Apps

Microsoft Defender for Cloud Appsは、世界有数のクラウド アクセス セキュリティ ブローカーであり、Gartner のクラウド アクセス セキュリティ ブローカー (CASB) 市場のマジック クアドラントのリーダーとして名付けられています。 Defender for Cloudアプリは、クラウド アプリの使用をセキュリティで保護するために使用されます。 これにより、組織は、アンマネージド デバイスからのユーザー アクセスなど、危険なPower BI セッションをリアルタイムで監視および制御できます。 セキュリティ管理者は、機密情報を含むレポートのダウンロードなど、ユーザーアクションを制御するポリシーを定義できます。

Defender for Cloud アプリを使用すると、組織は次の 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アプリ アクティビティ ポリシー機能を利用して、独自のカスタム ルールを定義し、標準から逸脱したユーザーの動作を検出し、危険すぎる場合は自動的に処理することもできます。
  • Defender for Cloud アプリの組み込みの異常検出を操作します。 Defender for Cloudアプリの異常検出ポリシーでは、すぐに使用できるユーザー行動分析と機械学習が提供されるため、クラウド環境全体で高度な脅威検出を実行する準備が整います。 異常検出ポリシーが疑わしい動作を識別すると、セキュリティ アラートがトリガーされます。
  • Defender for Cloud アプリ ポータルで管理者ロールをPower BIします。 Defender for Cloud Apps には、アラート、危険なユーザー、アクティビティ ログ、その他のPower BI関連情報など、ポータルでPower BI関連するデータにアクセスするために必要なアクセス許可のみをPower BI管理者に付与するために使用できるアプリ固有の管理者ロールが用意されています。

詳細については、Power BIでのMicrosoft Defender for Cloud Apps コントロールの使用に関するページを参照してください。

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

このトピックでは、2021 年 3 月までリリースされる予定の機能の一覧を示します。 このトピックでは、まだリリースされていない可能性がある機能の一覧を示しているため、 配信タイムラインが変更され、予想される機能が 2021 年 3 月より後にリリースされる場合や、まったくリリースされない場合があります。 プレビューの詳細については、 オンライン サービスの使用条件を確認してください。

独自の Log Analytics を使用する (BYOLA)

独自の 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) を実装できます。これにより、ユーザーはアクセス権限を持つデータを表示できます。 クラウド内のデータ ソースへの接続では、シングル サインオンにAzure AD認証が使用されます。オンプレミス データ ソースの場合は、Kerberos、SAML、Azure ADがサポートされます。

    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 にアップロードされたら、ソース データに対して認証されているユーザーが、どのユーザーとグループがそのデータを表示可能であるかを管理する責任があります。

    Analysis Services データ ソースなどの RLS 対応データ ソースへのデータ接続が行われると、ダッシュボード データのみが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 – HTTPS + TLS 経由の WebSocket: このプロトコルでは、ポート 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 サービスとの対話処理を有効化するために必要な指定の共通ファイルのコレクションをダウンロードします。 ブラウザー ページには、Azure AD トークン、セッション情報、関連付けられているバックエンド クラスターの場所、Azure CDNと WFE クラスターからダウンロードされたファイルのコレクションが、Power BI サービスブラウザー セッションの間含まれます。

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 サブスクリプションを持つお客様に対して確立された接続は、アクセス制御と承認を有効にするためにAzure ADを使用して、Azure Business-to-Business (B2B) 承認プロセスを実装します。 Power BI は、その他の Azure AD ユーザーの場合と同様に、Power BI Premium のサブスクライバーから Power BI Premium のリソースへの接続を処理します。

その他のリソース

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