GDPR compliant adattörlés adatbázisból

Sokakat érint, és sokan gondban is vannak vele, hogy korrekt, auditorok előtt is vállalható módon meg tudják oldani a GDPR-ral összefüggésben befutó adattörlési kérelmek kezelését...

Ezt a problémát (reményeim szerint) megoldja egy múlt hétvégén összerakott szkript, aminek fő komponense a forget-db nevű open source projekt. A szkriptet sajnos nem publikálhatom (munkahelyi projektről lévén szó), viszont a forget-db kódja elérhető GitHub-on, aki esetleg nem hallott még róla, annak mindenképp ajánlanám a figyelmébe:

https://github.com/OwenMelbz/forget-db

Bár a kód alapvetően ebben a repóban is használható állapotban van (a "fancy" Unicode karakterekkel díszített kimeneteket leszámítva, amitől néhány szöveszerkesztő és terminal emulator "megbolondul"), azért volt néhány hiányossága, amit szerettem volna pótolni az éles használat előtt. Ebből született meg az alábbi fork:

https://github.com/kissg1988/forget-db

Ami miatt érdemes lehet használni:

  • Laravel Zero-ra épül (ami egy Laravel framework-re épülő, kifejezetten konzolos alkalmazások készítéséhez írt micro-framework), és szeretjük a Laravelt, mert jól átgondolt és elegáns :)
  • MySQL, PostgreSQL, MSSQL és SQLite támogatás (Oracle egyelőre nem támogatott, de szerintem könnyen megoldható)
  • Alapvetően elég egyszerű és logikus a folyamat: készítünk egy YAML-formátumú konfigot, ami felsorolja azokat a táblákat és mezőket, amelyek személyes adatot tartalmaznak, és kiválasztjuk, hogy milyen típusú (random) adattal íródjanak felül ezek.
  • A felülírandó adatokat kiválasztó lekérdezés szűrhető, ezzel pl. megoldható, hogy csak egy adott felhasználó adatai legyenek felülírva ("right to forget" elv szerint)
  • A kód lekezeli a táblák közötti kapcsolatokat is, lehet join-olni táblákat a konfigban
  • A 0.2.0 verzió óta lehet komplex, paraméterezett Faker formatter-eket is használni (pl. regexify), ami hasznos tud lenni, ha fix hosszúságú random adattal kell felülírni a mezők tartalmát
  • A konfigban a "unique:" előtaggal jelezhetjük, hogy a felülírt tartalomnak egyedinek kell lennie, ez leginkább akkor lehet hasznos, ha egy mezőre unique constraint van beállítva
  • Nagy, több ezer rekordot tartalmazó táblákkal is simán megbirkózik. Egy konkrét példa: egy éles DB teljes wipe-olásakor összesen 45 ezer rekordot írt felül a kód "unique:regexify('[A-Za-z0-9]{255}')" formatter használatával kb. 7 perc alatt. Ha nem elvárás a teljesen randomizált adatok használata, véletlenszerűen generált, szintaktikailag helyes fake adatok (pl. "name", "email", "address" formatter-ek) használatával meggyorsítható a folyamat. Ez mondjuk egy live DB -> teszt DB adatáttöltésnél igen hasznos tud lenni.

Az alkalmazás köré épített szkript kiegészíti a forget-db funkcionalitását néhány további hasznos funkcióval:

  • Több pass-ban futtatja a felülírást (hogy "kipörögjön" a felülírandó adat a tranzakciós logból)
  • Logol minden kimenetet timestamp-pel ellátott fájlba
  • Készít egy SHA256 checksum-ot a log fájlról a folyamat végén, ami a logfájl véletlen módosulása (sérülése) esetén hasznos lehet
  • Opcionálisan a wipe-olt adatbázisról készült mentéseket shred-del megsemmisíti a backup szerveren (kifejezetten a saját backup megoldásunkhoz hozzáigazítva)

