Guida GDPR per sviluppatori

In questi ultimi anni, noi sviluppatori siamo stati molto a contatto con tutto ciò che riguarda l’adeguamento GDPR. Se non altro perché abbiamo dovuto gestire le richieste dei clienti per adeguare siti e applicazioni a tale normativa.

Ricapitolando, la GDPR è il nuovo regolamento dell’Unione Europea riguardo alla protezione dei dati che si applica praticamente a tutti. Se lavoriamo per una grande compagnia, è molto probabile che ci sia già un regolamento in vigore che rende i sistemi compliant alla normativa.

Da tenere presente che la normativa si applica anche ai paesi non-europei ma che hanno i propri utenti residenti in Europa. Detto così fa capire che riguarda un pubblico molto, molto esteso di aziende e servizi.

Prima, un po’ di teoria. I diritti che l’utente/cliente (che nella normativa è definito come “data subject”) che sono rilevanti per noi sviluppatori sono: il diritto alla cancellazione (quindi ad essere cancellato definitivamente dal sistema), la proprietà dei dati relativi ad esso, la portabilità di questi (cioè la possibilità di esportare in un formato leggibile i dati che possediamo), il diritto alla rettifica, il diritto ad essere informato facilmente (cioè avere informazioni facilmente leggibili anziché una lista infinita di termini e condizioni) e infine il diritto all’accesso, ovvero la capacità di sapere di quali dati siamo in possesso.

Assieme a questi, ci sono altri principi rilevanti, come la minimizzazione dei dati (cioè raccogliere soltanto lo stretto necessario), integrità e confidenzialità (ovvero i metodi per la protezione dei dati più le misure per garantire che i dati non vengano modificati impropriamente).

Ancora, il GDPR prevede che siano formalizzati alcuni processi (nel caso si parli o di un azienda con oltre 250 dipendenti oppure se la mole dei dati è consistente) come quelli riguardante il logging di tutte le attività che hanno a che fare con i dati, inclusi i trasferimenti di dati verso terze parti, come ad esempio i provider cloud o di statistiche. Questa è l’unica parte che riguarda le grandi aziende, mentre tutte le altre, riguardano tutti, perché riguardano il diritto delle persone. Quindi il mito “sono piccolo, la GDPR non ci interessa” è una cazzata.

Parliamo sempre di “dati personali”. Ma quali sono questi dati? In linea di principio può essere definito come un dato personale, qualsiasi dato che può essere utilizzato per identificare univocamente una persona. Di solito, corrispondono ai dati inseriti direttamente dall’utente, ma anche ai dati raccolti da siti di terze parti basati sulle attività che esso fa sul sito (tipo la cronologia di navigazione, gli acquisti, etc.)

Detto questo, vediamo una serie di feature che sarebbe meglio implementare (e magari come farlo), assieme ad una lista di cosa NON fare. Da notare, che non tutte le operazioni che vi descrivo di seguito dovranno essere automatiche/automatizzate, ma possono essere effettuate manualmente se il caso lo richiede. Ovvio che su grandi sistemi, sarebbe meglio renderle self-service per non intasare il customer care.

Dimenticami

(Art. 17) Dovremmo implementare un sistema che, dato l’ID di un utente, cancella tutti i dati che possediamo su esso (sempre raccolti sulla base del suo consenso). Questo tipo di sistema può esserci molto utile sugli ambienti di test (per pulirlo dalle prove che eseguiamo), ma può essere complicato da sviluppare anche nella realtà, perché potrebbe creare incongruenze nel database andando a cancellare record e lasciando chiavi esterne senza collegamenti. Questo significa due cose: o creiamo un data-model che preveda delle chiavi cancellabili (ad es. se un Ordine ha un collegamento con l’utente, e questo chiede la sua cancellazione, dobbiamo poter cancellare il suo User ID dall’ordine), oppure cancellare a cascata tutti i record (quindi cancellare sia l’utente, sia i suoi ordini). Qui viene la difficoltà: se l’ordine viene usato per i tracking delle quantità prodotto o per le statistiche di vendita sarà difficile cancellare il suo record e quelli collegati senza creare inconsistenze. Progettualmente potremmo utilizzare un metodo che prevede degli snapshot con l’abilità di cancellare in ogni momento i record e ricreare questi snapshot. In ogni caso la formula “lo schema del database non lo permette” non è buona scusa. E per il backup? In un mondo perfetto dovremmo tenere sempre da parte una tabella con tutti gli ID degli utenti cancellati così se reimportassimo il backup, potremmo ri-cancellare tutti i gli utenti.

