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

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 des stratégies d’entrée, consultez Gérer les stratégies 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’accès entrant basé sur le contexte fonctionne avec les listes d’accès IP et la connectivité privée du frontal pour permettre aux administrateurs du compte de définir des règles d’autorisation et de refus qui combinent qui effectue la requête, d’où elle est effectuée et à quoi ils peuvent accéder dans Azure Databricks. Cela garantit que seules les combinaisons approuvées d’identité, de type de requête et de source réseau peuvent atteindre votre espace de travail. Le contrôle d’entrée basé sur le contexte est configuré au niveau du compte. Une stratégie unique peut régir plusieurs espaces de travail.

À l’aide d’une entrée basée sur le contexte, vous pouvez :

• Arrêtez l’accès à partir de réseaux non approuvés en exigeant un deuxième facteur, une source de réseau approuvée, en plus des informations d’identification.
• Autorisez l’accès aux clients SaaS ne disposant pas d’adresses IP de sortie fixes en vous basant sur l’identité plutôt que sur des plages d’adresses IP.
• Limitez l’accès en autorisant les sources moins approuvées à utiliser uniquement certaines étendues telles que Azure Databricks API ou l’interface utilisateur de l’espace de travail.
• Protéger l’automatisation privilégiée : limiter uniquement les principaux de service à haut niveau de valeur aux réseaux à haut niveau de fiabilité.
• Auditez efficacement : capturez des journaux détaillés des refus dans les tables système d’Unity Catalog pour surveiller les requêtes bloquées.

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

Sources réseau

Une source réseau définit l’origine des requêtes. Les types pris en charge comprennent les suivants :

Stratégie d’accès public :

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

Stratégie d’accès privé :

• Tous les points de terminaison privés inscrits : tout point de terminaison privé inscrit dans le compte.
• Points de terminaison privés sélectionnés : points de terminaison privés inscrits spécifiques dans le compte.

• Espace de travail Azure Private Link: Uniquement dans les règles de refus de la stratégie d’espace de travail. Refuse l’accès à tous les databricks_ui_api points de terminaison.
• Tout accès privé : uniquement dans les règles de refus de la stratégie de l’espace de travail. Refuse l'accès à tous les databricks_ui_api et aux points de terminaison enregistrés.

Accès inter-espaces de travail (bêta) : Définit quels espaces de travail sources peuvent accéder à cet espace de travail via un trafic sans serveur, en utilisant les mêmes identités ainsi que les mêmes règles d’autorisation et de refus que les autres sources réseau.

• Espaces de travail sélectionnés : Uniquement les espaces de travail dont vous listez les identifiants.

Vous pouvez également laisser cette politique en mode compatibilité, auquel cas elle ne régit pas l’entrée inter-espaces de travail et les contrôles réseau préexistants de l’espace de travail s’appliquent. Pour configurer l’accès inter-espaces de travail des deux côtés entrée et sortie, et pour examiner ses limites, voir Accès inter-espaces de travail.

Types d’accès

Les règles s’appliquent à différentes étendues de requête entrantes. Chaque étendue représente une catégorie de requêtes entrantes que vous pouvez autoriser ou refuser :

Types d’accès aux stratégies au niveau de l’espace de travail :

• Interface utilisateur de l’espace de travail : accès du navigateur à l’espace de travail.
• API : accès programmatique via Azure Databricks API, y compris les points de terminaison SQL (JDBC/ODBC). Vous pouvez cibler toutes les API ou une étendue d’API spécifique, comme les applications, le tableau de bord ou le service de modèle.
• Runtime des applications : Autoriser ou refuser l’accès aux déploiements Databricks Apps. Consultez Databricks Apps. Seule l’option d’identité tous les utilisateurs et les principaux de service est prise en charge pour ce type d’accès.

• Runtime Lakebase : Connexions aux instances de base de données Lakebase. Voir Lakebase. Seule l’option d’identité tous les utilisateurs et les principaux de service est prise en charge pour ce type d’accès.

Types d’accès aux stratégies au niveau du compte :

• Interface utilisateur du compte : Accès du navigateur aux ressources au niveau du compte (par exemple, la console de compte et le niveau du compte Genie One).
• API de compte : accès par programmation via Azure Databricks API de compte.

Identities

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

