Meilleures pratiques de sécurité pour Delta Sharing

 

Le lac de données nous a permis de consolider nos architectures de gestion de données, d'éliminer les silos et de tirer parti d'une plateforme commune pour tous les cas d'utilisation. L'unification des cas d'utilisation d'entreposage de données et d'IA sur une seule plateforme est un grand pas en avant pour les organisations, mais une fois qu'elles ont franchi cette étape, la question suivante à considérer est : « comment partager ces données simplement et en toute sécurité, quel que soit le client, l'outil ou la plateforme que le destinataire utilise pour y accéder ? » Heureusement, le lac de données a aussi une réponse à cette question : le partage de données avec Delta Sharing.

Delta Sharing

Delta Sharing est le premier protocole ouvert au monde pour partager des données en toute sécurité en temps réel, en interne et entre organisations, indépendamment de la plateforme sur laquelle résident les données. C'est un composant clé de l'ouverture de l'architecture du lac de données, et un facilitateur clé pour organiser nos équipes de données et nos modèles d'accès d'une manière qui n'était pas possible auparavant, comme le data mesh.

Sécurisé par conception

Il est important de noter que Delta Sharing a été conçu dès le départ en pensant à la sécurité, vous permettant d'utiliser les fonctionnalités suivantes prêtes à l'emploi, que vous utilisiez la version open source ou son équivalent géré :

• Chiffrement TLS de bout en bout du client au serveur en passant par le compte de stockage
• Informations d'identification à courte durée de vie telles que les URL pré-signées sont utilisées pour accéder aux données
• Gouvernez, suivez et auditez facilement l'accès à vos jeux de données partagés via Unity Catalog

Les meilleures pratiques que nous partagerons dans le cadre de ce blog sont additives, permettant aux clients d'aligner les contrôles de sécurité appropriés sur leur profil de risque et la sensibilité de leurs données.

Meilleures pratiques de sécurité

Nos recommandations de meilleures pratiques pour utiliser Delta Sharing pour partager des données sensibles sont les suivantes :

1. Évaluez la version open source par rapport à la version gérée en fonction de vos besoins
2. Définissez la durée de vie appropriée du jeton du destinataire pour chaque metastore
3. Établissez un processus de rotation des informations d'identification
4. Considérez le bon niveau de granularité pour les partages, les destinataires et les partitions
5. Configurez les listes d'accès IP
6. Configurez la journalisation d'audit Databricks
7. Configurez les restrictions réseau sur le(s) compte(s) de stockage
8. Configurez la journalisation sur le(s) compte(s) de stockage

1. Évaluez la version open source par rapport à la version gérée en fonction de vos besoins

Comme nous l'avons établi ci-dessus, Delta Sharing a été conçu dès le départ en pensant à la sécurité. Cependant, il y a des avantages à utiliser la version gérée :

• Delta Sharing sur Databricks est fourni par Unity Catalog, qui vous permet de fournir un accès granulaire à n'importe quel jeu de données entre différents ensembles d'utilisateurs, centralement à partir d'un seul endroit. Avec la version open source, vous devriez séparer les jeux de données qui ont divers droits d'accès aux données parmi plusieurs serveurs de partage, et vous devriez également imposer des restrictions d'accès sur ces serveurs et les comptes de stockage sous-jacents. Pour la facilité de déploiement, une image docker est fournie avec la version open source, mais il est important de noter que la mise à l'échelle des déploiements dans les grandes entreprises représentera une surcharge non négligeable pour les équipes responsables de leur gestion.
• Tout comme le reste de la plateforme Databricks Lakehouse, Unity Catalog est fourni en tant que service géré. Vous n'avez pas à vous soucier de choses comme la disponibilité, le temps de fonctionnement et la maintenance du service, car nous nous en occupons pour vous.
• Unity Catalog vous permet de configurer des capacités complètes de journalisation d'audit prêtes à l'emploi.
• Les propriétaires de données pourront gérer les partages en utilisant la syntaxe SQL. De plus, des API REST sont disponibles pour gérer les partages. L'utilisation de la syntaxe SQL familière simplifie la façon dont nous partageons les données, réduisant ainsi la charge administrative.
• En utilisant la version open source, vous êtes responsable de la configuration, de l'infrastructure et de la gestion du partage de données, mais avec la version gérée, toutes ces fonctionnalités sont disponibles prêtes à l'emploi.