Sajnos (még?) elég nagy a zűrzavar a témában, mivel nem egyértelmű, hogy mit vár el a törvény "secure erase" címszó alatt. Az viszont mindenképp jó pont, ha egy esetleges adatvédelmi audit (vagy egy incidens kivizsgálása) során meg tudja mutatni a cég IT üzemeltetésért felelős vezetője, hogy van megoldás az adattörlési kérések teljesítésére, illetve egy konkrét ügy kapcsán, ha a törlésről szóló logokat be tudja mutatni, akkor jogi értelemben (compliance) máris lesz eszköz a cég kezében annak alátámasztására, hogy "megtettünk mindent, ami tőlünk elvárható". A brutális bírságok elkerülésére ez mindenképp jó megoldás lehet, még ha technikailag nem is feltétlenül 100%-os ez a konkrét implementáció, pl. InnoDB adatfájlból nem biztos, hogy tényleg törlődik az adat bináris reprezentációja, illetve nem kizárt, hogy a DB adatfájljait tároló fájlrendszerből még valami módon (pl. heurisztikus kereséssel) visszanyerhető a törölt adat.

De ne legyünk telhetetlenek, már a fentebb részletezett process is egy nagy lépés a jog és a technológia harmonizációja felé és így talán elkerülhető az ecetes olló használata a szalagos mentések wipe-olása céljából... :)

Hozzászólások

nem trollkodni akarok becsszo, de a "tobb ezer rekord" az ne legyen mar "nagy" tabla... majd ha atlepte az 1 milliard sort, akkor mar nevezhetjuk picit nagyra nottnek:)

Az általános témához hozzászólva (bár tudom, hogy mindenki GDPR szakértő is), két dolgot érdemes megjegyezni.
1) A rendelet a törlés kapcsán (is) az ésszerűen elvárható erőfeszítésekről beszél.
2) A technológiai (és szervezési) intézkedéseknek az érintettek kockázatával kell hogy arányos legyen.

Ennek a kettőnek a metszetéből következik, hogy nincs olyan, hogy GDPR kompatiblis szoftver, hanem azt kell mérlegelni, hogy milyen kockázatot jelent a jóembernek, ha a törölt adat mégis visszanyerhető. Mondjuk egy webshopban vesz valaki egy tévét. A kapcsolódó adatkezelés az érintett számára csekély kockázatot jelent, hisz milyen következémnyei lehetnek egy adatszivárgásnak? Minden azon kívül, hogy jó esetben lefut egy DELETE tökéletes overkill GDPR szempontból.

Ezzel nem akarom csökkenteni a hasznosságát a dolognak amit kidolgoztatok, lehet hogy nálatok indokolt is az ilyen mértékű utánnajárás, de az említett dolgok megfontolását azért ajánlom a kedves olvasóknak, mielött elkezdenek vadul implementálni valamit, amire nincs szükségük.

GDPR kompatiblis != GDPR compliant

Tudom, hogy általánosságban írtad a kommentet, de ezt azért nem árt leszögezni, mivel ez a kis fejlesztés az utóbbi célból készült. A compliancy lényege ugye a jogszabályi megfelelőség. Az, hogy egy adott cég milyen konkrét lépéseket tesz azért, hogy az adattörlési kéréseket teljesíteni tudja, egyéni mérlegelés kérdése, van aki beéri egy DELETE-tel, van aki a full wipe-ig elmegy (ami mondjuk egy konténeres, jól elszeparált környezetben még akár működhet is, hagyományos osztott hostingnál viszont esélytelen).

Biztos sokszor ki lett már tárgyalva százszor, de szerintem a GDPR eső után köpönyeg a jelenlegi formájában, és úgy nagyjából 10-15 éves késéssel léptették hatályba. A FB-korszak kezdete előtt még lett volna értelme bevezetni, de ma már nincs. A civilizált emberiség túlnyomó többségének csaknem összes személyes adata megvan a Facebook, a Google és más IT-óriások rendszereiben, ahonnan (amiken keresztül) sok más helyre eljutottak vagy eljuthatnak a jövőben ezek az adatok, teljesen kontrollálhatatlan módon... és ez csak rosszabb lesz, ahogy telik az idő és már a munkaügyi, egészségügyi, közigazgatási adatainkat is kötelező lesz a felhőben tárolni (én tavaly még picit ágáltam az összes HR-jellegű adatom felhőbe migrálása ellen, de ma már igazából nem érdekel, belenyugodtam, hogy a trendekkel egymagam úgyse tudok szembe menni).

