Environnement isolé

L’architecture de l’environnement isolé hérite de la base de référence de connectivité renforcée et ajoute deux exigences : l’accès à l’espace de travail privé et un pare-feu externe requis. L’accès à l’espace de travail est uniquement possible via un VPN ou un Private Link entrant, et jamais via l’Internet public. Toutes les sorties de calcul classiques transitent par le pare-feu pour l’inspection et l’application des stratégies.

Cette architecture a :

• Isolation réseau complète : tous les flux de trafic transitent par des connexions privées.
• Accès à l’espace de travail privé : uniquement via un VPN ou un lien privé entrant. L’espace de travail est inaccessible à partir de l’Internet public.
• Inspection requise du trafic sortant : inspection par pare-feu de l’ensemble du trafic sortant des machines virtuelles classiques.
• Prévention de l’exfiltration des données : les contrôles de couche réseau bloquent le transfert de données non autorisé.

Utilisez cette architecture quand :

• L’accès à l’espace de travail doit être privé, par exemple via VPN ou Private Link entrant.
• Gestion des données dans des secteurs hautement réglementés, par exemple des services financiers, des soins de santé, du gouvernement.
• Les frameworks de conformité nécessitent des contrôles de sortie (par exemple, SOC 2, HIPAA, PCI DSS et FedRAMP).
• Implémentation d’infrastructures de sécurité de confiance zéro d’entreprise.
• La prévention de l’exfiltration des données est requise.

Prerequisites

• Azure Azure Databricks Premium avec un espace de travail injecté dans un réseau virtuel.

• Infrastructure VPN existante ou connectivité Private Link entrante.
• Pare-feu ou appliance virtuelle réseau (NVA).

Vue d’ensemble de l’architecture

L’architecture de l’environnement isolé achemine tout le trafic via des connexions privées avec inspection du pare-feu :

Type de trafic	Chemin
Accès utilisateur	Utilisateurs → VPN ou Private Link entrant → Espace de travail
Calcul classique → contrôle	Calcul → Private Link classique → plan de contrôle d’Azure Databricks
Calcul classique → cloud	Calcul → Points de terminaison de service ou UDR → Services Azure
Serverless → vos ressources	Calcul sans serveur → points de terminaison privés NCC → vos ressources Azure
Calcul classique → sortie	Calcul → pare-feu externe (obligatoire) → Internet inspecté

Composants requis

Trafic entrant

L’espace de travail est accessible uniquement par le biais de connexions privées : VPN, Private Link entrants ou les deux en fonction de votre infrastructure existante. Les clients sélectionnent généralement un plutôt que de les empiler.

Paramètres d'accès privé (désactiver l'accès public)

Il s’agit du mécanisme de contrôle qui bloque effectivement l’ingress public. Sans cela, l’espace de travail accepte toujours le trafic Internet même avec Private Link configuré. Private Link devient un chemin supplémentaire, pas le seul chemin d’accès.

Définissez l'accès réseau public Public Network Access sur Disabled dans le portail Azure. Cela bloque l’entrée publique de l’interface utilisateur et des API de l’espace de travail.

Contrôles d’entrée d’espace de travail

Configurez le trafic d'entrée de l'espace de travail via l'entrée basée sur le contexte (CBI), le framework de stratégie de trafic d'entrée recommandé. Les règles CBI combinent la source réseau (plages d’adresses IP), l’identité, le mécanisme d’authentification et l’étendue d’accès dans un modèle d’autorisation/refus unique, de sorte que l’attribut source réseau effectue le même travail que la fonctionnalité de liste d’accès IP autonome, ainsi que d’autres.

Les listes d’accès IP restent prises en charge et peuvent être configurées en même temps que CBI. Lorsque les deux sont configurés, une demande doit être autorisée par les deux contrôles.

Niveaux de configuration :

