Power BI のセキュリティ
Power BI のセキュリティの詳細については、Power BI のセキュリティに関するホワイト ペーパーを参照してください。
Power BI のセキュリティを計画するには、Power BI 実装計画のセキュリティ シリーズに関する記事を参照してください。 Power BI Security ホワイト ペーパーの内容から展開したものです。 Power BI セキュリティ ホワイト ペーパーでは、認証、データ所在地、ネットワーク分離などの主要な技術トピックに焦点を当てていますが、このシリーズの主な目標は、セキュリティとプライバシーの計画に役立つ考慮事項と決定事項を提供することです。
Power BI サービスは、Azure 上に構築されています。これは、Microsoft のクラウド コンピューティングのインフラストラクチャとプラットフォームです。 Power BI サービスのアーキテクチャは、次の 2 つのクラスターに基づいています。
- Web フロントエンド (WFE) クラスター。 WFE クラスターは、Power BI サービスへの初期接続と認証を管理するものです。
- バックエンド クラスター。 認証が完了した後のすべてのユーザー操作は、バックエンドが処理します。 Power BI でのユーザー ID の保存および管理には、Microsoft Entra ID が使用されます。 また、Microsoft Entra ID も、Azure BLOB と Azure SQL Database を使ってそれぞれデータ ストレージとメタデータを管理します。
Power BI のアーキテクチャ
WFE クラスターは、Microsoft Entra ID を使ってクライアントを認証し、その後の Power BI サービスへのクライアント接続にトークンを提供します。 Power BI は、Azure Traffic Manager (Traffic Manager) を使って、最も近いデータセンターにユーザー トラフィックを転送します。 Traffic Manager は、接続、認証、静的コンテンツとファイルのダウンロードを試行するクライアントの DNS レコードを使って、要求を転送します。 Power BI は、Azure Content Delivery Network (CDN) を使用して、必要な静的コンテンツとファイルを地理的なロケールに基づいてユーザーに効率的に配布します。
バックエンド クラスターは、認証されたクライアントが Power BI サービスと対話する方法を決定します。 バックエンド クラスターは、視覚化、ユーザー ダッシュボード、セマンティック モデル、レポート、データ ストレージ、データ接続、最新の情報への更新をはじめ、Power BI サービスと対話するためのさまざまな側面を管理します。 ゲートウェイ ロール は、ユーザーの要求と Power BI サービス間のゲートウェイとして機能します。 ユーザーは、ゲートウェイ ロール以外のすべてのロールと直接対話することはありません。 ゲートウェイ ロールを最終的に処理するのは、Azure API Management です。
重要
パブリック インターネット経由でアクセスできるのは、Azure API Management と Gateway のロールのみです。 これらには、認証、承認、DDoS 保護、調整、負荷分散、ルーティングなどの機能があります。
データ ストレージのセキュリティ
Power BI は、データを格納し、管理するために 2 つのプライマリ リポジトリを使います。
- 通常、ユーザーからアップロードされたデータは Azure Blob Storage に送信されます。
- システム自体の項目を含むすべてのメタデータは Azure SQL データベースに格納されます。
バックエンド クラスター図の点線は、点線の左側に示すユーザーがアクセスできる 2 つのコンポーネント間の境界を明示するものです。 システムからのみアクセスできるロールは右側に表示されています。 認証されたユーザーが Power BI サービスに接続したとき、クライアントからの接続とすべての要求は、ゲートウェイ ロールによって受け入れられ、管理されます。その後は、これらがユーザーに代わって Power BI サービスの残りの部分と対話します。 たとえば、クライアントがダッシュボードを表示しようとすると、ゲートウェイ ロールがその要求を受け入れ、それとは別にプレゼンテーション ロールに要求を送り、ブラウザーでダッシュボードを表示するために必要なデータを取得します。 最終的に、接続とクライアント要求は Azure API Management によって処理されます。
ユーザー認証
Power BI は、Microsoft Entra ID を使って、Power BI サービスにサインインするユーザーを認証します。 ユーザーがセキュリティで保護されたリソースにアクセスしようとすると、常にサインイン資格情報が要求されます。 ユーザーは、Power BI アカウントの設定時に使ったメール アドレスを使って、Power BI サービスにサインインします。 ユーザーがデータに接続しようとすると、Power BI は、"有効なユーザー名" と同じ資格情報を使い、リソースにそれを渡します。 その後、"有効なユーザー名" は "ユーザー プリンシパル名" にマップされ、認証の適用対象となる、関連付けられた Windows ドメイン アカウントに解決されます。
Power BI のサインインに職場のメール アドレス (david@contoso.com など) を使う組織の場合、"有効なユーザー名" から UPN へのマッピングは簡単です。 職場のメール アドレス (david@contoso.onmicrosoft.com) を使わなかった組織の場合、たとえば Microsoft Entra ID とオンプレミスの資格情報間のマッピングが正しく機能するには、ディレクトリの同期が必要です。
また、Power BI のプラットフォーム セキュリティには、マルチテナント環境のセキュリティ、ネットワーク セキュリティ、その他の Microsoft Entra ID ベースのセキュリティ対策を追加する機能も含まれています。
データとサービスのセキュリティ
詳細については、Microsoft トラスト センターの「信頼を基盤とする製品とサービス」を参照してください。
前述のように、オンプレミスの AD サーバーは、Power BI のサインインを使って資格情報の UPN にマップします。 ただし、ユーザーは、共有するデータの機密性を理解する必要があります。 データ ソースにセキュリティで保護された方法で接続し、レポート、ダッシュボード、またはセマンティック モデルを他者と共有すると、受信者はレポートへのアクセスが許可されます。 受信者がデータ ソースにサインインする必要はありません。
例外は、オンプレミス データ ゲートウェイを使って SQL Server Analysis Services に接続する場合です。 ダッシュボードは Power BI にキャッシュされますが、基のレポートまたはセマンティック モデルにアクセスすると、レポートまたはセマンティック モデルにアクセスを試みるユーザーごとに、認証が開始されます。 アクセスが許可されるのは、ユーザーがデータにアクセスできる十分な資格情報を持っている場合のみです。 詳細については、「オンプレミス データ ゲートウェイの詳細」を参照してください。
TLS バージョンの使用の強制
ネットワークおよび IT 管理者は、ネットワーク上のセキュリティで保護された通信に対して、現在の トランスポート層セキュリティ (TLS) の使用を強制できます。 Windows は Microsoft Schannel Provider を介した TLS バージョンをサポートしています。詳細については、「TLS/SSL のプロトコル (Schannel SSP)」を参照してください。
この強制を実装するには、管理者権限でレジストリ キーを設定します。 強制の詳細については、「クライアントの SSL/TLS プロトコルと暗号スイートの AD FS を管理する」を参照してください。
エンドポイントをセキュリティで保護するには、Power BI Desktop に TLS (トランスポート層セキュリティ) バージョン 1.2 (またはそれ以上) が必要です。 TLS 1.2 より前のバージョンの TLS を使用する Web ブラウザーやその他のクライアント アプリケーションでは、接続できません。 より新しいバージョンの TLS が必要な場合、Power BI Desktop では、これらの記事で説明されているレジストリ キー設定が優先され、また、存在する場合はこれらのレジストリ キー設定に基づいて許可される TLS のバージョン要件を満たす接続のみが作成されます。
これらのレジストリ キー設定の詳細については、「トランスポート層セキュリティ (TLS) のレジストリ設定」を参照してください。