Event-sourcing a GDPR

[hknmtt]

Ako riesite GDPR v pripade ES? Cital som mnoho nazorov a rieseni no nic z toho do konceptu ES nezapada.

Primarne ide o to, ze mozem napriklad uschovat PI data v dedikovanej tabulke kde kazdy udaj bude mat unikatne ID a v eventoch pouzit to ID ako kvazi pointer a potom po zmazani sa vlastne pri hydracii/replay nacitaju prazdne alebo "dummy" hodnoty. Lenze problem je napriklad ze ak by som nahradil email niecim ako "[id]-deleted@localhost", aby to preslo validaciou, tak budem mat duplicity a logika to nemusi pobrat(ie. duplikatne primarne/unikatne kluce v db pri rebuilde systemu - co je naprosto bezne, hlavne pri vecsich aktualizaciach).

Zahodit kryptovaci kluc je tiez riesenie ale zase potom mi vznika rovnaky problem len s tym, ze nebudem moct hydratovat agregat uz vobec, takze rebuild systemu alebo nieco podobne skratka ani nebude mozny v prvom rade a reaktory a akakolvek dalsia logika budu kompletne zabite.

Co sa prveho riesenia tyka, tak som aj cital pripady ze eventy boli tak "vykuchane", ze to boli len prazdne schranky bez akychkolvek pouzitelnych dat, co je proste na dve veci...

Dalsia vec je samotne PI - cize kedy je to PI a kedy nie. To uz je skor GDPR otazka mimo ES ale proste ak ma niekto email "danove@firma.com" tak to nie je PI ale ak ma "peter.sveter@firma.com" tak uz ano. Tak isto ak ma niekto "danove@firma.com" ktore nie je PI ale potom ma vedla toho ulozene este "Peter Sveter", tak dokopy uz o PI ide. Takze ako mam vediet ktore data su vobec PI a ktore nie? Ved to nie je mozne automatizovat.

Takze otazka je primarne ako pristupujete ku GDPR v kontexte event-sourcovania?

Robim na projekte kde prebiehaju financne transakcie, takze pravdepodobne "zabudnut" ludi nikdy nebudem musiet a teda cele GDPR ani riesit, a kryplit tak ES, ale zaujima ma tato problematika celkovo.

[Reklama]

[a6b]

podle me muzes mit osobni data v db ulozene, ale pripojeni appky k db musi byt sifrovane. pokud bys chtel data posilat mimo eu, tak jen se souhlasem osoby. musis hlidat, aby data neunikly a pokud se neco stane tak je tam lhuta na opravu.

[hknmtt]

podle me muzes mit osobni data v db ulozene, ale pripojeni appky k db musi byt sifrovane. pokud bys chtel data posilat mimo eu, tak jen se souhlasem osoby. musis hlidat, aby data neunikly a pokud se neco stane tak je tam lhuta na opravu.

Neriesim ulozenie dat, ale zmazanie dat. Cize v priapde ze uzivatel uzatvori ucet alebo posle ziadost o zabudnutie.

[a6b]

tak i vsechny event logy musis mit ulozene tak, aby to bylo bezpecne, takze pro by neslo mit kazdou polozku v zasifrovane (symetricky) podobe. pri zapomenuti zahodis klic ke vsem eventum pro danou osobu. z databaze to vymazes, tak aby vse co je spojeno s jednou osobou zmizelo a nezbyly zadne zavislosti.

zapomenuti osoby musi vypadat, jako by zadne eventy spojene s osobou nikdy neexistovaly.

[Filip Jirsák]

Když chcete nějaký údaj vymazat, je nesmysl vymýšlet tam nějakou pseudohodnotu jako [id]-deleted@localhost. Každá databáze umí reprezentovat stav "hodnota je neznámá/neexistuje" - např. v SQL je to NULL. Tím se vyřeší všechny problémy s validacemi, duplicitami apod., protože neexistující hodnota se ani nevaliduje ani nemůže být s ničím (ani jinou neexistující hodnotou) duplicitní.

Druhá možnost je místo modifikace zprávy o nastavený e-mailu tu zprávu úplně smazat, ale to záleží na datovém modelu, zda je to možné.

[Reklama]