In breve: dati personali fuori catena con un salt casuale per record; sulla catena solo l'impegno. Cancellati dato e salt, l'impegno non punta a niente.
Un registro delle decisioni è utile perché le sue voci non si possono cambiare a posteriori. La stessa proprietà diventa un problema la prima volta che una voce contiene dati personali e qualcuno chiede di cancellarli. La risposta si decide in fase di progetto, prima del primo ancoraggio, e non è un trucco da fare sulla catena.
Dividere il record in due
Il contenuto resta in un archivio ordinario sotto il vostro controllo: una tabella di database, un object store, quello che usa il resto del sistema. È lì che vivono i dati personali, e lì si possono correggere o cancellare come qualsiasi altro dato. La catena riceve solo un impegno verso quel contenuto: l'hash di una voce, o la radice di un albero di Merkle su molte voci ancorate insieme. La voce del registro dice cosa è successo e rimanda al record tramite identificativo, e la prova collega le due cose senza pubblicare il contenuto.
L'hash semplice non basta
Calcolare l'hash di un nome, di un indirizzo email o di un codice fiscale sembra sicuro, e spesso non lo è. Lo spazio degli input è piccolo: chi può indovinare dei candidati può calcolarne gli hash e confrontarli. Aggiungete un salt casuale a ogni record, generato per voce, e conservatelo accanto al dato nell'archivio esterno, mai sulla catena. L'impegno diventa l'hash di salt più contenuto. Senza il salt, il valore sulla catena non si riproduce partendo da un'ipotesi.
Cosa significa cancellare, allora
Quando una richiesta di cancellazione viene accolta, si eliminano dall'archivio esterno il contenuto e il suo salt. L'impegno sulla catena resta, ma non rimane più nulla che si possa ricalcolare per farlo coincidere. È un numero che non punta a niente. Il registro mostra ancora che una voce esisteva a una certa altezza, in una certa sequenza, e che la sequenza non è stata alterata attorno ad essa.
Cosa si perde, e cosa resta da decidere
Due conseguenze vanno scritte nel progetto. La prima: una volta sparito il contenuto, sparisce anche la possibilità di provare cosa diceva. Cancellazione e prova tirano in direzioni opposte, e per alcuni record saranno gli obblighi di conservazione a dire quale prevale. La seconda: se un hash conta ancora come dato personale è una questione giuridica che dipende dal caso, dall'input e da cos'altro vi si può collegare. Quel giudizio spetta al responsabile della protezione dei dati, non a chi disegna l'architettura.
La regola pratica è breve. Decidete prima del primo ancoraggio quali campi potrebbero dover essere cancellati, teneteli fuori dalla catena e scrivete la procedura di cancellazione insieme al progetto del registro. Dopo, è una migrazione.
Quali campi del vostro registro vi pentireste di aver ancorato?
Testo completo: lo schema di cancellazione per esteso
Articolo originale: https://www.omarbaruzzo.it/it/blog/cancellare-un-dato-ancorato
