Les défis de l’anonymisation des bases Test/Devs
L’anonymisation des données sensibles dans les bases Test/Devs : Pour les entreprises manipulant des « données sensibles », ces dernières ne doivent pas être accessibles dans les bases de données Dev / Test, afin de respecter la règlementation RGPD et protéger les données de l’entreprise contre d’éventuelles violations.
Comment protéger les données sensibles tout en préservant l’intelligibilité de la BDD et l’agilité des DEVs ?
-
-
- Par nature, un environnement de base de Dev / Test doit être ouvert, et présenter peu de contraintes pour de ne pas nuire au travail des concepteurs, développeurs et testeurs.
- Les données sur ces environnements doivent être aussi proches que possible des données Prod pour préserver leur cohérence.
-
La meilleure solution pour protéger les données tout en répondant à ces impératifs consiste donc à anonymiser les données sensibles dans les environnements autres que celui de production.
Quel est le défi technique principal de l’anonymisation?
Lorsque les données sont anonymisées, il est impératif de ne pas rompre les contraintes et validations existantes:
-
-
- Préserver la cohérence interne des données composites (ex: adresse avec rue, ville, CP…)
- Préserver les règles de structure des données (ex: carte de crédit, structure Iban…)
- Préserver les règles de dépendance (par exemple: le numéro de sécurité sociale peut contenir une date de naissance qui est également stockée dans une autre colonne de l’enregistrement)
-
Les données anonymisées doivent conserver la qualité des données de votre base de production:
-
-
- Elles doivent être utilisables (pas de hiéroglyphes, prononçables…).
- Cohérentes (les données répétées doivent être anonymisées de la même manière).
- Avoir du sens (attribuer des prénoms féminins et masculins anonymisés séparément, le cas échéant).
- Pouvoir être « rejouées » (la même anonymisation doit être appliquée lorsque les données sont rechargées, de sorte que l’environnement Test / Dev reste familier).
- Être non réversibles. Il ne doit pas être possible de déduire la valeur d’origine de celle anonymisée.
-
Le processus d’anonymisation doit être documenté
Cette documentation est importante à la fois pour les rapports aux auditeurs mais aussi pour le suivi et l’évolution du système.
Il existe une solution d’anonymisation adaptée à votre environnement DB2 for i
Le module Anonymize -DB de la suite Xcase for i peut être utilisé comme une solution autonome complète (indépendante des autres solutions Xcase for i) pour se conformer à vos obligations réglementaires.
- Une fois anonymisées, les équipes de développement peuvent travailler sans contrainte avec des données de haute qualité sans mettre en danger la conformité aux réglementations légales ou aux règles métier internes.
- Anonymize-DB produit un script SQL, qui peut être exécuté pour anonymiser les données ( 8 méthodes d’anonymisation différentes sont proposées). Ce script peut être utilisé pour plusieurs ensembles de données et environnements donnant lieu à un processus répétable et automatisable.
- Avec la qualité des données anonymisées fournies, les testeurs se sentent comme s’ils étaient en production et les données restent cohérentes même lorsqu’elles sont rechargées.
- Test-DB, s’il est combiné avec Anonymize-DB, ne générera qu’un petit sous-ensemble de la base de données Prod pour les Test / Dev, pour un impact minimal sur le délai de livraison des données
- Anonymize génère une documentation textuelle et graphique
- Il prend en charge plusieurs SGBDR simultanés (DB2, SQL Server, My SQL…)
