L’articolo 32 del Regolamento Europeo sulla Data Protection (GDPR) prescrive di mettere “in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”. Tra queste misure viene prevista la pseudonimizzazione dei dati (conservazione di informazioni di profilazione in una forma che impedisca l’identificazione dell’utente); questa tecnica diventa particolarmente rilevante quando non vi è necessità di utilizzare i reali e completi dati personali degli interessati.
Pseudonimizzazione o anonimizzazione dei dati?
Sono diversi i casi in cui questo avviene. Si pensi, per esempio, a un’azienda che lavori nel campo della somministrazione di trattamenti sanitari: i propri medici avranno bisogno di tutte le necessarie informazioni per la cura del singolo paziente; la struttura di Ricerca e Sviluppo non avrà bisogno dei dati del singolo paziente, ma dei dati aggregati di tutti i pazienti, per esempio, per comprendere l’incidenza di una specifica patologia su una certa regione geografica, su una certa fascia di età o su un particolare sesso.
L’Azienda, il Titolare del Trattamento, sarà quasi sempre in grado, grazie a tutti i dati in suo possesso, di risalire ai dati del singolo interessato a partire dal dato aggregato, pseudonimizzato (figura 1). Si parla infatti di “anonimizzazione” esclusivamente quando il Titolare non è in grado in nessun modo di risalire al dato specifico di un interessato perché non possiede più o non ha mai posseduto le informazioni complete.
In alcuni casi è possibile ricorrere a una tecnica di anonimizzazione del dato basandosi su una tecnica definita Data Masking .
Per il trattamento di tali dati personali verranno plausibilmente utilizzati sistemi informatici specifici. Tali sistemi sono spesso sistemi specializzati e complessi, soggetti a procedure di change management specifiche e, secondo le best practice internazionali più accreditate, parte di un ecosistema di sistemi informatici, in cui quelli di produzione sono solo una quota parte di quelli necessari alla corretta erogazione del servizio e trattamento dei dati. In questi casi la pseudonimizzazione dei dati ottenuta tramite la rimozione di alcune informazioni non sarebbe uno strumento efficace per assicurare la “minimizzazione dei dati” ex art. 5.
Di seguito si ipotizza un ipotetico modello di procedura di gestione di application lifecycle all’interno di una procedura di change management per comprendere l’efficacia del Data Masking a tutela del business del Titolare e dei diritti dell’interessato (figura 2).
Plausibilmente esisterà un sistema di sviluppo delle nuove funzionalità, a cui avrà per certo accesso il fornitore / team di sviluppatori al fine di implementare quanto richiesto dal demand management.
Secondo il modello ipotizzato esisterà un sistema di test sul quale verrà verificato il funzionamento e la correttezza delle nuove funzionalità, o della modifica di quelle esistenti. A tale sistema, oltre al fornitore, avranno accesso i key user che dovranno testare i business case definiti, al fine di poter validare il corretto funzionamento del sistema.
Esisterà, sempre plausibilmente, un sistema dedicato alla formazione, in cui gli utenti potranno eseguire, guidati, in modalità training-on-the-job o in modalità self service tutti i necessari test per diventare “esperti” del sistema e delle nuove o modificate funzionalità. Tale sistema permetterà di eseguire tutti i necessari “esperimenti, test” al fine di verificare il corretto utilizzo delle procedure da parte degli incaricati, senza manipolare i dati “reali, di produzione” degli interessati.
Sempre volendo seguire le best practice di settore dovrebbe esistere un sistema di pre-produzione, dove solo lo staff interno ai Sistemi Informativi eseguirà i necessari test, prima di mettere in produzione le modifiche eseguite al sistema, siano esse di tipo minor or major.
In uno scenario come quello prospettato la pseudonimizzazione dei dati non potrà essere ottenuta tramite la rimozione degli estremi identificativi specifici dell’interessato, come nel primo esempio. Per questa ragione si ricorre a una tecnica chiamata Data Masking che consiste nel sostituire sui sistemi ove questo sia consigliabile e opportuno (misura di sicurezza adeguata), i sistemi di sviluppo, test, formazione i dati reali con dati plausibili.
Compiuta la pseudonimizzazione dei dati, gli sviluppatori avranno la possibilità di lavorare e svolgere le verifiche del caso, visualizzando dati coerenti, ma non reali. Inoltre le misure di sicurezza meno stringenti, troppo spesso applicate ai sistemi di test, non metteranno a rischio la riservatezza delle informazioni.
Anche i key user durante i test e gli incaricati, in fase di formazione, avranno accesso a dei dati intelligibili, che permettano di operare in modo concreto, senza dover operare sui dati reali degli interessati.
Avere sistemi di sviluppo, test, formazione con dati reali di produzione è purtroppo una prassi consolidata, anche grazie ai moderni sistemi di virtualizzazione dei server, poiché è possibile in pochi secondi creare un ambiente parallelo, replicato a partire dal sistema di produzione, e quindi ad esso fedele, sul quale eseguire tutte le necessarie operazioni.
Questa prassi, purtroppo però, mette a serio rischio la confidenzialità di tali informazioni. Per questa ragione si ricorre al Data Masking.
Il processo di Data Masking
Il processo di Data Masking, operato tramite software specifici, peculiari del DBMS in uso, permette quindi di trasformare i dati degli interessati in modo semplice, trasparente e irreversibile, così da garantire il principio di minimizzazione dei dati.
Un esempio di Data Masking può essere quello riportato nella figura 4.
Un software automatizzato che anonimizzi i dati reali in tal modo permetterebbe quindi di poter consultare un’anagrafica clienti, fornitori, un elenco fatture, un elenco di carte di credito, codici fiscali, e-mail o indirizzi conservando la coerenza dei diversi campi, rendendola comprensibile a chi svolge i test, senza esporre i dati reali degli interessati.
Se l’elenco dei dati mascherati venisse perso (perdita di disponibilità), corrotto (perdita di integrità), sottratto, copiato o diffuso (perdita di riservatezza), l’impatto per il business e per gli interessati sarebbe nullo.
Si ritiene opportuno sottolineare, tuttavia, che l’utilizzo di questa tecnica, oltre ad essere coerente con le misure previste dal Regolamento Europeo sulla Data Protection e oltre ad essere in linea con le più diffuse best practice di mercato, procurerebbe enormi benefici circa le minori necessità in merito alle misure di sicurezza da adottare in alcuni ambienti applicativi, ma non annullerebbe la necessità di continuare a seguire le politiche aziendali di cyber security. Se è vero che una violazione di tali sistemi, infatti, avrebbe un impatto nullo su business o diritti degli interessati, comunque una compromissione di tali sistemi a causa di aggiornamenti (patch) mancanti o password deboli potrebbe portare a gravi conseguenze.
A titolo di esempio non esaustivo è possibile citare più gravi intrusioni su altri sistemi aziendali, in caso di segregation non completa e totale, o all’utilizzo di tali sistemi come testa di ponte per attacchi nei confronti di altri sistemi, esterni all’azienda.
Per concludere, la tecnica di Data Masking si rivela molto spesso uno strumento essenziale nel rendere accessibili a terzi, come ad esempio i fornitori, esclusivamente dati non riservati o particolari. Questo permette di garantire tanto i diritti degli interessati, quanto la tutela del Business Aziendale, impedendo che dati particolarmente riservati possano essere erroneamente diffusi o trafugati. Il Data Masking, infatti, permette di dimostrare in maniera efficace, secondo il principio dell’accountability proprio del GDPR, che i dati personali trattati sono “adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)” in conformità a quanto prescritto dall’art. 5, comma 1.c.
