GDPR lato infrastruttura: cosa significa in pratica

Il GDPR viene spesso vissuto come una questione di moduli da firmare e informative da pubblicare. È una parte della storia, ma non tutta. Molte delle regole del regolamento si giocano sui server, nei database e nei backup: cioè sull’infrastruttura. Chi gestisce sistemi non deve dare pareri legali, ma è utile che capisca quali scelte tecniche il regolamento chiede di prendere. Questo articolo prova a spiegarlo in modo semplice.

Una precisazione doverosa prima di iniziare: questo non è un parere legale. È una spiegazione generale del lato tecnico. Per gli obblighi specifici del proprio caso servono un consulente o il proprio responsabile della protezione dei dati.

Di cosa parliamo

GDPR sta per General Data Protection Regulation, in italiano Regolamento generale sulla protezione dei dati. È il Regolamento (UE) 2016/679, approvato il 27 aprile 2016 e applicabile dal 25 maggio 2018. Riguarda il trattamento dei dati personali, cioè qualsiasi informazione che si riferisce a una persona identificata o identificabile: un nome, un’email, un indirizzo IP, i dati di un ordine.

Il punto di partenza è semplice. Se un sistema conserva o muove dati di persone, il modo in cui lo fa non è indifferente. Il regolamento chiede che sia fatto con criterio e, in caso di problemi, chiede di poterlo dimostrare.

I principi che riguardano chi gestisce i sistemi

L’articolo 5 elenca i principi di fondo del trattamento. Tre di questi toccano da vicino l’infrastruttura.

Minimizzazione dei dati. I dati raccolti devono essere «adeguati, pertinenti e limitati a quanto necessario» rispetto allo scopo. Tradotto: non si raccoglie tutto per ogni evenienza, ma solo ciò che serve davvero.
Limitazione della conservazione. I dati vanno tenuti «per un arco di tempo non superiore» a quello necessario. Cioè: hanno una scadenza, non si accumulano all’infinito.
Integrità e riservatezza. I dati vanno trattati in modo da garantire un’adeguata sicurezza, compresa la protezione da accessi non autorizzati e da perdite o distruzioni accidentali.

C’è poi un quarto principio che fa da cornice, la responsabilizzazione (in inglese accountability): chi tratta i dati deve non solo rispettare le regole, ma essere «in grado di comprovarlo». È il motivo per cui tante scelte tecniche vanno documentate.

Cifratura: dati a riposo e in transito

L’articolo 32 riguarda la sicurezza del trattamento. Tra le misure che cita per nome ci sono «la pseudonimizzazione e la cifratura dei dati personali».

Cifrare vuol dire trasformare i dati in modo che siano leggibili solo con la chiave giusta. Nella pratica si distinguono due momenti.

In transito, cioè mentre i dati viaggiano in rete. È il caso di un sito che usa HTTPS invece di HTTP, o di un collegamento tra due server dentro un tunnel cifrato. Chi intercetta il traffico vede passare qualcosa, ma non riesce a leggerlo.
A riposo, cioè mentre i dati stanno fermi su un disco. Se il supporto viene rubato o una copia finisce nelle mani sbagliate, senza la chiave resta illeggibile, un principio che vale anche sullo storage cloud, dove per esempio S3 ha cambiato le impostazioni predefinite di cifratura.

Lo stesso articolo considera i rischi legati alla distruzione, perdita, modifica, divulgazione o accesso non autorizzato a dati «trasmessi, conservati o comunque trattati». Da qui la distinzione pratica tra dati in movimento e dati fermi.

Log: utili, ma non per sempre

I log - i registri di ciò che accade su un sistema - sono preziosi per capire i problemi e ricostruire un incidente. Ma spesso contengono dati personali: un indirizzo IP, un nome utente, l’orario di un accesso.

Questo significa che anche ai log si applicano gli stessi principi. Minimizzazione: registrare ciò che serve, non tutto per abitudine. Limitazione della conservazione: definire per quanto tempo tenerli e poi cancellarli o anonimizzarli. Tenere i log all’infinito «per sicurezza» va nella direzione opposta a quella che il regolamento indica.

Controllo e tracciamento degli accessi

Un’idea ricorrente è che a un dato debba poter accedere solo chi ne ha davvero bisogno, e per il tempo in cui ne ha bisogno. Sul piano tecnico questo si traduce in cose concrete: account personali invece di credenziali condivise, permessi assegnati per ruolo, revoca degli accessi quando una persona cambia mansione o lascia l’organizzazione, magari partendo da un unico punto di ingresso sorvegliato come un bastion host.

Accanto al controllo c’è il tracciamento: sapere chi ha fatto cosa e quando. Serve sia a scoraggiare gli abusi sia, in caso di incidente, a capire cosa è successo. È anche uno degli strumenti con cui si dimostra di aver agito con criterio.

Backup sicuri

L’articolo 32 cita anche la capacità di ripristinare tempestivamente la disponibilità e l’accesso ai dati dopo un incidente fisico o tecnico. In altre parole: i backup non sono solo una buona pratica, sono parte della sicurezza richiesta.

Ma un backup è a tutti gli effetti una copia dei dati, e va protetto come l’originale, idealmente seguendo una strategia strutturata come la regola del 3-2-1. Se i dati in produzione sono cifrati e le copie no, la protezione ha un buco. Per questo un backup andrebbe cifrato, conservato in un luogo sicuro e testato: una copia che non si riesce a ripristinare non protegge nessuno.

Dove risiedono i dati

Un’altra domanda che il regolamento rende rilevante è semplice: dove si trovano fisicamente i dati? Il GDPR pone condizioni specifiche per il trasferimento di dati personali fuori dall’Unione europea. Non è un divieto, ma richiede garanzie.

Per chi gestisce infrastruttura questo si traduce in scelte concrete su come scegliere il fornitore cloud e sulla regione in cui girano i server e vengono conservati i backup. Sapere in quale Paese risiedono i dati non è un dettaglio burocratico: è un’informazione tecnica che conviene conoscere.

Un approccio, non una lista di regole

Verrebbe voglia di avere una checklist fissa di «misure minime». Il regolamento non funziona così. Come ricorda anche il Garante per la protezione dei dati personali, l’elenco dell’articolo 32 è aperto e non esaustivo, e dopo il 25 maggio 2018 non esistono obblighi generalizzati di misure minime: la scelta è rimessa caso per caso al titolare, in rapporto ai rischi concreti. Un punto fermo però c’è: difendere come adeguato un software abbandonato dal produttore è quasi impossibile.

Questo è il concetto di protezione «fin dalla progettazione», previsto dall’articolo 25: la tutela dei dati va pensata all’inizio, quando si progetta un sistema, non aggiunta alla fine. E va proporzionata al rischio: i dati di un forum di quartiere e quelli sanitari di una clinica non richiedono le stesse cautele.

Un ultimo punto pratico. Se avviene una violazione dei dati che comporta un rischio per le persone, il titolare deve notificarla all’autorità di controllo «senza ingiustificato ritardo e, ove possibile, entro 72 ore». Avere in anticipo log, backup e un minimo di procedura rende questa scadenza gestibile invece che un’emergenza.

In sintesi

Sul piano infrastrutturale il GDPR chiede cose ragionevoli: cifrare i dati fermi e in movimento, raccogliere e conservare solo il necessario, controllare e tracciare gli accessi, proteggere i backup, sapere dove risiedono i dati. Non è una lista da spuntare una volta sola, ma un modo di progettare i sistemi proporzionato al rischio e capace di rendere conto delle proprie scelte. Il lato legale resta un altro mestiere: per gli obblighi del proprio caso serve un consulente.