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:

 Fordítsuk le kicsit a jogi szöveget, hogy halandó IT-s is megértse

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.

Forrás: http://kiber.blog.hu/