Ha IT oldalról nézzük, a GDPR-ban két technológia kerül nevesítésre, minden más technológiára csak burkolt célzást tartalmaz a 32. cikk.

Az álnevesítés és a titkosítás rossz nyelvek szerint azért került konkrétan megnevezésre, mert a 6 évig a GDPR szövegén dolgozó jogászok együttesen és mindösszesen ennek a két technológiának a nevével voltak tisztában.

Nézzük tehát a titkosítást

Az ESET vírusvédelmi gyártó szerint a titkosítás:

A titkosítás az információ oly módon történő kódolása, hogy azt illetéktelen személyek ne legyenek képesek elolvasni. (https://encryption.eset.com/hu/mi-az-a-titkositas/ )

A több oldalról is borzasztóan pongyola megfogalmazás (és szeretném a kriptós kollégákat megkérni, hogy ne köpjenek le mert idézem), de alighanem ezt értették meg a GDPR rendelet megalkotói, ezért szerintem fogadjuk el ezt a definíciót – de kicsit megfordítva.

A titkosítás az információ oly módon történő kódolása, hogy azt csak az arra jogosult személyek legyenek képesek elolvasni.

A titkosítás ugyanis a GDPR 32. cikk b. pontjában szereplő „bizalmas jelleg” – azaz a bizalmasság teljesülésének feltételét biztosítja. Az információt csak az olvashatja el, aki arra jogosult (mert rendelkezik olyan eszközzel/eljárással/jelszóval/kulccsal, amely ezt lehetővé teszi a számára).

Mikor kell a GDPR szerint titkosítást alkalmazni?

A GDPR egyáltalán nem rendelkezik erről konkrétan.

A 32. cikk 1-es pontja beszél arról, hogy az adatkezelés kockázatait figyelembe véve kell a megfelelő biztonsági szintet meghatározni.

Tehát, ha úgy gondolod (ne gondold, mérd fel, és írd le!), hogy az adott adatkezelési folyamatot nem fenyegeti olyan mértékű kockázat, hogy indokolt lenne részedről (a költség és egyéb vonzatokra tekintve) titkosítást alkalmazni – akkor ne alkalmazz titkosítást.

Nézzünk erre példát (DPIA/BIA-s kollégák szintén ne köpjenek le, próbálom közérthetően megfogalmazni).

A CRM/ERP rendszerben kell-e titkosítanod?

Működés:

A CRM/ERP rendszer nálatok működik, a sarokban búgó szerveren. Gyula, a rendszergazda hetente egyszer néz rá (távolról), mert egyébként van neki főállása is valahol, de mivel a főnök unokatestvérének volt kollégiumi szobatársa, ezért ő a külsős rendszergazda.

Nem tudjuk, Gyula hogy néz rá a szerverre, de a cucc működik vagy 12 éve, és még soha nem volt vele semmi gond (Gyula jó rendszergazda!).

A kollégáiddal a böngészőből éritek el, tök kényelmes az egész, beírod a címet, kér egy nevet meg egy jelszót (már nem emlékszel mi a jelszavad, 12 éve állította be Gyula, de a böngésződ emlékszik rá szerencsére). Mostanában kicsit macerásabb, mert a Chrome meg a Firefox valami olyat kiabál, hogy nem titkosított a kapcsolat, ezért inkább a régi Internet Explorert használod, Gyula abba is beállította neked a jelszót és az IE jól működik, problémamentes a belépés.

Mind a 10 sales kolléga eléri a szervert és az összes adatot látja benne.

Milyen személyes adatokat tárol:

Hááááát 12 évre visszamenőleg minden ügyfél, kapcsolat, célpont nevét, címét, telefonszámát, lábméretét, szülinapját, anyja nevét, ha ügyfél akkor a szerződést, a személyigazolványa másolatát, a születési anyakönyvi kivonatát, stb. A jó sales MINDENT tud az ügyfeleiről, és még többet tud a LEENDŐ ügyfeleiről.

Jelenlegi biztonsági intézkedések:

Már most is túlzók. A szervert csak a cégen belülről lehet elérni. Amúgy a céges TPLINK-típusú tűzfal minden kibertámadást kivéd, hiszen soha nem volt semmilyen gond vele, úgyhogy ez szerinted túlzás, jó lenne otthonról is elérni, mert van, amikor otthonról kell dolgoznod, de megoldod végülis, mert az esti melóhoz szükséges adatokat hazaküldöd a Gmailedre és abból dolgozol.  

Gyula azt mondja, hogy a szerver meg van védve a kibertámadásoktól, a mentésről meg ő gondoskodik, mert otthonra le tudja menteni (mert ő bezzeg eléri!!) az adatbázist, és le is szokta havonta menteni, de tök felesleges, még soha nem kellett visszaállítani, mert minden működik. Jó, néha, amikor a böngésző elfelejti a jelszót, akkor Gyula szokott segíti, megnézi a legutóbbi mentést az otthoni gépén, és abból meg tudja mondani a jelszót a feledékeny kollégának (miért nem írja fel az ilyen!!).

Van szünetmentes USP eszköz a szerveren, amitől a szerver szünet nélkül működik.

Kockázatok:

Szerinted semmi, a rendszer működik, atomstabil (és egyébként tényleg!).

Volt valami IT felmérés (a főnök akarta, hogy legyen, Gyula egyik haverja a Béla jött el felmérni, de pont előtte balhézott össze a Gyulával, úgyhogy egy csomó sületlenséget írt le, kár volt kidobni rá a pénzt. 

1. A szerver elérése titkosítatlan HTTP protokolon keresztül történik. A Chrome és a Firefox ugyan szól érte és figyelmezet, de Gyula mitigálta a problémát azzal, hogy minden felhasználó használjon Explorert, hát az van benne a Windózba, az jobb.
   
   
2. Jelszócsere 12 éve nem volt, mindenki a böngészőben elmentve tárolja a belépési adatokat. Állítólag azt a vírus el tudja lopni, de hülyeség, a TPLINK-típusú tűzfal megállítja a kibertámadásokat.
   
   
3. A belépéshez szükséges jelszó az adatbázisban nem titkosítottan tárolódik, hiszen Gyula a szofisztikált mentésből ki tudja olvasni a jelszót.
   
   
4. A szofisztikált mentés konkrétan azt jelenti, hogy az adatbázis és abban tartott személyes adatok Gyula otthoni gépére tárolódnak (tök rendes tőle, és nem számít fel tárolási díjat se!!).
   
   
5. Gyula valamilyen módon eléri a szervert távolról, Béla leírta, hogy Gyula egy „Port Forward” nevű programot használ erre a célra amit a tűzfalra telepített (??! – nem is vettünk ilyet, tök rendes Gyulától, hogy a sajátját használja, főleg úgy, hogy egyébként nincs is szerződés vele aláírva), meg állítólag nem csak Gyula éri el, de más is, de biztos hazudik.
   
   
6. A felhasználók a személyes adatokat máshol is kezelik, nem csak a rendeltetési helyen, hiszen pl. Te is hazaküldöd a Gmailedre, és az otthoni gépeden dolgozol az adatokkal. Legalább egy csomóról van mentés nálad is, ha valami baj lenne Bála gépével.

És így tovább.. (esküszöm, nem nagyon túlzok, a példa életből vett)

Szóval, hol kell akkor titkosítani?

Hát jelen esetben majdnem tökmindegy, de egyébként:

• A bejelentkezéshez szükséges jelszót (megfelelően) titkosítva kell az adatbázisban tárolni, ez alapvető biztonsági intézkedés, amely az adatokhoz való hozzáférést szabályozza.
  
  
• Mivel a rendszer nagymennyiségű személyes (és egyébként más, üzleti-bizalmas, titkos, fontos, szenzitív) adatot tárol, az adatok elérésének titkosított kapcsolaton keresztül kellene történnie. Alapvető biztonsági intézkedés, amely az adatokhoz való hozzáférést szabályozza (bizalmasság, sértetlenség).
  
  
• Ha hazaküldöd az adatokat magadnak akkor az adat rendeltetési helyétől eltérő helyen valósul meg az adatkezelés. Ez csak abban az esetben történhet, ha a másik helyen működő rendszerben „megfelelő technikai és szervezési intézkedéseket hajt(ottak) végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálja” – ez pedig az otthoni gépedre nem igaz (jelen esetben mondjuk a céges és az otthoni között nemigazan van biztonsági szint különbség, de elvekről van szó és nem gyakorlatról :)). És még ebben az esetben is problémás, hiszen nem dokumentált adatkezelés, feldolgozás történik. Ráadásul a Gugli postafiókodban a cég által kezelt személyes adatok lesznek megtalálhatók.
  
  
• Gyula mentési eljárása látszólag megfelel a rendelkezésre állás elvárásának, azonban a személyes adatok rendeltetési helyüktől eltérő helyen kerülnek tárolásra, megfelelő védelmi intézkedések és szabályzások nélkül. A tárolt adatok megismerhetővé válhatnak, hiszen Gyula gépéhez mások is hozzáférhetnek (nagyi, tesó, iráni hekker). Gyula, mint SaaS Backup Service gondoskodjon a megfelelő, titkosított tárolásról :) És persze legyen megfelelő szerződés.
  
  
• A „Port Forward program” használata elérhetővé teszi nem titkosított csatornán (HTTP) keresztül az szerver elérését, ez a bizalmasság, sértetlenség és rendelkezésre állás hármas egységét is sérti. Kicsit jobb lenne a helyzet, ha Gyula átállítaná a rendszert a HTTPS kapcsolatra, mert akkor legalább az alapvető (titkosított kapcsolat) elvárások szűk szeletkéjét ki lehetne pipálni. Egyébként a rendszerhez kívülről mások is hozzáférnek (iráni, pakisztáni, líbiai hekker)

