Accès sécurisé aux sources de données Azure depuis Azure Databricks

Azure Databricks est une plateforme unifiée d'analyse de données qui fait partie du cloud Microsoft Azure. Construite sur les fondations de Delta Lake, MLFlow, Koalas et Apache Spark, Azure Databricks est un service de première partie sur le cloud Microsoft Azure qui offre une configuration en un clic, des intégrations natives avec d'autres services Azure, un espace de travail interactif et une sécurité de niveau entreprise pour alimenter les cas d'utilisation de données et d'IA pour les clients mondiaux, petits et grands. La plateforme permet une véritable collaboration entre différentes personnes travaillant avec les données dans toute entreprise, comme les ingénieurs de données, les scientifiques de données, les analystes de données et les équipes SecOps / Cloud Engineering.

Dans ce blog, le premier d'une série de deux, nous donnerons un aperçu de l'architecture d'Azure Databricks et expliquerons comment les clients peuvent se connecter à leurs propres instances gérées de services de données Azure de manière sécurisée.

Aperçu de l'architecture Azure Databricks

Azure Databricks est une application gérée sur le cloud Azure. À un niveau élevé, l'architecture se compose d'un plan de contrôle/gestion et d'un plan de données. Le plan de contrôle réside dans un abonnement géré par Microsoft et héberge des services tels que l'application web, le gestionnaire de clusters, le service de tâches, etc. Dans le déploiement par défaut, le plan de données est un composant entièrement géré dans l'abonnement du client qui comprend un VNET, un NSG et un compte de stockage racine connu sous le nom de DBFS.

Le plan de données peut également être déployé dans un VNET géré par le client, pour permettre aux équipes SecOps et Cloud Engineering de construire l'architecture de sécurité et réseau pour le service conformément à leurs politiques de gouvernance d'entreprise. Cette capacité est appelée Bring Your Own VNET ou Injection de VNET. L'image montre une vue représentative d'une telle architecture client.

Connectivité sécurisée aux services de données Azure

La sécurité d'entreprise est un principe fondamental dans le développement de logiciels chez Databricks et Microsoft, et elle est donc considérée comme un élément de première importance dans Azure Databricks. Dans le contexte de ce blog, la connectivité sécurisée fait référence à la garantie que le trafic d'Azure Databricks vers les services de données Azure reste sur le réseau dorsal d'Azure, avec la capacité inhérente de lister Azure Databricks comme source autorisée. En tant que meilleure pratique de sécurité, nous recommandons quelques options que les clients peuvent utiliser pour établir un tel mécanisme d'accès aux données aux services de données Azure comme Azure Blob Storage, Azure Data Lake Store Gen2, Azure Synapse Data Warehouse, Azure CosmosDB, etc. Lisez la suite pour une discussion sur Azure Private Link et les Service Endpoints.

Option 1 : Azure Private Link

La manière la plus sécurisée d'accéder aux services de données Azure depuis Azure Databricks est de configurer Private Link. Selon la documentation Azure, Private Link permet d'accéder aux services PaaS Azure (par exemple, Azure Storage, Azure Cosmos DB et SQL Database) et aux services clients/partenaires hébergés par Azure via un Private Endpoint dans votre réseau virtuel. Le trafic entre votre réseau virtuel et le service transite par le réseau dorsal Microsoft, éliminant ainsi l'exposition à l'Internet public. Vous pouvez également créer votre propre Service Private Link dans votre réseau virtuel (VNet) et le fournir en privé à vos clients. L'expérience de configuration et de consommation utilisant Azure Private Link est cohérente sur les services PaaS Azure, les services détenus par les clients et les services partenaires partagés. Pour plus de détails, veuillez vous référer à ceci.

Voir ci-dessous comment Azure Databricks et Private Link peuvent être utilisés ensemble.

Azure Databricks et les points de terminaison privés des services de données Azure dans des VNET séparés

Azure Databricks et les points de terminaison privés des services de données Azure dans le même VNET

Considérations relatives aux points de terminaison privés

Veuillez prendre en compte les points suivants avant de mettre en œuvre le point de terminaison privé :

• Offre une protection contre l'exfiltration des données par défaut. Dans le cas d'Azure Databricks, cela s'appliquerait une fois que le client aura autorisé l'accès à des services spécifiques dans le plan de contrôle.
• Maintient le trafic sur le réseau dorsal Azure, c'est-à-dire que le réseau public n'est pas utilisé pour les flux de données.
• Étends l'espace d'adressage de votre réseau privé aux services de données Azure, c'est-à-dire que le service de données Azure obtient effectivement une adresse IP privée dans l'un de vos VNET et peut être traité comme faisant partie de votre réseau privé plus large.
• Se connecte en privé aux services de données Azure dans d'autres régions, c'est-à-dire qu'un VNET dans la région A peut se connecter à des points de terminaison dans la région B via Private Link.
• Private Link est relativement plus complexe à configurer que d'autres mécanismes d'accès sécurisé.
• Consultez la documentation pour une liste détaillée des avantages de Private Link et la disponibilité spécifique au service.

Un exemple où l'on pourrait utiliser Private Link est lorsqu'un client utilise quelques services de données Azure en production avec Azure Databricks, comme Blob Storage, ADLS Gen2, SQL DB, etc. L'entreprise souhaite que les utilisateurs interrogent les données agrégées masquées d'ADLS Gen2, mais les empêche d'accéder aux données confidentielles non masquées d'autres sources de données. Dans ce cas, un point de terminaison privé pourrait être établi uniquement pour le service ADLS Gen2 en utilisant l'une des sous-options discutées ci-dessus.

