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

Cette page offre un aperçu du contrôle d’entrée basé sur le contexte, incluant ses concepts fondamentaux, les modes d’application, l’audit, et la manière dont il interagit avec d’autres contrôles réseau. Pour configurer les politiques, voir Gérer les politiques d’entrée contextuelles. Pour le contrôle de sortie serverless, consultez 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’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.

Politiques au niveau de l’espace de travail vs politiques au niveau du compte

Le contrôle d’entrée basé sur le contexte utilise deux types de politiques. Les politiques au niveau de l’espace de travail régissent l’accès aux espaces de travail. Les politiques au niveau du compte régissent l’accès aux ressources au niveau du compte, telles que la console de compte et le Genie One au niveau 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é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) : Contrôles sur les espaces de travail source qui peuvent accéder à cet espace via un trafic sans serveur, en utilisant les mêmes identités et les mêmes règles d’autorisation et de refus que d’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 l’un des éléments suivants :
  • Toutes les API.
  • Un périmètre API spécifique, utilisant IN. Par exemple, vous pouvez spécifier des applications, un tableau de bord ou un service de modèle.
  • Tous les champs d’application d’API sauf ceux sélectionnés, utilisant NOT IN.
• 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 à la politique au niveau du compte (Bêta) :

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

Databricks recommande de commencer en test à blanc pour observer l’impact de la stratégie avant de la faire 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)

Les refus de la politique au niveau du compte sont enregistrés avec workspace_id défini sur 0.

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.

Gérer les politiques d’entrée contextuelles

Configurez et attachez des politiques au niveau correspondant à la ressource que vous souhaitez protéger :

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, voir Gérer les politiques d’entrée contextuelles du compte.

API et Terraform

En plus de la console de compte, vous pouvez gérer les politiques d’entrée contextuelles de manière programmatique :

• API REST : Utilisez l’API Azure Databricks REST pour gérer les politiques réseau.
• Terraform : Utilisez le fournisseur Azure Databricks Terraform pour gérer les politiques d’entrée comme infrastructure en tant que code.

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.

Availability