Pseudonimizzazione VS Anonimizzazione, facciamo chiarezza

In questo articolo cercherò di fare chiarezza su cosa si intende per Pseudonimizzazione e cosa la differenzia dall’anonimizzazione.

Il GDPR introduce I concetti di Privacy by Design e Privacy by default, concetti che anche prima della loro espressione ufficiale erano tema di riflessione nello sviluppo di qualsiasi software.

Nello specifico, quando parliamo di Privacy by Design, significa ragionare su come fare il possibile per garantire la Sicurezza dei dati personali durante tutto il ciclo del prodotto o servizio aziendale.
La sicurezza delle informazioni personali trattate da un sistema informatico si progetta dall’inizio.

Quando ragioniamo sui sistemi per proteggere le informazioni, oltre alla criptazione, dobbiamo valutare in base alle necessità, meccanismi quali la Pseudonimizzazione e l’ Anonimizzazione dei dati personali.

Cosa è la Pseudonimizzazione

La pseudonimizzazione è una misura di sicurezza introdotta ufficialmente dal GDPR, che la definisce come:

"Il trattamento dei dati personali in modo tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente e soggette a misure tecniche e organizzative intese a garantire che tali dati personali non siano attribuiti a una persona fisica identificata o identificabile" (art. 4 punto 5 del GDPR).

Cosa è l’Anonimizzazione

L'anonimizzazione è un processo mediante il quale, i dati personali vengono modificati in modo irreversibile e tale che l'interessato non possa più essere identificato direttamente o indirettamente da nessuno, nemmeno in collaborazione con altre parti.

Pseudonimizzazione VS Anonimizzazione

La Pseudonimizzazione la si usa quando dobbiamo proteggere i dati dell’interessato, in alternativa o insieme alle tecniche di criptazione.

L’anonimizzazione invece, la possiamo usare quando abbiamo necessità di gestire dati per esempio per una ricerca scientifica, per statistiche, dati aggregati e non abbiamo necessità o diritto che tali dati siano associati agli interessati.
In questi casi possiamo sottoporre i dati ad anonimizzazione. In tal modo trasformiamo i dati personali in dati non più personali perché non associati agli interessati, leggasi "dati anonomizzati".

Quando usare la pseudonimizzazione e quando l’anonimizzazione?

Facciamo un esempio reale che ci aiuta a comprendere meglio la visione d’insieme.
Mettiamo che un software di un negozio di occhiali gestisca questo set di informazioni di fantasia :

Tabella A

in questa tabella stiamo trattando dati personali ad alto rischio, perché? Perché sono dati riguardanti la salute, “parliamo di problemi visivi dei soggetti”. Nello specifico tali dati vengono definiti “Dati particolari”, tempo fa li conoscevamo con l’appellativo di “Dati sensibili”.

In base all'utilizzo che se ne deve fare distinguo di seguito due Casistiche (Caso 1 e Caso 2)

Caso 1 - Quando usare l'Anonimizzazione dei dati personali

Il titolare del negozio vorrebbe tenere le informazioni storiche del livello di miopia di tutte le persone che hanno acquistato occhiali.
Perchè? Per fini marketing ad esempio, perché vuole sapere se ci sono range di miopia ed età che portano i clienti ad essere più interessati all’acquisto di lenti a contatto.

Se “giuseppe verdi” non è più cliente, il Titolare del trattamento, non ha nessun diritto di trattare ulteriormente le sue informazioni.
C’è una soluzione? certo! ci viene in aiuto l’anonimizzazione ed ecco come metterla in atto:

La nostra applicazione deve prevedere la cancellazione “esclusivamente” dei dati che possono ricondurre a un’interessato. Nel semplice caso della tabella in questione, il dato"nominativo". Nei casi reali avremo sicuramente, quantomeno, anche il codice fiscale.

Potremo quindi continuare a utilizzare i dati "originariamente di Giuseppe Verdi", per i nostri fini statistici, perché non sono più riconducibili a nessun interessato.

Ecco la tabella con anonimizzazione dei dati (Tabella B)

Consiglio comunque che all'anonimizzazione si affianchi un meccanismo di generalizzazione del dato, atto a ridurre il grado di dettaglio di una determinata informazione.