• Stratégies CBI au niveau du compte : s’appliquent à tous les espaces de travail associés à la stratégie. Consultez Gérer les stratégies d’entrée basées sur le contexte.
• Listes d’accès IP au niveau de l’espace de travail : appliquer à un seul espace de travail. Voir Configurer des listes d’accès IP pour les espaces de travail.
• Listes d’accès IP au niveau du compte : s’applique à la console de compte. Voir Configurer des listes d’accès IP pour la console de compte.

Meilleures pratiques :

• Démarrez large, affinez en fonction de l’utilisation réelle.
• Documentez les plages d’adresses IP avec leur usage ainsi que leurs dates d’expiration.
• Conservez l’accès administrateur via une plage d’adresses IP connues.
• Chaque trimestre, passez en revue les plages et supprimez celles qui sont obsolètes.

Avertissement

Les stratégies d’entrée et les listes d’accès IP peuvent vous verrouiller hors de votre espace de travail si elles sont mal configurées. Conservez toujours l’accès administrateur via une plage d’adresses IP connues.

Contrôle d’accès du destinataire OpenSharing

OpenSharing utilise ses propres listes d’accès IP configurées sur les objets destinataires. Ceci est distinct des listes d’accès IP de l’espace de travail et n’est pas régi par les règles de trafic entrant basées sur le contexte. S’applique uniquement au partage de Databricks vers Open (destinataires autres qu’Azure Databricks).

Consultez Restreindre l’accès des destinataires d’Open Sharing à l’aide de listes d’accès IP (partage Databricks vers Open).

Connectivité entrante

Établit une connectivité privée pour l’accès utilisateur à l’interface utilisateur et à l’API de l’espace de travail. Les utilisateurs accèdent à l’espace de travail via un VPN ou un Private Link entrant, jamais l’Internet public.

Consultez Configurer une liaison privée entrante.

DNS personnalisé

Configurez le DNS privé afin que les points de terminaison Azure Databricks soient résolus en adresses IP privées.

Azure crée automatiquement des zones DNS privées lors de la création de points de terminaison privés.

Sortant

Les contrôles du trafic de sortie serverless (stratégies réseau et points de terminaison privés NCC) sont hérités de la base de référence Connectivité renforcée. Cette architecture rend le pare-feu externe, facultatif dans Renforcé, obligatoire pour l’inspection complète du trafic sortant de calcul classique.

Pare-feu externe (obligatoire)

Acheminer tout le trafic de sortie à travers un pare-feu pour l’inspection, la journalisation et l’application des politiques. Les options sont les suivantes :

• Pare-feu Azure ou des appliances virtuelles réseau tierces (NVA).

Tip

Utilisez des stratégies de point de terminaison de service pour le stockage des artefacts Azure Databricks afin de contourner le pare-feu et de réduire les coûts de transfert des données. Le stockage d’artefacts seul peut prendre en compte jusqu’à 11 Go téléchargés par nœud de cluster.

Consultez Adresses IP et domaines des services et ressources Azure Databricks pour connaître les points de terminaison Azure Databricks requis à autoriser dans les règles de pare-feu.

Tip

Pour un verrouillage maximal, envisagez d’héberger un dépôt de package privé (tel que JFrog Artifactory ou Sonatype Nexus) pour les packages Python, R et Maven. Cela élimine la nécessité de règles de pare-feu autorisant l’accès aux index de package publics comme PyPI.

Avertissement

Le plan de contrôle Azure Databricks et les connexions de relais SCC utilisent TLS avec l’épinglage des certificats. N’activez pas l’inspection TLS (déchiffrer et rechiffrer) sur le trafic entre vos clusters et le plan de contrôle Azure Databricks. Cela entraîne des défaillances du cluster. Configurez des règles de pare-feu pour autoriser ces connexions par nom de domaine complet de destination ou IP sans interception TLS. Consultez Adresses IP et domaines des services et ressources Azure Databricks pour les points de terminaison requis.

Important

Les règles de pare-feu configurées de manière incorrecte peuvent interrompre les fonctionnalités de Azure Databricks. Testez soigneusement dans un environnement hors production.

