Azure Databricksのサーバーレス環境からAzure StorageやADLS Gen2などのAzureリソースへ安全に接続する場合、今後の基本方針はAzure Network Security Perimeter（NSP）を使って、リソース側の受信アクセスを一元管理することです。特に、従来のサブネットIDやIPアドレス許可リストに依存している環境では、NSPへの移行可否と設定状況を早めに確認する必要があります。Microsoft Learnの公式情報では、Azure DatabricksサーバーレスからAzureリソースへのアクセス制御にNSPを使う手順、AzureDatabricksServerlessサービスタグの利用、Transition modeでの検証、診断ログによる確認が整理されています。(Microsoft Learn)
今回のポイントは、単に「新しいネットワーク設定が追加された」という話ではありません。2026年4月7日以降、Azure Databricksサーバーレスでサービスエンドポイントを構成するにはAzure Network Security Perimeterが必要とされており、従来のサーバーレス向けファイアウォール構成も2026年6月9日以降は利用できなくなるため、既存環境では移行計画が実務上の課題になります。(Microsoft Learn)
Azure Network Security Perimeterとは何か
Azure Network Security Perimeter（NSP）は、仮想ネットワークの外側にあるAzure PaaSリソースに対して、論理的なネットワーク境界を作るAzureの機能です。Azure StorageやAzure Key VaultなどのPaaSリソースをNSPに関連付けることで、パブリックアクセスを明示的な受信・送信ルールで制御できます。目的は、不要な外部アクセスや意図しないデータ流出を減らしつつ、複数リソースのネットワーク制御をまとめて扱いやすくすることです。(Microsoft Learn)
NSPは、従来のNSGやVNet内のルーティング制御とは役割が異なります。NSGは主に仮想ネットワーク上の通信を制御しますが、NSPはPaaSリソースのパブリックアクセス境界を管理します。そのため、Azure Databricksサーバーレスのように、Databricks管理側のコンピュートから自社のAzure Storageへアクセスする構成では、Databricks側だけでなく、接続先リソース側のNSP設定が重要になります。
NSPを構成する主な要素は次のとおりです。
| 要素 | 役割 | 実務での見方 |
|---|---|---|
| Network Security Perimeter | 論理的なセキュリティ境界 | 部門、環境、本番・検証などの単位で設計する |
| Profile | アクセスルールのまとまり | 同じアクセス要件を持つリソース群に適用する |
| Access rule | 受信・送信の許可ルール | Databricksサーバーレスを許可するルールなどを定義する |
| Resource association | PaaSリソースとNSPの関連付け | StorageアカウントなどをNSPプロファイルに参加させる |
| Diagnostic settings | ログと監査 | 許可・拒否・フォールバックの確認に使う |
今回の公式情報で押さえるべき変更点
Azure Databricks向けの公式手順では、サーバーレスコンピュートからAzureリソースへアクセスするために、AzureポータルでNSPを作成し、対象リソースをNSPプロファイルに関連付け、AzureDatabricksServerless.[リージョン] のサービスタグを受信アクセスルールに追加する流れが示されています。(Microsoft Learn)
管理者が特に確認すべき変更点は次のとおりです。
| 確認項目 | 変更・ポイント | 影響を受けやすい環境 |
|---|---|---|
| サービスエンドポイント構成 | 2026年4月7日以降、構成にはNSPが必要 | DatabricksサーバーレスからStorageへサービスエンドポイント経由で接続する環境 |
| 従来のファイアウォール構成 | レガシー機能は2026年6月9日以降利用不可 | NCCやサブネット許可リストでStorageアクセスを制御している環境 |
| 許可対象の指定方法 | 個別IPやサブネットIDではなく、サービスタグを使う設計へ | DatabricksのIP変更に追従する運用をしていた環境 |
| 推奨されるタグ | グローバルタグよりリージョン別タグを優先 | 単一リージョンのDatabricksワークスペース |
| アクセスモード | 多くのDatabricksサーバーレス用途ではTransition modeが推奨 | 既存ファイアウォールルールやサービスエンドポイントと併用する環境 |
ここで重要なのは、NSPを導入しても、いきなり既存のファイアウォール設計をすべて置き換える必要はないという点です。Azure Databricksの公式手順では、対象リソースをまずTransition modeでNSPに関連付け、NSPルールが一致しない場合は既存のリソースファイアウォールへフォールバックする形で検証する流れが示されています。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
Azure Network Security Perimeterの設定は、ネットワーク管理者だけの作業ではありません。Azure Databricks管理者、データエンジニア、セキュリティ担当、FinOps担当がそれぞれ確認すべきポイントがあります。
| 担当者 | 確認すべきこと | 見落とすと起きる問題 |
|---|---|---|
| Azureネットワーク管理者 | NSP、Profile、受信ルール、診断設定の設計 | 許可漏れによりサーバーレスジョブがStorageへ接続できない |
| Azure Databricks管理者 | サーバーレスSQLウェアハウス、ジョブ、ノートブック、Model Servingなどの利用状況 | 一部のワークロードだけ移行対象から漏れる |
| データエンジニア | ADLS Gen2のパス、Unity Catalog外部ロケーション、ETLジョブの接続先 | 本番ジョブで読み取り・書き込みエラーが発生する |
| セキュリティ担当 | Transition modeのログ、許可・拒否の証跡、Enforced mode移行可否 | 既存の許可ルールに依存した通信を把握できない |
| FinOps担当 | ワークスペースとStorageのリージョン、クロスリージョン通信 | 不要なデータ転送料金が発生する |
Azure Databricksの対象ワークロードとしては、サーバーレスSQLウェアハウス、ジョブ、ノートブック、Lakeflow Spark Declarative Pipelines、Model Servingエンドポイントからのアクセスが挙げられています。(Microsoft Learn)
一方で、AzureDatabricksServerlessサービスタグのNSP受信ルールについては、公式情報でAzure Storage（ADLS Gen2を含む）を対象にした説明が中心です。Storage以外のPaaSリソースを含める場合は、対象サービスがNSPにオンボードされているか、プレビュー扱いではないか、個別サービスの制限がないかを必ず確認してください。NSP全体としては、Storage、Key Vault、Event Hubs、Service Busなど複数サービスが対応していますが、Cosmos DB、SQL DB、Azure OpenAI Serviceなどは公開プレビューとして扱われる項目があります。(Microsoft Learn)
Azure Databricks向けNSP設定の基本手順
Azure DatabricksサーバーレスからAzureリソースへアクセスさせる場合、作業は大きく4段階に分かれます。公式手順はAzureポータルでの操作を前提にしています。(Microsoft Learn)
事前に確認する権限とリージョン
設定前に、次の条件を確認します。
| 確認項目 | 必要な内容 |
|---|---|
| Databricks側の権限 | Azure Databricksアカウント管理者であること |
| Azureリソース側の権限 | 対象リソースに対するContributorまたはOwner権限 |
| NSP作成権限 | AzureサブスクリプションでNSPリソースを作成できること |
| リージョン | Databricksワークスペースと対象Azureリソースを同一リージョンにそろえることが望ましい |
同一リージョンを推奨する理由は、パフォーマンスとコストです。公式情報では、ワークスペースとAzureリソースを同じリージョンに配置することで、最適な性能を得やすく、リージョン間データ転送料金を避けやすいとされています。(Microsoft Learn)
NSPとプロファイルを作成する
Azureポータルで「Network security perimeters」を検索し、NSPを作成します。作成時には、サブスクリプション、リソースグループ、NSP名、リージョン、プロファイル名を指定します。
ここで注意したいのは、NSPのリージョンです。Databricksワークスペース、対象Storageアカウント、NSPのリージョンがずれていると、アクセス制御だけでなくコストや設計の複雑さにも影響します。最初の設計では、原則として「同じリージョンのDatabricksワークスペースとStorageを1つの単位」として考えると整理しやすくなります。
作成後は、NSPプロファイルのResource IDを控えておきます。Azure CLIやAPIで関連付けを行う場合、このプロファイルIDが必要になります。
対象リソースをTransition modeで関連付ける
次に、Azure DatabricksサーバーレスからアクセスしたいStorageアカウントなどのAzureリソースを、NSPプロファイルに関連付けます。公式手順では、リソースの関連付け後、Access Mode列がTransitionになっていることを確認するよう案内されています。Transition modeは既定のモードです。(Microsoft Learn)
Transition modeでは、まずNSPルールが評価されます。該当するNSPルールがなければ、既存のリソースファイアウォールルールにフォールバックします。つまり、既存通信をすぐに止めずに、NSPルールでどの通信が許可されるかを段階的に確認できます。
Databricksサーバーレス用の受信アクセスルールを追加する
NSPプロファイルに、Azure Databricksサーバーレスからの受信アクセスを許可するルールを追加します。設定の要点は次のとおりです。
| 項目 | 設定例 | 判断基準 |
|---|---|---|
| Rule name | allow-databricks-serverless | 後から用途が分かる名前にする |
| Source Type | Service Tag | IPアドレスの手動管理を避ける |
| Allowed Sources | AzureDatabricksServerless.EastUS2 など | 原則はワークスペースのリージョン別タグを使う |
| グローバルタグ | AzureDatabricksServerless | 複数リージョンからのアクセスが本当に必要な場合に限定する |
Databricksは、露出範囲を抑えるためにリージョン別サービスタグの利用を推奨しています。リージョン別タグには、対象リージョンのサービスエンドポイントIPとAzure Databricks NAT IPが含まれ、タグは自動更新されるため、IP範囲の追加に合わせて手動更新する運用を減らせます。(Microsoft Learn)
サーバーレスから実際にアクセスをテストする
設定後は、Azure Databricksワークスペースのサーバーレス環境から、対象リソースへアクセスできるかを確認します。ADLS Gen2上のDeltaテーブルを読む場合、公式手順では次のようなクエリ例が示されています。(Microsoft Learn)
SELECT * FROM delta.`abfss://[email protected]/path/to/data` LIMIT 10;クエリが成功すれば、少なくともそのパスに対するサーバーレスからのアクセスは機能しています。ただし、読み取りだけで確認を終えるのは不十分です。本番ジョブで書き込み、MERGE、DELETE、チェックポイント作成、Auto Loader、モデル推論時の参照などを行っている場合は、実際の処理に近いテストケースで確認してください。
Transition modeとEnforced modeの使い分け
NSPには、Transition modeとEnforced modeがあります。一般的なNSPの考え方では、Transition modeで既存アクセスパターンを把握した後、Enforced modeへ移行して明示的に許可されない通信をブロックする設計が想定されます。(Microsoft Learn)
ただし、Azure Databricksサーバーレス向けの公式手順では、多くのユースケースでTransition modeを継続することが推奨されています。理由は、Enforced modeにするとリソースファイアウォールルールがバイパスされ、NSPルールに一致しないトラフィックがブロックされるためです。これはAzure Databricksだけでなく、既存のリソースファイアウォールで許可していた他サービスにも影響します。(Microsoft Learn)
| モード | 動作 | Databricksサーバーレスでの判断 |
|---|---|---|
| Transition mode | NSPルールを先に評価し、一致しなければ既存ファイアウォールへフォールバック | 既存構成と併用しながら検証する場合に適している |
| Enforced mode | NSPルールに一致しない通信をブロックし、既存ファイアウォールをバイパス | 他サービスの通信まで洗い出せている場合のみ慎重に検討する |
実務では、まずTransition modeでログを取り、Databricksサーバーレス、クラシッククラスター、バックアップ、運用監視、外部連携などの通信がどのルールで許可されているかを確認します。Enforced modeへの切り替えは、通信棚卸しと影響確認を終えてから判断すべきです。
レガシー構成から移行する場合の注意点
従来のAzure Databricksサーバーレス向けファイアウォール構成は、Network Connectivity Configuration（NCC）を使ってネットワークIDやサブネット情報を許可リストに追加する考え方でした。公式情報では、このレガシー機能は2026年6月9日以降利用できなくなるため、新しいNetwork Security Perimeter機能へ移行する必要があるとされています。(Microsoft Learn)
移行時は、次の順序で進めるとリスクを抑えやすくなります。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 現状把握 | Storageアカウントのネットワーク設定、許可済みVNet、サブネット、IP、NCC利用有無を一覧化 | どのDatabricksワークスペースがどのStorageを使うか |
| 設計 | リージョン単位でNSPとプロファイルを設計 | グローバルタグを安易に使わない |
| 検証 | 対象StorageをTransition modeでNSPに関連付け | 既存ジョブを止めずにログを確認 |
| ルール追加 | AzureDatabricksServerless.[リージョン] を受信ルールに追加 | ワークスペースリージョンと一致しているか |
| 動作確認 | 読み取り、書き込み、バッチ、スケジュールジョブをテスト | 成功・失敗だけでなくログも確認 |
| 切替判断 | 古い許可リストの削除可否を検討 | クラシックコンピュートや他サービスへの影響を確認 |
移行で失敗しやすいのは、「Databricksサーバーレスのアクセスだけを見て、クラシックコンピュートや他のAzureサービスのアクセスを見落とす」ケースです。たとえば、同じStorageアカウントに対してクラシッククラスター、Azure Data Factory、バックアップ、監視ツールがアクセスしている場合、NSP側の設計を誤ると一部の処理だけが失敗します。
診断ログで確認すべきポイント
NSPを設定したら、Azureリソース側で診断設定を有効にし、接続試行がNSPルールで許可されたのか、既存ファイアウォールへフォールバックしたのかを確認します。Azure Storageの場合、公式手順ではStorageReadやStorageWriteなどのログカテゴリを選び、Log Analyticsワークスペース、Storageアカウント、Event Hubなどへ送る方法が示されています。(Microsoft Learn)
ログ確認では、次の観点を見ます。
| 観点 | 確認内容 |
|---|---|
| 許可された通信 | DatabricksサーバーレスからのアクセスがNSPルールに一致しているか |
| フォールバック通信 | 既存ファイアウォールに依存している通信が残っていないか |
| 拒否された通信 | 本来許可すべきジョブやアプリの通信が拒否されていないか |
| 時間帯 | 夜間バッチ、週次処理、月次処理の通信も確認したか |
| 操作種別 | 読み取りだけでなく書き込みや削除系の処理も確認したか |
本番環境では、1回の手動クエリが成功しただけで完了と判断しないことが重要です。ジョブのスケジュール、ピーク時間帯、障害時のリトライ、メンテナンス処理まで含めてログを確認すると、切り替え後のトラブルを減らせます。
Storageアカウントで特に注意すべき制限
Azure Databricksサーバーレスの接続先としてADLS Gen2やBlob Storageを使っている場合、Storage側のNSP制限も確認が必要です。公式情報では、StorageアカウントがNSPに関連付けられている場合の制限として、Blobのオブジェクトレプリケーション、NFS・SMB・SFTPなどHTTPS以外のアクセス、Azure Backup、Static Websiteなどに関する注意点が示されています。(Microsoft Learn)
| 項目 | 注意点 | 対応方針 |
|---|---|---|
| オブジェクトレプリケーション | 送信元または送信先がNSPに関連付けられているとサポート対象外になる場合がある | レプリケーションを使うStorageはNSP適用前に確認する |
| NFS・SMB・SFTP | HTTPS以外のプロトコルはブロック対象になり得る | 該当プロトコルを使うStorageは慎重に切り分ける |
| Azure Backup | StorageアカウントでNSP利用時の制限がある | バックアップ対象Storageは事前検証を必須にする |
| Static Website | NSPとの併用がサポートされないシナリオがある | 静的Webサイト用途のStorageは別設計にする |
| CMK | Key Vaultへアクセスできる必要がある | StorageとKey VaultのNSP設計をセットで確認する |
特にCMKを使っている場合、StorageだけをNSPに入れても、関連するKey Vaultへのアクセスが成立しなければ暗号化キーの参照に問題が出る可能性があります。Storage、Key Vault、Databricksの関係を個別リソースではなく、ひとつのデータ基盤として確認してください。
Private Linkやネットワークポリシーとの違い
NSPはPrivate Linkの代替ではありません。NSPはPaaSリソースのパブリックアクセス境界を制御する機能であり、Private Endpoint経由の通信はNSPルールの対象外として扱われます。Private Linkを使う場合は、パブリックエンドポイントを使わないプライベート接続として別途設計します。(Microsoft Learn)
また、Azure Databricksにはサーバーレスエグレス制御やネットワークポリシーの考え方もあります。ネットワークポリシーでは、サーバーレスワークロードのアウトバウンド接続を制御し、制限モードではUnity Catalog外部ロケーションや明示的に定義したFQDN、Storageなどへ接続先を絞れます。(Microsoft Learn)
整理すると、役割は次のように分かれます。
| 機能 | 主な役割 | 使う場面 |
|---|---|---|
| Network Security Perimeter | Azure PaaSリソース側のパブリックアクセス境界を制御 | DatabricksサーバーレスからStorageなどへのアクセスを許可する |
| Private Link | プライベートエンドポイント経由でPaaSへ接続 | パブリックエンドポイントを避けたい高セキュリティ環境 |
| Databricksネットワークポリシー | サーバーレスワークロードの送信先を制御 | インターネットや外部サービスへのエグレスを制限したい環境 |
| Storageファイアウォール | Storage単体のネットワーク制御 | 既存構成との互換性確認やTransition modeのフォールバック先 |
展開時によくある失敗と回避策
NSP導入では、設定そのものよりも設計判断で失敗するケースが多くあります。
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| いきなりEnforced modeにする | 既存ファイアウォールで許可していた通信が止まる | まずTransition modeでログを確認する |
| グローバルサービスタグを安易に使う | 許可範囲が必要以上に広くなる | 単一リージョンではリージョン別タグを使う |
| Storageだけを見てKey Vaultを忘れる | CMK利用時にキー参照で問題が出る | 暗号化、バックアップ、監視まで依存関係を棚卸しする |
| 読み取りテストだけで完了する | 書き込みやバッチ処理で後から失敗する | 本番ジョブと同じ処理で検証する |
| レガシー許可リストをすぐ削除する | クラシッククラスターや他サービスが接続できなくなる | ログで通信元を確認してから段階的に整理する |
| クロスリージョンを放置する | 余計なデータ転送料金や遅延が発生する | ワークスペースとStorageを同一リージョンに寄せる |
NSPは「設定すれば安全になる」機能ではなく、「許可すべき通信を可視化し、段階的に絞り込む」ための機能です。特にDatabricksのように、複数のワークロードが同じStorageを参照する環境では、通信経路の棚卸しが成功の鍵になります。
管理者と開発者が今すぐ確認すべきチェックリスト
まずは、次のチェックから始めてください。
| チェック | 対象 | 完了の目安 |
|---|---|---|
| Databricksサーバーレス利用状況を確認 | SQLウェアハウス、Jobs、Notebooks、Model Serving | 対象ワークロード一覧がある |
| 接続先Storageを一覧化 | ADLS Gen2、Blob Storage | ワークスペース別・リージョン別に整理されている |
| レガシー構成の有無を確認 | NCC、サブネット許可リスト、Storageファイアウォール | 移行対象が明確になっている |
| NSPを検証環境で作成 | NSP、Profile、Resource association | Transition modeで関連付け済み |
| 受信ルールを追加 | AzureDatabricksServerless.[リージョン] | グローバルタグを使う理由が説明できる |
| 診断ログを有効化 | StorageRead、StorageWriteなど | 許可・拒否・フォールバックを確認できる |
| 本番相当テストを実行 | 読み取り、書き込み、定期ジョブ | 実際の業務処理で成功している |
| Enforced modeの可否を判断 | 他サービス、バックアップ、Key Vault依存 | 影響範囲が文書化されている |
まとめ：まずはTransition modeで可視化し、移行期限から逆算する
Azure DatabricksサーバーレスからAzureリソースへ接続する環境では、Azure Network Security Perimeterを前提にしたアクセス制御へ移行する流れが明確になっています。特に、サービスエンドポイントを使う構成や、従来のサーバーレス向けファイアウォール機能に依存している環境では、設定確認を後回しにしない方が安全です。
最初にやるべきことは、Databricksサーバーレスの利用ワークロードと接続先Storageを一覧化することです。次に、検証環境でNSPを作成し、対象リソースをTransition modeで関連付け、リージョン別のAzureDatabricksServerlessサービスタグを追加します。そのうえで、診断ログを見ながら既存ファイアウォールへのフォールバックや拒否通信を確認してください。
本番展開では、Enforced modeへの切り替えを急ぐより、まずはTransition modeで通信を可視化し、レガシー構成からの移行計画を作ることが現実的です。2026年6月9日のレガシー機能終了に該当する環境では、検証、ログ確認、関係部門レビュー、本番反映までの期間を逆算して進めましょう。
コメント