GDPR a küszöbön

HUP cikkturkáló

http://m.hvg.hu/itthon/20170817_bubi_adatok

BKK T lazán kapcsolódik.

  • 6364 megtekintés

Az inkrementalis backup egy eszköz, amelyet ha felhasznalsz (visszaallitod) akkor nem lesz benne az ügyfél. Egy korábbi állapotában igen de az nem hagyományos felhasználas.

Sima db-bol torlódás, akkor sem kell a hdd-t gyalulni csak azért mert a Kürt vissza tudna hozni.

A jogászokkal arra jutottunk, hogy nincs szükség a törlésre. Elég, ha az ügyfél adatait elrejted a felhasználók elől. Eleve vannak olyan esetek, amikor fizikailag nem is tudsz törölni. Pl. bináris állományban többezer dokumentumot tárolsz, nem törölhetsz bele az állományba. Egyedül az adatbázis indexeket tudod módosítani, hogy a dokumentumot ne lehessen megjeleníteni.

Igen, megoldható, mindenképp kemény szivatúra. Ha a törzsadatok (amivel a többi adat adott személyhez köthetővé, azaz személyes adattá válik) tárolása az idők során változik/változott, akkor mindegyik verzióhoz külön visszaállítási folyamatot kell kreálni - és azt tesztelni.
Hatványozottan igaz a nagy szívás a már kivezetett, de archív állapotban megőrzendő rendszerek esetén - ott ugyanis vagy visszaépíti a cég a teljes infrát a felejtési jog alkalmazásának a tesztjeihez, vagy valamikor a jövőben egy visszaállítás során élesben kell kitörpölni, hogy hogyan miként lehet anonimizálni bizonyos személyek adatait.

Kivezetett, archiv állapotban lévő rendszerek szerintem ugyanoda sorolhatók, mint a mentések: ezekből nem kell eltávolítani a felhasználók adatait, hisz nem éles rendszerek.
Azt me, hogy ki, mit, hogyan, hova állított ezekből helyre, azt szabályozni és logolni kell.
Nyilván nem életszerű, hogy egy hónapokkal, évekkel archivált rendszert egyszercsak (az akkori adatokkal) élesbe visszatöltenek. Ugyanez érvényes a mentésekre is, ott sem a hónapokkal ezelőtti állapotra szokás visszaállni (akár disaster esetn sem), hanem az aktuális legutolsóra. Így meg már csak az azóta igényelt adattörléseket kell újra megtenni. Egy jól szabályozott, nyomon követkető, logolt rendszerben ez nem lesz annyira bonyolult. Az tény, hogy egy ilyet kialakítani hatalmas szívás lesz, főleg azoknak, akik most kezdenek hozzá, és van még 7 hónapjuk meglépni legalább az alapdolgokat.
Megjegyzem, a GDPR nagy része már most is szabályozott volt (belső vagy külső szabályzatok alapján), csak most megpróbálták ezeket egységes mederbe terelni, valamint be is fogják tartatni a leírtakat.

Elméletileg jó, tippre a jogászok is ezt hiszik... A visszatöltésnél nem számít, hogy "éles" rendszrebe kerül-e vissza, vagy épp egy hatósági megkeresés okán kell újraéleszteni x évvel ezelőtti állapotot - a visszaállított adathalmazban nem szerepelhet a felejtés jogával élni kívánt személyekről személyes adat. Jogászul persze a mentésben _sem_ lehetne ott a törlési igényt követően, de amikor visszakérdeztem, hogy oké, van havi archívként ezres nagyságrendben egyszer írható média, ami ráadásul időbélyegzett/elektronikusan aláírt mentést tartalmaz, azzal mi legyen? Jogászilag onnan is ki kéne piszkálni azt, amiről kérte az érintett, hogy felejtsük el...

vagy épp egy hatósági megkeresés okán kell újraéleszteni x évvel ezelőtti állapotot - a visszaállított adathalmazban nem szerepelhet a felejtés jogával élni kívánt személyekről személyes adat.

Ha a hatósági megkeresés biztosítása céljából van eltéve az x évvel ezelőtti állapot, akkor igencsak sanszos, hogy fogalmilag kizárt a felejtés joga az adott rendszerre vonatkozóan - hiszen ebben az esetben jogszabály/hatóság dönti el, hogy milyen adatoknak kell rendelkezésre állniuk, és ebből nyilván nem töröltetheti magát a magánszemély...

