GDPR felkészülés KKV szektorban

 ( akoska00 | 2018. február 26., hétfő - 21:30 )

Sziasztok!

Véleményt szeretnék kérni tőletek, illetve tapasztalatot, hogy KKV esetén mely dolgokra koncentráljunk a májustól kötelező új szabályrendszernek való megfelelés érdekében? Van néhány anyagunk, az eddigi Infotv. szerint igyekeztünk ezeket csiszolgatni. Nincs webshop, főleg cégeknek végzünk szolgáltatást szerződés alapján, illetve részükre értékesítünk, hírleveleket nem küldünk senkinek. Melyik jogszabályt érdemes a pl. adatvédelmi nyilatkozatban hivatkozni? A magyar infotv.-t vagy az életbe lépő EU-s szabályrendszert? Van-e szerintetek lényeges szigorítás az eddigi szabályokon vagy csak egy felkapott téma lett?

Előre is köszönöm a véleményeket!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A szabályok alig változtak, a kiszabható bírság változott nem kicsit. Azért lett felkapott téma, mert a bírság felső határa a korábbi több millió forintos összegről több millió eurós összeg lett, de akár a cég éves bevételének a 4%-át is elérheti.

Azt lehet tudni, hogy fogja-e ezt ellenorizni egyáltalán valamilyen szerv, vagy csak feljelentésék, perek esetén van jelentősége?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Azon országokban ahol ez már megy, a feljelentések + incidens bejelentések ugrásszerűen megnőttek amivel bírkózik a hatóság. Idehaza az információim szerint kb 150 embert képez ki a NAIH erre a feladatra, ami a vállalkozások számát tekintve nem is olyan sok, de elképzelhető hogy lesz kapacitásuk szisztematikus ellenőrzésekre...

Ha ezt is annyira szelektíven fogjak kezelni, mint a jelenlegi adatvedelmi szabályozast sértő eseteket, akkor nem várhato túl sok változás.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Kolléga egy időben sportot űzött abból, hogy a megjelölt "szabályos lejelentkezés" procedúrák többszöri végigvitele után felhívta az érintett cégeket, hogy kilátásba helyezze a következő lépését.
Azóta megsokszorozódott a webcégek száma - kétlem, hogy a kompetencia és jogkövetési szándék lépést tartott volna ezzel.

Nem erről jut eszembe: érdekes jogi eset lesz, amikor azt kell eldönteni, hogy adott csillió forintos bírságot a Kubatov Bt, a Fidesz MPP vagy Magyarország Kormánya kénytelen fizetni, vagy nincs itt semmi látnivaló.
Popcorn required.

Ha nem a harmadik, egy karton sört fizetek és közösen isszuk meg a Lánchídon.
A dobozokat természetesen visszaváltjuk, és azt is leisszuk.
Na?

Off: erről a 150 emberről van valami konkrét infó? Sok helyről hallom, de senki nem tudott konkrétumot mondani. (Pl. hogy ha van 3-4 érdeklődő ismerősöm, hova lehet referálni őket. :D)

Szerk: merthogy “Jelenleg nincs érvényes álláspályázat.”

Ezt én is másodkézből hallottam, elvileg a NAIH-val konferenciáltak a jóemberek, de biztosat nem tudok. Majd ha legközelebb NAIH randevúm lesz rákérdezek.

"Azon országokban ahol ez már megy, a feljelentések + incidens bejelentések ugrásszerűen megnőttek amivel bírkózik a hatóság."

Forrás?

Hollandia például korábban implementálta a data breach notification kapcsolódó szabályait (kis változással), elég sok cikk van róla, íme egy:

https://iapp.org/news/a/130-days-1500-notifications-does-dutch-breach-rule-foreshadow-gdpr/

Még az előző munkahelyemen kb. másfél-két éve kaptunk levelet valamelyik állami szervtől (fogyasztóvédelem talán), hogy szisztematikus ellenőrzésen találtak kifogásokat az oldalon (apróbb hiányok az ASZF-ben, feltüntetendő dolgok, stb.), szóval ellenőrzések már eddig is voltak.

Akkor segítőkész, támogató jellegűek voltak. Arra jutottunk, hogy nem büntetni akartak, hanem konstruktívan felkészítő jelleggel írtak. Persze, ez nem jelent semmit.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

subs

+1

+1

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

+1

Nézzétek át hol tároltok személyhez köthető adatokat úgy papíron mint elektronikusan. Az adatok törlésére illetve a fizikai megsemmisítésre fókuszáljatok szerintem, ezeket dokumentálni is kell. Ha vannak mobil eszközeitek azok legyenek mind titkosítva. Pendrive-ok kivezetése illetve titkosítása ha mégis kell használni.

http://eur-lex.europa.eu/legal-content/HU/TXT/HTML/?uri=CELEX:32016R0679&from=HU

Egyszer átnéztem és ennyit jegyeztem le belőle magamnak, mint lényeg:

32. cikk idézet:
"Az adatkezelés biztonsága
(1) Az adatkezelő és az adatfeldolgozó a tudomány és technológia állása és a megvalósítás költségei, továbbá az adatkezelés jellege, hatóköre, körülményei és céljai, valamint a természetes személyek jogaira és szabadságaira jelentett, változó valószínűségű és súlyosságú kockázat figyelembevételével megfelelő technikai és szervezési intézkedéseket hajt végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálja, ideértve, többek között, adott esetben:
a) a személyes adatok álnevesítését és titkosítását;
b) a személyes adatok kezelésére használt rendszerek és szolgáltatások folyamatos bizalmas jellegének biztosítását, integritását, rendelkezésre állását és ellenálló képességét;
c) fizikai vagy műszaki incidens esetén az arra való képességet, hogy a személyes adatokhoz való hozzáférést és az adatok rendelkezésre állását kellő időben vissza lehet állítani;
d) az adatkezelés biztonságának garantálására hozott technikai és szervezési intézkedések hatékonyságának rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást.
(2) A biztonság megfelelő szintjének meghatározásakor kifejezetten figyelembe kell venni az adatkezelésből eredő olyan kockázatokat, amelyek különösen a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítéséből, elvesztéséből, megváltoztatásából, jogosulatlan nyilvánosságra hozatalából vagy az azokhoz való jogosulatlan hozzáférésből erednek.
(3) Az adatkezelő, illetve az adatfeldolgozó 40. cikk szerinti jóváhagyott magatartási kódexekhez vagy a 42. cikk szerinti jóváhagyott tanúsítási mechanizmushoz való csatlakozását felhasználhatja annak bizonyítása részeként, hogy az e cikk (1) bekezdésében meghatározott követelményeket teljesíti.
(4) Az adatkezelő és az adatfeldolgozó intézkedéseket hoz annak biztosítására, hogy az adatkezelő vagy az adatfeldolgozó irányítása alatt eljáró, a személyes adatokhoz hozzáféréssel rendelkező természetes személyek kizárólag az adatkezelő utasításának megfelelően kezelhessék az említett adatokat, kivéve, ha az ettől való eltérésre uniós vagy tagállami jog kötelezi őket. "

40. cikk idézet:
"A tagállamok, a felügyeleti hatóságok, a Testület és a Bizottság ösztönzik olyan magatartási kódexek kidolgozását, amelyek – a különböző adatkezelő ágazatok egyedi jellemzőinek, valamint a mikro-, kis- és középvállalkozások sajátos igényeinek figyelembevételével – segítik e rendelet helyes alkalmazását."

Összefoglalva: Az, hogy mi vonatkozik rád a 32.cikk-ből (minden vagy semmi) azt nem neked kellene eldönteni, de mivel nem tudok kidolgozott "magatartási kódexet" ezért mégiscsak mindenki magának dönti el. Aztán majd vagy fizet vagy nem.

Ha csak szolgáltatást végeztek, akkor nincs olyan sokminden, a végzés során véletlen adathozzáférés előfordulhat, erre legyen a szerződött fél felé szóló NDA.

Biztos, hogy van belső adatkezelésetek: foglalkoztatáshoz kapcsolódan, toborzás, e-mailek, ilyesmi. Egy KKV esetén előírt papírmunka ehhez nincs, de a szabályozás fontos része, hogy neked kell bizonyítani, hogy megtettétek a megfelelő "technológiai és szervezési intézkedéseket" az adatbiztonság érdekében. Erről lehet egy egyszerű adatleltárt készíteni (ami egy excel fájl kb), de persze több szép dokumentumot is lehet szülni. Erre best practice egyelőre nem sok van, most kezd alakulni. Végiggépelni nem gépelném :)

