Connectivité renforcée

La connectivité renforcée s’appuie sur la sécurité managée pour ajouter des contrôles d’entrée et de sortie en couches : entrée basée sur le contexte (CBI), points de terminaison VPC, contrôles de sortie serverless et pare-feu externe facultatif. L’accès à l’espace de travail reste sur l’Internet public, contrôlé par CBI.

Cette architecture a :

  • Accès à l’espace de travail basé sur le contexte : les utilisateurs se connectent via Internet, et les stratégies CBI limitent l’accès à l’espace de travail en fonction de la source réseau, de l’identité, du mécanisme d’authentification et de la portée de l’accès. Il s’agit d’un compromis de simplicité par rapport aux architectures contrôlées par VPN.
  • Accès au service de cloud privé : les points de terminaison DU VPC (AWS) ou les points de terminaison de service (Azure) conservent le trafic du service cloud hors de l’Internet public.
  • Contrôle du trafic sortant sans serveur : les stratégies réseau et les points de terminaison privés NCC régissent le trafic sortant provenant des ressources de calcul sans serveur.
  • Inspection facultative de sortie : déployez un pare-feu externe pour inspecter et consigner la sortie de calcul classique.
  • Aucun VPN requis : accès utilisateur simplifié sans dépendance réseau d’entreprise.

Utilisez cette architecture quand :

  • La sécurité des données est le principal problème, et non pas le contrôle d’accès de l’espace de travail.
  • La complexité du VPN est un obstacle à la productivité des utilisateurs.
  • Les contrôles d’accès basés sur IP sont suffisants pour la conformité.
  • Votre organisation préfère les modèles d’accès cloud-first.

Prerequisites

  • Azure Azure Databricks Premium avec un espace de travail injecté dans un réseau virtuel.
  • Liste des plages d’adresses IP pour le contrôle d’accès à l’espace de travail.

Vue d’ensemble 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
Accès utilisateur Utilisateurs → stratégie CBI → Internet → 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 (facultatif) → Internet inspecté

Note

L’accès à l’espace de travail n’est pas privé dans cette architecture. Les utilisateurs se connectent via l’Internet public, limités par les stratégies CBI. Si votre organisation a besoin d’un accès à un espace de travail privé, utilisez plutôt l’architecture de l’environnement isolé .

Composants requis

Trafic entrant

Aucun Private Link entrant. L’accès à l’Internet public est limité par les stratégies d’entrée basées sur le contexte et, éventuellement, les listes d’accès IP. Utilisez l’IAM standard pour l’authentification. Consultez Authentification et contrôle d’accès.

Icône protection de l’utilisateur. 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 :

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.

Icône Verrouiller le partage. Contrôle d’accès du destinataire OpenSharing

OpenSharing utilise ses propres listes d’accès IP configurées sur les objets destinataires. Cela est distinct des contrôles d’accès entrants basés sur le contexte et des listes d’accès IP de l’espace de travail. 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).

Sortant

Le trafic de sortie serverless est régi par des stratégies réseau et des points de terminaison privés NCC. Utilisez Unity Catalog pour la gouvernance des données de l’accès aux données sortantes. Consultez Qu’est-ce que Unity Catalog ?.

Icône de filtre. Contrôle du trafic sortant sans serveur

Configurez des stratégies réseau pour contrôler le trafic sortant du calcul sans serveur. Définissez les destinations autorisées à l’aide de plages d’adresses IP ou de noms de domaine complets.

Consultez En quoi consiste le contrôle de sortie serverless ?.

Icône de liaison. Private Link sans serveur (points de terminaison privés NCC)

Fournit une connectivité privée entre le calcul sans serveur et vos ressources via Private Link. Le trafic de données serverless ne transite pas par l’Internet public.

Consultez Configurer la connectivité privée aux ressources Azure.

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. Aucun composant de référence supplémentaire n’est nécessaire, mais vous pouvez éventuellement ajouter un pare-feu externe pour inspecter la sortie de calcul classique.

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.

Note

