メインコンテンツまでスキップ

コンテキストベースのネットワークポリシー

備考

プレビュー

**アカウント**レベルの**コンテキストベースのイングレス****ポリシー**は**ベータ版**です。

Databricksのコンテキストベースポリシーは、ワークスペースおよびアカウントレベルのリソース(例:アカウントコンソールおよびアカウントレベルのGenie)へのインバウンドおよびアウトバウンドトラフィックの両方を管理するための統一されたセキュリティフレームワークを提供します。ワークスペースポリシーは**ワークスペースレベルポリシー**で構成され、明示的な割り当てがないすべてのワークスペースにはデフォルトのワークスペースポリシーが割り当てられます。アカウントレベルポリシーは、単一のaccount-policyを使用して別途構成されます。

**コンテキストベースのイングレス**を使用すると、管理者はID、ネットワーク**ソース**、およびリクエストタイプを組み合わせて**ワークスペース**および**アカウント**レベルの**アクセス**を**制限**できます。**サーバレス****エグレス****ポリシー**は、**サーバレス****ワークロード**を**認可**された**宛先**に**制限**することで、この**制御**を**アウトバウンドトラフィック**に**拡張**します。これらを組み合わせることで、これらのネットワーク**ポリシー**は、ユーザー**アクセス**と**データ**の移動の両方が組織全体で信頼できる境界内に留まることを**保証**するのに役立ちます。

コンテキストベースのネットワーク ポリシーは、次の既存のセキュリティ機能を補完します。

  • コンテキストベースのイングレス制御:

    • ワークスペースIPアクセスリスト
    • アカウント IP アクセス リスト
    • インバウンド Private Link(プライベートアクセス設定を使用)
  • サーバーレス出力制御:

    • アウトバウンドPrivate Link(ネットワーク接続構成を使用)

利点

コンテキストベースのイングレス ネットワーク ポリシーは、ネットワーク セキュリティに次のような利点をもたらします。

  • セキュリティの強化:不正アクセスやデータ流出のリスクを軽減します。
  • IDベースの制御:安定したIP範囲を持たないSaaSクライアントをIDベースのルールを使用することでサポートします。
  • 柔軟な適用:さまざまなリクエストタイプ、ソース、IDに異なるルールを適用します。
  • 集中管理:アカウントレベルで一度設定し、複数のワークスペースに適用します。
  • 安全なテスト:ドライランモードを使用して、完全な適用前にポリシーの影響をテストします。

ポリシータイプの比較

コンテキストベースのネットワーク ポリシーには、イングレス制御とエグレス制御の 2 つの種類があります。次の表は主な違いをまとめたものです。

属性

進入制御

退出制御

制御するもの

Databricksワークスペースおよびアカウントレベルのエンドポイントへのインバウンドリクエスト。

サーバレスコンピュートから外部宛先へのアウトバウンド接続。

主なユースケース

ワークスペースとアカウントレベルのリソースにアクセスできるユーザー、アクセス元、および到達できるものを制限します。

サーバレス コンピュートがどの外部リソースに接続できるかを制御することで、データの漏洩を防ぎます。

ポリシー基準

ID(複数のユーザーまたは複数のサービスプリンシパル)

ネットワークソース(CIDR範囲、登録済みVPCエンドポイント)

アクセスタイプ:ワークスペースの場合(**ワークスペース UI**、**API**、**アプリ**、**Lakebase コンピュート**)、アカウントの場合(**アカウント UI**、**アカウント API**)

許可された場所

FQDN

クラウドストレージコンテナ

監査ログ

system.access.inbound_network システムテーブル

system.access.outbound_network システムテーブル

属性

進入制御

退出制御

制御するもの

Databricksワークスペースおよびアカウントレベルのエンドポイントへのインバウンドリクエスト。

サーバレスコンピュートから外部宛先へのアウトバウンド接続。

主なユースケース

ワークスペースとアカウントレベルのリソースにアクセスできるユーザー、アクセス元、および到達できるものを制限します。

サーバレス コンピュートがどの外部リソースに接続できるかを制御することで、データの漏洩を防ぎます。

ポリシー基準

ID(複数のユーザーまたは複数のサービスプリンシパル)

ネットワークソース(CIDR範囲、登録済みVPCエンドポイント)

