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