Databricks IP Access Listsでワークスペースを守る

Databricksワークスペースはデフォルトでインターネット上のどのIPアドレスからでもログイン画面にアクセスできます。 企業環境では「社内VPNからのみアクセスを許可したい」「特定の拠点IPだけに制限したい」という要件が必ず出てきます。IP Access Listsは、ワークスペースにアクセスできるIPアドレスの範囲をCIDR単位で制御する機能です。

この記事では、IP Access Listsの仕組み、Allow ListとBlock Listの動作の違い、REST APIによる設定手順、 CIDR表記の基礎、そしてVPNやPrivate Linkとの使い分けを整理します。

IP Access Listsの仕組み

IP Access Listsはワークスペースレベルのネットワークアクセス制御です。 有効にすると、ワークスペースへのすべてのリクエスト（UIログイン・REST API呼び出し・JDBC/ODBC接続）に対して送信元IPアドレスのチェックが行われます。 許可されていないIPからのリクエストは403 Forbiddenで拒否されます。

IP Access Listsには2つの種類があり、それぞれ役割が異なります。

評価順序はBlock List → Allow Listです。 Block Listに一致すればAllow Listに含まれていても拒否されます。 Allow Listが1つ以上定義されている場合、どのAllow Listにも一致しないIPは暗黙的に拒否されます。

CIDR表記の基本

IP Access Listsの設定ではCIDR（Classless Inter-Domain Routing）表記を使います。 ネットワーク管理に馴染みのないデータエンジニア向けに基本を整理します。

スラッシュの後の数字はネットワークプレフィックス長です。値が大きいほど範囲が狭くなります。 /32は1つのIPアドレス、/0は全IPアドレスです。

Allow List × Block Listの評価フロー

IP Access Listsが有効な場合のリクエスト処理フローは以下の通りです。

1. リクエスト送信元のIPアドレスを取得
2. Block Listとの照合: いずれかのBlock ListのCIDRに一致 → 即座に403拒否
3. Allow Listとの照合: いずれかのAllow ListのCIDRに一致 → 許可（通常の認証処理へ進む）
4. どのAllow Listにも不一致 → 暗黙拒否（403）

Allow Listが0件でBlock Listのみが定義されている場合、Block List以外のすべてのIPが許可されます。 ただし実務ではAllow Listを主体にし、Block Listは例外除外用に使うのが推奨パターンです。

REST APIによるIP Access Listの設定

IP Access Listsの設定はUIからも行えますが、IaC管理や自動化にはREST APIを使います。 以下はAllow Listを作成するcurlコマンドの例です。

# Allow Listを作成（社内VPNのCIDR）
curl -X POST \
  "https://<workspace-url>/api/2.0/ip-access-lists" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Corporate VPN",
    "list_type": "ALLOW",
    "ip_addresses": [
      "10.0.0.0/16",
      "172.16.0.0/12"
    ]
  }'

Block Listを追加する場合はlist_typeを"BLOCK"に変更します。

# Block Listを追加（特定サブネットを除外）
curl -X POST \
  "https://<workspace-url>/api/2.0/ip-access-lists" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Exclude Guest Network",
    "list_type": "BLOCK",
    "ip_addresses": [
      "10.0.99.0/24"
    ]
  }'

IP Access Lists機能自体の有効化・無効化は、ワークスペース設定APIで行います。

# IP Access List機能を有効化
curl -X PATCH \
  "https://<workspace-url>/api/2.0/workspace-conf" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "enableIpAccessLists": "true"
  }'

VPN / Private Link / IP Access Listの比較

Databricksのネットワークセキュリティ機能は複数あり、試験でも混同しやすいポイントです。 それぞれの守る範囲と特性を比較します。

IP Access Listは最も導入が簡単で即座に効果を発揮します。一方、通信自体はインターネットを経由するため、 「データが社外ネットワークを一切通過しないこと」が要件の場合はPrivate Linkが必要です。 多くの企業ではIP Access Listで初期導入し、コンプライアンス要件の厳格化に応じてPrivate Linkへ移行する段階的アプローチを取ります。

IP Access List運用のベストプラクティス

• Allow Listは最小限に保つ: 社内ネットワーク全体（/8や/16）ではなく、 VPN出口IP（/32）やオフィスサブネット（/24）を指定して攻撃面を小さく保つ
• 自動化パイプラインのIPを忘れない: GitHub ActionsやJenkinsなどCI/CDランナーのIPレンジも Allow Listに含めないとデプロイが失敗する
• ラベルで管理する: 各リストに意味のあるラベル（"Tokyo Office", "CI/CD Runners"等）を付けて 後から何のために作ったリストか判別できるようにする
• 有効化前にテストする: Allow Listを作成してから有効化する順序を守る。 先に有効化すると「許可リストが空 → 全員ブロック」の事故が起きる
• Account Consoleは影響を受けない: ワークスペースからロックアウトされても Account Console経由でリストを修正できることを把握しておく

Terraformでの管理

IP Access ListをIaCで管理する場合、Databricks Terraform Providerのdatabricks_ip_access_listリソースを使います。

resource "databricks_ip_access_list" "corporate_vpn" {
  label    = "Corporate VPN"
  list_type = "ALLOW"
  ip_addresses = [
    "10.0.0.0/16",
    "172.16.0.0/12",
  ]
}

resource "databricks_ip_access_list" "guest_block" {
  label    = "Block Guest Network"
  list_type = "BLOCK"
  ip_addresses = [
    "10.0.99.0/24",
  ]
}

resource "databricks_workspace_conf" "ip_access" {
  custom_config = {
    "enableIpAccessLists" = "true"
  }
}

Terraformで管理すると、IP変更のレビュープロセス（PR → approve → apply）を強制でき、 「誰がいつどのIPを変更したか」の監査ログも自然に残ります。

試験で問われるポイント

• 「ワークスペースへのアクセスを特定IPに制限するには」→ IP Access List
• 「インターネットを経由させずにワークスペースに接続するには」→ Private Link（IP Access Listではない）
• 「Block ListとAllow Listの優先順位は」→ Block Listが優先
• 「IP Access ListはどのレベルでScopingされるか」→ ワークスペースレベル
• 「CI/CDパイプラインがIP制限でブロックされた場合の対処」→ ランナーIPをAllow Listに追加

問題で確認

よくある質問