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

このページでは、コンテキストベースのイングレス制御の概要について説明します。 サーバーレスエグレス制御については、「 サーバーレスエグレス制御とは」を参照してください。

イングレス ポリシーを構成するには、 コンテキストベースのイングレス ポリシーの管理に関するページを参照してください。

コンテキストベースのイングレス制御の概要

コンテキストベースのイングレス制御は、IP アクセス リストとフロントエンド プライベート接続と共に機能し、アカウント管理者は、呼び出し 元 、呼び出し 元 、Azure Databricks で到達できる 内容 を組み合わせた許可規則と拒否規則を設定できます。 これにより、信頼できる ID、要求の種類、ネットワーク ソースの組み合わせのみがワークスペースに到達できるようになります。 コンテキストベースのイングレス制御は、アカウント レベルで構成されます。 1 つのポリシーで複数のワークスペースを管理できるため、組織全体で一貫した適用が保証されます。

コンテキストベースのイングレスを使用すると、次のことができます。

• 資格情報に加えて、信頼されたネットワーク ソースである 2 番目の要素を要求して、信頼されていないネットワークからのアクセスを停止します。
• IP 範囲の代わりに ID をキー設定することで、安定したエグレス IP なしで SaaS クライアントへのアクセスを許可します。
• 信頼度の低いソースが Databricks API やワークスペース UI などの特定のスコープのみを使用できるようにすることで、アクセスを制限します。
• 特権の自動化を保護する: 高価値のサービス プリンシパルを高信頼ネットワークのみに制限します。
• 監査を効果的に行う: ブロックされた要求を監視するために、Unity カタログ システム テーブルで詳細な拒否ログをキャプチャします。

コンテキストベースのイングレス コントロールのコア概念

ネットワーク ソース

ネットワーク ソースは、要求の配信元を定義します。 サポートされる型には次のようなものがあります。

• すべてのパブリック IP: 任意のパブリック インターネット ソース。
• 選択した IP: 特定の IPv4 アドレスまたは CIDR 範囲。

アクセスの種類

規則は、さまざまな受信要求スコープに適用されます。 各スコープは、許可または拒否できる受信要求のカテゴリを表します。

• ワークスペース UI: ワークスペースへのブラウザー アクセス。
• API: SQL エンドポイント (JDBC/ODBC) を含む Databricks API を介したプログラムによるアクセス。
• アプリ: Databricks Apps のデプロイへのアクセスを許可または拒否します。 Databricks アプリを参照してください。 このアクセスの種類では、[ すべてのユーザーとサービス プリンシパル の ID] オプションのみがサポートされています。

• Lakebase コンピューティング: Lakebase データベース インスタンスへの接続。 Lakebase インスタンスを参照してください。 このアクセスの種類では、[ すべてのユーザーとサービス プリンシパル の ID] オプションのみがサポートされています。

アイデンティティーズ

ルールは、さまざまな ID の種類を対象にすることができます。 [アプリ] と [Lakebase コンピューティング] のアクセスの種類の場合、サポートされているオプションは [すべてのユーザーとサービス プリンシパル] のみです。

• すべてのユーザーとサービス プリンシパル: 人間のユーザーと自動化の両方。
• すべてのユーザー: 人間のユーザーのみ。
• すべてのサービス プリンシパル: オートメーション アイデンティティのみ。
• 選択した ID: 管理者によって選択された特定のユーザーまたはサービス プリンシパル。

ルールの評価

• 既定の拒否: 制限モードでは、明示的に許可されない限り、アクセスは拒否されます。
• 許可前に拒否: 拒否ルールを使用すると、許可ルールの例外を定義できます。
• 既定のポリシー: 各アカウントには、ポリシーを明示的に割り当てずに、対象となるすべてのワークスペースに既定のイングレス ポリシーが適用されます。

強制モード

コンテキストベースのイングレス ポリシーでは、次の 2 つのモードがサポートされます。

• すべての製品に適用: ルールはアクティブに適用され、違反する要求はブロックされます。
• すべての製品のドライ ラン モード: 違反はログに記録されますが、要求はブロックされないため、ポリシーへの影響を安全に評価できます。

Auditing

拒否された要求またはドライラン要求は、 system.access.inbound_network システム テーブルに記録されます。 各ログ エントリには、次のものが含まれます。

• イベント時間
• ワークスペース ID
• 要求の種類
• アイデンティティ
• ネットワーク ソース
• アクセスの種類 (DENIED または DRY_RUN_DENIAL)

これらのログに対してクエリを実行して、ルールが正しく適用されていることを検証し、予期しないアクセス試行を検出できます。

他のコントロールとの関係

• ワークスペース IP アクセス リスト: コンテキストベースのイングレス ポリシーが要求を許可する前に評価されます。 どちらも要求を許可する必要があります。 ワークスペースの IP アクセス リストは、アクセスをさらに絞り込むことができますが、拡大することはできません。
• サーバーレス エグレス制御: サーバーレス コンピューティングからの送信ネットワーク トラフィックを制御することで、イングレス ポリシーを補完します。 ネットワーク ポリシーの管理を参照してください。

• フロントエンド プライベート接続: パブリック ネットワーク アクセスを許可 するが 有効になっている場合は、イングレス ポリシーと共に適用されます。 [パブリック ネットワーク アクセスを許可する] が [無効] の場合、すべてのパブリック イングレスがブロックされ、イングレス ポリシーは評価されません。 「受信プライベート リンクの構成」を参照してください。

ベスト プラクティス

• ドライランモードから始め、アクセスを中断することなく影響を観察します。
• IP をローテーションする SaaS クライアントでは、可能な限り ID ベースのルール を使用します。
• まず 特権サービス プリンシパルに「拒否ルール」を適用して、影響範囲を制限します。
• 長期的な保守容易性のために、ポリシー名を明確にし、一貫性を保ちます。