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’entrée basé sur le contexte fonctionne en même temps que 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 les appelants , à partir de l’endroit où ils appellent et de ce qu’ils peuvent atteindre 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, ce qui garantit une mise en œuvre cohérente au sein de votre organisation.

À 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.
• Autoriser l’accès pour les clients SaaS sans adresses IP de sortie stables en utilisant l’identité plutôt que les plages d’adresses IP.
• Limitez l’accès en autorisant des sources moins approuvées à utiliser uniquement certaines étendues telles que les API Databricks 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é.
• Audit efficace : capturez les journaux de refus détaillés dans les tables système de Unity Catalog pour surveiller les demandes 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 :

• Toutes les adresses IP publiques : toute source Internet publique.
• Adresses IP sélectionnées : adresses IPv4 spécifiques ou plages CIDR.

Types d’accès

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

• Interface utilisateur de l’espace de travail : accès du navigateur à l’espace de travail.
• API : Accès par programmation via les API Databricks, y compris les points de terminaison SQL (JDBC/ODBC).
• Applications : autorisez ou refusez 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.

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

Identities

Les règles peuvent cibler différents types d’identité. Pour les types d’accès Apps et Lakebase Compute , 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 choisis par l’administrateur.

Évaluation de règle

• Refus par défaut : en mode restreint, l’accès est refusé, sauf autorisation explicite.
• Refuser avant d’autoriser : si les deux types de règles existent, les règles de refus sont prioritaires.
• Stratégie par défaut : chaque compte a une stratégie d’entrée 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 prennent en charge deux modes :

• Appliqué pour tous les produits : les règles sont appliquées activement et les demandes de violation sont bloquées.
• Mode exécution sèche pour tous les produits : les violations sont enregistrées, mais les demandes ne sont pas bloquées, ce qui vous permet d’évaluer l’impact de la stratégie en toute sécurité.

Auditing

Les demandes refusées ou à exécution sèche sont consignées dans la system.access.inbound_network table système. Chaque entrée de journal inclut les éléments suivants :

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

Vous pouvez interroger ces journaux pour vérifier que vos règles sont appliquées correctement et pour détecter les tentatives d’accès inattendues.

Relation avec d’autres contrôles

• Listes d’accès IP de l’espace de travail : évaluée avant que la stratégie d’entrée basée sur le contexte autorise une demande. Les deux doivent autoriser la demande. 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.

• Connectivité privée frontale : appliquée en même temps que les stratégies d’entrée lorsque l’accès au réseau public est 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 du front-end.

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 le rayon d’explosion.
• Conservez les noms de politiques clairs et cohérents pour une maintenance à long terme.