JaSipos IT biztonsági és audit Kft +36 70 931-3439 info@jasipos.com
Adatvédelmi Bírság NAIH DIGI Tesztadatbázis

Adatvédelmi bírság

Adatvédelmi bírság “országos csúcs”

2020. május 18-án új hazai rekord született: a Nemzeti Adatvédelmi és Információszabadság Hatóság ezen a napon 100 millió forintos adatvédelmi bírság fizetésére kötelezte a Digi Távközlési és Szolgáltató Kft-t egy adatvédelmi incidens miatt.

Mielőtt elmélyülnénk a részletekben, idézzük fel:

100 millió forint adatvédelmi bírság egy incidensért?

A reakciók szélsőségesek, leegyszerűsítve:

  • a Digi jól járt, mert a bírság árbevételének “csak” kb. 0,2%-a, holott a bírság maximuma az éves konszolidált árbevétel (47 299 383 ezer forint) 2%-a (kb. 1 milliárd forint), vagy 10 millió Euró (azaz kb. 3,5 milliárd forint) is lehetett volna;
  • a Digi indokolatlanul lett büntetve, hiszen senkit sem ért kár.

Mi vezetett ide?

Lássuk, mi történt (dióhéjban –  a nyilvánosság számára elérhető bővebb információ a határozatban olvasható).

  • A Digi létrehozott egy tesztadatbázist, amelybe betöltötte számos megrendelőjének és hírlevél-feliratkozójának személyes adatait, majd erről a vállalaton kívülről is elérhető tesztadatbázisról “elfelejtkezett”.
  • Egy etikus hacker rátalált az adatbázisra és észlelte, hogy abban számos természetes személy neve, anyja neve, születési helye és ideje, lakcíme, személyi igazolványszáma (esetenként személyi száma), e-mail címe, vezetékes és mobil telefonszáma található. Bizonyítékként letöltött egy rekordot és a biztonsági hiányosságról értesítette a Digi Kft-t.
  • A Digi a jogszabályi elvárásoknak megfelelően adatvédelmi incidensként kezelte az esetet: kivizsgálta azt, megszüntette a hiányosságot illetve az elvárt határidőn belül jelentette a NAIH felé, a történteket.
  • A NAIH vizsgálatot indított és megállapította a hiányosságot, majd határozatot hozott : az eredmény új adatvédelmi bírság rekord, kerek 100 millió forint.

A cikk írásakor számos nyitott kérdés van: a határozat nem tért ki például arra, mennyi ügyfél (?) lehetett érintett az incidensben, és arra sem, hogy az etikus hackeren kívül bárki is hozzáfért-e az adatokhoz.

Nem ismert az sem, hogy a Digi belenyugszik-e a határozatba (és az adatvédelmi bírság mértékébe) vagy bíróságon támadja meg a határozatot (ahogyan a korábbi “rekorder” tette).

FRISSÍTÉS [2020.06.27 23:44]: A Digi kommentje alapján bíróságon fogja megtámadni a határozatot, azonban a bírósági eljárás elindításáról a frissítésben jelzett időpontig információ még nem áll rendelkezésre.

Hogyan reagált a “szakma”?

Az IT biztonsági  és adatvédelmi szakemberek nyilván elemezni fogják az esetet és várható, hogy születnek majd összehasonlítások egy korábbi, szintén etikus hacker által azonosított hiányossággal (amikor az etikus hacker a BKK elektronikus jegyrendszerét “törte fel” – annak a jutalma 10 millió forintos NAIH bírság volt).

FRISSÍTÉS [2020.06.17 22:51]:

Cikkünk publikálását követően elkezdtek sorjázni a szakmai oldalak cikkjei, például

    • a HWSW cikke (“Rekord mértékű adatvédelmi bírságot kapott a DIGI”),
    • az Infostart cikke (“Rekord mértékű GDPR-bírságot kapott a DIGI”),
    • a Media1 cikke (“100 milliós bírságot kapott a DIGI, mert rossz gazdája volt az ügyfelei adatainak”),
    • a COMPUTERWORLD cikke (“Durva összegű bírságot fizethet a DIGI”),
    • a Jogaszvilag.hu cikke (“100 milliós adatvédelmi bírságot kapott a DIGI”),
    • az ITcafe cikke (“Súlyos adatvédelmi bírságot kapott a DIGI”),
    • a Pénzcentrum cikke (“Lecsapott a hatóság: csúnya bírságot kapott a Digi”)

