Contrôle d'entrée basé sur le contexte

remarque

Cette fonctionnalité nécessite le niveau Enterprise.

info

Aperçu

Les plate-formes de partenaires en tant que source de réseau sont en bêta. Ajoutez à la liste blanche les adresses IP que les applications tierces (Power BI, Tableau Cloud et dbt platform) utilisent pour se connecter à Databricks. Databricks gère et met à jour ces listes IP automatiquement.

Cette page fournit une vue d'ensemble du contrôle d'entrée basé sur le contexte. Pour le contrôle de sortie Serverless, consultez Qu'est-ce que le contrôle de sortie Serverless ?.

Pour configurer les politiques d'entrée, consultez Gérer les politiques d'entrée basées sur le contexte.

Vue d'ensemble du contrôle d'entrée basé sur le contexte

Le contrôle d'entrée basé sur le contexte fonctionne conjointement avec les listes d'accès IP et la connectivité privée front-end pour permettre aux administrateurs de compte de définir des règles d'autorisation et de refus qui combinent qui appelle, d'où ils appellent et ce qu'ils peuvent atteindre dans Databricks. Cela garantit que seules les combinaisons fiables d’identité, de type de requête et de source réseau peuvent atteindre votre workspace. Le contrôle d'ingestion basé sur le contexte est configuré au niveau du compte. Une seule stratégie peut régir plusieurs espaces de travail.

Grâce à l'entrée basée sur le contexte, vous pouvez :

• Bloquez l'accès depuis les réseaux non fiables en exigeant un second facteur, une source de réseau fiable, en plus des identifiants.
• Autoriser l’accès pour les clients SaaS sans IP de sortie stables en se basant sur l’identité au lieu des plages d’adresses IP.
• Limitez l'accès en permettant aux sources moins fiables d'utiliser uniquement certains périmètres, comme les APIs Databricks ou l'interface utilisateur du Workspace.
• Protéger l'automatisation privilégiée : Limitez les Databricks Service Principal de grande valeur aux réseaux de confiance élevée uniquement.
• Auditez efficacement : capturez les journaux de refus détaillés dans les tables système Unity Catalog pour surveiller les requêtes bloquées.

Concepts fondamentaux du contrôle d'entrée basé sur le contexte

Sources réseau

Une source réseau définit l'origine des requêtes. Les types pris en charge incluent :

Politique d'accès public :

• Toutes les adresses IP publiques : Toute source Internet publique.
• IPs sélectionnées : Adresses IPv4 spécifiques ou plages CIDR.
• Plateformes partenaires (Bêta) : adresses IP que les applications tierces (Power BI, Tableau Cloud et plateforme dbt) utilisent pour se connecter à Databricks. Databricks gère et met à jour ces listes d’adresses IP automatiquement.

Accès inter-workspace (bêta) : contrôle quels Workspace sources peuvent atteindre ce Workspace via le trafic Serverless, en utilisant les mêmes identités et règles d'autorisation et de refus que les autres sources réseau.

• Workspaces sélectionnés : uniquement les workspaces dont vous listez les ID.

Vous pouvez également laisser cette politique en mode compatibilité ; dans ce cas, elle ne régit pas l'entrée inter-workspace et les contrôles réseau préexistants du workspace s'appliquent. Pour configurer l'accès inter-workspace à la fois pour l'entrée et la sortie, et pour examiner ses limitations, voir Accès inter-workspace.

Types d'accès

Les règles s'appliquent à différentes portées de requêtes entrantes. Chaque portée représente une catégorie de requêtes entrantes que vous pouvez autoriser ou refuser :

Types d'accès aux politiques au niveau du Workspace :

• Workspace UI : Accès au Workspace via le navigateur.

• API : programmatic access through Databricks APIs, including SQL Endpoint (JDBC / ODBC). You can target any of the following:

  • Toutes les APIs.
  • Une portée d'API spécifique, utilisant IN . Par exemple, vous pouvez spécifier des applications, un tableau de bord ou le service de modèles.
  • Tous les champs d’application API, à l’exception de ceux sélectionnés, en utilisant NOT IN .

• Exécution d’applications : Autoriser ou refuser l’accès aux déploiements Databricks Apps. See Databricks Apps. Seule l’option d’identité Tous les utilisateurs et Service Principal est prise en charge pour ce type d’accès.