Nem tudom merrefelé vagytok, jövő héten tartok kifejezetten KKVéknak erről ingyenes előadást: http://gymskik.hu/hu/gyor-moson-sopron-megyei-kereskedelmi-es-iparkamara/rendezvenyek/gdpr-konzultacios-workshop-a-gyori-kamaraban-aprilis-12-en-13680

KATA-méretű vállalkozásban tolunk user interjúzást és usability tesztelést. Arckamerás videófelvételeink és toborzással kapcsolatos levelezéseink vannak.

Amúgy van adatvédelmi nyilatkozat, mindenkivel alá is iratjuk szépen évek óta. Ebben közöljük:
- az adatkezelés célját
- az adathoz hozzáférők körét
- az adatkezelés várható idejét
- a törlés végső határidejét

Ezután ezeket a felvételeket egyszerűen letöröljük a Google Drive-ról, vagy az adott szolgáltatásról (lookback.io, hellopingpong, stb)

Az adatbázisokat (a gyakorlatban: Google forms által generált google sheets) is töröljük a toborzási időszak lezárultával, más kutatásokhoz nem használjuk.

Aszondod, mint KKV minket nem érint a GDPR?:)

(Még nem volt időm és főleg pénzem elmenni ügyvédhez...)

Még csak véletlenül sem mondok olyat, hogy KKVét nem érint :) érinti őket, de van egy csomó cipőbolt jellegű KKV akinek a megfelelés tulajdonképpen triviális.

Toborzással kapcsolatos levelezés OK, a CVéket nem lehet örökre megtartani. Toborzási kör befejezte után 6 hónappal CV törlés. (6 hónap, mert annyi ideig lehet diszkrimináció miatt panaszt emelni.) Ha szeretnéd a CVét tovább megtartani (pl jövőbeli megkeresés miatt), akkor ahhoz beleegyezést kérsz.

Arckamerás felvételhez egy rendes hozzájáruló nyilatkozat teljesen korrekt. Kapcsolódó adatkezelési gyakorlatról (ki, mikor törli le) nem rossz ha van egy process leírás. A harmadik fél bevonása (Google, stb) kapcsán arra figyeljetek, hogy a tárolás is adatfeldolgozás, ergo valamilyen papír kell arról, hogy ők megbízott adatfeldolgozók és garantálják a megfelelő színvonalú (GDPR kompatibilis) adatkezelést. Google esetén most van erre Data Processing Amendment, amit online alá lehet írni és rendben vagytok, a többi céget amit említettél nem ismerem.

Ezen kívül még van némi foglalkoztatáshoz kapcsolódó adatkezelésetek gondolom, esetleg külsős bérszámfejtés, ilyesmi...

Ügyvédekkel óvatosan, a nagy része egyáltalán nem érti a GDPR gyakorlati oldalát, IThoz csak távolról szagolnak és tisztelet a kivételnek, de olyan zöldségeket képesek terjeszteni, hogy a hajam égnek áll :)

Nálunk a raktárban biztonsági kamerarendszer van, de a raktárba csak a saját alkalmazottak és az ügyfeleink léphetnek be. Azt mondja az egyik ügyvéd, hogy kameránként meg kell írásban határozni, hogy mit rögzít, mennyi ideig és mindenkivel, aki a kamera látókörébe kerülhet, egyenként alá kell iratni, hogy hozzájárul a felvételhez. Továbbá a kamerarendszer létét be kell jelenteni az adatvédelmi hatóságnak. A másik ügyvéd szerint ez marhaság, elég táblán kifüggeszteni, hogy itt kamerafelvétel készül és csak akkor kellene bejelenteni, ha a saját kollégáinkon és az ügyfeleinken kívül (akik pl. áruért jönnek) bárki arrajárót rögzítene a kamerarendszer (mondjuk ott aztán még érdekesebb lenne, ahogy egyenként megállítjuk az arrajárókat hogy smile, you are on candid camera, pls sign here). Nálunk a raktárig csak az jut el, akit odaengedünk.

Az ügyvédek szerepe azt hiszem ennek az egésznek a létrehozásában és fenntartásában sem elhanyagolható.

Jogászok, nem ügyvédek ;)
("Nyilván nem szó szerint kell érteni, ugyanúgy vonatkozik bármely tejipari termék készítőire.")

Igen, ez fontos kitétel, felelősség nélkül olyan faszságokat tunak mondani, hogy füstölök.

https://www.hwsw.hu/hirek/58469/gdpr-eu-adatvedelem-hr-allashirdetes-megfigyeles.html

Ezt nemrég olvastam:

Továbbá a kamerákat is lehet használni az irodában, de elsődlegesen csak a személy- és vagyonvédelmi, valamint a magánnyomozói tevékenység szabályairól szóló 2005. évi CXXXIII. törvényben (Szvtv.) meghatározott célokból. Ha a munkáltató ettől eltérő célból tervez kamerás megfigyelést alkalmazni, a GDPR-ban meghatározott „jogos érdek” jogalapjára kell hivatkoznia, és ezt a jogos érdeket igazolnia kell. A Szvtv. szabályozza a tárolás lehetséges időtartamát is. Fontos újdonság azonban, hogy nem elegendő a kamerás megfigyelésről szóló általános tájékoztatás, hanem minden kamera vonatkozásában egyesével kell tájékoztatni az érintetteket az adott kamera látószögéről, céljáról és szükségességéről.

És ha irodában nincs kamera, csak gyári üzem és külterületen?

A szabályozás eddig is feltételekhez kötötte a kamerás biztonsági megfigyelést, ebben sztem nincsen változás. A változás egy kalapnyi teljesen értelmetlen adminisztrációban van, ami tipikusan a brüsszeli jogászok merénylete az ép ész ellen. Nomeg a változás a bejelentési kötelezettségben van, ami az alapján dől el, hogy a saját alkalmazottakon és az ügyfeleken kívül is kerülhet-e bárki a kamera látókörébe. Ha kerülhet, be kell jelenteni, ha nem kerülhet, nem kell bejelenteni.

A szigorú szabályozás többek között a te seggedet is ugyanúgy védi az illetéktelen, visszaélésszerű adatfelhasznalastol, úgyhogy inkább örülj neki, hogy van, ahol gondolnak erre is!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Sztem nem védi.

Nem akarlak mindenáron meggyőzni.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A mindenárat persze lehetne összegszerűségében is pontosítani? (Ha te abban akarsz hinni, hogy a jognak dolga bárkit megvédeni, az nekem nincsen ellenemre, csak nem szeretném én megfizetni ennek a következményeit.)

A mindenáron azt jelenti, hogy amit a szó jelentese magában hordoz, mindenki azt hisz, amit akar. Ha te nem hiszel a jogrendszerben, az a te dolgod.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Azért van az a pénz, amiért jogász elvállalja, tanácsadó véleményezi, ne tagadjuk. Az egyén meg tejel, hogy megvédjék? Röhej.

Ha nem tetszik, hogy az igazságszolgáltatás a jogrendszeren alapszik, meg mindig foghatsz egy shotgunt és intezheted magad, ha sérelem er.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Jog elméletben tök szép dolog, de gyakorlatban addig terjed, míg érvényesíteni tudod azokat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az már viszont nem a jogrendszer hibája.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ennek a jogszabálynak semmi köze a jogrendszerhez. Igény persze lenne arra, hogy a rendszer is annyira túlszabályozott és ferde legyen, mint amennyire ez a jogszabály. Adminisztrációval, értelmetlen bürokráciával terhelik a nyulakat, miközben az elefántok azt csinálnak a háttérben, amit csak akarnak. Nevetséges lenne az egész, ha nem lenne ennyire siralmas.

Maguk az ügyvédek is bizonytalanok.