Protection contre l'exfiltration des données

Configurez les stratégies réseau et les contrôles de pare-feu pour empêcher l’exfiltration de données non autorisées :

• Contrôle du trafic de sortie serverless via des stratégies réseau.
• Trafic sortant classique des ressources de calcul via un pare-feu/une NVA.
• Règles de point de terminaison privé pour les destinations de données approuvées.

Consultez la protection contre l’exfiltration des données pour obtenir des conseils d’implémentation.

Base de référence de calcul classique

La base de référence de calcul classique est héritée de la sécurité managée et les points de terminaison de service cloud sont hérités de la connectivité renforcée. Aucun composant de calcul classique supplémentaire n’est requis pour cette architecture.

La base de référence inclut l’injection de réseaux virtuels, la connectivité de cluster sécurisé (SCC) et les Private Link classiques. Les points de terminaison de service cloud incluent des itinéraires définis par l’utilisateur, des points de terminaison de service et des points de terminaison privés pour les comptes de stockage gérés par le client.

Approches de sortie pour l’accès aux données

Il existe deux approches pour gérer l’accès aux données sortantes à partir de ressources de calcul :

• Passerelle NAT avec pare-feu : déployez une passerelle NAT pour la connectivité sortante et routez le trafic via un pare-feu à des fins d’inspection. Cette approche permet un accès contrôlé aux référentiels et API de package externes et maintient la visibilité des modèles de trafic. Utilisez cette approche lorsque vous devez accéder aux ressources externes, mais que vous avez besoin d’une inspection et d’une journalisation.

• Aucune passerelle NAT (entièrement privée) : supprimez entièrement la passerelle NAT pour éliminer toutes les communications publiques des ressources de calcul. Tous les accès aux données se produisent via des points de terminaison privés et des points de terminaison VPC uniquement. Cette approche a le niveau de sécurité le plus élevé en supprimant la possibilité d’exfiltration de données par le biais de chemins de sortie publics. Utilisez cette approche lorsque votre organisation interdit toute communication Internet publique à partir de ressources de calcul.

Implementation

Partez d’une configuration de base de connectivité renforcée déployée. Les phases suivantes ajoutent l’accès à l’espace de travail privé et le pare-feu externe requis qui définissent cette architecture.

Phase 1 : Contrôles entrants

Configurer le Private Link entrant

Configurez les Private Link entrants afin que l’accès utilisateur à l’interface utilisateur et aux API Azure Azure Databricks soit routé en privé au lieu d’adresses IP publiques. Consultez Configurer une liaison privée entrante.

Désactiver l’accès au réseau public

Définissez l'accès réseau public Public Network Access sur Disabled dans le portail Azure. C’est ce qui bloque réellement l’entrée publique. Sans cela, l’espace de travail accepte toujours le trafic Internet même avec des Private Link entrantes configurées.

Tester l’accès utilisateur privé

Testez l’accès utilisateur via VPN ou Private Link pour vérifier que les utilisateurs authentifiés peuvent atteindre l’espace de travail uniquement via le chemin du réseau privé et que l’accès public est bloqué.

Phase 2 : pare-feu externe (obligatoire)

Déployer un pare-feu externe

Déployez Pare-feu Azure ou une appliance virtuelle réseau (NVA) tierce dans un réseau virtuel hub, puis connectez le réseau virtuel de l'espace de travail à l'aide de l'appairage de réseaux virtuels ou d'un hub virtuel.

Acheminer le trafic sortant via le pare-feu à l’aide de routes définies par l’utilisateur (UDR)

Configurez des itinéraires définis par l’utilisateur dans les sous-réseaux de l’espace de travail avec un itinéraire par défaut vers le pare-feu afin que le trafic sortant de Azure Databricks flux de calcul transite par le pare-feu hub. Voir Paramètres de routage définis par l’utilisateur pour Azure Databricks.

Configurer des règles de pare-feu sans interception TLS