A vicces példából egy nagyon fontos dolog derül ki. Maguknak a személyes adatoknak nem kell titkosítva tárolódniuk az adatbázisban.

Számos ponton jöhet be a titkosítás a képbe, de az adatokat magukat nem szükséges titkosítani, amennyiben a megfelelő védelmi intézkedések (pl a kapcsolat titkosítása, a hozzáféréshez szükséges jelszó titkosítása, stb.) garantálják, hogy a rendszerben csak az arra jogosult személyek férhessenek hozzá az adatokhoz.

Kitárolt adatok

Egy csomó esetben az adatbázisban tárolt adatok megjelennek másol is, munkaállomásokon, fájlszervereken, adathordozókon, levelezésben.

Ilyen esetekben viszont el kell gondolkodni az adatok titkosításán, hiszen az adatok a védett (?) rendszerből kikerülve hozzáférhetőve válhatnak jogosulatlan személyek számára is.

Néhány tipp:

• Fájlszerveren nem szükséges a személyes adatokat titkosítani, ha a jogosultság-kezelés és a hozzáférés védelem biztosítja, hogy csak a jogosult személyek férhessenek hozzá az adatokhoz. (rendszergazdák kíméljenek)
  
  
• Laptop esetében az adatokat nem feltétlen kell titkosítani, ha maga a laptop titkosítva van (full disk encryption). Egyszerűbb a teljes laptopot titkosítani, mint egyes fájlokat.
  
  
• Ha emailben küldünk személyes adatokat (és itt arra gondolok, hogy nagymennyiségű személyes adatot), akkor szükséges a titkosítás bevezetése. Nyilván 1-1 adatcsoport esetében nem kell titkosítani, de szerintem, ha fájlokat küldünk amelyben bizalmas adatok vannak, akkor nem árt a titkosítás. Erre akár egy jelszóvédett ZIP is megfelelő, csak a jelszót ne emailbe küldjük, hanem egy másik csatornán, pl. SMS-ben.
  
  
• USB adathordozón szintén szükséges a titkosítást használni, részegen elhagyni egy pendrájvot igen könnyű. De ez sem a GDPR-al jön be a képbe, általános biztonsági intézkedés az adatok bizalmasságának biztosítására. Itt is lehet csak a személyes adatokat tartalmazó fájlt titkosítani (jelszóvédett ZIP), vagy az egész adathordozót.