Sajnos úgy tűnik, az egyetlen gyakorlati haszna a GDPR-nak, hogy piaci rést teremtett egy csomó szakmának (tanácsadók, jogászok, szoftverfejlesztők stb), akik szépen kaszálhatnak a "GDPR kompatibilis/compliant" termékeikkel/szolgáltatásaikkal... :(

Ettől függetlenül a GDPR egy hatályba lépett EU-s jogszabály, így sajnos minden EU-ban tevékenykedő cégnek alkalmazkodnia kell hozzá - erre ad egy lehetséges megoldást a fentebb részletezett process. Szerintem ezzel már bőven biztosított a megfelelőség, az ecetes ollós példát csak ironizálásból írtam, nyilván senki nem várja el, hogy egy adattörlési kérésnél égesd fel az összes szalagos archívodat, és hozd létre újra úgy, hogy Tóth Pista adatai ne legyenek benne, mivel ez egyértelműen irreális elvárás lenne.

Alapvetően azt gondolom, hogy a megoldásotok nagyon jó, pusztán arra ragadtam meg az alkalmat, hogy egy kicsit hangoztassam az arányossági elveket, mert ennek a hiányával találkozom lépten nyomon. A KKVéknak elég sok helyen próbáltunk segíteni, kamarán keresztül, előadásokon, fórumokon, anyagok közzétételével. Lépten nyomon hívtak kisvállalkozók kétségbe esve, hogy most akkor mi legyen... nekem is elég sok fejtörést és utánnajárást okoznak ezek a kérdések.

Példa: fodrász stúdió, ahol a kliensek elérhetőségén kívül azt is nyilvántartják, hogy ki milyen festékre alergiás. Horribile dictu ez egyenesen egészségügyi adat. Már az nagy eredmény, hogy a gépükről egyszer egy hónapban véletlenül van mentés, nemhogy azon matekozzanak, hogy hogyan töröljenek abból vagy a visszaállításból. Nincs az az élet, hogy kitudjanak fizetni egy fejlesztést vagy más szakértést...

Hogy a GDPR jöhetett volna korábban, nem kérdéses. Hogy mostanra érdektelen lenne, nem gondolom, elég csak kitekinteni a kínai adatkezelési példákra és más durvaságokra. Érintőlegsen ráláttam big data jellegű adatsáfárkodásokra, szerintem a helyzet még bőven lehet rosszabb. Nem biztos, hogy a GDPR lesz rá a végső megoldás, de kiindulásnak megteszi és legalább van valami.

Jó érveket írsz, nálam sajnos némileg eltorzítja a dolgokat, hogy egy multicégnél dolgozom, ahol sok pénzt és energiát ölt bele a cégvezetés globális szinten, hogy meg tudjunk felelni a GDPR előírásainak a bevezetés napjára (és itt elsősorban a tanácsadó cégek megbízására, oktatások szervezésére és a belső folyamatok gyökeres átalakítására gondolok). Ebben a folyamatban én is részt vettem, viszont mivel a hatályba lépés környékén még elég sok nyitott kérdés volt, így akkor még nem foglalkoztunk mélyebben az adattörlési kérések kezelésével. Most viszont volt egy kis időm és gyakorlatilag szorgalmi feladatként készítettem egy egyszerű, világos elvek mentén működő megoldást a nem is létező problémára. :)

Egyetértek veled, kiindulási alapnak jó a GDPR, de szerintem nem érdemes túl sokat remélni tőle. Volt egy adattörlési kérésem pár hónapja, az egyik ételrendelős oldal valamit csúnyán elbarkácsolt az új weboldalának élesítésekor és a saját loginemmel belépve egy másik személy adatait láttam, név, cím, telefonszám... azonnal jeleztem a problémát nekik, és kértem, hogy töröljék az adataimat, mert egy olyan szolgáltatást, ahol ilyen hiba amatőr hiba előfordulhat, nagy ívben szeretném elkerülni (csak tipp: szerintem az új weboldal mögötti adatbázisban nem volt unique constraint beállítva a felhasználónévre, így újra be tudott regelni valaki az általam évek óta használt usernévvel). Ki tudja, lehet hogy egy másik user meg az én személyes adataimhoz jutott hozzá, és az is lehet, hogy a hiba a felhasználók többségét érintette (esetleg mindenkit?), ezt sosem fogjuk megtudni...