"Még mindig nem tudunk pontos információkat a május 26-án hatályba lépő, Magyarországon is közvetlenül hatályos európai Általános Adatvédelmi Rendelet (GDPR) ügyvédeket érintő kötelező előírásainak hatályáról. A legnagyobb problémánk, hogy a Magyar Országgyűlés még nem alkotta meg sem a rendelethez igazodó Infotörvény novellát, sem azt az egyes ágazati szabályokat módosító saláta törvényt, amely az ügyvédi tevékenységről szóló, idén hatályba lépett ágazati törvényre is vonatkozna. Nem jelölte ki továbbá azt a hatóságot sem, amely ezekben a ügyekben eljárhat. Annak várományosa, a NAIH is tehát nagyon óvatosan nyilatkozik és hangsúlyozza hogy szakmai véleményükre egyelőre ne támaszkodjunk.

A Magyar Ügyvédi Kamara elnöke már több ízben kapcsolatba lépett a jelenlegi adatügyi hatósággal és a fejleményeket követi. A szabályozási jogkörökkel nem rendelkező Budapesti Ügyvédi Kamarában pedig egy szakértői csoport alakul, amely a fővárosi ügyvédek szakmai álláspontját fogja megfogalmazni a leglényegesebb kérdésekben. Április végén és májusban – később meghirdetett időpontokban - pedig a kamarában nyilvános konzultációkat, fórumokat fogunk tartani.

Egyenlőre nincs több információnk, amint valami fontos és használható információ birtokába jutunk, azt tagjainkkal médiumaink útján közölni fogjuk."

Szóval emiatt a marhaság miatt még további rendeleteket és törvényeket kell hozni, hogy egyáltalán értelmezhető legyen. Nő a bürokrácia minden szinten és gyarapodik a semmittevő siserahad. De a legnagyobb bírság mértékét már kiszámolták. Röhej az egész.

Röhej, de ez nem az EU hibája. A rendelet lassan két éve hatályos. Csak hőn szeretett kormányunk nem készült el a házi feladattal. Biztos hiányzott hozzá a kétharmad, de majd most, amint a Stop Soros kész, belenéznek, nincs-e valami elmaradás.

Ha ebben a formában létre se jött volna, most nem kellene foglalkozni vele. Ha meglesz a hazai hozzáilleszkedés, lesz egy kisebb regény belőle, úgy egy tucat különböző joghelyen.

A fingra gombot varrni külön mesterség, jogászaink semmivel sem gyengébbek ebben, mint a brüsszeliek.

Az én seggemet mitől védi?
Ugyanúgy jönnek majd a 2000000email címlista 2forintért levelek, mint eddig, és azok akik ezt kiküldik, illetve igénybe veszik, azok ugyanúgy messziről tojni fognak GDPR-ra, ahogyan eddig az Info tv-re.
De legalább a vállalkozásokat szénné lehet büntetni, remek.

Lehetőséged van jogi úton érvényt szerezni az erdekserelmeden, enélkül pedig csak ki lennél szolgáltatva a hatalomnak.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Azért várjál, a 2000000email címlista a kisebb baj, nekem a privát levelezésemre hetente max 1-2 db spam érkezik, az kevésbé érdekel.

Viszont kapásból tudok 4-5 céget akinek alig várom, hogy harapófogót akaszthassak a tökeire a sorozatos, levakarhatatlan baromságaik miatt. Májusban úgy fogok sátrazni az Illetékes Hivatal székhelye előtt, mintha megjelent volna az iPhone XI.

mahaha, lajk :-)

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Az első ügyvédnek abban van igaza, hogy kamera szabályzatot illik írni, ami dokumentálja, hogy miért van az a kamera, mit figyel meg, hol tárolják a felvételt, ki fér hozzá és mennyi idő múlva semmisítik azt meg. A törlés a vagyonvédelem esetén ez az itthoni törvények szerint 3 munkanap. Ettől el lehet térni alaposan megindokolt "jogos érdek" alapján, azaz a cég valamilyen alapos üzleti érdekére hivatkozik, ami erősebb a természetes személyek jogainál. Vékony jég, de esetenként működhet, pl ATM esetén jóval késöbb derülhet ki egy visszaélés, ezért tovább kell tárolni az adatokat.

Abban viszont a második ügyvéddel értek egyet, hogy a személyenkénti hozzájárulás nettó marhaság :) Majd nézzük csak meg, hogy mielött(!) belép valaki egy bankba majd mindenkivel kitöltetnek-e egy ilyen hozzájárulást :) Nyilván nem életszerű és a rendelet is inkább arról szól, hogy tisztességes módon történik az adatkezelés. Ez kamerás rendszerek esetén a bejártnál kívülről (belépés elött) látható tájékoztatással a legegyszerűbb megoldani, miszerint odabent felvétel készül.

Az ügyvédek szerepét a történetben nem vitatom, van egy alapos hisztériakeltés :)

nalunk pl. a szerverszobaban van kamera, ahova kb 3 ember mehet be (meg akit a portas neha beenged a tudtunk nelkul, emiatt van a kamera). mondjuk van rajta arcfelismeres is, es ha nem regisztralt arcot lat, kuld emailben riasztast. ez minek szamit? :)

Lesz több kanyar a történetben :)

Az arcfelismerés bonyolítja a helyzetet, mert van biometrikus adatfeldolgozás mögötte. A személyek biometrikus adatai a 9. cikkelyben említett különleges adat körébe tartoznak, amit alapvetően hozzájárulással lehet kezelni, így a belépőknek ilyet alá kellene írni. Sajnos az ajtóra kihelyezett kamera figyelmeztetés ez esetben nem elég.

Ámde :) foglalkoztatás körében nem lehet hozzájárulást kérni semmihez, mert "egyenlőtlen erőviszonyok" állnak fent a munkáltató és a munkavállaló között. (Azaz úgy érezheted, hogy ha meg akarod tartani a munkádat akkor hozzájárulást adsz mindenhez.) A feloldása az ellentmondásnak, hogy a munkaszerződésben vagy annak kiegészítésében kell ezt rögzíteni, hogy a cég ilyen rendszert üzemeltet a szerverterem védelmére. (Külsősökkel marad a hozzájárulás aláiratása.)

Valami ilyesmi :) attól tartok ennek egyszerűbb megoldása nincs, ha a rendelet szerint akartok eljárni. HA :)

"a vagyonvédelem esetén ez az itthoni törvények szerint 3 munkanap"

Ezt milyen törvény írja elő?

Személy és vagyonvédelmi törvény 31§/2

Kösz!

"felhasználás hiányában"
Tehát ha nem történt semmi.

A 3 nap komolytalan. Nálunk ami átmegy a kamera területe alatt, 4-5 nap, amíg odaér a rendeltetési helyére (Portugáliába). Azért van a felvétel, hogy látszodjon, milyen állapotban, hogyan indult el a raklap, ki és hogyan rögzítette a kamionban. Az első reklamáció 6-7 nap múlva érkezhet akkor, ha sérülten érkezik. De jog szerint egy éven belül bármikor reklamálhatnak. Egy évig csak azért nem tudom megtartani a felvételt, mert nincs akkora tárhely.

A "jogvédő" aki a 3 napot kitalálta, jogász lehetett. Nem akarom megsérteni.

egyetertek. ismerosnel is eltunt egyszer 3 uj laptop egy raktarbol, persze mire eszrevettek mar letelt a 3 nap... nem tudom hogy zart raktarakra is vonatkozik-e a 3 nap, de leszarom, ott nem toroljuk mostmar a felveteleket.

Nem kell nagyon ráparázni, jogos érdek keretében lehet hosszabb a tárolási idő, az említett kamionos sztori az tipikusan ilyen. A kamera szabályzatban meg kell róla emlékezni, hogy ilyen olyan okból mi úgy döntöttünk, hogy X napig fogjuk tárolni a kamera felvételt és jók vagytok.

A három napos szabály inkább az ilyen barkács bolt jellegű dolgokra van kigondolva, ahol rengeteg ember megfordul, nyilván van valamennyi vagyonvédelmi jelentősége a dolognak, de azért elég indokolatlan lenne az idők végezetéig tárolgatni a felvételeket.

Ez alapján a jogszabály alapján egy közepes ügyvéd félkézzel bármikor bebizonyítja, hogy a kamerafelvétel, amit 3 nap után nem töröltek, az jogellenes. Egy jó ügyvéd szép kis pénzt kipörölhet az alkalmazottnak sérelmi díjként az ilyenért.

