Adatbiztonsági tanulságok a hazai és uniós adatvédelmi hatósági döntések alapján – 110 millió és 980 millió forint bírság

Hazai és uniós adatvédelmi hatósági döntések
2024/03.

Adatkezelőként szükséges figyelemmel lenni az adatkezelések kialakítása során a személyes adatok kezelésére vonatkozó alapelvekre, melyek mindennapi működésbe történő beépítése és megtartása a jogszerű működés elengedhetetlen feltétele. Az adatkezelési folyamatok kialakításához és azok működtetéséhez érdemes nyomon követni az adatvédelmi felügyeleti hatóságok döntéseit is, ehhez kívánunk hatékony segítséget nyújtani a Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH), illetve uniós tagállami adatvédelmi felügyeleti hatóságok határozatainak, döntéseinek rövid ismertetésével, összefoglalásával a PRAUDIT adatvédelmi blogjában.

Jelen bejegyzésünkben két jelentős, az adatbiztonságot érintő adatvédelmi incidens kerül bemutatásra.

I. KRÉTA rendszer támadásával kapcsolatos kiemelt adatbiztonsági megállapítások
Hatóság: Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH)
Dátum: 2024.
Bírság: 110 millió forint

Jelen ügyben a NAIH 110 millió forint összegű bírságot szabott ki a Kréta rendszer fejlesztőcégére (Szervezet), ugyanis az informatikai fejlesztői környezetének adatbiztonsági beállításai során nem vette kellőképpen figyelembe az adatkezelésből eredő olyan kockázatokat, amelyek a személyes adatok jogosulatlan nyilvánosságra hozatalából vagy azokhoz való jogosulatlan hozzáférésből erednek és emiatt 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 nem garantálta. Ezen felül a szervezet az adatvédelmi incidenst nem jelentette be indokolatlan késedelem nélkül.

Adatkezelés körülményei

A KRÉTA rendszert támadás érte, akként, hogy egy támadó több oktatási intézmény alkalmazottjának kártékony kódot tartalmazó linkkel ellátott üzenetet küldött a rendszeren keresztül és az ebben található linkre a Szervezet egyik munkavállalója rákattintott. Ezzel a támadó bejutott és hosszabb ideig bent tartózkodott az érintett kolléga számítógépében, melyen keresztül hozzáférhetett az Szervezetnél munkavégzéshez használt rendszerekhez, a számítógépen elmentve tárolt jelszavakhoz.

Ahogy a Szervezet megbizonyosodott a támadásról 2022 szeptemberében, azonnal lecserélte az érintett felhasználó gépét, és inaktiválta mind az eredeti felhasználói fiókját, mind pedig a különféle jogosultságait, majd részére új felhasználói fiókot hozott létre. Ugyanakkor az érintett felhasználó mind a régi, mind az új felhasználójához tartozó belépési adatokat (felhasználói neveket és jelszavakat) a Google Ireland Ltd. (Google) egyik szolgáltatásaként nyújtott jelszókezelőbe szinkronizálta. A Google jelszókezelő szolgáltatása úgy működik, hogy a használója a saját Google fiókjába mentheti a más weboldalakon elérhető alkalmazások, rendszerek eléréséhez szükséges felhasználói neveket és jelszavakat. Ha a jelszavait ilyen módon tároló felhasználó Google fiókjához illetéktelenek férnek hozzá, akkor az ott tárolt valamennyi felhasználói nevet és jelszót képesek megismerni. A jelszókezelő által biztosított szinkronizálás révén, ha valamely más weboldalhoz, rendszerhez a felhasználó a már mentetthez képest eltérő, új jelszót ad meg, akkor a Google jelszókezelője ezt képes eltárolni, vagyis a régi jelszót felülírni az újjal. A támadók az érintett felhasználó Google fiókját érhették el továbbra is, egy nyitva maradt munkamenet (ún. session) révén, és így szerezték meg a Szervezet valamennyi olyan rendszeréhez tartozó jelszavakat, amelyeket ugyancsak a jelszókezelőben tárolt.

