Connectivité renforcée

La connectivité renforcée s'appuie sur la sécurité gérée pour ajouter des contrôles d'entrée et de sortie en couches : entrée basée sur le contexte (CBI), Endpoint VPC, contrôles de sortie Serverless et un pare-feu externe facultatif. L'accès au Workspace reste sur l'internet public, sécurisé par CBI.

Cette architecture a :

• **Ingress du workspace basé sur le contexte** : les utilisateurs se connectent via Internet, et les politiques CBI limitent l'accès au workspace par source réseau, identité, mécanisme d'authentification et portée d'accès. Il s'agit d'un compromis de simplicité par rapport aux architectures sécurisées par VPN.
• **Accès aux services cloud privés** : les Endpoint Virtual Private Cloud (VPC) (AWS) ou les endpoints de service (Azure) maintiennent le trafic des services cloud hors de l'Internet public.
• Contrôle d'extraction serverless : Les stratégies réseau et les endpoints privés NCC régissent le trafic sortant du compute serverless.
• Inspection facultative de la sortie : Déployez un pare-feu externe pour inspecter et journaliser la sortie du compute classique.
• Aucun VPN requis : Accès utilisateur simplifié sans dépendance au réseau d'entreprise.

Utilisez cette architecture lorsque :

• La sécurité des données est la principale préoccupation, et non le contrôle d'accès au Workspace.
• La complexité du VPN est un obstacle à la productivité de l'utilisateur.
• Les contrôles d'accès basés sur l'IP sont suffisants pour la conformité.
• Votre organisation préfère les modèles d'accès axés sur le cloud.

Prérequis

• Plan Databricks Enterprise.

• Liste de plages IP pour le contrôle d'accès du Workspace.

Présentation de l'architecture

L'architecture de connectivité renforcée sécurise le trafic réseau et simplifie l'accès utilisateur :

Type de trafic	Chemin d'accès
Accès utilisateur	Utilisateurs → Internet → Politique CBI → 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 (facultatif) → Internet inspecté

Type de trafic	Chemin d'accès
Accès utilisateur	Utilisateurs → Internet → Politique CBI → 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 (facultatif) → Internet inspecté

remarque

L'accès au Workspace n'est pas privé dans cette architecture. Les utilisateurs se connectent via Internet public, soumis aux politiques CBI. Si votre organisation exige un accès privé au workspace, utilisez plutôt l'architecture environnement isolé.

Composants requis

Entrant

Aucun PrivateLink entrant. L'accès internet public est restreint par des stratégies d'entrée basées sur le contexte et, facultativement, par des listes d'accès IP. Suivez l'IAM standard pour l'authentification. Voir Authentification et contrôle d'accès.

Contrôles d'entrée Workspace

Configurez 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** :

• **Politiques CBI au niveau du compte** : S'appliquent à tous les Workspaces du compte. 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.

attention

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

OpenSharing utilise ses propres listes d'accès IP configurées sur les objets destinataires. Ceci est distinct de l'entrée basée sur le contexte et des listes d'accès IP du Workspace. S'applique uniquement au partage Databricks-to-Open (destinataires non-Databricks).

Consultez Restreindre l'accès des destinataires OpenSharing à l'aide de listes d'accès IP (Databricks–OpenSharing).

Sortant

La sortie serverless est régie par des politiques réseau et des endpoints privés NCC. Utilisez Unity Catalog pour la gouvernance des données de l'accès sortant. Consultez Qu'est-ce que Unity Catalog ?.

Contrôle de sortie Serverless

Configurez les stratégies réseau pour contrôler le trafic sortant du compute serverless. Définissez les destinations autorisées à l'aide de plages IP ou de FQDN.

Voir Qu’est-ce que le contrôle de sortie serverless ?.

Serverless PrivateLink (endpoints privés NCC)

Offre une connectivité privée du compute Serverless à vos ressources via PrivateLink. Le trafic de données Serverless reste hors de l'internet public.

Consultez Configurer la connectivité privée aux Ressources gérées par AWS pour la connectivité privée aux buckets S3 et Configurer la connectivité privée aux Ressources de votre Virtual Private Cloud (VPC) pour la connectivité privée aux Ressources de votre Virtual Private Cloud (VPC).

Base de référence du Classic Compute

Le compute classique de base est hérité de la sécurité gérée. Aucun composant de base supplémentaire n’est requis, mais vous pouvez ajouter en option un pare-feu externe pour inspecter le trafic sortant du compute classique.

La base de référence inclut le Virtual Private Cloud (VPC) géré par le client, la connectivité sécurisée des clusters (SCC) et PrivateLink classique.

remarque

Cette architecture n'utilise pas de PrivateLink entrant. Les utilisateurs accèdent au Workspace via l'internet public, contrôlés par les politiques CBI. Si votre organisation nécessite un accès privé au workspace, consultez l'architecture de l'environnement isolé, qui ajoute un accès PrivateLink entrant ou un accès sécurisé par VPN.

PrivateLink du plan de compute Classique