Cette architecture n'utilise pas les Private Link entrantes. Les utilisateurs accèdent à l’espace de travail via l’Internet public, contrôlé par les stratégies CBI. Si votre organisation nécessite un accès à un espace de travail privé, consultez l’architecture Environnement isolé, qui ajoute un accès entrant via Private Link ou protégé par VPN.

Icône de lien. Plan de calcul classique Private Link

Fournit une connectivité privée entre votre réseau virtuel et le plan de contrôle Azure Databricks. L’API REST et le trafic de relais SCC entre les clusters et le plan de contrôle restent privés au lieu d’utiliser l’Internet public.

Consultez Configurer la connectivité privée du plan de calcul classique pour Azure Databricks.

Icône de connexion des flèches. Itinéraires définis par l’utilisateur

Configurez le routage pour l’accès au service cloud pour maintenir le trafic privé et réduire les coûts.

Configurez les UDR avec des étiquettes de service pour les services Azure. Voir Paramètres de routage définis par l’utilisateur pour Azure Databricks.

Icône bouclier. Pare-feu externe pour le calcul classique (facultatif)

Acheminez le trafic de sortie de la capacité de calcul classique via un pare-feu externe pour l'inspection, la journalisation et l'application des stratégies. Obligatoire dans l’environnement isolé ; facultatif ici.

Les options incluent Pare-feu Azure ou une appliance virtuelle réseau tierce (NVA).

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. Consultez Adresses IP et domaines des services et ressources Azure Databricks pour les points de terminaison requis.

Mise en œuvre

Partez d’une configuration de référence de sécurité administrée déjà 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

Configurer des stratégies d’entrée basées sur le contexte

Configurez des stratégies d’entrée basées sur le contexte au niveau du compte (CBI) pour restreindre l’accès à l’espace de travail par source réseau, identité, mécanisme d’authentification et étendue d’accès. Consultez le contrôle d’entrée basé sur le contexte et gérer les stratégies d’entrée basées sur le contexte.

Configurer des listes d’accès IP au niveau de l’espace de travail (facultatif)

Si vous le souhaitez, configurez des listes d’accès IP au niveau de l’espace de travail parallèlement à CBI pour assurer la rétrocompatibilité ou appliquer des dérogations propres à chaque espace de travail. Lorsque les deux sont configurés, une demande doit être autorisée par les deux. Voir Configurer des listes d’accès IP pour les espaces de travail.

Configurer des listes d’accès IP au niveau du compte

Configurez les listes d’accès IP au niveau du compte pour contrôler l’accès à la console de compte. Voir Configurer des listes d’accès IP pour la console de compte.

Configurer des listes d’accès IP au niveau du destinataire

Si vous utilisez le partage OpenSharing Databricks-to-Open, configurez des listes d’accès IP au niveau du destinataire sur chaque destinataire de partage. Consultez Restreindre l’accès des destinataires d’Open Sharing à l’aide de listes d’accès IP (partage Databricks vers Open).

Plages d’adresses IP configurées dans le document

Conservez la documentation de toutes les plages d’adresses IP configurées, notamment la justification, les tickets liés et les dates de révision planifiées.

Vérifier le comportement d’accès

Vérifiez le comportement d’accès en testant la connexion à partir de plages d’adresses IP approuvées et en confirmant que les connexions provenant de plages d’adresses IP non approuvées sont bloquées.

Phase 2 : points de terminaison de service cloud

Configurer des itinéraires définis par l’utilisateur

Configurez des itinéraires définis par l’utilisateur à l’aide d’étiquettes de service Azure afin que le trafic vers Azure services suive vos chemins de sortie privés ou contrôlés souhaités. Voir Paramètres de routage définis par l’utilisateur pour Azure Databricks.

Configurer des points de terminaison de service ou privés pour le stockage

Configurez les points de terminaison de service ou les points de terminaison privés pour les comptes de stockage gérés par le client Azure en fonction des besoins.

Phase 3 : contrôles serverless du trafic sortant