Nyilván elkenték a dolgot a szokásos blablával, hogy "egyszeri hiba történt, amit rövid időn belül javítottunk", ami vagy igaz, vagy nem. Miután megerősítették, hogy törölték az adataimat, elengedtem a témát.

Látom, hogy eléggé képben vagy a GDPR kapcsán, ha érdekel, (anonimizáltan) szívesen elküldöm neked privátban az ide kapcsolódó levelezést. Lehet vele demózni, hogy a cégek (pláne a magyar cégek) hogyan is kezelik az adatvédelmi incidenseket...

Oh, hát igen, egy multi életét teljesen máshogy érinti ez a kérdés. Nagy kockázat, nagy pánik, nagy költekezés és végül nagy fejetlenség :) és sok esetben béna GDPR megfelelés. Küzdöttem én is végig, időnként farkasszemet nézve a cég jogászával, hogy akkor most kinek is van igaza.

A levelezést ha el tudod küldeni, azt megköszönöm, megpróbálom HUPon átküldeni az e-mail címemet.

"farkasszemet nézve a cég jogászával, hogy akkor most kinek is van igaza" - nekem volt szerencsém több jogásszal egyszerre beszélgetni a témáról, jó volt látni meg hallani, amikor számukra totálisan ismeretlen szakterületről egymással is vitába szálltak (és gyakorlatilag nem tudtak megegyezni...), hogy hogyan kéne csinálni, hogy megfeleljen a GDPR-nek...

És mit lesz a napi/heti/havi/éves komplett adat/rendszermentésekkel?

Ezen a jogászok is vitatkoznak :-P Egyébként a törlés helyett az elrejtés is lehet egyfajta megoldás ezekben az esetekben - az persze jó kérdés, hogy az archív adatokat kezelő, már nem fejlesztett, nem támogatott szoftvernek az átalakítását hogyan képzelik el a GDPR-t kiagyaló jogtudorok, mert 9x% az esélye annak, hogy lövésük sincs hozzá, hiszen az ő papír alapú világukban elég egy vastag fekete filctoll vagy épp egy iratmegsemmisítő...

Jellemzően semmi nem lesz velük. Annyit lehet esetleg biztosítani, hogy visszaállítás esetén az időközben törölt adatokat újra töröljük (azaz van róla valami logunk hogy mit kellett törölni). De az ilyen intézkedések is csak akkor indokoltak, ha az érintett kockázata a nem törlés miatt számottevő (lásd korábbi hozzászólásom).

Azt írod, hogy "...van róla valami logunk hogy mit kellett törölni..." akkor meg a logban marad róla "személyes" adat.

Mindenesetre jó játék lehet, egy pl. több példányban, több földrajzi helyen tárolt inkrementális adatmentési sorozatokból visszaállítani valamire, kivadászni belőle a törlendőket, aztán újra visszaarchiválni, kipróbálni a visszaállíthatóságot, majd az előzőt kompletten megsemmisíteni. Akkor már nem lehet elmondani róla, hogy az egy valamikori állapot. Ezzel nincs baj? Valamilyen módon hitelesített...titkosított...időbélyegzős stb. állományok is lehetnek akár még adatbázis dumpokban is. Ezek másokkal vagy más ügyekkel is összefüggében lehetnek. Esetleg ezeket is vizsgálni kellene megsemmisítést megelőzően, hogy pontosan mit lehet eltüntetni véglegesen? Ha le van írva hogy kinek mijét, akkor meg az tartalmaz az illetőről adatokat, a kéréseit stb. Lesz olyan, aki írásban kiadja a pontos teendőket utasításban? Na már belebonyolódtam...talán nem vagyok egyedül...egy hét, mire kipihenem.

> akkor meg a logban marad róla "személyes" adat

Ezeket a primary key-eket kell torolni DB restore-kor:

9a44d719-2874-4ba1-adab-7fd2cd1e737d
0003a019-58a5-4e97-9718-8c165bda79b3
077a5fcb-be9c-431b-91b3-f015edbfbc58
94e7ac7e-dc38-4685-b73d-5273f76f2e93
cd7df889-e757-4ffd-82fb-ff793300e49e

