Il caso
In Se tutto dipende da tutto, il problema non è il codice ho raccontato di un e-commerce con social network integrato, migliaia di utenti e un monolite ereditato dall'outsourcing.
La tabella users era letta e scritta dalla registrazione, dal social network e dai processi di pagamento, con join su cinque o sei tabelle e un grafo di dipendenze che nessuno conosceva per intero.
Una piattaforma con migliaia di utenti tratta dati personali, e prima o poi qualcuno chiede di essere cancellato. Nel racconto quella richiesta non c'è, ma una delle attività a cui dovemmo ottemperare fu proprio l'adeguamento al GDPR.
La richiesta
L'articolo 17 del GDPR dice che l'interessato ha il diritto di ottenere dal titolare "la cancellazione dei dati personali che lo riguardano senza ingiustificato ritardo", per esempio quando i dati "non sono più necessari rispetto alle finalità per le quali sono stati raccolti". Ti sei iscritto su un social network e vuoi cancellarti? Puoi chiedere che la piattaforma cancelli tutti i tuoi dati. Attenzione però, non è un diritto assoluto: il paragrafo 3 esclude, tra l'altro, i dati che vanno conservati per adempiere un obbligo di legge.
L'articolo 20 chiede invece l'operazione opposta: l'interessato ha il diritto di ricevere i dati che ha fornito "in un formato strutturato, di uso comune e leggibile da dispositivo automatico", quando il trattamento si basa sul consenso o su un contratto. Ti sei iscritto a un social network e vuoi un "backup" delle informazioni che ha su di te? Hai il diritto di richiederlo, e il paragrafo 3 chiarisce che la portabilità non incide sul diritto alla cancellazione previsto dall'articolo 17: esportare non vuol dire cancellare.
L'articolo 25 aggiunge la parte di progettazione: il titolare mette in atto misure tecniche e organizzative adeguate "volte ad attuare in modo efficace i principi di protezione dei dati", e per impostazione predefinita tratta "solo i dati personali necessari per ogni specifica finalità", anche in termini di accessibilità. Tenendo conto dello stato dell'arte e dei costi: nessuno chiede l'architettura perfetta.
In pratica: devi sapere dove vive ogni singolo dato di una persona, e poter decidere campo per campo cosa cancellare e cosa conservare.
La stessa riga, tre destini differenti
Il punto critico era proprio la riga della tabella users, informazioni dell'utente quali nome e cognome che, dietro richiesta di cancellazione avrebbero dovuto sparire, creando così un problema nel confronto dei dati legati ai pagamenti e agli ordini la cui conservazione ha obblighi fiscali.
In quel monolite cancellare il profilo significava rompere l'esportazoine dei dati di checkout, ed elencare tutti i posti in cui comparivano i dati di una persona era un lavoro di archeologia informatica.
Esportare e cancellare sono la stessa domanda posta in due modi: dove sono i dati di questa persona? L'export dovemmo costruirlo, e per farlo bisognava prima rispondere a quella domanda. Per la cancellazione, dove la riga del profilo non si poteva rimuovere senza rompere i riferimenti, optammo per sostituire i dati personali con valori casuali.
Funziona e si può fare a due condizioni: i valori devono essere davvero casuali, non derivati dagli originali (un hash dell'email si ricalcola partendo dall'email quindi non andrebbe utilizzato), e bisogna guardare cosa resta collegato a quella riga: se lo stesso user_id porta ancora a ordini e indirizzi, quei dati restano personali, e si tengono solo se c'è una base per farlo, come un obbligo fiscale. Altrimenti è pseudonimizzazione, non anonimizzazione, e per il GDPR i dati pseudonimizzati restano personali.
La separazione per domini l'abbiamo fatta per poter rilasciare, non per il GDPR. Ma il metodo era lo stesso che serve qui: mappare quali moduli leggono e scrivono quali tabelle, e dare a ogni dominio i suoi dati. Un servizio che possiede i propri dati può avere la propria procedura di cancellazione, con le proprie regole di conservazione.
Lo ritrovo spesso, anche senza tirare in ballo i monoliti: l'utente rimosso dall'applicazione ma ancora ben presente nel CRM, o peggio ancora nella piattaforma di newsletter e negli export condivisi.
Dichiarato vs dimostrato
| Cosa si dichiara | Cosa si dimostra |
|---|---|
| "Gestiamo le richieste di cancellazione" | Il registro delle richieste: data, risposta, tempi, sistemi coinvolti |
| "Gli utenti possono scaricare i propri dati" | L'export di un utente di test, confrontato con la mappa dei dati: cosa c'è e cosa manca |
| "Sappiamo dove sono i dati degli utenti" | La mappa di quali tabelle e servizi contengono dati personali, e chi li legge e scrive |
| "Cancelliamo tutto" | Per ogni categoria di dato: cancellato, anonimizzato o conservato, e con quale base |
| "Gli utenti cancellati sono anonimi" | Cosa resta dopo la cancellazione, e la verifica che incrociando le altre tabelle non si risalga alla persona |
| "I dati degli ordini li teniamo per legge" | Quali campi, per quanto tempo, e cosa succede alla scadenza |
| "Ogni modulo vede solo quello che gli serve" | I permessi sul database o sui servizi, verificati di recente |
La colonna di destra è quella che serve quando l'interessato, o il Garante, chiede di vedere cosa è successo davvero.
Da dove partirei
- Una mappa dei dati personali. Per ogni tabella o servizio: quali dati di persone contiene, chi li legge, chi li scrive. Non deve essere perfetta, deve bastare a rispondere alla prima richiesta.
- Una regola per ogni categoria di dato. Alla cancellazione: si elimina, si anonimizza, o si conserva per un obbligo di legge, fino a quando.
- Un export e una cancellazione di prova, documentati. Crei un utente di test, lo usi in tutti i flussi, chiedi l'export dei suoi dati e poi la cancellazione. Verifichi cosa esce, cosa resta e dove. Annoti data ed esito.
Non serve riscrivere il monolite in microservizi per rispondere a una richiesta di cancellazione, serve sapere dove sono i dati e avere già deciso cosa farne.
Il caso reale da cui nasce, raccontato come appunto di lavoro: il problema, come l'ho affrontato, cosa ho imparato.
Se tutto dipende da tutto, il problema non è il codice→
In sintesi (TL;DR)
- Gli artt. 17 e 20 del GDPR danno all'interessato il diritto di ottenere la cancellazione dei propri dati e di riceverne una copia in un formato leggibile da una macchina: entrambi presuppongono di sapere dove sono.
- In un applicativo dove registrazione, social network e pagamenti leggono e scrivono la stessa tabella utenti, esportare o cancellare una persona significa prima scoprire dove si trova.
- Dove la riga non si può rimuovere, i dati personali si sostituiscono con valori casuali. Ma se lo stesso id porta ancora a ordini e indirizzi è pseudonimizzazione: quei dati restano personali e si tengono solo con una base come un obbligo fiscale.
- L'art. 25 chiede di progettare il trattamento perché i principi siano rispettati per costruzione: sapere chi tocca quale dato è il primo passo.