és sorolhatnánk – gyakorlatilag minden lényegi oldalon foglalkoztak a NAIH határozattal – nyilván a rekordösszegű bírság miatt.

FRISSÍTÉS [2020.06.27 23:44]:

A hír elérte a nem szakmai portálok, blogok ingerküszöbét is – mutatóba néhány észrevétel:

    • origo (“Rekordösszegű bírság az adatvédelmi hatóságtól Digi-ügyben”),
    • kilonem100.blog.hu (“A GDPR egy európai kafkai rémálom: az adatvédelmi szabályozás nem teszi jobbá a piacot, sőt”),
    • borsod24 (“Rekord nagyságú büntetést osztottak a DIGI-nek egy adatvédelmi hiba miatt, a cég perre megy”),
    • pcx.hu (“A DIGI százmilliós adatvédelmi bírságot kapott – Törvénysértésről ezúttal nincs szó, de a súlyos adatkezelési mulasztások miatt fizetniük kell Kilenc éve ismert biztonsági rést hagytak figyelmen kívül”),
    • bitport.hu (“100 milliójába kerül a DIGI-nek az elhanyagolt biztonsági rés”),
    • hvg (“Kikerültek az ügyfelek adatai, százmillió forintos bírságot kapott a DIGI”)

Az első kérdés:

Elkerülhető lett volna az adatvédelmi bírság?

A második kérdés:

Mit kell tenni, hogy Ön ne kapjon adatvédelmi bírságot?

Kezdjük pozitívan: a rendelkezésre álló információ alapján a Digi példamutatóan kezelte az incidenst, le a kalappal előttük – ez lehetne egy külön cikk témája, ahogyan az is, miért lett mégis adatvédelmi bírság rekord a határozatban, de most tekintsük át,

milyen hibák vezettek az elmarasztaláshoz,

ezekből már szinte elkerülhetetlenül következni fog, mit kellett volna másképpen tenni, illetve Önnek mit kell tenni, hogy ne kerüljön hasonló helyzetbe.

A magyarázatok, példák során túl fogok lépni a konkrét eseten, azon nyilvánvaló okból, hogy jelenleg nincsen a NAIH határozaton túlmutató információnk – nyilván egy szervezet sem szívesen osztja meg a számára hátrányos információt, különösen úgy, hogy lehetséges, bíróságon fog folytatódni az ügy és a perbeli érdekérvényesítést ronthatná, ha idő előtt kommunikálna a részletekről, álláspontjáról.

FRISSÍTÉS [2020.06.17 22:51]: Cikkünk publikálását követően érkezett információ: a Digi kommentje alapján bíróságon fogja megtámadni a határozatot.