Ebbol melyiket hivjak Jozsinak?

+1, vagy épp az adott DB-re jellemző, abban tárolt, egyedi azonosítsra alkalmas adatokból képzett hash-t is citálhatnám: Jóskapistabélanéni jön, hogy töröljék ki, a DB-ben meglévő azonosító adataiből csinálni kell egy hash-t, elrakni egy "ezeketkelltörölni" adatbázisba, és utána törlés. Ha restore van, akkor meg a visszaállítás után végigmenni a visszaállított adatokon, megnézni, hogy adott rekord hash-e benne van-e az ezeketkelltörölni-ben, és ha igen, akkor törlés.

Ha a technológiai megoldás miatt nincsenek pseodonym jellegű azonosítók, az is elférhet, hogy logban marad róla személyes adat. Nyilván a logban már jóval kevesebb és kevésbé érzékeny információ van.

Az inkrementális felvetésed lényegét nem értem, én is belebonyolódtam :)

Érdekességként egyébként megjegyzem, hogy az adatvédelmi hatóságtól az egyik cégnél írásos véleményt kértek arról, hogy ha a technikai sajátosság miatt nem tudják a mentésből soha törölni az adatokat, de olyan titkosított módon vannak eltéve, amihez három embernek van csillió-bit kulcsos hozzáférése, az elfogadható-e. És a hatóság simán rábólintott.

A GDPR szövegezése nem ostoba, de alaposan oda kell figyelni az olyan kifejezéseknél, hogy "kockázatokkal arányos" meg "elvárható lépések". Az átlag jogászok nem értik a technikai kivetülését az átlag szakik pedig nem értik a jogi elvárásokat és hogy mi a mozgásterük. Mindenkét fél fekete-fehér specifikációt próbál készíteni és azzal védeni magát... és ebből sok a félreértés.

Igen, hát én is kérdeztem a jogsegélyüket az archív állományokkal kapcsolatban, nem tudtak választ adni.
Ezt elmondták, hogy ha valaki törlést kért, arról jó jegyzőkönyvet felvenni. Kérdeztem, hogy akkor meg azt tárolom, hogy ki kért törlést. Így patt helyzet alakult ki.

A fentebbi bejegyzés így adatbázis sorokra utaló napló részlete.
Ezeket a primary key-eknek mi lesz a sorsuk? Ki fogja ezeket figyelembe venni a későbbiekben?
De továbbra is ott vannak az archív állományokban a jogtalanul tárolt/kezelt adat.

Azzal nem lehet védekezni, hogy ha visszaállítom majd én vagy valaki más, bár mikor, akkor az tutira nem felejti el a napló szerint végrehajtani a törléseket, mielőtt illetéktelen megláthatná vagy kikerülne. Én úgy gondolom, hogy az adat tárolva van. És itt a pont a mondat végén. Hogy tőle elvárható, meg jóhiszemű, meg mindent megtett,...az már értelmezési csűr-csavar. Az IT-seknek vagy más módon érintetteknek talán a legmegnyugtatóbb az lenne, ha írnának egy tájékoztatót főnökeiknek a körülményekről, és minden egyes teendőnél pontos utasítást kapnának írásban és csak azt hajtanák végre, jegyzőkönyvezve. Na most már két hetet kell pihennem...hagyok nektek is karakter helyeket...

Hmmm ... pedig a csűrcsavarban van a lényeg, ezért van hatóság meg bíróság, hogy az adott esetre vonatkozóan eldöntsék, hogy miként kell alkalmazni a rendelkezést. És igenis vizsgálják, hogy mi volt az elvárható az adott esetben és elégséges volt-e amit megtett az adatkezelő. Ez a sava borsa az egész történetnek.

Nem győzöm eléggé hangsúlyozni, hogy az elvárások az érintettek kockázatával arányos. Néhány példa:

1) Van egy póló webshopom, volt aki kérte hogy töröljem, ezt megtettem, de tönkrement a szerver, backup-ból visszahoztam és fogalmam sincs kit kell törölni. Kockázat? Valakiről van elérhetőségi infóm (az hogy vett XY pólót az amúgy is rajta van a számlán, ami természetesen megvan). => várható hatósági vélemény: ejnye bejnye, legközelebb írja fel hogy kit törölt és törölje újra. Büntetés 0.

