I dati di test secondo il GDPR sono una frase che di solito arriva accompagnata da una realizzazione scomoda: il database di staging che tutti hanno interrogato liberamente contiene nomi reali, indirizzi reali e numeri di identificazione reali, e nessuno ha mai deciso che ciò dovesse essere permesso. Era semplicemente comodo.
Questo articolo tratta ciò che conta come dato personale in un record di test, perché gli ambienti di sviluppo sono il posto sbagliato per le copie di produzione, la differenza tra mascherare i dati e rimuoverli, e come appare una sostituzione praticabile.
Cosa conta come dato personale in questo contesto?
Più di quanto le persone si aspettino, e l’elenco è comportamentale anziché tecnico. Un nome, un numero di identificazione, una data di nascita, un indirizzo di casa, un numero di telefono e un indirizzo email sono i membri ovvi. A essi si uniscono membri meno ovvi: una fotografia, un identificatore di dispositivo, una traccia di posizione, un soprannome di account e qualunque nota in un sistema di assistenza che descriva per caso qualcuno.
- Membri ovvi: un nome, un numero di identificazione, una data di nascita, un indirizzo di casa, un numero di telefono e un indirizzo email
- Meno ovvi: una fotografia, un identificatore di dispositivo, una traccia di posizione, un soprannome di account
- Altrettanto personali: qualunque nota in un sistema di assistenza che descriva per caso qualcuno
Il concetto è definito con riferimento alla persona anziché al campo. Un dato è personale quando si riferisce a un individuo identificabile, direttamente o indirettamente, il che significa che un campo non deve contenere un nome per essere personale. Un record con una data di nascita, un codice postale e un titolo professionale può essere personale se quei tre insieme individuano una sola persona nella popolazione coperta dai dati.
È quella definizione che rende l’ambiente di test una questione viva anziché una formalità. Se il database di staging contiene qualcuna di queste informazioni, lo staging sta trattando dati personali, e ogni argomento su conservazione, accesso e sicurezza ora si applica a un sistema che è stato progettato senza di essi.
Perché i sistemi di test non dovrebbero detenere dati di produzione?
Perché i controlli che proteggono la produzione sono esattamente i controlli che gli ambienti inferiori non hanno. La produzione di solito ha accesso limitato, archiviazione cifrata, registrazione di audit e un processo di modifica. Lo staging di solito non ha nessuno dei quattro, perché esiste per essere comodo. Copiare un dataset al suo interno è quindi un abbassamento della protezione applicato ai record più sensibili che l’organizzazione detiene.
Ne derivano tre conseguenze, e ciascuna è costosa a modo suo. L’accesso si moltiplica: ogni collaboratore esterno, ogni account di test automatizzato e ogni portatile che ripristina un dump ora detiene dati personali. La conservazione diventa accidentale: la copia viene aggiornata, dimenticata, sottoposta a backup e lasciata in un bucket che non appartiene a nessuno. E l’ambito degli incidenti cresce: quando da qualche parte avviene una fuga ordinaria, la domanda non è più quali sistemi siano stati esposti ma quante copie esistano.
L’angolo normativo è più stretto di quello ingegneristico ma punta nella stessa direzione. I dati personali devono essere raccolti per finalità specifiche e non usati per finalità incompatibili, quindi riutilizzare in silenzio i record di produzione per testare una migrazione è una nuova finalità a cui nessuno ha acconsentito. Nulla di tutto questo è esclusivo di un singolo quadro giuridico; lo stesso ragionamento compare nella maggior parte dei regimi sulla privacy, ed è per questo che il consiglio pratico converge.
Qual è la differenza tra anonimizzazione e pseudonimizzazione?
Questi due vengono costantemente trattati come sinonimi e non lo sono. I dati pseudonimizzati hanno visto gli identificatori diretti scambiati con un codice, con la mappatura conservata da qualche parte. Il record non può essere attribuito senza quell’informazione aggiuntiva, ma il collegamento esiste ancora e può essere seguito se la mappatura viene divulgata. I dati anonimizzati sono stati trattati in modo che l’individuo non possa più essere identificato da nessuno, compresa l’organizzazione che li detiene, e la trasformazione non può essere invertita.
La distinzione decide se i dati siano ancora dati personali. I record pseudonimizzati restano personali per la maggior parte degli scopi, perché esiste una chiave. I record anonimizzati, fatti propriamente, no — ma dimostrare una corretta anonimizzazione è davvero difficile, ed è la difficoltà che rende l’uso dei dati di produzione per i test uno scambio così svantaggioso.
C’è una seconda trappola oltre agli identificatori diretti. Rimuovere i nomi da una tabella non la rende anonima, perché le combinazioni dei campi rimanenti identificano le persone. Un titolo professionale raro in una piccola città è spesso sufficiente da solo. In un esame giuridico, la domanda giusta non è se sia presente un nome, ma se qualcuno possa ragionevolmente identificare l’individuo da ciò che rimane, usando informazioni che possiede o potrebbe ottenere.
Il mascheramento e la cancellazione risolvono il problema?
Il mascheramento sostituisce i caratteri sensibili con un motivo fisso, ed è eccellente per la visualizzazione: un operatore dell’assistenza vede le ultime quattro cifre di un numero mentre il resto è nascosto. Non è anonimizzazione, perché il valore originale di solito è ancora memorizzato, e uno strato di mascheramento davanti a un record reale non fa nulla al record reale.
La cancellazione di singoli campi ha la stessa debolezza in un costume diverso. Togli il nome e il record ha ancora un indirizzo, una data di nascita e un numero di telefono. Sostituisci anche l’indirizzo e i campi rimanenti possono comunque individuare una sola persona nella popolazione. Ogni rimozione restringe il rischio senza chiuderlo, e raramente esiste un punto chiaro in cui si possa dimostrare che il rischio ha raggiunto lo zero.
C’è anche un problema di documentazione. In pratica, i team non riescono a dimostrare quali record siano stati anonimizzati correttamente e quali siano soltanto camuffati, perché la trasformazione è avvenuta in modo estemporaneo e non ha lasciato traccia. Un dataset la cui provenienza nessuno sa ricostruire non può essere difeso in seguito.
Cosa dovrebbe sostituire le copie di produzione?
Record che non sono mai appartenuti a nessuno. Questo è l’argomento a favore del generare i dati anziché raccoglierli, ed è per questo che i record sintetici risolvono in una volta sia la questione della privacy sia quella della qualità. Non c’è nulla da proteggere, nulla da conservare, nulla da divulgare e nessuna limitazione delle finalità su cui discutere, perché i dati non sono mai appartenuti a una persona fin dall’inizio.
I record generati si comportano anche meglio nei test. I valori prodotti dal generatore di identità e dati di test sono internamente coerenti — indirizzo, codice postale e prefisso telefonico appartengono allo stesso paese, e i formati degli identificatori seguono le convenzioni di quel paese — il che significa che un dataset di test non ha bisogno di riparazioni a mano. Sono record sintetici solo per i test software, e non sono utilizzabili per impersonare una persona reale né per soddisfare alcun controllo reale di identità, età o idoneità.
L’avvertenza onesta è che i dati sintetici non riproducono automaticamente ogni correlazione del mondo reale. Se un test dipende davvero dalla forma statistica dei dati reali, quella forma deve essere modellata di proposito, e il confronto tra approcci sintetici espone cosa comporta la modellazione e dove questa non basta.
Come si tengono i dati personali fuori da log e screenshot?
La fuga raramente è il database. È il log delle query che ha catturato un record completo, il report di errore che ha incorporato il corpo della richiesta, lo screenshot allegato a un ticket di bug, il foglio di calcolo esportato per l’analisi e lasciato in un’unità condivisa, e il dump locale che qualcuno ha fatto per riprodurre un difetto in aereo.
Tre controlli ne riducono la maggior parte. Primo, tieni i record reali fuori dagli ambienti in cui i log sono dettagliati, il che è un argomento diretto a favore dell’uso di dati sintetici nello staging. Secondo, tratta uno screenshot o un’esportazione come contenente qualunque cosa contenesse lo schermo, e pretendi che le prove di test provengano da ambienti che non detengono record reali. Terzo, rendi esplicita la conservazione: una copia che esiste per uno scopo dovrebbe avere una data di fine, e una copia senza data di fine non è una copia, è un secondo database di produzione.
Anche la revisione degli accessi appartiene a questo punto. Sapere chi può raggiungere il dataset è utile solo se la risposta è stata verificata di recente, e il momento in cui una copia è ampiamente condivisa è quello in cui quella revisione smette di avere senso.
Per gli sviluppatori: isolamento, provenienza e prova
Separa gli ambienti anziché filtrare un flusso di dati dentro l’altro. Un ambiente di sviluppo dovrebbe essere popolato da un passo di generazione, mai da un ripristino dalla produzione, e la connessione dallo sviluppo alla produzione non dovrebbe esistere affatto — non semplicemente essere inutilizzata.
Etichetta la provenienza dei dati nel dataset stesso. Un marcatore che dice che queste righe sono sintetiche e solo per i test sopravvive all’esportazione, allo screenshot e al ticket di assistenza, e dice a un lettore futuro tutto ciò che deve sapere su ciò che sta guardando. È la salvaguardia più economica disponibile e quella più spesso saltata.
Infine, prepara la risposta alla domanda che un revisore porrà: come sai che questo dataset non contiene record reali? Un passo di generazione che parte da un seed e non legge mai una fonte di produzione è una risposta dimostrabile. Una pipeline che ha trasformato un’esportazione di produzione non lo è, per quanto accurata appaia la trasformazione in fase di revisione. L’assenza verificabile batte sempre il camuffamento dimostrabile.
Passi successivi
Scopri se il tuo database di staging è stato ripristinato da un dump di produzione e, se lo è stato, sostieni la causa della sua sostituzione con righe generate prima della prossima revisione trimestrale degli accessi. Poi esamina una segnalazione di bug del mese scorso e conta in quanti posti sono passati i dettagli di una persona reale al suo interno — log, allegati, screenshot — perché quel conteggio è ciò contro cui l’alternativa compete. Quando passi all’azione, genera il primo lotto nel generatore di identità ed etichetta ogni riga come sintetica prima che venga importata.