Pour ces raisons, nous recommandons d'évaluer les deux versions et de prendre une décision en fonction de vos besoins. Si la facilité d'installation et d'utilisation, la gouvernance et l'audit prêts à l'emploi, et la gestion de service externalisée sont importants pour vous, la version gérée sera probablement le bon choix.

2. Définissez la durée de vie appropriée du jeton du destinataire pour chaque metastore

Lorsque vous activez Delta Sharing, vous configurez la durée de vie du jeton pour les informations d'identification du destinataire. Si vous définissez la durée de vie du jeton à 0, les jetons du destinataire n'expirent jamais.

La définition de la durée de vie appropriée du jeton est d'une importance capitale d'un point de vue réglementaire, de conformité et de réputation. Avoir un jeton qui n'expire jamais représente un risque énorme ; par conséquent, il est recommandé d'utiliser des jetons à courte durée de vie comme meilleure pratique. Il est beaucoup plus facile d'accorder un nouveau jeton à un destinataire dont le jeton a expiré que d'enquêter sur l'utilisation d'un jeton dont la durée de vie a été mal définie.

Consultez la documentation (AWS, Azure) pour configurer les jetons afin qu'ils expirent après le nombre approprié de secondes, minutes, heures ou jours.

3. Établissez un processus de rotation des informations d'identification

Il y a un certain nombre de raisons pour lesquelles vous pourriez vouloir faire pivoter les informations d'identification, que ce soit l'expiration d'un jeton existant, la crainte qu'une information d'identification ait pu être compromise, ou même simplement que vous ayez modifié la durée de vie du jeton et que vous souhaitiez émettre de nouvelles informations d'identification qui respectent cette durée d'expiration.

Pour garantir que ces demandes soient satisfaites de manière prévisible et rapide, il est important d'établir un processus, de préférence avec un SLA établi. Cela pourrait être bien intégré à votre processus de gestion des services informatiques, avec l'action appropriée effectuée par le propriétaire des données désigné, l'administrateur des données ou le DBA pour ce metastore.

Consultez la documentation (AWS, Azure) pour savoir comment faire pivoter les informations d'identification. En particulier :

• Si vous devez faire pivoter une information d'identification immédiatement, définissez --existing-token-expire-in-seconds sur 0, et le jeton existant expirera immédiatement.
• Databricks recommande les actions suivantes en cas de suspicion de compromission des informations d'identification :
  1. Révoquez l'accès du destinataire au partage.
  2. Faites pivoter le destinataire et définissez --existing-token-expire-in-seconds sur 0 afin que le jeton existant expire immédiatement.
  3. Partagez le nouveau lien d'activation avec le destinataire prévu via un canal sécurisé.
  4. Une fois l'URL d'activation accédée, accordez à nouveau l'accès au partage au destinataire.

4. Tenez compte du bon niveau de granularité pour les Partages, les Destinataires et les Partitions

Dans la version gérée, chaque partage peut contenir une ou plusieurs tables et être associé à un ou plusieurs destinataires, en utilisant des contrôles granulaires pour gérer qui ou comment les plusieurs jeux de données sont accédés. Cela nous permet de fournir un accès granulaire à plusieurs jeux de données d'une manière qui serait beaucoup plus difficile à réaliser en utilisant uniquement open source. Et nous pouvons même aller plus loin, en ajoutant seulement une partie d'une table à partager en fournissant une spécification de partition (voir la documentation sur AWS, Azure).

Il est utile de tirer parti de ces fonctionnalités en implémentant vos partages et destinataires pour suivre le principe du moindre privilège, de sorte que si les informations d'identification d'un destinataire sont compromises, elles soient associées au moins grand nombre de jeux de données ou au plus petit sous-ensemble des données possible.

5. Configurez les listes d'accès IP

