Mi is az a GDPR? Nem tudom pontosan, de be merem vallani. Ahogy most látom egy felkapott szókapcsolat, ami kapcsán végtelen pénzt lehet elégetni az év során. Ezzel kapcsolatban számos ötletet lehet találni a Blog oldalai között is.

Tények szintjén egy törvény (EU 2016/679 és 2016/680 – ez nem törvény, de együtt járnak), ami hazánkban, mint EU tagországban is érvényes, s rövidesen hatályba lép. A szövege magyar nyelven is elérhető, s eredendően egy másik jogrendben történt, angol nyelvű törvény fordítása. Hazai értelmező dokumentumok nagyon limitáltan érhetőek el hozzá, külföldi munkacsoportok nagyobb már nagyobb erőforrásokat fektettek a megfejtésébe. Az értelmezés és a pontos bírságolási gyakorlat sem ismert még. (Pl. kire érvényes? 2003/361/EK bizottsági ajánlás mellékletének 2. cikkét ki említette a téma kapcsán?) A törvény 2016.05.24-én lépett hatályba.

A köznyelvben forog a 20.000.000 EUR vagy 4% büntetési tétel – ami egy elméleti plafon lehet. Jól megfogható és azonnali fejlesztésre ösztönöz. A törvénynek e mellett azonban fontos része, hogy eredeti célja a privacy by design – ebből fakadóan van egy fele ekkora fenyegetéssel járó tétel is. Az akkor lép érvénybe, ha nem foglalkozom az egész dologgal. Más szavakkal: akkor is megbüntethetnek, ha nem történik feltárt adatszivárgás, de nem is érdekelt a dolog. Ugyanígy igaz, ha megveszem a legdrágább gyártói megoldást, akkor is megbüntethetnek, ha nem tudom megmondani, miért vettem meg.

Számtalan nagy építőkocka elérhető a piacon és a kereslet is hatalmas. Gondolkozzunk egy kicsit, mielőtt kártyavárat építünk. Gyártóink közül – különös módon – a CISCO szintén ezt javasolja. Egy jó megközelítés lehet menedzsment oldalról, elemzéssel megközelíteni a problémát. Fontos másik kitétel, hogy nemcsak az elektromosan tárolt informatikai adatokról van szó, hanem minden adathordozóról, így a papírról is (pl. HR akta)!

Van egy új, kötelező érvényű külső szabályozás. Nézzük meg, milyen hiányosságaink vannak, mely feltételeket nem teljesítjük – biztos lesz ilyen terület (ha nem, akkor kérjünk prémiumemelést!). Így mérlegelni kell a nem-megfelelés költségeit – nincs mit mérlegelni, direkt ilyen magasra emelték a limiteket a GDPR kapcsán. Azaz kénytelenek leszünk foglalkozni vele.

Vezessünk be egy általános megoldást – mindenre jó, a gyártó is megmondta. Ettől még a mi felelősségünk, hogy az valóban megfelelő-e. Másik veszélye, hogy előfordulhat, hogy sokkal nagyobb területet lefedve vezetem be a megoldást, mint amennyire szükséges lenne. Például 3000 felhasználóra teljes DLP-t 20 felhasználó helyett. Még van időnk, egyeztettünk, s próbáljuk meg kitalálni, mi is lehet a célunk. Amennyiben ezt dokumentáljuk is, akkor máris lesz mit megmutatni a NAIH ellenőreinek, mint „folyamat bizonyítékot”.

Kire érvényes?

Aki EU állampolgárhoz kapcsolódó személyes adatot (PII) tárol, feldolgoz, felhasznál – nemcsak Európában. Személyes adat további értelmezésig bármi lehet – email cím, vállalati telefonszám, használt IP cím, hely, hagyományosan személyes adatnak tekintett adatok. Egyes gyártói kommunikációk mást-és-mást vesznek ki a hatályból – de az nem az EU és nem a NAIH. Ezzel szemben EU határozat, hogy a hálózati elérés során kapott ideiglenes IP cím személyes adat. (Emlékszik még valaki az adatok kötelező tárolását előíró EU direktívára? 2006/24/EK 2006.03.15 – 2014.08.15. Az Írek okosak voltak.) Külön kiemeli, hogy a profilozáson alapuló beazonosítás is a hatályba tartozik. Szóval nem lehetünk biztonságban.