2) Van egy szexjáték webshopom, volt aki kérte hogy töröljem, ezt megtettem, de tönkrement a szerver, backup-ból visszahoztam és fogalmam sincs kit kell törölni. Kockázat? Valakinek a szexuális orientációjáról vannak érzékeny információim, kvázi profilom. => várható hatósági vélemény: mulasztást követett el azzal, hogy nem tartotta nyilván, hogy kit kell törölni egy esetleges visszaállítás után. Fizessen ZZZ bírságot és mutassa be a korrekciós intézkedéseket.

3) Van egy DNS adatbázisom, amit orvosi kutatási célokra használunk, volt aki kérte hogy töröljem, ezt megtettem, de tönkrement a szerver, backup-ból visszahoztam és fogalmam sincs kit kell törölni. Kockázat? Az egekben! => várható hatósági vélemény: már a backup-ot úgy kellett volna megvalósítani, hogy egyedi információkat lehessen törölni abból. Fizessen ZZZ^2 bírságot és mutassa be a korrekciós intézkedéseket.

Valami ilyesmi :)

Igen, ideális esetben az 1-es esetnél is tudod, de ha nem tartalmaz a gyakorlatod jelentős kockázatot, akkor hatóságilag is elnézhető. Van egy csomó olyan nagyon egyszerű és hétköznapi adatkezelési eset, ahol egész egyszerűen nem elvárható, hogy az ilyen alapvető logolások és visszaállítás utáni dolgokról gondoskodjon az adatkezelő (aka triviális adatkezelés).

A bírság lehet nulla befizetéssel járó megrovás, figyelemfelhívás, utasítás stb, a rendelet nem tartalmaz erre vonatkozó megszorítást (és ellentétes is lenne a rendelet szellemiségével).

Vannak mentések, illetve archív adatok. Ezekből jogászilag egyszerű törölni Jóskapistabélanéni adatait, de ha egy törlési ciklus (amíg egy törlési kérelemhalmaz "végigmegy", és az érintett adatok törlésre/anonimizálásra kerülnek) idején belül jön újabb igény, akkor azt a következő takarítási körben kell pucolni/anonim izélni - ergo soha nem lesz, nem lenne vége a régi adatokból történő takarításnak.
Emiatt van az, hogy a visszaállítást követően elég törölni, illetve elrejteni a jogszerűen nem tárolható adatokat. Ehhez persze az kell, hogy az adott adatbázisban tárolt szmeélyes adatokból egyértelműen el lehessen dönteni, hogy maradhat vagy sem. Az adatok normalizálása (encoding, kisbetű/nagybetű, szóköz, írásjel, stb.) után alkalmazott megfelelő hasítófüggvény példának okáért tud adni erre megoldást: Jóskapictabélanéni jön, hogy őt felejtsék mindenestől el, akkor a meglévő adatvagyon (archív adatbázisok, aktuális rendszerek, stb.) alapján egy vagy több hash-t kell csinálni Jóskapistabélanéni adataiból, eltárolni, hogy melyik hash melyik adatbázis/rendszer esetében hasnzálandó adatelrejtésre/törlésre/anonimizálásra jelölt rekordok kiválasztásához, és visszaállítás után ezek alapján lehet a megfelelő műveletet elvégezni Jóskapistabélanéni visszaállított adataival.
Van, aki vitatja jogi oldalról, hogy a hash jó erre a célra, merthogy egyértelmű a kapcsolat, csak azt felejti el, hogy addig személyes adat valami, amíg a kapcsolat visszaállítható. Márpedig kizárólag az adott hash birtokában nem mondható meg, hogy az mely természetes személy adataiból készült.

Normalizalni kene azokat a franya adatbazisokat adatduplikacio helyett, maris nem lenne gond...

Olcso, olcso, aztan meg jon a fejvakaras, meg a workaround hackek tomegei, ha szemelyes adatot kellene torolni...

Nem veletlen lettek ezek kitalalva ugy, ahogy. De nyilvan a legegyszerubb ugy hozzaallni, hogy "jo lesz ez igy, mire osszeomlik a kartyavar, addigra mar ugyse leszek itt", csak engem meg ettol a hozzaallastol raz ki a hideg.