Di che sto parlando? Ipotizziamo che:
- abbiamo anonimizzato le informazioni in nostro possesso
- nella tabella (B) sia presente il campo "data di nascita", es “04/02/2000”
- il negozio stia in un paesino di 10.000 abitanti
In questo caso, siamo sicuri che non si possa riuscire in nessun modo a identificare a chi si riferisca il record (anonimizzato)?
Per vie traverse si potrebbero incrociare i dati di nascita dei residenti nel paese e trovare quindi con un certo grado di probabilità l'interessato.

Quindi cosa è possibile fare? Generalizzare l’informazione!
E' possibile trasformare la data di nascita “04/02/2000” in anno di nascita “2000”.
Per questione di compatibilità con la tipologia DateTime dei database, è possibile stabilire che le date processate per la generalizzazione abbiano il formato “01/01/anno”. Nel nostro caso diventerebbe “01/01/2000”.

Caso 2 - Quando usare la Pseudonimizzazione dei dati personali

Il titolare del negozio di occhiali deve sapere che il signor rossi suo cliente ha attualmente 2 gradi di miopia e 1 di presbiopia.
Il titolare del trattamento (che per noi è sempre il negoziante - ottico) deve comunque adottare delle misure di sicurezza tecniche (oltre quelle organizzative) per proteggere tali informazioni.
Può proteggere i dati con l’anonimizzazione? Certo che no, non riuscirebbe a usarli per lo scopo principale.
Può invece proteggerli con la pseudonimizzazione.

Come funziona la pseudonimizzazione?

1) Il titolare del trattamento deve individuare:
- quali dati sono identificatori, come ad esempio il nominativo o il codice fiscale;
- quali dati sono informazioni correlate, es grado di miopia, presbiopia, lenti a contatto

2) Applicare una tecnica per pseudonimizzare le informazioni, fondamentalmente:

1. si disaccoppia l’identificatore dalle informazioni correlate
2. si sostituisce l’identificatore con uno pseudonimo o un token
3. si mappano gli pseudonimi con gli identificatori degli interessati (tabella di mapping)
4. I dati disaccoppiati si conservano su un sistema (data base) differente e quanto più lontano possibile (altra sede e meglio ancora altra web farm) da quello in cui sono conservati gli identificatori.

In questo caso visto che solo il Titolare o il responsabile del trattamento ha visione “sulla tabella di mapping” sarà solo lui ad avere le informazioni necessarie a risalire all’identità degli interessati.
Attenzione: I dati sottoposti a tale processo continuano ad essere dati personali e come tali vanno trattati, finalità comprese. Non facciamo quindi confusione con i dati anonimizzati.

Di seguito un esempio semplificato di disaccoppiamento delle informazioni

Tabella delle informazioni disaccoppiate

Tabella di mapping identificatori (interessati) ↔ pseudonimi

Ovviamente non si tratta solo di un sistema per mascherare il dato, questa operazione è già fattibile con i moderni DBMS che applicano delle maschere “al volo” ai dati estratti in base alle utenze utilizzate.

La forza di questo sistema sta nel disaccoppiamento delle informazioni e conservazione in ambienti separati.
Se il database delle “informazioni pseudonimizzate o disaccoppiate” subisce un accesso abusivo o è oggetto di furto, gli interessati sono comunque protetti.
Chi ha avuto accesso a tali informazioni, se non ha accesso alla “tabella di mapping” che ricordiamo essere la mappatura tra pseudonimi e identificatori degli interessati non sarà in grado di associarli (se tutto è stato correttamente progettato).

Come creare gli pseudonimi? Esistono diversi metodi purché:

• garantiscano l’univocità nel sistema
• non permettano di risalire all’identificatore

Va benissimo la generazione di una GUID (Globally Unique Identifier, identificatore unico globale) che è un numero pseudo-casuale.
Va benissimo l’applicazione di un algoritmo di SHA (Secure Hash Algorithm) purché l’informazione originale sia abbinata a un SALT, necessario a rendere inefficaci le Rainbow Table (per i profani: tabelle pre-calcolate per invertire le funzioni hash crittografiche)

Personalmente sono per l’uso della GUID ma dipende tutto da come si vuole gestire il sistema di mapping.