Par défaut, tout ce qui est requis pour accéder à vos partages est un fichier d'informations d'identification Delta Sharing valide. Par conséquent, il est essentiel de minimiser la possibilité que les informations d'identification soient compromises en implémentant des limites au niveau du réseau sur l'endroit où elles peuvent être utilisées.

Configurez les listes d'accès IP Delta Sharing (voir la documentation pour AWS, Azure) pour restreindre l'accès des destinataires aux adresses IP de confiance, par exemple, l'adresse IP publique de votre VPN d'entreprise.

La combinaison des listes d'accès IP avec le jeton d'accès réduit considérablement les risques d'accès non autorisé. Pour qu'une personne accède aux données de manière non autorisée, elle doit avoir acquis une copie de votre jeton et se trouver sur le même réseau autorisé, ce qui est beaucoup plus difficile que de simplement acquérir le jeton lui-même.

6. Configurez la journalisation d'audit Databricks

Les journaux d'audit sont votre enregistrement faisant autorité de ce qui se passe sur votre Databricks Lakehouse Platform, y compris toutes les activités liées à Delta Sharing. À ce titre, nous vous recommandons vivement de configurer les journaux d'audit Databricks pour chaque cloud (voir la documentation pour AWS, Azure) et de configurer des pipelines automatisés pour traiter ces journaux et surveiller/alerter sur les événements importants.

Consultez notre article de blog complémentaire, Surveillance de votre Databricks Lakehouse Platform avec les journaux d'audit pour une analyse plus approfondie de ce sujet, y compris tout le code dont vous avez besoin pour configurer des pipelines Delta Live Tables, configurer des alertes Databricks SQL et exécuter des requêtes SQL pour répondre à des questions importantes telles que :

• Quels sont mes partages Delta les plus populaires ?
• De quels pays mes partages Delta sont-ils accédés ?
• Les destinataires de Delta Sharing sont-ils créés sans restrictions d'accès IP appliquées ?
• Les destinataires de Delta Sharing sont-ils créés avec des restrictions d'accès IP qui se situent en dehors de ma plage d'adresses IP de confiance ?
• Les tentatives d'accès à mes partages Delta échouent-elles aux restrictions d'accès IP ?
• Les tentatives d'accès à mes partages Delta échouent-elles de manière répétée à l'authentification ?

7. Configurez les restrictions réseau sur le(s) compte(s) de stockage

Une fois qu'une requête de partage Delta a été authentifiée avec succès par le serveur de partage, un tableau d'informations d'identification à courte durée de vie est généré et renvoyé au client. Le client utilise ensuite ces URL pour demander les fichiers pertinents directement auprès du fournisseur de cloud. Cette conception signifie que le transfert peut se faire en parallèle à une bande passante massive, sans diffuser les résultats via le serveur. Cela signifie également que, d'un point de vue sécurité, vous voudrez probablement implémenter des restrictions réseau similaires sur le compte de stockage par rapport au destinataire du partage Delta lui-même - il est inutile de protéger le partage au niveau du destinataire si les données elles-mêmes sont hébergées dans un compte de stockage accessible par n'importe qui et n'importe où.

Azure

Sur Azure, Databricks recommande d'utiliser les Identités managées (actuellement en aperçu public) pour accéder au compte de stockage sous-jacent au nom de Unity Catalog. Les clients peuvent ensuite configurer les pare-feu de stockage pour restreindre tout autre accès aux points de terminaison privés, réseaux virtuels ou plages d'adresses IP publiques de confiance que les clients Delta Sharing peuvent utiliser pour accéder aux données. Veuillez contacter votre représentant Databricks pour plus d'informations.

Note importante : Encore une fois, il est important de prendre en compte tous les cas d'utilisation potentiels lors de la détermination des restrictions de niveau réseau à appliquer. Par exemple, en plus d'accéder aux données via Delta Sharing, il est probable qu'un ou plusieurs espaces de travail Databricks auront également besoin d'accéder aux données, et par conséquent, vous devriez autoriser l'accès à partir des points de terminaison privés, réseaux virtuels ou plages d'adresses IP publiques de confiance utilisés par ces espaces de travail.

AWS

