Bon nombre des principes fondamentaux de la sécurisation d’un lac de données seront familiers à quiconque a déjà sécurisé un conteneur de stockage cloud « de sécurité cloud ». C’est logique, bien sûr, puisque la plupart des lacs de données commerciaux s’appuient sur une infrastructure cloud existante.
Toutefois, les lacs de données ajoutent des éléments supplémentaires tels que les flux de données et l’analyse des données (data lake house, outils d’analyse tiers, etc.), ce qui accroît la complexité des interactions au-delà de celle d’un simple conteneur de stockage. En substance, il s’agit de sécuriser une application à grande échelle, avec d’énormes exigences en matière de données stockées, de données entrantes, d’interactions avec les données et de connexions réseau. Compte tenu de l’importance des analyses et des applications de « Big Data » pour les résultats financiers d’une entreprise, la sécurisation des lacs de données constitue une priorité essentielle pour les équipes de sécurité.
Il existe trop de variantes possibles de lacs de données pour fournir des étapes précises correspondant à chaque cas d’usage en matière de sécurité ; toutefois, comme pour un serveur, un réseau ou tout autre composant d’infrastructure informatique, nous pouvons définir des principes de sécurité. Ces principes aident les équipes à comprendre les objectifs ; nous devons ensuite examiner les différentes options disponibles et nous assurer qu’elles sont conformes à nos objectifs, principes et politiques.
Périmètre de sécurité des lacs de données
Un responsable de la gouvernance des données se concentrera principalement sur l’accès, la transmission et le stockage des données, mais un responsable de la sécurité informatique doit adopter une perspective plus large englobant l’infrastructure et les outils. Toutefois, si l’éventail des préoccupations possibles va des équipements physiques au code des applications, le périmètre réaliste sera plus restreint et dépendra de la manière dont notre lac de données particulier a été mis en place.
Certains lacs de données tendent vers un modèle de logiciel en tant que service (SaaS), dans lequel la plupart des fonctions de sécurité sont intégrées au logiciel et où les équipes de sécurité informatique n’ont plus qu’à vérifier quelques détails. À l’autre extrémité du spectre, les lacs de données internes peuvent même nécessiter la sécurisation des équipements physiques ainsi que des pièces et des bâtiments qui les abritent.
Malgré ce large éventail de mises en œuvre possibles, les professionnels de l’informatique devraient déjà comprendre raisonnablement bien comment sécuriser une solution SaaS classique ou un centre de données reposant sur des équipements physiques. Cet article se concentrera donc sur les problématiques propres aux lacs de données et laissera également de côté les aspects de sécurité qui s’appliquent à des domaines généraux et bien connus, tels que : la vérification d’identité, la recherche de logiciels malveillants, la résilience (les sauvegardes, etc.), les pare-feu, la détection des menaces réseau et la réponse aux incidents.
Consultez les meilleures solutions de sécurité Zero Trust
Principales problématiques de sécurité des lacs de données : visibilité et contrôles
Un lac de données peut potentiellement contenir toutes les données d’une organisation. Lorsque toutes les données se trouvent au même endroit, les risques sont démultipliés.
Les attaquants concentreront leurs efforts sur l’accès au lac de données afin de tenter d’exfiltrer des informations précieuses. Les menaces internes tenteront de dépasser leurs limites d’accès ou de télécharger de manière inappropriée des informations précieuses. Même les accès autorisés et légitimes aux données doivent être gérés afin de se prémunir contre la divulgation accidentelle de données top secrètes ou réglementées à des personnes non autorisées.
Pour se prémunir contre les accès inappropriés, les équipes de sécurité doivent connaître leurs données, connaître leurs utilisateurs et définir les accès autorisés. Une fois les accès appropriés mis en œuvre, elles doivent ensuite les tester et surveiller en continu leur utilisation afin de détecter tout usage abusif.
Ces problématiques de sécurité des lacs de données peuvent être regroupées en deux catégories : la visibilité et les contrôles. Sans maîtriser ces deux aspects, tout autre aspect de la sécurité peut être considéré comme exposé.
Visibilité des lacs de données
Pour garantir une utilisation appropriée des données, l’équipe chargée de leur sécurité doit d’abord disposer d’une visibilité sur celles-ci. Une fois les données connues, les contrôles doivent imposer des accès appropriés ; même alors, l’équipe de sécurité devra disposer d’une visibilité sur leur utilisation afin de vérifier que les contrôles fonctionnent correctement.
Visibilité des données des lacs de données : classification
La classification des données sera essentielle pour contrôler efficacement les accès au sein du lac de données. Si la classification initiale peut être effectuée en fonction des sources d’ingestion, les fichiers du lac de données devront finalement être inspectés afin d’y rechercher des données sensibles.
Les différents lacs de données disposeront de capacités différentes grâce à leurs fonctionnalités intégrées et pourront proposer des fonctions supplémentaires via des produits distincts ou des modules complémentaires tiers. Les capacités de ces fonctionnalités varieront également : certains produits pourront classifier les fichiers, tandis que d’autres ne feront qu’ajouter des classifications aux données extraites des fichiers.
Pour comprendre ce que cela peut impliquer, examinons les exemples suivants :
- AWS
- Propose un service complémentaire : Amazon Macie.
- Macie est facturé en fonction du nombre de Go traités
- Macie recherche dans les documents à l’aide d’algorithmes de machine learning (ML) afin d’identifier et de signaler les informations sensibles
- Propose un service complémentaire : Cloud DLP
- Cloud DLP est facturé en fonction du nombre de Go traités.
- Cloud DLP détecte plus de 100 identifiants intégrés
- Snowflake
- La classification s’applique aux données stockées dans les tables et les vues
- La classification entraîne des coûts de calcul, mais aucuns frais de licence supplémentaires
- La classification utilise le machine learning pour suggérer des catégories
- Les catégories de classification comprennent
- Catégories sémantiques (nom, adresse, âge, etc.)
- Catégories de confidentialité (sous-catégories des catégories sémantiques)
- Identifiants directs (nom, numéro de sécurité sociale, etc.)
- Identifiants indirects (âge, sexe, code postal, etc.)
- Attributs personnels (salaire, état de santé, etc.)
Compte tenu de l’échelle considérable d’un lac de données classique, les bonnes pratiques nécessiteront une détection et une classification automatisées des données au fur et à mesure de leur chargement dans le lac de données. Une fois catégorisées, les données pourront également être organisées, nettoyées et déplacées afin de permettre la mise en place de contrôles robustes.
Bien qu’il s’agisse davantage d’une question de gouvernance des données, les équipes chargées de leur sécurité doivent savoir comment traiter les données réglementées afin de pouvoir les catégoriser correctement et établir les contrôles appropriés. Par exemple, que se passe-t-il lorsqu’un numéro de sécurité sociale ou des informations personnelles concernant un citoyen de l’Union européenne (UE) sont détectés ?
Databricks recommande une approche proactive et la suppression des données personnelles de citoyens de l’UE lors de l’ingestion des données car le Règlement général sur la protection des données (RGPD) autorise l’application de sanctions pouvant atteindre 20 millions d’euros, voire davantage, à l’encontre des contrevenants. Des infractions peuvent être commises en cas de violation de données, mais aussi en cas de manquement à l’effacement correct des données (dans le cadre du droit à l’oubli de l’UE).
Même si l’entreprise décide de conserver les données, la gouvernance des données doit déterminer qui peut les voir ou les rechercher, et dans quelles circonstances. Pour garantir un traitement approprié, une solution consiste à déplacer les données dans des dossiers spécifiques (pour Azure, Google, etc.) ou à les associer à la catégorie de données restreintes afin de les signaler dans la base de données (pour Snowflake, Databricks, etc.).
Comme nous le verrons plus en détail ci-dessous, les contrôles de sécurité au niveau des dossiers sont beaucoup plus faciles à mettre à l’échelle que les contrôles plus granulaires basés sur les objets (fichiers, tables, etc.), qui doivent être attribués, surveillés et entretenus séparément. Les outils de lac de données peuvent détecter les catégories et déplacer les données pendant l’ingestion, afin de les catégoriser et de les sécuriser automatiquement, rapidement et à grande échelle.
À lire également : Réglementations en matière de conformité et de confidentialité des données
Visibilité sur l’utilisation des lacs de données : surveillance et journalisation
Une fois qu’une équipe de sécurité a mis en place une catégorisation et des contrôles parfaits, le lac de données est protégé ! Du moins en théorie. L’équipe de sécurité devra disposer d’une visibilité sur les actions des utilisateurs et des API afin de vérifier que la théorie continue de fonctionner dans la pratique.
Les équipes de sécurité devront établir, maintenir et auditer différents journaux et alertes au sein de l’environnement du lac de données. Compte tenu de l’échelle d’un lac de données, l’automatisation pourra être nécessaire pour la plupart des alertes afin de bloquer les activités suspectes.
Les équipes de sécurité doivent vérifier attentivement la journalisation d’audit au sein du lac de données afin de déterminer ce qui doit être activé en fonction de la capacité et du budget de l’équipe de sécurité. Par exemple, l’activité des administrateurs est activée par défaut dans les lacs de données Google, tandis que les journaux d’accès aux données sont désactivés par défaut afin de réduire le bruit et le volume de stockage.
En cas d’incident, les pratiques standard de réponse aux incidents doivent s’appliquer au lac de données au même titre qu’à toute autre ressource. Toutefois, les équipes de sécurité doivent vérifier que les alertes et les éléments de preuve sont correctement transmis à l’équipe chargée de la réponse aux incidents.
À lire également : Comment créer un plan de réponse aux incidents
Contrôles des lacs de données
Une fois que les équipes chargées de la gouvernance des données ont déterminé comment celles-ci doivent être traitées, les équipes de sécurité des données mettent en place des contrôles pour faire respecter ces règles. Souvent, ces règles prolongeront les politiques informatiques existantes, mais certaines politiques devront peut-être être réexaminées et révisées. Les principaux types de contrôles de sécurité pour les lacs de données relèvent des catégories suivantes : isolation, autorisation, chiffrement, transmission et stockage.
Isolation des lacs de données
En tant que professionnels de la sécurité, nous souhaitons limiter le nombre de connexions que nous devons contrôler et gérer pour notre infrastructure informatique. De nombreux fournisseurs recommandent l’isolation comme première étape de la mise en place d’un lac de données.
Bien que la terminologie puisse varier selon les solutions, les lacs de données peuvent être configurés de manière à être privés et dissimulés, afin d’empêcher leur détection fortuite par des tiers. Certains fournisseurs recommandent de n’autoriser l’accès au lac de données que depuis un réseau d’entreprise sécurisé. Avec l’adoption croissante de la sécurité sans périmètre, les réseaux d’entreprise pourraient être remplacés, dans cette recommandation, par des passerelles sécurisées ou d’autres configurations réseau Zero Trust.
Restreindre fortement les communications entre le lac de données et le monde extérieur peut réduire la capacité des attaquants à exfiltrer des données. Toutefois, des mesures de prévention des pertes de données (DLP) doivent également être mises en place afin de dissuader les menaces internes et d’empêcher l’exfiltration de données lors d’attaques réussies.
Consultez les meilleures solutions de prévention des pertes de données (DLP)
Des contrôles d’isolation similaires doivent être appliqués aux clusters informatiques gérés par l’organisation qui exécuteront les requêtes. Ces contrôles peuvent notamment consister à restreindre le shell sécurisé (SSH) et l’accès réseau.
Azure Private Link et AWS PrivateLink proposent des solutions cloud natives et de marque qui créent des connexions réseau privées entre les ressources de l’entreprise et isolent le lac de données d’Internet ou d’autres ressources publiques. Bien sûr, les entreprises peuvent toujours déployer davantage d’efforts et établir leurs propres passerelles sécurisées pour obtenir un résultat similaire.
Certains fournisseurs, comme Databricks, intègrent certaines de ces fonctionnalités de sécurité au cluster par défaut. Toutefois, il incombe à l’équipe de sécurité d’en vérifier les spécificités et de prendre en compte les éventuelles faiblesses qui pourraient nécessiter des mesures correctives.
Contrôles d’autorisation des lacs de données
L’autorisation consiste à contrôler les accès en fonction de la catégorisation des données. L’accès sera déterminé en fonction de l’utilisateur, de l’API ou même de la requête.
Conformément aux principes modernes du Zero Trust, le statut d’accès aux données par défaut doit être configuré pour refuser entièrement l’accès. L’accès doit être accordé activement en fonction des besoins.
Pour permettre aux utilisateurs d’accéder au lac de données, la plupart des lacs de données s’intégreront aux technologies standard de la gestion des identités et des accès (IAM), bien que les modalités puissent varier selon les implémentations. Chaque technologie peut ensuite ajouter des couches de sécurité supplémentaires afin d’associer des utilisateurs, des groupes, des projets ou des entreprises spécifiques à des référentiels de données précis (dossiers, fichiers ou colonnes de données).
Voici quelques exemples d’outils IAM associés :
- Lacs de données Azure
- Azure Active Directory (AAD)
- Groupes de sécurité Azure
- Lacs de données AWS
- AWS Identity and Access Management
- AWS Directory Service
- DataBricks
- S’intègre à Azure et à AWS IAM
- Snowflake
- Compatible avec différents protocoles OAuth, authentification multifacteur (MFA), authentification unique (SSO), et authentification fédérée
Après avoir autorisé un utilisateur à se connecter au lac de données, nous devons déterminer la durée de connexion autorisée pour les utilisateurs. La plupart des lacs de données devraient appliquer une durée d’expiration de session par défaut, qui peut être modifiée pour correspondre aux politiques habituelles de l’entreprise. Toutefois, les équipes de sécurité devront travailler avec les data scientists afin de s’assurer que les comptes n’expirent pas au milieu de longues requêtes de base de données.
En ce qui concerne l’accès aux données proprement dites, la plupart des lacs de données fonctionnent avec une forme de hiérarchie qui correspond plus ou moins à l’infrastructure informatique traditionnelle.
Certains lacs de données (Azure, etc.) placent les données brutes dans des dossiers et sécurisent ces dossiers comme on pourrait le faire pour des dossiers sur un serveur partagé. Les dossiers peuvent être attribués à des groupes d’utilisateurs, des projets ou même des utilisateurs spécifiques, et les sous-dossiers peuvent soit hériter des droits du dossier parent, soit se voir attribuer des droits spécifiques.
Les droits attribués peuvent être complets (lecture, écriture, copie et requête) ou limités (lecture seule, etc.). Les équipes de sécurité devront vérifier comment leur implémentation spécifique du lac de données gère les dossiers enfants supplémentaires, afin de garantir la conservation des droits du dossier parent et de l’héritage des droits des utilisateurs.
D’autres outils (Snowflake, etc.) combinent le contrôle d’accès discrétionnaire (DAC) et le contrôle d’accès basé sur les rôles (RBAC) pour fournir des droits similaires, mais fondés sur des objets spécifiques (entrepôt, base de données, etc.) plutôt que sur des dossiers. Dans les deux cas, les utilisateurs doivent être soigneusement affectés à des groupes ou à des rôles afin de bénéficier des droits appropriés.
Certains outils proposent de nombreux rôles prédéfinis et imposent des limites aux propriétaires des comptes principaux. Par exemple, chaque politique du lac de données de Google ne prend en charge que 1 500 comptes principaux, mais elle comprend de nombreux rôles prédéfinis tels que « Actions Admin », « ApiGateway Viewer » et « Monitoring Dashboard Configuration Editor ».
Avec l’intégration à AD, ces droits peuvent être hérités de l’infrastructure informatique source de l’organisation, mais les équipes de sécurité devront auditer ces rôles pour vérifier que :
- Les rôles dans AD sont correctement transférés
- Les utilisateurs disposent des rôles appropriés
- Les rôles appropriés correspondent aux bonnes données dans le lac de données.
Consultez les meilleurs outils de sécurité Active Directory
Chiffrement des lacs de données
En matière de chiffrement, la plupart des outils fournissent des clés de chiffrement intégrées, mais nombre d’entre eux s’intègrent également à différentes technologies de gestion des clés afin de permettre à une organisation de contrôler directement les clés de chiffrement.
Par exemple :
- Azure utilise par défaut la technologie Azure Key Vault
- Les lacs de données AWS utilisent par défaut AWS Key Management Services
- Databricks s’intègre à Azure, AWS et aux services internes de gestion des clés du client
- Snowflake génère des clés privées et prend en charge la gestion interne des clés du client, avec une paire de clés RSA d’au moins 2 048 bits requise.
Le chiffrement doit être appliqué aux données en transit, aux données stockées ainsi qu’aux données préparées en vue de leur chargement.
Les équipes de sécurité doivent vérifier que le chiffrement appliqué par défaut répond aux critères minimaux des normes de sécurité de l’organisation. Certains lacs de données permettent également de renouveler périodiquement les clés des données chiffrées. Les équipes de sécurité qui souhaitent adopter ce niveau de sécurité supérieur doivent vérifier le temps nécessaire à l’exécution d’un renouvellement de clé ainsi que les coûts susceptibles d’être engagés.
À lire également : Selon une entreprise, le chiffrement des données en cours d’utilisation permet de stopper l’exfiltration
Sécurité des transmissions des lacs de données
Lorsque nous pensons à la transmission des données, nous pensons principalement aux réseaux. La plupart des lacs de données chiffrent par défaut les transmissions de données, mais les équipes de sécurité doivent vérifier à nouveau que le chiffrement est bien en place.
Les lacs de données doivent limiter leur exposition réseau en restreignant les connexions au lac de données au moyen de listes d’adresses IP uniques ou de plages d’adresses IP limitées aux réseaux internes ou aux passerelles réseau (voir la section Isolation ci-dessus). Certains outils de lacs de données (Exemple : Snowflake) permettent d’appliquer des politiques réseau à chaque utilisateur, bien que ce niveau de granularité puisse être difficile à maintenir à grande échelle pour un grand nombre d’utilisateurs et d’applications.
Pour les outils qui se connectent à plusieurs ressources cloud (Databricks, Snowflake), les responsables de la sécurité réseau devront également s’assurer que les connexions, même lorsqu’elles sont établies automatiquement par l’application, sont correctement configurées. Il peut également exister des connexions réseau privées manuelles (ex. : AWS PrivateLink, etc.) dont la mise en place, la sécurisation et la maintenance relèveront entièrement de l’équipe de sécurité de l’organisation.
Les équipes de sécurité doivent garder à l’esprit que tous les outils ne chiffrent pas les communications par défaut. Par exemple, Microsoft Azure exige l’activation de l’option « Secure transfer required » pour bloquer les connexions HTTP et SMB non chiffrées.
Toutefois, au-delà de ces connexions réseau, les lacs de données exigent également des équipes de sécurité qu’elles prennent en compte les connexions d’API ou les connexions de requête spécifiques, ainsi que les métadonnées ou les informations sur les colonnes de base de données qu’elles peuvent renvoyer. De nombreux outils utilisent des contrôles d’interface supplémentaires qui peuvent ajouter des fonctionnalités de sécurité, ou les outils eux-mêmes peuvent servir d’intermédiaires, en recevant et en transmettant les données des requêtes tout en empêchant le demandeur d’accéder directement aux données.
Certaines données sensibles seront conservées et disponibles pour les requêtes, mais pas pour l’affichage. Certaines colonnes de métadonnées peuvent être désignées comme devant être masquées pour certains types de données ou certaines catégories d’utilisateurs qui verront les résultats, les données sensibles étant remplacées par des astérisques ou chiffrées d’une autre manière ou bloquées.
La sécurité des transmissions doit également s’appliquer à tout outil connecté au lac de données. Chaque outil de lac de données possède ses propres connecteurs, API et pilotes, qui nécessitent un formatage, une configuration et des procédures spécifiques pour se connecter au lac de données de manière sécurisée.
Snowflake classe les connexions comme outils de l’écosystème Snowflake, connexions de partenaires Snowflake, configuration générale (outils de diagnostic, limites de taille du texte des requêtes, etc.), client en ligne de commande SnowSQL, ainsi que d’autres connexions et pilotes pour Python, Spark, etc. Les équipes de sécurité devront vérifier les connexions équivalentes pour leur implémentation spécifique du lac de données et surveiller le lac de données afin d’empêcher les connexions indésirables.
Contrôles du stockage des lacs de données
Le contrôle de sécurité le plus courant pour le stockage des données est le chiffrement, que nous avons déjà abordé. Dès lors que les données ont été correctement classifiées, les contrôles d’accès devraient gérer la plupart des autorisations d’accès aux données stockées.
Toutefois, les équipes de sécurité devront également vérifier quels types de mécanismes de sécurité sont activés par défaut dans le lac de données et lesquels doivent éventuellement l’être. Par exemple, Microsoft Azure recommande d’activer Microsoft Defender for the Cloud pour tous les comptes de stockage afin de détecter et d’éliminer les logiciels malveillants chargés dans le lac de données.
Les données critiques peuvent généralement être désignées pour être stockées dans des données immuables, où elles ne pourront pas être modifiées ou supprimées par les utilisateurs du lac de données. Des options de suppression réversible peuvent également être disponibles pour permettre la récupération d’un conteneur ou de données pendant une certaine période après leur suppression.
Les données peuvent également être automatiquement transférées vers un stockage à froid ou supprimées en fonction de leur utilisation ou de leur ancienneté. Les équipes chargées de la sécurité des données doivent collaborer avec les équipes responsables de la gouvernance des données afin de classifier et d’activer correctement les données du lac de données pour le stockage immuable, la suppression réversible, le stockage à froid et la suppression automatisée.
Collaboration nécessaire
Les fondamentaux de la sécurité des lacs de données reposent sur les principes éprouvés de la sécurité informatique : visibilité et contrôle. Toutefois, comme pour toute autre infrastructure informatique, ces principes peuvent être compromis si nous négligeons les détails de l’implémentation spécifique.
Les lacs de données se complexifient, car nos équipes de sécurité informatique doivent collaborer plus directement avec les professionnels de la gouvernance et de l’exploration des données que dans de nombreuses autres applications. Toutefois, lorsque toutes les parties prenantes peuvent communiquer efficacement, des politiques de gouvernance peuvent être mises en œuvre pour classifier et sécuriser automatiquement les données au sein d’un lac de données de manière efficace.