Dans la stratégie définie au niveau du compte, la seule option prise en charge est Tous les utilisateurs et principaux de service.

• Tous les utilisateurs et principaux de service : utilisateurs humains et automatisation.
• Tous les utilisateurs : utilisateurs humains uniquement.
• Tous les principaux de service : identités d’automatisation uniquement.
• Identités sélectionnées : utilisateurs ou principaux de service spécifiques.

Évaluation de règle

• Refus par défaut : en mode restreint, l’accès est refusé, sauf autorisation explicite.
• Refuser avant d’autoriser : les règles de refus vous permettent de définir des exceptions à vos règles d’autorisation.
• Stratégie au niveau de l’espace de travail par défaut : chaque compte a une stratégie d’entrée au niveau de l’espace de travail par défaut appliquée à tous les espaces de travail éligibles sans attribution de stratégie explicite.

Modes d’application

Les stratégies d’entrée basées sur le contexte activent deux modes :

• Appliqué à tous les produits : Azure Databricks applique activement des règles et bloque les demandes non conformes.
• Mode d’essai pour tous les produits : Azure Databricks consigne les violations, mais ne bloque pas les requêtes. Utilisez ce mode pour évaluer l’impact de la stratégie avant de l’appliquer.

Auditing

Les demandes refusées ou de test sont consignées dans la table système system.access.inbound_network. Si vous n’avez pas accès aux tables système, un administrateur de metastore peut vous accorder des autorisations. Consultez Octroyer un accès aux tables système.

Chaque entrée de journal inclut les éléments suivants :

• Heure de l’événement
• ID de l’espace de travail
• Étiquette de règle (de la règle qui a refusé la demande)
• Type de requête
• Identité
• Source réseau
• Type d’accès (REFUSÉ ou DRY_RUN_DENIAL)

Interrogez ces journaux afin de vérifier que vos règles fonctionnent comme prévu et de détecter des tentatives d’accès inattendues.

Relation avec d’autres contrôles

• Listes d’accès IP de l’espace de travail : sont évaluées conjointement avec la stratégie d’accès entrant basée sur le contexte à l’aide d’un ET logique, sans ordre strict entre les deux. Une demande est autorisée uniquement si la liste d’accès IP et la stratégie d’entrée l’autorisent. Les listes d’accès IP de l’espace de travail peuvent restreindre davantage l’accès, mais ne peuvent pas l’élargir.
• Contrôle de sortie serverless : complète les stratégies d’entrée en contrôlant le trafic réseau sortant à partir du calcul serverless. Consultez Gérer les stratégies réseau.
• Accès inter-espaces de travail : Contrôle quels espaces de travail source peuvent atteindre un espace de travail via un trafic serverless, en plus des contrôles source réseau et d’identité sur cette page. Voir l’accès inter-espaces de travail.
• 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. Ce sont des contrôles séparés pour les destinataires ouverts que les fournisseurs configurent par destinataire. Consultez Restreindre l’accès des destinataires d’Open Sharing à l’aide de listes d’accès IP (partage Databricks vers Open).

• Connectivité privée front-end : Pour les politiques d’espace de travail et un point de terminaison enregistré donné, les points de terminaison autorisés soit dans l’entrée contextuelle, soit dans le databricks_ui_api point de terminaison privé sont autorisés. Cependant, si la stratégie d’entrée basée sur le contexte de l’espace de travail comporte une règle de refus qui bloque tous les points de terminaison databricks_ui_api, alors aucun point de terminaison databricks_ui_api ne peut accéder à Azure Databricks. Voir Configurer le lien Private Link entrant pour les espaces de travail.
• Bouton bascule Autoriser l’accès au réseau public : lorsque Autoriser l’accès au réseau public est activé, les listes de contrôle d’accès IP de l’espace de travail sont prises en compte. Sinon, toutes les entrées publiques sont bloquées et les stratégies d’entrée publique de l’espace de travail ne sont pas évaluées.

Meilleures pratiques

• Commencez par le mode de fonctionnement sec pour observer les impacts sans interrompre l’accès.
• Utilisez des règles basées sur des identités lorsque cela est possible pour les clients SaaS qui font pivoter des adresses IP.
• Appliquez d’abord des règles de refus aux principaux de service privilégiés pour limiter la zone affectée.
• Conservez les noms de stratégie clairs et cohérents.