DPO – új poszt, de kell az nekünk? Nem egyértelmű. Illetve kicsit az. 250 alkalmazott felett kötelező, alatta pedig az adatok besorolása alapján dől el. Mi is az a besorolás? Érdekes kérdés, nézzük meg!

Gyakorlatban – elvben – a kockázatelemzésünk alapjai között található egy vagyonleltár az adatgazdák kijelölésével. Én valahol itt kezdeném a felkészülést. Felmérném, hogy mely területek – mely adatgazdák esetén – szembesülünk személyes adattal. Például HR, könyvelés, marketing, pénzügy és utalások, egyéb területek. Most jöhet a GDPR legkellemesebb része, vegyük elő a PIÁ-t! Hatáselemzést kell végeznünk a GDPR értelmében, s be kell sorolni ezeket az adatokat. Így már nem kell minden területen mindent védeni, elegendő csak a 3-ból a legmagasabbra koncentrálni, a többire folyamatos fejlesztési folyamat közben – már ha kérdezi valaki – időszakosan visszatérni. Ezek alapján módosíthatom vagy kiegészíthetem a klasszifikációt a leltárban. A személyes adatokra kiemelt kockázatot jelentő területekre fokozottan rá kell koncentrálni. Hol is láttam hasonlót … igen! A PCI DSS kapcsán már többször hatásosan lehetett manipulálni a feladatot. Szerintem itt is lehet alkalmazni, azaz próbáljuk meg korlátozni a GDPR területi hatályát, így csökkentve a költségeket.

A folyamataimat is át kell néznem, mert számos változás történt, például „cselekedni” kell a felhatalmazáshoz, azaz lehet, hogy újra kell rögzíttetnem pár adatot vagy még idén ismételt hozzájárulást kell kérnem. A bekerülés mellett az életutat is szabályozza a GDPR – kiterjesztett jogokat kap a személy. Ezeket a jogokat érdemes átnézni és átvezetni a folyamatokban! Van pár érdekes, akár NP-teljes is közöttük.
„Mutass meg minden fájlt, papírt és adatrekordot, ahol rólam van adat” – szerintem ez nehéz feladat, ha szó szerint szeretném értelmezni. Jelentős mennyiségű metaadattal kell kiegészítenem minden jelenlegi rendszeremet. Pl. melyik banki átutalási csomagban szerepel a GIRO számom 5 évre visszamenőleg minden példányt, a mentéseket is beleértve?

„Mutasd meg, ki és hogyan férhet hozzá bármelyikhez” – ó, ez könnyű feladat, role-based elérési szabályozásom alapján egy egyszerű lekérdezés az IAM Auditor moduljából. Vagy nem. Előző pontban felmértem az érintett fájlokat, már csak a követésüket kell megoldanom. Itt lehet több elkerülő megoldásom is, például:

• tartalmi jellegű naplózás, minden PII tartalom követése tároláskor, mozgásban, stb. DLP vagy IRM megoldások
• jogosultságok elemzése, fájlok követése – fájl audit megoldások az adott területekre és üzletágakra
• naplózás és kiértékelés – audit megoldások telepítése, lehetőleg célzottan. Detektív kontroll, de sokat segít. Célmegoldások jelentősen olcsóbbak egy SIEM kiépítésénél, bővítésénél.

„Ki és mikor fért hozzá” – korábbi pontban megadott megoldások választ adhatnak erre is.

„Mi történik, ha nem jogosult?” – ez már incidens. Ne feledjük időben jelenteni!

„Töröld ki ezt-és-ezt” – itt ismét tanácstalan vagyok. Pl. a nyugdíj-meghatározáshoz szükséges jelentéseket végtelen ideig meg kell őrizni, egyéb bizonylatok esetében is 10+ évekről lehet szó. Ezek után jön a delikvens, s kéri adatainak törlését – és azt most hogyan?! Ha anonimizálom, akkor már lehet, hogy nem használhatom eredeti céljára.