Sur AWS, Databricks recommande d'utiliser les politiques de compartiment S3 pour restreindre l'accès à vos compartiments S3. Par exemple, l'instruction Deny suivante pourrait être utilisée pour restreindre l'accès aux adresses IP et VPC de confiance.

Note importante : Il est important de prendre en compte tous les cas d'utilisation potentiels lors de la détermination des restrictions de niveau réseau à appliquer. Par exemple :

• Lors de l'utilisation de la version gérée, les URL pré-signées sont générées par Unity Catalog, et par conséquent, vous devrez autoriser l'accès à partir de l'IP NAT du plan de contrôle Databricks pour votre région.
• Il est probable qu'un ou plusieurs espaces de travail Databricks auront également besoin d'accéder aux données, et par conséquent, vous devriez autoriser l'accès à partir des ID VPC pertinents si le compartiment S3 sous-jacent se trouve dans la même région et que vous utilisez des points de terminaison VPC pour vous connecter à S3 ou à l'adresse IP publique à laquelle le trafic du plan de données se résout (par exemple via une passerelle NAT).
• Pour éviter de perdre la connectivité depuis votre réseau d'entreprise, Databricks recommande d'autoriser toujours l'accès à partir d'au moins une adresse IP connue et de confiance, telle que l'adresse IP publique de votre VPN d'entreprise. En effet, les conditions Deny s'appliquent même dans la console AWS.

En plus des restrictions au niveau du réseau, il est également recommandé de restreindre l'accès aux compartiments S3 sous-jacents au rôle IAM utilisé par Unity Catalog. La raison en est que, comme nous l'avons vu, Unity Catalog offre un accès granulaire à vos données d'une manière qui n'est pas possible avec les autorisations grossières fournies par AWS IAM/S3. Par conséquent, si quelqu'un parvenait à accéder directement au compartiment S3, il pourrait contourner ces autorisations granulaires et accéder à plus de données que prévu.

Note importante : Comme ci-dessus, les conditions de refus s'appliquent même au sein de la console AWS, il est donc recommandé d'autoriser également l'accès à un rôle d'administrateur qu'un petit nombre d'utilisateurs privilégiés peuvent utiliser pour accéder à l'interface utilisateur/aux API AWS.

8. Configurer la journalisation sur le(s) compte(s) de stockage

En plus d'appliquer des restrictions au niveau du réseau sur le(s) compte(s) de stockage sous-jacent(s), vous voudrez probablement surveiller si quelqu'un essaie de les contourner. À ce titre, Databricks recommande :

• La configuration de la journalisation d'accès aux serveurs S3 sur AWS, ainsi que la surveillance et l'alerte appropriées autour de celle-ci
• La configuration de la journalisation de diagnostic sur Azure, ainsi que la surveillance et l'alerte appropriées autour de celle-ci

Conclusion

Le lakehouse a résolu la plupart des problèmes de gestion des données qui ont conduit à des architectures de données et des modèles d'accès fragmentés, et a considérablement ralenti le temps de valorisation que les organisations pouvaient attendre de leurs données. Maintenant que les équipes de données sont libérées de ces problèmes, le partage de données ouvert mais sécurisé est devenu la prochaine frontière.

Delta Sharing est le premier protocole ouvert au monde pour partager des données de manière sécurisée en temps réel, en interne et entre organisations, indépendamment de la plateforme sur laquelle résident les données. Et en utilisant Delta Sharing en combinaison avec les meilleures pratiques décrites ci-dessus, les organisations peuvent échanger facilement mais en toute sécurité des données avec leurs utilisateurs, partenaires et clients à l'échelle de l'entreprise.

Les marchés de données existants n'ont pas réussi à maximiser la valeur commerciale pour les fournisseurs et les consommateurs de données, mais avec Databricks Marketplace, vous pouvez tirer parti de la plateforme Databricks Lakehouse pour atteindre plus de clients, réduire les coûts et offrir plus de valeur à travers tous vos produits de données.

Si vous souhaitez devenir un partenaire fournisseur de données (Data Provider Partner), nous serions ravis d'avoir de vos nouvelles !

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