Azure DatabricksでワークスペースへのアクセスをPrivate Link化したい場合、2026年4月更新のポイントは「ユーザーからAzure Databricksワークスペースへの入口を、どのように私設ネットワーク経由へ寄せるか」をより実装寄りに整理している点です。特に、databricks_ui_apiのプライベートエンドポイント、SSO用のbrowser_authenticationエンドポイント、Private DNS、ハイブリッドアクセスの考え方を正しく理解しておくことが重要です。
データエンジニアにとっては、NotebookやREST APIへの接続経路を安全にする話です。DBAやデータ基盤担当者にとっては、監査・閉域接続・DNS設計の話です。分析部門のリーダーにとっては、「セキュリティを強化しながら、ユーザー体験と運用負荷をどう両立するか」を判断する材料になります。
この記事では、Microsoft公式ドキュメント「Configure Inbound Private Link – Azure Databricks」の2026年4月更新内容をもとに、実務で押さえるべき変更点、構成パターン、導入時の判断基準、失敗しやすいポイントを整理します。Microsoft Learnでは、Inbound Private LinkはユーザーとAzure Databricksワークスペース間の接続を保護するための構成として説明されています。(Microsoft Learn)
Azure DatabricksのInbound Private Linkとは
Azure DatabricksのInbound Private Linkは、ユーザー、社内ネットワーク、踏み台VM、VPN、ExpressRouteなどからAzure Databricksワークスペースへアクセスする入口を、プライベートエンドポイント経由にするための仕組みです。
対象になるのは主に次の接続です。
| 対象 | Inbound Private Linkで保護する内容 |
|---|---|
| Azure Databricks Web UI | ブラウザからワークスペースへログインする経路 |
| REST API | CI/CD、運用スクリプト、外部アプリからのAPI呼び出し |
| Databricks Connect API | 開発端末や外部環境からの接続 |
| SSO認証 | ブラウザベースのログイン時に必要な認証経路 |
重要なのは、Inbound Private Linkは「ユーザーからDatabricksへ入る経路」を守る機能だという点です。クラスタやジョブがAzure Storage、Azure SQL Database、外部データソースへ接続する経路を守る設定とは別です。
Azure DatabricksのPrivate Linkには、Inbound、Outbound、Classic compute planeのように用途の異なる接続パターンがあります。Microsoft Learnでも、Inboundはユーザーからワークスペースへの接続、Outboundはserverless computeからAzureリソースへの接続、Classicはクラスタからコントロールプレーンへの接続を保護するものとして整理されています。(Microsoft Learn)
2026年4月更新で特に注目すべきポイント
今回の更新で実務上の読みどころになるのは、単に「Private Linkを有効化する」ではなく、構成モデル・認証用エンドポイント・DNS・検証方法まで踏み込んでいる点です。
ハイブリッドアクセスモデルが明確に扱われている
公式ドキュメントでは、プライベート接続の構成として大きく次の2つが示されています。
| 構成モデル | 内容 | 向いているケース |
|---|---|---|
| No public access | ワークスペースへのパブリックアクセスを無効化し、Private Link経由に限定する | 規制業界、機密データ基盤、厳格な閉域要件がある環境 |
| Hybrid access | Private Linkを使いながら、条件付きでパブリックアクセスも残す | 段階移行、グローバル拠点、固定IPの社外アクセスが必要な環境 |
2026年4月更新の公式ガイドでは、特にハイブリッドアクセスモデルの実装が説明されています。Private Linkを有効にしつつ、パブリックアクセスを完全に切らず、context-based ingress controlsやIPアクセスリストと組み合わせて制御する考え方です。(Microsoft Learn)
これは現場ではかなり重要です。いきなりパブリックアクセスを無効化すると、次のような問題が起きやすいためです。
- 海外拠点や委託先のユーザーがログインできなくなる
- CI/CDパイプラインからREST APIを呼べなくなる
- SSOのリダイレクトやDNS解決で失敗する
- 障害時の切り戻し経路がなくなる
- DNSの伝播や条件付きフォワードの設定漏れに気づきにくい
ハイブリッドアクセスは、閉域化への中間ステップとして使いやすい構成です。ただし、「Private Linkを作ったから安全」と考えるのは危険です。パブリックアクセスを残す場合は、誰が、どこから、どの種類のリクエストを許可されるのかを別途制御する必要があります。
Inbound Private Linkで作成する2種類のエンドポイント
Azure DatabricksのInbound Private Linkで混乱しやすいのが、databricks_ui_apiとbrowser_authenticationの違いです。どちらも重要ですが、役割は異なります。
| エンドポイント | 主な役割 | 作成場所の考え方 |
|---|---|---|
databricks_ui_api | ワークスペースのWeb UI、REST API、Databricks Connect APIへの接続をプライベート化する | ユーザー通信を集約するTransit VNet側 |
browser_authentication | ブラウザSSOログインをPrivate Link経由で成立させる | 専用の認証用ワークスペースに持たせる構成が推奨される |
databricks_ui_apiだけを作ると、API接続は期待通り動いても、ブラウザログインでSSOが失敗する可能性があります。Microsoft Learnでは、ブラウザベースのSSOをPrivate Linkで動かすには専用のbrowser_authenticationエンドポイントが必要だと説明されています。(Microsoft Learn)
browser_authenticationは軽視しない
実務で特に注意すべきなのは、browser_authenticationエンドポイントをどのワークスペースに持たせるかです。
公式ガイドでは、専用のブラウザ認証用ワークスペースを作成し、そこにbrowser_authenticationプライベートエンドポイントを作る構成が推奨されています。さらに、そのワークスペースではDatabricksのワークロードを実行せず、誤削除を防ぐために削除ロックを設定する流れが示されています。(Microsoft Learn)
この設計は地味ですが、運用上は非常に大切です。
たとえば、本番ワークスペースAにbrowser_authenticationを作成し、同じリージョンの複数ワークスペースがその認証経路に依存していたとします。その後、ワークスペースAを統廃合や検証終了で削除すると、他のワークスペースのブラウザログインまで影響を受ける可能性があります。
そのため、本番環境では次のように考えると安全です。
| 判断項目 | 推奨される考え方 |
|---|---|
| 本番利用 | 認証専用ワークスペースを作る |
| 検証環境 | 既存ワークスペースに持たせてもよいが、依存関係を明記する |
| 複数ワークスペース運用 | リージョン単位で認証用ワークスペースを設計する |
| 削除リスク | Azure Locksで削除ロックを設定する |
| ワークロード実行 | 認証用ワークスペースではクラスタ、ジョブ、SQL Warehouseを動かさない |
導入前に確認すべき前提条件
Inbound Private Linkの構成は、Azureポータルでプライベートエンドポイントを作るだけでは完了しません。事前条件を満たしていないと、設定途中で詰まるか、設定後にユーザーがログインできない状態になります。
公式ガイドでは、主な要件としてPremiumプラン、VNet injection、プライベートエンドポイント作成権限、DNSレコード管理権限などが示されています。(Microsoft Learn)
実務向けチェックリスト
| 確認項目 | 確認内容 | 不備がある場合の影響 |
|---|---|---|
| Azure Databricksのプラン | Premiumプランか | Private Link関連機能を利用できない |
| VNet injection | ワークスペースが自社管理VNetにデプロイされているか | 公式手順の前提と合わない |
| Secure Cluster Connectivity | No Public IPが有効か | 閉域構成の前提が崩れる |
| Public Network Access | ハイブリッド構成では有効のまま進める | 途中で無効化すると検証や切り戻しが難しくなる |
| Azure権限 | Private Endpoint、Private DNS Zoneを作成・管理できるか | ネットワーク担当に依頼が必要 |
| DNS運用 | Azure DNSか、独自DNSか | 条件付きフォワードやAレコード設計が変わる |
| 既存ワークロード | クラスタ、プール、SQL Warehouseを停止できるか | 更新作業が失敗する可能性がある |
| 認証方式 | Microsoft Entra ID連携、SSOの経路を把握しているか | ブラウザログインで失敗しやすい |
既存ワークスペースへ適用する場合、作業前にクラスタ、プール、classic SQL Warehouseなどのコンピュートリソースを停止する必要があります。公式ガイドでも、実行中のコンピュートリソースがあるとアップグレードが失敗するため、ダウンタイムを計画することが推奨されています。(Microsoft Learn)
推奨アーキテクチャはHub-SpokeとTransit VNet
今回の公式ガイドでは、標準的なHub-Spokeネットワークトポロジーを使い、Transit VNetにプライベートエンドポイントを配置する考え方が示されています。
ここでいうTransit VNetは、単なるVNetではありません。ユーザーや社内ネットワークからAzure Databricksへ入る通信を集約し、VPN、ExpressRoute、ファイアウォール、DNS、共有サービスなどと接続する中心的なネットワークです。
MicrosoftのAzure Architecture Centerでも、Hub-Spoke構成は共有ネットワークサービス、クロスプレミス接続、エグレス制御、DNSなどをハブ側に集約するパターンとして説明されています。(Microsoft Learn)
なぜTransit VNetに置くのか
databricks_ui_apiのプライベートエンドポイントを各ワークスペースの近くにバラバラに置くと、次のような運用課題が出ます。
- DNSレコードの管理場所が分散する
- 拠点接続やExpressRouteの経路設計が複雑になる
- 監査ログやファイアウォール制御を集約しにくい
- 複数ワークスペースの追加時に同じ設計を再利用しにくい
- グローバル展開時にリージョンごとの差分が増える
Transit VNetに集約すると、ユーザーアクセスの入口を一元管理しやすくなります。データエンジニアはワークスペース単位で考えがちですが、DBAやネットワーク担当、セキュリティ担当は「どのネットワーク境界から入ってくるか」を重視します。Inbound Private Linkの設計では、この視点の違いを早めにすり合わせることが成功の鍵です。
構成手順の全体像
公式手順を実務向けに整理すると、次の流れになります。
| 手順 | 作業 | 実務での注意点 |
|---|---|---|
| 事前準備 | 要件、権限、DNS、ダウンタイムを確認 | 既存環境ではコンピュート停止を忘れない |
| Step 1 | VNet injectionとPublic Network Accessを確認 | ハイブリッドアクセスではPublic Network Accessを有効にして進める |
| Step 2 | databricks_ui_apiプライベートエンドポイントを作成 | Transit VNetのプライベートエンドポイント用サブネットに配置 |
| Step 3 | 認証専用ワークスペースを作成 | ワークロードを実行せず、削除ロックを設定 |
| Step 4 | browser_authenticationプライベートエンドポイントを作成 | 同じTransit VNetに接続し、Private DNS連携を確認 |
| Step 5 | DNSを検証 | ワークスペースURLとSSO認証URLがプライベートIPへ解決されるか確認 |
| Step 6 | 接続テスト | 社内ネットワーク、VPN、ExpressRoute、テストVMからログイン確認 |
| Step 7 | アクセス制御を強化 | context-based ingress controlsやIPアクセスリストを調整 |
この順序で進めると、問題が発生したときに切り分けしやすくなります。特にDNS検証を後回しにすると、「Private Endpointは作成済みなのにログインできない」という典型的なトラブルに陥ります。
DNS設計が成否を分ける
Inbound Private Linkの構成で最も失敗しやすいのはDNSです。
公式ガイドでは、プライベートエンドポイント作成後にprivatelink.azuredatabricks.netのPrivate DNS Zoneを確認し、ワークスペースURLとブラウザ認証用レコードがプライベートIPを指しているか検証する流れが示されています。(Microsoft Learn)
Azure DNSを使う場合
Azure DNSでPrivate DNS Zoneを管理する場合は、次の点を確認します。
| 確認対象 | 内容 |
|---|---|
| Private DNS Zone | privatelink.azuredatabricks.netが作成されているか |
| VNetリンク | Transit VNetにPrivate DNS Zoneがリンクされているか |
| ワークスペースURL | adb-xxxxxxxxxxxxxxxx.xのAレコードが存在するか |
| 認証レコード | browser_authentication用のAレコードが存在するか |
| 解決先IP | パブリックIPではなくプライベートエンドポイントのIPか |
検証にはnslookupを使います。たとえば、Transit VNet内のVMやVPN接続済み端末から次のように確認します。
nslookup adb-xxxxxxxxxxxxxxxx.x.azuredatabricks.net期待されるのは、privatelink.azuredatabricks.net側の名前に解決され、最終的にプライベートエンドポイントのIPアドレスが返る状態です。
独自DNSを使う場合
企業ネットワークでは、Azure DNSだけでなく、オンプレミスDNS、Infoblox、Windows DNS Server、クラウドDNSなどを併用していることがあります。この場合は条件付きフォワードの設計が重要です。
公式ガイドでは、独自DNSを使う場合、Databricks関連ドメインをAzureの内部DNSへ条件付きフォワードする方式が推奨されています。対象として*.azuredatabricks.net、*.privatelink.azuredatabricks.net、*.databricksapps.comが示されています。(Microsoft Learn)
手動でAレコードを作成する方法もありますが、リージョンやSSOの制御プレーン構成によって追加レコードが必要になる可能性があります。長期運用を考えると、可能な限り条件付きフォワードを優先した方が安全です。
IPアクセスリストやcontext-based ingress controlsとの使い分け
Inbound Private Linkはネットワーク経路をプライベート化する仕組みですが、それだけでアクセス制御が完成するわけではありません。
ハイブリッドアクセスでは、パブリックアクセスを残すため、どのネットワークからのアクセスを許可するかを明確にする必要があります。Azure Databricksでは、ワークスペースIPアクセスリストとaccount-levelのcontext-based ingress controlsを組み合わせて制御できます。
Microsoft Learnでは、ワークスペースIPアクセスリストとcontext-based ingress controlsは一緒に適用され、リクエストが成功するには両方で許可される必要があると説明されています。また、context-based ingress controlsはID、リクエスト種別、ネットワークソースを組み合わせて制御できるため、主なアクセス管理手段として推奨されています。(Microsoft Learn)
実務での使い分け
| 制御方法 | 向いている用途 | 注意点 |
|---|---|---|
| Inbound Private Link | 社内ネットワーク、VPN、ExpressRoute経由の閉域アクセス | DNSと認証エンドポイントの設計が必要 |
| IPアクセスリスト | 固定グローバルIPからのアクセス制限 | IPv4中心。IP変更時の運用が必要 |
| context-based ingress controls | ID、リクエスト種別、ネットワーク条件を組み合わせた制御 | アカウントレベルの設計と検証が必要 |
| Public Network Access無効化 | 完全な閉域化に近づける | 切り戻し経路、SSO、API利用元の確認が必須 |
おすすめは、段階的に導入することです。
まずInbound Private Linkを構成し、社内ネットワークからの接続を確認します。次にIPアクセスリストやcontext-based ingress controlsでパブリック側の入口を絞ります。最後に、要件が厳しい環境ではPublic Network Accessの無効化を検討します。
Inboundだけで「完全閉域」になるわけではない
Azure DatabricksのPrivate Link設計でよくある誤解が、「Inbound Private Linkを設定すれば、Databricks全体が完全に閉域化される」というものです。
Inbound Private Linkは、ユーザーからワークスペースへのフロントエンド接続を保護します。一方で、クラスタからコントロールプレーンへの接続や、serverless computeからAzure Storageなどへの接続は別の設計が必要です。
Microsoft Learnでは、Classic compute plane Private LinkはクラスタとAzure Databricksコントロールプレーン間の通信を保護するための構成として説明されています。(Microsoft Learn) また、serverless computeからAzureリソースへのプライベート接続はNetwork Connectivity Configurations、つまりNCCを使って管理されます。(Microsoft Learn)
目的別に必要なPrivate Linkを選ぶ
| 目的 | 必要な構成 |
|---|---|
| ユーザーのWeb UIアクセスを閉域化したい | Inbound Private Link |
| REST APIを社内ネットワークから安全に呼びたい | Inbound Private Link |
| ブラウザSSOをPrivate Link経由で動かしたい | browser_authenticationエンドポイント |
| classic computeのクラスタ通信を閉域化したい | Classic compute plane Private Link |
| serverless computeからAzure Storageへ閉域接続したい | Serverless Private Link / NCC |
| 可能な限り全面的に閉域化したい | Inbound、Classic、Serverless、DNS、アクセス制御を組み合わせる |
分析基盤のセキュリティレビューでは、「Private Linkを使っています」と一言で説明するのでは不十分です。どの通信経路をPrivate Link化していて、どの通信はまだパブリック経路を使う可能性があるのかを明確にする必要があります。
導入時に失敗しやすいポイント
Public Network Accessを早く無効化しすぎる
閉域化を急ぐあまり、検証前にPublic Network Accessを無効化すると、管理者自身がワークスペースへアクセスできなくなることがあります。
特にグローバル企業では、日本本社、海外拠点、外部パートナー、CI/CD環境、監視システムが異なる経路から接続していることがあります。まずハイブリッドアクセスで接続経路を洗い出し、ログイン、API、ジョブ運用、監視を確認してから、無効化を検討する方が安全です。
DNSレコードだけを見て接続確認を終える
Aレコードが存在していても、実際のクライアントがそのDNSを使っているとは限りません。
確認すべきなのは、Azureポータル上のDNSレコードだけではありません。ユーザー端末、踏み台VM、オンプレミスネットワーク、VPN接続後の端末、CI/CDエージェントから名前解決した結果です。
特に独自DNSを使う企業では、条件付きフォワードの設定が一部の拠点にしか反映されていないことがあります。
認証専用ワークスペースを通常用途で使ってしまう
browser_authentication用に作成したワークスペースで、検証用クラスタやジョブを動かしてしまうのは避けるべきです。認証基盤としての役割が曖昧になり、削除、権限変更、ネットワーク変更の影響範囲が読みにくくなります。
名前にも工夫が必要です。たとえば、WEB_AUTH_DO_NOT_DELETE_<region>のように、削除してはいけない用途であることが分かる命名にすると、運用事故を減らせます。
API利用元を見落とす
Azure DatabricksはWeb UIだけで使われるとは限りません。次のようなAPI利用元を棚卸ししておく必要があります。
- GitHub ActionsやAzure DevOpsのデプロイパイプライン
- Databricks CLIを使う運用端末
- Terraform実行環境
- 監視ツール
- 社内ポータルや自動化スクリプト
- BIツールや外部連携アプリケーション
Private Link化後、これらの実行環境がTransit VNetやVPN、ExpressRoute経由で名前解決・接続できるかを確認してください。
data engineers、DBAs、analytics leaders別の確認ポイント
同じInbound Private Linkでも、立場によって見るべきポイントは変わります。
| 立場 | 主な関心 | 確認すべきこと |
|---|---|---|
| data engineers | Notebook、ジョブ、API、開発体験 | ログイン、REST API、Databricks Connect、CI/CDが継続利用できるか |
| DBAs / データ基盤管理者 | DNS、閉域接続、監査、データ保護 | 名前解決、接続元制限、Private DNS Zone、認証経路が正しいか |
| analytics leaders | セキュリティ強化と業務影響のバランス | 移行期間、ユーザー影響、海外拠点対応、運用コストを把握できているか |
| セキュリティ担当 | 攻撃面の縮小、データ持ち出し対策 | パブリックアクセスの残存、IP制御、context-based ingress controlsの適用範囲 |
| ネットワーク担当 | Hub-Spoke、ExpressRoute、Firewall、DNS | Transit VNet、ルーティング、条件付きフォワード、障害時の切り分け手順 |
技術的にはネットワーク構成の話ですが、実際には組織横断の変更です。データエンジニアだけで進めると、DNSや認証で詰まりやすくなります。逆にネットワーク担当だけで進めると、Databricks CLI、REST API、Databricks Connectなどの利用実態を見落とすことがあります。
導入判断の目安
Inbound Private Linkを導入すべきか迷う場合は、次の基準で判断すると整理しやすくなります。
| 状況 | 導入優先度 | 理由 |
|---|---|---|
| 機密データ、個人情報、金融・医療・公共系データを扱う | 高 | ネットワーク境界の明確化と監査対応が重要 |
| VPNまたはExpressRoute中心の社内アクセスに統一したい | 高 | ユーザーアクセスを私設ネットワークに寄せやすい |
| REST APIを社内システムから頻繁に呼ぶ | 中〜高 | API呼び出し元の制御がしやすくなる |
| 少人数の検証ワークスペースのみ | 中 | まずIP制御やcontext-based ingress controlsで十分な場合もある |
| グローバル拠点から柔軟にアクセスしたい | 要設計 | ハイブリッドアクセスと段階移行が現実的 |
| 完全閉域を求められている | 高。ただしInboundだけでは不十分 | Classic、Serverless、DNS、データソース側のPrivate Linkも必要 |
導入の判断で大切なのは、「何を閉域化したいのか」を明確にすることです。ユーザーアクセスだけなのか、クラスタ通信も含むのか、serverless computeからデータソースへの通信も含むのかで、必要な構成は変わります。
実装前に作っておくべき設計メモ
Inbound Private Linkを安全に導入するには、作業前に簡単な設計メモを作ることをおすすめします。長大な設計書である必要はありません。最低限、次の項目を1枚にまとめるだけでもトラブルを減らせます。
| 項目 | 記入例 |
|---|---|
| 対象ワークスペース | 本番、検証、開発の各ワークスペース名 |
| リージョン | Japan East、East USなど |
| Transit VNet | VNet名、サブネット名、IPレンジ |
| Private Endpoint | databricks_ui_api、browser_authenticationの名前と配置先 |
| 認証用ワークスペース | ワークスペース名、削除ロック有無、Public Network Access設定 |
| DNS方式 | Azure DNS、独自DNS、条件付きフォワードの有無 |
| 接続元 | 社内LAN、VPN、ExpressRoute、踏み台VM、CI/CD環境 |
| 検証項目 | Web UIログイン、REST API、CLI、Databricks Connect、SSO |
| 切り戻し方針 | Public Network Access、DNS変更、アクセス制御の戻し方 |
| 影響部門 | データエンジニア、分析部門、ネットワーク、セキュリティ、運用 |
このメモがあると、障害時に「誰がどの設定を変更したのか」「どの接続元が影響を受けているのか」を追いやすくなります。
まず取るべき次のアクション
Azure DatabricksのInbound Private Linkは、セキュリティ強化に有効ですが、単独で完結する設定ではありません。2026年4月更新の公式ガイドを読むと、ポイントは次の5つに整理できます。
- Inbound Private Linkは、ユーザーからAzure Databricksワークスペースへの接続を保護する
- ハイブリッドアクセスでは、Private Linkとパブリックアクセス制御を併用する
databricks_ui_apiだけでなく、SSO用のbrowser_authenticationも重要- DNS、特にPrivate DNS Zoneと条件付きフォワードの設計が成否を分ける
- 完全な閉域化には、Classic compute planeやserverless compute側のPrivate Linkも検討する必要がある
最初にやるべきことは、現在のAzure Databricksワークスペースについて「誰が、どこから、どの方法でアクセスしているか」を棚卸しすることです。そのうえで、Transit VNet、認証用ワークスペース、DNS、アクセス制御を設計し、検証環境でハイブリッドアクセスから始めるのが現実的です。
いきなり本番でPublic Network Accessを無効化するのではなく、まずはPrivate Link経由のWeb UIログイン、REST API、SSO、CLI、CI/CDを確認してください。その結果をもとに、IPアクセスリストやcontext-based ingress controlsを調整し、最終的にどこまで閉域化するかを決めるのが安全な進め方です。
コメント