Identités

Les règles peuvent cibler différents types d’identité. Pour les types d'accès **runtime d'applications** et **runtime Lakebase**, la seule option prise en charge est **Tous les utilisateurs et les principaux de service**.

• Tous les utilisateurs et Databricks Service Principal : utilisateurs humains et automatisation.
• Tous les utilisateurs : Utilisateurs humains uniquement.
• Tous les Service Principal Databricks : identités d'automatisation uniquement.
• Identités sélectionnées : Utilisateurs spécifiques ou Service Principals Databricks.

Évaluation des règles

• default deny : en mode restreint, l'accès est refusé sauf s'il est explicitement autorisé.
• Refuser avant d'autoriser : Les règles de refus vous permettent de définir des exceptions à vos règles d'autorisation.
• default Workspace-level policy : Chaque compte dispose d’une politique d’entrée par default au niveau du Workspace appliquée à tous les Workspaces éligibles sans affectation de politique explicite.

Modes d'application

Les politiques d'entrée basées sur le contexte permettent deux modes :

• Appliqué à tous les produits : Databricks applique activement les règles et bloque les requêtes non conformes.
• Mode de simulation pour tous les produits : Databricks enregistre les violations, mais ne bloque pas les requêtes. Utilisez ce mode pour évaluer l'impact de la politique avant son application.

remarque

Une politique réseau ne prend en charge qu’un seul mode d’application à la fois.

Audit

Les requêtes refusées ou simulées sont enregistrées dans la table système system.access.inbound_network. Si vous n'avez pas accès aux tables système, un administrateur de métastore peut vous accorder des autorisations. Consultez Accorder l'accès aux tables système.

Chaque entrée de Logs comprend :

• Heure de l'événement
• ID du Workspace
• Étiquette de la règle (de la règle ayant refusé la requête)
• Type de requête
• Identité
• Source réseau
• Type d'accès (DENIED ou DRY_RUN_DENIAL)

Interrogez ces logs pour vérifier que vos règles fonctionnent comme prévu et pour détecter les tentatives d'accès inattendues.

Relation avec d'autres contrôles

• Listes d'accès IP du Workspace : évaluées avec la politique d'entrée basée sur le contexte à l'aide d'un ET logique, sans séquence stricte entre les deux. Une requête est autorisée uniquement si la liste d’accès IP et la politique d’entrée le permettent. Les listes d’accès IP du Workspace peuvent restreindre davantage l’accès, mais ne peuvent pas l’élargir.
• Contrôle de la sortie Serverless : complète les politiques d'entrée en contrôlant le trafic réseau sortant du compute Serverless. Voir Gérer les politiques de réseau.
• Accès inter-workspace : contrôle quels workspaces sources peuvent atteindre un workspace via le trafic serverless, en plus des contrôles d'identité et de source réseau présents sur cette page. Voir Accès inter-workspace.
• Listes d'accès IP des destinataires OpenSharing : l'entrée basée sur le contexte ne s'applique pas aux listes d'accès IP des destinataires OpenSharing. Il s'agit d'un contrôle distinct pour les destinataires ouverts que les fournisseurs configurent par destinataire. Voir Restreindre l'accès des destinataires OpenSharing à l'aide de listes d'accès IP (partage Databricks vers Open).

astuce

Pour réduire la complexité, Databricks vous recommande d’utiliser la politique d’entrée basée sur le contexte comme seul moteur de politique, plutôt que de maintenir également des listes d’accès IP.

• Connectivité privée front-end : appliquée parallèlement aux politiques d'entrée lorsque l' accès public est activé est True . Si l' accès public activé est False , tout accès public entrant est bloqué et les stratégies d'entrée ne sont pas évaluées. Voir Gérer les paramètres d'accès privé.

Bonnes pratiques

• Commencez par le mode de simulation pour observer les impacts sans interrompre l’accès.
• Utilisez des règles basées sur l'identité, si possible pour les clients SaaS qui font tourner les adresses IP.
• Appliquez d'abord les règles de refus aux Service Principals Databricks privilégiés afin de limiter la zone affectée.
• Maintenez les noms de politique clairs et cohérents.

remarque

Le contrôle d'ingestion basé sur le contexte n'est pas disponible dans la région GCP Middle East Central 2.