· 6 min read

Copier et anonymiser vos données de prod pour vos devs

Je suis sûr que vous avez déjà eu besoin de copier des données de production pour vos devs. Voyons comment faire ça simplement avec Snaplet et rester enfin en conformité avec le RGPD !

Je suis sûr que vous avez déjà eu besoin de copier des données de production pour vos devs. Voyons comment faire ça simplement avec Snaplet et rester enfin en conformité avec le RGPD !

Introduction

Si vous êtes dev ou Lead Dev, vous avez probablement déjà eu besoin de copier des données de production pour vos développeurs. C’est une tâche assez courante, mais qui peut être complexe. En effet, il faut non seulement copier les données, mais aussi les anonymiser pour rester en conformité avec le RGPD.

Combien le font vraiment ? Pas beaucoup ! C’est pourtant une étape cruciale pour protéger les données de vos utilisateurs. Dans cet article, je vais vous montrer comment copier et anonymiser vos données de production pour vos développeurs avec l’aide de Snaplet en quelques étapes simples.

Plus d’excuses pour ne pas le faire !

Pourquoi copier et anonymiser vos données de production pour vos devs ?

Avant de rentrer dans le vif du sujet, je vais vous expliquer pourquoi il est important de copier et anonymiser vos données de production pour vos développeurs.

Protéger les données de vos utilisateurs

La première raison est évidente : protéger les données de vos utilisateurs. En effet, si vous copiez les données de production telles quelles sur les laptops de vos développeurs, vous prenez le risque de voir ces données fuiter. C’est un risque que vous ne pouvez pas vous permettre de prendre. Que vous ne devriez pas prendre.

Respecter le RGPD

La seconde raison est tout aussi importante : respecter le RGPD. En effet, le RGPD impose des règles strictes en matière de protection des données personnelles. Si vous ne respectez pas ces règles, vous risquez de lourdes amendes. En anonymisant les données de production, vous vous assurez de rester en conformité avec le RGPD.

Mise en place du lab de démo

Nous allons mettre en place un lab de démo pour illustrer les différentes étapes de copie et d’anonymisation des données de production.

Nous allons créer un docker compose avec deux instances de PostgreSQL : une pour la production (source) et une pour le développement (target).

Création du docker compose

Nous allons créer un docker compose avec deux instances de PostgreSQL : une pour la production (source) et une pour le développement (target) sur les ports 5454 et 5555 respectivement.

  • Créons un répertoire pour notre lab de démo :
mkdir Snaplet
cd Snaplet
  • Créons un fichier compose.yml :
version: '3.1'

services:
  source:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example
    ports:
      - 5454:5432

  target:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example
    ports:
      - 5555:5432
  • Lancez le docker compose :
docker compose up

Création des bases de données

  • Créons une base de données demosur l’instance de production :
psql -h localhost -p 5454 -U postgres -c "CREATE DATABASE demo;"
  • Créons de fausses tables et de fausses données sur l’instance de production en créant un fichier SQL small_db_setup.sql :
-- Drop existing tables if they exist
DROP TABLE IF EXISTS orders CASCADE;
DROP TABLE IF EXISTS customers CASCADE;
DROP TABLE IF EXISTS products CASCADE;

-- Creation of 'customers' table
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) NOT NULL UNIQUE
);

-- Creation of 'products' table
CREATE TABLE products (
    product_id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    price DECIMAL(10, 2) NOT NULL CHECK (price > 0)
);

-- Creation of 'orders' table with foreign keys to 'customers' and 'products'
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    product_id INTEGER NOT NULL,
    quantity INTEGER NOT NULL CHECK (quantity > 0),
    order_date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);

-- Inserting seed data into 'customers'
INSERT INTO customers (name, email) VALUES
('Jean Dupont', 'jean.dupont@example.com'),
('Marie Curie', 'marie.curie@example.com');

-- Inserting seed data into 'products'
INSERT INTO products (name, price) VALUES
('Laptop', 999.99),
('Smartphone', 599.99);

