Azure Databricksによるデータ漏洩対策

前回のブログでは、仮想ネットワークサービスエンドポイントまたはPrivate Linkを使用して、Azure DatabricksからAzureデータサービスに安全にアクセスする方法について説明しました。 この記事では、これらのベストプラクティスのベースラインを前提として、データの流出を防止するために、ネットワークセキュリティの観点からAzure Databricksのデプロイを強化する方法について、詳細な手順をウォークスルーします。

Wikipediaによるとデータ漏洩は、マルウェアや悪意のある行為者がコンピュータから不正なデータ転送を行うことで発生します。一般に、データ漏洩またはデータエクスポートとも呼ばれます。データ漏洩は、データ窃盗の一形態とも考えられています。2000年以降、多くのデータ漏洩が発生し、世界中の企業の消費者信頼、企業評価、知的財産、政府の国家安全保障に深刻な損害を与えました。 この問題は、企業が機密データ（PII、PHI、戦略的機密情報）をパブリッククラウドサービスで保管・処理するようになると、さらに重要性を増します。

PaaSサービスがデータの保存を要求したり、サービスプロバイダーのネットワーク内でデータを処理したりする場合、データ漏洩の解決は手に負えない問題になる可能性があります。 しかし、Azure Databricksを利用することで、お客様はAzureサブスクリプションにすべてのデータを保持し、Azure上で最も急速に成長しているデータ & AIサービスのPaaSの性質を維持しながら、独自のマネージドプライベート仮想ネットワークでデータを処理することができます。 私たちは、最もセキュリティ意識の高いお客様と協力しながら、プラットフォームの安全な展開アーキテクチャを考え出しました。

Databricksの展開オプション

Databricksワークスペースの展開には、ネットワークの観点から3つの特徴があります。

1. マイクロソフトが管理する仮想ネットワーク（VNet）にワークスペースを展開
2. 顧客管理の仮想ネットワークにワークスペースを展開（VNetインジェクション）
3. Private Linkを使用して顧客管理の仮想ネットワークにワークスペースの展開

どのオプションを選択しても、Databricksで使用される仮想ネットワークはAzureサブスクリプションに存在することに注意してください。 この記事の残りの部分は、オプション3、つまり セキュアなクラスタ接続とPrivate Linkにより、お客様が管理する仮想ネットワークにワークスペースを展開します。

標準デプロイまたは簡略化されたデプロイの選択

Azure DatabricksがサポートするPrivate Linkの展開には次の2つのタイプがあり、どちらかを選択する必要があります：

標準デプロイ（推奨）：セキュリティ強化のため、Databricksではフロントエンド接続に別のトランジットVNetから別のプライベートエンドポイントを使用することを推奨しています。 フロントエンドとバックエンドの両方のPrivate Link接続を実装することも、バックエンド接続だけを実装することもできます。 クラシックデータプレーンでコンピュートリソースに使用するVNetとは別に、ユーザーアクセスをカプセル化するために別のVNetを使用します。 バックエンドとフロントエンドのアクセス用に別々のPrivate Linkエンドポイントを作成します。 「標準デプロイとして Azure Private Link を有効にする」の手順に従ってください。

簡略化されたデプロイ：組織によっては、複数のプライベートエンドポイントを許可しない、トランジットVNetを分離しないなど、さまざまなネットワークポリシー上の理由で標準デプロイを使用できない場合があります。 代わりに、Private Linkの簡略化されたデプロイを使用することもできます。 クラシックデータプレーンでコンピュートリソースに使用するVNetからユーザーアクセスを分離するVNetはありません。 代わりに、データプレーンVNetのトランジットサブネットがユーザーアクセスに使用されます。 Private Linkのエンドポイントは1つだけです。 通常、フロントエンドとバックエンドの両方の接続が設定されます。 オプションでフロントエンド接続のみを設定できます。 この配置タイプでは、バックエンド接続のみを使用するように選択することはできません。 「簡略化されたデプロイとして Azure Private Link を有効にする」の手順に従ってください。