Nem para, csak megint túl van szabályozva valami, ami semmiféle törvényi szabályozást nem igényelne (a kamerafelvétel törlését simán lehetne az általános elévülés szabályai szerint rendelni). Teli vagyunk unatkozó jogászokkal, ha a töküket vakargatnák naphosszat, előrébb lennénk.

Muhaha, nálunk az előző helyen pont a rakisok szerették volna, hogy legyen hónapokra vissza kamerafelvétel. Mármint az egyszerű mezei alkalmazottak. ;)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nyilván, az nekik is fontos bizonyíték... de jön Szása, a brüsszeli ügyvédsegéd kisúttörő és segít rajtuk, mert fontos, hogy a jogrendszer védje a honpolgárt. Akár jó az neki akár nem.

Nagyon szépen köszönöm :)

CV-t nem tartunk, ez egy kérdőív, mittom, használtál-e már email marketing szoftvert, a cégnél beosztásod vezető-marketinges-egyéb stb, az a lényeg, szűri a jutalomra hajtó delikvenseket aszerint hogy célközönsége-e a szoftvernek amit tesztelünk épp. Viszont nyilván kell az emailcíme is, hogy felvehessük vele a kapcsolatot ha megfelelt a kritériumoknak, innentől kezdve beazonosítható....

A többi szoftvernek is muszáj GDPR kompatibilisnek lenni, ezek szakszoftverek, nem hiszem h kidobnák az EU piacot kompletten emiatt.

Azt nem tudom, a Google-nél a törlés dokumentációját hogy oldjuk meg. Az egyes alanyok könyvtárait monogram jelzi, egy hónap után már én se szoktam tudni ebből ki kicsoda :) de ha belenéznék a videóba nyilván beugrana.

Szóval alapvetően - mivel történt már visszaélés beazonosíthatósággal - komolyan van véve nálunk az anonimizáció, de a zabhegyezés fogalmam nincs milyen szinten kell hogy legyen.

Ah, akkor a toborzást én értettem félre :) Az ilyen jellegű adatgyűjtéshez egyszerűen hozzájárulást kell kérni, ha van a korábban említett adatvédelmi tájékoztatásnál ilyen, akkor nincs más tennivaló, ha nincs, akkor ezzel érdemes kiegészíteni.

Az egyéb szoftverek kapcsán, ha azok nálatok futó szoftverek, nem kell külön GDPR megfelelés, nektek kell adatvédelmi szempontból okos módon használni őket. Azthittem, hogy azok is felhő szolgáltatások, abban az esetben több a bonyodalom.

A törlést akkor érdemes lehet fejleszteni, hogy egyértelmű legyen mi a régi adat.

Zabhegyezni szerintem mérsékelten érdemes, ideális esetben egy "szakértővel" egy óra alatt átnéznétek a gyakorlatot, leírnátok mit kell finomítani és kész. Sajnos jelenleg úgy néz ki a GDPR piac, hogy kevés az igazán hozzáértő, azok meg elsősorban a nagy cégek drága megfelelésén szertenek dolgozni és ilyen KKV jellegű ránézésekben nem partnerek (vagy nem tudják mit kezdjenek vele, mert ők csak a nagyágyú módszereket ismerik).

Van az alján egy adatkezelési szövegblokk, nem nagy, de van:

http://bit.do/jelentkezes_kutatasra

E-mail cím mezőnél ott van. Persze infotörvény meg NAIH szám nincs, pedig tudom h kéne, de most ez gyorsan kellett.

Ez az adatkezelésink: https://drive.google.com/open?id=0B9rEsG3a7264bzZhVXkwa2Z4c0U

Én azt gondolom, reálisan senkinek nem lehet kifogása az ellen, hogy kontaktáljak vele egy személyes interjú időpontegyeztetése miatt, ha egyszer pont erre jelentkezik, és nyilván minden más megoldás csak bonyolítja.

Van valaki aki ezeket le tudja tisztázni es ajánlod?

NAIH szám május 25-től nem kell, úgyhogy azt megússzátok :)
Ezek a kis kiegészítések szerintem tök elégségesek, nem kell jogi szöveg, egyszerű érthető leírása annak, hogy mi történik az adattal. A tetején nekem kicsit fura a megfogalmazás, nem egyértelmű, hogy a kutatás kapcsán az iTeam Holding Zrt a kivitelező, azaz nekik adom oda az adataimat vagy csak az ő kutatásuk, de más cég jár el. Ezt talán lehetne javítani.

Az adatkezelési doksi nincs nyilvánosra téve, ha megteszed arra is rápillantok. Hogy ki az aki le tudja tisztázni, ajánlom magamat, de nem biztos hogy erre szükségetek van :)

Ezt a GDPR törvényt mindenki máshogy értelmezi.
Ha jól sejtem, a megoldásod nem felel meg.
Ha személyes adatot (pl. email cím) kérsz be, akkor szerintem jó a szöveg amit az email alá írtál, viszont ezt egy külön pipa mellé kellene tenni, ami alapból nincs bepipálva.

Jó meglátás, ha nem is az e-mail cím mellé, de a lap aljára kellene egy checkbox, hogy "hozzájárulok, hogy az adatkezelő az elérhetőségeimet a megkeresés céljából és idejére eltárolja" vagy valami ilyesmi.

A kérdőívre újra ránézve, még annyi probléma van, hogy az adatkezelő nincs azonosítva. A cég elérhetőségét illene feltüntetni. Opcionálisan egy teljesebb adatkezelési tájékoztatót lehet linkelni, ahol nem csak az adatkezelési gyarkolat van leírva, hanem hogy hogyan élhetnek az adat alanyok a jogaikkal, stb.

"akinek a megfelelés tulajdonképpen triviális."

HA-HA-Ha...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Arra van valakinek ötlete, hogy hogy lehet user blacklistet fentartani a jövőben? Gondolom simán az email cím nem lesz jó, mert azt törölni kell. Abból képzett hash se jó ha minden igaz, mert egyértelműen azonosít embert (ja, az lenne a cél). Szóval ötletek?

IANAL, de ez belefér a “reasonable” adatkezelésbe. “GDPR suppression list” felé érdemes keresgélni.

Ez érdekes kérdés, le tudnád írni bővebben? Van valami online szolgáltatásod, ahonnan bannolod a regisztrált embereket (email blacklistre kerül) és utánna nem léphetnek be vagy ilyesmi?

Online bolt, és vannak nemkívánatos elemek. IP cím alapján nem elégséges a szűrés, de az email cím alapján már elég jól lehet (főleg, hogy a regisztrációkor használt emial címnek a paypal címmel meg kell egyezni, azt meg azért nem lehet csak úgy generálgatni)

Érdekes kérdés, töprengetem rajta egy cseppet :)

Jelenlegi álláspont szerint az email cím lehet személyes adat, ha azonosít valakit (pl.

, elég konkrét), de lehet nem személyes is, ha csak valami fantázia név. Ez nem sokat segít, hasonló az IP logoláshoz, a dinamikus IP mögött nem tudod ki van, de egy megvásárolt fix IP mögött már tudhatod, mégis szükség van arra hogy mindenféle hozzájárulás nélkül tárold a szerven a dolgot. A CJEU állásfoglalása szerint az IP nem személyes adat például (ignorálták a fix IP kérdést). No ez nem sokat segít, csak leírtam érdekességként :)

Gyakorlatibb vizeken a lényegesebb dolog az, hogy a GDPR elismeri a vállalkozás "jogos érdekét", mint jogalapot. Ilyen jogos érdek lehet kiberbűnözés elleni védekezés, így a szerver logok esetében vagy a te esetedben a csalással összefüggő azonosítók tárolása nem jelenthet problémát. Más contextusban (pl telekommunikáció esetén) kifejzetten előkerül a WP29-es útmutatókban a csalás elleni védekezés kapcsán elismert adatkezelés. Annyi kérése van a rendeletnek, hogy a transzparencia legyen meg, azaz az oldalad privacy notification oldalán jelezd a kedves látogatóknak, hogy az e-mail címek tárolásra kerülhetnek, ám _kizárólag_ a visszélések megelőzése érdekében használod azt (és nem spammeled őket). Ha pedig valaki explicit kéri az eltávolítását az adatbázisodból, akkor azt pedig tedd meg...

