次の方法で共有


データフローのデータ流出の考慮事項とベスト プラクティス

ファブリック データフローPower Platform データフローは、ユーザーがサポートされている何百ものデータ ソース間でデータに簡単に接続、抽出、移動、変換できるようにする Microsoft 365 サービスです。 データフローは、クラウド サービスとしてデータ移動エンジン (マッシュアップ エンジン) をホストする Power Query Online という基になるサービスに基づいています。 既定では、接続はこのクラウドの場所から発信され、インターネットに無制限にアクセスできます。 そのため、データフローを使用して機密データにアクセスして移動する場合、組織は、偶発的または悪意のあるデータ流出からインサイダーを阻止する戦略を検討する必要があります。 この記事では、既知のリスク要因とセーフガードのベスト プラクティスについて説明します。

考慮事項

任意コード実行

データフロー ETL ジョブは、Power Query M と呼ばれる言語で記述されたプログラムを通じて定義されます。既定の構成では、マッシュアップ エンジンは、テナントのネットワーク境界外のクラウドで、インターネット アクセスへの制限なくこれらのプログラムを実行します。 ユーザーは、複数のデータ ソースに接続するプログラムを作成でき、同意があれば、これらのソース間でデータをフローさせることができます。

機密データにアクセスできる信頼できるユーザーは、信頼されていないデータ ストアにデータをプッシュするプログラムを作成できます。 マッシュアップ エンジンは完全にクラウドで実行されるため、企業のファイアウォールやプロキシ サーバーを経由することはありません。 そのため、これらのネットワークによって適用される可能性のあるデータ損失防止 (DLP) ポリシーの対象になりません。 アクセス ポイントはパブリック インターネット上に存在するため、データは、認証または匿名アクセスを使用して、ユーザーがアクセスできる任意の宛先に移動できます。 これらのプログラムが機密データを流出させることができる方法の例を次に示します。

  • 匿名 Web 要求: Web.Contents を使用すると、ユーザーは要求の本文に機密データを含む Web 要求を行うことができます。
  • クロス データ ソースのフィルター処理と結合: 機密データは、他の信頼されていないデータ ソースに対するフィルター処理または結合条件として使用できます。 具体的には、データは、クエリ文字列またはパラメーターの形式で信頼されていないデータ ソースに移動できます。
  • 出力先: Fabric データフローを使用すると、ユーザーはクエリの出力先を指定できるため、Azure SQL データベースと Data Warehouse、Fabric Lakehouses、Warehouses、KQL データベースなど、サポートされているデータ シンクの一覧にデータを転送できます。

クラウド上で実行される M プログラムで任意のコードを実行し、信頼されていないデータ ソースに接続する方法の画像。

テナント間のデータ移動

マッシュアップ エンジンでは、接続を行う前にデータ ソースを明示的に定義する必要があります。 データ ソースは、種類とパス キー (たとえば SQL;contoso.database.windows.net) を持つプログラムにバインドされます。 このバインドにより、組織は、データ ソース パスに基づいてフィルター処理することで、許可されるデータ ソースを管理できます。 ただし、パスがすべての接続で共通であり、データがサインインしているユーザーの OAuth 資格情報のテナントによってのみセグメント化されるデータ ソースがいくつかあります。 このシナリオでは、データ流出のリスク要因が作成されます。この場合、ユーザーはより高いセキュリティ テナントとより低いセキュリティ テナントにサインインし、それらの間でデータを移動します。 通常、この流出は次の 2 つの方法で実行できます。

  • 送信: 上位のセキュリティ テナントの信頼されたユーザーは、その環境でデータフローを定義し、許可されたデータ シンクへの出力先を作成しますが、下位のセキュリティ テナントのアカウントを使用してデータ シンクで認証します。
  • 受信: 下位のセキュリティ テナントのユーザーは、上位のセキュリティ テナントの機密データ ソースからデータを読み取るデータフローを定義します。 この定義は、上位のセキュリティ テナントの信頼されたアカウントを使用して機密データ ソースに対して認証することで実現できます。

低セキュリティ テナントにデータを転送し、信頼されていないデータ ソースに出力データにアクセスできる高セキュリティ テナントの画像。

DLP ポリシーは、さまざまな OSI レイヤで動作できます。 一般に、データの機密性が高いほど、ポリシーを適用する必要があるレイヤは低くなります。 低レイヤ プロトコルは、通常、実装にコストがかかり、スケーリングが困難になり、操作が困難になります。 たとえば、ガバナンス要件が低い組織では、アプリケーション レイヤー ポリシーを適用するだけで済む場合があります。 ただし、機密性の高いデータを処理する組織やエンティティによっては、物理的な分離などの極端な対策が必要になる場合があります。 機密データを処理する組織は、内部関係者による脅威から保護するために、アプリケーションレベルのポリシーとネットワーク レベルのポリシーを組み合わせて使用することをお勧めします。

ネットワークの分離

機密データを含むすべてのデータ ストアは、選択したネットワークからのアクセスのみを許可するようにネットワークの分離をすることをお勧めします。 この分離制限は、ネットワーク層以下で定義および運用する必要があります。 たとえば、レイヤ 3 のファイアウォール、ネットワーク セキュリティ グループ (NSG)、Azure Private Link は、使用できるメカニズムの良い例です。 ただし、Microsoft Entra ID の場所ベースの条件付きアクセス ポリシーはアプリケーション レイヤーで動作し、この目的には不十分と見なされます。

