13
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nakazax(Hiroyuki Nakazato)inデータブリックス・ジャパン株式会社

【NCCディープダイブ】Azure Databricksのサーバーレスのネットワークセキュリティ

13
Last updated at Posted at 2024-04-19

はじめに

本記事では、Azure DatabricksのサーバーレスコンピュートからユーザーのAzureリソースへのネットワークセキュリティについて、Azure Network Security Perimeter (NSP) を使ったストレージアカウントのファイアウォール設定と、ネットワーク接続構成（略称NCC） を使ったプライベートリンク設定の概要を、アカウントコンソールやAzureポータルの設定画面のキャプチャを交えながら紹介していきます。

まずは主な更新情報を紹介した後、Azure Databricksのサーバーレスの概要を軽く振り返り、それからNCCとNSPにディープダイブしていきましょう。

本記事のカバー範囲について

本記事ではAzure Databricksにフォーカスして記載します。Databricks on AWSおよびDatabricks on Google Cloudについては本記事ではカバーしません。

主な更新情報

本記事の内容に関連する主な更新情報をお知らせします。

NCCファイアウォールが対応するサーバーレスの種類が拡大（2024年5月）

2024年5月31日のリリースノートで、NCCファイアウォールが、SQLに加えて以下のサーバーレスコンピュートタイプをサポートすることが発表されました。

  • SQL（従前からサポート）
  • ノートブック
  • ジョブ
  • Lakeflow Declarative Pipelines（旧Delta Live Tables）
  • モデルサービング

NCCプライベートリンクが対応するAzureサービスの種類が拡大（2024年11月）

2024年11月21日に、NCCプライベートリンクのアップデートが発表され、以下のサーバーレスコンピュートから、Azure Private Linkに対応する60以上のAzureの1stパーティサービスへの接続が可能になりました。

  • SQL
  • ノートブック
  • ジョブ
  • Lakeflow Declarative Pipelines（旧Delta Live Tables）
  • モデルサービング

ストレージアカウントFWがNSP + Service Tag方式に移行（2026年1月）

2026年1月に、ストレージアカウントのファイアウォール設定における接続方式が、従来のNCC + サブネットID方式からAzure Network Security Perimeter (NSP) + AzureDatabricksServerless Service Tag方式に変更されることが発表されました。従来方式（サブネットID方式）は2026年4月7日にEnd of Lifeとなり、それまでにNSP方式への移行が必要です。

NSP方式では、AzureDatabricksServerless Service Tagを使うことで、個別のサブネットIDを管理する必要がなくなり、運用負荷が大幅に軽減されます。本記事の「ストレージアカウントのファイアウォール設定の流れ（NSP + Service Tag方式）」セクションもNSP方式の手順に更新しています。

※プライベートリンクのみを利用している場合はこの移行の影響を受けません。

サーバーレスの概要

ここではNCCの前提知識として、Azure Databricksのサーバーレスの概要を簡単に振り返ります。

サーバーレスのリリース状況

2023年から、Azure Databricksのサーバーレス機能がどんどん強化されています。現在は、SQLウェアハウス、ノートブック、ジョブ、パイプライン（Lakeflow Declarative Pipelines） のサーバーレスコンピュートが東日本リージョンを含む多くのリージョンで利用可能になっています。

各リージョンへの最新の展開状況は、以下のページをご覧ください（日本語版に反映されるのに若干のタイムラグがあるため英語版をご覧頂くのがおすすめです）。

サーバーレスのメリット

サーバーレスのメリットについて、以下のデータブリックス新井さんの記事に分かりやすくまとまっています。端的には、圧倒的な起動時間の短さ、性能およびコストパフォーマンスの高さがサーバーレスのメリットです。

サーバーレスはAzure Databricksがコンピューティングを完全に管理