„Automatikusan töröld ki (lejárat)” – lásd fentit. Piroska a radírral naponta végigmegy minden archivált aktánkon.

„Anonimizáltan kezeld” – GDPR eredeti célja során jó ötlet, de mi is sokat kamatoztathatjuk!

„Adj át minden adatot és töröld a rendszeredből” – korábbi pontokban már érintettem.

Felmerülő további kérdések

Mentésben nincs benne? Biztos észrevettem, hogy kimásolták? Van felügyeletem felette? Nem vezettek „fekete” nyilvántartást? Shadow-IT és felhő oldal – telefonok mentései is – teljesen ismert előttem?

Szerintem e kérdések kapcsán még jól jöhet, ha dokumentálom döntéseimet és azt be tudom mutatni az ellenőröknek: én mindent megtettem és a szervezet is, hogy megfeleljünk, de éppen erre nem gondoltunk. Felvesszük a listára, s kiértékeljük a következő körben.

Javaslom még az egyes ajánlatok tartalmának visszaellenőrzését a törvény szövegével szemben, illetve a pontos szövegkörnyezet értelmezését. Egyik kiemelt példám tud lenni a titkosítás. Szerepel egy olyan kósza példa, hogy amennyiben az adatok egy titkosítva kerültek tárolásra és ellopták őket, akkor én mindent megtettem, nincs problémám. Ez a szövegkörnyezetben: „amelyek a személyes adatokhoz való hozzáférésre fel nem jogosított személyek számára értelmezhetetlenné teszik az adatokat”, s a példa az USB kulcsra vonatkozott. Azaz ha titkosítva volt az adatállomány a tárolón és a tárolót ellopták – ennek ellenére a teljes titkosítást jó megoldásnak ítélik. Védelmi értéke is van: a támadó besétál, s a hátán a titkosított storage rendszeremmel kisétál. Lényegében az értelmezhetetlenségen van a hangsúly, tehát ha titkosítottan tárolom az adatokat, de a másolás a titkosítás feloldása után a rendszerből történt meg, akkor nagy bajban lehetek, mert: nem tudom megmondani, ki mikor mit és milyen céllal másolt ki, hiszen erre a teljes titkosítás nem ad megoldást.

Hasonló megoldás a külső szolgáltató vagy szolgáltatás igénybe vétele – hiszen az közkedvelt és elfogatott költség és kockázat csökkentő megoldás. Itt minden esetben kövessem le PII életútját! DLP kapcsán is probléma lehet, ha megjelenik a DLP logban a PII, mint talált – ekkortól a DLP rendszerem is GDPR magas kockázati besorolású rendszer lesz az összes üzemeltetővel. A külső naplóelemzés során is kikerülhet PII adat, s innentől már én felelek a szolgálató törvénysértéseiért is. Itt egy furcsa megoldást tudok javasolni: formátumtartó anonimizálást minden kikerült adatra. Így a szolgáltató jelezni tudja a problémát, GDPR értelemben zárni tudom a folyamatot, de mégsem került ki adat. A tokenizálás jó megoldás lehet minden határfelületen a scope csökkentésére. Ismert olyan SIEM megoldás, ami hordozza ezt a képességet.

Fontos ugyanakkor, hogy a költség-haszon elemzés elve itt is megmaradt, így jogom van konzultálni a hatósággal (36. cikk), ha túl nagy költséget jelentene a védekezés megvalósítása.

Személyes véleményem alapján a GDPR, mint a szociális hálózatokat és mamut adatkezelőket („Facebook és Google törvény”) regulázni akaró valami célt érhet. Számos pozitív hozadéka lehet általános gazdasági környezetekben is, ugyanakkor vállalati szinten bizonyos esetekben túlszabályozottságot mutat. Én például a kapott névjegykártáyk adatait alapból alacsony szintre tenném, s eltekintenék a részletes követésüktől minden szinten – kivéve, ha azokat direkt marketing adatbázisban is alkalmazni akarom. Kinek kell tudnia róla? Mindenkinek és a kiemelt területeknek részletesebben. Folyamatos és célzott tudatossági képzésekre lesz szükség, hogy csökkentsük az eddig ismeretlen gyakorlatból adódó kockázatokat. Valamint a cégünk adatkezelési nyilatkozatát alaposan nézzük át, s amennyiben még nem tettük meg, tegyük elérhetővé a honlapon.

