Toute équipe chargée des bases de données est tôt ou tard confrontée au même problème : vos meilleures données de test sont vos données réelles, mais leur utilisation en dehors de l'environnement de production représente un risque majeur en matière de conformité. Les réglementations telles que le RGPD, la loi HIPAA et la norme PCI-DSS ne tiennent pas compte du fait que vous ne faisiez « que tester » ; si l'ordinateur portable d'un développeur ou un serveur de préproduction divulgue les noms, adresses e-mail ou informations de paiement réels de clients, il s'agit d'une violation de données. Navicat 18 s'attaque directement à ce défi grâce au masquage de données, une nouvelle fonctionnalité conçue pour transformer les enregistrements de production sensibles en données fictives, sûres et réalistes, permettant ainsi à vos équipes de développement, de test et d'assurance qualité de travailler sans risque.
Why Masking Beats Deleting or Faking Data
Supprimer entièrement les colonnes sensibles ou les remplacer par des espaces réservés manifestement fictifs test1, test2, xxxxx) perturbe souvent les workflows mêmes que vous cherchez à tester. En effet, les requêtes qui dépendent de formats réalistes, de contraintes d’unicité ou d’intégrité référentielle peuvent se comporter différemment face à des données erronées. Le masquage résout ce problème en préservant la structure et la facilité d’utilisation de vos données tout en supprimant tout élément susceptible d’identifier une personne réelle.
Navicat 18 prend en charge cinq techniques de masquage conformes aux normes du secteur
- Substitution : remplace les valeurs réelles par des valeurs réalistes mais fictives (par exemple, un nom réel remplacé par un autre nom plausible)
- Variance : décale les valeurs numériques ou de date d’un décalage aléatoire, en conservant les tendances intactes sans exposer les chiffres exacts
- Brassage : réorganise de manière aléatoire les valeurs au sein d’une colonne, de sorte que les données restent réelles mais ne soient plus associées à la ligne correspondante.
- Hachage : convertit les valeurs en une chaîne de caractères fixe et irréversible, utile lorsque vous avez besoin de cohérence (une même entrée est toujours hachée de la même manière) sans aucune ressemblance avec l’original.
- Mise à NULL : efface simplement entièrement un champ, idéal pour les données qui n’ont absolument aucune utilité en dehors de l’environnement de production
Le choix de la technique à utiliser dépend des besoins réels du test en aval ; le hachage est idéal pour les valeurs sur lesquelles vous devez effectuer des jointures ou des comparaisons, tandis que la substitution permet de conserver la lisibilité des données pour les équipes d'assurance qualité qui les examinent visuellement.
Masquage des données dans Navicat 18 : un guide rapide
La fonctionnalité de masquage des données est disponible dans les éditions Enterprise et Standard et fonctionne avec les bases de données MySQL, Oracle, PostgreSQL, SQLite, SQL Server, MariaDB, MongoDB et Snowflake. Voici comment transformer plusieurs colonnes de données clients réelles en données fictives réalistes et sécurisées :
- Dans la fenêtre principale, sélectionnez Outils → Masquage des données dans la barre d’outils.
- Cela lancera l'assistant de masquage de données, qui nous guidera tout au long du processus.
Sur le premier écran, nous pouvons appliquer le masquage à notre flux de travail en transférant les données masquées vers une autre base de données (option par défaut) ou en appliquant le masquage à des tables existantes. Nous conserverons l'option par défaut.
- Il est ensuite temps de sélectionner les bases de données source et cible. Comme nous avons choisi, à l'écran précédent, de transférer les données masquées vers une autre base de données, nous avons la possibilité de choisir une base de données ou d'exporter le code SQL vers un fichier. Optons pour cette dernière solution et nommons notre fichier « customer_test ». C'est un excellent choix si nous souhaitons utiliser les mêmes données de test sur plusieurs bases de données.
- L’écran suivant nous permet de sélectionner les tables et les lignes que nous souhaitons masquer. Nous choisirons la table « customer ». (Notez que, pour toutes les bases de données à l’exception de MongoDB, l’application du masquage des données nécessite que la table dispose d’une clé primaire.) Deux modes de transfert principaux sont disponibles : « Auto » et « Avancé » : le mode « Auto » masque toutes les lignes et conserve les noms de champs intacts, tandis que l’option « Avancé » nous offre un contrôle total sur le nom de la table cible, les noms de champs, ainsi que sur les lignes à traiter. Nous conserverons tous les paramètres par défaut, à l’exception de l’ensemble d’enregistrements. Ici, nous limiterons les enregistrements aux dix premiers identifiants clients (*customer_ids*). Pour ce faire, nous procéderons comme suit :
- Sélectionnez l'option « Ensembles d'enregistrements personnalisés ». Le curseur se place alors sur une nouvelle ligne vide dans la liste des ensembles d'enregistrements.
- Cliquez sur le bouton représentant trois points [...] à droite de la zone de texte pour ouvrir la boîte de dialogue « Filtre ».
- Cliquez ensuite sur le signe + pour ajouter une nouvelle condition. Vous reconnaîtrez probablement la démarche qui est exactement la même que celle de la clause WHERE du générateur de requêtes visuel.
- Nous pouvons afficher le code SQL généré en cliquant sur le bouton « Aperçu SQL ».
Voici l’écran « Objets de la base de données » une fois complété :
Nous allons maintenant sélectionner les champs à masquer. Choisissons les champs store_id, last_name, email et create_date.
- L’écran suivant nous permet d’indiquer précisément à Navicat comment masquer chaque champ. Passons-les en revue un par un :
La colonne « store_id »
Comme il s’agit d’un champ numérique, « store_id » nous offre de nombreuses options de masquage. Choisissons « Brassage » comme technique de masquage des données. Cela attribuera des identifiants valides à chaque ligne, mais dans un ordre différent.
Nous pouvons voir le résultat au bas de l’écran.
La colonne « last_name »
Pour le champ « last_name », nous utiliserons la « Substitution » comme technique de masquage des données. Il existe également plusieurs catégories parmi lesquelles choisir, allant des plus génériques aux plus spécialisées. « Name » (Nom) conviendra parfaitement à nos besoins.
Nous pouvons également conserver une partie de la valeur d’origine et masquer le reste, ou remplacer la valeur par une valeur fictive. Nous opterons pour la première option afin que chaque lettre du nom de famille, à l’exception de la première, soit masquée par des astérisques (*).
La colonne « E-mail »
Les e-mails disposent de leur propre catégorie, ce qui nous permet d’appliquer un masque différent aux parties « nom d’utilisateur » et « domaine ». En ce qui concerne le nom de domaine, Navicat propose une liste personnalisable de candidats potentiels.
La colonne « create_date »
Les dates et heures offrent de nombreuses possibilités de masquage. Par exemple, nous pouvons convertir un objet DateTime en Date, modifier des valeurs ou les remplacer par des valeurs fictives réalistes.
- Le récapitulatif offre une dernière occasion de vérifier les opérations de masquage avant de lancer le processus.
- Navicat nous fournit un récapitulatif complet des actions qu’il effectue.
- Après avoir fermé la boîte de dialogue, nous pouvons consulter le fichier de sortie dans Navicat via la commande Fichier -> Ouvrir un fichier -> Requête…
Comme l’ensemble du processus s’exécute au sein de Navicat, il n’est pas nécessaire d’exporter les données vers un outil ou un script séparé : vous pouvez masquer une base de données entière en quelques minutes, directement depuis l’environnement dans lequel vous travaillez déjà.
Pour conclure
Le masquage des données comble une véritable lacune pour les équipes qui doivent concilier les exigences de conformité et le besoin concret de disposer de données de test réalistes. Associé à la gamme plus étendue d’outils d’IA de Navicat 18, il transforme ce qui était auparavant un processus manuel et source d’erreurs en une opération réalisable en quelques clics. Si votre équipe traite des données réglementées dans des environnements de développement ou de test, cette fonctionnalité mérite d’être testée dès que vous aurez effectué la mise à jour !