Ebben nem értünk egyet - egy "0fa7c7d4ab51e1309b5c4125692a505db9aa3aae" hash csak akkor személyes adat, ha a kapcsolat az érintettel visszaállítható. A hash-ből indulva ez a kapcsolat nem állítható helyre, csak a mentésben található, a hash-sel törlésre/vissza nem állításra jelölt adatok felől.

Minden adat személyes adat, ami az eredeti személyhez kötődik.

Ha a nevéből előállítasz egy hasht, az is az lesz, mert ha másvalaki is előállítja azt a hasht, ugyanazt kapja. Ezért nem lehet használni az EU-ba pl. az ilyen hash alapú központi ügyféltörténet nyilvántartókat.

Az üf. bejött, megadta az adatait, hogy kéri törölni a hozzá kapcsolódó személyes adatokat. Az éles rendszerből törlés megtörtént. Az adatait nem tároljuk a továbbiakban, az adatokból képzett hash-t hozzácsapjuk egy szűrőlistához, amit a mentések/archivált állapotok visszaállításakor használunk a törlések elvégzésénél. Igen, persze, lehetne az ugyfél rendszeren belül generált azonosítóját is használni erre a célra, csak ad1. nem biztos, hogy van ilyen, ad2. nem biztos, hogy minden adatbázisban van ilyen és azonosak (mert nem biztos, hogy az egyes adatbázisokat még adott adatkezelő esetén is össze szabad-e kapcsolni egymással ilyen egyszerűen (anno ezt is túljogászkodták a szmeélyi szám "betiltásával", hiszen természetes azonosítókkal simán ment/megy az összekapcsolás, csak picit bonyolultabb a select...))...

Szóval az éles rendszerből való törlés/anonimizálás után hogyan állítod vissza a kapcsolatot az adott személy és a 0fa7c7d4ab51e1309b5c4125692a505db9aa3aae hash között?

Jogilag persze az is személyes adat, hogy "x.y kérte adatainak a törlését" - ha az erről tárolt információból vissza lehet következtetni x.y-ra. Vissza lehet? A mentés visszatöltése és az abban szereplő összes rekordra lefuttatott függvényből kiesik, hogy az adott hash x.y-hoz tartozik - de ha nem esne ki, akkor a restore során hogyan is törölnénk/anonimizálnánk x.y adatait? Ha ez a működést (visszatöltés során ott lesz a törlendő/anonimizálandó adat, de a visszatöltsé végén, a visszaállított adatok között már nem lesz/anonimizálva lesz ott) jogilag nem fogadható el, akkor gyakorlatilag nincs megoldás a mentésekben, archívált állapotokban lévő személyes adatok kezelésére...

Nem a hash maga a személyes adat. Az a lényeg, hogy minden személyes adat, ami alapján összekötheted a te adatodat a valódi személyes adattal.

Ha józsiból mindig gsdf4 hash lesz, akkor igaz, hogy a gsdf4 hash-ból nem tudod meg ,hogy mi az eredeti név, de egyszer tudod meg, utána össze tudod kötni, hogy mindenhol ahol a gsdf4 hash van, az a józsi.

Az ügyfélvéleményező szolgáltatások is úgy működnek, hogy hash-t képeznek a személyes adakból (név, ip cím, email cím, utca házszám, stb) és ezeket küldik be mikor valaki reportol valakiről valaimt. Ebből nem állítható helyre az eredeti adat, mivel a hash egyirányú. De ha neked is megvan az eredeti adat amiből a hasht képezet (és miért ne lenne, ez a lényege, hogy ellenőrizd az ügyfeled történetét más szolgáltatónál) akkor már tudod, hogy melyik hash mit jelent. Ezért teljesen illegálisak ezek a szolgáltatások az EU-ba, mert az adatvédelemmel nem férnek össze.

Itt viszont nincs meg az eredeti adat, hiszen annak a törlése megtörtént az éles rendszerből.
Az alapfelállás az, hogy a mentésből visszatöltött adatokból is el kell távolítani azt, aminek a törlését kérte valaki. Ha van minden személy összes adatához az adataiból nem generálható egyedi azonosítója, ami alapján egy mentésből való visszaállítás során törölhető/aninimizálható valamennyi olyan adat, ami személyes adatnak minősül, akkor azt kell használni. Ha viszont nincs, akkor valamilyen módon tárolni kell, hogy mely adatokat kell ilyen esetben kipucolni.
A mentések visszaállítására és tisztítására természetesen megfelelően szigorú folyamatokat kell rárakni, hogy a takarítólista (akár rendszeren belüli sorszám, akár a takarítandó adatokból képzett hash) a visszaállítás során automatikusan és megkerülhetetlenül érvényesüljön. Ezek is olyan feltételek, amik jogászul jól hangzanak, de a valóságban azért nem ilyen egyszerűek...

