Phase 4 : conception de l'architecture réseau

Dans cette phase, vous concevez l'infrastructure réseau pour les Workspace Databricks, y compris les modèles d'architecture, les options de connectivité et les contrôles de sécurité.

Comprendre le réseau Databricks

L'architecture réseau dans Databricks régule trois chemins de communication distincts :

• Connectivité entrante (front-end) : Accès des utilisateurs à la console d’administration et aux Workspaces via l’interface utilisateur et les APIs.
• **Connectivité sortante (serverless)** : connexions de Workload depuis le compute serverless de Databricks vers les ressources de vos clients.
• Connectivité classique (back-end) : sécurise les connexions du plan de compute classique au plan de contrôle.

La manière dont la sécurité réseau est appliquée dépend directement du modèle de compute :

• Compute classique : les charges de travail s'exécutent dans les réseaux cloud gérés par le client. La posture réseau est donc principalement mise en œuvre par le biais de la segmentation, du routage, de la connectivité privée et des contrôles de sortie gérés par le client.
• **Compute Serverless** : Les charges de travail s'exécutent dans un plan de compute géré par Databricks, de sorte que les administrateurs s'appuient davantage sur les contrôles de la plateforme et les configurations au niveau du compte pour régir la connectivité, en particulier l'accès sortant, tout en s'alignant sur le même modèle de risque et les mêmes exigences de réseau d'entreprise.

Les administrateurs doivent considérer ces contrôles réseau comme complémentaires aux limites Workspace et aux garde-fous au niveau du Workspace. Les contrôles Workspace définissent les opérations utilisateur et les modèles d’exécution autorisés, tandis que les contrôles réseau limitent l’accessibilité et les chemins de déplacement des données. En utilisant les deux couches de protection, les organisations peuvent réduire la zone d’impact de la sécurité et éviter de trop dépendre d’une seule couche de contrôle.

Concevoir la configuration du réseau privé virtuel

Databricks offre des options de mise en réseau flexibles pour s'aligner sur la posture de sécurité et de conformité de votre organisation à travers les architectures de compute classiques et serverless.

Cloud privé virtuel géré par le client pour les Workspace classiques

Les Workspaces classiques Databricks sont déployés dans un cloud privé virtuel (VPC) dans votre environnement cloud. Pour un contrôle maximal, Databricks recommande d’utiliser des réseaux virtuels gérés par les clients pour vos Workspaces classiques. Ce modèle offre le plus grand contrôle sur la topologie du réseau, les plages de sous-réseaux et les groupes de sécurité, ce qui est essentiel pour répondre aux exigences strictes de sécurité et de conformité.

Compute Serverless (connectivité gérée par Databricks)

Pour les ressources de compute Serverless (telles que les SQL Warehouse Serverless), Databricks gère le réseau du plan de compute, offrant une simplicité opérationnelle et une réduction des frais administratifs. Cependant, ce modèle offre toujours un contrôle robuste sur la sécurité et l'accès au plan de données :

• Ingress/egress sécurisé : des fonctionnalités telles que la connectivité sécurisée des clusters et Private Service Connect garantissent une communication privée entre votre Workspace, votre compute et vos sources de données, quel que soit le modèle de compute.
• Connectivité privée Serverless : Les configurations de connectivité réseau (NCC) vous permettent de définir des règles d'égresse pour le compute serverless géré par Databricks, offrant un contrôle granulaire sur la destination de votre trafic de plan de compute.

Cette approche en couches vous permet de sélectionner l'équilibre optimal entre la simplicité opérationnelle et le contrôle granulaire du réseau pour diverses charges de travail au sein de votre architecture lakehouse.

Connectivité sécurisée des clusters (SCC)

La connectivité de cluster sécurisée (SCC) est devenue la recommandation par default et est le mode de déploiement par default pour les Workspaces. La SCC inverse l'appel du plan de contrôle au plan de compute :

Chaque cluster initialise une connexion au relais SCC dans le plan de contrôle, établissant un tunnel de communication sécurisé. Le plan de contrôle renvoie ensuite les tâches d'administration de cluster au cluster via ce tunnel. Par conséquent, aucun port ouvert ni adresse IP publique n’est requis sur les nœuds du plan de compute classique. Toutes les communications du plan de compute classique vers le plan de contrôle sont sortantes.

