GDPR Hasznos Holmik - bevezető gondolatok
GDPR Hasznos Holmik – bevezető gondolatok
Elindítottunk egy kis videó-sorozatot, ahol olyan eszközöket szeretnénk bemutatni, amelyek nem csillagháborús rendszerek, egy-egy jól körülhatárolható problémára fókuszálnak, és amelyekkel növelhető az általános IT- és információbiztonsági felkészültség.
Na meg persze, jók GDPR ellen is arra, hogy a GDPR szempontjából releváns IT- és üzemeltetési folyamatokat kicsit meg tudjátok erősíteni.
Hol szerepel az IT biztonság a GDPR-ban?
Legmarkánsabban a 32. cikk foglalkozik vele, minden konkrétum nélkül. Ezt azért fontos kimondani, mert amikor az IT sales (nem te) megkezdi udvarlását, sűrűn emlegeti a GDPR-nak való megfelelőséget (hiszen ma semmit nem lehet eladni, ami nem jó „GDPR ellen”).
Lássuk, mi minden jó tehát a GDPR ellen (Jellemzően ezek újonnan beszerzendő eszközök, ha van meglévő eszköz, az lehet, hogy nem jó, és ha nem jó, akkor kockáztatod a 20 millió EUR büntetést :))
- Tűzfal,
- IDS/IPS
- Vírusvédelem
- Privilégizált felhasználók felügyelete
- Fejlett malware- és APT védelem
- DLP
- Wi-Fi
- Storage
- Adatbázis
- Titkosítás
- Mentés/archiválás
- Naplózás
- Beléptetés
- Több faktor
- Ticketing
- Bármi, amiben van Mesterséges Intelligencia
Szóval igazából mintha minden új eszköz jó lenne a GDPR megfelelőség eléréséhez.
Nézzük azt a 32. Cikkelyt:
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.
Fordítsuk le kicsit a jogi szöveget, hogy halandó IT-s is megértse
(1) Ha tárolsz és kezelsz személyes adatot, a tevékenységed és a tevékenységedet fenyegető kockázatok (és mellékhatások) figyelembe vételével alkalmazz (üzemeltess, használj, szerezz be, fejlessz) műszaki és adminisztratív védelmet és valósíts meg átlátható folyamatokat annak érdekében, hogy a kezelt adatok biztonságban legyenek. Ilyen védelmek lehetnek pl:
a) a személyes adatok álnevesítése és titkosítása (hiszen, ha már nem következtethető belőle ki a személy, akkor már nem személyes adat)
b) Gondoskodj az adatok sértetlenségének, rendelkezésre állásának és bizalmasságának feltételeiről (ahogyan azt egyébként a saját tulajdonú titkos, bizalmas, érzékeny adataiddal amúgy is teszed!)
c) Rendelkezz olyan műszaki képességgel, hogy ha valami baj történik, pl. elszállnak az adatok, akkor helyre tudj állni, és a személyes adatok újra rendelkezésre álljanak a kellő időben (ahogyan a saját tulajdonú adataid esetében amúgy is rendelkezel ilyen képességgel)
d) Ha már valami műszaki védelmet alkalmazol, vagy folyamatokat használsz, nem árt meggyőződni arról (és rögzíteni az eredményeket), hogy a műszaki védelem egyáltalán működik, illetve a folyamat valóban azt az eredményt hozza, emit elvártál amikor megtervezted a folyamatot.
(2) Amikor műszaki vagy adminisztratív védelmet tervezel, mérd fel a kockázatokat, tartsd szem előtt a bizalmasság, sértetlenség és rendelkezésre állás elveit, minden folyamatban (tárolás, hozzáférés, továbbítás, kezelés, stb.) tedd fel a kérdést, hogy az adott lépés milyen hatással van az adat bizalmasságára, sértetlenségére és rendelkezésre állására.
Mintha ismerős lenne
Ha megnézzük a rögtönzött fordítást, az a rémisztő gondolat juthat eszünkbe, hogy baszki, annyira nagyon meglepő dolgokat nem is vár tőlünk ebben a pontban, sőt, mintha a sima IT- és információvédelem is ugyanezeket várná el tőlünk: a számunkra fontos adatok sértetlenségének, rendelkezésre állásának és bizalmasságának biztosítását.
Ezen a szálon tovább lépve belátható, hogy a GDPR és a hatókörébe tartozó személyes adatok nem jelentenek új adatosztályt a számunkra, inkább a „Bizalmas” adatosztályon belül egy adatminőséget, adatjellemzőt jelentenek – rájuk vonatkozó kontroll intézkedésekkel.
Nade a „Bizalmas” adatosztályhoz tartozó adatokat nem véletlenül soroltuk be "Bizalmasnak", azokra (elvileg) kontroll intézkedéseket hoztunk, legalább azt, hogy ész nélkül ne küldözgessük/publikáljuk/továbbítsuk – csak oda és akkor, amikor és ahova kell.
Szóval akkor felmerülhet a kérdés, hogy ha már eleve védjük a "Bizalmas" adatokat, akkor miért is kellene új eszközöket beszerezni egy már meglévő és most is védett adatosztályhoz tartozó adat védelmére?
Na?
Kivétel erősíti...
Természetesen azért nem teljesen ilyen egyszerű a kép, van néhány „elmebeteg” – és emiatt technológiailag vagy irdatlan költség mellett, vagy egyáltalán nem megvalósítható dolog a GDPR-ban.
Ennek ékes példája a törlésekkel kapcsolatos rendelkezés, pontosabban „A törléshez való jog („az elfeledtetéshez való jog”) – 17. cikk.“. Most hagyjuk, hogy vannak adatok, amiket azért nem lehet törölni, mert törvényi előírás az 5-10-25-50 éves megőrzés, amit ilyenkor fel szoktak hozni, hogy akkor ez azt jelenti, hogy ha valaki kéri a törlést, akkor nekem elő kell szedni az archivált szalagokat és az adatbázisokból ki kell törölni a vonatkozó személyes adatokat?
Igen azt jelentené, de ez technológiailag több okból sem megvalósítható.
Egyrészt az alkalmazások nem így lettek fejlesztve, ha adatbázisból kitörölnek adatokat, az az egész adatbázis integritására káros hatással lehet, másrészt meg egy ilyen művelet időben és munkafolyamatban is aránytalan terhet jelent a Szervezetre.
Én a magam részéről azt gondolom (és erre célozgat a GDPR is), hogy ha valami nem, vagy csak aránytalan költség mellett megvalósítható, akkor sajnos azt maradványkockázatként viselni kell (nyilván azzal, hogy akkor meghozunk olyan adminisztratív intézkedéseket, amelyekkel csökkenthető a kockázat). Meg kell tenni, amit lehet, de amit nem lehet, vagy nem vagyunk képesek megtenni, azzal nincs értelme foglalkozni.
A Hatóság (szerintem) amúgy sem ezt fogja vizsgálni, ennek műszaki ellenőrzésére semmiféle lehetősége nincs, és szerintem nem is lesz. Ráadásul értelme sincs ezt vizsgálni, amikor ezer más sebből véreznek a Szervezetek, minek ezzel bajmolódni, amikor egy NAIH kolléga néhány kiló papír bekérése és elolvasása után amúgy is bőven talál megállapítani valót (és akkor ne beszéljünk arról, hogy távolról egy weboldal átnézése, egy ügyfélszolgálat felhívásával bőven talál(hat) megállapítani valót).
Nyilván ennek a szélsőséges archiválásos/mentéses példának is lehetne műszaki megoldása – ha a rendszereket már eleve így fejlesztették volna. Egyébként azt viszont markánsan elvárja a GDPR, hogy az új fejlesztésű rendszereknél már a tervezéskor figyelembe kell venni ezeket az elveket, szóval ott már nemigazán menthető a dolog, de a meglévő rendszerek esetében szerintem ezt a példát el kell engedni.
(A példánál maradva, ha nem tudjuk törölni az archiválásból a személyes adatot, akkor biztosítsuk, hogy a szalagokhoz csak a megfelelő személy, csak felügyelet mellett, csak adminisztrálva, visszakereshetően, ellenőrzötten férhessen hozzá, ne állíthasson helyre csak ellenőrzötten adatokat a szalagról. Ez nem oldja meg a problémát, de csökkenti a bizalmasságra leselkedő kockázatot, és a nap végén a NAIH azt fogja vizsgálni, mit tettél annak érdekében, hogy az adatok biztonságban legyenek, és mit tettél annak érdekében, hogy megvédd az adatot).
Összefoglalva: néhány szélsőséges (és szerintem nem átgondolt) rendelkezés/elvárás kivételével, az IT oldalról a GDPR „megfelelőség” a legegyszerűbben úgy értelmezhető, hogy a személyes adatokra biztosítani kell a bizalmasság, sértetlenség és rendelkezésre állás szent hármasát – pontosan ugyanúgy, ahogyan azt a saját, szenzitív adatainkkal kapcsolatban is meg kell(ene) tennünk.