Notifica alle terze parti

(Art. 19) Cancellare dati dai nostri sistemi è una cosa, ma siamo anche obbligati ad informare le terze parti alle quale inviamo i dati. Quindi, se per esempio abbiamo inviato dati a Salesforce, Hubspot, Twitter o qualsiasi altro provider cloud o social, dovremmo fare una chiamata API per cancellare i dati dell’utente sui loro sistemi. Se ci trovassimo dall’altra parte, cioè fossimo gli sviluppatori del servizio cloud, dovremmo naturalmente offrire l’endpoint API per farlo. Comunque, una chiamata API non è la fine della storia. Google, per esempio, non ha certo delle API per cancellare le pagine indicizzate, ma ha soltanto un metodo manuale di rimozione URL.

Accesso ristretto

(Art. 18) Nel pannello amministratore, nella lista utenti, dovrebbe esserci un pulsante “Accesso ristretto” per rendere appunto quel dato profilo utente ad accesso limitato. Questo significa che l’utente non dovrebbe essere più visibile agli altri amministratori che accedono al back-end (o al pubblico). Possiamo implementarlo facilmente come un flag.

Esportazione dei dati

(Art. 20) Accanto al pulsante di prima, dovrebbe essercene un altro, molto importante: “Esporta dati”. Una volta cliccato l’utente dovrebbe ricevere via email tutti i dati che possiamo su di esso, qualsiasi essi siano. Idealmente dovrebbero corrispondere ai dati che cancelleremmo se l’utente cliccasse su “Dimenticami”, con l’aggiunta dei dati che prima abbiamo etichettato come “incancellabili”: pensiamo agli ordini che magari non possono essere cancellati per consistenza ma possono essere sicuramente contenuti nell’export che forniamo all’utente. La “forma” dei dati non viene definita dal GDPR, la mia raccomandazione è quella di usare un formato più diffuso possibile, XML o JSON. Se i dati sono semplici, cioè appartengono idealmente allo stesso schema, un semplice CSV/XLS dovrebbe essere ok. Come sappiamo (chi meglio di noi!) l’export può non essere un’operazione che NON può essere eseguita al volo: a questo punto possiamo tranquillamente inviare una mail all’utente con un link quando l’esportazione sarà finita. Twitter, per esempio, ci permette di richiedere copia di tutti i nostri tweet, con un link dal quale scaricare un archivio, via mail. Non dobbiamo scrivere necessariamente un sistema automatico per questa operazione, perché potremmo anche eseguirla manualmente. Certo, però, dai, siamo developer.

Gli utenti possono modificare i propri dati

(Art. 16) So che sembra una cosa ovvia, ma sviluppatori pigri o troppo indaffarati spesso saltano (o fanno male) questo passaggio. Ogni utente loggato deve naturalmente poter modificare i propri dati personali, compresi i dati che lo collegano a terze parti (es. il login con Facebook). La regola d’oro – ma capisco che in certi casi può risultare complesso – sarebbe quella di poter far modificare tutti i dati della “tabella utente”. Certamente questa procedura, come accennavamo poc’anzi, potrebbe essere richiesta ed eseguita manualmente, ma un semplice form rende la vita più semplice a tutti. C’è uno scenario più complicato: quello nel quale i dati vengono presi da terze parti (quindi l’utente non li ha forniti direttamente a noi). Anche qui, la regola vale, l’utente dovrebbe poterli modificare dopo il login.

I checkbox

(Art. 7) “Accetto termini e condizioni” in teoria non è sufficiente a poter affermare che l’utente ha accettato il salvataggio e il processamento dei suoi dati. Questo perché l’utente dovrebbe spuntare un checkbox per ogni singola (o particolare) voce che lo riguarda all’atto della registrazione. Dovremo tenere separati questi consensi all’interno del database in modo da permettere all’utente di togliere il permesso a ciascuna voce dalla propria aria riservata (vedi punto precedente). Questi checkbox, ve lo ricordo, non devono essere checkati di default, altrimenti che consenso è? Un altro punto importante è il machine learning/AI. Mettiamo il caso che i dati vadano a fare in training di un modello ML: anche qui il consenso esplicito è necessario.