Configurer des stratégies réseau serverless

Configurez des stratégies réseau serverless afin de restreindre le trafic sortant de la capacité de calcul serverless aux destinations approuvées à l'aide de plages d'adresses IP ou de FQDN. Consultez En quoi consiste le contrôle de sortie serverless ?.

Configurer les points de terminaison privés NCC

Configurez les points de terminaison privés NCC pour une connectivité privée entre le calcul serverless et vos ressources Azure. Consultez Configurer la connectivité privée aux ressources Azure.

Tester la sortie serverless

Vérifiez que les charges de travail serverless peuvent atteindre des destinations approuvées et qu’elles sont bloquées lorsqu’elles tentent d’atteindre des destinations non approuvées.

Phase 4 (facultative) : pare-feu externe pour le calcul classique

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 et connectez-la au réseau virtuel de l'espace de travail à l'aide de l'appairage de réseaux virtuels.

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

Configurez les UDR dans les sous-réseaux de l’espace de travail avec un itinéraire par défaut vers le pare-feu.

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

Configurez des règles de pare-feu pour autoriser les points de terminaison Azure Databricks requis sans interception TLS pour le trafic du plan de contrôle et du relais SCC.

La Azure Databricks Terraform SRA fournit des modèles Infrastructure-as-Code qui automatisent ce déploiement.

Vérification

Après avoir déployé l’architecture, exécutez les vérifications suivantes pour confirmer que le trafic du plan de calcul classique reste privé et que votre liste d’accès IP limite l’accès à l’espace de travail tel qu’il est configuré.

Vérification Résultat attendu
Espace de travail accessible à partir d’adresses IP autorisées Oui
Espace de travail bloqué contre les adresses IP non autorisées Oui
Lancement de clusters avec SCC Oui, pas d’adresses IP publiques
Accès aux données via des connexions privées Oui
Installation de packages à partir de référentiels d'artefacts privés Oui

Troubleshooting

Si une vérification de validation échoue ou qu’une charge de travail se comporte de façon inattendue, utilisez le tableau suivant pour diagnostiquer les problèmes courants.

Issue Cause Résolution
Impossible d’accéder à l’espace de travail Adresse IP non dans la liste d’accès Ajouter une adresse IP à la liste d’espaces de travail
Échec de démarrage du cluster Configuration incorrecte du routage ou du point de terminaison Vérifier les tables de routage et la connectivité de point de terminaison privé
Échec de l’accès S3/ADLS Problème de point de terminaison ou de routage DU VPC Vérifier la configuration du point de terminaison et les groupes de sécurité
Échec de l’installation du package Référentiel d’artefacts privé inaccessible Vérifier la configuration du point de terminaison de réseau virtuel et la résolution DNS pour votre référentiel d’artefacts
Problèmes d’accès intermittents Adresses IP dynamiques Utiliser un VPN avec une adresse IP de sortie statique ou des plages d’adresses IP étendues

Maintenance permanente

  • Gestion des listes d’accès IP : passez en revue mensuellement, ajoutez de nouveaux emplacements, supprimez les plages obsolètes.
  • Surveillance des points de terminaison : suivez l’état des points de terminaison privés et les coûts de transfert de données.
  • Gestion des dépôts d’artefacts : gérez des miroirs privés de paquets et surveillez leur disponibilité.
  • Prise en charge des utilisateurs : gérer le processus pour les problèmes d’accès IP.

Étapes précédentes et suivantes

Architecture Quand choisir
Sécurité gérée Étape précédente. Si les contrôles d’accès basés sur IP, les points de terminaison VPC et les contrôles de sortie serverless sont supérieurs à vos charges de travail. La base de référence inclut le réseau virtuel géré par le client et SCC, avec des Private Link classiques facultatifs.
Environnement isolé Étape suivante. Si le contrôle d’accès basé sur IP s’avère insuffisant, les réglementations nécessitent un accès à l’espace de travail privé ou la conformité nécessite la prévention de l’exfiltration des données.
  • Last updated on