Chi si occupa di sviluppare un’applicazione complessa come ad esempio una soluzione ERP, un dipartimentale per la gestione della logistica, un CRM o altro software che necessiti di un database OLTP prima o poi avrà la necessità di verificare il funzionamento dell’applicazione con dati reali.
Può essere necessario utilizzare un backup del database di produzione per verificare il funzionamento dell’applicazione con gli strumenti di debug offerti dall’ambiente di sviluppo per correggere bug non riproducibili nell’ambiente di test, per fare troubleshooting o per verificare come performano le query su dati reali, su tabelle con milioni di record.
Vi sarà successo di chiedere ad uno dei vostri clienti più significativi: “Posso prendere un backup del DB di produzione per eseguire test in Azienda?”
Cosa vi ha risposto? Cosa pensate risponderà ora dopo l’entrata in vigore del Regolamento Europeo 679/2016, meglio conosciuto con il nome di GDPR, sulla protezione dei dati personali? Nel migliore dei casi la risposta sarà: “Puoi prendere un backup rispettando la normativa ma i dati devono essere anonimi!”.
Si tratta quindi di mascherare i dati su un backup del database di produzione chiedendo al cliente di effettuare le opportune verifiche prima di prelevarlo con l’autorizzazione finale a procedere.
Le recenti versioni di SQL Server offrono interessanti servizi di data masking ma devono essere attivati e non sono presenti in tutte le versioni di SQL Server.
Ho avuto anch’io questa necessità e non potendo utilizzare i servizi di data masking offerti da SQL Server ho implementato un comando specifico nella command-line utility sqlcmdcli che trovate in questo repository Github.
Il comando anonymizedb anonimizza tutte le colonne di testo (di tipo char, nchar, varchar, nvarchar, text, ntext) più lunghe di due caratteri nel database passato come parametro; esegue in ordine i seguenti step:
- Analisi dello schema del DB
- Disabilitazione delle foreign key attive sulle colonne di testo
- Disabilitazione dei check constraint attivi sulle colonne di testo
- Disabilitazione dei trigger attivi
- Data masking
- Abilitazione delle foreign key (precedentemente disabilitate)
- Abilitazione dei check constraint (precedentemente disabilitati)
- Abilitazione dei trigger (precedentemente disabilitati)
Al termine si otterrà un database le cui colonne di tipo testo sono state anonimizzate.
La prima implementazione dell’algoritmo di data masking è piuttosto semplice; per le colonne di tipo testo minori o uguali a 2000 caratteri, ogni carattere viene shiftato di un numero random di caratteri compreso all’interno di un range. Per le colonne di tipo testo maggiori di 2000 caratteri, al momento viene eseguito il reverse. Le future release di sqlcmdcli potranno implementare algoritmi più sofisticati.
Riporto di seguito un esempio per invocare il comando anonymizedb sul database AdventureWorks2017:
sqlcmdcli.exe anonymizedb -servername:YourTestServer -databasename:AdventureWorks2017 -username:YourSQLLogin -password:YourPassword -verbose
L’esecuzione riporterà un output simile a quello illustrato nella figura seguente:
La command-line utility è scritta in Delphi, è un progetto opensource, chiunque voglia contribuire è il benvenuto, il compilato sqlcmdcli.exe è disponibile nella sezione Releases del repository.
La wiki del progetto è disponibile qui.
Buon divertimento!