Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les stratégies contextuelles d’Azure Databricks fournissent un cadre de sécurité unifié pour gérer à la fois le trafic entrant et sortant de vos espaces de travail et de vos ressources au niveau du compte (par exemple, la console du compte et Genie One au niveau du compte). Les stratégies au niveau de l’espace de travail sont configurées sous stratégies au niveau de l’espace de travail, avec une stratégie au niveau de l’espace de travail par défaut affectée à tous les espaces de travail sans affectation explicite. La stratégie au niveau du compte est configurée séparément sous stratégie au niveau du compte ; son ID de stratégie est account-policy.
Avec l’entrée basée sur le contexte, les administrateurs peuvent restreindre l’accès au niveau de l’espace de travail et au niveau du compte en fonction d’une combinaison d’identité, de source réseau et de type de requête. Les stratégies de sortie serverless étendent ce contrôle au trafic sortant en limitant les serverless workloads aux destinations autorisées. Ensemble, ces stratégies réseau permettent de s’assurer que l’accès utilisateur et le déplacement des données restent dans des limites approuvées au sein de votre organisation.
Les stratégies réseau basées sur le contexte complètent ces fonctionnalités de sécurité existantes :
- Contrôle d’entrée basé sur le contexte :
- Listes d’accès IP de l’espace de travail
- Listes d’accès IP de compte
- Private Link entrant (avec les paramètres d’accès privé)
- Contrôle des flux sortants sans serveur :
- Liaison pricée sortante (utilisant des configurations de connectivité réseau)
Avantages
Les stratégies réseau d’entrée basées sur le contexte offrent les avantages suivants à votre sécurité réseau :
- Sécurité renforcée : atténuer les risques d’exfiltration de données et d’accès non autorisés.
- Contrôle prenant en charge les identités : prendre en charge les clients SaaS sans plages d’adresses IP stables à l’aide de règles basées sur l’identité.
- Application flexible : appliquez différentes règles à différents types de demandes, sources et identités.
- Gestion centralisée : configurez une fois au niveau du compte, appliquez-les à plusieurs espaces de travail.
- Test sécurisé : utilisez le mode simulation pour tester les effets de la stratégie avant son application complète.
Types de stratégie comparés
Les stratégies réseau basées sur le contexte incluent deux types : le contrôle d’entrée et le contrôle de sortie. Le tableau suivant résume les principales différences :
| Caractéristique | Contrôle d’entrée | Contrôle de sortie |
|---|---|---|
| Qu’est-ce qu’il contrôle ? | Requêtes entrantes vers les points de terminaison Azure Databricks au niveau de l’espace de travail et du compte. | Connexions sortantes des services informatiques sans serveur vers des destinations externes. |
| Cas d’usage principal | Limitez les utilisateurs qui peuvent accéder à votre espace de travail et aux ressources au niveau du compte, à partir de l’endroit où et de ce qu’ils peuvent atteindre. | Empêchez l’exfiltration des données en contrôlant les ressources externes auxquelles le calcul serverless peut se connecter. |
| Critères de stratégie | Identité (plusieurs utilisateurs ou plusieurs principes de service) Source réseau (plage CIDR, points de terminaison privés inscrits) Type d’accès : pour les espaces de travail (interface utilisateur de l’espace de travail, API, runtime d’applications, runtime Lakebase) ; pour le compte (interface utilisateur du compte, API de compte) |
Emplacements autorisés Noms de domaine complets (FQDNs) Conteneurs de stockage cloud |
| Journalisation d’audit |
system.access.inbound_network table système |
system.access.outbound_network table système |
Fonctionnement des stratégies basées sur le contexte
Avec le contrôle d’entrée, vous pouvez :
- Arrêtez l’accès à partir de réseaux non approuvés en exigeant des informations d’identification valides et une source de réseau approuvée.
- Autoriser les outils d’automatisation SaaS avec des adresses IP dynamiques à l’aide de règles basées sur des identités plutôt que des listes d’autorisation IP.
- Limitez les opérations sensibles à l’interface utilisateur tout en autorisant un accès à l’API plus large.
- Limitez les entités de service à privilèges élevés uniquement aux plages de réseau d’entreprise.
Avec le contrôle de sortie, vous pouvez :
- Empêchez l’exfiltration des données en limitant les API externes que le calcul serverless peut atteindre.
- Autorisez la connectivité uniquement aux compartiments de stockage cloud approuvés et aux bases de données externes.
- Bloquez les connexions sortantes vers des destinations non autorisées tout en autorisant les intégrations requises.
- Appliquez la conformité en limitant le déplacement des données aux régions et services approuvés.
| Guide de configuration | Descriptif |
|---|---|
| Configurer des stratégies d’entrée | Configurez les règles d’autorisation et de refus qui combinent l’identité, la source réseau et le type d’accès pour contrôler les demandes entrantes dans votre espace de travail. |
| Configurer des stratégies de sortie | Définissez les règles de connexion sortante pour contrôler les destinations externes auxquelles vos ressources de calcul serverless peuvent atteindre. |
Modes d’application
Les stratégies basées sur le contexte ont deux modes d’application différents :
- Mode appliqué : les règles sont appliquées activement. Les requêtes en violation sont bloquées.
- Mode exécution sèche : les violations sont journalisées, mais pas bloquées. Utilisez ce mode pour tester les impacts de stratégie avant l’application.
Databricks recommande de commencer par le mode exécution sèche pour éviter les interruptions d’accès involontaires.
Journalisation d’audit
Azure Databricks journalise toutes les évaluations de stratégie pour la conformité et la surveillance :
- Entrée : consigné dans la table système
system.access.inbound_network. - Sortie : consigné dans la table système
system.access.outbound_network.
Interrogez ces fichiers de journalisation pour valider l’efficacité de la stratégie et détecter les tentatives d’accès non autorisées.
Interaction des stratégies avec d’autres contrôles
- Listes d’accès IP : les listes d’accès IP et les stratégies d’entrée basées sur le contexte d’accès public doivent autoriser une demande. Si vous désactivez l’accès public dans vos paramètres d’accès privé, le système refuse toutes les demandes publiques, quelles que soient les règles de stratégie d’entrée.
-
Connectivité privée :
- Pour les stratégies d’espace de travail et pour un point de terminaison enregistré donné, les points de terminaison autorisés soit dans l’entrée basée sur le contexte, soit dans le point de terminaison privé
databricks_ui_apisont 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 terminaisondatabricks_ui_api, alors aucun point de terminaisondatabricks_ui_apine peut accéder à Azure Databricks. - Pour la politique au niveau du compte, l’entrée basée sur le contexte est la seule source de vérité pour la politique d’accès privé.
- Pour les stratégies d’espace de travail et pour un point de terminaison enregistré donné, les points de terminaison autorisés soit dans l’entrée basée sur le contexte, soit dans le point de terminaison privé
- Profils de sécurité : les stratégies basées sur le contexte fournissent des contrôles au niveau du réseau qui complètent la gouvernance des calculs et des données.
Note
L’entrée basée sur le contexte est généralement disponible (GA). Certaines fonctionnalités associées 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. Les refus de ces polices ne sont pas enregistrés.
- 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.
Meilleures pratiques
- Commencez par le mode exécution sèche pour valider le comportement de la stratégie avant l’application.
- Utilisez des règles basées sur des identités pour les clients SaaS avec des adresses IP dynamiques.
- Appliquez d’abord des règles de refus aux principaux de service à privilèges élevés pour limiter les risques.
- Surveillez régulièrement les journaux d’audit pour détecter des modèles d’accès inattendus.
- Testez les stratégies de sortie pour vous assurer que les ressources externes requises restent accessibles.
- Utilisez des noms de stratégie descriptifs pour la maintenance à long terme.