Még a fix ip mögött sem tudod biztosan garantálni a felhasználó személyét!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Garantálni nem kell, elég ha nagyon valószínűsíthető. Megtörtént eset, hogy a jóember a céges fix IPről meglátogatta a szuper-prémium-mindenre-megoldás-szoftver honlapot, majd másnap kapott egy hívást a cégtől, hogy tudnak-e neki segíteni a döntésben, kell-e extra infó, stb. Ez több adatvédelmi szakértő szerint is erősen problémás, de egyelőre amig marad az CJEU iránymutatás, addig az IP cím nem privát. (Ez alól kivétel, ha tudod azonosítani, pl ISP vagy, esetleg olyan állami szervezet aki ehhez hozzáfér, stb.)

Deleted

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ez kettővel több mint amit az átlagjózsi vagyok ,de azért csalni akarok megtesz.

Kérem?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Az átlag józsi, idáig már nem jut el (látom, van olyan aki több éve csalt, majd megint próbálkozik, de még mindig ugyanaz maradna a paypal email címe).

link
3. (e)
Ha tényleg árt neked az illető, fel kell jelenteni, és addig tárolhatod az adatait :).

"Abból képzett hash se jó ha minden igaz, mert egyértelműen azonosít embert"

Erre tudsz adni valami forrást? Mert mi pont így oldjuk meg a törölt userek nyilvántartását. (User jelzi, hogy törölni akarja magát, megtesszük az éles rendszerből, de a backupokból nem, csak ha vissza kell állítani a backupot. Ehhez viszont valahogy logolni kell, hogy ki a törölt user.)

Ha a fenti állításod igaz, akkor feloldhatatlan ellentmondások keletkeznek a rendszerünkben, és félek, fel fogunk szívódni egy hirtelen keletkezett szingularitásban.

--
Csaba

Ez már eddig is így volt az infotörvény alapján. Mindegy, hogy ID, hash, vagy akármi, amíg egyértelműen beazonosítható az ember, az személyes adat (és a hash egyértelműen azonosítja, mert gyakorlatilag egyedi).

Úgy tudom, ha kérte a törlést (és más törvény miatt nincs ennek akadálya, pl. számla megőrzés), eddig is törölni kellett a backupból, mert nincs külön kezelve a biztonsági mentés a jog által.

Szerintem a hash nem az, mert abból nem tudod megmondani, hogy az kihez tartozik. Még azt sem, hogy emberhez tartozik-e.

--
Ickenham template engine

Olvastam állásfoglalást, ahol kijelentették, hogy a személyes adatból képzett akármi is, amíg egyedien azonosítja az alanyt, ugyanúgy személyes adat. Szerintem a hash-ra is illik ez, mert az oké, hogy az eredeti adat nem visszafejthető belőle, de egyedileg azonosítja az embert.

Pont azért kérdeztem rá, mert mi implementáció előtt lezongoráztuk ezt a céges ügyvéddel, aki azt mondta, hogy a hash nem személyes adat, mert nem állítható belőle vissza az eredeti. Most nagyon ki vagyunk akkor segítve...

Tudsz forrást adni az általad hivatkozott állásfoglalásra? Csak mert ha igazad van, akkor az egész megoldásunk borul.

--
Csaba

Állásfoglalásról én nem tudok, de a working party (a GDPR mögötti tanácsadó testület) wp136-os véleményében a "one-way cryptography"-t is pseudonym adathoz sorolja sajnos. A technológia megoldások értelmezése nem mindig erőssége a GDPR-nak. A hashelés önmagában lehet jó és rossz is. Volt olyan cég, ahol telefonszámokat akartak behashelni, nyilván egy számhoz ugyanaz a hash jön fel az egész adatbázisban, amit összerakva egyéb információkkal már nem biztosított a "nem azonosíthatóságot", tehát rossz megoldás volt. A ti megoldásotok szerintem a jók közé tartozik és nincs a rendelet szerinti fekete/fehér definició.

Egyébként a log, ami alapján újra törölnétek az adatokat recovery után, hash-elés nélkül is elfogadható (mégha átmenetileg olyan személyes adatot tárol amit elvileg törölni kellett volna). Mint ahogy a backup-ban is ott van visszanyerhetően az adat átmenetileg. Ez hozzátartozik a technológiai limitációkhoz. A fontos az, hogy a törlésre jelölt adatok ne kerüljenek további feldolgozás alá, semmilyen körülmények között.

Köszönöm, ez nagyon hasznos. Ezen a dokumentum vonalon indulunk tovább.

--
Csaba

A baj az, hogy ha a user újra jön, akkor ugyanazt a hasht kapja, amivel végső soron azonosítható a korábbi tevékenység.
Egy sima autinc ID-re ez nem igaz, és a célnak tökéletesen megfelel.

Hát figy, mint általában ez úgy van, hogy egyik jogász így értelmezi, másik meg úgy, a hatóság meg harmadik féle képpen.

Sebaj, ha a szerződés szerint a jogász anyagi felelősséggel tartozik, akárcsak a könyvelő, akkor bátran el lehet fogadni az állásfoglalását! :)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

van naponta gzippelt sql dump. abbol hogy torlod utolag? mindegyiket visszatoltod egy testz rendszreen, lefuttatod az sql parancsokat ami kipucolja az osszes tablabola vele kapcsolatos adatokat, aztan ujra lemented? vagy megy az egesz backupod a devnullba? esetleg irsz sed/awk/stb scripteket ami bele kokanyol az sql dumpba?
(a dolog meg izgibb mssql eseten)

Ilyen jellegű backupból nem törlünk, a rendelet "elvárható mértékű erőfeszítést" ír elő. Arról viszont tarthatsz egy log fájlt / jegyzetet, hogy ki kérte, hogy töröljék az adatait és ha a backupból visszaállításra kerül a sor, akkor egyszerűen újra törlöd az élesben (még mielött az adatokat újra elkezdet processzálni). Elöbb utóbb kipörög :)

"Úgy tudom, ha kérte a törlést (és más törvény miatt nincs ennek akadálya, pl. számla megőrzés), eddig is törölni kellett a backupból, mert nincs külön kezelve a biztonsági mentés a jog által."

Itt érzek némi ellentmondást, kimondja a GDPR, hogy ilyen esetben töröljük az adatait a rendszerből, ez pipa, de kimondja egy másik törvény, hogy a mentéseket 10 évig meg kell őriznünk (pénzügyi terület), ez gyakorlatilag megoldhatatlan! (több 100 TB adatról lehet szó, több különböző rendszerből)

A törvények bizonyos esetekre előírnak kötelezően megtartott adatot, de ezeknek a köre elég kicsi, amúgy ez erősebb, mint a felejtéshez való jog.

1. Amíg mindenki boldog, van egy csomó adatod a felhasználóról, semmi gond.
2. A felhasználó kéri a törlést. Törölsz mindent, amit nem muszáj megtartani, amit meg muszáj megtartani, azt nem törlöd.
3. Ha a törvény által előírt idő letelik, törlöd a maradék adatot is.

Azt a GDPR és az eddigi adatvédelmi törvény is mondja, hogyha valamit más miatt meg kell tartanod, akkor azt addig az ideig kezelheted. Pl. a számlát meg kell őrizni 8 évig, azt nem tudod törölni. De mondjuk azt, hogy a preferált vásárlási módja a bankkártya, azt már törölnöd kell.

Egyebkent honnan szedtetek azt a baromsagot, hogy az email hash-et nem lehet tarolni?

Ahogy fentebb írtam a working party (a GDPR mögötti tanácsadó testület) wp136-os véleményében (opinion on personal data) a "one-way cryptography"-t is pseudonym adathoz sorolja. A pseudonym adat pedig, mégha közvetlen nem is értelmezhető, személyes adatnak minősül.

Ennek ellenére lehet az emailt vagy a hasht bizonyos célokkal tárolni (pl az említett backup visszaállítós újra törlés az ilyen). Mint psudonymizáció növeli az adat biztonságát, ezt egy esetleges ellenőrzésnél figyelembe fogják venni, de a hashelés önmagában nem fogja kivonni az információt a rendelet hatálya alól.