-- Inserting seed data into 'orders'
INSERT INTO orders (customer_id, product_id, quantity) VALUES
(1, 1, 1),
(2, 2, 2);
  • Jouons la requête suivante pour utiliser notre fichier SQL small_db_setup.sql et créer les tables et les données sur l’instance de production :
psql -h localhost -p 5454 -U postgres -d demo -f small_db_setup.sql

Copie et anonymisation des données de production pour vos devs

Nous allons maintenant voir comment copier et anonymiser les données de production pour vos développeurs et vos développeuses.

installation et configuration de Snaplet

Snaplet est un outil qui permet de copier et d’anonymiser les données de production. Il existe une verison en SaaS et une version auto-hébergée. Nous allons utiliser la version auto-hébergée.

  • Installation de Snaplet :
npx snaplet setup
  • Configuration de Snaplet (en utilisant notre instance de production source) pour générer les fichiers de configuration (et en ajoutant les types typedefs et transform qui sont necessaires pour anonymiser les données de manière automatique) :
SNAPLET_SOURCE_DATABASE_URL=postgres://postgres:example@127.0.0.1:5454/demo npx snaplet config generate --type typedefs --type transform

Cette commande génère un fichier snaplet.config.js dans le répertoire courant. Dans notre cas, le fichier ressemble à ceci :

// eslint-disable-next-line @typescript-eslint/triple-slash-reference
/// <reference path=".snaplet/snaplet.d.ts" />
// This config was generated by Snaplet make sure to check it over before using it.
import { copycat, faker } from "@snaplet/copycat";
import { defineConfig } from "snaplet";
copycat.setHashKey("w6CrXJ+ODrVttXsr");
export default defineConfig({
  transform: {
    public: {
      customers({ row }) {
        return {
          name: copycat.fullName(row.name, {
            limit: 100,
          }),
          email: copycat.email(row.email, {
            limit: 100,
          }),
        };
      },
      products({ row }) {
        return {
          name: copycat.fullName(row.name, {
            limit: 100,
          }),
        };
      },
    },
  },
});

On peut voir que Snaplet a généré un fichier de configuration avec des transformations pour les tables customers et products totalement automatiquement. C’est très pratique ! Il est possible de personnaliser les transformations si besoin evidemment.

On peut voir que Snaplet utilise une librairie de génération de données aléatoires pour anonymiser les données. Trop cool non ? Surtout qu’on a pas eu grand chose à faire pour le mettre en place 😃.

Créer un snapshot

Nous allons maintenant créer un snapshot de la base de données de production en anonymisant les données.

  • Création d’un snapshot de la base de données de production :
SNAPLET_SOURCE_DATABASE_URL=postgres://postgres:example@127.0.0.1:5454/demo npx snaplet snapshot capture ./tmp/my-snapshot
  • Vous pouvez maintenant vérifier que le snapshot a bien été créé :
ls -l ./tmp/my-snapshot

Restaurer le snapshot

Nous allons maintenant restaurer le snapshot sur l’instance de développement target.

  • Restauration du snapshot sur l’instance de développement :
SNAPLET_TARGET_DATABASE_URL=postgres://postgres:example@127.0.0.1:5555/demo npx snaplet snapshot restore ./tmp/my-snapshot
  • Vous pouvez maintenant vérifier que le snapshot a bien été restauré sur l’instance de développement :
psql -h localhost -p 5555 -U postgres -d demo -c "SELECT o.order_id, o.order_date, o.quantity, c.name AS customer_name, c.email, p.name AS product_name, p.price FROM orders o JOIN customers c ON o.customer_id = c.customer_id JOIN products p ON o.product_id = p.product_id;"

Conclusion

Snaplet est un outil très pratique pour copier et anonymiser les données de production pour vos développeurs et développeuses. Il permet de rester en conformité avec le RGPD tout en simplifiant la tâche. Plus d’excuses pour ne pas le faire !

La détection automatique des transformations est un vrai plus. Cela permet de gagner du temps pour la création des règles d’anonymisation (même si je vous conseille de les vérifier et de les ajuster à la main) et ne pas ce prendre trop la tête avec ça.

Merci d’avoir lu jusqu’au bout ✌️

Share:
Back to Blog