サーバーレスの特徴の一つとして、クラスターやウェアハウスといった「コンピュート（計算資源）」の実行される場所が従来とは異なる点が挙げられます。従来型（クラシックコンピューティングプレーン）では、ユーザーのAzureサブスクリプションのVNet内でコンピュートが実行されます。一方サーバーレスは、Azure Databricksによって管理されるサーバーレスコンピューティングプレーンでコンピュートが実行されます。

image.png

出典：サーバーレス コンピューティング プレーン ネットワーキング - Azure Databricks | Microsoft Learn

上記の図の2番：サーバーレスコンピュートとAzure Storageなどのユーザーリソース間のネットワークセキュリティについて、ストレージアカウントのファイアウォールにはAzure Network Security Perimeter (NSP) + Service Tag方式を、プライベートリンク接続にはネットワーク接続構成（NCC） を使って管理します。

なお、上記の図の1番：ユーザー & アプリとコントロールプレーン間のネットワークセキュリティは、IPアクセスリストやPrivate Linkで保護できます。本記事では詳しく触れませんが、以下のDatabricksブログや私が以前作成したスライドに詳細がまとまっていますので、ご興味ある方はご覧ください。

Databricksセキュリティ & トラストセンター

サーバーレス全般のセキュリティについてご興味がある方は以下のDatabricksセキュリティ & トラストセンターをご覧ください。サーバーレスのページについて日本語でサマリーしたスライドも合わせてご覧頂くと良いと思います。

NCCの概要

ここからNCCの深掘りをしていきます。まずは、NCCの概要について見ていきましょう。正確な定義については以下のドキュメントに譲るとして、本記事では誤解を恐れずに分かりやすさを優先して記載します。

本記事の情報は古くなる可能性があります

なるべく最新化に努めたいとは思っていますが、本記事の情報が公式よりも古くなる可能性があります。特に制限周りの各種の数字について変更されるかもしれません。NCCを利用の際には必ず公式のドキュメントも合わせてチェックしてください。

NCCとは？

ネットワーク接続構成（NCC）は、複数のAzure DatabricksワークスペースのサーバーレスコンピュートからユーザーのAzureサブスクリプションにあるAzure Storageなどのリソースへのネットワークセキュリティをアカウントレベルで一元的に管理するための機能です。

サーバーレスコンピュートのネットワークセキュリティオプション

ユーザーが管理するAzureリソースに対して、以下2つの方式でネットワークセキュリティを適用できます。

1. ストレージアカウントのファイアウォール（NSP + Service Tag方式）

Azure Network Security Perimeter (NSP) と AzureDatabricksServerless Service Tagを使って、サーバーレスコンピュートからのサービスエンドポイント経由のアクセスを許可し、接続元を制限します。以下のサーバーレスコンピュートタイプをサポートしています。

  • SQL
  • ワークフロー
  • ノートブック
  • Lakeflow Declarative Pipelines（旧Delta Live Tables）
  • モデルサービング

NSP方式では、ストレージアカウントをNSPに関連付け、AzureDatabricksServerless Service Tagのインバウンドアクセスルールを追加するだけで設定が完了します。個別のサブネットIDを管理する必要がなく、Azure Databricksがサービスエンドポイントを追加した場合もルールの更新は不要です。

※従来はNCCの静的サブネットID群をストレージアカウントのファイアウォールに直接登録する方式でしたが、この方式は2026年4月7日にEnd of Lifeとなります。詳しくは「ストレージアカウントのファイアウォール設定の流れ（NSP + Service Tag方式）」セクションをご覧ください。

2. プライベートリンク（NCC経由）

NCCのプライベートエンドポイントルールを使って、以下のサーバーレスコンピュートからAzure Private Linkに対応する60以上のAzureサービスに接続できます。

  • SQL
  • ジョブ
  • ノートブック
  • Lakeflow Declarative Pipelines（旧Delta Live Tables）
  • モデルサービング

主な接続先サービスには以下が含まれます。

  • Azure Storage（Blob Storage、ADLS Gen2）
  • Azure SQL Database
  • Azure OpenAI
  • Azure Key Vault
  • Azure Event Hubs
  • Azure Service Bus
  • その他のAzure Private Link対応サービス