Mutass mar egy birot vagy egy auditort aki bebizonyitja, hogy az egy hash, es hogy abbol tudom, hogy milyen emaile. Azert ennyire ne szarjuk mar ossze magunkat. Masik topikban lattam egy gyokeret, aki meg akarta oldani hogy egy query-bol csak egy email johessen ki es ezert dobta volna el az SQL-t. Ennyit mar tenyleg nem er az egesz, inkabb irj egy privacy policy-t, hogy ezeket te minosegbiztositasi okokbol rogzited, keresre anonimizalod (torlod, de a relaciokat meghagyod), de amugy nem adod ki senkinek es kesz.

A "minosegbiztositasi ok" mint olyan, szerinted hova sorolható jogilag, és vajon felulirja-e a személyiségi jog hatályát?..

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A privacy policy-t miota kotelezo elfogadni? Le is lehet lepni az oldalrol, senki nem tart pisztolyt a fejedhez hogy add meg az email cimed.

Raadasul ez nem is GDPR specifikus argument (de anelkul is, meg annak is baromsag). Egyaltalan. Szemelyisegi jogok korabban is leteztek, megis lehoz a SELECT email FROM users ezt-azt valami csoda folytan. A kifejezes amit keresel: szemelyes adat.

Ha a tobbiek is ilyen sotetek a topikban akkor mar ertem mi ez a droidkodas itt.

A jogellenes feltételekkel kötött szerződés semmisnek tekintendő, a hatályos jog ellenében nem köthetsz ki saját feltételeket. A sotetseggel kapcsolatban először is egy kicsit a saját búrádban kellene turkalnod!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Egészen pontosan:

Idézet:
A "2010. évi CXXX. törvény a jogalkotásról" alapján a szolgáltató nem jogalkotó és nem jogforrás. Következményként az ÁSZF/EULA törvényt nem írhat felül.

Még ezer éve olvastam egy adatvédelmi valaki állásfoglalásáról (a témában) született izében, de csak ennyit mentettem el belőle...

Nem minden adathalmaz végtelen. Az adott hashelési eljárásodhoz én is le tudom generálni a hash-eket. Pl. ha magyar lakosok neveit tárolod hashben, fogom a lakossági névjegyzéket, legenerálom a 10M emberre és máris tudom, hogy melyik kihez tartozik... A hash pseudonym adat nagyon sok esetben.

Es ha sozom, es nem mondom meg neked hogy mi alapjan es hogy soztam? Oke, Hunger lehet talalna valakit aki arra is rajonne, de nem olyan fog jonni auditornak. Balfasz meg nem vagyok hogy valaki titoktartasi nelkul dumpolgathassa a db-imet. Es mindenki latta, hogy mindent elkovettem az adatbiztonsag erdekeben.

Lehet hogy a hatóság elfogja fogadni. Azt tudom mondani, hogy az állásfoglalás szerint, az egy irányú titkosítás, sózva is, pseudonym marad, mert ha megszerzik a sót, akkor újra előállítható. Ameddig nem anyonym, addig marad személyes adat.

Valószínű hogy eseti mérlegelés lesz. Volt olyan nagy cég, aki kért állásfoglalást arról, hogy a nagyon titokba tartott kulcs segítségel titkosított backup tekinthető-e úgy, hogy törölve van. És becsszóra csak 2 embernek lesz meg a kulcs. Hatósági válasz született róla, hogy ez nekik megfelel, míg betű szerint értelmezve a szabályt ez tökre nem okés. Arra mondjuk kíváncsi leszek, hogy a NAIHnak lesz-e elég házon belüli kvalifikációja technológiailag helytálló véleményt alkotni a gyakorlatban.

Ennyi erővel hiába tartom titkosítva az adatokat, mert ha megszerzik a kulcsot, el lehet olvasni. Ha azt mondják, hogy így nem jó, akkor nem lehet adatot tárolni.

Lehet adatot tárolni, az eszmecsere itt arról szólt hogy titkosítás vagy hashelés után esetleg már nem számít személyes adatnak, így a rendelet nem érvényes rá. A szűkebb értelmezésbe viszont sajnos marad személyes adat.

Egész pontosan meg kell szerezned:
1. a pontos algoritmust,
2. mely személyes adatokból (és más adatokból, pl. só), mily módon átalakítva kerül hash-elésre.

A legfőbb gond itt azzal van, hogy ahhoz, hogy tudd, hogy melyik hash kihez tartozik, ahhoz neked meg kell szerezned azon személynek a hash-elésben szereplő személyes adatait. Ha valaki meg tudja szerezni egy személy személyes adatait, akkor a hash-el nem lesz előrébb, hiszen már megvannak neki a személyes adatok.

Egy cikkben ezt írták:
"Személyes adatnak ugyanis az olyan információ számít, amely egy azonosítható élő személlyel kapcsolatos vagy éppen az információk összegyűjtése egy bizonyos személy azonosításához vezethet. Ebbe a körbe tartoznak a titkosított vagy álnevesített személyes adatok is, amelyek felhasználhatóak egy személy újraazonosítására. Egyedül az nem képezi a kör részét, amelyet úgy anonimizáltak, hogy az érintett már többé nem azonosítható az alapján, tehát "az anonimizálásnak visszafordíthatatlannak kell lennie" - írja a közlemény."

A hash az egy visszafordíthatatlan anonimizálás, nem?

--
Ickenham template engine

Tételezzük fel, hogy van egy adatbázisod, amiben vannak oszlopok, hogy "családnév" és "keresztnév", benne a hashek. Legenerálom a hash-eket általános nevekre, hogy "kovács", "horváth", "lászló", "géza". Elég egyszerű módszer arra, hogy azonosítsam az adatot. Ennél fogva anonimizálásként nem fogadja el a rendelet, azaz az adat nem vonódik ki a rendelet hatálya alól. (Ettől még persze tárolhatod megfelelő indokokkal.) A pseudonymizálási technológiák, mint biztonsági tényezőt növelő intézkedés elismert a GDPRban, de a lényeg, hogy a hashelt adat is jellemzően személyes adat marad.

Ezt lehet vitatni, ha be tudod bizonyítani, hogy semmilyen technológiai megoldással nem lehet visszaforgatni, személyhez rendelni, a hatóságnak illene ezt elfogadni. De biztos vagyok benne, hogy lesznek esetek, ahol nem lesz elfogadható, pl a példa amít említettem.

"A legfőbb gond itt azzal van, hogy ahhoz, hogy tudd, hogy melyik hash kihez tartozik, ahhoz neked meg kell szerezned azon személynek a hash-elésben szereplő személyes adatait. Ha valaki meg tudja szerezni egy személy személyes adatait, akkor a hash-el nem lesz előrébb, hiszen már megvannak neki a személyes adatok."

Két dolog (minimum) van.
- Az egyik, amit már kolléga írt, hogy simán lehet bruteolni, adott esetben akár rainbowolni egy ilyet. Igen, tudom, só és hasonlók, de látni kell, hogy az csak nehezít, nem lehetetlenné tesz. Az meg, hogy eléggé nehezít-e már nyilván eseti megítélés kérdése. Amiben nincs semmi csoda, a jogrendszer alapvetően így működik, csak itt a gyakorlatban majd nyilván bejön az, hogy jogászoknak kellene felfogni és átlátni olyan dolgokat, ami tipikusan az ITs kollégáknak sem megy zökkenőmentesen. Ebből azért várható némi bizonytalanság. Egyébként ez sem egyedülálló, gyakorlatilag minden műszaki szakértő bevonását igénylő kérdésben többé-kevésbé jelen van ez.

- A másik meg az, hogy a hashelésben simán lehet, hogy kevesebb adat szerepel, mint ami a hash visszafejtésével rendelkezésre áll. Nyilván ilyesmi tipikusan úgy történik, hogy mondjuk a törzsadat tábla sorából lesz hash, ami kb a név, email, stb mentén mozog, de ha ez megvan, akkor az összes kapcsolódó cucc az adatbázisodban hirtelen kiderül, kihez tartozik.

Illetve van még egy harmadik is az ilyen "backupból ezeket a hashűeket nem kell visszatölteni" dolgokkal, hogy aztán ha a user újra regisztrál, azt gondolja, hogy tiszta lappal, aztán vagy leveszed a hasht a listáról, és simán lehet, hogy egy esetleges restorenál visszajönnek törölt dolgai, vagy nem veszed le, és egy esetleges restorenál beszopja. Ez ellen mondjuk azért nem olyan nehéz védekezni, csak ésszel kell hashelni.