アクセスタイプ:ワークスペースの場合(**ワークスペース UI**、**API**、**アプリ**、**Lakebase コンピュート**)、アカウントの場合(**アカウント UI**、**アカウント API**)

許可された場所

FQDN

クラウドストレージコンテナ

監査ログ

system.access.inbound_network システムテーブル

system.access.outbound_network システムテーブル

コンテキストベースのポリシーの仕組み

イングレス制御を使用すると、次のことが可能になります。

  • 有効な資格情報と信頼できるネットワーク ソースの両方を要求することで、信頼できないネットワークからのアクセスを停止します。
  • IP 許可リストの代わりに ID ベースのルールを使用して、動的 IP を持つ SaaS 自動化ツールを許可します。
  • 機密性の高い操作をUIに制限する一方で、広範なAPIアクセスを許可します。
  • 高特権サービスプリンシパルを企業ネットワーク範囲のみに制限します。

出力制御を使用すると、次のことが可能になります。

  • サーバレス コンピュートがアクセスできる外部APIsを制限することで、データの漏洩を防ぎます。
  • 承認されたクラウド ストレージ バケットと外部データベースへの接続のみを許可します。
  • 必要な統合を許可しながら、許可されていない宛先への送信接続をブロックします。
  • データの移動を承認された地域とサービスに制限することで、コンプライアンスを強化します。
    • 入力ポリシーを構成する
    • ID、ネットワーク ソース、アクセス タイプを組み合わせた許可ルールと拒否ルールを設定し、ワークスペースへの受信要求を制御します。
    • 出力ポリシーを構成する
    • 送信接続ルールを定義して、サーバーレス コンピュート リソースが到達できる外部宛先を制御します。

執行モード

コンテキストベースのポリシーには、次の 2 つの異なる適用モードがあります。

  • 強制モード : ルールがアクティブに適用されます。違反するリクエストはブロックされます。
  • Dry 実行モード : 違反はログに記録されますが、ブロックされません。 このモードを使用して、ポリシーの影響を強制適用前にテストします。

Databricks 、意図しないアクセスの中断を避けるために、 dry 実行 モードから始めることをお勧めします。

監査ログ

Databricks 、コンプライアンスとモニタリングのすべてのポリシー評価をログに記録します。

これらのログをクエリして、ポリシーの有効性を検証し、不正なアクセスの試みを検出します。

ポリシーが他のコントロールとどのように相互作用するか

  • **IP アクセスリスト**:IP アクセスリストとパブリックアクセスコンテキストベースのイングレスポリシーの両方でリクエストを許可する必要があります。プライベートアクセス設定でパブリックアクセスを無効にすると、システムはイングレスポリシー規則にかかわらずすべてのパブリックリクエストを拒否します。

  • プライベート接続

    • トラフィックを許可するには、プライベートアクセス設定とコンテキストベースのイングレスの両方でエンドポイントを許可する必要があります。デフォルトでは、コンテキストベースのイングレスは**すべてのプライベートエンドポイントからのアクセスを許可**に設定されており、アクセス決定はワークスペースのプライベートアクセス設定に委ねられます。コンテキストベースのプライベートアクセス**ポリシー**を構成する場合は、ワークスペースにプライベートアクセス設定がアタッチされ、すべての登録済みプライベートエンドポイントが許可されていることを確認してください(詳細については以下を参照)。これにより、ワークスペースのコンテキストベースのイングレスポリシーにアクセス決定が委ねられます。
    • アカウントポリシーの場合、コンテキストベースのイングレスがプライベートアクセスポリシーの唯一の信頼できる情報源となります。
  • セキュリティ プロファイル : コンテキスト ベースのポリシーは、コンピュートとデータガバナンスを補完するネットワーク レベルの制御を提供します。

ベストプラクティス

  • 強制実行前にポリシーの動作を検証するには、ドライ実行モードから開始します。
  • 動的 IP アドレスを持つ SaaS クライアントには ID ベースのルールを使用します。
  • リスクを制限するために、最初に高特権のサービスプリンパルシに拒否ルールを適用します。
  • 予期しないアクセス パターンを検出するために、監査ログを定期的に監視します。
  • 必要な外部リソースに引き続きアクセスできることを確認するために、出力ポリシーをテストします。
  • 長期的な保守性を確保するため、説明的なポリシー名を使用します。