Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Brouiller les données sensibles avec Data Masking

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Vous vous êtes souvent demandé comment poursuivre les développements et tests avec des données cohérentes sans toutefois livrer des données de production à vos équipes de développement ?
A un moment ou à un autre, beaucoup d’entreprises se retrouvent à gérer cette problématique, surtout lorsqu’il y a un besoin réel de limiter la diffusion d’informations sensibles sur ses clients, ses finances. Cela devient encore plus sensible lorsque les développements sont externalisés vers un prestataire externe, que celui-ci travaille au sein de vos locaux ou non. Oracle a prévu une option de l’Entreprise Edition incluse dans l’offre Real Application Testing nommée Oracle Data Masking qui permet de brouiller les données contenues dans les colonnes de tables identifiées comme sensibles; on peut alors appliquer le principe du « Need to know » bien connu chez les militaires, où seuls ceux qui ont VRAIMENT besoin de connaître les données réelles y ont accès.
Cet article donne les étapes nécessaires pour offrir un jeu de données cohérentes à vos équipes de dev, stagiaires ou autres.

Stratégie

La stratégie la plus propre, si elle peut être employée, consiste à travailler avec 3 bases:

  • Base de production
  • Base temporaire sur laquelle on gèrera les définitions de masquage et le brouillage des données
  • Base de dev/tests qui sera chargée à partir d’un export full de la base temporaire contenant les données brouillées.

Cette base temporaire devra être accessible uniquement au dba responsable de l’opération. La base temporaire peut être ignorée, et l’on travaillera directement sur la base de dev/tests, mais dans ce cas d’autres mesures devront être prises pour s’assurer que seul le dba autorisé pourra se connecter à cette base tant que les données sensibles n’auront pas été brouillées.

Etape 1. Identifier les colonnes contenant des données sensibles.

Là pas de secret, il faut passer en revue le schéma de données entier et identifier les colonnes contenant par exemple:

  • nom et prénom des utilisateurs ou contacts
  • nom des entreprises
  • Nom de machines, d’instances, de bases de données
  • Adresses mail, URL web, adresses IP
  • Numéros de téléphone, fax

Il est important a ce stade d’identifier les colonnes dotées de contraintes d’unicité, ex. Le login utilisateur ou l’identifiant client car dans ces cas là, on ne peut remplacer la valeur sensible par une chaîne de caractère ou un nombre qui risque de se répéter.

Etape 2. Créer des formats de brouillage

Dans la console Enterprise Manager, il y a déjà une série de format mais qui sont touts orienté anglo-saxon, nous allons donc créer nos propre formats qui seront réutilisés par plusieurs colonnes de tables.
Selon le type de données à brouiller, nous utiliserons différentes techniques: par exemple pour brouiller un numéro de téléphone, nous allons simplement générer un numéro au bon format, c’est à dire 10 chiffres commençant par 06 ou 07 pour un portable français; pour les noms et prénoms, nous créerons une table de données fictive dans un des schémas à brouiller, et nous y piocherons des valeurs. Dans d’autres cas nous pourrions simplement mélanger les données avant de les replacer dans les champs comme l’on mélangerait un jeu de cartes.

Mots de passe

Dans la console Enterprise Manager, allons dans l’onglet « Schéma », section « Masquage des données », lien « Bibliothèque de formats ». Nous allons créer un modèle de masquage (ou bibliothèque) pour les mots de passe qui seront composés de la chaine de caractères « Bienvenue » suivi du chiffre 1 à 9:
Bouton « Créer », donner un nom au modèle: FR-motdepasse
et une description: Format pour masquer un mot de passe Bienvenue[1,9]
Dans la section « Entrée de format », dérouler la liste, choisir « Chaine fixe » et Executer. Saisir « Bienvenue » dans le champ de saisie et valider avec OK.
Maintenant pour le chiffre aléatoire, dans la liste déroulante, au lieu de « Chaine fixe », sélectionner « Liste de tableaux » et Exécuter; cette fois ci, dans le champ de saisie, nous mettons les valeurs séparées par des virgules:
1,2,3,4,5,6,7,8,9 avant de valider avec OK
Dans la section échantillon, vous pouvez cliquer sur « Regénérer » pour avoir un aperçu des mots de passe générés:

Bienvenue4
Bienvenue3
Bienvenue5
Bienvenue1
Bienvenue2

Nous pourrons alors utiliser cette définition pour remplacer tous les mots de passe applicatifs avec des valeurs que nous connaissons.

identifiants (logins)

Nous ferons la même chose pour les logins avec des chaines de caractères fixes suivies cette fois d’un nombre aléatoire compris entre 100 et 999 pour éviter de créer 2 logins identiques:

monclient321
monclient557
userinterne256
...

Noms de serveurs

dmask02

Adresses IP

Pour les adresses IP, nous utiliserons le même principe en construisant une chaine de caractères commençant par 10, 172 ou 192 (pour faire des IP privées), suivi d’un point, une valeur entre 0 et 254 répété trois fois.
dmask07
Les adresses ainsi générées ne seront pas toutes de vraies adresses privées, mais pour notre besoin cela suffira.
Et on peut faire pareil pour des noms de serveurs ou de base que l’on puisse mémoriser!
dmask06

Prénoms, noms, email et noms de sociétés

Ici nous utiliserons la possibilité de piocher des valeurs de façon aléatoire dans une table tampon créée spécialement pour:

CREATE TABLE "DUMMY_DATA"
(
"CUST_FIRST_NAME" VARCHAR2(20),
"CUST_LAST_NAME" VARCHAR2(20),
"CUST_EMAIL" VARCHAR2(50),
"COY_NAME" VARCHAR2(30),
"COY_FIELD" VARCHAR2(20)
)

Insérons des données dans cette table, pour les noms et prénoms j’ai pris les 40 plus courants en France d’après Wikipedia ! Pour les noms d’entreprises j’ai copié 50 noms au hasard dans un fichier de prospects, pour les adresses mail j’ai juste concaténé prénom.nom@entreprise.com en enlevant les espaces dans les noms avant.

insert into DUMMY_DATA (CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL, COY_NAME,COY_FIELD) values ('Martine','Dubois','Martine.Dubois@oseo.com','OSEO','Finance');

La même logique pourrait être appliquée à des adresses postales, mais dans ce cas précis, il peut être envisageable de simplement mélanger des adresses réelles de la table existante surtout s’il y en a beaucoup.

Etape 3. Créer la définition complète de brouillage

Maintenant que nous avons des format pour brouiller les noms, prénoms, adresses IP,mots de passe et login, nous allons créer une « Définition » regroupant toutes les règles. En revenant dans l’onglet « Schéma », section « Masquage des données », allons dans le lien « Définitions » et cliquons sur le lien « Créer » pour créer une définition de nous nommerons « Brouillage MAPROD »

Ajout de colonnes

Pour chaque schema applicatif nous chercherons tous les champs contenant %ip% pour y appliquer le modèle de brouillage d’adresses IP créé précédemment. Sur les 4 champs remontés, 3 ont été identifiés lors de l’étape 1, dans mon cas, le dernier concernant l’IPhone, ne m’intéresse pas ici! Je sélectionne les champs à brouiller et clique sur « Définir le format et ajouter »
dmask03
Dans la page « Définir un masque de colonne », je clique sur « Importer un format » et dans la page suivante, je sélectionne le format « FR-ipaddress » puis « Importer ». La page de définition du masque vue lors de l’étape 2 ci-dessus est de nouveau affichée pour personnaliser la définition si souhaité.
L’opération d’ajout de colonnes à brouiller est répétée pour toutes les colonnes identifiées lors de l’étape 1, en appliquant les formats à une ou plusieurs colonnes d’un coup en fonction du contenu. A la fin de cette opération, ma définition comporte 48 champs ou colonnes de plusieurs schéma contenant des données à brouiller, mélanger ou remplacer.

Produire le script

Nous pouvons générer le script de masquage; cette opération prend quelques minutes, la page Enterprise Manager permet alors de visualiser ce script sous forme de récapitulatif ou  bien le script complet, à noter également dans la deuxième moitié de la page un rapport d’impact alertant en cas d’espace insuffisant: avant d’être brouillées, les données sont copiées dans des tables temporaires qui pourront être purgées à la fin de l’opération, en attendant il faut une volumétrie disque suffisante.
Nous choisirons d’enregistrer le script complet afin de le télécharger et étudier le script plus tard.
dmask09
Il est également possible d’exporter la définition au format xml, ceci permet alors de la ré-importer dans une autre base de test puis de lancer le brouillage sur des schémas importés depuis la production avec impdp par exemple.

Etape 4. Appliquer le brouillage

Lorsque la définition de brouillage est prête, elle doit être disponible sur la machine qui va brouiller les données.
Les données des schémas métier à brouiller sont importées dans la base temporaire (ou de dev/tests) par impdp.
Après, le plus efficace est d’utiliser la console Enterprise Manager, et aller dans les définitions de masquage, sélectionner la définition et cliquer sur « Programmer le travail » (le job…). Il est également possible d’exécuter le script maskingNNN.sql, mais celui-ci ne gère pas toutes les tâches de nettoyage à la fin du processus, notamment la suppression de tables temporaires pouvant contenir des données sensibles.
dmask10
Dans l’exemple ci-dessus, EM va générer un script masking452.sql dans le dossier $ORACLE_HOME/dbs
Comme nous somme sen exécution immédiate, le job est lancé et peut être suivi dans la console en rafraichissant la page du navigateur avec F5, ou bien avec un tail sur le fichier $ORACLE_HOME/dbs/maskingNNN.log bien que cette trace semble disparaitre à la fin du traitement
dmask11

Etape 5. Epilogue

Penser à vérifier/supprimer/modifier les dblinks, dba_directories, mots de passe administrateurs et applications sur la base clonée+brouillée.
Un passage de utlrp.sql et un calcul de statistiques, ne seraient pas non plus du luxe suite à l’import/brouillage; et la base pourra être ouverte aux développeurs, testeurs & key users.
Si vous travaillez avec une base temporaire, il faudra rajouter la phase d’export/import vers la base de dev/tests.
En conclusion, l’option du Datamasking est particulièrement riche en fonctionnalités qui ne peuvent être documentées dans un seul article.
La documentation Oracle dans http://docs.oracle.com/cd/E11882_01/server.112/e16540/tdm_data_masking.htm#DAFJDJAA et vous donnera plein d’autres options disponible lors du brouillage des données

1 réflexion sur “Brouiller les données sensibles avec Data Masking”

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.