> Igen, tudom, só és hasonlók, de látni kell, hogy az csak nehezít, nem lehetetlenné tesz.

Lehet hulyeseg, de mi van, ha a so nem statikus, hanem minden esetben random generalt? Abbol azert mar nehezkesebb visszafejteni, nem?

Hehe, ebből a kommentből most kicsit jobban belegondoltam a buliba, és az van, hogy ez egy kissé spec helyzet. Az általános patterneknél ugyanis a salt az bizony random egyedi, minden elemnél. Nézz csak megy egy /etc/shadow -t mondjuk "$6$bla$blablabla". Itt a 6 a hash algoritmus, az első bla a salt, a többi meg a hash.

Ugye az a dictionary attack meg a rainbow táblák ellen véd valamennyire (egyébként ugyanazért, a rainbow tábla tulajdonképp "csak" egy előre kalkulált dictrionary attack, ha az input halmaz is szar, meg hashelés is), azzal, hogy nem elég minden feltételezett inputot kiszámolni egyszer, és megnézni, hogy van-e passzoló hash valahol, hanem minden lehetséges inputot végig kell számolni az egyedi saltjával minden lehetséges hashra.

Viszont ez csak akkor működik, ha a normális use-caseben van valami, amiből be lehet azonosítani az egy darab vizsgálandó hasht. Ugye tipikusan ilyen a usernév, azt akarjuk megnézni, hogy neki az-e a jelszava ami, fogjuk amit beírt, hozzácsapjuk a saltot a hash elől, hashelünk, ha jó, nyert, ha nem, akkor még kétszer dobhat.

Ellenben így hirtelen nem tudom, hogy mondjuk egy db restore esetén lehet-e olyan adatot találni, ami önmagában nem személyhez köthető, és be tudja azonosítani azt a hasht, amelyiket le kell ellenőrizni, hogy be kell-e tölteni, nem lehetetlen, de azért messze nem olyan triviális.

Ha ilyen nincs, és fix saltot használsz, annak túl sok haszna nincs. Egyetlen, hogy ha a fix saltot ilyenkor nem teszed mellé, hanem azt kvázi mint egy titkos kulcsot kezeled, akkor funkcionalitásában ekvivalens azzal, hogy a saltolatlan hasheid egyébként titkosítva tartod. Hogy biztonsági szintjében is tudja-e ugyanazt, azon erősen el kellene gondolkodnom, addig inkább maradnék a reasonable doubt álláspontján.

Ráadásul ha van olyan info, ami alapján be lehet azonosítani a sort, ami alapján meg lehet nézni a hasht, akkor egyébként a hash elsőre fölöslegesnek tűnik, elég eltenni ezt az infót, és nem betölteni a sorokat, amire passzol. Pl hashelgetés helyett tartani egy listát a users tábla blacklistelt IDjairól.

Pont ilyen támogatsban felkészítésben várnám el a kamarűnak a segítségét.
Csinálnának a főb vállalkozástipusokhoz egy-egy sablont, azzal már azért sokan előrébb lennének.

Most őszintén, a kamara csinál is valamit azon kívül hogy beszedi a tagsági díjat?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Elkölti? :D

Basszus, azt én is el tudnám nélkülük is... :/

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Nálatok nem csinál? Nálunk volt, talán 2x is

"Tisztelt Cégvezető!

Ezúton tisztelettel meghívom Önt a Csongrád Megyei Kereskedelmi és Iparkamara és a Szegedi Tudományegyetem Munkaügyi Kapcsolatok és Társadalombiztosítási Képzések Intézete által szervezett „GDPR - az EU Általános Adatvédelmi Rendelete - minden vállalkozás életét érintő jogszabály” című regionális rendezvényre.

A GDPR minden céget érint, ahol személyes adatokat kezelnek (a munkavállalóké is az), online tevékenységet folytatnak, bármilyen céllal adatbázisokkal foglalkoznak. A papíron lévő adatok is ide tartoznak. Részletes program a mellékletben olvasható.
Időpont: 2018. március 12. (hétfő) 10.00-12.30
Helyszín: Csongrád Megyei Kereskedelmi és Iparkamara Székháza, II. emeleti konferenciaterem
(6721 Szeged, Párizsi krt. 8-12.)

A rendezvényen történő részvétel térítésmentes, azonban előzetes jelentkezéshez kötött. A jelentkezését kérjük, 2018. március 8-ig töltse ki: JELENTKEZÉS

Tisztelettel:

Bács-Kiskun Megyei Kereskedelmi és Iparkamara
Kommunikációs iroda"

Én a héten pont a kamara színeiben próbálok hasonlót tenni, bár ez Győr: http://gymskik.hu/hu/gyor-moson-sopron-megyei-kereskedelmi-es-iparkamara/rendezvenyek/gdpr-konzultacios-workshop-a-gyori-kamaraban-aprilis-12-en-13680

BKIK-el is kerestem a kapcsolatot, de eddig nem válaszoltak.

Nem hinném, hogy probléma lenne egy bármekkora terem megtöltése Budapesten, szerintem igen gyorsan lehetne termet is szerezni hozzá. :)

Mi a véleményed a Git history-ról? Az én véleményem az, hogy itt a megőrzési kötelezettség (nekem bizonyítanom kell tudni, hogy az adott forráskód honnan van, és jogosan van ott) erősebb, mint a felejtés joga.

Ugyanezt a gondolatmenetet követném a Gerritnél (code review adatbázis, belül Git-et használ).

Amit még nem tudok, hogy pl. Jira, Redmine ... stb. esetén is megállhatnak a fentiek, vagy ott mindenképpen törölni kell a usereket ha kérik.

Igen, úgy tűnik érdeklődés van rá, de önerőből nem szívesen szervezek ilyet, ahhoz sürű a menetrend. Majd a héten még koptogatok a BKIK-nál.

A Git-es kérdés kapcsán. Az hogy meglegyen az információ arról, hogy az adott commit-ot ki csinálta, ahogy írtad, a cég jogos érdeke és ez megállja a helyét a JIRA, stb esetén is. Az accountot inaktiválod, de nem kell történelemhamisításba kezdeni :)

Keringenek olyan értelmezések, hogy ha valaki lelép a cégtől, akkor a nevét az összes e-mailből törölni kell, még ha csak CCén volt akkor is vagy hogy a szerződésekről hibajavítóval lehúzod :) Ezek hozzátartoznak a szépen épülő GDPR urban legends katalógushoz. A rendelet explicit azt mondja, hogy elvárható erőfeszítést teszel a törlés érdekében, az említett értelmezések bőven túl vannak ezen és egyébként is teljesen életszerűtlenek.

Erdekes volt az eloadas bar kulon tetszett az "attol fuggetlen, hogy mi itt mit mondunk az semmit sem jelent, a NAIH azt csinal amit akar" felhang.

Ertem en, hogy mi volt a szandek az egesz mogott, miert kell ez az egesz GDPR, de ebben az orszagban ez a penzbehajtasrol fog szolni szerintem...

--

"You can hide a semi truck in 300 lines of code"

Ah, voltak HUPperek \o/

Sajnos a NAIH gyakorlatáról még semmit nem tudunk. Külföldön, ahol már részlegesen megy a GDPR az látszik, hogy a hatóság elúszik az incidens bejelentésekben és külön vegzáló kommandók nincsenek egyelőre. Remélem nem mennek rá a szivatásra. Nekem a NAIH vezetőről egyébként jó benyomásaim vannak, de nyilván átnyúlhatnak felette ha pénzbehajtásra akarják használni. Annyi "jó" dolog azért van a történetben, hogy az adatvédelmi hatóságoknak nemzetközileg is össze kell hangolni, hogy miért és hogyan büntetnek. Ha valami nagyon gerinctelen dolog történik, akkor lehet az EU felé panaszkodni... elviekben. Gyakorlati tapasztalat erről egyelőre nincs.