Fournit une connectivité privée entre votre Virtual Private Cloud (VPC) et le plan de contrôle Databricks. L'API REST et le SCC relaient le trafic entre les clusters et le plan de contrôle de manière privée au lieu d'utiliser l'Internet public.

Consultez Configurer la connectivité privée classique à Databricks.

Endpoints VPC

Configurez le routage pour l'accès aux services cloud afin de maintenir le trafic privé et de réduire les coûts. Les endpoints Virtual Private Cloud (VPC) de la passerelle S3 offrent un accès au stockage dans la même région sans traverser l'Internet public.

Créez des Endpoint Virtual Private Cloud (VPC) pour S3 (passerelle), STS et Kinesis. Voir Ajouter des Endpoints Virtual Private Cloud (VPC) pour d’autres services AWS.

Stratégies d'endpoint VPC

Restreignez les compartiments S3 auxquels vos Endpoint Virtual Private Cloud (VPC) peuvent accéder. Sans politique, l'endpoint de passerelle S3 autorise les connexions à n'importe quel compartiment S3 de n'importe quel compte AWS, y compris les compartiments externes ou contrôlés par des attaquants. Une politique d'endpoint Virtual Private Cloud (VPC) limite l'endpoint à vos seuls compartiments approuvés, bloquant ainsi un chemin clé d'exfiltration des données S3.

Consultez Configurer un Virtual Private Cloud (VPC) géré par le client pour des exemples de politiques fonctionnelles et l'accès requis au bucket Databricks.

Stratégies de compartiment S3

Appliquez des politiques de compartiment pour restreindre l'accès à vos compartiments S3 Databricks par source Virtual Private Cloud (VPC) ou Endpoint Virtual Private Cloud (VPC). Cela empêche l'accès à vos données depuis l'extérieur de vos chemins de réseau approuvés, même si les identifiants sont compromis.

Consultez Configurer un Virtual Private Cloud (VPC) géré par le client pour connaître les exigences, des exemples de politiques opérationnelles et des conseils sur l'association des politiques de compartiment avec les politiques d'endpoint VPC.

Pare-feu externe pour le compute classique (facultatif)

Acheminez le trafic de sortie du compute classique via un pare-feu externe pour l'inspection, la journalisation et l'application des politiques. Requis dans un environnement isolé; facultatif ici.

Les options incluent AWS Network Firewall (service géré, intégré au routage AWS) ou un appareil tiers tel que Palo Alto intégré avec Gateway Load Balancer.

attention

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. See IP addresses and domains for Databricks services and assets for required endpoints.

Mise en œuvre

Start d'une base de référence Sécurité gérée déployée. Les phases suivantes ajoutent les contrôles d'entrée et de sortie qui définissent cette architecture.

Phase 1 : Contrôle d'accès entrant

1. Configurez les politiques d'entrée basées sur le contexte (CBI) au niveau du compte pour restreindre l'accès au Workspace par source réseau, identité, mécanisme d'authentification et étendue d'accès. Consultez Contrôle d'entrée basé sur le contexte et Gérer les politiques d'entrée basées sur le contexte.
2. En option, configurez les listes d'accès IP au niveau du workspace avec CBI pour la compatibilité ascendante ou les remplacements par workspace. Lorsque les deux sont configurés, une requête doit être autorisée par les deux. Voir Configurer les listes d’accès IP pour les Workspace.
3. Configurez les listes d'accès IP au niveau du compte pour contrôler l'accès à la console du compte. Consultez Configurer les listes d'accès IP pour la console de compte.
4. Si vous utilisez le partage Databricks-to-Open OpenSharing, configurez les listes d’accès IP au niveau du destinataire sur chaque destinataire du partage. Voir Restreindre l'accès des destinataires OpenSharing à l'aide de listes d'accès IP (partage Databricks vers OpenSharing).
5. Documentez chaque plage d'adresses IP configurée avec le propriétaire, l'objectif et la date de révision/d'expiration dans votre système de gestion des changements ou de documentation.
6. Testez l'accès depuis les adresses IP autorisées et bloquées (par exemple, les réseaux de bureau, VPN et domestiques) pour vérifier que les politiques d'entrée se comportent comme prévu.

Phase 2 : Endpoints de service cloud

1. Créez un endpoint Virtual Private Cloud (VPC) de passerelle pour S3 et des endpoints Virtual Private Cloud (VPC) d'interface pour STS et Kinesis afin que le trafic des clusters vers ces services reste sur le réseau AWS. Voir Ajouter des Endpoints Virtual Private Cloud (VPC) pour d’autres services AWS.
2. Appliquez des politiques d'endpoint VPC pour restreindre les buckets S3 que l'endpoint de passerelle peut atteindre. Consultez Configurer un VPC géré par le client.
3. Appliquez des politiques de compartiment S3 pour restreindre l'accès à vos compartiments S3 Databricks par VPC source ou par endpoint Virtual Private Cloud (VPC).

Phase 3 : contrôles de sortie serverless

