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

info

Aperçu

La politique d'ingestion basée sur le contexte au niveau du compte est en Beta.

remarque

Cette fonctionnalité nécessite le niveau Enterprise.

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.

Politique d'accès privé :

• Tous les endpoints privés enregistrés : tout endpoint privé enregistré dans le compte.
• Endpoints privés sélectionnés : endpoints privés spécifiques enregistrés dans le compte.

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.

• Environnement d'exécution Lakebase : Connexions aux instances de base de données Lakebase. Consultez les instances Lakebase. Seule l’option d’identité Tous les utilisateurs et Service Principal est prise en charge pour ce type d’accès.

Types d'accès à la politique au niveau du compte :

• Interface utilisateur du compte : Accès par navigateur aux ressources au niveau du compte (par exemple, la console du compte et Genie One au niveau du compte).
• API de compte : Accès programmatique par le biais des APIs de compte Databricks.

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**.

Dans la politique au niveau du compte, la seule option prise en charge est Tous les utilisateurs et Service Principals .

• 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.

remarque

Limitation de l’aperçu bêta

Les refus de politique au niveau du compte ne sont pas encore enregistrés.

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.

• Listes d’accès IP au compte : Évaluées avec la politique d’ingestion basée sur le contexte au niveau du compte à 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 au niveau du compte l’autorisent. Les listes d'accès IP de compte peuvent affiner davantage l'accès, mais ne peuvent pas l'élargir.
• Bascule d'accès public du paramètre d'accès privé : appliquée parallèlement aux stratégies d'entrée lorsque l' accès public 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é.
• Connectivité privée front-end :
  • Pour que le trafic soit autorisé, les paramètres d'accès privé et l'entrée basée sur le contexte doivent tous deux autoriser l'endpoint. Par défaut, l'entrée basée sur le contexte est définie sur Autoriser l'accès depuis tous les private endpoints , ce qui reporte la décision d'accès au paramètre d'accès privé du workspace. Si vous souhaitez configurer des politiques d'accès privé basées sur le contexte, assurez-vous que votre workspace dispose d'un paramètre d'accès privé attaché, avec tous les endpoints privés enregistrés autorisés (voir plus ci-dessous). Ceci déférera la décision d’accès à la politique d’ingestion basée sur le contexte de votre workspace.
  • Pour la politique au niveau du compte, l'entrée basée sur le contexte est la source unique de vérité pour la politique 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.