2022. november 7. napján a Telex internetes hírportálon közölt sajtócikk szerint a Köznevelési Regisztrációs és Tanulmányi Alaprendszert (KRÉTA) fejlesztő céget informatikai támadás érte és súlyos adatvédelmi incidens következhetett be. A NAIH nem is késlekedett sokat, egy nappal később hatósági ellenőrzést, majd adatvédelmi hatósági eljárást indított. Az eljárást lezáró határozat a közelmúltban került közzétételre, amely – egyelőre nem jogerősen – 110 millió forint összegű adatvédelmi bírságot rótt ki a mulasztó cégre. Jelen írás keretében az ügy rövid összefoglalása és tanulságai kerülnek ismertetésre – Dr. Pilling Zoltán ügyvéd tollából.
A KRÉTA rendszer
Bevezetésként ismerkedjünk meg azzal, hogy mi is a KRÉTA és milyen jellegű személyes adatokat kezel? Talán a legismertebb funkciója az elektronikus napló, azonban emellett több, mint húszféle hasonló modullal rendelkezik, például: e-ügyintézés, iskolai étkezés, egészségügy, tanulói jelzőrendszer, gazdálkodási, de a KRÉTA alá tartozik a felnőttképzések adatszolgáltatási rendszere is.
A fenti felsorolásból látható, hogy a kezelt adatok köre meglehetősen széles, többek között a tanárok, diákok, szülők természetes személyazonosító adatai, adóazonosító, TAJ szám, egészségügyi adatok (pl. beilleszkedési, tanulási, magatartási, nevelési nehézségek, sajátos nevelési igény), és a tanulókra vonatkozó értékelések egyaránt szerepelnek a rendszerben.
A cég becslése szerint összesen kb. 225 ezer alkalmazott (köztük főként tanárok), 1.500.000 diák és 1.870.000 szülő személyes adata található meg a KRÉTA rendszerben. Ez közel 60 millió személyes adatot jelent a teljes mennyiséget illetően.
Hogyan történt a támadás?
A KRÉTA rendszer üzemeltetését adatfeldolgozóként az eKRÉTA Informatikai Zrt. végezte a köznevelési intézményekkel (vagy fenntartóikkal) kötött szerződések alapján. Az adatkezelők azok a köznevelési intézmények voltak, ahova a gyermekek tanulni, a pedagógusok pedig tanítani járnak.
2022. szeptember 15. napján ismeretlenek adathalász támadást hajtottak végre. A cég egyik support tevékenységet végző munkavállalója az adathalász levélben küldött fertőzött elemet megnyitotta, amivel a támadók megszerezték a munkavállaló jelszavait és hozzáférést kaptak a rendszerhez. A support munkavállaló ugyanis minden hozzáférési jogosultsággal rendelkezett mind a teszt, mind az éles KRÉTA rendszerhez és a kapcsolódó adatbázisokhoz egyaránt. Emellett a munkavállaló support tevékenysége keretében az éles rendszerből gyakran ment le személyes adatokat a rendszerből saját gépére. A 2022. szeptemberi támadás során tizenkét oktatási intézmény teljes adatállománya volt megtalálható a gépén.
Az incidensről a munkavállaló napokkal később értesítette a cég vezetését. A cégnél lecserélték az adathalász támadás áldozatául esett munkavállaló gépét, törölték a belépési azonosítóit, jogosultságait, majd a munkavállaló új számítógépet és új jelszavakat kapott. A jelszócserét követően nagy mértékű adatmozgást a rendszer vonatkozásában nem észleltek, a vizsgálatot a cég befejezte és az ügyet lezártnak tekintette.
Közel két hónappal később azonban jött a közmondásos fekete leves, a Telex-es sajtócikk megjelenésének napján (2022. november 7.) az internetes sajtót nem olvasó munkatársak is értesülhettek a támadásról, ugyanis a támadó a cég belső kommunikációs csatornáján közzétett egy tájékoztatást arról, hogy a rendszert feltörték. Csak ezt követően került sor egy átfogóbb és alaposabb belső adatvédelmi vizsgálatra, valamint az adatvédelmi incidens hatósági bejelentésére.
Adódik a kérdés, hogy miképpen volt lehetséges a KRÉTA rendszer feltörése, ha a 2022. szeptemberi adathalász incidens után a munkavállaló jelszavait lecserélték? Röviden összefoglalva, két körülmény játszott közre.
Az egyik az, hogy a munkavállaló a Google fiókjában tárolta minden belépési adatát. A Google azonban nemcsak tárolja, hanem szinkronizálja is tudja az adatokat. Ez azt jelenti, hogy amikor megváltoznak az adatok, akkor a Google a régi adatok helyére felviszi az újakat. Amikor a 2022. szeptemberi incidens után új belépési jogosultságokat kapott a munkavállaló, akkor ezeket a Google frissítette és eltárolta.
A másik kulcs tényező az volt, hogy egy nyitva maradt munkameneten keresztül a támadók a munkavállaló Google fiókjához továbbra is hozzáfértek, így az új jelszavakat is könnyedén megszerezték, ami lehetővé tette a rendszer feltörését.
A hatóság megállapításai
A NAIH az adatvédelmi incidenst két részre bontotta:
1. A 2022. szeptemberi incidens elsődlegesen annak a 12 intézménynek teljes adatállományát érintette, amelyet a munkavállaló az éles rendszerből lementett a gépére. Ebben az esetben bizonyíthatóan megvalósult az adatvédelmi incidens
2. A 2022. novemberben megismert incidens esetében csak annyi volt a megállapítható, hogy a támadók hozzáférhettek a teljes KRÉTA adatállományhoz. Azt nem sikerült az eljárásban kétséget kizáróan bizonyítani, hogy a KRÉTA rendszerből a támadók ténylegesen mentettek-e le személyes adatokat vagy sem.
A cég eljárása jogszabálysértést valósított meg: egyrészt nem tett megfelelő technikai és szervezési intézkedéseket és nem biztosította a megfelelő adatbiztonsági követelményeket (GDPR 32. cikk), másrészt az adatvédelmi incidenst nem jelentette be késedelem nélkül (GDPR 33. cikk).
Az eset fontosabb tanulságai, a cég mulasztásai
Késedelem nélküli bejelentés: A NAIH álláspontja szerint a kezelt adatok mennyiségére és érzékeny jellegére tekintettel már a 2022. szeptemberi incidenst is mindenképpen be kellett volna jelenteni, hiszen ez esetben minden kétséget kizáróan megvalósult egy magas kockázatú adatvédelmi incidens. Noha az adatvédelmi incidens bejelentést nem a cégnek, mint adatfeldolgozónak, hanem az adatkezelő oktatási intézménynek kellett volna megtenni, csak a cég volt abban a helyzetben, hogy az incidens súlyát felmérje és erről értesítse az adatkezelőket.
Jelszavak Google fiókba történő mentése kockázatos: Önmagában érzékeny jelszavak bármilyen fiókba, böngészőkbe történő mentése is hordoz magában kockázatot, azonban a KRÉTA üggyel érintett mennyiségű és minőségű személyes adat esetében ez súlyos és elfogadhatatlan adatbiztonsági hiba. Léteznek más, biztonságosabb (pl. a gépre telepített) jelszótároló lehetőségek.
Munkamenet automatikus kiléptetés: Súlyos adatbiztonsági mulasztásként került értékelésre az a tény is, hogy a nem került beállításra az automatikusan kiléptetés.
Nincs jelentősége az adatok tényleges felhasználásának: A cég azzal próbált védekezni, hogy keresést folytatott a dark weben és ott nem voltak fellelhetőek a KRÉTA felhasználók adatai. A NAIH – helyesen – az adatok bizonyítható felhasználásának semmilyen jelentőséget nem tulajdonított, hiszen nem szükségképpen fogják a támadók az adatokat nyilvánosságra hozni, másrészt a jövőre nézve sem lehet kizárni az adatokkal történő visszaéléseket.
Nem megfelelő kivizsgálás: A 2022. szeptemberi adathalász támadás kivizsgálása nem volt teljes körű. A felhasználó fiókok törlése és új jelszavak generálása nem elégséges különösen a rendszerben kezelt személyes adatok mennyiségére és érzékenységre tekintettel. Egy alapos vizsgálat megelőzhette volna a helyzet súlyosbodását. A NAIH jó gyakorlata szerint a munkavállalóhoz kapcsolódó hálózati forgalmat figyelni kellett volna, amiből ki lehetett volna deríteni, hogy melyik forgalom tartozik a munkavállalóhoz és mely a támadókhoz. A cég ugyanis nem tudta egymástól elválasztani a munkavállaló és a támadó tevékenységét. Ha erre képes lett volna, akkor észlelnie kellett volna a támadó jelenlétét.
Elégtelen naplózás: Ahogy az előző pont végén is említésre került, a cég által végzett naplózás nem segítette az incidens feltárását. Ha a támadó a munkavállaló profiljával lépett be a rendszerbe, akkor nem lehetett megállapítani a naplóból, hogy a támadó vagy a munkavállaló van-e jelen. A NAIH elvárása szerint a naplónak alkalmasnak kell lenni az incidens megfelelő feltárására.
Kétfaktoros azonosítás: A kétfaktoros azonosítás bevezetésére csak 2022. november 10. napján kerített sort, azonban egy KRÉTA szintű rendszer esetében minimum elvárás lett volna a kezdetektől.
Az emberi hibafaktor: Ahogy a mondás tartja, csak az nem hibázik, aki nem dolgozik. Ennek megfelelően az emberi hiba lehetőségével számolni kell, „hiszen egy vállalkozás sem építhet arra, hogy a munkavállalója ’úgysem fog hibázni’”. Olyan adatbiztonsági intézkedéseket kell bevezetni, ami egy emberi hiba esetén is képes a súlyos következmények megakadályozására.
Számítani kell a támadásra: A NAIH szerint bizonyos esetekben, pl. a kezelt adatok mennyisége, érzékenysége miatt vagy a gazdasági élet szereplői esetében elvárható, hogy készüljenek arra, hogy informatikai támadásnak lesznek kitéve. A biztonsági rendszerüket ennek megfelelően kell megtervezni.
Végezetül az eset legszomorúbb konklúziója is ide kapcsolható. A NAIH határozata is megemlíti, hogy a cégnél feltehetően a támadás előtt is tisztában voltak a rendszer sebezhetőségével, azonban gondatlanságból és/vagy hanyagságból elmulasztották a megfelelő biztonsági rendszer kiépítését. Erre utal, hogy a rendszer feltörését követően alapvető változásokat eszközöltek (csak a felsorolásuk közel húsz pontot tartalmaz) és kialakították a biztonságos adatkezelés feltételeit. Kérdés, hogy ehhez miért kellett megvárni, amíg a rendszert feltörik és illetéktelenek a teljes KRÉTA adatállományhoz hozzáférnek?