Avantages de l'architecture SCC

• Aucune adresse IP publique n'est requise sur les nœuds compute.
• Aucun port entrant n'est requis sur les groupes de sécurité du compute.
• Posture de sécurité réseau simplifiée.
• Surface d'attaque réduite pour les ressources de compute.

Bonnes pratiques pour SCC

• Activer le SCC pour tous les nouveaux workspaces (default).
• Utilisez SCC comme posture de sécurité de référence.
• SCC est compatible avec Private Service Connect et d'autres fonctionnalités de réseau avancées.

Concevoir une stratégie de contrôle d'accès IP

Configurez les listes d'accès IP afin de restreindre les adresses IP qui peuvent se connecter à Databricks en vérifiant si l'utilisateur ou le client API provient d'une plage d'adresses IP « fiable » connue, telle qu'un VPN ou un réseau de bureau. Les sessions utilisateur établies ne fonctionnent pas si l'utilisateur bascule vers une adresse IP « non valide », par exemple, lors de la déconnexion du VPN.

Niveaux de liste d'accès IP

• Listes d'accès IP au niveau du Workspace : Appliquées aux workspaces individuels.
• Listes de contrôle d'accès IP au niveau du compte : appliquées à tous les Workspaces du compte et à l'accès à la console du compte.

Modèles de liste d'accès IP

• VPN d'entreprise : autorisez l'accès uniquement à partir des plages d'adresses IP du VPN d'entreprise.
• Réseaux de bureau : Autoriser l'accès depuis des Sites des bureaux spécifiques.
• Réseaux de fournisseurs de cloud : permettent l’accès depuis des régions de cloud ou des VPC spécifiques.
• **Approche hybride** : Combinez plusieurs plages d'adresses IP pour différents types d'utilisateurs.

Meilleures pratiques pour les listes d'accès IP

• start par les listes d'accès IP au niveau du compte pour une application cohérente.
• Utilisez les listes au niveau du Workspace pour les exigences spécifiques au Workspace.
• Documentez les plages d’adresses IP et leurs objectifs.
• Planifiez les scénarios de télétravail (exigences VPN).
• Tester les listes d'accès IP avant leur application complète.

Concevez la protection contre l’exfiltration de données

La protection contre l'exfiltration de données pour les Workspace peut être mise en place par la sécurisation du réseau, la restriction du routage et l'ajout d'un pare-feu réseau pour restreindre l'accès sortant des Workspace.

Modèles de protection contre l'exfiltration de données