A Hatóság a Szervezet saját fejlesztői környezete, rendszere, és a KRÉTA rendszer éles és teszt adatbázisainak onnan való elérése tekintetében alkalmazott adatbiztonsági követelményeket vizsgálta, azzal, hogy az adatvédelmi incidens vizsgálata esetén az incidens kezelése során tett lépések értékelése elválaszthatatlan az adatkezelő / adatfeldolgozó rendszereinek adatbiztonsági beállításaitól, az adatbiztonsági környezet sajátosságaitól.

Hatóság megállapításai

A Hatóság az adatvédelmi incidensek súlyosságát elsősorban a biztonsági sérülésnek az érintett természetes személyek jogaira és szabadságaira jelentett kockázat szintje alapján értékeli. Összességében a korábban kifejtettekkel összhangban megállapítható, hogy egy vállalkozásnak, amely olyan jellegű rendszert fejleszt, mint a KRÉTA rendszer (mely több millió természetes személy több tízmillió személyes adatát tartalmazza), és bír az abban tárolt adatokhoz hozzáféréssel, már csak erre tekintettel is, a legkisebb biztonsági sérülésre utaló jelet is a lehető legkomolyabban kell vennie és kivizsgálnia. Különösen igaz ez akkor, amikor ténylegesen egy olyan profillal kapcsolatban merül fel a támadás lehetősége/esélye, amelyről az éles KRÉTA rendszerhez is hozzáférhetnek. Az érintett felhasználó a feltárt tényállás alapján support tevékenységet is ellátott, ebből következően minden olyan jogosultsággal rendelkezett, amely szükséges ahhoz, hogy az éles és teszt KRÉTA rendszerekhez, ill. azok adatbázisaihoz hozzáférjen.

A KRÉTA rendszerből korábban tesztelés céljából lementett, az érintett felhasználó gépén a támadás időpontjában éppen elérhető személyes adatok számáról és mennyiségéről a Szervezet azt nyilatkozta, hogy 12 darab szakképzési centrumhoz kapcsolódóan szerepelnek személyes adatok, összesen – a Szervezet által a Hatóság részére megküldött excel táblázatban szereplő adatok szerint – 8574 tanuló ~290.000 adata, 11.082 gondviselő ~44.000 adata, valamint 1205 alkalmazott ~35.000 adata.

Fentiekben említett, a Google jelszókezelőjének alkalmazása ilyenformán a KRÉTA rendszerben tárolt adatok biztonságára nézve egy kezeletlen kockázatot jelentett. A támadók az érintett felhasználó Google fiókjába már azt megelőzően beléphettek, hogy a KRÉTA rendszerhez új felhasználói fiókot és jelszót kapott, és ott ezután is bent maradhattak, köszönhetően annak, hogy a Google szervere és a támadók számítógépe között folyamatosan nyitott volt a kapcsolat (munkamenet).

Ebből következően önmagában a KRÉTA rendszerhez új felhasználói fiók létrehozása ez esetben nem lehetett elégséges lépés, mivel annak jelszavát az érintett felhasználó általi első sikeres belépést követően a Google jelszókezelője szinkronizálta. A Hatóság álláspontja szerint egy ilyen jellegű tevékenységet ellátó munkatárs esetén mind a jelszavak Google szinkronizációja, mind az a tény, hogy a session nem kerül automatikusan kiléptetésre, súlyos adatbiztonsági hibának minősül, ezek elfogadhatatlan mértékben növelték a rendszer kitettségét, hiszen léteznek olyan, csak az adott számítógépre telepített jelszókezelő szoftverek, amelyekben – mint egy széfben – biztonságosan tárolhatóak a felhasználók jelszavai. Az ezekben a szoftverekben tárolt jelszavak általában csak a felhasználó kétfaktoros azonosítása, vagy rendkívül erős jelszó megadása mellett érhetőek el.

Az a körülmény, hogy a támadó konkrétan meg is ismerte-e az éles KRÉTA rendszerben tárolt személyes adatokat, nem volt az eljárás során bizonyítható, tekintettel arra, hogy a támadó, amennyiben belépett az éles KRÉTA rendszerbe, azt érvényes jogosultságokkal, az érintett felhasználó jogosultságaival tette, így pusztán a naplófájlok böngészése alapján nem választhatóak el a támadó lépései az érintett felhasználó lépéseitől.

