Contrôle d'entrée basé sur le contexte
L'entrée basée sur le contexte nécessite l'offre Entreprise. L'entrée basée sur le contexte est généralement disponible (GA), à l'exception de l'accès privé aux Workspace et aux politiques au niveau du compte, qui sont en bêta.
Cette page donne un aperçu du contrôle d’accès entrant basé sur le contexte, notamment ses concepts fondamentaux, ses modes d’application, l’audit et son interaction avec d’autres contrôles réseau. Pour configurer les politiques, consultez la section Gérer les politiques d’accès entrant basées sur le contexte. Pour le contrôle de sortie serverless, consultez la section Qu’est-ce que le contrôle de sortie serverless ?.
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 frontale 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 des combinaisons fiables d’identité, de type de demande et de source peuvent atteindre votre workspace. Le contrôle d’entrée basé sur le contexte est configuré au niveau du compte. Une seule politique peut régir plusieurs Workspace.
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.
- Autorisez l’accès aux clients SaaS (outil/solution/technologie/plateforme as a Service) sans IP de sortie statiques en basant l’authentification sur l’identité plutôt que sur des plages d’IP, ou en autorisant une plateforme partenaire que Databricks maintient à jour.
- 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.
Politiques au niveau du workspace et au niveau du compte
Le contrôle d’entrée basé sur le contexte utilise deux types de politiques. Les politiques au niveau du Workspace régissent l’accès aux workspaces. Les politiques au niveau du compte régissent l’accès aux ressources au niveau du compte, telles que la console du compte et Genie One au niveau du compte.
Attribut | Politique au niveau du workspace | Politique au niveau du compte |
|---|---|---|
Contrôle l'accès à | Espaces de travail | Ressources au niveau du compte (console du compte, Genie One au niveau du compte, APIs du compte) |
Types d’accès | Interface utilisateur du workspace, API, environnement d'exécution des apps, environnement d'exécution Lakebase | UI du compte, API du compte |
Identités | Tous les utilisateurs et Service Principal, tous les utilisateurs, tous les Service Principal, ou identités sélectionnées | Tous les utilisateurs et service principals uniquement |
Sources | Public, privé et inter-workspace | Public et privé |
Politique default | Une politique au niveau du workspace default s’applique aux workspaces sans attribution explicite | Une seule politique fixe ( |
Journalisation des refus | Connexion | Connexion à |
Gérer | Gérer les politiques d’accès entrant basées sur le contexte du workspace | Gérer les politiques d’accès entrant basées sur le contexte du compte |
Les politiques au niveau du compte sont en version bêta. Pour commencer, activez Context-Based Ingress : Account Policy .
Concepts fondamentaux du contrôle d'entrée basé sur le contexte
Sources
Une source définit l'origine des demandes.
Les politiques d’accès public prennent en charge les sources suivantes :
- Toutes les adresses IP publiques : Toute source Internet publique.
- IPs sélectionnées : Adresses IPv4 spécifiques ou plages CIDR.
- Plateformes partenaires : applications tierces que Databricks tient à jour pour vous. Pour Power BI, Tableau Cloud, dbt Cloud, ChatGPT et Claude, Databricks synchronise les plages IP publiées par le partenaire. Pour les applications Databricks Genie pour Slack et Microsoft Teams, Databricks fait correspondre l’ID client OAuth de l’application. Voir Autoriser les plateformes partenaires dans les politiques d’entrée basées sur le contexte.
Les politiques d’accès privé prennent en charge les sources suivantes :
- 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.
Bêta
L'accès privé aux Workspace utilisant l'entrée basée sur le contexte est en Bêta. Pour l'utiliser, un administrateur de compte doit activer Entrée basée sur le contexte : politiques d'accès privé aux Workspace sur la page Aperçus de la console de compte. Consultez Gérer les aperçus au niveau du compte.
Accès inter-Workspace (bêta) : contrôle les Workspace sources pouvant atteindre ce Workspace via le trafic Serverless, en utilisant les mêmes identités et les mêmes règles d’autorisation et de refus que les autres sources.
- 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 :
Les politiques au niveau du workspace prennent en charge les types d'accès suivants :
-
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.
-
Environnement d’exécution Lakebase : Connexions aux instances de base de données Lakebase. See Lakebase. Seule l’option d’identité All users and service principals est prise en charge pour ce type d’accès.
Types d’accès aux politiques au niveau du compte (bêta) :
- 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.
Une politique réseau ne prend en charge qu’un seul mode d’application à la fois.
Databricks recommande de commencer en mode simulation pour observer l’impact de la politique avant de l’activer.
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
- Type d'accès (DENIED ou DRY_RUN_DENIAL)
Les refus de la politique au niveau du compte sont enregistrés avec workspace_id défini sur 0.
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 les Workspace sources pouvant atteindre un Workspace via le trafic Serverless, en plus des contrôles de source et d’identité 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).
Pour réduire la complexité, Databricks vous recommande d'utiliser la politique d'entrée basée sur le contexte comme unique moteur de politique plutôt que de maintenir également des listes d'accès IP. Si vos workspaces possèdent déjà des listes d'accès IP, consultez la page Migrer les listes d'accès IP du workspace vers une entrée basée sur le contexte.
- 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é conjointement aux politiques d’entrée lorsque Accès public est défini sur Géré par vos politiques d’entrée Databricks . Si Accès public est défini sur Bloquer l’accès au réseau public , le trafic entrant public est bloqué et les politiques d’entrée ne sont pas évaluées. Consultez 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 default, l'entrée basée sur le contexte est définie sur Autoriser l'accès depuis tous les Endpoint privés , ce qui renvoie la décision d'accès au paramètre d'accès privé du Workspace. Cette option couvre jusqu'à 200 Endpoint privés enregistrés. Pour augmenter la limite, contactez votre équipe de compte. Pour configurer des politiques d'accès privé basées sur le contexte, attachez un paramètre d'accès privé à votre Workspace qui autorise tous les Endpoint privés enregistrés. Cela renvoie la décision d'accès à la politique d'entrée basée sur le contexte de votre workspace. Voir Configurer la politique d'accès privé.
- 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é.
Gérer les politiques d’entrée basées sur le contexte
Configurez et attachez des politiques au niveau qui correspond à la ressource que vous souhaitez protéger :
-
- Gérer les politiques d’accès entrant basées sur le contexte du workspace
- Créez une politique au niveau du workspace, configurez les règles publiques, privées et inter-workspace, et associez-la aux workspaces.
-
- Autoriser les plateformes partenaires
- Autorisez Power BI, Tableau Cloud, dbt Cloud, ChatGPT, Claude et les applications Databricks Genie pour Slack et Microsoft Teams sans avoir à maintenir des adresses IP de partenaires.
-
- Accès inter-workspace
- Contrôlez le trafic réseau serverless entre les workspaces à l'aide de règles d'entrée et de sortie inter-workspace.
Pour configurer les règles publiques et privées sur la politique au niveau du compte qui protège les ressources au niveau du compte, consultez Manage account context-based ingress policies.
API et Terraform
Outre la console de compte, vous pouvez gérer les politiques d’entrée basées sur le contexte par programmation :
- API REST : utilisez l’API REST Databricks pour gérer les politiques réseau.
- Terraform : utilisez le fournisseur Databricks Terraform pour gérer les politiques d’entrée en tant qu’infrastructure sous forme de code.
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.
Disponibilité
Le contrôle d’entrée basé sur le contexte est disponible dans toutes les régions.