Configurez les règles d’application et de réseau d’Pare-feu Azure pour autoriser uniquement les points de terminaison Azure Databricks requis (voir Adresses IP et domaines des services et ressources Azure Databricks) sans interception TLS du trafic du plan de contrôle et du relais SCC.

Phase 3 : Validation

Vérifier le contrôle de sortie

Vérifiez le contrôle du trafic sortant en examinant les journaux et les diagnostics d’Pare-feu Azure afin de vous assurer que le trafic d’Azure Databricks est inspecté et limité conformément à la stratégie.

Confirmer l’absence d’adresses IP publiques

Vérifiez qu’aucune adresse IP publique n’est affectée aux nœuds de cluster ou à d’autres ressources de calcul gérées par Azure Databricks dans le réseau virtuel de l’espace de travail.

Valider les flux de trafic via des chemins privés

Vérifiez que tout le contrôle, les données et le trafic entrant transitent par le biais des points de terminaison de Private Link configurés et du pare-feu hub comme conçu.

Le Azure Databricks Terraform SRA fournit des modèles Infrastructure-as-Code comme point de départ pour ce modèle de déploiement.

Validation

Après avoir déployé l’architecture, exécutez les vérifications suivantes pour vérifier que l’isolation réseau complète, la connectivité privée et les contrôles de sortie fonctionnent comme configurés.

Vérifier	Résultat attendu
Espace de travail accessible via VPN	Oui
Espace de travail accessible sans VPN	Non
Lancement de clusters avec SCC	Oui, pas d’adresses IP publiques
Accès aux données via des connexions privées	Oui
Sortie bloquée sans approbation de pare-feu	Oui
Le DNS renvoie vers des adresses IP privées	Oui

Troubleshooting

Si une vérification de validation échoue ou qu’une charge de travail ne peut pas se connecter à un point de terminaison requis, utilisez la table spécifique au cloud qui suit pour diagnostiquer les problèmes courants.

Issue	Cause	Résolution
Échec de démarrage du cluster	Blocage par le pare-feu des points de terminaison requis ou mauvaise configuration des points de terminaison privés pour SCC, le plan de contrôle d’Azure Databricks ou les comptes de stockage (règles NSG, routage)	Passez en revue les journaux du pare-feu et ajoutez des règles d’infrastructure Azure Databricks ; vérifiez que les règles de groupe de sécurité réseau de point de terminaison privé autorisent le trafic à partir de sous-réseaux de cluster ; vérifiez les UDR
Échec de la résolution DNS	DNS privé mal configuré	Vérifier les zones DNS privées et les liens de réseau virtuel
Échec de l’accès au stockage	Problème de point de terminaison privé ou de routage	Vérifier la configuration du point de terminaison privé et les tables de routage
Échec de l’installation du package	PyPI bloqué par pare-feu	Ajouter PyPI à la liste d’autorisation du pare-feu

Maintenance permanente

• Règles de pare-feu : passez en revue et mettez à jour régulièrement les listes d’autorisation de sortie.
• Gestion DNS : mettez à jour les enregistrements lorsque vous ajoutez des espaces de travail.
• Surveillance des points de terminaison : suivez l’état des points de terminaison privés et les coûts de transfert de données.
• Stratégies réseau : ajoutez des points de terminaison privés pour les nouvelles sources de données approuvées.
• Supprimer le pare-feu : si la surcharge opérationnelle du pare-feu est trop élevée ou si les exigences de conformité sont trop élevées, vous pouvez supprimer le composant de pare-feu et maintenir la connectivité privée et l’accès VPN.
• Revenir à une connectivité sécurisée : si l’accès à l’espace de travail privé devient un obstacle à la productivité.

Étapes suivantes

Ressource	Description
Protection contre l’exfiltration des données	Architecture de référence détaillée pour combiner des contrôles réseau et catalogue Unity pour empêcher l’exfiltration des données.
Mise en réseau	Options et concepts de mise en réseau pour Azure Databricks.