これらのネットワークの分離ポリシーは、データフローのクラウド実行エンジンから機密データ ストアへの見通し線を妨げる必要があります (クラウド エンジンはパブリック インターネット上で実行されるため)。 その後、これらのデータ ストアへのデータフローの接続は、オンプレミス データ ゲートウェイまたは VNet データ ゲートウェイへの接続をバインドすることによって、許可されているネットワークの 1 つから発信されるよう強制されます。 データフローの重要な実行特性は、クラウドベースの評価とゲートウェイベースの評価がブレンドされないということです。 データフローがネットワーク分離データ ストアにアクセスする必要がある (したがってゲートウェイにバインドされている) 場合は、すべてのデータ アクセスがゲートウェイを通過する必要があります。 さらに、ゲートウェイはユーザー テナントによって制御されるネットワークに物理的に存在するため、ファイアウォールや DLP 保護ソリューションなどのネットワーク レベルの制限に準拠します。 これらの制限により、ゲートウェイ環境は企業のマネージド デバイスと同様にセキュリティで保護され安全となり、クラウド環境での任意コード実行に関連するリスクが軽減されます。

信頼されていないデータ ソースへのゲートウェイの実行エンジンの送信アクセスが拒否され、機密データ ストアへのクラウド実行エンジンの受信アクセスも拒否されるアーキテクチャ図の画像。

機密データを含む可能性のあるすべてのデータ ストアにネットワークの分離を適用する必要があることに注意してください。 ユーザーが OneDrive for Business から Power BI にデータを読み取るデータフローを作成する例を考えてみましょう。 その後、ユーザーはリンクされたデータフローを作成して、Power BI のデータをダウンストリーム エンティティに変換します。 このシナリオでは、OneDrive for Business を信頼されたネットワークに分離するだけでは不十分です。 機密データは Power BI 内にも存在する可能性があるため、このようなデータを分離するには、プライベート リンクを有効にし、Power BI のパブリック インターネット アクセスを無効にすることが重要です。 プライベート エンドポイントを使用した Power BI への安全なアクセスについて確認してください

ゲートウェイの実行を強制する

選択したネットワークに機密データ ストアを分離する目的は、アクセス元を信頼されたネットワークに強制的に戻すことです。これにより、マネージド デバイスを管理する既存のポリシーを使用して、データフローからのデータ移動を管理できます。 場合によっては、完全なネットワークの分離ソリューションの開発、テスト、デプロイに時間がかかる場合があります。 別の方法として、データフロー サポート チケットを提出して、マッシュアップ エンジンをオフにするテナント全体のポリシーを適用することもできます。 このポリシーは、Power Query Online マッシュアップ エンジンを使用するすべてのクエリ評価に影響します。 影響を受ける機能は次のとおりです。

  • ファブリック データフロー
  • Power Platform データフロー
  • Azure Data Factory のラングリング データフロー
  • Dynamics 365 のデータフロー (Customer Insights、Intelligent Order Management など)
  • Power BI データマート
  • SharePoint からの Power BI クイック インポート

ポリシーの適用後、すべてのクラウドベースの実行が失敗し、次のエラーが発生します。Cloud evaluation request denied based on tenant policies. Please use a data gateway and try again. このエラーにより、最初に完全なネットワークの分離ソリューションをロールアウトすることなく、テナント内のすべてのクエリ評価がゲートウェイで強制的に効率よく実行されます。 ポリシーは、ワークロードのサブセットではなく、テナント全体に適用されることに注意してください。 このポリシーは、既存のワークロードがすぐに失敗し、ゲートウェイで実行するように変換するために手動による介入が必要であることを意味します。 また、このポリシーを適用する組織は、すべてのワークロードに対応できる十分な容量をゲートウェイ クラスターに確保する必要があります。

テナントの分離

Fabric Lakehouse や Power Platform Dataverse などのほとんどのサービスとしてのソフトウェア (SaaS)レイヤ データ ストアには、通常、データにアクセスするために通信するマルチテナント エンドポイントがあります。 これらのエンドポイントは、サービスのすべてのユーザーに共通しているため、ネットワーク (レイヤ 3) 分離手法のみを使用して分離および保護することは困難な場合があります。 この種のデータ ストアには、通常 Microsoft Entra ID によって提供されるレイヤ 7 ポリシーを使用することをお勧めします。

  • Microsoft Entra ID 認証のみ許可します。 データ ストアから匿名認証スキームとユーザー名/パスワード認証スキームを削除します。
  • 場所ポリシーを使用して、マネージド デバイスからのみセキュリティで保護されたテナントへのサインインを許可します。 詳細情報。
  • Microsoft Entra ID テナント制限を使用して、マネージド デバイスからの不明なテナント サインインを禁止します。 テナント制限を使用して SaaS アプリへのアクセスを管理します。 詳細情報。

この方法では、テナントの機密データ ストアへのアクセスを、別のテナントへのサインインが許可されていない一連のマネージド デバイスに制限し、テナント全体のデータ移動を効果的に分離します。

ロードマップ

次の一覧には、組織が Fabric のデータ流出リスクをより適切に管理するために現在計画されている機能の一部が含まれています。

  • データ ソース接続許可リスト: Fabric テナント管理者は、テナント内で使用できるコネクタの種類と、コネクタが接続できるエンドポイントを制御できます。
  • 接続の使用状況の監査: 接続の作成、更新、削除、使用状況を追跡する監査ログのサポート。