A kétfaktoros autentikáció hiánya és a Szervezet által végzett naplózás fentebb részletezett hiányosságai a fejlesztői környezetben semmiképpen nincsenek összhangban a tudomány és a technológia állásával. A Szervezet által fejlesztett rendszerben tárolt, illetve adott esetben a support tevékenység körében lementett személyes adatok mennyisége jól meghatározza az adatkezelés jellegét és hatókörét, ilyen rendszer fejlesztése esetén minimum elvárás, hogy a tudomány és technológia legújabb állásának megfelelő, minden észszerűen elérhető adatbiztonsági intézkedésnek érvényt kell szerezni. A Szervezet által az incidens bekövetkezését követően megtett, a lentiekben részletesen ismertetett adatbiztonsági jellegű intézkedéseket a Hatóság megfelelőnek ítélte, ez is csak azt támasztja alá azonban, hogy a Szervezet tisztában van azzal, hogy milyen szintű és jellegű adatbiztonsági intézkedések lennének elvárhatóak egy olyan rendszer esetében, mint amelyet fejleszt, mégis jelen incidensnek kellett bekövetkeznie ahhoz, hogy ezek meg is valósuljanak.

A Hatóság megállapította, hogy a támadás bizonyítottan érintette azokat a személyes adatokat, amelyeket az érintett felhasználó a support tevékenységével kapcsolatban mentett le a gépére, illetve a Szervezet munkavállalóinak adatait. Az éles KRÉTA rendszerben szereplő személyes adatokhoz való potenciális támadó általi hozzáférés kapcsán a Hatóság ismételten ki kívánja emelni, hogy a Szervezet az eljárás során nem mutatott be semmiféle olyan információt, amely minden kétséget kizáróan bizonyítaná, hogy a támadó az éles KRÉTA rendszerből nem mentett ki személyes adatokat. A Hatóság álláspontja szerint az eljárás során feltárt információk alapján összességében megalapozottan lehet arra következtetni, hogy a támadás során hozzáfértek az éles KRÉTA rendszerben tárolt személyes adatokhoz is.

Az incidens fenti körülményeit összesítve, a Szervezetnél egymással összefüggő okokból bizonyíthatóan bekövetkezett egyrészről egy magas kockázatú incidens, másrészről valószínűsíthetően bekövetkezett egy kiemelkedően magas kockázatú incidens. Bár az adatvédelmi incidensek kockázatainak felmérése tipikusan az adatkezelő feladata, ez esetben a KRÉTA rendszer, és a fejlesztői környezet jellegéből kifolyóan a Szervezet volt csak abban a helyzetben, hogy az eset összes körülményének ismeretében az incidens kockázatait fel tudja mérni.

Adatbiztonságot érintő körülmények

A 2022 szeptemberben közepén észlelt adathalász támadás kivizsgálása során a Hatóság álláspontja szerint a Szervezet – közvetlenül a támadás 2022 szeptemberi észlelését követően – nem folytatott az érintett munkavállalóhoz kapcsolódó információbiztonsági kockázatok teljeskörű felmérése érdekében kellő mélységű vizsgálatot, válaszintézkedései szinte kimerültek abban, hogy az adott felhasználói fiókot törölte, és az érintett felhasználó jogosultságait felfüggesztette. Amennyiben erre a vizsgálatra – különösen az éles KRÉTA rendszerben tárolt személyes adatok mennyiségét és érzékenységét is figyelembe véve – a kellő gondosság mellett sor került volna, úgy a Szervezetnek az információbiztonsági jó gyakorlatokat követve legalább az érintett felhasználóhoz kapcsolódó hálózati forgalmat figyelnie kellett volna huzamosabb ideig, és az adott felhasználó bevonásával kellett volna vizsgálnia azt is, hogy mely forgalom köthető az ő tevékenységéhez és melyik ismeretlen – így vélelmezhetően illetéktelen – felhasználókhoz. Erre már csak azért is szükség lett volna, mivel a Szervezetnek nem volt kellő információja arról, hogy sor került-e jogosulatlan hozzáférésre, így az esemény okainak és potenciális következményeinek a teljes körű kivizsgálása elvárható lett volna a részéről. Ha erre sor került volna, akkor a Szervezet vélhetően időben észlelte volna, hogy illetéktelenek tartózkodnak a rendszereiben, úgyszintén azt is, hogy pontosan mihez fértek hozzá, és így jó eséllyel elkerülhették volna a helyzet további súlyosbodását.

