(nem hivatalos e-kormányzati témájú oldal)
| Mottó: Digi-dagi elesett. /Digi-dagi, daganat c. mondóka/ | ||
| 2020. június 15. | ||
| GDPR: Digi... Dagi... Daganat... | ||
| A Digi Távközlési és Szolgáltató Kft. 2020-05-18-án megtapasztalhatta a NAIH határozata révén, hogy az EU-s GDPR rendelet milyen módon kényszeríti az adatvédelmi hibák, mint daganatok eltávolítására a különböző adatkezelőket, adatfeldolgozókat. Korábban már elemezgettem (ld. GDPR: Ha nem elég a PR...), hogy az EU-s GDPR rendelet mely cikkeiből eshet ki valamilyen műszaki követelmény, továbbfejlesztési igény, de végrehajtási rendeletek, műszaki specifikációk hiányában végül nem derül ki pontosan, hogy mely támadások ellen kell tudni védekezni, a sokféle technológia, ellenintézkedés közül melyiket érdemes használni. Éppen ezért rendkívül hasznos a mostani NAIH határozat leírása, az eset bemutatása, az indoklások és az ítéletek. (Az alábbi elemzés nem teljeskörű, csak bizonyos részeket emelek ki, azaz pl. a tesztadatbázisnál a létrehozás, a korlátozott tárolhatóság és a célhoz kötöttség elemzése most nem kerül terítékre.) A Nemzeti Adatvédelmi és Információszabadság Hatóság [...]A sok felmerült műszaki kérdés közül a 32. cikk (1) - (2) bekezdései a "személyes adatok [...] titkosítását", illetve a "tárolt [...] adatok [...] jogosulatlan nyilvánosságra hozatalából vagy az azokhoz való jogosulatlan hozzáférésből" fakadó adatszivárgások rejtjelezéssel történő megoldását érintik. Ezen felül a 33. és 34. cikk szerinti "adatvédelmi incidens orvoslására tett vagy tervezett intézkedéseket" is elemzik, azaz az üzemeltetési, patch management témákat is érintik. Titkosítás, rejtjelezés Még mindig az a kérdés, hogy pontosan kivel szemben kell védeni az adatok bizalmasságát? Csak a személyes adatokat kezelő vagy feldolgozó oldal, az adatbázisszerverhez fájlrendszer szinten hozzáférő belső rendszergazdájától (COPY) vagy a külső támadótól is, aki pl. az alkalmazásszerverre tud behatolni, ahol a connection string ismeretében JDBC/ODBC DB driver rétegen keresztül tud lekérdezgetni (SELECT), vagy attól, aki pl. a webes felületen, SQL injection (UNION SELECT) révén szerzi meg az adatbázis dump-ot? Korábban azzal nyugtáztam a kérdést, hogy a nagy SIEM (Security Information and Event Management) gyártók közül páran az általuk alkalmazott TDE (Transparent Data Encryption) miatt kirakták a GDPR Ready plecsnit a termékükre, miközben most kiderült, hogy SQL injection ellen is kell védekezni, amire sem a column-szintű Oracle TDE (Transparent Data Encryption), sem a MS SQL Server Always Encrypted nem elégséges. Igazából, csak a patch-elés jó, azaz az SQL injection lehetőségek megszüntetése (ld. OWASP Cheat Sheet Series: SQL Injection Prevention Cheat Sheet). Ha rosszindulatú lennék, akkor azt is mondhatnám, hogy ezen pár nagy SIEM gyártó megtévesztette az ügyfeleit a GDPR Ready plecsnivel... Nem olcsó egy-egy ilyen SIEM rendszer (illetve annak a bevezetése és üzemeltetése), de a jelen eset alapján hamis biztonságérzetet is adhat az ügyfeleknek, amiből majd csak egy NAIH bírság ébresztheti fel őket... Üzemeltetés, patch management A NAIH határozat szerint probléma, hogy "A biztonsági rés egyébként már több mint 9 éve ismert volt és rendelkezésre állt hozzá javítás is, [...] azonban [...] a javítás nem képezte részét a szoftverhez hivataloson kiadott javítás-csomagoknak.". Ez felvet olyan kérdéseket, hogy vajon minden rendszernél be lehet-e vállalni nem hivatalos (unofficial) patch telepítését?! Ki vállalja ezért a felelősséget egy (mission) critical infrastructure rendszernél? Természetesen, fordítva is feltehető a kérdés: ha ismertté válik egy sérülékenység, akkor szabad-e halogatni a patch-elést, a workaround berakását? Ki vállalja ezért a felelősséget egy (mission) critical infrastructure rendszernél? A jelen rendszernél a leírás szerint a tartalomkezelő (CMS - Content Management System) volt a sérülékeny pont, ami lehet, hogy valamelyik népszerű PHP-s, azaz script-nyelves, nyílt forráskódos megoldáson alapul (pl. WordPress, Joomla, Drupal, Magento, Chamilo). Ez azt jelenti, hogy ha a sérülékenység nyilvános és megfelelően van dokumentálva (pl. CVE - The MITRE Corporation), akkor van lehetősége az üzemeltetőnek (fejlesztői segítséggel) javítani, egy workaround bekerülhet addig, amíg kijön a hivatalos (official) patch. Hogy elkerülhető lett volna-e a NAIH bírság? A régóta nyilvános, kezeletlen sérülékenység - már csak saját üzemeltetési szempontok miatt is - fontos, hogy vagy a nem hivatalos (unofficial) patch révén vagy egyéb workaround révén, de legyen javítva (ha tényleg PHP-s a CMS, akkor erre lett is volna lehetőség). A nyilvános sérülékenységi adatbázis alapján történő rendszeres ellenőrzés (mission) critical infrastructure rendszernél alapvető fontosságú (pl. Drupal CMS kapcsán 2002-ig visszamenőleg több, mint 1000 CVE jegy került felvételre), tehát az nehezen védhető, hogy 9 év alatt nem derült fény erre. A bírság ezen része szerintem indokolt (egy 0-day vulnerability esetén viszont valószínűleg más lett volna a helyzet). A NAIH határozat másik oldala viszont már aggályos... Ha sem az EU rendelet, sem a mögötte levő szakik, sem a nemzeti hatóságok (pl. NAIH) nem adnak műszaki útmutatásokat a rendelet high-level jogi szövegeihez, akkor nehéz a megfelelést biztosítani egy terméknél, illetve a terméket használó szolgáltatásnál. Mindenki másképp tudja értelmezni a jogi szövegeket, mindenki másra (más attack vector-ra) tudja azt mondani, hogy védett ellene a rendszere, azaz GDPR Ready. Természetesen, ha valaki semmit nem tesz - még a TDE (Transparent Data Encryption) funkciót sem állítja be az adatbázisban -, akkor az nehezen védhető, de tudni kell, hogy akár ezen TDE esetén is kiszivárogtak volna egy SQL injection sérülékenységen keresztül az adatok. TDE az ellen nem véd! De akkor miért nem adnak műszaki útmutatásokat a rendelet high-level jogi szövegeihez? Általában alapértelmezetten szoktak születni végrehajtási rendeletek, műszaki specifikációk az ilyen komoly rendeletekhez (pl. eIDAS), de a GDPR esetében ezek elmaradtak. Anno, a közelgő hatályosodási határidő, azaz 2018-05-25 előtt én is beküldtem hivatalos csatornán keresztül a kérdéseimet a NAIH felé, még NAIH be is fogadta (2018\EBE\0000150 azonosító alatt igazolt vissza), de válaszokat végül nem adott (2020-06-15-ig).
Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