ハイレベルなデータ流出防止アーキテクチャ

ハブ & スポークトポロジーのスタイルのリファレンスアーキテクチャをお勧めします。 ハブ仮想ネットワークは、検証済みのソースや、オプションでオンプレミス環境に接続するために必要な共有インフラを収容します。 また、スポーク仮想ネットワークはハブとピアリングしながら、異なるビジネスユニットや分離されたチームのために分離されたAzure Databricksワークスペースを収容します。

このようなハブ & スポークアーキテクチャにより、目的やチームごとに複数のスポークVNetを作成することができます。 また、連続した大規模な仮想ネットワーク内にチームごとに個別のサブネットを作成することで、分離を実現することも可能です。 このような場合、分離された複数のAzure Databricksワークスペースをそれぞれのサブネットペアにセットアップし、同じ仮想ネットワーク内の別の姉妹サブネットにAzure Firewallをデプロイすることが可能です。

ハイレベルな見解：

安全なAzure Databricksデプロイの手順：

1. VNetインジェクションとPrivate Linkを使用したスポーク仮想ネットワークで、セキュアクラスター接続 （SCC）を有効にしたAzure Databricksを展開します。
2. Azure Databricksスポーク仮想ネットワーク内の別のサブネットに、Azureデータサービス用のPrivate Linkエンドポイントを設定します。 これにより、すべてのワークロードのデータが、デフォルトのデータ流出防止機能を備えたAzureネットワークバックボーン経由で安全にアクセスされるようになります（詳細については、このブログを参照してください）。 また、一般的には、Azure Databricksワークスペースをホストしている仮想ネットワークにピアリングされた別の仮想ネットワークに、これらのエンドポイントをデプロイしてもまったく問題ありません。 プライベートエンドポイントには追加コストが発生するため、（組織のセキュリティポリシーに基づいて）プライベートエンドポイントではなくサービスエンドポイントを活用して Azureデータサービスにアクセスすることは問題ありません。
3. Azure Databricks Unity Catalogを活用した統合ガバナンスソリューション。
4. ハブ仮想ネットワークにAzure Firewall（または他のネットワークバーチャルアプライアンス）を導入：Azure Firewallでは、以下のような構成が可能です：
   • アプリケーションルール：ファイアウォールを通してアクセス可能な完全修飾ドメイン名（FQDN）を定義するアプリケーションルール。 Azure Databricksで必要なトラフィックの一部は、アプリケーションルールを使用してホワイトリストに登録できます。
   • ネットワークルール：FQDNを使用して構成できないエンドポイントのIPアドレス、ポート、プロトコルを定義するネットワークルール。 必要なAzure Databricksトラフィックの一部は、ネットワークルールを使用してホワイトリストに登録する必要があります。
   お客様の中には、Azure Firewallの代わりにサードパーティのファイアウォールアプライアンスを使用することを希望される方もいらっしゃいますが、一般的には問題なく動作します。 ただし、製品ごとに微妙な違いがあるため、適切な問題のトラブルシューティングには、関連する製品サポートやネットワークセキュリティチームを活用頂くことをお勧めします。
5. 以下のルールでユーザー定義のルートテーブルを作成し、Azure Databricksサブネットにアタッチして、すべてのデータ転送トラフィックをAzure Firewallにルーティングします。 Azure Firewallを簡単に管理できるようにし、IP変更時のサービス停止を防ぐために、Azureサービスタグを使用することをお勧めします。 また、ユーザー定義のルートテーブル（およびサービスタグルールの追加）を使用して、データ転送トラフィックを制御プレーンアセットにルーティングすることもできます。
6. Azure Databricksスポーク仮想ネットワークとAzure Firewallハブ仮想ネットワーク間の仮想ネットワークピアリングを構成します。
7. ハブVnet（プライベートエンドポイントサブネット）上にフロントエンドとブラウザ認証（SSO用）用のプライベートエンドポイントをデプロイします。