Hangsúlyozom ezért, hogy a következő “magyarázatok” általános szakmai hibákat mutatnak be, és határozottan NEM a Digi hiányosságait (hacsak ezt kifejezetten nem írom). A határozatban bemutatotthoz HASONLÓ helyzet tehát akkor fordulhat elő, ha:

  • valós üzemi (“éles”) adatokat használnak tesztadatbázisban – ez sajnos gyakori, mert
    • “A valós életben előfordult problémák, hibák a legjobb tesztesetek!” netán
    • “A tesztadatokat állandóan frissíteni kellene, és nincs idő mindig személyteleníteni az üzemi adatbázisból áttöltött adatokat.”, vagy
    • “A tesztelés olyan komplex, hogy ahhoz nem lehetséges hasonló komplexitású tesztadatokat generálni, a projekt költségvetése és átfutási ideje nem bírná el.”.
  • lehetséges, nem is tesztelésre, hanem egy üzemi adatbázis hibájának átmeneti javításáig a napi munkavégzés támogatására használják az adatokat – a jelenlegi határozatból ez gyanítható, azonban már a Digi sem emlékszik, milyen célra, mikor és hogyan kerültek a valós adatok a tesztadatbázisba, mert sem az üzleti, sem az informatikai oldalon nem tartották nyilván, abban a konkrét esetben mit és miért tettek az ügyféladatokkal – sajnos ez is gyakori szokott lenni, mert
    • “Az informatikusok tudják, mi kell a rendszerekhez, nem az üzleti felhasználók – hagyjuk őket dolgozni.”
    • “A tesztadatbázist úgyis el fogjuk dobni, arra a néhány napra nem kell ez a felesleges macera…”
    • “Csak próbálkozunk valami átmeneti megoldást összekalapálni, több ötletünk is van, nem kérhetünk mindegyikhez vezetői jóváhagyást, mert csak égő, hogy mi sem tudjuk, mi lesz nyerő elképzelés.”
  • mivel az adatbázisban ügyféladatok és hírlevélre feliratkozók adatai együttesen szerepelnek, lehetséges, nem is kellett volna valamennyi adatot betölteni az adatbázisba, de
    • “Adatbázisból adatot nem törlünk, mert az csak felesleges hibalehetőség – megszűnik az adatok közötti konzisztencia.”
    • “Adatbázisból adatot nem törlünk, mert még nem tudjuk, mely rekordok kellenek majd nekünk.”
    • “Adatbázisból adatot nem törlünk, mert nincs rá idő – ha létrehozzuk az adatbázist, azonnal el kell kezdenünk használni, nem játszadozni akarunk!”
  • az igénylési, jóváhagyási, végrehajtási és ellenőrzési funkciók nem működnek – erre az informatikusok általában legyinteni szoktak, vagy idegesek lesznek:
    • “Nincs nekünk időnk ennyi felesleges piszmogásra!” vagy
    • “Kevesen vagyunk, nincs lehetőségünk ennyi szerepkört kialakítani.” esetleg
    • “Nálunk univerzális szakemberek dolgoznak, akik tudják, mit és miért tesznek, önmagukat ellenőrzik.”
  • az adatokat nem titkosítják, mert
    • “Ezt csak belsős kollégák használják, külsősök nem ismerik az elérési utat [szájhúzás, legyintés]”
    • “Ez csak egy gyenge tesztszerver, a titkosítás csak lassítaná a munkát [homlokkopogtatás]”
    • “Erre a néhány napra miért titkosítsunk, ez nem a NASA! [vállvonogatás]”
    • “Ezek csak nevek és címek, ha megnézik a cégnyilvántartást, egymillió ilyet találnak, hahaha… [össznépi kuncogás]”
  • az adatok a vállalati környezeten kívülről is elérhetőek, mivel
    • “A külsős kollégáknak el kell valahogyan érniük a szervert, különben nem tudnak fejleszteni munkaidőn kívül”
    • “Nem lehet mindent korlátozni a tűzfalon, mert ha mellényúlunk, megállnak a rendszerek aztán kereshetjük a hibákat – ki tudja, melyik alkalmazáshoz milyen portot kell nyitva tartani.”
    • “Mindent tiltani és csak a szükségeseket engedélyezni? Hol élsz kisöreg, ki tudná, mi a szükséges?!?”
  • a nyilvánosságra hozott sérülékenységeket nem szüntetik meg, a javítócsomagokat nem telepítik, mivel
    • “Ki akarna ide betörni, ez csak tesztadatbázis?”
    • “Honnan tudjuk, mikor, mihez adnak ki frissítést, nincs nekünk időnk ennyi marhaságot figyelni, a rendszernek ketyegnie kell, az a lényeg.”
    • “Nincs időablak a patchelésre, mert ennek a rendszernek mindig mennie kell.”
    • “Majd amikor leállítjuk a rendszert, patchelünk – szóljál, ha majd akkor eszedbe jut és még fontos lesz.”
  • a szükségtelen adatbázisokat nem törlik, mert
    • “Örülünk, hogy létrehoztuk és végre tudjuk használni, dehogy töröljük!”
    • “Nekem kellene figyelni, hogy törölhető-e? Honnan tudjam, mikor lehet törölni? Még nem is dolgoztam itt, amikor létrehozták, azt sem tudom, ki kérte…”
    • Én aztán nem törlöm, senki sem meri kijelenteni, hogy már nem szükséges, én nem fogom a hátam tartani, hogy aztán majd rajtam verjék le, hogy valamit miattam nem tudnak megcsinálni!”
    • “Én csak üzemeltetek, nekem nem feladatom a törlés, az a biztonságiak dolga.”
    • “Én csak a biztonságért felelek, az adatbázisokat az üzemeltetők hozzák létre és tartják karban, nekik kell tudni, törölhető-e.”
  • a külső hozzáféréskor nem kerül sor riasztásra, ugyanis
    • “Miért lett volna furcsa, hogy kívülről is hozzáfértek? Mindegyik fejlesztőnk kívülről dolgozik…”
    • “Nincs nyilvántartás a felhasználókról, a biztonságot az adja, hogy csak a munkavállalók ismerik az elérési utat.”
    • “Központi naplóállomány gyűjtő és elemző rendszer? Tudod Te, mennyibe kerül az és milyen sok ember kell, hogy működtesse?”
  • a naplóállományokat nem megfelelően mentik, mert
    • “Mentés? Hova? Örülünk, hogy a szükséges adatoknak van hely: éles adatbázis, fejlesztői adatbázis, felhasználói teszt adatbázis… meg az az új valami, amin a most felvett emberek dolgoznak, amit nem is tudunk, micsoda…”
    • “Tesztadatbázist naplózni és menteni? Miért? Mi érdekes van egy tesztadatbázisban? Ja, nevek és címek – hát, tudod Te, mennyi Kovács úr létezik, nem mindegy, hogy itt vagy ott lakik?”
    • “Mentettük mi, de egy hét után felülírtuk, mert nem volt semmi probléma, akkor meg miért is kellene őrizgetnünk?”
  • az informatikai környezetet nem ellenőrzik, mert
    • “Belső ellenőr? IT auditor? Penetrációs teszter? Aztán a pénzt ki adja rá?”
    • “Van ellenőrünk, de megmondtuk neki, ne zavarja a munkát, mert ő is abból kapja a fizetését, amit megtermelünk.”
    • “Annyi hatóság, felügyelet auditálgat bennünket, hogy nem hiányzik még egy belső ellenőr a vérünket szívni!”
    • “Sérülékenységvizsgálatot, hogy megfeküdjön a rendszerünk? Éjjel, amikor a mentések mennek?”

