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 au sein d’un cloud privé virtuel (virtual private cloud) 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 Link assurent une communication privée entre votre Workspace, le compute et les 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 Link et d’autres fonctionnalités 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 du réseau : Déployez des Workspace dans des clouds privés virtuels isolés.
• Filtrage de sortie : Utilisez des pare-feu réseau pour contrôler le trafic sortant.
• Connectivité privée : utilisez Private Link pour empêcher 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 le Private Link pour les environnements très 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.

Conception de la stratégie de Private Link

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

Architecture de Link privé

• Private Link frontal : Connectivité privée à l'interface utilisateur et aux APIs du Workspace.
• Link privé de back-end : Connectivité privée du compute vers les services du plan de contrôle.

Le Link privé 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.

Meilleures pratiques pour le Private Link

• Utilisez Private Link pour les Workspace avec des données très sensibles.
• Activez Private Link à la fois front-end et back-end pour une isolation maximale.
• Planifiez la configuration DNS des Endpoint Private Link.
• Tester la connectivité Private Link avant l'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

• Adresses IP stables : pour la liste d'autorisation du pare-feu.

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 AWS

Configuration VPC de base

Pour un déploiement AWS classique avec des ressources de compute déployées dans un VPC dans le compte AWS d'un client, l'architecture principale nécessite :

Exigences du sous-réseau

• Au moins deux sous-réseaux, chacun défini dans une zone de disponibilité (AZ) différente au sein de la région cloud AWS.
• Dédiez des sous-réseaux au déploiement d'instances EC2 de clusters Spark et de SQL Warehouse.
• Databricks attribue deux adresses IP par nœud (instance EC2) :
  • Un est utilisé pour le trafic de gestion : orchestration, monitoring et communications du plan de contrôle.
  • Un utilisé par le conteneur Spark pour le trafic d'applications intra-cluster.

Dimensionnement du sous-réseau

Databricks ne limite pas les masques de réseau pour le Virtual Private Cloud (VPC) de l’Workspace, mais chaque sous-réseau d’Workspace doit avoir un masque de réseau compris entre /17 et /26. Le nombre total d’instances pour chaque sous-réseau est égal à la moitié du nombre d’adresses IP disponibles, après suppression des cinq adresses IP réservées dans un sous-réseau.

Taille du Virtual Private Cloud (VPC) (CIDR)	Taille du sous-réseau (CIDR)	Nombre maximum de nœuds de cluster Databricks par sous-réseau/AZ
= /16	/17	16 381 (= (32 768 - 5) // 2)
= /20	/21	2045 (= (4096-5) // 2)
= /25	/26	29 (= (64-5) // 2)

Taille du Virtual Private Cloud (VPC) (CIDR)	Taille du sous-réseau (CIDR)	Nombre maximum de nœuds de cluster Databricks par sous-réseau/AZ
= /16	/17	16 381 (= (32 768 - 5) // 2)
= /20	/21	2045 (= (4096-5) // 2)
= /25	/26	29 (= (64-5) // 2)

Configuration de la table de routage

La/Les table(s) de routage associée(s) à ces sous-réseaux doit/doivent contenir des itinéraires vers :

• Service S3 : installez l'Endpoint de passerelle S3 du Virtual Private Cloud (VPC) dans le VPC et spécifiez les sous-réseaux lors de l'installation.
• Accès Internet : Routage vers 0.0.0.0/0 avec la passerelle NAT (ou pare-feu réseau) comme cible.

Endpoint VPC de type d'interface

Installez des Endpoint VPC de type interface (basés sur PrivateLink) pour accéder en privé aux services STS et Kinesis d'AWS dans un sous-réseau séparé et plus petit (un par zone de disponibilité). Les groupes de sécurité associés à ces points de terminaison doivent autoriser l'accès entrant depuis les groupes de sécurité associés aux clusters Databricks.

important

Si l'accès privé aux services S3 est strictement requis, un endpoint VPC S3 de type interface doit également être installé. Cependant, cela représente un coût élevé, car les endpoints Virtual Private Cloud (VPC) de type interface facturent la quantité de données qui les traverse. Sauf si cela est strictement requis pour des raisons de conformité, préférez les Endpoint VPC S3 de type passerelle, qui sont gratuits.

Configuration de la passerelle NAT

Établissez l’accès à Internet en installant une passerelle NAT sur un sous-réseau distinct. Pour un accès Internet haute disponibilité, déployez une passerelle NAT (et un sous-réseau) dans chaque zone de disponibilité utilisée par les sous-réseaux pour les instances de compute Databricks. La table de routage de ces sous-réseaux doit inclure une entrée pour 0.0.0.0/0, acheminant le trafic vers la passerelle Internet attachée au Virtual Private Cloud (VPC).

Pare-feu réseau (facultatif)

Si vous avez besoin d'un pare-feu réseau pour la protection contre l'exfiltration de données, installez-le dans des sous-réseaux dédiés (un par zone de disponibilité). Configurer les tables de routage pour :

• Tables de routage pour les sous-réseaux de la passerelle NAT : acheminez le trafic vers internet (0.0.0.0/0) à la passerelle NAT.
• Tables de routage pour les sous-réseaux de compute Databricks : acheminer le trafic vers Internet vers les endpoints du pare-feu réseau.
• Tables de routage pour le sous-réseau de la passerelle NAT : Acheminez le trafic vers les clusters Databricks par l'intermédiaire des endpoints du pare-feu réseau.

Partage des ressources réseau par plusieurs Workspace

Vous pouvez partager un seul Virtual Private Cloud (VPC) sur plusieurs workspaces. Dans ce cas, vous pouvez partager les sous-réseaux pour la passerelle NAT, le pare-feu réseau et les Endpoint Virtual Private Cloud (VPC). Cependant, vous devez créer des sous-réseaux différents pour le déploiement des clusters Databricks (un ensemble différent par Workspace).

Architecture en étoile

Vous pouvez utiliser une architecture hub-and-spoke Virtual Private Cloud (VPC), où tous les Endpoint Virtual Private Cloud (VPC), les passerelles NAT, les pare-feu, et ainsi de suite, sont installés dans le VPC hub. Chaque Workspace est associé à des sous-réseaux (pour lancer des clusters Databricks) dans un Virtual Private Cloud (VPC) différent, au sein du même compte AWS ou d'un compte AWS différent. Les Virtual Private Cloud (VPC) spoke sont connectés au Virtual Private Cloud (VPC) hub à l'aide d'une Transit Gateway.

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 Link 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 Workspace (cloud privé virtuel 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 Link définie (si requise 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.