両者の違いについては以下の図をご覧ください。

以前から何が変わったの？

プライベートリンクのサポートは2024年4月に新しく始まったものです。ストレージアカウントのファイアウォールについては、以下のように方式が変遷してきました。

2023年10月以前（ドキュメント公開方式）: DBSQLサーバーレスが経由するサービスエンドポイントのサブネットID群をドキュメントで公開しており、それらのサブネットID群をストレージアカウントのファイアウォールに追加する方式でした。ただ、この方式だと、将来的にサブネットIDの追加や変更が発生した場合に、ユーザーがドキュメントを見て、ストレージアカウントのファイアウォールに反映するという作業が必要になってしまいます（そもそもどうやってユーザーが変更に気付くのかという問題もあります）。

image.png
以前のドキュメントで公開していたサブネットID群（以下の永田さんのQiita記事より）

2023年10月〜2026年4月（NCC静的サブネットID方式）: NCC作成時に、サーバーレスコンピューティングが経由するサービスエンドポイントの「静的な」サブネットID群が設定されるようになりました。ユーザーはそれらのサブネットID群を一度だけストレージアカウントのファイアウォールに追加すれば良くなり、利便性が向上しました。ただし、この方式は2026年4月7日にEnd of Lifeとなります。

2026年1月〜（NSP + Service Tag方式）: Azure Network Security Perimeter (NSP) と AzureDatabricksServerless Service Tagを使った方式に移行しました。NCCの作成やサブネットIDの管理が不要になり、運用負荷が大幅に軽減されています。

NCCへのアクセス方法

GUI、REST API、Databricks CLI、Terraformによるアクセスが可能です。

GUIアクセス