Fentiek pontosan megvilágítják a tényállás egyik meghatározó elemét, mégpedig azt, hogy miért lett volna kiemelt jelentőségű, és akadályozhatta volna meg az incidenst, ha a Szervezet informatikai fejlesztői környezetében használt rendszerekhez – legalább amelyekben személyes adatok szerepelnek – már a támadás időpontjában is csak kétfaktoros hitelesítést követően lehetett volna hozzáférni, és az éles KRÉTA rendszer eléréséhez a kétfaktoros beállítására a Szervezet nem csak 2022 novemberében kerített volna sort.

Megállapítható az is, hogy az a naplózás, amelyet a Szervezet a munkatársainak tevékenysége kapcsán végzett, az incidens kivizsgálása szempontjából elégtelennek bizonyult, hiszen – mint ahogyan az jelen esetben is történt – ha egy támadó hozzáférést szerzett valamely munkatárs profiljához, onnantól kezdve a támadó bármit csinálhatott, akár minden adatot (beleértve ez esetben az éles KRÉTA rendszerben szereplő adatokat is) kimenthetett, a támadó tevékenységét onnantól kezdve nem lehetett elválasztani a feltört profil tulajdonosának tevékenységétől. Ez súlyos adatbiztonsági hiányosság, hiszen ilyen naplózással lehetetlen eleget tenni az általános adatvédelmi rendelet 32. cikk (1) bekezdés b) pontjában és 32. cikk (2) bekezdésében megfogalmazott követelményeknek. A Hatóság ismét hangsúlyozza, hogy a Szervezet az eljárás során semmi olyan információt nem prezentált, amely bizonyító erővel rendelkezett volna azzal kapcsolatban, hogy a támadás során az éles KRÉTA rendszerből nem mentettek le adatokat.

Fentiekből következően egyértelműen megállapítható tehát, hogy egy KRÉTA szintű rendszer fejlesztése során minimum elvárás a kétfaktoros hitelesítés, valamint egy esetleges biztonsági incidens kivizsgálása esetén a történtek felderítéséhez elegendő tartalmú naplózás megléte. A Hatóság számára nem az bír jelentőséggel, hogy a Szervezet által végzett naplófájlok pontosan milyen rekordokat tartalmaznak, hanem az, hogy ezen rekordok alapján lehetséges-e a biztonsági esemény kellő mélységű feltárása. Ez utóbbi kérdésre nemleges válasz adandó jelen ügyben, és a kétfaktoros autentikáció is csak a támadást követően került bevezetésre, mely körülmények jelentős mértékben hozzájárultak a támadás sikerességéhez, valamint ahhoz, hogy a Szervezet nem volt képes időben felismerni a jogosulatlan hozzáférés tényét, illetve annak mértékét, és így nem tudta időben elkezdeni a kockázatcsökkentő intézkedések implementálását sem.

Szervezet által incidens következtében foganatosított intézkedések

A Hatóság megállapította, hogy a Szervezet rendszerszintű változásokat is tartalmazó, alapvető fontosságú és a technológia állása szerint is elvárható intézkedést vezetett be az incidens bekövetkezését követően, mely intézkedéseket a Hatóság megfelelőnek ítélte, azzal, hogy ezen intézkedések azt támasztják alá, hogy a Szervezet tisztában van azzal, hogy milyen szintű és jellegű adatbiztonsági intézkedések lennének elvárhatóak egy olyan rendszer esetében, mint amelyet fejleszt, mégis jelen incidensnek kellett bekövetkeznie ahhoz, hogy ezek meg is valósuljanak. A Szervezet által elvégzett intézkedések:

a) Hitelesítési megoldások felülvizsgálata, szabályozás áttekintése: 2022 november-decemberében megtörtént.
b) E-mail biztonság felülvizsgálata: Az adathalász tevékenységről a KRÉTA központi oldalán elhelyezésre került egy tájékoztató, illetve a munkavállalók külön, a belső rendszerekre és saját e-mailekre vonatkozó tájékoztatást kaptak ebben a témakörben. Egy „Böngésző biztonságos jelszó tárolása” című dokumentum, illetve egy adathalász levelek felismerésére szolgáló általános tájékoztató kiküldésre került szintén a munkavállalók számára.
c) A külföldi IP címek letiltásra kerültek a KRÉTA rendszerek WEB elérhetőségein, valamint a VPN elérhetőségen (egyedi bejelentés alapján kivételi listák engedélyezhetőek).
d) A belső hálózathoz tartozó felhasználónevek és jelszavak biztonságának fokozása érdekében utasítás került kiadásra 2022 novemberében. Ez tartalmazza, hogy tilos elmenteni a céges rendszerek (Outlook, PROD vagy UAT környezeten lévő KRÉTA, illetve egyéb KRÉTA modul, stb.) felhasználóihoz tartozó jelszavakat a böngészőben. A nem AD autentikációt használó rendszerekhez eltérő jelszavakat kell használni. Az AD policy-t meghaladó, nem kitalálható jelszavakat kell használni. Jelszó megosztása bárkivel tilos. A magán és céges jelszavakat szigorúan szét kell választani.
e) Kétfaktoros azonosítás bevezetése 2022. november 15. napján: Klebelsberg Központ VPN elérésére, a belső kommunikációra használt Slack alkalmazás esetében. A munkatársaknak a belső rendszerekhez való hozzáférései esetében bevezette a kötelező kétfaktoros azonosítást, valamint megtiltotta saját Google fiók magáncélú használatát a munkahelyi eszközökön.
f) 2023. június 9. napján az új, felülvizsgált és a nemzetközi jó gyakorlatok alapján átalakított IT biztonsági szabályzat közzétételre került.
g) A hálózati erőforrások átalakítása 2023 februárjában megtörtént.
h) A munkatársak 2023 januárjában adatbiztonsági és adatvédelmi oktatáson estek át.
i) Az adatbázisok oszlop szintű titkosításának lehetősége felmérésre került, azonban a rendszer teljesítményének romlására tekintettel ennek megvalósítása jelenleg nem lehetséges.
j) Minden 2023. október 31. napja után keletkező eseti mentés (copyonly) vagy mentési lánc állományai titkosított formában kerülnek tárolásra. Azok visszaállítása csak a titkosító kulcs birtokában lehetséges.
k) Több faktoros autentikáció bevezetése: az „Új jelszókezelési eljárásrend kialakítása” című dokumentum elkészült, és a funkció fejlesztés alatt áll. Ennek célja a diákok / tanárok /intézményi adminisztrátorok / központi KRÉTA felhasználók és gondviselők regisztrációs és belépési folyamatában a biztonság növelése. A funkció a központi KRÉTA felhasználók/ tanárok /intézményi adminisztrátorok számára bevezetésre került 2023 júniusában.
l) Az adatbázis biztonsági szabályzata (jogosultságkezelés, minimum jogosultság elve, szerepkörök szétválasztása) elkészült, kihirdetése a válasz időpontjában folyamatban volt.
m) A legmagasabb szintű jogosultsági körök a hálózatban 2023 januárjával felülvizsgálatra kerültek.
n) Az NSZFH (Nemzeti Szakképzési és Felnőttképzési Hivatal) környezetében található intézményi KRÉTA SQL szerverének ellenőrzése megtörtént.
o) Minden munkavállaló számára orientáció 2023. október 26. napján, hogy csak Windows vagy tanúsítvány alapú hitelesítést használjanak.
p) Felmérésre került, hogy a kulcsok tárolásához milyen szoftveres és hardveres feltételek szükségesek, ennek a bevezetése a tervek szerint 2023 év végéig megtörténik.
q) A rendszeres API kulcs cserékhez képest időközi kulcscserék kerültek végrehajtásra.

Döntés

Fentiekre tekintettel a Hatóság megállapította, hogy a Szervezet megsértette az általános adatvédelmi rendelet 33. cikk (2) bekezdését, mert az adatvédelmi incidenst nem jelentette be indokolatlan késedelem nélkül az adatkezelőknek.

Hatóság a bírság kiszabásakor súlyosító körülményként vette figyelembe a következőket:

– Az incidenssel érintett adatok kezelése az adatok mennyiségéből és jellegéből fakadóan kiemelkedően magas kockázattal jár, ezért a Szervezetnek fokozott elővigyázatossággal kellett volna eljárnia a kockázat mértékének megfelelő szintű adatbiztonság garantálása érdekében. A Szervezet ennek ellenére a nagyszámú érintettre kiterjedő, nagy mennyiségű személyes adat kezelésére használt rendszere folyamatos bizalmas jellegének biztosítása érdekében nem hozott az incidenst megelőzően megfelelő intézkedéseket. A jogsértés az elvárható adatbiztonsági intézkedések megléte esetén vagy be sem következett volna, vagy már 2022 szeptemberében megszüntetésre kerülhetett volna. A feltárt tényállás alapján ugyanakkor az incidens súlyának és az adatbiztonsági hiányosságok tényleges mértékének felismerésére csak 2022 novemberében került sor.

– A Szervezet felróható, gondatlan magatartása vezetett a fenti jogsértésekhez, a Szervezetnek az általa fejlesztett rendszer ismertsége és a benne tárolt személyes adatok mennyisége miatt is számítania kellett külső támadásokra, az általános adatvédelmi rendelet 32. cikkében említett technikai és szervezési intézkedések kötelezettsége pedig az informatikai támadások sikerességének elkerülés érdekében is került meghatározásra. Az a tény azonban, hogy a fent ismertetett intézkedéseket csak az incidens bekövetkezése után vezette be a Szervezet, arra utal, hogy a Szervezet könnyelműen bízott a támadások elmaradásában, és egy alapvetően magas kockázatú adatkezelés tekintetében a jogosulatlan hozzáférések kiküszöbölésére és kimutatására alkalmatlan, a kockázatokkal aránytalan adatbiztonsági intézkedéseket alkalmazott.

– Hatóság az adatvédelmi incidensről nem a Szervezet által, hanem a médiában megjelent hírek alapján szerzett tudomást.

– Arra, hogy a támadó mit kezd a támadás során megszerzett személyes adatokkal, nincs további ráhatása a Szervezetnek, ez a körülmény pedig a személyes adatok további sorsával kapcsolatban nagy mértékű bizonytalanságra ad okot.

Elérhető az adatvédelmi hatóság döntése itt.

II. Spanyol bank pénzmosási célú adatátadási csatornát érintő adatbiztonsági kérdések
Hatóság: Spanyol adatvédelmi hatóság (AEPD)
Dátum: 2023-2024.
Bírság: 2.500.000 euro (kb. 980 millió forint)

A spanyol adatvédelmi hatóság (AEPD) 2023. július 28-án tette közzé a PS-00331-2022 számú eljárásban hozott határozatát, amelyben egy panaszt követően összesen 2,5 millió euró bírságot szabott ki az Open Bank, S.A.-ra (Bank) az általános adatvédelmi rendelet (GDPR) megsértése miatt.

Adatkezelés körülményei

2021. augusztus 5-én az érintett panaszt nyújtott be az AEPD-hez a Bankkal, mint adatkezelővel szemben. Az érintett azt kifogásolta, hogy a Bank a bankszámláján lévő több pénzösszeg eredetének igazolását kérte, annak érdekében, hogy a Bank megfeleljen a pénzmosás elleni szabályoknak.

Az AEPD kiemelte, hogy annak ellenére, hogy az érintett aggályait fejezte ki az adatvédelmi kockázatokkal kapcsolatban, a Bank nem kínált alternatívát, mechanizmust a fenti információk biztonságos módon történő rendelkezésre bocsátásának megkönnyítésére, például az információk titkosításával vagy a webes portálra való feltöltésével, a panaszosnak az elektronikus levelezésen kívül nem állt rendelkezésére olyan mechanizmus, amellyel biztonságosan megadhatta volna ezt az információt.

Az AEPD volt illetékes vezető felügyeleti hatóságként eljárni, mivel a Bank székhelye és fő telephelye Spanyolországban található.

Hatóság megállapításai

Az AEPD megállapította, hogy a Bank megsértette a GDPR 25. és 32. cikkét.