Nekem egy "Józsit törölni kell" hash van a birtokomban. Ha a másik cég adatkupacában jogosult vagyok Józsi adatait elérni, azokat kezelni, akkor való igaz, hogy visszaállíthatom azt az infót, hogy "Józsit törölni kell".
Viszont ha Józsi megvonta tőlem a személyes adatainak a kezelési jogát, akkor a másik cég adataiban jogosultként kurkászva sem használhatom Józsi adatait...

A hash-es módszernél a hash két információt tárol: az adott hash-sel jellemezhető személyes adatok tulajdonosáról tároltak adatokat, de azoknak a törlését igényelték.
Ha az adatkezelő - személyes adat érintettje kapcsolat egykori fennállásáról sem tárolható információ, akkor nagyon-nagyon érdekes lesz megoldani a mentések/archívált adatok tisztogatását.

Mondok jobbat. Egy táblába elteszed, kiket kell törölni, bármilyen belső ID alapján. Ezen tábla alapján mindenféle háttérfolyamat elkezdi törölni az emberke adatait. Őt már backupolni sem szabad innen kezdve. Egyszer csak kikopik az utolsó backupból is, akkor törlöd az elején említett táblából, és kész vagy. A backup időintervalluma legyen kisebb, mint a törlés végrehajtásához szükséges törvényi határidő. Ettől nagyobb távra meg ne ments személyes adatot, úgysem reális, hogy hónapokkal ezelőtti állapotra vissza kellene állni. (Kivéve, amit muszáj megtartani, de azt meg úgyse kell törölni, ha kérik.)

A jelenlegi adatvédelmi törvény szerint nem feltétlenül kell törölnöd.

"17. § (1) Ha a személyes adat a valóságnak nem felel meg, és a valóságnak megfelelő személyes adat az adatkezelő rendelkezésére áll, a személyes adatot az adatkezelő helyesbíti.
(2) A személyes adatot törölni kell, ha
a) kezelése jogellenes;
b) az érintett - a 14. § c) pontjában foglaltak szerint - kéri;
c) az hiányos vagy téves - és ez az állapot jogszerűen nem orvosolható -, feltéve, hogy a törlést törvény nem zárja ki;
d) az adatkezelés célja megszűnt, vagy az adatok tárolásának törvényben meghatározott határideje lejárt;
e) azt a bíróság vagy a Hatóság elrendelte.
(3) A (2) bekezdés d) pontjában meghatározott esetben a törlési kötelezettség nem vonatkozik azon személyes adatra, amelynek adathordozóját a levéltári anyag védelmére vonatkozó jogszabály értelmében levéltári őrizetbe kell adni.
(4) Törlés helyett az adatkezelő zárolja a személyes adatot, ha az érintett ezt kéri, vagy ha a rendelkezésére álló információk alapján feltételezhető, hogy a törlés sértené az érintett jogos érdekeit."

2011. évi CXII. törvény
az információs önrendelkezési jogról és az információszabadságról

( andrej_ v | 2017. 10. 14., szo – 13:18 )

Még tavaly voltunk GDPR fejtágítón (igen kb. 1 éve...) és ezek a fő vonulatok. Remélem jól emlékszem, de majd a járatosabbak kijavítanak.

- A kedves felhasználó adatait csak az adott ügyhöz szükséges legkisebb mértékben kérheted el kötelező jelleggel és használhatod fel. Például nem lehet feltétel egy online vásárláshoz a születési idő, hacsaknem kifejezetten szükséges a rendelés teljesítéséhez.

- Az illetőt tájékoztatni kell az adatkezelés idejéről és hogy kik kezelik az adatot, logikusan pl. csomagküldésnél, számlázásnál stb.

- Az egyéb jogszabályokban foglalt megőrzési időket (pl. számlázás és vonatkozó számviteli előírások) nyilván be kell tartani. Logikusan egy törölt weboldal regisztráció az élő webes adatbázisból törli az illetőt, de a számlázásban ott lesz. Ott lesz a mentésekben is.

Biztosan lesznek majd még érdekes kérdések ezügyben, de alapvetően ügyviteli problémának érzem ezt és nem IT issue-nak.