Azure Databricksのアカウントコンソール (https://accounts.azuredatabricks.net) の[クラウドリソース] > [ネットワーク接続構成]でNCCの編集・閲覧ができます。

image.png

REST APIアクセス

以下のAPIリファレンスを参照ください。

必要な権限

各方式に応じて、以下の権限を持っている必要があります。

NSP + Service Tag方式（ストレージアカウントFW）

  • NSPの作成・編集権限（Azureサブスクリプション側）
  • 対象のストレージアカウントのネットワーク設定の編集権限

プライベートリンク方式（NCC経由）

  • Azure Databricksアカウントのアカウント管理者ロール
    • NCCはアカウントレベルのリソースのため、ユーザーはアカウント管理者ロールを持っている必要があります
  • 対象のAzureリソースのプライベートエンドポイントの編集権限

Azure Databricksのアカウントコンソールを有効化しておらず、アカウント管理者ロールが存在しない場合は、以下のドキュメントを参考に設定してください。

制限事項

NSP + Service Tag方式

  • NSPのアクセスモードについて、DatabricksはTransitionモードのみを推奨しています。Enforcedモードに切り替えると、NSPルールに一致しないすべてのアクセスがブロックされるため、サービスエンドポイント経由のアクセスやクラシックコンピュートからの接続に影響が出る恐れがあります

NCC（プライベートリンク方式）

  • NCCをアタッチするワークスペースはPremiumプランの必要があります
  • 1つのNCCは最大で50個のワークスペースにアタッチできます
  • 1つのAzure Databricksアカウントはリージョンごとに最大で10個のNCCを持つことができます
  • 1つのAzure Databricksアカウントはリージョンごとに最大で100個のプライベートエンドポイントを作成でき、必要に応じて1から10個のNCCに分散できます

NCCの料金

NCCの料金体系は2024年12月4日に変更されました。

2024年12月4日以前

NCCは無料でご利用頂けました。ストレージアカウントのファイアウォール、プライベートリンクどちらのオプションを利用する場合も追加料金は発生しませんでした。

2024年12月4日以降

外部リソースに接続するサーバーレスワークロードのネットワークコストの課金が開始されます。以下の点に注意が必要です。

  • 課金は段階的に実施され、2024年12月4日以降も一定期間は課金されない場合があります
  • 課金が有効になる前の使用量に対して、さかのぼっての課金は発生しません
  • 課金が有効になった後は、以下の料金が発生する可能性があります。

  1. Private Link経由でのリソースへのプライベート接続

    • データ処理料金は無期限に免除
    • 時間単位の料金が適用

  2. NATゲートウェイ経由のリソースへのパブリック接続

    • 接続時の料金が発生

  3. リージョン間データ転送料金

    • サーバーレスコンピューティングとターゲットリソースが異なるリージョンにある場合など

ストレージアカウントのファイアウォール設定の流れ（NSP + Service Tag方式）

ここから実際にGUIを使ったストレージアカウントのファイアウォール設定の流れをウォークスルーしていきます。NSP + Service Tag方式では、NCCの作成やワークスペースへのアタッチは不要で、Azureポータル上でNSPの設定を行うだけで完了します。

従来方式（非推奨）：NCC + サブネットID方式の手順

従来方式は2026年4月7日にEnd of Lifeとなります。以下は参考のために残しています。

https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/serverless-firewall

旧ステップ1. NCCを追加（アカウントコンソール）

アカウントコンソール (https://accounts.azuredatabricks.net/) にアクセスし、左サイドバーの [クラウドリソース] > [ネットワーク接続構成] をクリックします。すると以下のような画面が表示されます。

image.png

画面右上にある [ネットワーク接続構成を追加] ボタンをクリックします。

image.png

任意の名前を入力、アタッチしたいワークスペースが存在するリージョンを選択し、[追加] をクリックします。

image.png

指定した名前でNCCが作成されます。

image.png

旧ステップ2. NCCの静的サブネットID群をコピー（アカウントコンソール）

作成したNCCをクリック、[デフォルトルール] タブにアクセスし [すべて表示]　リンクをクリックします。

image.png

静的なサブネットIDの一覧が表示されるので [サブネットをコピー] をクリックします。

image.png

以下がクリップボードにコピーされたサブネットIDの一覧の例です（あくまで例であり、NCCによってサブネットIDは異なる可能性があります）。各サブネットIDがカンマと半角スペースで区切られています。

この後、このサブネットID群をストレージアカウントのファイアウォールにスクリプトで追加していくのですが、その際にカンマがあるとエラーになりますので、テキストエディタなどに貼り付けてカンマを除去した上で、適当な名前で手元のPCに保存しておきましょう。

クリップボードにコピーされたサブネットIDの一覧の例（カンマと半角スペース区切り）
/subscriptions/23a8c420-c354-43f9-91f5-59d08c6b3dff/resourceGroups/prod-japaneast-snp-1-compute-4/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-4/subnets/worker-subnet, /subscriptions/31ef391b-7908-48ec-8c74-e432113b607b/resourceGroups/prod-japaneast-snp-1-compute-2/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-2/subnets/worker-subnet, /subscriptions/56beece1-dbc8-40ca-8520-e1d514fb2ccc/resourceGroups/prod-japaneast-snp-1-compute-8/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-8/subnets/worker-subnet, /subscriptions/653c13e3-a85b-449b-9d14-e3e9c4b0d391/resourceGroups/prod-japaneast-snp-1-compute-6/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-6/subnets/worker-subnet, /subscriptions/6c0d042c-6733-4420-a3cc-4175d0439b29/resourceGroups/prod-japaneast-snp-1-compute-3/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-3/subnets/worker-subnet, /subscriptions/8453a5d5-9e9e-40c7-87a4-0ab4cc197f48/resourceGroups/prod-japaneast-snp-1-compute-1/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-1/subnets/worker-subnet, /subscriptions/9d5fffc7-7640-44a1-ba2b-f77ada7731d4/resourceGroups/prod-japaneast-snp-1-compute-5/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-5/subnets/worker-subnet, /subscriptions/b4f59749-ad17-4573-95ef-cc4c63a45bdf/resourceGroups/prod-japaneast-snp-1-compute-10/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-10/subnets/worker-subnet, /subscriptions/b96a1dc5-559f-4249-a30c-5b5a98023c45/resourceGroups/prod-japaneast-snp-1-compute-7/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-7/subnets/worker-subnet, /subscriptions/d31d7397-093d-4cc4-abd6-28b426c0c882/resourceGroups/prod-japaneast-snp-1-compute-9/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-9/subnets/worker-subnet

旧ステップ3. NCCをワークスペースにアタッチ（アカウントコンソール）

アカウントコンソールの左サイドバーの [ワークスペース] をクリックし、NCCをアタッチするワークスペースの名前をクリックします。

image.png

[構成] タブが表示されるので右上の [ワークスペースを更新] ボタンをクリックします。

image.png

[ネットワーク接続構成] 欄に作成したNCCを設定し [更新] ボタンをクリックします。

image.png

以上でNCCのワークスペースへのアタッチは完了です。

image.png

（ドキュメントに以下の記述がありますので、念のため本記事にも転記しておきます）

  • 変更が有効になるまで10分待ちます
  • ワークスペースで実行中のサーバーレスのSQLウェアハウスをすべて再起動します

旧ステップ4. ストレージアカウントのファイアウォールを有効化（Azureポータル）

  • Azureポータル (https://portal.azure.com) にアクセスし、対象ストレージアカウントを選択し、[ネットワーク] をクリックします
  • [ファイアウォールと仮想ネットワーク] > [パブリックネットワーク アクセス]について [選択した仮想ネットワークとIPアドレスから有効] にチェックし [保存] をクリックします

image.png

旧ステップ5. ストレージアカウントのファイアウォールにNCCのサブネットID群を追加（Azure CLIなど）

Azure CLIやPowerShell、Terraform、または他のツールを使って、ストレージアカウントのファイアウォールにNCCのサブネットID群を追加します。

以下はAzure CLIを使って複数のサブネットID群をループして追加するスクリプトです。スクリプトを実行する前に以下の文字列を置き換える必要があります。

  • SUBNETSの値をカンマを除去したサブネットID群で置き換えます
  • --subscriptionの値を自身のAzureサブスクリプションIDに置き換えます
  • --resource-groupの値を対象のストレージアカウントが存在するリソースグループ名に置き換えます
  • --account-nameの値を対象のストレージアカウント名に置き換えます
スクリプト例
#!/bin/bash
SUBNETS=(/subscriptions/8453a5d5-9e9e-40c7-87a4-0ab4cc197f48/resourceGroups/prod-azure-eastusc3-nephos2/providers/Microsoft.Network/virtualNetworks/kaas-vnet/subnets/worker-subnet /subscriptions/8453a5d5-9e9e-40c7-87a4-0ab4cc197f48/resourceGroups/prod-azure-eastusc3-nephos3/providers/Microsoft.Network/virtualNetworks/kaas-vnet/subnets/worker-subnet)
for SUBNET in ${SUBNETS[@]}
do
  az storage account network-rule add --subscription 9999999-1ff3-43f4-b91e-d0ceb97111111 --resource-group mystorage-rg --account-name myaccount --subnet ${SUBNET}
done

コマンドの実行が完了したら、Azureポータルから対象のストレージアカウントの [ネットワーク] > [仮想ネットワーク] を確認します。以下のようにサブネットID群が追加されていればOKです。

image.png

なお、エンドポイント状態列の「アクセス許可が不十分です」という表示や、ネットワーク一覧の下の警告は無視してOKです。これらは、ユーザーがNCCのサブネットID群の読み取りアクセス許可を持っていないことを示しているだけであり、サーバーレスコンピュートからストレージアカウントへの接続を妨げるものではありません。

1. NSPを作成しストレージアカウントを関連付け（Azureポータル）

Azure Network Security Perimeter (NSP) を作成し、対象のストレージアカウントをTransitionモードで関連付けます。

1-1. NSPの作成

  • Azureポータル (https://portal.azure.com) にアクセスし、上部の検索ボックスで「ネットワークセキュリティ境界」（または「Network security perimeters」）と入力して選択します
  • [+ 作成] をクリックします
  • 以下の情報を入力します
    • サブスクリプション: 対象のAzureサブスクリプションを選択
    • リソースグループ: 既存のリソースグループを選択、または新規作成
    • 名前: NSPの名前を入力（例: databricks-nsp）
    • リージョン: Azure Databricksワークスペースおよびストレージアカウントと同じリージョンを選択
    • プロファイル名: プロファイル名を入力（例: databricks-profile）
  • [確認および作成] をクリックし、[作成] をクリックします

1-2. ストレージアカウントをNSPに関連付け（Transitionモード）

  • 作成したNSPに移動します
  • 左サイドバーの [設定] > [リソース] をクリックします
  • [+ 追加] > [既存のプロファイルにリソースを関連付ける] を選択します
  • ステップ1-1で作成したプロファイルを選択し、[関連付け] をクリックします
  • リソースの種類でフィルター（例: Microsoft.Storage/storageAccounts）し、対象のストレージアカウントを選択します
  • [関連付け] をクリックします

関連付け完了後、リソース一覧で対象のストレージアカウントのアクセスモード列が「Transition」になっていることを確認します。

Transitionモードについて

Transitionモードでは、まずNSPルールで評価し、一致するルールがない場合はストレージアカウントの既存のファイアウォールルールにフォールバックします。既存のアクセスパターンを維持しながらNSPの設定をテストできるため、安全に移行を進められます。

DatabricksはTransitionモードの使用を推奨しており、Enforcedモードへの切り替えは推奨されていません。Enforcedモードでは、NSPルールに一致しないすべてのアクセスがブロックされ、サービスエンドポイント経由のアクセスやクラシックコンピュートからの接続に影響が出る恐れがあります。

2. NSPアクセスルールにService Tagを追加（Azureポータル）

NSPプロファイルに AzureDatabricksServerless Service Tagを使ったインバウンドアクセスルールを追加します。

  • 作成したNSPに移動します
  • 左サイドバーの [設定] > [プロファイル] をクリックします
  • 対象のプロファイル（例: databricks-profile）を選択します
  • [設定] > [受信アクセス規則]（Inbound access rules）をクリックします
  • [+ 追加] をクリックします
  • 以下を入力します
    • ルール名: 分かりやすい名前を入力（例: allow-databricks-serverless）
    • ソースの種類: 「Service Tag」を選択
    • 許可されたソース: 「AzureDatabricksServerless」を選択
  • [追加] をクリックします

AzureDatabricksServerless Service Tagについて

AzureDatabricksServerless Service Tagは、Azure Databricksのサーバーレスコンピュートが使用するサービスエンドポイントを表す特別なIPアドレスにマッピングされています。このService Tagを使うことで、同一リージョンまたはペアリージョンのAzureストレージアカウントへの接続をカバーできます。

Service Tagは全リージョンのサーバーレスサービスエンドポイントを自動的にカバーしますが、リージョンをスコープすることも可能です。リージョン名をService Tag名に追加します（例: AzureDatabricksServerless.JapanEast）。DatabricksはワークスペースのリージョンにスコープしたService Tagの使用を推奨しています。

個別のサブネットIDを管理する必要がなくなり、Azure Databricksが新しいサービスエンドポイントを追加した場合もルールの更新は不要です。

非サーバーレスのクラスターやSQLウェアハウスからのアクセス許可について

ストレージアカウントのファイアウォールが「すべてのネットワークから有効」以外に設定されている場合、非サーバーレスのクラシックコンピュートからのアクセスも考慮が必要です。Azure Databricksワークスペースの2つのサブネット（通称 public-subnet と private-subnet）のIDをストレージアカウントの「仮想ネットワーク」セクションに追加してサービスエンドポイントを有効化してください。

上記を行わないと、非サーバーレスのクラスターやSQLウェアハウスから対象のストレージアカウントにアクセスできなくなります。

なお、サービスエンドポイントが利用できるのはVNetインジェクションされたAzure Databricksワークスペースである点に留意ください。

3. サーバーレスからストレージアカウントへの接続確認（ワークスペース）

対象のワークスペースにアクセスします。

タイプがサーバーレスのSQLウェアハウスがない場合、左サイドメニューの [SQLウェアハウス] > [SQLウェアハウスを作成]をクリックして作成します。接続確認が目的なので、クラスターサイズはXXSなどの小さなサイズでOKです。

image.png

左サイドメニューの [SQLエディタ] にアクセスし、対象のストレージアカウントにデータがあるテーブルに対してSELECTをクエリを実行します。結果が表示されれば接続確認は問題ありません。

image.png

ストレージアカウント側のネットワーク設定が上手く行えていない場合、以下のエラーメッセージが出力されます。その場合は前の手順に戻って見落としやミスがないかを確認してみてください。

image.png

エラーメッセージ例
This Azure storage request is not authorized. The storage account's 'Firewalls and virtual networks' settings may be blocking access to storage services. Please verify your Azure storage credentials or firewall exception settings.

NCCの設定の流れ：プライベートリンク

続いてNCCのプライベートリンクの設定手順をウォークスルーしていきます。ストレージアカウントのファイアウォールと手順的に被る部分についてはキャプチャを省略してサクサクいきたいと思います。

1. NCCを追加（アカウントコンソール）

  • アカウントコンソール (https://accounts.azuredatabricks.net/) にアクセスし、左サイドバーの [クラウドリソース] > [ネットワーク接続構成] をクリックします
  • 画面右上にある [ネットワーク接続構成を追加] ボタンをクリックします
  • 任意の名前を入力、アタッチしたいワークスペースが存在するリージョンを選択し、[追加] をクリックします

image.png

2. NCCをワークスペースにアタッチ（アカウントコンソール）

  • アカウントコンソールの左サイドバーの [ワークスペース] をクリックし、NCCをアタッチするワークスペースの名前をクリックします
  • [構成] タブが表示されるので右上の [ワークスペースを更新] ボタンをクリックします
  • [ネットワーク接続構成] 欄に作成したNCCを設定し [更新] ボタンをクリックします

image.png

（ドキュメントに以下の記述がありますので、念のため本記事にも転記しておきます）

  • 変更が有効になるまで10分待ちます
  • ワークスペースで実行中のサーバーレスのSQLウェアハウスをすべて再起動します

3. 対象のストレージアカウントのリソースIDをコピー（Azureポータル）

Azureポータル (https://portal.azure.com) にアクセスし、対象ストレージアカウントの [概要] ページの右上にある [JSONビュー] をクリックします。

image.png

上部にリソースIDが表示されるので、枠で囲んだアイコンをクリックしてリソースIDをコピーします。

image.png

4. プライベートエンドポイントルールを追加（アカウントコンソール）

  • アカウントコンソールの左サイドバーの [クラウドリソース] > [ネットワーク接続構成] にアクセスし、追加したNCCをクリックします
  • [プライベートエンドポイントルール] タブを開き、[プライベートエンドポイントルールを追加] ボタンをクリックします

image.png

[適用先AzureリソースのID] に先ほどコピーしたストレージアカウントのリソースIDを貼り付けます。

ADLS Gen2（階層型名前空間が有効なストレージアカウント。ワークスペースルートストレージもこれに該当します）を対象とする場合には、dfs と blob の両方のサブリソースに対してプライベートエンドポイントルールを作成、承認する必要があります。

image.png

[追加] ボタンが処理中を表す表示に変わるので、しばらく待ちます。（数十秒〜1分程度）

image.png

自動的に表示が切り替わり、プライベートエンドポイントルールが1件追加されます。ステータスが PENDING になっているはずです。

image.png

補足: Azureのサブリソース名

上記以外のAzureサービスのサブリソース名については、Azure Private Linkのドキュメントをご確認ください。

5. プライベートエンドポイント接続を承認（Azureポータル）

Azureポータルで対象のストレージアカウントにアクセスし、[ネットワーク] > [プライベート エンドポイント接続] タブを開きます。接続状態が 保留中 のプライベートエンドポイント接続が1件表示されるので、チェックボックスにチェックを入れて [承認] をクリックします。

image.png

必要に応じて説明を入力し（ブランクでもOK）、[はい] をクリックします。

image.png

しばらく待機し、接続状態が 承認済み になることを確認します。

image.png

アカウントコンソールのプライベートエンドポイントルールのステータスが ESTABLISHED になっていることを確認します。

image.png

6. （オプション）ストレージアカウントのパブリックネットワークアクセスを無効化（Azureポータル）

省略可能な手順です。対象のストレージアカウントへのアクセスについてプライベートエンドポイントに限定したい場合は、パブリックネットワークを 無効 に変更して保存します。

image.png

7. DBSQLサーバーレスからストレージアカウントへの接続確認（ワークスペース）

  • NCCをアタッチしたワークスペースにアクセスします
  • タイプがサーバーレスのSQLウェアハウスがない場合、左サイドメニューの [SQLウェアハウス] > [SQLウェアハウスを作成]をクリックして作成します。接続確認が目的なので、クラスターサイズはXXSなどの小さなサイズでOKです
  • 左サイドメニューの [SQLエディタ] にアクセスし、対象のストレージアカウントにデータがあるテーブルに対してSELECTをクエリを実行します。結果が表示されれば接続確認は問題ありません

image.png

NCCのウォークスルーは以上です。

Appendix

ここからは付録的な内容です。

NCCの設計（プライベートリンク利用時）

NSP + Service Tag方式ではNCCは不要ですが、プライベートリンクを利用する場合はNCCの設計が必要です。同じ部署内で同じリージョンのワークスペース間ではNCCを共有するなど、前述のNCCの制限を念頭に置きつつ、組織の実情に合わせて設計するのが良いでしょう。

ストレージアカウントへのアクセス制御の粒度

サーバーレスコンピュートからストレージアカウントへの通信は、NCCのアタッチ有無にかかわらず、認証や1時間の短命なトークンを使ったアクセス、暗号化などによって安全に保護されています。

NSP + Service Tag方式では、AzureDatabricksServerless Service Tagに含まれるすべてのサーバーレスコンピュートからのアクセスが許可されます。特定のワークスペースのサーバーレスコンピュートからのネットワークアクセスのみに限定したい場合には、NCCのプライベートリンクの利用を検討してください。

まとめ

本記事では、Azure DatabricksのサーバーレスコンピュートからユーザーのAzureリソースへのネットワークセキュリティについて、概要と設定手順を紹介しました。

サーバーレスコンピュートからAzureサービスへのネットワークアクセスを制御する方法は以下の2つです。

  1. NSP + Service Tag方式（ストレージアカウント向け）: Azure Network Security Perimeter (NSP) と AzureDatabricksServerless Service Tagを使って、サーバーレスコンピュートからのサービスエンドポイント経由のアクセスをストレージアカウントに対して許可します。NCCは不要で、Azureポータル上のNSP設定のみで完了します（従来のサブネットID方式からの移行が2026年4月7日までに必要です）
  2. NCC + プライベートリンク方式（60以上のAzureサービス向け）: NCCのプライベートエンドポイントルールを使って、Azure Private Link経由でAzure Storage、Azure SQL Database、Azure OpenAIなどのAzureサービスに接続します

組織の要件に合わせて、適切な方式を選択して活用していきましょう。

13
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
13
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?