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

Note

Cette fonctionnalité nécessite le niveau Premium.

Important

Les fonctionnalités suivantes de l’entrée contextuelle sont en version Bêta :

• Politiques d’entrée contextuelles pour votre compte : Appliquer les politiques d’accès à la console du compte, au niveau du compte Genie One et aux API du compte.
• Plateformes partenaires en tant que source réseau : autorisez les adresses IP que les applications tierces (Power BI, Tableau Cloud et dbt platform) utilisent pour se connecter à Azure Databricks. Azure Databricks gère et met à jour ces listes IP automatiquement.
• Les rejets de règles au niveau du compte ne sont pas encore journalisés.

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.

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.

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. Consultez les instances 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.

Note

Une stratégie réseau ne prend en charge qu’un seul mode d’application à la fois.

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.

Tip

Pour réduire la complexité, Databricks recommande d’utiliser la stratégie d’entrée basée sur le contexte en tant que seul moteur de stratégie plutôt que de conserver des listes d’accès IP.

• Connectivité privée frontale : appliquée en même temps que les stratégies d’entrée lorsqu’Autoriser l’accès au réseau public a la valeur Activé. Si l’accès au réseau public est désactivé, toutes les entrées publiques sont bloquées et les stratégies d’entrée ne sont pas évaluées. Consultez Configurer une liaison privée entrante.
• 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.

Note

Le contrôle d’entrée basé sur le contexte n’est pas disponible dans la région Inde Ouest Azure.