1. Configurez des stratégies réseau Serverless pour restreindre le trafic sortant du compute Serverless vers des destinations approuvées à l'aide de plages d'adresses IP ou de FQDN. Voir Qu'est-ce que le contrôle de sortie Serverless ?.
2. Configurez les Endpoints privés NCC pour une connectivité privée depuis le compute Serverless vers vos compartiments S3 et les Ressources dans votre Virtual Private Cloud (VPC). Voir Configurer la connectivité privée aux ressources gérées par AWS et Configurer la connectivité privée aux ressources de votre Virtual Private Cloud (VPC).
3. Testez que les charges de travail Serverless peuvent atteindre les destinations approuvées et sont bloquées des destinations non approuvées.

Phase 4 (facultatif) : Pare-feu externe pour le compute classique

1. Déployez AWS Network Firewall ou une appliance tierce et intégrez-la à votre Workspace Virtual Private Cloud (VPC).
2. Configurez les tables de routage pour envoyer 0.0.0.0/0 au pare-feu tout en maintenant le trafic d'Endpoint Virtual Private Cloud (VPC) et PrivateLink sur des routes directes.
3. Configurez des règles de pare-feu pour autoriser les points de terminaison Databricks requis (consultez adresses IP et domaines pour les services et assets Databricks) sans interception TLS sur le trafic de relais du plan de contrôle et du SCC.

Le SRA Terraform de Databricks fournit des Template Infrastructure-as-Code qui automatisent ce déploiement.

Validation

Après avoir déployé l'architecture, effectuez les vérifications suivantes pour confirmer que le trafic du plan de compute classique reste privé et que votre liste d'accès IP restreint l'accès au Workspace tel que configuré.

Vérifier	Résultat attendu
Workspace accessible depuis les adresses IP autorisées	Oui
Workspace bloqué depuis des adresses IP non autorisées.	Oui
Les clusters se lancent avec SCC	Oui, pas d'IP publiques
Accès aux données via des connexions privées	Oui
Installation de package à partir de référentiels d'artefacts privés	Oui

Vérifier	Résultat attendu
Workspace accessible depuis les adresses IP autorisées	Oui
Workspace bloqué depuis des adresses IP non autorisées.	Oui
Les clusters se lancent avec SCC	Oui, pas d'IP publiques
Accès aux données via des connexions privées	Oui
Installation de package à partir de référentiels d'artefacts privés	Oui

Dépannage

Si une vérification de validation échoue ou si une charge de travail se comporte de manière inattendue, utilisez le tableau suivant pour diagnostiquer les problèmes courants.

Problème	Cause	Résolution
Impossible d’accéder au Workspace	IP non présente dans la liste d'accès	Ajouter une IP à la liste de Workspace
Échec du start du cluster	Mauvaise configuration du routage ou de l'endpoint	Vérifier les tables de routage et la connectivité des Endpoint privés
L'accès S3/ADLS échoue	Problème d'Virtual Private Cloud (VPC) endpoint ou de routage	Vérifiez la configuration de l'endpoint et les groupes de sécurité
L'installation du package échoue	Repository d'artefacts privé inaccessible	Vérifiez la configuration de l'endpoint Virtual Private Cloud (VPC) et la résolution DNS pour votre repository d'artefacts.
Problèmes d’accès intermittents	Adresses IP dynamiques	Utilisez un VPN avec une IP de sortie statique ou élargissez les plages d'adresses IP.

Problème	Cause	Résolution
Impossible d’accéder au Workspace	IP non présente dans la liste d'accès	Ajouter une IP à la liste de Workspace
Échec du start du cluster	Mauvaise configuration du routage ou de l'endpoint	Vérifier les tables de routage et la connectivité des Endpoint privés
L'accès S3/ADLS échoue	Problème d'Virtual Private Cloud (VPC) endpoint ou de routage	Vérifiez la configuration de l'endpoint et les groupes de sécurité
L'installation du package échoue	Repository d'artefacts privé inaccessible	Vérifiez la configuration de l'endpoint Virtual Private Cloud (VPC) et la résolution DNS pour votre repository d'artefacts.
Problèmes d’accès intermittents	Adresses IP dynamiques	Utilisez un VPN avec une IP de sortie statique ou élargissez les plages d'adresses IP.

Maintenance continue

• Gestion de la liste d'accès IP : examinez-la tous les mois, ajoutez de nouveaux emplacements, supprimez les plages obsolètes.
• **Monitoring des Endpoint** : Suivez l'état des endpoints privés et les coûts de transfert de données.
• **Gestion des repository d'artefacts** : Maintenez des miroirs de packages privés et surveillez la disponibilité.
• Support utilisateur : Maintenir un processus pour les problèmes d'accès IP.

Étapes précédentes et suivantes

• • Sécurité gérée
  • Étape précédente. Si les contrôles d'accès basés sur IP, les Virtual Private Cloud (VPC) endpoints et les contrôles de sortie serverless sont plus que ce que vos charges de travail requièrent. La base de référence comprend un Virtual Private Cloud (VPC) géré par le client et SCC, avec un PrivateLink classique en option.
• • Environnement isolé
  • Étape suivante. Si le contrôle d'accès basé sur IP s'avère insuffisant, les réglementations exigent un accès privé au Workspace, ou la conformité nécessite la prévention de l'exfiltration de données.