Pl. a user accountodhoz tartozo e-mail cimet bekerik ha a user accountot hoznak letre, viszont ha torlest kersz, akkor nyilvan megy a levesbe az accountod az e-mail cimmel egyutt. Ellenben a szamlazasi rendszerben megmaradnak az adatok, hiszen azt kotelezo megorizni.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Itt a rendszerek elválnak. Adott egy élő webes rendszer, klasszikus példánál maradva mondjuk egy webáruház. Regisztráltál és megadtál mindenféle emailcímet, telószámot, számlázási ÉS mondjuk külön szállítási címet. Ha a rányomsz az account törlése gombra, akkor mindenhonnan (élő rendszer) törölniük kell azokat az adatokat, amiknél nincs egyéb (pl. számviteli) kötelezettség. A gyakorlatban ez a webáruházi élő webes rendszerből törlést jelenti, de a számlázó rendszerben megmarad jó eséllyel minden számlázáshoz kötődő adat és valszin a szállítólevélen tárolt infók is. Ha megadtál pl. derékméretet meg lábújkörömvastagságot, hogy a születési időről ne is beszéljünk, azoknak mennie kell a levesbe. Az megint más kérdés, hogy ezek hol és mennyire vannak elválasztva, de elvileg mindenképp illene.

A GDPR célja, hogy eleve minimalizálják a "csak úgy" tárolt személyes adatokat és kötelezzék az adatkezelőket felelősebb viselkedésre, illetve aki akarja az ténylegesen törölheti magát. Másodlagos célnak tűnik egyfajta kárcsökkentés is egy esetleges biztonsági probléma esetén, bár nem tudom mennyire akarnak majd CMS-eket erősebben frissíteni ezután a delikvensek.

Itt az nem működik, hogy a törölt felhasználót anonimizálják, de megmarad minden olyan adata, ami alapvetően nem személyes adat? Mert egy komplex rendszert nem tudsz úgy kivitelezni, hogy ne legyen inkonzisztens, ha törölsz belőle tranzakciókat egy-egy részből... raktárkészletbe nem teheted vissza, amit eladtál, annak ott kell lennie, hogy eladtál X dolgot Y felhasználónak Z időpontban... ugyanígy egy csomó analitika is alapulhat ezen, amikor beszállítókkal kell elszámolni... ha mondjuk havonta számolsz el a futárcégekkel, akkor kell legyen egy pontos listád, hogy melyik terméket hova kellett szállítani, átvették-e, kifizették-e, beérkezett-e a pénz, akkor is, ha a kedves user a rendelés után azonnal törölni akarja magát.

Ez jó kérdés - ugye van az a kitétel, hogy addig személyes adat a személyes adat, ameddig a kapcsolat visszaállítható. Ha a természetes azonosítók (név, születési adatok), illetve egyéb olyan információk hiányoznak, amik ezt a visszaállítást lehetővé teszik, akkor már nem tekinthető személyes adatnak. Ezt persze vizsgálni kell, hogy pl. egy cím meddig valakinek a címe...? Ha egy soklakásos lpécsőház, akkor elég-e a házszámig visszatörölni, vagy a házszám semmaradhat? Ugyanez egy falusi ház esetén? Egy olyan utcában, ahol egy darab ház van csak? - A biztos módszer itt úgy tűnik, hogy maximum a település/irányítószám, ami megmaradhat...
A rendelés azonosítója rendszeren belül egyedi, a számlázási adatokat jogszabályi kötelezettség alapjánkell kezelni, úgyhogy ott azért bejön a "törölni, de mégse" effektus is...

Én alapvetően nem tudom másképp elképzelni ezt a törlést, minthogy törlődnek a személyhez köthető adatok, de a tranzakciók maradnak, csak egy anonimizált ügyfélhez kapcsolódnak... és persze, ha volt számlázás, akkor a számlázás felől vissza lehet követni, hogy ki vette meg az adott terméket vagy szolgáltatást.

Értem a törekvést és a szándékot, csak ebből is olyan faszságok fognak kijönni, mint a cookie-bar.

A számlázási adatok megőrzését jogszabályi kötelezettség írja elő (adatkör, időtartam), ezeknél pont az archív (előírt megőrzési időnél régebbi) adatoknál van bibi - persze már most is, hiszen a kötelező idő lejártával az adatok további kezelésének nincs jogalapja. Azaz a vásárlók listája adatkupacból kikukázható/anonimizálható Gipsz Jakab, de a számlázórendszerből nem - jó kérdés, hogy ennek milyen valós értelme lesz...?

