Datalake et sécurité des données

 

Un datalake centralise l’ensemble des données de l’organisation ; il lui permet de stocker, traiter et analyser ses données dans une optique d’amélioration de son business. Au vu de la quantité de données que nous générons, nous vous laissons imaginer d’une part la taille de ces datalakes ou lac de données et d’autre part la difficulté pour sécuriser ces données. En cas de faille, c’est potentiellement toutes les informations de l’organisation qui fuitent ! Le dilemme de ces organisation est donc  comment  assurer la sécurité des données de ces datalakes tout en pouvant procéder aux traitements nécessaires à l’amélioration de leur activité .

De la difficulté de sécuriser les données d’un datalake

La première solution qui viendrait à l’esprit pour sécuriser les données d’un datalake serait l’anonymisation des données.  Il serait possible d’anonymiser les données avant qu’elles ne soient déposer dans le datalake.

Cela pose deux problèmes.  Le premier  concerne le fait qu’une donnée anonymisée ne peut plus être récupérée et cela d’une manière irréversible ; cela peut donc poser certains problèmes car elle ne pourra plus faire l’objet ultérieurement de certains types de traitement.

Le deuxième problème concerne la certitude de l’anonymisation des données, elle peut donc s’avérer très complexe. Prenons un exemple qui parlera aux techniciens et au moins techniciens d’entre nous.

Bob se poste à l’entrée d’une agence bancaire pendant quelques jours, il relève les gens qui vont à l’agence, il les identifie individuellement, ensuite, sans autre information que les relevés bancaires (dépôt de chèques à telle date, ou dépôt d’argent ou retrait guichet), il y a des chances qu’il arrive à identifier les comptes des personnes ou des organisations simplement avec les relevés et sans aucune information d’authentification individuelle. Ainsi avoir accès à des données qui sont anonymes peut permettre de les ré-identifier.

Une solution, en utilisant une stratégie d’anonymisation des données, serait d’anonymiser en bruitant les données soit en les modifiant.  Cependant l’anonymisation va dépendre du traitement ultérieur que l’on va vouloir faire. Si nous reprenons notre exemple de la banque:  je souhaite pouvoir établir les heures d’affluence de l’agence. Je vais donc anonymiser les données d’identité, de dépôts de montant … Mais je vais laisser en clair les données de dates et d’heures afin d’effectuer le traitement souhaité.

Mais si je souhaite effectuer un autre traitement par exemple sur le montant moyen déposé, je vais devoir anonymiser les données d’heures, de dates, d’identités … Mais laisser cette fois en clair les données relatives aux montants des dépôts.

Il y aura donc autant de stratégie d’anonymisation que de traitements. Vous pouvez aisément imaginer la complexité de cette stratégie et le véritable casse-tête qu’elle représente !

Mais alors comment sécuriser les données d’un datalake ?

Reprenons notre datalake débordant de données diverses et variées. Différentes personnes au sein de l’organisation souhaitent pouvoir faire des analyses à grandes échelles sur ces données tout en respectant le RGPD. Ces personnes souhaitent chacune faire des traitements différents.  Il est donc nécessaire de trouver une solution qui permettent à la fois :

• A différentes personnes d’effectuer des analyses
• D’effectuer différents types de traitement
• De respecter la protection des données conformément à la réglementation

En utilisant les algorithmes de chiffrement que nous utilisons chez Lybero.net,  nous vous proposons une stratégie afin de répondre à ces différentes contraintes.

Nous allons utiliser un chiffrement ElGamal à la Pedersen avec un groupe d’administrateurs de secrets, nous appelons ce groupe un groupe à quorum.

Nous avons donc d’un côté le datalake rempli de données, d’un autre côté un groupe à quorum d’administrateurs de secrets et enfin une personne souhaitant effectuer un traitement sur des données.

Le groupe a quorum est constitué de plusieurs personnes, il aura la charge de contrôler l’accès aux données qui se trouvent dans le datalake lorsqu’une personne en fera la demande. Ce groupe à quorum a sa propre clé publique.Chaque membre du groupe à quorum a une clé privée spécifique associée au groupe à quorum. Lorsque l’on chiffre avec la clé publique du groupe une information, il faut que différents administrateurs de secrets (dont le nombre est le quorum) déchiffrent chacun avec leur clé privée de groupe successivement afin d’obtenir le déchiffrement final.

Dans le datalake, chaque type de données est chiffré avec une clé de contenu AES différente. Cette même clé est chiffrée par la clé publique du groupe à quorum.

Une personne souhaite faire un traitement sur un type de données que nous appellerons A. Il va donc demander au groupe à quorum s’il peut avoir accès aux données. Cette demande est matérialisée par le surchiffrement avec sa clé publique par le demandeur de la clé de contenu associée à A chiffrée par la clé publique du groupe à quorum. La clé de contenu est donc chiffrée et surchiffrée.

Deux cas se présentent alors en fonction du traitement.

Dans le cas d’un traitement direct des données, le groupe à quorum va accepter la demande de cette personne. L’acceptation est faite via le déchiffrement par le groupe à quorum (donc les déchiffrements successifs) de la clé de contenu chiffrée par la clé publique du groupe à quorum. Ils libèrent la clé de contenu pour le type de données demandées.  La personne peut déchiffrer les données et a accès à ces données et peut effectuer le traitement souhaité.

Le quorum peut bien sûr aussi refuser la demande cette personne et la procédure s’arrête immédiatement.

Dans le deuxième cas, la personne va faire une demande pour un traitement indirect de ces données. Ceci peut être le cas s’il faut anonymiser ces données au vu de leur caractère personnel et sensible.

La personne va donc demander l’accès aux données au groupe à quorum. Comme dans le premier cas celui-ci peut accorder l’accès ou pas. S’il accorde l’accès il libère donc la clé mais non pas vers le demandeur, mais vers un process qui va faire le traitement spécifique d’anonymisation des données, avant de les rechiffrer à destination du demandeur.

Le terme libéré est dans ce cas trompeur, les administrateurs de secrets n’ont jamais accès à la clé de contenu des données ni aux données.

La personne peut donc maintenant accéder aux données anonymisées et effectuer le traitement souhaité.

Ainsi en intégrant des technologies de chiffrement et un séquestre numérique à quorum il est possible de sécuriser les données stockées sur les datalake et d’en assurer l’intégrité et la confidentialité.

A cela il est bien sûr conseillé de rajouter une architecture réseau isolée accompagnée d’accès contrôlés ou de bastions pour les VMs traitant les données afin de renforcer leur sécurité.

Avec cette stratégie, il est donc possible de sécuriser les données présentes dans les datalake de manière très sûre en :

• Garantissant une isolation maximale des rôles et des responsabilités des personnes intervenants dans le traitement des données

• Restreignant l’accès des données : les personnes qui ont besoin d’accéder à des données, auront accès uniquement aux données nécessaires.