セキュアなAzure Databricksの展開詳細

始める前に

なぜワークスペースごとに2つのサブネットが必要なのですか？
ワークスペースには2つのサブネットが必要で、一般に「ホスト」（別名「パブリック」）と「コンテナ」（別名「プライベート」）と呼ばれています。 各サブネットは、ホスト（Azure VM）とVM内で実行されるコンテナ（Databricksランタイム、別名dbr）にIPアドレスを提供します。

パブリックまたはホストのサブネットにはパブリックIPアドレスがありますか？
いいえ、SCCと呼ばれるセキュアなクラスタ接続を使用してワークスペースを作成した場合、DatabricksのサブネットにはパブリックIPアドレスはありません。 ホストサブネットのデフォルト名がpublic-subnetになっているだけです。 SCCは、ネットワーク外からネットワークトラフィックが侵入しないようにします。 DatabricksワークスペースコンピュートインスタンスにSSH接続します。

デプロイ後にサブネットのサイズを変更できますか？
Databricksワークスペースがデプロイされると、Databricksネットワークのサブネットのサイズを変更することはできません。

前提条件

仮想ネットワークへのAzure Databricksの展開

ステップ 1: 仮想ネットワークにAzure Databricksワークスペースをデプロイします。

Azure Databricksの標準デプロイでは、Databricksが管理するリソースグループに新しい仮想ネットワーク（2つのサブネットを持つ）が作成されます。 セキュアなデプロイに必要なカスタマイズを行うために、ワークスペースのデータプレーンは、NPIPを使用して独自の仮想ネットワークにデプロイする必要があります。 このデプロイは、Azure PortalまたはAll in one ARMテンプレートを使用するか、Azure Databricks Terraform Providersを使用して行うことができます。

3つのサブネット（host/public、container/private、pe）を持つリソースグループ内に仮想ネットワークを作成します。 pe-subnetはプライベートエンドポイントに使用され、すべてのアプリケーションデータがAzureネットワークバックボーン上で安全にアクセスされることを保証します。 host（public）とcontainer（private）のサブネットは、ワークスペースをデプロイする前に、ユースケースに基づいて決定する必要があります。 Databricksワークスペースがデプロイされると、Databricksネットワークのサブネットのサイズを変更することはできません。

AzureポータルからのAzure Databricksのデプロイ

AzureポータルからVNetインジェクションとパブリックIPなし（SCC）で Azure Databricksワークスペースを作成

Review and Createをクリックします。 いくつか注意すべきことがあります：

1. SCC / NPIP（パブリックIPなし）およびVNetインジェクションオプションを選択します。
2. Azure Databricksワークスペースを展開する仮想ネットワークを選択します。
3. 仮想ネットワークには、各Azure Databricksワークスペース専用の 2 つのサブネット（プライベートサブネットとパブリックサブネット）を含める必要があります（ネーミングルールは任意のものを使用してください）。
   • パブリックサブネットは、各クラスタノードのホストVMのプライベートIPのソースです。 プライベートサブネットは、各クラスタノードにデプロイされたDatabricks RuntimeコンテナのプライベートIPのソースです。 これは、各クラスタノードが現在2つのプライベートIPアドレスを持っていることを示しています。
   • 各ワークスペースのサブネットのサイズは、/18から/26まで許容され、実際のサイジングはワークスペースごとの全体的なワークロードの予測に基づいて行われます。 アドレス空間は任意（RFC1918以外のものも含む）ですが、企業のオンプレミスとクラウドのネットワーク戦略に沿ったものでなければなりません。
   • Azure Databricksは、Azureポータルを使用してワークスペースをデプロイするときに、これらのサブネットを作成し、Microsoft.Databricks/workspaces サービスへのサブネット委任を実行します。 これにより、Azure Databricksは必要なネットワークセキュリティグループ（NSG）ルールを作成することができます。 Azure Databricksが管理するNSGルールのスコープを追加または更新する必要がある場合、Azure Databricksは常に事前に通知します。 これらのサブネットがすでに存在する場合、サービスはそれらをそのまま使用することに注意してください。 これらのNSGルールの詳細な説明は下表の通りです。
   • これらのサブネットとAzure Databricksワークスペースの間には1対1の関係があります。 同じサブネットペアで複数のワークスペースを共有することはできず、異なるワークスペースごとに新しいサブネットペアを使用する必要があります。
   • ワークスペースがデプロイされると、パブリックサブネットとプライベートサブネットのサイズを変更することはできません。
   • Azure Databricksのデプロイによって、AzureポータルのAzure Databricksリソースの概要ページに管理されたリソースグループが作成されることに注意してください。 管理対象リソースグループにリソースを作成したり、既存のリソースを編集したりすることはできません。