Voici comment un tel environnement pourrait être configuré :

1 - Configurer Private Link pour ADLS Gen2

2 - Déployer Azure Databricks dans votre VNET

Veuillez noter qu'il est possible de configurer plusieurs Private Links par service de données Azure, ce qui vous permet de construire une architecture conforme aux besoins de gouvernance de votre entreprise.

Option 2 : Points de terminaison de service Azure Virtual Network

Selon la documentation Azure, les points de terminaison de service Virtual Network (VNET) étendent l'espace d'adressage privé de votre réseau virtuel. Les points de terminaison étendent également l'identité de votre VNet aux services Azure via une connexion directe. Les points de terminaison vous permettent de sécuriser vos ressources critiques de service Azure uniquement à vos réseaux virtuels. Le trafic de votre VNet vers le service Azure reste toujours sur le réseau dorsal Microsoft Azure.

Les points de terminaison de service offrent les avantages suivants (source) :

Sécurité améliorée pour vos ressources de service Azure

Les espaces d'adressage privés de différents réseaux virtuels peuvent se chevaucher. Vous ne pouvez pas utiliser d'espace réseau qui se chevauche pour identifier de manière unique le trafic provenant d'un VNET particulier. Une fois les points de terminaison de service activés pour les sous-réseaux de votre VNET, vous pouvez ajouter une règle de pare-feu de réseau virtuel pour sécuriser les services de données Azure en étendant votre identité VNET à ces ressources. Une telle configuration permet de supprimer l'accès public à ces ressources et d'autoriser le trafic uniquement à partir de votre VNET.

Routage optimal pour le trafic des services de données Azure depuis votre réseau virtuel

Actuellement, les routes de votre VNET utilisées pour diriger le trafic public via vos appliances virtuelles basées sur le cloud/sur site sont également utilisées pour le trafic des services de données Azure. Les points de terminaison de service fournissent un routage optimal pour le trafic Azure.

Maintien du trafic sur le réseau dorsal Azure

Les points de terminaison de service dirigent toujours le trafic des services de données Azure directement depuis votre VNET vers la ressource sur le réseau dorsal Microsoft Azure. Maintenir le trafic sur le réseau dorsal Azure vous permet de continuer à auditer et à surveiller le trafic Internet sortant de vos réseaux virtuels, via le tunneling forcé, sans impacter le trafic des services de données. Pour plus d'informations sur les routes définies par l'utilisateur et le tunneling forcé, consultez le routage du trafic du réseau virtuel Azure.

Configuration simple sans surcharge de gestion

Vous n'avez plus besoin d'adresses IP publiques réservées dans vos réseaux virtuels pour sécuriser les ressources des services de données Azure via un pare-feu IP. Aucun périphérique de traduction d'adresses réseau (NAT) ou de passerelle n'est requis pour configurer les points de terminaison de service. Vous pouvez configurer les points de terminaison de service via une configuration simple pour un sous-réseau. Il n'y a aucune surcharge supplémentaire pour la maintenance des points de terminaison.

Point de terminaison de service Azure avec Azure Databricks

Considérations relatives aux points de terminaison de service Azure

Veuillez prendre en compte les points suivants avant de mettre en œuvre les points de terminaison de service :

• Ne fournit pas de protection contre l'exfiltration de données par défaut.
• Maintient le trafic sur le réseau dorsal Azure, c'est-à-dire que le réseau public n'est pas utilisé pour le flux de données.
• N'étend pas votre espace d'adressage réseau privé aux services de données Azure.
• Ne peut pas se connecter de manière privée aux services de données Azure dans d'autres régions (sauf pour les régions appairées).
• Consultez la documentation pour une liste détaillée des avantages et des limitations des points de terminaison de service Azure.

En reprenant le même exemple que celui mentionné ci-dessus pour Private Link, et à quoi il pourrait ressembler avec les points de terminaison de service. Dans ce cas, le point de terminaison de service Azure Storage pourrait être configuré sur les sous-réseaux Azure Databricks et les mêmes sous-réseaux pourraient ensuite être mis sur liste blanche dans les règles de pare-feu ADLS Gen2.

Voici comment un tel environnement pourrait être configuré :

1 - Configuration du point de terminaison de service pour ADLS Gen2

2 - Déploiement d'Azure Databricks dans votre VNET

3 - Configuration des règles de pare-feu IP sur ADLS Gen2

Premiers pas avec l'accès sécurisé aux données Azure

Nous avons discuté de plusieurs options disponibles pour accéder en toute sécurité aux services de données Azure depuis votre environnement Azure Databricks. En fonction de vos spécificités commerciales, vous pourriez utiliser Azure Private Link ou les points de terminaison de service de réseau virtuel. Une fois l'approche de connectivité réseau finalisée, vous pourriez utiliser des approches d'authentification sécurisées pour vous connecter à ces ressources :

• Veuillez consulter la documentation Azure Databricks pour les sources de données spécifiques.
• Envisagez d'utiliser des secrets pour masquer les informations d'identification.
• Lorsque cela est possible, accédez à ADLS Gen2 en utilisant le passage d'informations d'identification Azure AD.

Dans le prochain article de cette série, nous examinerons en détail comment configurer un environnement verrouillé pour empêcher l'exfiltration de données (en d'autres termes, mettre en œuvre une architecture de prévention des pertes de données). Il utiliserait un mélange des options discutées ci-dessus et Azure Firewall. Veuillez contacter vos équipes de compte Microsoft ou Databricks pour toute question.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original