A GDPR (General Data Protection Regulation, magyarul Általános Adatvédelmi Rendelet) 2016. május 25-e óta hatályban van. 2018 május 25-étől vált kikényszeríthetően alkalmazandóvá és azóta is az egyik legfontosabb (akár horrorisztikusan magas büntetési tételekkel operáló) IT kihívás, amit érdemes alaposan körbejárni. A GDPR nem ad technológiai megoldásokat, irányelveket az általa definiált elvárások teljesítésére, ellenben hangsúlyos artikulációja a kockázat elvű stratégia, amelyben az ésszerűség határain belül minden meg kell tenni a biztonsági kockázatok mininalizálása érdekében.
Kié az adat?
Az adat, amelyet bekérünk egy szoftver felületen, nem a mi tulajdonunk, hanem azé, aki azt megadja számunkra, a mi kezelésünkbe. És ezért (az adatokért) felelősséggel tartozunk a tulajdonos irányába. Őriznünk kell az adatait, azon mód használhatjuk fel, amellyel a tulajdonos egyetért (megért) és beleegyezik, nem adhatjuk önhatalmúan oda másnak, vagy ha egyértért azzal, hogy odaadhatjuk, meg kell győződünk annak megfelelő védelméről. Ha az adat tulajdonos azt kívánja, el kell távolítanunk a rá vonatkozó adatokat. Összefoglalva, az adatkezelő felelőssége az adatbirtokos személyes adatainak védelméhez fűződő alapvető jog biztosítása.
Az adat tulajdonosát átlátható és megérthető módon kell tájékoztatni arról, hogy
- milyen adat
- meddig
- milyen célból
- és kik által hozzáférhetően kerül tárolásra.
Úgyszintén biztosítani kell az adat birtokosának a lehetőséget arra, hogy
- igazolhassa
- módosíthassa
- letölthesse
- mozgathassa és akár véglegesen (későbbi azonosításra nem alkalmas módon) törölhesse az adatait a rendszerünkől.
A módosítás nem csak a közvetlen személyes adatok könnyű megváltoztatását kell hogy lehetővé tegye, hanem bármilyen, a rendszerben beállított (megadott) hozzájárulás ki és be kapcsolását is.
Személyes adat a log file?
A GDPR kizárólag a személyekhez kapcsolódó adatokkal foglalkozik, amelyek alapján az adat tulajdonosa egyértelműen azonosítható, például név, e-mail cím stb. De mi a helyzet a napló fájlokkal?
Több alkalmazás generál és tárol úgynevezett „log” file-okat a rendszerben történt egyes eseményekkel kapcsolatosan. Ezek olyan riport adatok, amelyekben bizonyos változásokat lehet visszakövetni. Általánosan letárolásra kerülnek és valamilyen beállított időablakban mindig elérhető a legfrisseb verziójuk, míg a régebbieket az újak felülírják. Ezeket a log riportokat használhatjuk elemzésre, rendszer szűk keresztmetszet meghatározásra, terhelés megosztásra, egy-egy esemény bekövetkezésének lekövetésére stb. Kérdésként merül fel, hogy ezek személyes adatok-e?
Meglátásunk szerint abban az esetben mindenképpen, amennyiben a rendszer naplózása során a napló fájlokban lévő adatok bármelyike egyértelműen összekapcsolható egy, a rendszerben felvett adat tulajdonosával.
A log file a rendszer alapvetése szerint folyamatosan újraírja az adatait. Amennyiben egy regisztrált adat tulajdonos törli magát a rendszerből attól még a hozzárendelt log file adatai a rendszerben maradhatnak, jobb esetben és GDPR konform módon anonimizáltan. A rossz megoldás, ha a törölt felhasználó bárhol is a rendszerben (akár a log file adataiban is) személyes azonosításra alkalmas módon található meg. Megoldás, ha az addig regisztrált adatbirtokos azonosítója helyett például „törölt user” elnevezés kerül be az adattáblákba. A log riportokat addig érdemes a rendszerben naplóztatni, ameddig annak valóban van tényszerű hasznossága és az abból kinyerhető adatok elemzése számunkra előremutató.
Next, next, finish?
A GDPR reguláció kritikus üzleti aspektusa minden olyan szoftver fejlesztésnek, adatbázis kezelésnek, ahol személyekkel összekapcsolható adattartalmat generálunk. A technológia önmaga nem oldja meg a rendelet teljesítésével kapcsolatos kihívásokat, azonban szemmel láthatóan támogatja azt.
A GDPR tehát távolról sem arról szól, hogy veszünk egy kiváló dobozos terméket, feltelepítjük, és láss csodát máris kész a megfelelősség. Job’s done.
Biztosan eleve terveznünk kell (ésszerű és kockázat alapú) GDPR konform megoldásokat magán az alkalmazás, az azt futtató infrastruktúra és az adatbázis rétegen is.
Ugyancsak vitathatatlanul foglalkoznunk kell az Adatkezelési Tájékoztató, az Adatvédelmi Szabályzat és az Adatvédelmi Nyilatkozat elkészítésével, folyamatos követésével és betartásával.
A GDPR arra ösztönöz, hogy mérlegeljük az adatkezelés kockázatait és a sarkallatos pontokat erősítsük meg, legyünk képesek jól behatárolni a bekért adatok körét és annak tárolási szükségességét és akár visszakövetni az adatforgalmat.
Adatvédelem, titkosítás. Egykutya?
A biztonság fenntartása és a GDPR 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 ilyen kockázatok csökkentését szolgáló intézkedéseket, például titkosítást alkalmaz. Ezért például alkalmazás fejlesztés, adatbázis nyilvántartások megtervezése során már jóelőre figyelembe kell venni ezeket az előírásokat.
Az adatvédelem és a titkosítás az két nagyon különböző dolog.
Az adatvédelem a személyes adatok kezelésével, védelmével kapcsolatos jogi szabályozás összessége, tehát nem információ technológiai eljárás.
A titkosítás egy olyan információ technológiai (cél)eljárás, amikor a személyes adatokhoz való hozzáférésre fel nem jogosított személyek számára értelmezhetetlenné tesszük az adatokat. Tehát a megfelelő szinten titkosított személyes adat a megismerésére jogosultsággal nem rendelkező személy számára a titkosítást feloldó kulcs hiányában értelmezhetetlen.
Többféleképpen lehet titkosított az adat és az is felmerülhet kérdésként, hogy pontosan milyen adatok legyenek így tárolva, és milyen helyzetben szeretnénk ellehetetleníteni, de legalább megnehezíteni az adatok jogosulatlan megismerését. Csak az személyes adatokat tartalmazó adatbázis, vagy a képek, videók, hang file-ok is legyenek titkosítottan tárolva?
Operációs rendszer szintű titkosítás
Jellemzően ez a fajta titkosítás nem érhető el a szerver erőforrást saját infrastruktúrával biztosító cégek portfoliójában. Operációs rendszer szintű titkosításkor minden titkosítva van, maga az operációs rendszer is. Az ellen véd, hogy valaki bemegy az adatközpontba (kijátszva a kamerákat, lőfegyveres őröket, személyes azonosítók megadását), és hozzáférést szerez az adathordozóhoz (például kiveszi a szerverből a fizikai HDD-t, SSD-t) és ki akarja olvasni az adatvagyont (vagy ott a helyszínen, vagy máshol). A fájlrendszer vagy az operációs rendszer titkosításakor a gépet csak jelszóval lehet elindítani. Ilyenkor maga az induláshoz használt fájlok nagy része is a titkosított lemezen van. A videók, képek és az adatbázisok is titkosítottan kerülnek tárolásra. Ez viszont megakadályozhat hiba esetén egy automatikus újraindulást.
Kicsi az esélye és a kockázata annak, hogy egy adattolvaj bejut az őrségen keresztül és kiszemelve egy darab szervert és kiemeli a fizikai adathordozót. A távoli illetéktelen hozzáférést pedig a port szintű korlátozással és tűzfallal oldhatjuk meg. Az operációs rendszer szintű titkosítás a képek, videók, hang file-ok titkosítására is alkalmas.
Felcsatolt kötet titkosítása
Ez jellemzően ingyenes a szerver szolgáltatást saját hardverrel biztosító cégeknél. Hasonló mint az előző megoldás, de az operációs rendszer fájljai nem titkosítottak. Ilyenkor az adott kötet felcsatolásához kell jelszó (vagy minden indulásnál manuálisan megadni, vagy nem titkosított helyen tárolni). Ugyanúgy a adott titkosított köteten tárolt videók, képek, hang file-ok és az adatbázis is titkosítva vannak tárolva. Az ellen véd, hogy valaki bemegy az adatközpontba, hozzáférést szerez az adathordozóhoz és ki akarja olvasni az adatvagyont. Ez a módszer egy-egy meghajtó (fizikai vagy virtuális) titkosítása, amely akár a média fájlok titkosítására és akár az adatbázis fájlok titkosítására is lehetőséget ad.
Ez az eljárás leginkább azt képes megakadályozni, hogy maga a szerver szolgáltatást nyújtó cég alkalmazottja ne lásson egyszerűen bele a forrás fájlokba. Ha azonban valaki a virtuális gépen futó operációs rendszerbe jut be, akkor a kapott jogosultságoktól függően tud fájlokat olvasni, átírni.
Adatbázis titkosítás
Jellemzően ez a fajta titkosítás szintén nem érhető el a szerver erőforrást saját infrastruktúrával biztosító cégek kínálatában. Adatbázis titkosításnál csak maguk az adatbázis fájlok titkosítottak.
Ennek foganatosításához szükség van egy előfizetéses típusú Oracle, Microsoft stb. Enterprise szolgáltatásra, aminek havi vagy éves díja van. A program futtatásához (amely az adatbirtokosok személyes adatait használja) az adatbázis jelszavának valahol ott kell lennie a szerveren, így ha valaki szerver szintű hozzáférést szerez, a titkosítás máris értelmét veszti. Ha csak az adatbázis motor alatti céges adatbázis a titkosított, a szolgáltató alkalmazottja vagy az adatrabló előkeresheti az adatbázis jelszavát a program kódjából, és így az adatbázishoz is hozzáférhet.
Jobbára tehát az Enterprise szintű (titkosításra alkalmas) adatbázis motor kicsivel több energiára kényszeríti a jogosulatlan felhasználót, ha a szerveren lévő mappákban tárolt forráskódokhoz is hozzáfér. Fizikai adathordozó eltulajdonítása esetén, ha nincsen sem operációs rendszer, sem felcsatolt kötet szintű titkosítás, akkor teljes körűen hozzáfér minden adathoz.
Ennek okán célszerű elválasztani az adatbázis és az alkalmazás szervert fizikailag.
Felhasználók adatai, tevékenységek és szövegek titkosítása
Fájlrendszer szintű és/vagy adatbázis szintű titkosítást kell alkalmazni. Lehet csak az adatbázis titkosított, de ahhoz kell a Oracle vagy Microsoft Enterprise előfizetéses licencelése. Ha az adatbázis titkosított, akkor valahol ott kell lennie a kulcsnak ugyanazon a gépen, ameddig csak egy szerver van. Így ha valaki hozzáférést szerez a szerverhez, csak idő kérdése, hogy hozzáférhessen a mappákban lévő forráskódban tárolt adatbázis motor kulcshoz. Azért érdemes a Oracle/Microsoft Enterprise adatbázis szervert bevezetni, mert enélkül ha egy hacker bejut a szerverre és képes az adatbázis fájlokat lemásolni, akkor annak adattartalmát változatlan formában képes olvasni is. Ha van Enterprise szintű adatbázis motor, akkor kell jelszó is az adatbázis megnyitáshoz. Ha egy adattolvaj bejut a forráskódot tartalmazó mappába, akkor abban szinte kötelezőleg megvan az a jelszó is, amivel az Enterprise adatbázis kezelő alatt lévő adatbázishoz hozzá lehet férni. Ilyenkor vajmi keveset ér az Enterprise titkosítás.
A felhasználói fiók jelszava
A legérzékenyebb adatok egyike, jellemzően (profibb megoldásoknál) a felhasználók jelszava nincs plain text-ként tárolva, hanem nehezen visszafejthető formátumú. Az adott alkalmazás forráskód szintű tulajdonosai sem tudjuk ezt feloldani, azaz kizárólag a jelszó emlékeztetés működik, ha valaki a jelszavát elfelejtette egy ilyen rendszerben. A kockázatokat mérlegelve esetleg érdemes másodlagos, úgynevezett kétlépcsős azonosítást használni (hardver token, sms, másodlagos e-mail címre érkező megerősítés, autentikátor külső szoftver stb.)
Egyéb lehetséges védelmi intézkedések
- Portok korlátozása tűzfal segítségével.
- Akár IP cím szerint szűrést is beállítható, például csak adott IP címről, tartmányról lehet bejelentkezni.
- Kezelőfelülethez csak SSH kulccsal lehet hozzáférni.
