Go to Qiita Advent Calendar Top
LoginSignup
6
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 14

株式会社TRAILBLAZER Advent Calendar 2025

@takanosutin株式会社TRAILBLAZER

Databricksのサーバレスセキュリティ〜Terraformで実装するアウトバウンド制御〜

Last updated at Posted at 2025-12-13

この記事は 株式会社TRAILBLAZER Advent Calendar 2025 の14日目の記事です。

はじめに

こんにちは。株式会社TRAILBLAZERでインフラエンジニアをしている高野です。

現在弊社では、JR西日本グループが保有する鉄道・生活サービスなどの膨大なデータを有効活用し、新たな価値を創出するためのR&Dに取り組んでいます。私はその中核となるデータ分析基盤（以下、R&D環境）の構築を担当しており、アーキテクチャには AWS と Databricks を主たるプラットフォームとして採用しています。

近年、Databricks界隈でもご多分に漏れず、サーバレスの波が急速に広がっています。SQL Warehouseのサーバレス化に始まり、最近ではJobやNotebookのコンピュートまでもがサーバレスで動作するようになりました。インスタンスの起動待ち時間がほぼゼロになる体験は、一度味わうと元には戻れません。

私たちのR&D環境でも、この圧倒的な運用性の高さと管理コストの低減を享受すべく、Serverless Computeを全面的に採用する方針を固めていました。

しかし、インフラ担当として最後まで懸念していたのがネットワークセキュリティです。 コンピュートリソースがVPCの外側（Databricks管理下）にあるサーバレス環境では、従来のようなAWSレベルでの制御が難しくなります。ユーザーの誤操作や、悪意あるライブラリによる情報の持ち出しを、フェールセーフやフールプルーフの思想でどう防ぐか。これが最大の課題でした。

そんな中、Data + AI Summit 2025 にて、サーバレス環境における Egress Control（アウトバウンド通信制御） のGA（一般提供開始）がアナウンスされました。

「これこそ求めていた機能だ」と直感し、早速検証を行ったところ、セキュリティ要件をクリアしつつサーバレスの利便性を活かせる構成が実現できました。 本記事では、私たちが実際に構築して手応えを感じた、Databricks Serverlessにおけるセキュリティ設定の実践知をご紹介します。

1. Databricksのコンピュートアーキテクチャ：Classic vs Serverless

まず、なぜサーバレス環境でのネットワーク制御がこれほど議論になるのか、従来のClassicコンピュートとのアーキテクチャの違いから整理します。

Classic Compute Plane

DatabricksのコントロールプレーンはDatabricks社が管理しますが、実際に計算処理を行うデータプレーン（EC2インスタンス）は、下図のようにユーザー自身のAWSアカウント（VPC）内に展開されます。

