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

remarque

Cette fonctionnalité nécessite le niveau Enterprise.

info

Aperçu

Les plateformes partenaires en tant que source de réseau sont en version bêta. Autorisez les adresses IP qu'utilisent les applications tierces (Power BI, Tableau Cloud et dbt platform) pour se connecter à Databricks. Databricks gère et met à jour automatiquement ces listes d'adresses IP.

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.

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 : Accès programmatique via les APIs Databricks, y compris les SQL endpoints (JDBC / ODBC). Vous pouvez cibler toutes les API ou un périmètre d'API spécifique, tel que les applications, le tableau de bord ou le service de modèle.
• 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.

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.