Az előadást visszük tovább hamarosan Mosonmagyaróvárra, Sopronba. A BKIK egész egyszerűen nem írt vissza (összesen 5 e-mail címen próbálkoztam), úgyhogy Budapest egyelőre nincs tervben :(

Nemide, beneztem

Igen, en legalabb 4 HUPpert lattam az elso 2 sorban. \o/
Az eloadas maga tenyleg jo volt es latszott, hogy sok munka volt benne, hogy az atlag szamara is ertheto nyelven fogalmazza meg a dolgokat.

Aki mar foglalkozott ezzel annak valoszinuleg sok uj dolgot nem mond az eloadas, de segit rendszerbe foglalni a dolgokat.

--

"You can hide a semi truck in 300 lines of code"

Köszi a visszajelzést!

sub

[Troll on]
Az adatkezeleshez kitoltott beleeggyezesi nyilatkozatokat meddig taroljam, es milyen beleeggyezo nyilatkozat kell a tarolasahoz?
Infinite loop
[Troll off]

van valakinek tapasztalata abban, hogy egy email archivalo rendszer hogyan segiti a gdpr-t?

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Hhahahah, sehogy! :D Benne az a sok gonosz e-mail mindenféle személyes adattal. ;) Kimondottan a GDPR ellensége egy ilyen szörnyeteg. :D

--
Tanya Csenöl az új csatorna

nem hinnem, hogy a gdpr ellensege, foleg ha ceges kornyezetre fokuszalunk...

--
A rendszervaltas jeloltjei: https://rendszervaltas2018.hu/

Ha nem is ellensége, de ugyanolyan megoldatlan jogi katyvasz, mint a szalagos backup vagy a suppression list.

Szerintem nem olyan veszélyes a dolog. Az e-mail archiválás növeli az adatok integritását, ebből a szempontból a GDPR barátja :)

Annyira kell figyelni, hogy ez is adatkezelésnek fog minősülni, ergo, te adatfeldolgozó leszel. Az adatfeldolgozó csak olyan adatokhoz nyúlhat hozzá (és olyan módon), amiket a megbízója (az adat kezelő) meghatároz. Azaz, kell hogy legyen egy szerződéses megbízás amiben azt mondja a megbízó cég, hogy: "Figyi én megbízlak az e-mailek archiválásával, aminek keretein belül hozzáférést adok egy csomó érzékeny adatot tartalmazó e-mailhez. Azt kérem, hogy ezek az e-maileket archiváld nekem, úgy hogy mindeközben illetéktelen arcok ne férjenek hozzá. Továbbá kérem, hogy az archiváló rendszer az adatok érzékenységének megfelelő technikai védelemmel legyen ellátva, és kérlek garantáld hogy a céged és szolgáltatásod GDPR előírásoknak megfelelő módon működik."

Ilyesmi :)

ok, koszi. Viszont nem csak szolgaltatoi oldalrol gondoltam a dolgot, hanem arrol, ha egy ceg sajat maga (vesz egy szoftvert, es azzal) vegez email archivalast. Milyen kovetelmenyeknek kell megfelelni maganak a szoftvernek, hogy az gdpr kompatibilis legyen? Vagy gyakorlatilag barmelyik (esszeruen osszerakott) szoftverrel megoldhato a kompatibilitas, mert az elsosorban a ceg folyamatain ill. lepapirozasan mulik?

Ezt te mint software vendor nem annyira tudod eldönteni. Adhatsz garanciákat arra, hogy a te szoftvered ilyen vagy olyan jó adatbiztonság szempontjából, pl auditáltatod vagy vulnerability scan-t csinálsz ilyesmi. Innentől fogva a szoftver használójának kell eldönteni, hogy a szoftvered az ő adatkezeléséhez elég jó-e vagy nem.

Ha mondjuk egy horgászbot bolt használja az archiválódat, akkor az adatok érzékenysége nem túl nagy, kb ki vett horgászbotot. Alapvető biztonság elég. Ha a szoftvered a nemzetbiztonsági hivatal használja ugyanarra a funkcióra, ott már súlyos adatok vannak, amihez már lehet hogy nem elég biztonságos az alkalmazás. De hogy ki mire használja nem tudhatod.

Példa: excelben le lehet jelszavazni a fájlt. Az MS-nek nem fáj a feje amiatt, hogy ez elég-e vagy nem, amikor te beírod az adatokat az táblázatba, neked kell eldönteni, hogy ez most okés-e így vagy sem.

ok, vagom, kosz az infot.

Sehogy, cserébe majd implementálhatsz egy halom funkciót amit senki nem fog használni, de ha nem lesz benne, nem fogod tudni teljesíteni a GDPR-ben leírt követelményeket.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

milyen halom funkciorol beszelsz, amik nelkul pontosan mely kovetelmenyeket nem tudom teljesiteni?

Pl. hogyan implementáld a random jogi változásoknak megfelelő, teljesen életszerűtlen törlési funkciókat.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

tulzonak tartom a tobbes szamot a 'torlesi funkciok'-nal. Egy bizonyos torles azonban mar van benne: az auditor role-lal rendelkezo userek kepesek leveleket torolni az archivumbol...

Persze, csak aztán majd jön a mindenféle légből kapott X nap, midnenhonnan, irgumburgum, még a backup backupjából is jellegű, technológiailag nehezen kivitelezhető és egyébként is életszerűtlen jogi dolgok.

Egyébként ilyen szempontból amire még nagyon sokan nem godnolnak az például a logok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Még másfél éve voltunk egy egy áttekintő napon GDPR témában. Ott az volt a mondás, hogy az "élő adatokból", kell törölni. Egy naplózás vagy mentés egyébként még egyéb jogszabályi megfelelőséghez is kellhet. Ami a trükkös, az a mentésből visszaállításkori törlése a közben törölteknek, viszont akkor valahogy tárolni kell, hogy kit töröltél... :)

Ami a trükkös, az a mentésből visszaállításkori törlése a közben törölteknek, viszont akkor valahogy tárolni kell, hogy kit töröltél...

Ahogy fentebb említettem, nálunk pont ez van. Úgy oldottuk meg, hogy a usereket egyedi, random IDvel azonosítjuk (amit nem a user saját adatából generálunk, hanem timestampből), a törölt usernek csak az ID-ját tároljuk, és backup visszaállítás esetén az ID alapján töröljük őket a visszaállított éles rendszerből. A mi jogászunk állásfoglalása szerint az ilyen módon generált ID anonim adat, ezért nem vonatkozik rá a GDPR (személyes adatokra vonatkozó része).

Egyébként a jelen thread alapján futottam újabb köröket a cégben, de úgy tűnik, ez jó megoldás.

--
Csaba

Ez teljesen jó, de a korábbi hozzászólásban, csak az adat hasheleését írtad, ezzel bevittél minket egy kicsit a málnásba :) Úgy értelmeztem, hogy valami személyes adatot hasheltek, és az alapján töröltök. De ha van egy ilyen random jellegű userID, aminek nincsen tartalmi kapcsolata személyes adattal, az sokkal jobb. Én is úgy gondolom, hogy ez bőven megfelel.

Bocs, nem volt szándékos. Igazából közben kellett megkérdezni a kollégát, aki írta a kódot a user id generálására, számomra onnan derült ki ez a részlet. Kösz a segítségért.
--
Csaba

csak aztán majd jön a mindenféle légből kapott

ez megalapozatlan es folosleges panikkeltes. Masfelol a vilag civilizaltabb reszen vannak torvenyek, jogszabalyok, whatever, de legbol kapott dolgok nincsenek.

A logok az jo kerdes. Elso lepeskent ossze kell szedni, hogy egyreszt mit loggolunk, masreszt hogy azt hogyan kezeljuk (meedig taroljuk, ki fer hozza, stb)...

--
'Amikor az embernek rossz szerencséje van, az rossz szerencse' - Best of Leekens, a foci feltamasztoja (muhahaha)

sub

Nálam ma éppen a kamerák és a felvételek rögzítés, azok kezelésének kérdése volt soron a GDPR felkészülés kapcsán.

--
trey @ gépház

Vajon mi lesz a GDPR-hez a first amendment? :P

Az első már készül: ePrivacy Regulation néven elhíresült, lesz benne némi sütizés, marketing megkeresésekről infó és még néhány más. Eredeti terv szerint május 25 ez is, de eléggé meg vannak csúszva az elfogadással.