Environnement isolé
L'architecture d'environnement isolé hérite de la base de connectivité renforcée et ajoute deux exigences : un accès privé au Workspace et un pare-feu externe requis. L'accès au Workspace est sécurisé par un VPN ou PrivateLink entrant, jamais par l'internet public. Tous les flux de sortie du compute classique passent par le pare-feu pour l'inspection et l'application de la politique.
Cette architecture a :
- Isolation complète du réseau : Tout le trafic transite par des connexions privées.
- Accès privé au workspace : VPN ou PrivateLink entrant uniquement. Le workspace est inaccessible depuis l'internet public.
- **Inspection sortante requise** : Inspection du pare-feu de tout le trafic sortant du compute classique.
- Prévention de l'exfiltration de données : Les contrôles au niveau du réseau bloquent les transferts de données non autorisés.
Utilisez cette architecture lorsque :
- L'accès au Workspace doit être privé, par exemple via un VPN ou PrivateLink entrant.
- Gestion des données dans les secteurs d'activité fortement réglementés, par exemple les services financiers, la santé, le gouvernement.
- Les cadres de conformité exigent des contrôles de sortie (par exemple, SOC 2, HIPAA, PCI DSS et FedRAMP).
- Mise en œuvre des cadres de sécurité zéro confiance d'entreprise.
- La prévention de l'exfiltration de données est une exigence.
Prérequis
-
Plan Databricks Enterprise.
-
Infrastructure VPN existante ou connectivité PrivateLink entrante.
-
Pare-feu ou appliance virtuelle de réseau (NVA).
Présentation de l'architecture
L'architecture de l'environnement isolé achemine tout le trafic via des connexions privées avec inspection par pare-feu :
Type de trafic | Chemin d'accès |
|---|---|
Accès utilisateur | Utilisateurs → VPN ou PrivateLink entrant → Workspace |
Compute classique → contrôle | Compute → PrivateLink Classique → plan de contrôle Databricks |
Compute classique → cloud | Calcul → points de terminaison Virtual Private Cloud (VPC) → services AWS (S3, STS, Kinesis) |
Serverless → vos ressources | Serverless compute → endpoints privés NCC → Vos buckets S3 ou Virtual Private Cloud (VPC) |
Compute classique → flux sortant | Compute → Pare-feu externe (obligatoire) → Internet inspecté |
Composants requis
Entrant
Le Workspace n'est accessible que via des connexions privées : VPN, PrivateLink entrant, ou les deux selon votre infrastructure existante. Les clients en sélectionnent généralement un plutôt que de les empiler.
Paramètres d'accès privé (désactiver l'accès public)
Paramètres d'accès privé (désactiver l'accès public)C'est le contrôle d'accès qui bloque en fait l'entrée publique. Sans cela, le workspace accepte toujours le trafic internet, même avec PrivateLink configuré. PrivateLink devient un chemin d'accès supplémentaire, pas le seul.
Créez un objet de paramètres d'accès privé avec Accès public activé défini sur Faux et attachez-le au Workspace. Lorsque l'accès public est désactivé, aucun trafic public ne peut atteindre le Workspace.
Contrôles d'entrée Workspace
Contrôles d'entrée WorkspaceConfigurez l'entrée du workspace via l'entrée basée sur le contexte (CBI), le cadre de stratégie d'entrée recommandé. Les règles CBI combinent la source réseau (plages IP), l'identité, le mécanisme d'authentification et l'étendue d'accès en un modèle unique d'autorisation/refus, de sorte que l'attribut de source réseau remplit la même Job que la fonctionnalité de liste d'accès IP autonome, et plus encore.
Les listes d'accès IP restent prises en charge et peuvent être configurées en parallèle de CBI. Lorsque les deux sont configurés, une requête doit être autorisée par les deux contrôles.
**Niveaux de configuration** :
- Account-level CBI policies : Apply to all Workspace associés à la politique. Voir Gérer les politiques d'entrée basées sur le contexte.
- Listes d'accès IP au niveau du Workspace : s'appliquent à un seul Workspace. Voir Configurer les listes d'accès IP pour les Workspace.
- Listes d'accès IP au niveau du compte : s'appliquent à la console du compte. Voir Configurer les listes d'accès IP pour la console du compte.
Bonnes pratiques :
- start broad, refine based on actual usage.
- Documenter les plages d'adresses IP avec leur objectif et leurs dates d'expiration.
- Maintenir l'accès administrateur via une plage d'adresses IP connue et fiable.
- Examinez trimestriellement et supprimez les plages obsolètes.
Ingress policies and IP access lists can lock you out of your workspace if misconfigured. Always maintain administrator access through a known-good IP range.
Contrôle d'accès des destinataires OpenSharing
Contrôle d'accès des destinataires OpenSharingOpenSharing utilise ses propres listes d'accès IP configurées sur les objets destinataires. Ceci est distinct des listes d’accès IP du workspace et n’est pas couvert par l’ingestion basée sur le contexte. S'applique uniquement au partage Databricks-to-Open (destinataires non-Databricks).
Connectivité entrante
Connectivité entranteÉtablit une connectivité privée pour l'accès des utilisateurs à l'interface utilisateur et à l'API du Workspace. Les utilisateurs accèdent au Workspace via un VPN ou un PrivateLink entrant, jamais via l'internet public.
DNS personnalisé
DNS personnaliséConfigurez le DNS privé pour résoudre les points de terminaison Databricks en adresses IP privées.
Sortant
Les contrôles d'accès sortant Serverless (stratégies réseau et endpoints privés NCC) sont hérités de la ligne de base de la connectivité renforcée. Cette architecture rend le pare-feu externe, facultatif dans Hardened, obligatoire pour une inspection complète de l'accès sortant du compute classique.
Pare-feu externe (obligatoire)
Pare-feu externe (obligatoire)Acheminez tout le trafic de sortie par le biais d'un pare-feu pour l'inspection, la journalisation et l'application des politiques. Options incluses :
- AWS Network Firewall, un service géré avec des frais généraux opérationnels réduits et une intégration avec le routage AWS.
- Appliance de pare-feu tierce (telle que Palo Alto) intégrée à l'équilibreur de charge Gateway pour davantage de capacités d'inspection. Privilégié par les organisations ayant déjà investi dans Palo Alto.
Consultez Adresses IP et domaines pour les services et assets Databricks pour les endpoints Databricks requis que les règles de pare-feu doivent autoriser.
For maximum lockdown, consider hosting a private package repository (such as JFrog Artifactory or Sonatype Nexus) for Python, R, and Maven packages. This eliminates the need for firewall rules allowing access to public package indexes like PyPI.
Databricks control plane and SCC relay connections use TLS with certificate pinning. Do not enable TLS inspection (decrypt and re-encrypt) on traffic between your clusters and the Databricks control plane. Doing so causes cluster failures. Configure firewall rules to allow these connections by destination FQDN or IP without TLS interception. See IP addresses and domains for Databricks services and assets for required endpoints.
Incorrectly configured firewall rules can break Databricks capabilities. Test thoroughly in a non-production environment.
Protection contre l'exfiltration de données
Protection contre l'exfiltration de donnéesConfigurez les stratégies réseau et les contrôles de pare-feu pour empêcher l'exfiltration non autorisée des données :
- Contrôle de sortie Serverless via les stratégies réseau.
- Sortie de compute classique via pare-feu/NVA.
- Règles des Endpoint privés pour les destinations de données approuvées.
Consultez la section Protection contre l'exfiltration de données pour obtenir des conseils de mise en œuvre.
Base de référence du Classic Compute
La base de référence compute classique est héritée de Sécurité gérée, et les endpoints de service cloud sont hérités de Connectivité renforcée. Aucun composant de compute classique supplémentaire n'est requis pour cette architecture.
La base de référence comprend le Virtual Private Cloud (VPC) géré par le client, la connectivité de cluster sécurisée (SCC) et PrivateLink classique. Les Endpoint des services cloud incluent les Endpoint Virtual Private Cloud (VPC), les politiques d'Endpoint Virtual Private Cloud (VPC) et les politiques de compartiment S3.
Approches d'extraction pour l'accès aux données
Il existe deux approches pour gérer l'accès aux données sortantes à partir des ressources de compute :
-
**Passerelle NAT avec pare-feu** : Déployez une passerelle NAT pour la connectivité sortante et acheminez le trafic via un pare-feu pour inspection. Cette approche permet un accès contrôlé aux external package repositories et aux APIs, et maintient la visibilité sur les modèles de trafic. Utilisez cette approche lorsque vous devez accéder à des ressources externes, mais que vous exigez une inspection et une journalisation.
-
Pas de passerelle NAT (entièrement privé) : Supprimez entièrement la passerelle NAT pour éliminer toutes les communications publiques des ressources de compute. Tout accès aux données s'effectue uniquement via des endpoints privés et des endpoints Virtual Private Cloud (VPC). Cette approche offre le plus haut niveau de sécurité en éliminant 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 depuis les ressources de compute.
Mise en œuvre
start d'une base de référence de connectivité renforcée déployée. Les phases suivantes ajoutent l’accès privé au workspace et le pare-feu externe requis qui définissent cette architecture.
Phase 1 : Contrôles entrants
- Configurez PrivateLink entrant afin que l'accès des utilisateurs à l'application web Databricks et aux API REST transite par PrivateLink au lieu des adresses IP publiques. Consultez Configurer PrivateLink entrant pour Workspace.
- Créez un objet de paramètres d'accès privé avec Accès public activé défini sur Faux et attachez-le au Workspace. C'est ce qui bloque en fait l'entrée publique. Sans cela, le Workspace accepte toujours le trafic internet même avec PrivateLink entrant configuré.
- Testez l'accès des utilisateurs via le VPN d'entreprise ou le chemin PrivateLink pour vérifier que le trafic vers l'Workspace est acheminé sur le réseau privé comme prévu, et que l'accès public est bloqué.
Phase 2 : Pare-feu externe (obligatoire)
- Déployez une appliance de pare-feu tierce (telle que Palo Alto) dans un Virtual Private Cloud (VPC) hub et intégrez-la au Virtual Private Cloud (VPC) de l'espace de travail en utilisant un routage approprié (par exemple, Transit Gateway ou le peering Virtual Private Cloud (VPC)), ou utilisez AWS Network Firewall.
- Configurez les tables de routage pour envoyer
0.0.0.0/0au pare-feu. Les règles de pare-feu doivent autoriser les endpoints Databricks requis (voir adresses IP et domaines pour les services et les asset Databricks), les endpoints de service cloud et les services externes approuvés. - Configurez les règles de pare-feu sans interception TLS sur le trafic du plan de contrôle et du relais SCC.
Phase 3 : validation
- Vérifiez le contrôle de sortie en examinant les logs du pare-feu pour vérifier que le trafic des clusters et serverless n'atteint que les endpoints externes ou internes approuvés.
- Confirmez qu'il n'y a pas d'adresses IP publiques sur les nœuds de cluster ou d'autres ressources de compute gérées par Databricks.
- Validez que tout le trafic de contrôle, de données et entrant passe par les endpoints PrivateLink configurés et les chemins de pare-feu.
Le SRA Terraform Databricks fournit des modèles Infrastructure-as-Code qui automatisent ce modèle de déploiement.
Validation
Après avoir déployé l'architecture, exécutez les vérifications suivantes pour confirmer que l'isolation complète du réseau, la connectivité privée et les contrôles de sortie fonctionnent comme configuré.
Vérifier | Résultat attendu |
|---|---|
Workspace accessible via VPN | Oui |
Workspace accessible sans VPN | Non |
Les clusters se lancent avec SCC | Oui, pas d'IP publiques |
Accès aux données via des connexions privées | Oui |
Sortie bloquée sans approbation du pare-feu | Oui |
DNS résout les adresses IP privées | Oui |
Dépannage
Si une vérification de validation échoue ou si une charge de travail ne peut pas se connecter à un Endpoint requis, utilisez le tableau spécifique au cloud qui suit pour diagnostiquer les problèmes courants.
Problème | Cause | Résolution |
|---|---|---|
Échec du start du cluster | Pare-feu bloquant les Endpoint requis ou Endpoint Virtual Private Cloud (VPC) mal configurés pour SCC, le plan de contrôle Databricks, S3, Kinesis ou STS (groupes de sécurité, routage). | Examinez les Logs du pare-feu et ajoutez des règles d'infrastructure Databricks ; vérifiez que les groupes de sécurité de l'Endpoint Virtual Private Cloud (VPC) autorisent le trafic provenant des sous-réseaux de clusters ; vérifiez les tables de routage |
La résolution DNS échoue | DNS privé mal configuré | Vérifier les zones hébergées privées Route 53 et les associations Virtual Private Cloud (VPC) |
L'accès S3 échoue | Problème d'Virtual Private Cloud (VPC) endpoint ou de routage | Vérifiez la configuration du Endpoint de la passerelle S3 et les tables de routage |
L'installation du package échoue | PyPI bloqué par le pare-feu | Ajoutez PyPI à la liste d’autorisation du pare-feu |
Maintenance continue
- Règles de pare-feu : vérifiez et mettez à jour régulièrement les listes d'autorisation de sortie.
- Gestion DNS : Mettre à jour les enregistrements lorsque vous ajoutez des workspaces.
- **Monitoring des Endpoint** : Suivez l'état des endpoints privés et les coûts de transfert de données.
- Stratégies de réseau : Ajoutez des Endpoint privés pour les nouvelles sources de données approuvées.
- Supprimer le pare-feu : Si la charge de travail opérationnelle du pare-feu est trop élevée ou si les exigences de conformité se relâchent, vous pouvez supprimer le composant pare-feu et conserver la connectivité privée et l'accès VPN.
- Rétrogradation vers une connectivité renforcée : Si l'accès privé au workspace devient un obstacle à la productivité.
Étapes suivantes
-
- Protection contre l'exfiltration de données
- Architecture de référence détaillée pour combiner les contrôles de réseau et Unity Catalog afin de prévenir l'exfiltration de données.
-
- Mise en réseau
- Options et concepts de mise en réseau pour Databricks.