• Segmentation réseau : déployez des Workspace dans des VPC isolés.
• Filtrage de sortie : Utilisez des pare-feu réseau pour contrôler le trafic sortant.
• **Connectivité privée** : Utilisez Private Service Connect pour éviter l'exposition à Internet.
• Workspace features : Désactivez les fonctionnalités susceptibles de divulguer des données (par exemple, l'exportation de notebooks, les boutons de download de données).

Bonnes pratiques pour la protection contre l'exfiltration de données

• Évaluez les protections contre l'exfiltration de données en fonction de la sensibilité des données.
• Utilisez Private Service Connect pour les environnements hautement sensibles.
• Configurez les pare-feu réseau pour autoriser uniquement les destinations requises.
• Désactiver les fonctionnalités du workspace qui pourraient permettre l'exfiltration de données.

Pour obtenir des conseils détaillés sur la configuration de la protection contre l'exfiltration de données, consultez Réseau.

Concevoir une stratégie Private Service Connect

Private Service Connect permet une connectivité privée depuis les réseaux virtuels des fournisseurs cloud et les réseaux on-premise vers les services des fournisseurs cloud, évitant ainsi l'exposition à l'internet public.

Architecture de Private Service Connect

• Front-end Private Service Connect : Connectivité privée à l'interface utilisateur du workspace et aux APIs.
• Private Service Connect back-end : Connectivité privée du compute aux services du plan de contrôle.

Private Service Connect n'est pris en charge qu'au niveau du workspace. Les listes d'accès IP peuvent continuer à protéger les services au niveau du compte.

Bonnes pratiques pour Private Service Connect

• Utilisez Private Service Connect pour les Workspaces contenant des données hautement sensibles.
• Activez Private Service Connect front-end et back-end pour une isolation maximale.
• Planifiez la configuration DNS pour les Endpoint Private Service Connect.
• Testez la connectivité Private Service Connect avant utilisation en production.

Concevez la connectivité Serverless (NCC)

Les ressources de compute Serverless s'exécutent dans le plan de compute Serverless, qui est géré par Databricks. Les administrateurs de compte peuvent configurer une connectivité sécurisée entre le plan de compute serverless et leurs ressources à l'aide des configurations de connectivité réseau (NCC).

Capacités de NCC

• ID de projet stables : pour VPC Service Controls.

Architecture NCC

Les administrateurs de compte créent des NCC dans la console du compte, et chaque NCC peut être attaché à un ou plusieurs workspaces. Lorsqu'une NCC est attachée à un workspace, le compute serverless dans ce workspace utilise la configuration réseau de la NCC pour établir des connexions sortantes sécurisées vers les ressources des clients. Le mécanisme spécifique dépend du fournisseur cloud, comme décrit dans les fonctionnalités ci-dessus.

remarque

La NCC n'a pas d'impact sur la connectivité entrante vers les ressources Serverless.

Bonnes pratiques pour NCC

• Créez des NCC distincts pour différents environnements (par exemple, dev, staging, production).
• Créez des NCC distincts pour différentes unités commerciales lorsque l'isolation est requise.
• Utilisez les NCC pour contrôler la sortie serverless vers les Ressources des clients.
• Mettez sur liste verte les plages d'adresses IP NCC sur les pare-feu de stockage et les bases de données.

Architecture réseau GCP

Chaque nœud du cluster utilise deux adresses IP du sous-réseau : une pour la communication interne du cluster et une pour la communication externe (vers le plan de contrôle/les source de données).

Dimensionnement du sous-réseau

L'espace d'adresses doit être au moins de /26, et le tableau suivant résume la taille de réseau requise en fonction du nombre prévu de nœuds dans le workspace :

Taille du sous-réseau des nœuds	Nombre maximal de nœuds Databricks par workspace
/25	60
/20	2 000
/19	4 000

Taille du sous-réseau des nœuds	Nombre maximal de nœuds Databricks par workspace
/25	60
/20	2 000
/19	4 000

Configuration de la zone de compute

La zone de calcul et/ou la haute disponibilité peuvent être configurées comme paramètre de cluster. Le paramètre 'automatique' indique une allocation automatique vers une zone décidée dynamiquement par GCP.

Accès privé Google

L'accès Serverless et compute classique aux services Google intégrés s'effectue via Private Google Access (PGA). Dans le compute classique, cela exige que les APIs PGA soient accessibles (sur liste blanche dans le pare-feu) depuis le sous-réseau du nœud.

Passerelle NAT

L'accès à internet est établi en installant une passerelle NAT, généralement sur un sous-réseau séparé. La table de routage de ces sous-réseaux doit inclure une entrée pour 0.0.0.0/0, dirigeant le trafic vers la passerelle Internet default attachée au Virtual Private Cloud (VPC). Ceci est requis pour la communication avec le plan de contrôle, à moins que Private Service Connect (PSC) ne soit utilisé.

Virtual Private Cloud (VPC) partagé

Le déploiement au sein d'un Virtual Private Cloud (VPC) partagé est pris en charge. Les nœuds résident dans le projet de service tandis que les artefacts réseau (NAT et routeur ou Endpoint PSC, selon le mode de déploiement) résident dans le projet hôte.

VPC Service Controls

Certains déploiements GCP sécurisés utilisent les VPC Service Controls (VPC-SC). Databricks peut s'exécuter au sein de son propre périmètre de service ou en partager un avec d'autres Ressources, ce qui peut différer du périmètre des sources de données. Le principe de déploiement est que le plan de contrôle gère le plan de compute, et que les identités des deux plans doivent gérer les données. En conséquence, les contrôles VPC-SC requis varient selon le déploiement et peuvent évoluer au fil du temps. Bien qu'une configuration fixe « least privilege » avec SLA ne soit pas encore disponible, un guide de configuration est fourni.

Contrôles de sécurité réseau par risque

Les clients ayant des données et des charges de travail présentant des niveaux de risque variables peuvent combiner les contrôles de Workspace et de réseau pour établir des limites opérationnelles claires tout en réutilisant la gouvernance partagée et les services de plateforme. Une limite de Workspace est un moyen efficace de séparer les domaines et les environnements (tels que Dev vs. Prod) et d'appliquer des contrôles de portée Workspace. Les contrôles de réseau fournissent ensuite une couche d'application indépendante qui limite l'emplacement d'exécution des charges de travail et les destinations qu'elles peuvent atteindre, y compris l'accès aux services internes et à l'Internet public.

Exemple de modèle de workspace hiérarchisé

Les charges de travail à risque plus élevé sont placées dans des environnements de connectivité plus restrictifs. Les Workspace alignés sur les classifications de risque restreintes sont déployés dans des configurations Virtual Private Cloud (VPC)/VNet plus strictes et sont limités aux destinations de sortie approuvées, telles que les repository privés et les services internes. Les charges de travail à faible risque peuvent fonctionner dans des environnements réseau moins restrictifs, ce qui préserve la vélocité des développeurs et élargit l'accès aux packages.

Ce modèle permet aux administrateurs d'ajuster les contrôles à plusieurs couches :

• Contrôles au niveau du Workspace : Définissez « qui peut faire quoi » dans le Workspace (garde-fous d'accès et d'exécution).
• Contrôles au niveau du réseau : Définissez « l’endroit où les charges de travail peuvent se connecter » (restrictions Virtual Private Cloud (VPC)/VNet et contrôles de sortie).

L'objectif de conception n'est pas de « choisir la bonne couche », mais d'appliquer des contrôles complémentaires. Utilisez des Workspaces pour créer des limites administratives claires et réduire le rayon d'explosion entre les environnements. Utilisez la segmentation réseau et les contrôles de sortie pour appliquer des contraintes de connectivité qui restent efficaces même lorsque les utilisateurs disposent de larges capacités au sein d'un workspace.

Pour les workspaces serverless, le même principe s'applique, mais la surface de contrôle passe des constructions réseau gérées par le client aux contrôles de plateforme tels que les politiques de contrôle de sortie serverless.

Recommandations relatives à l'architecture réseau

Recommandations

• Déployez des espaces de travail dans des réseaux virtuels gérés par les clients pour un contrôle maximal.
• Les sous-réseaux doivent être au moins en /26, mais la plupart des cas d'utilisation nécessitent au moins /23 (voir les détails de dimensionnement ci-dessus).
• Aligner les NCC serverless aux paramètres VNet/Virtual Private Cloud (VPC) gérés par le client.
• Utilisez les listes d'accès IP pour restreindre l'accès aux plages d'adresses IP connues.
• Utilisez l'architecture en étoile pour les ressources réseau partagées entre plusieurs workspaces.
• Prévoyez une haute disponibilité en déployant des ressources sur plusieurs zones de disponibilité.

Evaluer en fonction des exigences

• Pour les clients avec des politiques de sécurité réseau strictes :
  • Évaluez les protections supplémentaires contre l'exfiltration de données.
  • Envisagez d'utiliser Private Service Connect pour les charges de travail très sensibles.
  • Configurez les pare-feu réseau pour contrôler le trafic de sortie.

Résultats de la phase 4

Après avoir terminé la phase 4, vous devriez avoir :

• Architecture réseau conçue pour les Workspaces (VPC géré par le client).
• Stratégie de connectivité sécurisée des clusters (SCC) définie.
• Stratégie de contrôle d'accès IP conçue.
• Protection contre l'exfiltration de données évaluée (pour les charges de travail sensibles).
• Stratégie Private Service Connect définie (si nécessaire pour la conformité).
• Connectivité Serverless (NCC) conçue pour les workloads serverless.
• Architecture réseau conçue pour le cloud (AWS/Azure/GCP).
• Architecture réseau en étoile évaluée.
• Contrôles de sécurité réseau alignés sur les niveaux de risque.
• Dimensionnement des sous-réseaux calculé en fonction des tailles de cluster prévues.

Phase suivante : Phase 5 : Conception de l'architecture de stockage

Conseils de mise en œuvre : pour des instructions détaillées sur la mise en œuvre de votre conception de réseau, consultez Mise en réseau.