4. Azure Databricksは、フロントエンド（ユーザーからワークスペースへのリンク）とプライベートリンクの両方に対応しています。 Allow public network access set to Disabled）とバックエンド（データプレーンからコントロールプレーン。 Azure Databricks ルールを使用しない）パブリックインターネットにトラフィックを公開することなくプライベート接続を可能にします。
5. ドキュメントに従ってプライベートエンドポイントを作成し、簡易または標準のデプロイメントパターンを使用してPrivate LinkでAzure Databricksをデプロイします。
6. 暗号化されたデータを保護し、アクセスを制御するために、顧客が管理するキーを有効にします。

ネットワークセキュリティルール：その意味は？

インバウンドルール

Worker to Worker Inboundルールは、クラスタのインスタンス間のトラフィックを許可します。

アウトバウンドルール

• Worker to Workerルールはクラスタのインスタンス間のトラフィックを許可し、ドライバとワーカーが相互に通信できるようにします。
• メタストア（Sqlサービスタグ）は、パブリックサブネットからデフォルトHiveメタストアへのアウトバウンドトラフィックを許可します。
• コントロールプレーン（AzureDatabricksサービスタグ）は、Azure Databricks コントロールプレーン（すなわちSCC、Webapp) をパブリックサブネットから取得します。
• 注：バックエンドのプライベートリンクが有効な場合、AzureDatabricksサービスタグはNSGルールに追加されません。
• ストレージ（Storageサービスタグ）は、パブリックサブネットからログストレージ、アーティファクト、DBFSなどのコントロールプレーン資産へのアウトバウンドトラフィックを許可します。
• Event Hub（EventHubサービスタグ）は、パブリックサブネットからEvent Hubエンドポイント（オブザーバビリティ用）へのアウトバウンドトラフィックを許可します。
• Private Linkが有効なワークスペースの場合、プライベートエンドポイントサブネットとのアウトバウンド通信用に、2つの追加ポート（443、6666）を追加する必要があります。 プライベートエンドポイントサブネットのNSGルールでは、インバウンド通信用に同じポートを開く必要があります。

ステップ2：デフォルトのBlobストレージ（DBFS）用のプライベートエンドポイントの設定（オプション）

Azure Databricksは、デプロイプロセス中にデフォルトのBlobストレージ（別名ルートストレージ）を作成し、ログとテレメトリーの保存に使用します。 このストレージでパブリックアクセスが有効になっていても、このストレージに作成された拒否割り当てはストレージへの外部からの直接アクセスを禁止しています。 Azure Databricksのデプロイでは、プライベートエンドポイント（dfsとblobの両方）の作成により、ルートBlobストレージ（DBFS）へのセキュアな接続がサポートされるようになりましたが、DBFSのプライベートエンドポイントを有効にしてもパブリックアクセスはオフになりません。 なお、ストレージ用のプライベートエンドポイントには追加費用が発生します。

ベストプラクティスとして、アプリケーションデータをルートBlob（DBFS）ストレージに保存することは推奨されません。 Private Link（Azureデータサービスへのセキュアなアクセス）を使用してアプリケーション固有のデータを保存するために、独立したADLS Gen2 Storageを活用します。

