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, ロナルド・チャン, オリ・エドゥアル, アントン・フリッツ, イダン・シェインバーグ, ロン・ギラド, サギフ・ハダヤ, ポール・インバー, イゴール・ウージヴィエフ, Michael Roth, ハイメ・タルキノ, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yari 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 Online Services 利用規約 のデータ処理条件の場所と Data Protection 補遺を参照してください。 コンプライアンスについては、Microsoft セキュリティ センターが Power BI に関する主要なリソースです。 Power BI チームは、お客様に最新の技術革新と生産性を届けようと懸命に取り組んでいます。 Microsoft コンプライアンス オファリングのコンプライアンスの詳細について説明します。
Power BI サービスは、セキュリティの保証とコンプライアンスの要件をサポートする厳格なセキュリティ プラクティスであるセキュリティ開発ライフサイクル (SDL) に従います。 SDL は、開発者がソフトウェアの脆弱性の数と重大度を減らし、開発コストを削減することで、より安全なソフトウェアを構築するのに役立ちます。 詳細については、 Microsoft セキュリティ開発ライフサイクル プラクティスを参照してください。
Power BI アーキテクチャ
Power BI サービスは、Microsoft のクラウド コンピューティング プラットフォームである Azure 上に構築されています。 Power BI は現在、世界の多くのデータセンターにデプロイされています。リージョン内のお客様が利用できるようにデータセンターによって提供されている多数のアクティブなデプロイだけでなく、各アクティブなデプロイのバックアップとして提供されるパッシブなデプロイも同じくらい多く存在します。
Web フロントエンド クラスター (WFE)
WFE クラスターは、サイトの読み込み時に HTML ページの初期コンテンツをユーザーのブラウザーに提供し、Azure Active Directory (Azure AD) を使用して Power BI の初期接続と認証プロセスを管理し、クライアントを認証し、Power BI バックエンド サービスへの後続のクライアント接続用のトークンを提供します。
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 は、組織のテナントを格納するバックエンド クラスターをブラウザーに指定します。 ユーザーが認証されると、顧客データに対する後続のクライアント対話がバックエンドまたは Premium クラスターで直接行われ、WFE はそれらの要求の仲介者になることはありません。
*.js、*.css、イメージ ファイルなどの静的リソースは、ほとんどの場合、Azure Content Delivery Network (CDN) に格納され、ブラウザーによって直接取得されます。 ソブリン政府クラスターのデプロイはこの規則の例外であり、コンプライアンス上の理由から CDN を省略し、代わりに準拠しているリージョンの WFE クラスターを使用して静的コンテンツをホストします。
Power BI バックエンド クラスター (BE)
バックエンド クラスターは、Power BI で使用できるすべての機能のバックボーンです。 これは、Web フロントエンドおよび API クライアントによって使用される複数のサービス エンドポイントと、バックグラウンド作業サービス、データベース、キャッシュ、およびその他のさまざまなコンポーネントで構成されます。
バックエンドはほとんどの Azure リージョンで使用でき、利用可能になると新しいリージョンにデプロイされます。 1 つの Azure リージョンでは、1 つのクラスターの垂直方向と水平方向のスケーリングの制限が使い果たされると、Power BI サービスの無制限の水平スケーリングを可能にする 1 つ以上のバックエンド クラスターがホストされます。
各バックエンド クラスターはステートフルであり、そのクラスターに割り当てられているすべてのテナントのすべてのデータをホストします。 特定のテナントのデータを含むクラスターは、テナントのホーム クラスターと呼ばれます。 認証されたユーザーのホーム クラスター情報はグローバル サービスによって提供され、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 バックエンド、XMLA クライアント経由の直接接続、ARM API などがあります。
Azure リージョンのPower BI Premium インフラストラクチャは、複数のPower BI Premium クラスターで構成されます (最小値は 1)。 Premium リソースの大部分はクラスター (コンピューティングなど) 内にカプセル化され、一般的なリージョン リソース (メタデータ ストレージなど) がいくつかあります。 Premium インフラストラクチャを使用すると、リージョン内で水平方向のスケーラビリティを実現する 2 つの方法があります。クラスター内のリソースを増やしたり、必要に応じて必要に応じてクラスターを追加したりできます (クラスター リソースが制限に近づいている場合)。
各クラスターのバックボーンは、 仮想マシン スケール セット と Azure Service Fabric によって管理されるコンピューティング リソースです。 仮想マシン スケール セットと Service Fabric を使用すると、Power BI Premiumサービスとアプリケーションのデプロイ、管理、監視の使用量が増加し、調整されるにつれて、コンピューティング ノードの迅速かつ痛みのない増加が可能になります。
ロード バランサー、仮想ネットワーク、ネットワーク セキュリティ グループ、サービス バス、ストレージなど、セキュリティで保護された信頼性の高いインフラストラクチャを確保する多くのリソースが周囲にあります。Power BI Premiumに必要なすべてのシークレット、キー、および証明書は、Azure Key Vaultによって排他的に管理されます。 すべての認証は、Azure AD との統合によって排他的に行われます。
Power BI Premiumインフラストラクチャに送信されるすべての要求は、最初にフロントエンド ノードに送信されます。外部接続で使用できるノードは、そのノードだけです。 残りのリソースは、仮想ネットワークの背後に隠されています。 フロントエンド ノードは、要求の認証、処理、または適切なリソース (バックエンド ノードなど) への転送を行います。
バックエンド ノードは、ほとんどの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 on-prem (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 アプリでは、顔 ID、タッチ ID、iOS のパスコード、Android 用の生体認証データ (指紋 ID) の指定など、追加の ID を構成してデータを保護できます。 その他の識別の詳細については、こちらをご覧ください。
Power BI サービスへの認証
Power BI サービスに対するユーザーの認証は、ユーザーのブラウザーと Power BI サービスまたは Power BI で使用される Azure サービスの間で行われる、一連の要求、応答、リダイレクトで構成されます。 このシーケンスでは、 Azure Active Directory の認証コード付与フローに従う Power BI でのユーザー認証のプロセスについて説明します。 組織のユーザー認証モデル (サインイン モデル) のオプションの詳細については、「 Microsoft 365 のサインイン モデルの選択」を参照してください。
認証シーケンス
Power BI サービスのユーザー認証シーケンスは、次の手順で説明されているように発生します。この手順は、その後の図に示されています。
ユーザーがブラウザーからPower BI サービスへの接続を開始するには、アドレス バーで Power BI アドレスを入力するか、Power BI ランディング ページ (https://powerbi.microsoft.com) からサインインを選択します。 接続は TLS 1.2 と HTTPS を使用して確立され、それ以降にブラウザーと Power BI サービスの間で行われるすべての通信には HTTPS が使用されます。
Azure Traffic Manager は、ユーザーの DNS レコードをチェックして、Power BI がデプロイされている最も適切な (通常は最も近い) データセンターを特定し、ユーザーの送信先となる WFE クラスターの IP アドレスを使用して DNS に応答します。
WFE は、ユーザーを Microsoft Online Services ログイン ページにリダイレクトします。
ユーザーが認証された後、ログイン ページは、認証コードを使用して WFE クラスター Power BI サービス最も近くで決定されたユーザーにリダイレクトします。
WFE クラスターは、認証コードを使用して Azure AD セキュリティ トークンを取得するために、Azure AD サービスと確認します。 Azure AD からユーザーの認証が成功し、Azure AD セキュリティ トークンが返されると、WFE クラスターは Power BI グローバル サービスを参照します。このサービスでは、テナントとその Power BI バックエンド クラスターの場所の一覧が保持され、ユーザーのテナントを含む Power BI バックエンド サービス クラスターが決定されます。 その後、WFE クラスターは、操作に必要なセッション、アクセス、ルーティング情報を含むアプリケーション ページをユーザーのブラウザーに返します。
これで、クライアントのブラウザーで顧客データが必要になると、承認ヘッダーに Azure AD アクセス トークンを含むバックエンド クラスター アドレスに要求が送信されます。 Power BI バックエンド クラスターは、Azure AD アクセス トークンを読み取り、要求の ID が有効であることを確認するために署名を検証します。 Azure AD アクセス トークンの既定の有効期間は 1 時間であり、現在のセッションを維持するために、ユーザーのブラウザーはアクセス トークンの有効期限が切れる前に定期的に更新要求を行います。
データの保存場所
ドキュメントで特に示されていない限り、Power BI は、Azure AD テナント が初めて Power BI サービスにサインアップしたときに割り当てられる Azure 地域に顧客データを格納します。 Azure AD テナントには、組織とそのセキュリティに関連するユーザーとアプリケーションの ID、グループ、およびその他の関連情報が格納されます。
テナント データ ストレージに対する Azure geography の割り当ては、Azure AD テナントセットアップの一環として選択された国またはリージョンを、Power BI デプロイが存在する最も適切な Azure 地域にマッピングすることによって行われます。 この決定が行われると、組織が複数地域デプロイを利用する場合を除き、すべての Power BI 顧客データがこの選択した Azure geography ( ホーム geo とも呼ばれます) に格納されます。
複数の地域 (複数地域)
一部の組織はグローバルプレゼンスを持ち、複数の Azure 地域で Power BI サービスを必要とする場合があります。 たとえば、企業は米国に本社を置く場合もあれば、オーストラリアなどの他の地理的な地域でもビジネスを行う場合があります。 このような場合、ビジネスでは、ローカルの規制に準拠するために、特定の Power BI データをリモート リージョンに保存し続けることを要求する場合があります。 Power BI サービスのこの機能は、マルチ geo と呼ばれます。
複数 geo ワークスペースに割り当てられたクエリ実行レイヤー、クエリ キャッシュ、成果物データはホストされ、リモート容量の Azure geography に残ります。 ただし、レポート構造などの一部の成果物メタデータは、テナントのホーム geo に保存されたままになる場合があります。 さらに、複数地域の Premium 容量でホストされているワークスペースであっても、一部のデータ転送と処理がテナントのホーム geo で引き続き発生する可能性があります。
複数の Azure 地域にまたがる Power BI デプロイの作成と管理の詳細については、Power BI Premiumに対する複数地域のサポートの構成に関するページを参照してください。
リージョンとデータセンター
Power BI サービスは、 Microsoft セキュリティ センターで説明されているように、特定の Azure 地域で利用できます。 データの格納場所と使用方法の詳細については、 Microsoft セキュリティ センターを参照してください。 保存中の顧客データの場所に関するコミットメントは、 Microsoft Online Services の利用規約のデータ処理条件で指定されています。
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 データベースに格納されている顧客データは、Azure SQLの Transparent Data Encryption (TDE) テクノロジを使用して完全に暗号化されます。 Azure Blob Storage に格納されている顧客データは、 Azure Storage Encryption を使用して暗号化されます。
必要に応じて、組織は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 所有の保護されたストレージ アカウントに配置されます。 保存中にデータを保護するために、Blob Storage コンテナーでストレージ暗号化が有効になっています。 以下の「 保存データ 」セクションを参照してください。 ただし、ユーザーは、自分の Azure サブスクリプションに関連付けられている独自のストレージ アカウントを構成できます。 その場合、Power BI サービス プリンシパルには、そのストレージ アカウントへのアクセス権が付与され、更新時にそこにデータが書き込まれる可能性があります。 この場合、ストレージ リソース所有者は、構成された ADLS ストレージ アカウントで暗号化を構成する責任を負います。 データは常に暗号化を使用して Blob Storage に送信されます。
ストレージ アカウントへのアクセス時のパフォーマンスは一部のデータに対して最適ではない可能性があるため、ユーザーは 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 クラスターに直接通信するために使用されます。
Premium Gen1 の場合、テナントの容量ごとに 1 つのサンドボックスが存在し、容量に割り当てられたワークスペースによって共有されます。
Premium Gen2 では、レポートのレンダリングの 1 つごとに個別および排他的なエフェメラル サンドボックスが作成され、ユーザー間の分離レベルが高くなります。
ページ分割されたレポートは、レポートのレンダリングの一部として、幅広いデータ ソースセットにアクセスできます。 サンドボックスは、どのデータ ソースとも直接通信するのではなく、信頼されたプロセスと通信してデータを要求し、信頼されたプロセスによって必要な資格情報が接続に追加されます。 このようにして、サンドボックスは資格情報やシークレットにアクセスすることはありません。
Bing マップやAzure Functionsの呼び出しなどの機能をサポートするために、サンドボックスはインターネットにアクセスできます。
Power BI 埋め込み分析
独立系ソフトウェア ベンダー (ISV) とソリューション プロバイダーには、Web アプリケーションとポータルに Power BI 成果物を埋め込む主な 2 つのモードがあります。 組織用に埋め込み 、 顧客用に埋め込みます。 成果物は、アプリケーションまたはポータルの iframe に埋め込まれます。 iframe は外部 Web アプリケーションまたはポータルからデータの読み取りまたは書き込みを行うことができません。また、iframe との通信は、POST メッセージを使用して Power BI クライアント 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 は、暗号化された埋め込みトークンを Authorization: EmbedToken ヘッダーとして Power BI 要求に自動的に追加します。 このヘッダーに基づいて、Power BI では、生成時に ISV によって指定されたとおりに、すべてのポリシー (アクセスや RLS など) が正確に適用されます。
埋め込みと自動化を有効にし、前述の埋め込みトークンを生成するために、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 ビジュアル、クラスタリング、予測、Q&A、Quick-Insightsなどの機能が含まれます。AI エンリッチメント機能には、AutoML、AzureML、CognitiveServices、R/Python 変換などの機能が含まれます。
上記の機能のほとんどは、現在、共有ワークスペースと Premium ワークスペースの両方でサポートされています。 ただし、AutoML と CognitiveServices は、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 ユーザーに Azure AD トークンを必要とするデータ ソースとして Power BI に表示されます。 これらの AI データ ソースは、独自のデータを表示せず、これらの関数/変換のみを提供するため、特別です。 実行中、これらの機能は、顧客のデータを送信するために他のサービスに送信呼び出しを行いません。 Premium シナリオを個別に見て、通信パターンとそれらに関連するセキュリティ関連の詳細を理解しましょう。
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でデータセットを作成している間、ユーザーは Premium Power BI ワークスペースにアクセスできる場合にのみ、この機能にアクセスできます。 そのため、お客様は Azure AD 資格情報の入力を求められます。
ネットワークの分離
このセクションでは、Power BI の高度なセキュリティ機能について説明します。 一部の機能には、特定のライセンス要件があります。 詳細については、以下のセクションを参照してください。
サービス タグ
サービス タグは、指定された Azure サービスからの IP アドレス プレフィックスのグループを表します。 これは、ネットワーク セキュリティ規則に対する頻繁な更新の複雑さを最小限に抑えるのに役立ちます。 お客様は、サービス タグを使用して、ネットワーク セキュリティ グループまたはAzure Firewallのネットワーク アクセス制御を定義できます。 お客様は、セキュリティ規則を作成するときに、特定の IP アドレスの代わりにサービス タグを使用できます。 ルールの適切な送信元または送信先 (API の場合) フィールドにサービス タグ名 (など PowerBI) を指定することで、顧客は対応するサービスのトラフィックを許可または拒否できます。 サービス タグに含まれるアドレス プレフィックスの管理は Microsoft が行い、アドレスが変化するとサービス タグは自動的に更新されます。
Private Link統合
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 レポートを操作する場合の概要を次に示します。
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 ワークスペースとデータセット タスクを自動化する 」を参照してください。
Microsoft Purview for Power BI
Microsoft Purview Information Protection
Power BI は、Microsoft Perview Information Protection (以前は Microsoft 365 コンプライアンス Information Protection) と深く統合されています。 Microsoft Purview 情報保護を使用すると、組織は、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 コンテンツのスキャンに依存します。
- 機密として識別されたデータセットが見つかった場合は、何をすべきかを理解するのに役立つカスタマイズされたポリシー ヒントを確認できます。
- データセット所有者の場合は、ポリシーをオーバーライドし、有効な理由がある場合にデータセットが "機密" として識別されないようにすることができます。
- データセットの所有者は、機密情報の種類が誤って識別されたと判断した場合に、ポリシーに関する問題を報告できます。
- セキュリティ管理者へのアラートなどの自動リスク軽減策を呼び出すことができます。
詳細については、「 Power BI のデータ損失防止ポリシー」を参照してください。
Power BI のMicrosoft Defender for Cloud Apps
Microsoft Defender for Cloud Appsは、世界有数のクラウド アクセス セキュリティ ブローカーの 1 つであり、Gartner のクラウド アクセス セキュリティ ブローカー (CASB) 市場向けのマジック クアドラントのリーダーとして名付けられています。 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 月より後にリリースされる場合や、まったくリリースされない場合があります。 プレビューの詳細については、 オンライン サービスの使用条件を確認してください。
独自の 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 に関する詳細については、次のリソースを参照してください。