Először is, a Bank hiányos adatvédelmi hatásvizsgálatot (DPIA) végzett. Bár az általános adatkezelésről DPIA-t készítettek, ez nem terjedt ki a személyes adatok pénzmosás elleni ellenőrzésekkel összefüggésben történő feldolgozására, mely mulasztás a GDPR követelményeinek való megfeleléshez szükséges megfelelő technikai és szervezési intézkedések hiányához vezetett. Az AEPD különösen megjegyezte, hogy a Bank által a panaszostól kért információk “pénzügyi adatoknak” minősülnek, ami egy sor megerősített intézkedés alkalmazását teszi szükségessé az adatvédelmi elvek hatékony alkalmazása és a szükséges garanciák beépítése érdekében az adatkezelésbe, hogy az megfeleljen a GDPR követelményeinek. Az AEPD megállapította, hogy a Bank nem alkalmazta a beépített és alapértelmezett adatvédelem elveit.

Az AEPD kiemelte továbbá, hogy a Bank ügyféladatok megszerzésére irányuló technikai és szervezési intézkedései nem nyújtottak megfelelő biztonságot a GDPR 32. cikkében előírtaknak megfelelően, tekintettel az érintett személyes adatok érzékeny jellegére. Ezzel kapcsolatban az AEPD megjegyezte, hogy még ha az adatkezelés egésze nem is minősült magas kockázatúnak, az adatkezelés egyes szakaszaiban megfelelő biztonsági intézkedéseket kellett volna alkalmazni a lehetséges kockázatok kezelésére.

