Données personnelles détectées dans une base de données hors production

Bonjour,

Le scanner a détecté des numéros de carte de crédit non masqués dans votre base de développement, ce qui signifie que l’actualisation a probablement restauré des données de production sans appliquer le processus de masquage. Pour exécuter le script de masquage, il faut le lancer directement sur l’environnement de développement, en ciblant les tables concernées.

Si vous utilisez SQL Server, le script de masquage est généralement appliqué via DBCC ou des procédures stockées personnalisées. Par exemple, un script classique de masquage remplacerait les colonnes sensibles par des valeurs fictives en utilisant UPDATE <table> SET <colonne> = LEFT(NEWID(),16) ou une fonction maison. Vous devez exécuter ce script après l’actualisation, soit manuellement via SQL Server Management Studio, soit en l’intégrant dans le pipeline d’actualisation avec un job SQL Agent.

Dans Oracle, le masquage est souvent géré par Data Masking Pack ou des scripts PL/SQL. Le principe est identique : lancer le package ou la procédure de masquage immédiatement après le rafraîchissement.

Dans PostgreSQL ou MySQL, le masquage est généralement implémenté par des scripts SQL ou des triggers. Vous devez exécuter le script fourni par votre équipe de sécurité, qui applique des fonctions de substitution ou de randomisation sur les colonnes sensibles.

L’important est que le script soit exécuté dans le bon ordre : d’abord l’actualisation des données, ensuite le masquage, avant que les développeurs n’accèdent à la base. Si vous avez déjà le script officiel de votre organisation, il suffit de l’exécuter avec les droits DBA sur la base de développement. Si vous ne disposez pas du script, il faut le demander à l’équipe sécurité, car il doit être conforme aux règles PCI-DSS et ne peut pas être improvisé.

Domic Vo.