Nem IT issue, hanem az IT szállítja rá a megoldást, jelen esetben programfejlesztéssel. Ettől még az alapprobléma ügyviteli vagy cégpolicy jellegű. Az IT javasol, meg konzultálnak vele stb, de maga a probléma csak szeretnék, hogy IT issue legyen, hiszen akkor arrébb tudták tolni. Nem szabad hagyni.

(Az IT issue az, amikor programhiba van vagy keresztbeállnak az OS szemei...)

( Elbandi v | 2017. 10. 15., v – 22:17 )

a felejtes joga mellett hogy lehet megvalositani egy kitiltas funkciot?

Pl. Belat valamiert ki kell tiltani a webaruhazbol, majd jon Bela hogy marpedig toroljunk minden infot rola. Ezutan hogy lehet megoldani hogy Bela tobbe ne tudjon rendelni tolunk?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Vagy nem. A 8.8.8.8 az egy IP-cím, de hogy személyes adat lenne, azt kétlem :-P Hogyan állítod vissza az IP-cím _és_ az adott természetes személy közötti kapcsolatot a rendelkezésedre álló adatok alapján? Azt, hogy "Béla User" már nem tárolod.
Béla dinamikus IP-címe nálad az időpont ismeretében is csak egy IP-cím, ha a dhcp loghoz nincs hozzáférésed. (Azaz az internet szolgáltatójánál személyes adat a dhcp-log birtokában, de a dhcp log nélkül már nem, hiszen ebben az esetben már ott sem állítható vissza a kapcsolat Béla és a címe között.

De ott van egy paramparam123 kukac valami pont tld ip-cím. Ez, ha már nincs levél a birtokodban, amit Béla írt ezzel a feladóval, hogyan kapcsolódik Bélához? Ha már nincs a cím mellett ott Béla többi adata, csak az, hogy "töröltuser1234" "töröltcím" satöbbi...?

Nem én mondom, hanem a Péterfalvi Attila:

Az Internet hálózatában az IP címek egy-egy számítógépre utalnak, melyet az Internethez hozzáférést biztosító szolgáltató (internet access provider) rendel az előfizetőhöz abból a célból, hogy azonosítsa az előfizetőt.
...
A személyes adatok védelméről és a közérdekű adatok nyilvánosságáról szóló 1992. évi LXIII. törvény (a továbbiakban Avtv.) 2. § 1. pontja szerint az IP címek vonatkozásában személyes adatról beszélünk.

Akkor Péterfalvi úr állítsa vissza az IP-cím és az adott természtes személy kapcsolatát abból az egy szál infóból, hogy 193.6.x.y. és 2016.07.08. 09:10:11.12
A citált mondatok közül hiányzó részek a relevánsak szerintem, mert a szolgáltatónál ott van a log, amiben benne van a cím, meg az, hogy kinek lett kiosztva adott időpontban. Neked, mint a "másik oldalon" működő szerver adminjának viszont ez az infó nem áll a rendelkezésére, csak az ip-cím, meg egy időpont/intervallum. Ebből, kizárólag ebből nem lehet visszaállítani a -kapcsolatot - ami feltétele annak, hogy az adat személyes adat legyen.

Ilyen alapon az, hogy "Attila" minden esetben személyes adat, hiszen Péterfalvi úrral, mint természetes személlyel kapcsolatba hozható, őt azonosítja. Ja, hogy csak adott körben/helyzetben/feltételek mellett elegendő csak az utónév...?

Ja, már ott elbukik a jogászkodása, hogy "az IP címek egy-egy számítógépre utalnak"... NAT-ról beszélt-e neki valaki...? Ha nem, akkor kéne... Merthogy a full IPv6 az még bőven odább van...

A "személyes adat" és a "lehet személyes adat" között azért elég komoly különbség van. A szolgáltatói oldalon igen (tudniuk kell, hogy adott időpontban kinek volt kiosztva), egy webszerveren, amit arról a címről látogattak meg viszont csak akkor, ha a látogatás során olyan adatokat is begyűjt a webszerver/megad a felhasználó, amivel már személyhez köthető lesz.
Az egyéni privát véleményem röviden annyi, hogy ha az adott adatkezelőnél rendelkezésre álló adathalmaz alkalmas arra, hogy az adat és egy természetes személy közötti kapcsolat megmaradjon, illetve helyreállítható legyen, akkor az személyes adat. Ha nem, akkor nem.

(Kellően széles körű adatbányászkodással szinte bármilyen adatról kimutatható, hogy személyes adat...)