ネットワーク仮想アプライアンス/ファイアウォールを介してこのようなデータサービスへのアクセスを設定することは、ビッグデータワークロードと中間インフラのパフォーマンスに悪影響を与える可能性があるため、お勧めしません。

注：アプリケーションデータは、外部のADLS Gen2ストレージに保存することを強くお勧めします。 同様のセットアップを行い、外部ADLSストレージ用のPrivate Linkエンドポイントを作成し、データを安全にアクセス/保存します。

このようなプライベートエンドポイントを追加サービス用に設定するには、関連するAzureドキュメントを参照してください。

ステップ3：Azure Firewallの導入

Azure Firewallはスケーラブルなクラウドネイティブファイアウォールで、Azure Databricksワークスペースからアクセスを許可されたパブリックエンドポイントのフィルタリングデバイスとして機能します。

典型的な例では、ファイアウォールは中央集中型のハブVNetに配置され、複数のスポークVNetでピアリングされます。 スポークVNetはファイアウォール経由ですべてのトラフィックをアウトバウンドします。

Azure Firewallポリシーは、Azure Firewallのルールを作成するために推奨されるアプローチです。 Firewallポリシーは、複数のAzure Firewallインスタンスで使用できるグローバルリソースです。

以下のように、ネットワークルールとアプリケーションルールのコレクションを作成します。 アウトバウンドトラフィックがUDR経由の場合、アプリケーションルールはオプションであることに注意してください（次のセクションで説明します）。

注

1. ワークスペースのプライベートエンドポイントが有効になっている場合、AzureDatabricksサービスタグは必要ありません。
2. Azure Databricksは、NTPサービス、CDN、cloudflare、GPUドライバ、および適切にホワイトリストに登録する必要があるデモデータセットの外部ストレージへの追加呼び出しも行います。

FirewallポリシーをFirewallにアタッチします。

UDRとAzure Firewallポリシーでサービスタグを使用することは、管理を容易にするために推奨されますが、ここからワークスペースのAzure Databricksコントロールプレーンエンドポイントを活用できます。

ステップ4：ユーザー定義ルート（UDR）の作成

この時点で、セキュアでロックダウンされた展開のためのインフラストラクチャのセットアップの大部分は完了しています。 次に、Azure DatabricksワークスペースのサブネットからコントロールプレーンとAzure Firewallに適切なトラフィックをルーティングする必要があります。

ルートテーブルを作成し、すべてのトラフィックを仮想アプライアンス（Azure Firewall）に転送します。

ステップ6：VNETピアリングの設定

最後に、仮想ネットワークazuredatabricks-spoke-vnetと hub-vnetをピアリングして、先に設定したルートテーブルが正しく動作するようにする必要があります。 ドキュメントに従って、ハブとスポークネットワーク間のVNetピアリングを設定します。

これでセットアップは完了です。

ステップ7：ワークスペースUnity Catalogメタストアの割り当て

最後のステップに入りました。 次に、ワークスペースをUnity Catalogに割り当てます。

ステップ 8: 展開の検証

展開結果を検証します：

• フロントエンドのアクセスが無効になっている場合、VNetを使用して仮想マシンをデプロイします。
• ステップ1で作成したAzure Databricksワークスペースに移動し、起動してクラスタを作成します。
• ノートブックを作成し、クラスターにアタッチします。
• 先ほどのステップ2で作成したストレージアカウントにアクセスしてみてください。

データアクセスが問題なく動作していれば、サブスクリプションにおけるAzure Databricksの最適なセキュアなデプロイが達成されたことになります。 これはかなりの手作業でしたが、一回限りのショーケースのためでした。 現実的には、ARMテンプレート、Azure CLI、Azure SDKなどを組み合わせて、このようなセットアップを自動化したいと思うでしょう：