Classic Architecture
(※出典：https://docs.databricks.com/aws/ja/security/network/classic)

この構成の最大のメリットは、AWSのネイティブな機能を使ってネットワーク制御が容易な点です。

  • Security Groupによる制御
  • NAT Gatewayへの集約
  • AWS Network Firewallによるフィルタリング

つまり、「AWSの知識さえあれば、アウトバウンド制御は自前で実装可能」でした。

Serverless Compute Plane

一方、今回採用したいServerlessでは、コンピュートリソースは下図のようにDatabricksが管理するVPC内に展開されます。これを「Serverless Compute Plane」と呼びます。

Serverless Architecture
(※出典：https://docs.databricks.com/aws/ja/security/network/serverless-network-security)

ここで大きな壁となるのが、ユーザーはDatabricks管理のVPCに対して、AWSレイヤーでの直接的な設定（SGやNACL等）を行えないという点です。
リソースがブラックボックス化するため、デフォルトの状態ではインターネットへのアクセスが無制限、あるいは制御不可能な状態に見えてしまいます。

2. Serverlessにおけるアウトバウンド制御のアプローチ

この課題に対し、Databricksは Serverless Egress Control という機能を提供しています。これを利用することで、Serverless環境からのEgress（外向き）通信に対して、アプリケーションレイヤーでのファイアウォールルールのような制御が可能になります。

今回採用する戦略：ドメインベースのホワイトリスト制御

扱うデータは企業の重要資産です。漏洩を防ぐため、以下の方針で制御を行います。

  1. デフォルト拒否（Deny All）： 基本的にすべてのインターネットアクセスをブロックする。
  2. 許可リスト（Allow List）： 業務上必要な特定のドメイン（例: PyPI, 自社API, 特定のS3バケットなど）のみを許可する。

これにより、開発者が誤って不正なサイトへアクセスしたり、マルウェアを含むパッケージが外部へ通信を試みたりした場合でも、ネットワークレベルで遮断することが可能になります。

3. TerraformによるEgressポリシーの実装

Databricksの設定はGUIでも可能ですが、運用管理と再現性を考慮し、Terraform（IaC）で管理することをお勧めします。
ここでは、databricks プロバイダを使用した実装例を紹介します。

※ 前提として、この設定はAccount Levelの権限が必要です。

Step 1: Network Policyの定義

まず、アカウントレベルでネットワークポリシーを作成し、Egressルール（ホワイトリスト）を定義します。

# プロバイダ定義
 provider "databricks" {
   alias = "mws"
   host  = "https://accounts.cloud.databricks.com"
   account_id    = var.databricks_account_id
   client_id     = var.DATABRICKS_CLIENT_ID
   client_secret = var.DATABRICKS_CLIENT_SECRET
 }

resource "databricks_account_network_policy" "network_policy" {
  provider          = databricks.mws
  account_id        = var.databricks_account_id
  network_policy_id = "{ネットワークポリシー名}"
  
  egress = {
    network_access = {
      # 基本方針：制限付きアクセス（ホワイトリスト形式）
      restriction_mode = "RESTRICTED_ACCESS"
      
      allowed_internet_destinations = [
        # Terraformのループ機能でリストから動的に生成
        for domain in var.allowed_internet_destinations : {
          destination               = domain
          internet_destination_type = "DNS_NAME"
        }
      ]
      
      # ポリシーの強制モード
      policy_enforcement = {
        enforcement_mode = "ENFORCED" # MONITOR_ONLY にすれば監査モードとして動作可能
      }
    }
  }
}

# 変数定義の例
variable "allowed_internet_destinations" {
  type    = list(string)
  default = [
    "pypi.org",  # Pythonライブラリ利用用途
    "files.pythonhosted.org"  # Pythonライブラリ利用用途
  ]
}

enforcement_mode を "MONITOR_ONLY" に設定することで、通信をブロックせずにログのみを出力する「監査モード」でのデプロイも可能です。導入初期はまずMONITOR_ONLYで運用し、必要な通信を洗い出してから ENFORCED に切り替えるのが安全な進め方です。

ルールの適用には数分〜数十分かかる場合があります。設定直後は接続テストの結果が安定しない場合があるため注意してください。

Step 2: ワークスペースへの関連付け

作成したポリシーは、そのままでは効果を発揮しません。対象となるDatabricksワークスペースに関連付ける必要があります。

resource "databricks_workspace_network_policy_binding" "workspace_binding" {
  provider          = databricks.mws
  account_id        = var.databricks_account_id
  workspace_id      = var.databricks_workspace_id
  network_policy_id = databricks_account_network_policy.network_policy.network_policy_id
}

4. 設定の確認

Terraformでの適用が完了したら、Databricksのアカウントコンソールから設定が反映されているか確認しましょう。

アカウントコンソール > ワークスペース > 関連づけたワークスペース名 の順に画面遷移してください。
下図の赤枠のように、作成したネットワークポリシーが表示されていることを確認します。
image.png

5. System Tablesによるブロックログの解析

ホワイトリスト運用を始めると、必ず発生するのが「必要な通信までブロックしてしまい、ジョブが失敗する」という事象です。 どのドメインへのアクセスが必要だったのかを特定するためには、Databricksの System Tables を活用するのがおすすめです。

システムテーブルの活用

Serverlessコンピュートからのアウトバウンド通信のネットワークブロックログは、システムテーブルの一つであるsystem.access.outbound_networkを参照することで確認できます。
どのドメインへのアクセスが何回ブロックされたかを抽出するクエリを載せておきます。

SELECT
    destination_type, destination,
    COUNT(*) AS destination_count
FROM
    system.access.outbound_network
GROUP BY
    ALL;

このクエリの結果を見ることで、「あ、kaggle.com へのアクセスを許可し忘れていたな」といったことが即座に判明し、Terraformコードへフィードバックするサイクルを回すことができます。

6. 動作確認

ブロックされる通信の実施

ネットワークポリシー上は許可していない、弊社アドベントカレンダーページのURLへアクセスしてみます。（コードはGeminiにて生成しております。）
image.png

参考：アクセステスト用コード 
import requests

# ターゲットURL
url = "https://qiita.com/advent-calendar/2025/trail-blazer-member"

print(f"Connecting to: {url} ...")

try:
    # タイムアウトを5秒に設定してリクエスト
    response = requests.get(url, timeout=5)
    
    # ステータスコードの確認
    if response.status_code == 200:
        print("✅ Success: Connection allowed.")
    else:
        print(f"⚠️ Response received: {response.status_code}")
        
except requests.exceptions.ConnectionError as e:
    print(f"❌ Connection Error: {e}")
    print("-> ブロックされた可能性があります。System Tableを確認してください。")
except requests.exceptions.Timeout as e:
    print(f"⏰ Timeout: {e}")
    print("-> 応答がありません（ドロップされた可能性があります）。System Tableを確認してください。")
except Exception as e:
    print(f"❌ Error: {e}")

上記画像のエラーメッセージからブロックされたことがわかります。

ブロックされたことの確認

実運用では、上述したシステムテーブル確認用のSQLを利用して、アウトバウンド通信のブロック実績を確認することになると思います。
実運用を想定して、システムテーブルを解析した結果も以下に示します。
image.png

ブロックされた通信のアクセス先ドメインとブロック回数が表示されており、qiita.com向けのアウトバウンド通信がブロックされていることがわかります。
※システムテーブルへのログの反映に時間がかかるようです。反映されるまでに何度かリクエストを試行したため、destination_countは4回記録されております。

ホワイトリストへの追加

先ほど利用したホワイトリスト設定用のTerraform変数に対して、qiita.comのドメインを追加してみましょう。

# 変数定義の例
variable "allowed_internet_destinations" {
  type    = list(string)
  default = [
    "pypi.org",  # Pythonライブラリ利用用途
    "files.pythonhosted.org",  # Pythonライブラリ利用用途
    "qiita.com" # ←Qiitaアクセス用に追加
  ]
}

アクセスできるようになったことの確認

以下の動作確認結果の通り、無事弊社アドベントカレンダーページへのアクセスに成功しました。
image.png

7. まとめ：攻めのための守り

DatabricksのServerless Computeは、インフラ管理の手間を劇的に減らし、データ活用のスピードを加速させる強力な機能です。 しかし、その利便性を安心して享受するためには、ブラックボックス化するネットワークに対する適切なガバナンスが不可欠です。
その点、Serverless Egress Control を利用したアウトバウンド制御は、運用負荷少なくフェールセーフ/フールプルーフなホワイトリスト運用ができる点で、心強いのではないでしょうか。

しっかりとした「守り（セキュリティ）」があるからこそ、データサイエンティストやエンジニアは安心して「攻め（データ分析・R&D）」に集中できます。 今後もこの環境を活用し、グループ全体のデータ利活用を推進していきたいと思います。

この記事を読んでまた、弊社に興味を持っていただけたら嬉しいです。

最後に、私たち株式会社TRAILBLAZERは共に挑戦し、サービスを共創していく仲間を募集しています。詳細はこちらからご覧ください。

6
0
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
6
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?