Ukratko: osobni podaci izvan chaina uz nasumični salt po zapisu; na chain ide samo commitment. Obrišete li podatak i salt, commitment ne pokazuje ni na što.
Decision ledger je koristan jer se njegovi zapisi ne mogu naknadno mijenjati. Isto svojstvo postaje problem prvi put kad zapis sadrži osobne podatke, a netko traži njihovo brisanje. Odgovor se određuje pri projektiranju, prije prvog anchora, a ne nekim trikom na chainu.
Podijelite zapis na dva dijela
Sadržaj ostaje u običnom storeu pod vašom kontrolom: tablica u bazi, object store, što god koristi ostatak sustava. Tamo žive osobni podaci i tamo se mogu ispraviti ili obrisati kao svi drugi podaci. Chain prima samo commitment na taj sadržaj: hash jednog zapisa ili root Merkle stabla nad više zapisa koji se anchoraju zajedno. Zapis u ledgeru kaže što se dogodilo i upućuje na record preko identifikatora, a proof povezuje to dvoje bez objavljivanja sadržaja.
Običan hash nije dovoljan
Hashiranje imena, email adrese ili OIB-a djeluje sigurno, a često nije. Prostor mogućih ulaza je malen: tko može pogoditi kandidate, može izračunati njihove hasheve i usporediti. Dodajte nasumični salt svakom recordu, generiran po zapisu, i čuvajte ga uz podatak u vanjskom storeu, nikada na chainu. Commitment postaje hash od salta i sadržaja. Bez salta se vrijednost na chainu ne može reproducirati iz pretpostavke.
Što onda znači brisanje
Kad se zahtjev za brisanje prihvati, iz vanjskog storea brišu se sadržaj i njegov salt. Commitment na chainu ostaje, ali ne ostaje ništa što bi se moglo ponovno izračunati da mu odgovara. To je broj koji ne pokazuje ni na što. Ledger i dalje pokazuje da je zapis postojao na određenoj visini, u određenom slijedu, i da slijed oko njega nije mijenjan. Revizor tako i dalje može provjeriti da povijest nije prepravljena, ali ne može iz chaina saznati što je u tom zapisu pisalo. Za većinu poslovnih slučajeva to je upravo željena granica: integritet ostaje javno provjerljiv, a osobni podaci ostaju tamo gdje se njima može upravljati.
Što gubite i što tek treba odlučiti
Dvije posljedice treba zapisati u projekt. Prva: kad sadržaj nestane, nestaje i mogućnost da se dokaže što je pisalo. Brisanje i dokaz vuku u suprotnim smjerovima, a za neke zapise obveze čuvanja će reći što prevladava. Druga: smatra li se hash i dalje osobnim podatkom pravno je pitanje koje ovisi o slučaju, o ulazu i o tome što se još može povezati s njim. Tu procjenu daje službenik za zaštitu podataka (DPO), a ne arhitekt.
Praktično pravilo je kratko. Prije prvog anchora odlučite koja polja bi se ikada mogla morati brisati, držite ih izvan chaina i zapišite proceduru brisanja uz dizajn ledgera. Poslije je to migracija.
Koja polja u vašem ledgeru bi vam bilo žao što ste anchorali?
Cijeli tekst: cijeli obrazac brisanja
Articolo originale: https://www.omarbaruzzo.it/hr/blog/cancellare-un-dato-ancorato