Másodszor, az AEPD hangsúlyozta, hogy a protokollok vagy sablonok megléte önmagában nem elegendő a beépített és alapértelmezett adatvédelmi elveknek való megfeleléshez. A GDPR 32. cikkének (4) bekezdésében (valamint a vonatkozó pénzmosás és a terrorizmus finanszírozásának megelőzéséről szóló törvény (LPBCFT) előírt kötelező adatvédelmi hatásvizsgálat (DPIA) elvégzése önmagában nem elegendő a beépített adatvédelemnek a GDPR 25. cikkében foglalt követelményeinek teljesítéséhez. Ennek oka, hogy a GDPR 25. cikke szerinti kötelezettségek túlmutatnak az LPBCFT-ben meghatározott adatvédelmi szabályok puszta betartásán, hangsúlyozva, hogy a beépített és alapértelmezett adatvédelem több mint egy egyszerű hatásvizsgálat (DPIA) elvégzése.

Például a GDPR 25. cikkének való megfelelés érdekében a Banknak olyan protokollokat kellett volna kialakítania, amelyek közlik az ügyfelekkel, hogy az adott információt postai úton vagy személyesen a bankfiókokban is el lehet küldeni. Ehelyett az ügyfeleknek küldött közleményben csak az szerepelt, hogy az információkat titkosítatlan e-maileken keresztül is elküldhetik. Az AEPD megállapította, hogy egy szabványos e-mail nem tekinthető megfelelő eszköznek arra, hogy a személyes pénzügyi adatokat tartalmazó dokumentáció küldése során a kockázatnak megfelelő biztonsági szintet garantálja.

Az e-mailek biztonságát illetően a CNN-CERT BP02, a Nemzeti Kriptológiai Központ, a Nemzeti Hírszerző Központhoz rendelt szolgálat – amelynek feladata, hogy hozzájáruljon a spanyol kiberbiztonság javításához – 2021. évi jelentése tartalmaz egy sor e-mail sebezhetőséget és különböző támadási módokat, valamint biztonsági ajánlásokat. Az említett jelentés kiemeli, hogy még ha a TLS-kommunikáció sikeresen létre is jön, a levelezőszerverek, amelyeken az e-mail áthalad a célállomás eléréséig, hozzáférnének a tartalmához. Ezekből a tényekből következik, hogy nem elegendő az e-mail biztonságát a mögöttes technológiákra bízni, amelyek felelősek azért, hogy az e-mailt elküldjék a címzettnek.

Fent említett biztonsági hiányosságok fényében nyilvánvaló, hogy megerősített intézkedések elfogadására van szükség az e-mailben küldött személyes adatok sértetlenségének és bizalmas jellegének megfelelő garantálása érdekében, amikor különleges védelmet érdemlő személyes adatokat közölnek, mint például a jelen esetben, intézkedéseket nem alkalmaztak, ami nagyobb kockázatot jelentett a Bank azon ügyfelei számára, akik személyes adatokat küldtek ezen a csatornán keresztül.

Ebben a tekintetben az AEPD hangsúlyozni kívánja, hogy a jelen esetben az ügyfelek által szolgáltatott adatok különleges védelme miatt, valamint az ügyfelek jogaira és szabadságaira jelentett nagyobb kockázat miatt – amint azt korábban részletesen kifejtette – fokozott biztonsági intézkedéseket kellett elfogadni.

A Bank továbbá nem nyújtott bármilyen típusú segítséget az elküldött dokumentumok további titkosításához. Ebben az értelemben ez az AEPD jelezte, hogy a biztonság megteremtése az ügyfél műszaki ismereteinek szintjétől függ, és hogy rendelkezik-e a megfelelő eszközökkel. Ez a kockázatnak  Banktól az ügyfélre való átruházását jelentette.

Sem az AEPD, sem az EDPB jelentéseiben, állásfoglalásaiban, iránymutatásaiban és irányelveiben nem ismer olyan körülményt, amely jelezné a Bank számára, hogy úgy tekintse, hogy az e-mail használatának olyan intézkedésnek kell lennie, amelyet a személyes adatok későbbi feldolgozás céljából történő átvételét illetően meg kell tiltani általános jelleggel. Jelen ügyben sem szabad elfelejteni, hogy nem arról van szó, hogy az e-mail küldése bármilyen esetben és bármilyen kezelés tekintetében nem biztonságos eszköznek minősül, de tagadhatatlan, hogy jelen esetben nem volt megfelelő eszköz az LPBCFT II. fejezetében előírt információk megosztására, amely bizonyos megerősített intézkedések elfogadását írta elő. Minden esetben az adatkezelés körülményeinek vizsgálatával, ahol elvárt, adatvédelmi hatásvizsgálat elvégzésével szükséges mérlegelni az adatkezelés szempontjából megfelelő eszközök alkalmazását.

A Banknak az érintett által kifejezett aggályok után is intézkedéseket kellett volna hoznia, azonban a Bank csak több mint egy évvel később hajtott végre korrekciós intézkedéseket.

A Bank súlyosan hanyagul járt el az LPBCFT alapján a kért dokumentáció megküldésének módjának meghatározásakor, a Bank mindvégig nem hozott megfelelő biztonsági intézkedéseket a természetes személyek jogaira és szabadságaira jelentett kockázat alapján, még akkor sem, amikor egy ügyfél (mint a panaszos fél konkrét esetében) felhívta a figyelmet erre a kérdésre, még akkor sem, amikor a saját értékelő dokumentum hatásvizsgálata jelezte az LPBCFT alapján kért információknak a bank weboldalának privát felületén (felhasználónév és jelszó megadásával) keresztül történő megküldésének szükségességét, és jelezte, hogy ez a érintettek jogait és szabadságait érintő jelentős hatású adatkezelés.

A Hatóság megállapította, hogy a Bank csak 2022 októberében, több mint egy évvel később tette lehetővé a fenti lehetőséget, olyan mechanizmusok létrehozását, amelyek lehetővé teszik, hogy az érdekelt felek a Bank erre rendszeresített alkalmazásán, valamint a  Bank weboldalának privát felületén dokumentumokat nyújtsanak be.

Mindezek csak azt mutatják, hogy a Bank nem valósította meg szervezetében a beépített és alapértelmezett adatvédelem megközelítését, legalábbis a jelen szankciós eljárás tárgyát képező adatkezeléssel kapcsolatban.

Döntés

Az AEPD a GDPR 25. cikkének megsértése miatt 1,5 millió eurós, a GDPR 32. cikkének megsértése miatt pedig 1 millió eurós bírságot szabott ki.

Az AEPD súlyosbító tényezőként vette figyelembe a következőket:

– A jogsértés jellege, súlyossága és időtartama, figyelembe véve a szóban forgó adatkezelési művelet jellegét, hatályát vagy célját, valamint az érintett érdekelt felek számát és az általuk elszenvedett kár és sérelem mértékét.

– A Bank nem rendelkezett a kért dokumentáció megküldésére alkalmas eszközökkel az LPBCFT előírásai szerint, 2018 májusától 2022 októberéig, amely közvetlenül érinti a 65 000 érdekelt fél jogait és szabadságát, valamint potenciálisan 2 millió ügyfelet érint.

Elérhető a hatóság döntése eredeti nyelven itt.

Scroll to Top