• ARM テンプレートを使用した独自のマネージド VNET での Azure Databricks のデプロイ
• Azure CLI（またはARM テンプレート）を使用したプライベートエンドポイントの作成
• ARMテンプレート（またはAzure CLI）を使用した Azure Firewallのデプロイ
• ARMテンプレートを使用したルートテーブルとカスタムルートの展開
• ARMテンプレートを使用したピア仮想ネットワーク
• TerraformでAzure Databricksのプライベートリンクを作成

データ流出防止アーキテクチャに関するよくある質問

サービスエンドポイントを使用して、Azureデータサービスへのデータ送信を保護できますか？

はい、VNetインジェクションとともに保護できます。 サービスエンドポイントは、Azureバックボーンネットワーク上の最適化されたルートを通じて、Azureサービスへの安全で直接的な接続を提供します。 サービスエンドポイントは、外部Azureリソースへの接続を仮想ネットワークのみに保護するために使用できます。 サービスエンドポイントは、サービスエンドポイントを使用するAzureサービスのネットワークファイアウォールルールが適切に定義されている場合にのみ安全です。

サービスエンドポイントポリシーを使用できますか？

いいえ、Databricksによって使用されるサブネットは、ネットワークインテントポリシーを使用してロックされます。 Azureネットワークインテントポリシーは、お客様が誤ってDatabricksで使用するサブネットを変更しないようにするための内部ネットワーク構造です。

Azure Firewall以外のネットワーク仮想アプライアンス（NVA）を使用できますか？

はい、この記事で説明したようにネットワークトラフィックルールが設定されていれば、サードパーティのNVAを使用することができます。 なお、この設定はAzure Firewallのみでテストしていますが、他のサードパーティ製アプライアンスを使用しているお客様もいらっしゃいます。 アプライアンスはオンプレミスではなく、クラウド上に展開するのが理想的です。

Azure Databricksと同じ仮想ネットワークにファイアウォールのサブネットを持つことはできますか？

はい、できます。 Azureのリファレンスアーキテクチャによると、将来に向けてより良い計画を立てるためには、ハブ・スポーク型の仮想ネットワークトポロジーを使用することが推奨されます。 Azure FirewallのサブネットをAzure Databricksのワークスペースのサブネットと同じ仮想ネットワークに作成する場合は、上記のステップ6で説明したように、仮想ネットワークピアリングを構成する必要はありません。

Azure DatabricksのコントロールプレーンSCC Relay IpトラフィックをAzure Firewallでフィルタリングできますか？

可能ですが、あまりお勧めできません：

• Azure Databricksクラスタ（データプレーン）とSCC Relayサービス間のトラフィックは、Azureネットワーク上に留まり、パブリックインターネット上に流れることはありません。
• SCC Relayサービスとデータプレーンは、安定した信頼性の高い通信を行う必要がありますが、その間にファイアウォールや仮想アプライアンスがあると、ファイアウォールルールの設定ミスや予定されていたダウンタイムが発生した場合に、クラスタの起動に過度の遅延が発生したり（ファイアウォールの一時的な問題）、新しいクラスタを作成できなくなったり、ジョブのスケジューリングや実行に影響が出たりするなど、単一障害点が発生します。

Azure Firewallによって受け入れられた、またはブロックされたトラフィックを分析できますか？

このような要件には、Azure Firewall Logs and Metricsを使用することをお勧めします。

Azure Databricksを使用したデータ流出保護の開始

Azure Databricksのデプロイにデータ流出防止を実装するためのクラウドネイティブなセキュリティコントロールの活用について説明しました。 その他、このプロジェクトの一環として検討・実施した方がよいことがいくつかあります：

• データレイクの真の可能性を引き出すメタコントロールの有効化
• ノートブック機能へのアクセス管理
• 診断ログ、ストレージアクセスログ、NSGフローログですべてを監査（VNetインジェクションが必要です）

ご不明な点がございましたら、MicrosoftまたはDatabricksのアカウントチームまでお問い合わせください。