Chiedere nuovamente il consenso

Se il consenso espresso in precedenza dall’utente “non è chiaro” (ad esempio ha accettato un generico “Termini e condizioni”) possiamo – e dobbiamo – chiedere nuovamente quel consenso. Il modo migliore sarebbe quello di inviare una email a tutti i nostri utenti, chiedendogli di andare nella propria area personale e di spuntare tutti i checkbox per le attività che reputiamo necessarie. Attenzione: non spammiamo gli utenti!

Visualizza i miei dati

(Art. 15) Questo articolo assomiglia molto a quello sull’esportazione dei dati, cioè al tasto “Esporta”, tranne per il fatto che questi dati devono essere visualizzati nell’interfaccia, in una pagina, anziché in un file XML/JSON. Non è un passaggio obbligatorio, questo, ma sicuramente sarebbe una feature gradita, a favore della User Experience. Google Maps, ad esempio, ci fa visualizzare la cronologia dei nostri spostamenti. Questo vale anche per gli utenti non registrati, che potrebbero chiederci di visualizzare i propri dati in nostro possesso, anche come operazione manuale da parte nostra. Un’idea potrebbe essere quella di avere una funzione “controlla via email”, attraverso la quale possiamo controllare i dati nel database a partire dall’indirizzo che l’utente fornisce.

Controllo dell’età

(Art. 8) quando gli utenti sono minorenni, dovremmo chiedere il consenso dei genitori. Non c’è un modo regolamentato per farlo, il mio suggerimento è quello di creare un processo nel quale l’utente (il minore) indica l’email di un genitore, che poi può confermare in seguito. Ovviamente, chiunque potrebbe barare facilmente sulla propria data di nascita (specialmente i teenager come me quando lo ero io) o indicare una mail falsa.. ma noi siamo a posto dal punto di vista normativo!

Conservare i dati solo il tempo necessario

(Art. 5) Mettiamo il caso nel quale abbiamo dei dati che servono ad uno scopo specifico, come effettuare un ordine da un e-commerce. Secondo il regolamento dovremmo cancellarli o anonimizzarli non appena questi dati non ci “servono” più. Molti e-commerce permettono di acquistare senza registrazione, con il consenso che viene raccolto soltanto per quel singolo ordine. Avremo bisogno di implementare uno script che periodicamente scorre i dati e li anonimizza, una volta che l’ordine è stato evaso. Nel caso specifico degli ordini basterà cancellare nome ed indirizzo. Il mio consiglio è di tenere conto anche del periodo di reso dell’ordine e rendere anonimo l’ordine solo dopo tale data.

Sicurezza nei processi

L’Art. 32 riguarda alcune misure tecniche che è consigliabile adottare per proteggere i dati personali. Sono tecniche non necessariamente destinate a noi developer, ma probabilmente cadranno nei nostri to-do. Chiariamo, però, che queste misure non sono obbligatorie, ma sono delle good practice che dovrebbero già essere in atto, secondo me. Vediamole:

Il passaggio di dati deve essere criptato – Questo significa che lo scambio di dati fra l’application layer e il database deve avvenire su TLS. Il certificato può essere uno “ufficiale” o anche un self-signed, va bene lo stesso. Anche lo scambio fra nodi – pensiamo ai cluster MySQL – deve avvenire allo stesso modo
I dati stanziali devono essere criptati – Anche qui in molti casi dipende dal database (alcuni hanno l’encryption a livello di tabella) ma può essere fatto anche a livello della macchina. Potremmo avvalerci di servizi come AWS KMS per conservare nel cloud le chiavi private.
I backup devono essere criptati – Devo spiegarlo?
Implementare la pseudonimizzazione – Che vuole dire, in parole povere, rendere anonimi alcuni dati, cioè non riconducibili a persone reali. In alcuni scenari, pensiamo a quando inviamo dati (training) ad un sistema di Machine learning (pure di terze parti), dovremmo rendere impersonali i dati. Tecnicamente questo significa che potremmo avere una funzione che pseudonimizza (magari con un nome più carino) un User, applicando un metodo come hash+salt, bcrypt o PBKDF2 sui dati che potrebbero identificare l’utente. Questa modifica potrebbe essere reversibile oppure no, a seconda dei casi.
Tenere un registro delle azioni sotto GDPR – L’Art. 30 dice che dovremmo tenere un archivio di tutte le attività svolte utilizzando i dati personali degli utenti. Sì, suona un po’ come burocrazia. Potremmo implementare un microservice che si occupa di tenere traccia di tutte le azioni, come i checkbox di “Acconsento…” o tutte le altre disposizioni.
Log degli accessi ai dati personali – Ogni operazione di lettura dei dati personali dovrebbe essere loggata, così da sapere chi ha letto cosa e per quale motivo – Questa non è una regola esplicita del GDPR, ma è una buona prassi riguardante il semplice principio della responsabilità. Se un operatore accade (es. tramite una ricerca nel backend) ad una lista di dati che riguardano quindi più utenti? Secondo me un “L’operatore X ha cercato Y nel database” potrebbe essere sufficiente come riga di log. Un’accortezza che potremmo avere è sicuramente quella di non mostrare troppi dati personali in questi risultati di ricerca: a che serve sapere la data di nascita di un utente se vogliamo semplicemente vedere i suoi ordini?
Log delle chiamate API – Non dovremmo mai avere delle API che possono essere chiamate in modo anonimo per accedere a dati personali, ma sarebbe opportuno prevedere la registrazione.

Cosa non fare

Non utilizzare i dati personali per scopi non accettati dall’utente – Art.6 Questo, sembra banale dirlo, è il riassunto dell’intero GDPR. Se volessimo avere un nuovo tipo di API, o utilizzare i dati esistenti per del Machine learning, o aggiungere della pubblicità al sito, o vendere tutto il database a qualcuno – pensiamoci due volte. Come detto in precedenza dovremmo avere un sistema che avvisa gli utenti di darci il permesso per questo nuovo servizio, e saremo costretti a contattare via email in modo massimo tutti gli utenti per ottenere questi nuovi consensi.
Non loggare dati personali – Teniamo lontani dati personali dai nostri log di lavoro, specialmente se poi li inviamo a servizi di terze parti. Limitiamoci all’utilizzo di un ID e assicuriamoci che anche i vecchi log siano puliti.
Non utilizzare campi che non ci servono – Molti sono sempre tentati dall’ottenere più informazioni possibili all’atto della registrazione “per poi trovarseli in futuro”. Ma a meno che non ci servano strettamente per erogare il servizio, non chiediamoli. L’esempio su tutti: ma se non spediamo merce, a cosa ci serve sapere l’indirizzo di una persona?
Non dare per scontati che i siti di terze parti siano in regola – Siamo legalmente responsabili anche se un sistema di terze parti (quelli che normativa chiama processors) al quale inviamo dati personali subisce un data breach. Quindi prima di inviare dati via API ad un altro servizio, assicuriamoci che abbia almeno un livello di protezione base.
Ho un ISO, quindi sono in regola – Le certificazioni ISO coprono una buona parte di queste regole, quindi essendo in regola con quelle, siamo probabilmente compliant almeno al 70%. È sicuramente un buon inizio, ma molte regole che vi ho elencato in quest’articolo non sono automaticamente seguite.

Conclusioni

Chiudo dicendo che lo scopo della GDPR regulation è farci fare scelte consapevoli quando trattiamo dati personali. Certo, ci impone delle pratiche in senso di responsabilità legale, ma se seguiamo questi consigli quando progettiamo il database, lo storage, il data flow, le chiamate API, non dovremmo preoccuparci delle sanzioni (molto cospicue) che potremmo avere in futuro. I Regulators (cioè le autorità garanti) nella maggior parte dei casi ci imporranno una serie di controlli e fix da eseguire, a seguendo queste buone prassi non ci saranno problemi.

Se uniamo il buon senso, anche progettuale, un sistema creato in epoca pre-GDPR può essere adeguato in poche settimane, anche da un solo developer. Dobbiamo, ma sono sicuro che lo sappiamo già tutti, tenerci alla larga dai sistemi GDPR “belli e pronti da utilizzare” come soluzioni generiche. Il GDPR non è solo una questione tecnica, ma coinvolge anche dei processi aziendali.