Idézetek – szövegkörnyezetből kiemelve

(14) A természetes személyeket a személyes adataik kezelésével kapcsolatban e rendelet alapján nyújtott védelem állampolgárságuktól és lakóhelyüktől függetlenül megilleti. E rendelet hatálya nem terjed ki az olyan személyes adatkezelésre, amely jogi személyekre, illetve amely különösen olyan vállalkozásokra vonatkozik, amelyeket jogi személyként hoztak létre, beleértve a jogi személy nevét és formáját, valamint a jogi személy elérhetőségére vonatkozó adatokat.

(27) Ezt a rendelet nem kell alkalmazni az elhunyt személyekkel kapcsolatos személyes adatokra. A tagállamok számára lehetővé kell tenni, hogy az elhunyt személyek személyes adatainak kezelését szabályozzák.
(28)A személyes adatok álnevesítése csökkentheti az érintettek számára a kockázatokat, valamint segíthet az adatkezelőknek és az adatfeldolgozóknak abban, hogy az adatvédelmi kötelezettségeiknek megfeleljenek. Az „álnevesítés” e rendeletbe történő kifejezett bevezetése nem irányul más adatvédelmi intézkedés kizárására.

(30) A természetes személyek összefüggésbe hozhatók az általuk használt készülékek, alkalmazások, eszközök és protokollok által rendelkezésre bocsátott online azonosítókkal, például IP-címekkel és cookie-azonosítókkal, valamint egyéb azonosítókkal, például rádiófrekvenciás azonosító címkékkel. Ezáltal olyan nyomok keletkezhetnek, amelyek egyedi azonosítókkal és a szerverek által fogadott egyéb információkkal összekapcsolva felhasználhatók a természetes személyes profiljának létrehozására és az adott személy azonosítására.
(44) Az adatkezelés jogszerűnek minősül, ha arra valamely szerződés vagy szerződéskötési szándék keretében van szükség.
(76) Az érintett jogait és szabadságait érintő kockázat valószínűségét és súlyosságát az adatkezelés jellegének, hatókörének, körülményeinek és céljainak függvényében kell meghatározni. A kockázatot olyan objektív értékelés alapján kell felmérni, amelynek során szükséges megállapítani, hogy az adatkezelési műveletek kockázattal, illetve nagy kockázattal járnak-e.

(77) A megfelelő intézkedéseknek az adatkezelő vagy adatfeldolgozó általi végrehajtásához, valamint a megfelelés általuk való bizonyításához – különösen ami az adatkezeléssel kapcsolatos kockázat beazonosítását, valamint a kockázat forrásának, jellegének, valószínűségének és súlyosságának a felmérését illeti –, továbbá a kockázat mérséklésével kapcsolatos bevált gyakorlatoknak az azonosításához útmutatással szolgálhatnak különösen a jóváhagyott magatartási kódexek, a jóváhagyott tanúsítási eljárások, a Testület iránymutatásai vagy az adatvédelmi tisztviselő által nyújtott iránymutatások. A Testület emellett iránymutatásokat adhat ki az olyan adatkezelési műveletekre vonatkozóan is, amelyek valószínűsíthetően nem járnak magas kockázattal a természetes személyek jogaira és szabadságaira nézve, és megadhatják, hogy ilyen esetben mely intézkedések elegendők a szóban forgó kockázat kezeléséhez.

