Minden adatunkat tárolják, de nem mindegy, hogyan
A pénzügyi szolgáltatók gyakorlatilag minden olyan adatunkat tárolják, amelyek az adott szolgáltatás lebonyolításához szükségesek: jelszavakat, e-mail címeket, telefonszámokat, személyes adatokat, számlaszámokat, az utalások alapján feltérképezhető kapcsolati hálókat, a pénzügyi tranzakciókat és azok lebonyolítási körülményeit. Ezért fontos, hogy az ügyfél számára átlátható legyen, pontosan milyen adatokat is tud róla a szolgáltató, és hogyan gondoskodik azok védelméről – fogalmaz Szabolcsi András, a BlockBen informatikai igazgatója.
A digitális pénzügyi fejlesztésekkel foglalkozó cég szakértője kiemeli: az adatok tárolásában két védelmi vonal létezik. Az egyik maga az adatbázis a tárolt adatokkal, amely esetében ma már az is megoldható, hogy embernek egyáltalán ne legyen hozzáférése, csupán az adatbázist kiszolgáló szerverhez. Ez esetben például egy rendszergazda tudja üzemeltetni az adatbázis szervereket, de magukhoz az adatokhoz nem fér hozzá, a titkosított tárolás miatt.
A másik védelmi vonal, hogy a legérzékenyebb adatokat, jelszavakat, PIN kódokat különféle adattitkosítási megoldásokkal tárolják és titkosított csatornákon továbbítják. A szakértő úgy látja a sajtóhírek alapján: a Revolut esetében úgy tűnik, hogy nem alkalmazták a fenti eljárásrendet megfelelően, vagyis az adatokhoz való közvetlen hozzáférés és az adatbázis szerverekhez történő hozzáférés szétválasztását.
Csomagkézbesítés helyett adatlopás
Adatainkat rengeteg módon próbálják ellopni. A legegyszerűbb az adathalász módszer, a végfelhasználókat véve célkeresztbe. Ez sokkal olcsóbb, mint egy pénzügyi szolgáltató rendszereit feltörni. Adathalász módszer például, amikor egy, a valódihoz hasonlító vagy teljesen ugyanúgy kinéző weboldalt hoznak létre és ott kérik be a banki adatainkat.
Láttam már csomagkézbesítő szolgálat kártyás fizetési oldalát lemásolva. Ha csomagot vártam volna, akkor lehet, én is beleestem volna a csapdába, mert a webcím jónak tűnt elsőre és a kis zöld lakat is ott volt. Az oldal kinézete, az ikonok, a nyelvhasználat szintén rendben voltak. Egy dolog lett gyanús: túl gyorsan betöltődött az oldal! Emiatt kezdtem gyanakodni, mert a kriptográfiai algoritmusok és a fizetési protokollok egyszerűen nem lehetnek ilyen gyorsak. Ekkor, megnézve alaposan a webcímet, vettem észre, hogy két betű fel van cserélve benne. Összesen ennyi volt az árulkodó jel – érzékelteti Szabolcsi András, mennyire kifinomultak az adathalászok trükkjei.
Ugyancsak gyakori csalási módszer a különféle adathalász mobil applikációk használata vagy meglévő applikációk megfertőzése. Ilyenkor a csalók képesek akár még az SMS üzeneteket is eltéríteni, vagyis ma már az SMS alapú, kétfaktoros bejelentkezés is kijátszható. Ilyen eset történt pár hete az Európai Unióban is – emlékeztet a szakértő. Éppen ezért egyre többen ajánlják az SMS alapú, kétfaktoros hitelesítés helyett az autentikátor applikáció alapú megoldást (TOTP), amely egyszer használatos jelszavakat generál a felhasználó telefonján.
Hogyan védhetők meg adataink?
A szolgáltatók természetesen több szinten is igyekeznek védeni a felhasználókat. Technológiai szinten például valamilyen kriptográfiai megoldáson alapuló adathozzáférési szabályrendszer kidolgozása jelenthet erősebb védelmet.
Azonban felhasználóként fel kell ismernünk: a szolgáltató önmagában már nem mindig képes megvédeni minket. Folyamatosan fejlődnünk és tanulnunk kell, például annak érdekében, hogy a szolgáltatók idővel a jelszó alapú hitelesítést felválthassák digitális kulcs alapú és jelszómentes megoldásokra. Tudomásul kell vennünk azt is, hogy a pénzügyi szolgáltatók igyekeznek ugyan kényelmesebbé tenni az életünket, ám a kényelem és a biztonság sokszor két ellentétes igény.
Forrás: pénzcentrum
Nemrégiben az utóbbi évek egyik legkomolyabb IT biztonsági incidense történt, amikor a pénzváltással és pénzügyi tranzakciókkal foglalkozó Revolutot érte hackertámadás. Mintegy 50 ezer felhasználó – köztük magyarok – adatai szivároghattak ki, a csalók a hírek szerint bizonyos bankkártyaadatokhoz is hozzájuthattak.