Ismételten hangsúlyozom, a fenti példák “általános informatikus szövegek” és határozottan NEM a Digi szakembereitől származnak és még határozottabban NEM a jelenlegi sajnálatos eset hátterét mutatják be – annak ellenére, hogy már mindegyiket hallottam különböző, auditált szervezeteknél, viszont ha Ön hasonló magyarázkodást hall munkatársaitól, határozottan kezdjen el félni, mert könnyen hasonló cipőbe léphet, mint a DIGI.

A sok okoskodás után:

Szeretné elkerülni, hogy Önöket is adatvédelmi bírság sújtsa?

Mit kellene tenni, hogy hasonló eset Önöknél ne forduljon elő?

Csodák nincsenek, szisztematikus, kitartó munkát kell végezni. Tisztelettel adózva Benedek Tibor emlékének felidézzük, mit tartott ő sikerei titkának:

“… ha legvégül össze kellene foglalnom a sikereim okát, csak annyit mondanék, hogy mindig én akartam jobban”

Minimálprogram

  • fel kell mérni, felül kell vizsgálni a tesztadatokat tartalmazó adatbázisokat és
  • amennyiben nem szükségesek, törölni kell őket teljes mértékben, dokumentáltan (!),
  • amennyiben szükségesek:
    • meg kell akadályozni, hogy a Szervezeten kívülről elérjék a tesztadatbázisokat
      • ha ez bármi okból mégis szükséges, technológiai eszközökkel szabályozni és korlátozni szükséges, ki, mikor és hogyan érhető el az adatbázisokat (pl. ha a külső fejlesztő mindig éjjel dolgozik, számára nem indokolt a napközbeni hozzáférés, és fordítva: ha a tesztelők csak 6-12 óra között dolgoznak, számukra indokolatlan az ezen időszakon kívüli hozzáférés),
      • a “korlátot” a tesztadatbázistól “minél távolabb” kell felépíteni, és lehetőleg több szinten kell érvényesíteni (az IDS-ben, tűzfalban, VPN koncentrátorban  stb. korlátozni kell a felhasználót (le kell tiltani a távoli hozzáférését a mindig az irodában dolgozóknak), a belépés helyszínét (pl. a kizárólag Magyarországon munkálkodók esetében korlátozni kell az országon kívüli hozzáféréseket), valamint le kell tiltani a megbeszélt munkaidőn kívüli hozzáférési lehetőséget stb. – sőt, bármennyire is egyszerű, a MAC-address szűrés is lehet egy réteg,
    • a Szervezeten belüli tesztadatbázis-hozzáféréseket szintén a legszükségesebb személyekre kell korlátozni:
      • aki egy hónapig nem lép be az adatbázisba, attól meg kell vonni valamennyi hozzáférést (ha szükséges lesz, újra be lehet neki állítani),
      • a nevesítetlen vagy a több személy által használ felhasználókat meg kell szüntetni,
      • a szállító (gyártó) által létrehozott “beépített” felhasználókat lehetőleg át kell nevezni és a jogosultságaikat meg kell vonni,
      • ha lehetséges, be kell vezetni a kétfaktoros bejelentkezést valamennyi felhasználónál,
      • a különböző tesztadatbázisokban nem csak eltérő jelszavakat, de lehetőleg eltérő felhasználói azonosítót is kell adni a személyeknek (ha ugyanazon személy mindegyik tesztadatbázisban “Joska88” azonosítóval szerepel, innen csak egy lépés, hogy ugyanazt a jelszót is fogja használni),
      • kerülni kell a nyilvánvaló felhasználóneveket (“teszt”, “testuser”, “user”, “admin”, “guest”, “backup”, security”, “external”, “treasury”, “zsirosdeszka” (igen, az informatikusok között ez is tipikus…),
    • a tesztadatbázisokhoz hozzáférők jogosultságait a minimálisan szükséges, de elégséges szintre kell korlátozni (olvasási jogosultságon felül csak annak kell bármi jogosultságot beállítani, aki ÍRÁSBAN meg tudja indokolni a szükségletet és azt a felettese, valamint a tesztadatbázis létrehozását kérelmező felhasználó, valamint az informatikai vezető (ennek hiányában a leginkább respektált szakember) egyaránt ÍRÁSBAN jóváhagy; a napi szintű törlési jogosultság pedig általában senkinek sem indokolt (adatot óvatos informatikus nem töröl, “csak” az elérhetőségét korlátozza – a GDPR megkövetelte adattörlés eseti szokott lenni), a “drop table” utasításhoz pedig senkinek sem kell ÁLLANDÓ jogosultság – amikor szükséges, arra a néhány percre kell csak beállítani, utána visszavonni),
    • jelszópolicy-t kell bevezetni:
      • az üzemi adatbázisokkal megegyező védelmet kell kapnia minden tesztadatbázisnak, amelyben valós üzemi adatok szerepelnek,
      • legfeljebb öt sikertelen belépési kísérletet követően zárolni kell az azonosítót – feloldani csak ÍRÁSOS kérést követően szabad,
    • ki kell törölni a tesztadatbázisokból a nem releváns adatokat (a nem releváns mezőket és a teszteléshez szükséges számosságon felüli rekordokat egyaránt)
    • lehetőleg titkosítani kell valamennyi tesztadatbázist (ha valós felhasználói és egyéb, személyhez kötődő adatokat tartalmaznak),
    • át kell gondolni, szükségesek-e valós (éles, üzemi) adatok a teszteléshez és lehetőleg kiváltani őket tényleges tesztadatokkal (Teszt Terézia stb.), de legalábbis egyes adatokat át kell írni “generált adatokra”, például:
      • a neveket, édesanyja neveket véletlen karakterekre,
      • a születési adatok közül legalább a napot véletlen karakterekre kell cserélni,
      • a lakcímnél legalább a házszámot véletlen számra kell cserélni,
      • az adóazonosítót és egyéb hatósági azonosítót a szintaktikai szabályok szerint generált számra, karaktersorozatra kell cserélni

Első lépés az adatvédelmi bírság megelőzése érdekében

A valós helyzetet megismerése és a lehetséges gyengeségek azonosítása érdekében készíteni kell egy nyilvántartást, amely tartalmazza

  • valamennyi tesztadatbázis nevét, elérhetőségét, célját, létrehozási és utolsó használati idejét,
  • valamennyi tesztadatbázis további fenntartásának indoklását és a fenntartási időszak várható végét, az ezt igénylő üzleti felhasználótól származó indoklással és a felhasználó nevével, beosztásával,
  • valamennyi tesztadatbázis informatikai üzemeltetőjének nevét, beosztását, elérhetőségét,
  • valamennyi tesztadatbázis valamennyi felhasználójának nevét és beosztását (különös tekintettel a Szervezeten kívüli személyekre és a nevesítetlen, valamint a többek által használt felhasználókra ),
  • a tesztadatbázisokban tárolt adatok felsorolását (pl. milyen felhasználói és egyéb adatok találhatóak benne, meddig visszamenőleg, mikori állapot alapján készült, mely adatbázisból lett létrehozva stb.),
  • a tesztadatbázisokban tárolt adatok számosságát (pl. mennyi felhasználónak, mennyi adata található benne),
  • az egyes tesztadatbázis védelmére jelenleg alkalmazott megoldások leírását (különös tekintettel a felhasználói név és jelszó policy-re),
  • a tesztadatbázisok védelmére bevezethető további intézkedések leírását és a bevezetés határidejét,
  • a tesztadatbázis anominizálása érdekében alkalmazható intézkedéseket és azok határidejét,
  • a harmadik fél (külső szervezet, partner, fejlesztő, üzemeltető stb.) által üzemeltetett tesztadatbázisok esetében a fentieken túl
    • a Szervezet és a harmadik fél Adatkezelési tájékoztatójában a Szervezet felhasználóinak/ munkavállalóinak/ partnereinek adatainak kezelésére vonatkozó leírást,
    • a harmadik fél szerződéses kötelezettségvállalását arra vonatkozóan, hogy milyen védelmi intézkedéseket tett, tesz meg a jogosulatlan hozzáférések és módosítások megelőzése, azonosítása érdekében,
    • a harmadik fél Adatkezelési tájékoztatójában a Szervezet felhasználóinak/munkavállalóinak/partnereinek adatainak kezelésére vonatkozó leírást (tájékoztatást).

További lépések az adatvédelmi bírság megelőzése érdekében

A további lépések részben attól is függenek, hogy mi az eredménye a felmérésnek.

Örömmel segítünk Önnek, kérjük ezért vegye fel velünk a kapcsolatot.

KAPCSOLATFELVÉTEL

Általunk támogatott szervezet még nem kapott adatvédelmi bírságot, ami természetesen nem garancia arra, hogy ez a jövőben is így fog alakulni, de azért kedvező kiindulási alap a közös munkára.

Sipos János

CISA, CISM, CGEIT, CRISC, CFE, ITIL-F, ISO27001 Lead Auditor, Data privacy expert, CISO, CIO, engineer, economist

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

Ez az oldal az Akismet szolgáltatást használja a spam csökkentésére. Ismerje meg a hozzászólás adatainak feldolgozását .