(83)A biztonság fenntartása és az e rendeletet sértő adatkezelés megelőzése érdekében az adatkezelő vagy az adatfeldolgozó értékeli az adatkezelés természetéből fakadó kockázatokat, és az e kockázatok csökkentését szolgáló intézkedéseket, például titkosítást alkalmaz. Ezek az intézkedések biztosítják a megfelelő szintű biztonságot – ideértve a bizalmas kezelést is –, figyelembe véve a tudomány és technológia állását, valamint a végrehajtás kockázatokkal és a védelmet igénylő személyes adatok jellegével összefüggő költségeit. Az adatbiztonsági kockázat felmérése során a személyes adatok kezelése jelentette olyan kockázatokat – mint például a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítése, elvesztése, megváltoztatása, jogosulatlan közlése vagy az azokhoz való jogosulatlan hozzáférés –mérlegelni kell, amelyek fizikai, vagyoni vagy nem vagyoni károkhoz vezethetnek.

(94) Ha az adatvédelmi hatásvizsgálat azt jelzi, hogy a kockázat mérséklését célzó garanciák, biztonsági intézkedések és mechanizmusok hiányában az adatkezelés magas kockázattal járna a természetes személyek jogaira és szabadságaira nézve, és az adatkezelő véleménye alapján a kockázat nem mérsékelhető a rendelkezésre álló technológiák és a végrehajtási költségek szempontjából észszerű módon, akkor az adatkezelési tevékenység megkezdése előtt a felügyeleti hatósággal konzultálni kell. Valószínűsíthetően ilyen magas kockázattal járnak a személyes adatok kezelésének bizonyos típusai és az adatkezelés bizonyos mértéke és gyakorisága, amelyek emellett kárt is okozhatnak, illetve hátrányosan érinthetik a természetes személy jogait és szabadságait. A felügyeleti hatóság a konzultáció iránti megkeresésre meghatározott határidőn belül választ ad. Ha azonban, a felügyeleti hatóság az említett határidőn belül nem reagál, nem érinti a felügyeleti hatóságnak az e rendeletben megállapított feladataival és hatásköreivel összhangban álló beavatkozási jogkörét, az adatkezelési műveletek megtiltására vonatkozó hatáskörét is beleértve. E konzultációs eljárás során a szóban forgó adatkezelés tekintetében végzett adatvédelmi hatásvizsgálat eredményét, és különösen a természetes személyek jogait és szabadságait veszélyeztető kockázat mérséklésére szolgáló intézkedések tervezetét be lehet nyújtani a felügyeleti hatóságnak.

(158) E rendeletet az archiválási célokat szolgáló személyes adatok kezelésekor is alkalmazni kell, szem előtt tartva, hogy e rendelet nem alkalmazható elhunyt személyek személyes adataira. …

19. cikk A személyes adatok helyesbítéséhez vagy törléséhez, illetve az adatkezelés korlátozásához kapcsolódó értesítési kötelezettség – Az adatkezelő minden olyan címzettet tájékoztat a 16. cikk, a 17. cikk (1) bekezdése, illetve a 18. cikk szerinti valamennyi helyesbítésről, törlésről vagy adatkezelés-korlátozásról, akivel, illetve amellyel a személyes adatot közölték, kivéve, ha ez lehetetlennek bizonyul, vagy aránytalanul nagy erőfeszítést igényel. Az érintettet kérésére az adatkezelő tájékoztatja e címzettekről.

2. szakasz Adatbiztonság 32. cikk 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:

42. cikk Tanúsítás (1) A tagállamok, a felügyeleti hatóságok, a Testület, valamint a Bizottság – különösen uniós szinten – ösztönzik olyan adatvédelmi tanúsítási mechanizmusok, valamint adatvédelmi bélyegzők, illetve jelölések létrehozását, amelyek bizonyítják, hogy az adatkezelő vagy adatfeldolgozó által végrehajtott adatkezelési műveletek megfelelnek e rendelet előírásainak. Figyelembe kell venni a mikro-, kis- és középvállalkozások sajátos igényeit.

99. cikk Hatálybalépés és alkalmazás

(1) Ez a rendelet az Európai Unió Hivatalos Lapjában való kihirdetését követő huszadik napon lép hatályba.

(2) Ezt a rendeletet 2018. május 25-től kell alkalmazni.

Ez a rendelet teljes egészében kötelező és közvetlenül alkalmazandó valamennyi tagállamban.

Kelt Brüsszelben, 2016. április 27-én.
L119/88 HU Az Európai Unió Hivatalos Lapja 2016.5.4.