Anonymisation des données : étude de cas Bricoprivé

Le défi

BricoPrivé est une entreprise de vente en ligne spécialisée dans les articles de bricolage, présente dans plusieurs pays. Comme tout commerce en ligne, elle doit stocker diverses données personnelles telles que les noms, les adresses e-mail, les adresses de livraison, les coordonnées et autres informations relatives aux clients afin de pouvoir assurer la livraison de ses produits. La législation européenne est très stricte quant à la protection des informations des utilisateurs et demande aux entreprises de traiter ces données avec la plus grande prudence, en particulier lorsqu'elles sont susceptibles d'être manipulées par différentes équipes.

Technofy accompagne l'équipe de BricoPrivé sur de multiples aspects liés au cloud AWS et au DevOps. Ce cas d'usage se concentre sur la mise en place d'un mécanisme d'anonymisation des données pour assurer la conformité RGPD<span>lors de la manipulation des données clients par les employés de l'entreprise.</span>

Contexte et défis

• Manque d'observabilité
• Analyse des modèles dans les logs et les métriques
• Résolution des défaillances
• Manque de visibilité sur l'utilisation des ressources

‍

Tech stack 

‍

AWS

• Fonctions d'étape : Utilisées pour définir le processus d'anonymisation.
• Lambda : Service d'exécution de code sans serveur qui nous permet d'exécuter diverses actions du processus d'anonymisation.
• ECS : Utilisé pour exécuter le script d'anonymisation de la base de données qui peut dépasser la limite d'exécution du temps Lambda.
• RDS : Relational Database Service (service de base de données relationnelle) qui héberge des instances de base de données.

‍

La solution

‍

Vue d'ensemble

‍

‍

BricoPrivé disposait déjà d'un script d'anonymisation qui brouillait les données en place. L'objectif principal de notre opération était d'automatiser complètement le processus d'anonymisation et de fournir aux développeurs une nouvelle copie floutée de la base de données de production chaque semaine.

Les environnements de production et de développement sont séparés dans deux comptes AWS différents au sein de la même organisation. Cette pratique présente de nombreux avantages en termes de sécurité, d'isolation des ressources et de répartition des coûts. Cela signifie également que les bases de données de production et de développement sont deux clusters complètement séparés.

La solution se compose de deux parties :

• L'anonymiseur, qui fonctionne sur le compte de production.
• Le récepteur, qui fonctionne sur le compte de développement.

Le déroulement de chaque partie du processus est décrit dans les sections ci-dessous.

‍

Anonymisation des données

Le script développé par BricoPrivé brouille les informations personnelles "sur place", ce qui signifie que les données originales sont remplacées par les données brouillées. Dans notre cas, grâce à la flexibilité de l'écosystème AWS, nous pouvons créer une base de données à partir du dernier snapshot de production, exécuter le script et créer un snapshot anonymisé en quelques minutes.

C'est exactement ce que fait notre approche, et le tout est orchestré grâce à AWS Step Functions.

‍

‍

Le workflow comprend quelques contrôles de sécurité pour s'assurer que les actions se déroulent correctement et dans le bon ordre. Une fois que le snapshot a été créé et qu'il est considéré comme disponible, il est ensuite partagé sur le compte de développement.

Toutes les étapes utilisent une fonction Lambda, à l'exception de l'étape d'anonymisation, qui utilise un conteneur fonctionnant sur ECS, car le script peut dépasser la limite de temps d'exécution Lambda.

L'ensemble du processus se déroule dans le compte de production afin de garantir qu'aucune information personnelle ne quitte jamais l'environnement plus restreint. Les environnements de développement étant généralement plus laxistes en termes d'accès, il a été décidé qu'ils ne recevraient que des données anonymes.

‍

Recevoir des données anonymes

La seconde partie se trouve dans le compte de développement. Plutôt que de se baser sur les événements, une règle CloudWatch Event avec un calendrier sera utilisée pour déclencher l'autre Step Function. Cette approche a été choisie, car il est possible que nous ayons besoin de restaurer la base de données de développement plusieurs fois au cours de la semaine en utilisant le dernier snapshot disponible.

‍

‍

La première étape de ce workflow consiste à copier le snapshot reçu sur le compte actuel pour ne plus dépendre de l'anonymiseur. Ensuite, nous devons vérifier si une base de données anonymisée est déjà en place, pour savoir si nous devrons la supprimer avant de déployer la nouvelle avec le dernier snapshot reçu au cours de la journée.

Toutes les étapes utilisent des fonctions Lambda.

Résultats et faits marquants

Cette solution et cette approche présentent de nombreux avantages :

• Le processus est rentable grâce aux différents services serverless
• Il est facilement duplicable à une autre base de données
• Peut être déclenché manuellement ou automatiquement
• Le temps d'exécution est court
• Les données sensibles restent dans le compte de production

‍