前回のブログでは、仮想ネットワークサービスエンドポイントまたはPrivate Linkを使用して、Azure DatabricksからAzureデータサービスに安全にアクセスする方法について説明しました。 この記事では、これらのベストプラクティスのベースラインを前提として、データの流出を防止するために、ネットワークセキュリティの観点からAzure Databricksのデプロイを強化する方法について、詳細な手順をウォークスルーします。
Wikipediaによるとデータ漏洩は、マルウェアや悪意のある行為者がコンピュータから不正なデータ転送を行うことで発生します。一般に、データ漏洩またはデータエクスポートとも呼ばれます。データ漏洩は、データ窃盗の一形態とも考えられています。2000年以降、多くのデータ漏洩が発生し、世界中の企業の消費者信頼、企業評価、知的財産、政府の国家安全保障に深刻な損害を与えました。 この問題は、企業が機密データ（PII、PHI、戦略的機密情報）をパブリッククラウドサービスで保管・処理するようになると、さらに重要性を増します。
PaaSサービスがデータの保存を要求したり、サービスプロバイダーのネットワーク内でデータを処理したりする場合、データ漏洩の解決は手に負えない問題になる可能性があります。 しかし、Azure Databricksを利用することで、お客様はAzureサブスクリプションにすべてのデータを保持し、Azure上で最も急速に成長しているデータ & AIサービスのPaaSの性質を維持しながら、独自のマネージドプライベート仮想ネットワークでデータを処理することができます。 私たちは、最もセキュリティ意識の高いお客様と協力しながら、プラットフォームの安全な展開アーキテクチャを考え出しました。
Databricksワークスペースの展開には、ネットワークの観点から3つの特徴があります。
どのオプションを選択しても、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デプロイの手順：
なぜワークスペースごとに2つのサブネットが必要なのですか？
ワークスペースには2つのサブネットが必要で、一般に「ホスト」（別名「パブリック」）と「コンテナ」（別名「プライベート」）と呼ばれています。 各サブネットは、ホスト（Azure VM）とVM内で実行されるコンテナ（Databricksランタイム、別名dbr）にIPアドレスを提供します。
パブリックまたはホストのサブネットにはパブリックIPアドレスがありますか？
いいえ、SCCと呼ばれるセキュアなクラスタ接続を使用してワークスペースを作成した場合、DatabricksのサブネットにはパブリックIPアドレスはありません。 ホストサブネットのデフォルト名がpublic-subnetになっているだけです。 SCCは、ネットワーク外からネッ トワークトラフィックが侵入しないようにします。 DatabricksワークスペースコンピュートインスタンスにSSH接続します。
デプロイ後にサブネットのサイズを変更できますか？
Databricksワークスペースがデプロイされると、Databricksネットワークのサブネットのサイズを変更することはできません。
| 項目 | 詳細 |
|---|---|
| 仮想ネットワーク | Azure Databricks Dataplane（VNetインジェクション）を展開するための仮想ネットワーク。 正しいCIDRブロックを選択してください。 |
| サブネット | 3つのサブネット ホスト（パブリック）、コンテナ（プライベート）、プライベートエンドポイントサブネット（ストレージ、DBFS、その他のAzureサービス用のプライベートエンドポイントを保持します。） |
| ルートテーブル | Databricksのサブネットからネットワークアプライアンス、インターネット、またはオンプレミスのデータソースへのアウトバウンドトラフィックをルーティングします。 |
| Azure Firewall | データ転送トラフィックを検査し、許可/拒否ポリシーに従ってアクションを実行します。 |
| プライベートDNSゾーン | 仮想ネットワーク内のドメイン名を管理および解決するための、信頼性が高くセキュアなDNSサービスの提供（利用できない場合は、展開の一部として自動的に作成可能） |
| Azure Key Vault | DBFS、マネージドディスク、マネージドサービスを暗号 化するためのCMK（顧客管理のキー）を格納します。 |
| Azure Databricksアクセスコネクタ | Unity Catalogを有効にする場合は必要です。 Unity Catalogに登録されたデータにアクセスする目的で、マネージドIDを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をクリックします。 いくつか注意すべきことがあります：
インバウンドルール
Worker to Worker Inboundルールは、クラスタのインスタンス間のトラフィックを許可します。
アウトバウンドルール
Azure Databricksは、デプロイプロセス中にデフォルトのBlobストレージ（別名ルートストレージ）を作成し、ログとテレメトリーの保存に使用します。 このストレージでパブリックアクセスが有効になっていても、このストレージに作成された拒否割り当てはストレージへの外部からの直接アクセスを禁止しています。 Azure Databricksのデプロイでは、プライベートエンドポイント（dfsとblobの両方）の作成により、ルートBlobストレージ（DBFS）へのセキュアな接続がサポートされるようになりましたが、DBFSのプライベートエンドポイントを有効にしてもパブリックアクセスはオフになりません。 なお、ストレージ用のプライベートエンドポイントには追加費用が発生します。
ベストプラクティスとして、アプリケーションデータをルートBlob（DBFS）ストレージに保存することは推奨されません。 Private Link（Azureデータサービスへのセキュアなアクセス）を使用してアプリケーション固有のデータを保存するために、独立したADLS Gen2 Storageを活用します。
ネットワーク仮想アプライアンス/ファイアウォールを介してこのようなデータサービスへのアクセスを設定することは、ビッグデータワークロードと中間インフラのパフォーマンスに悪影響を与える可能性があるため、お勧めしません。
注：アプリケーションデータは、外部のADLS Gen2ストレージに保存することを強くお勧めします。 同様のセットアップを行い、外部ADLSストレージ用のPrivate Linkエンドポイントを作成し、データを安全にアクセス/保存します。
このようなプライベートエンドポイントを追加サービス用に設定するには、関連するAzureドキュメントを参照してください。
Azure Firewallはスケーラブルなクラウドネイティブファイアウォールで、Azure Databricksワークスペースからアクセスを許可されたパブリックエンドポイントのフィルタリングデバイスとして機能します。
典型的な例では、ファイアウォールは中央集中型のハブVNetに配置され、複数のスポークVNetでピアリングされます。 スポークVNetはファイアウォール経由ですべてのトラフィックをアウトバウンドします。
Azure Firewallポリシーは、Azure Firewallのルールを作成するために推奨されるアプローチです。 Firewallポリシーは、複数のAzure Firewallインスタンスで使用できるグローバルリソースです。
以下のように、ネットワークルールとアプリケーションルールのコレクションを作成します。 アウトバウンドトラフィックがUDR経由の場合、アプリケーションルールはオプションであることに注意してください（次のセクションで説明します）。
注
FirewallポリシーをFirewallにアタッチします。
UDRとAzure Firewallポリシーでサービスタグを使用することは、管理を容易にするために推奨されますが、ここからワークスペースのAzure Databricksコントロールプレーンエンドポイントを活用できます。
この時点で、セキュアでロックダウンされた展開のためのインフラストラクチャのセットアップの大部分は完了しています。 次に、Azure DatabricksワークスペースのサブネットからコントロールプレーンとAzure Firewallに適切なトラフィックをルーティングする必要があります。
ルートテーブルを作成し、すべてのトラフィックを仮想アプライアンス（Azure Firewall）に転送します。
最後に、仮想ネットワークazuredatabricks-spoke-vnetと hub-vnetをピアリングして、先に設定したルートテーブルが正しく動作するようにする必要があります。 ドキュメントに従って、ハブとスポークネットワーク間のVNetピアリングを設定します。
これでセットアップは完了です。
最後のステップに入りました。 次に、ワークスペースをUnity Catalogに割り当てます。
展開結果を検証します：
データアクセスが問題なく動作していれば、サブスクリプションにおけるAzure Databricksの最適なセキュアなデプロイが達成されたことになります。 これはかなりの手作業でしたが、一回限りのショーケースのためでした。 現実的には、ARMテンプレート、Azure CLI、Azure SDKなどを組み合わせて、このようなセットアップを自動化したいと思うでしょう：
はい、VNetインジェクションとともに保護できます。 サービスエンドポイントは、Azureバックボーンネットワーク上の最適化されたルートを通じて、Azureサービスへの安全で直接的な接続を提供します。 サービスエンドポイントは、外部Azureリソースへの接続を仮想ネットワークのみに保護するために使用できます。 サービスエンドポイントは、サービスエンドポイントを使用するAzureサービスのネットワークファイアウォールルールが適切に定義されている場合にのみ安全です。
いいえ、Databricksによって使用されるサブネットは、ネットワークインテントポリシーを使用してロックされます。 Azureネットワークインテントポリシーは、お客様が誤ってDatabricksで使用するサブネットを変更しないようにするための内部ネットワーク構造です。
はい、この記事で説明したようにネットワークトラフィックルールが設定されていれば、サードパーティのNVAを使用することができます。 なお、この設定はAzure Firewallのみでテストしていますが、他のサードパーティ製アプライアンスを使用しているお客様もいらっしゃいます。 アプライアンスはオンプレミスではなく、クラウド上に展開するのが理想的です。
はい、できます。 Azureのリファレンスアーキテクチャによると、将来に向けてより良い計画を立てるためには、ハブ・スポーク型の仮想ネットワークトポロジーを使用することが推奨されます。 Azure FirewallのサブネットをAzure Databricksのワークスペースのサブネットと同じ仮想ネットワークに作成する場合は、上記のステップ6で説明したように、仮想ネットワークピアリングを構成する必要はありません。
可能ですが、あまりお勧めできません：
このような要件には、Azure Firewall Logs and Metricsを使用することをお勧めします。
Azure Databricksのデプロイにデータ流出防止を実装するためのクラウドネイティブなセキュリティコントロールの活用について説明しました。 その他、このプロジェクトの一環 として検討・実施した方がよいことがいくつかあります：
ご不明な点がございましたら、MicrosoftまたはDatabricksのアカウントチームまでお問い合わせください。
