Miközben sokan a biometrikus azonosítástól féltik személyes adataikat a PSD2 bevezetése kapcsán, a legnagyobb veszélyeket máshonnan kellene várni.

A nyílt API-kban rejlő biztonsági kockázatokkal először a pénzügyi szektornak kellett intenzíven szembesülnie. A 2015-ben elfogadott, de csak tavaly szeptember közepén élesedő PSD2, azaz a pénzforgalmi szolgáltatásokról szóló módosított EU-irányelv ugyanis előírja a pénzintézeteknek, hogy megnyissák bizonyos ügyféladataikat külső szolgáltatók felé – természetesen csak akkor, ha ahhoz az ügyfél is hozzájárul. Az EU olyan nyílt API-k létrehozására kötelezte a bankokat, amelyeken keresztül az ún. AISP-k (Account Information Service Provider), amelyek a bankoknál vezetett folyószámlák adatai alapján nyújthatnak kényelmi szolgáltatásokat és a PISP-k (Payment Initiation Service Provider), amelyek fizetés-kezdeményezési szolgáltatásokat nyújtanak, elérhetik ezeket a banki adatokat.

Mekkora a kockázat?

Azt, hogy ez mekkora biztonsági kockázattal jár, egyelőre még mindig csak becsülni lehet, aminek talán az a legfőbb oka, hogy egyelőre kevesen használják. A közelmúltban Becsei András, a Bankszövetség alelnöke, azt állította egy konferencián, hogy miközben az európai bankok sok milliárd eurót költöttek el arra, hogy lényegében a versenytársaikat, azaz a banki piacot elfoglalni igyekvő fintecheket hozzák helyzetbe a PSD2-nek való megfelelésükkel, maguk a fintechek nem használják a nyílt bankolás nyújtotta lehetőséget. Ugyanezen a beszélgetésen azonban az is felvetődött, hogy az EU-direktívának az azonnali fizetéssel együtt már nagyon komoly hatással lehet a pénzügyi szektor innovációjára.

Becsei szavaiból azonban az következik, hogy egyelőre valójában nem sokat tudunk arról, milyen kockázatokkal jár a nyílt bankolás. A proof-of-conceptek ugyanis legfeljebb elképzelt forgatókönyveken alapulhatnak. Abban azonban minden érintett egyetért, hogy új, nagy figyelmet igénylő kockázati tényezővel gyarapodott a kibertér. A PSD2 már eleve számolt a növekvő kockázatokkal, azért is követeli az erős, többfaktoros azonosítást, illetve szorgalmazza a biometrikus azonosítás alkalmazását.

Utóbbi azonban paradox módon sok felhasználónál nem a biztonság erősödésével kapcsolódott össze, hanem épp ellenkezőleg! A Paysafe egy tavaly ősszel lefuttatott nemzetközi kutatásából például kiderül, hogy a németek egyenesen veszélyesnek tartják, ha a bankjuknál biometrikus azonosítást is kell használniuk.

Pedig nem itt van a probléma...

Az erős ügyfél-hitelesítésre azonban nem tudott időben felkészülni a világ. Ezért a PSD2 hatályba lépésekor az Európai Bankhatóság engedélyezte az erős hitelesítés bevezetésének elhalasztását 2020. december 31-ig. Sok más országhoz hasonlóan a Magyar Nemzeti Bank is élt ezzel a lehetőséggel. Ez probléma, mert tovább növeli az amúgy is nagy támadási felületet. A fintechek mint harmadik felek belépésével például új adatszivárgási forrás keletkezhet. (Ha egy fintechnél sérül az ügyfél adata, akkor azt a bankszámlája is megérezheti). Ezt valamelyest enyhíti a GDPR, amely előírja a pénzintézeteknek, hogy az ügyfelek adatait használó harmadik fél is megfelelően védje a banktól hozzá kerülő adatokat. Emellett érkezhet támadás harmadik fél mobil vagy webes appjának biztonsági hibáin keresztül, vagy a harmadik fél alkalmazottjaitól (pl. banki csalások).

Bankoknak ezeket a lehetőségeket például tranzakciós kockázatelemzéssel, a tranzakciók és a felhasználók viselkedésének figyelésével lehet csökkenteni. Ezért írta elő a szabályzó hatóság a többfaktoros azonosítást (biometria), a kommunikációs csatornák védelmét (biztonságos kommunikációs protokoll használata), a bank és a külső pénzügyi szolgáltató kölcsönös hitelesítését stb. Utóbbiaktól megköveteli, hogy osszák meg banki partnereikkel a független biztonsági auditálásuk eredményeit.
 

Ilyen környezetben kell működnie a nyílt API-nak


És végül, de nem utolsósorban el kell kerülni a nem megfelelő API-implementálásból eredő biztonsági sebezhetőségek kialakulását.

Ezt javasolják a biztonsági szakértők

A problémakör a bankok számára ismert, biztonságuk a napi gyakorlatban is azok köré épül. Az API-biztonság azonban minden érdekelt számára új. Vannak azonban olyan alapszabályok, melyek itt is érvényesek.

A legfontosabb ugyanis az, hogy mind a banknak, mind a külső szolgáltatónak meg kell győződnie arról, hogy az API által használt adatformátumtól függetlenül az alkalmazásprogramozási felület adatstruktúrákat feldolgozó szoftveres komponense ellenálló a kibertámadásoknak. Értsd: nincs olyan biztonsági rés, amin keresztül a kiberbűnözők hozzáférhetnek az ügyféladatokhoz és a tranzakciós információkhoz. Ezért minden API-t, sőt minden érintett eszközt(!) alá kell vetni biztonsági elemzésnek és tesztelésnek.

A biztonsági szakértők viszonylag egységes álláspontot képviselnek az API-védelemmel kapcsolatban. Szükség van például az API-infrasturktúrához is egy olyan dedikált biztonsági gateway-re, amely a vállalatot és az ügyfelek személyes adatait is védi. Ennek a gateway-nek a feladata, hogy megakadályozza az illetéktelen hozzáférést (hekkertámadás), és hogy csak a megfelelő kérések jussanak el a szerverig és az adatbázisig. Ennek érdekében egy ilyen gateway-nek kell a feleket azonosítani és hitelesíteni, a kéréseket és a válaszokat validálni, titkosítani a forgalmat, szűrni a tartalmat stb.

De még ilyenkor is bejuthatnak az API-infrastruktúrába kiberbűnözők. Azért a folyamatos figyeléshez szükség van megfelelően definiált API-biztonsági házirendekre, olyan naplózásra, amely a hozzáférési kérelmekre és tranzakciókra figyel, illetve alkalmas a titkosított HTTPS-csatornák monitorozására is.

Az API azonban nem csak a pénzügyi szektorban új kockázati tényező, hanem más iparágakban is. Összeállításunk következő részében utóbbiakkal foglalkozunk.

Biztonság

Újabb malware-figyelmeztetés az egészségügyi intézményeknek

A Nemzeti Kibervédelmi Intézet szerint több hazai egészségügyi intézmény infrastruktúrájának érintettsége is felmerült az Emotet malware-t terjesztő email-kampányokban.
 
Hirdetés

A hatásos védelemhez egy webalkalmazás-tűzfal ma már nem elég

A Proxedo API Security túllép a hagyományos webalkalmazás-tűzfalakon: hatásosan védi az API-végpontokat.

Bár a PSD2 kapcsán váltak széles körben ismertté az API-kban rejlő kockázatok, nem kell külső, harmadik fél ahhoz, hogy ezek a kockázatok testet öltsenek.

a melléklet támogatója a BalaSys

Nem általában a távmunkáé, hanem a mostani tipikus távmunka-helyzeteké. A szervezetek arra nem voltak felkészülve, hogy mindenki otthonról dolgozik.

Alapjaiban kell megújítani a biztonságról kialakított felfogásunkat

Tavaly január végétől megszűnt a Java SE 8 ingyenes frissítése, és a Java SE 11 sem használható ingyenesen üzleti célra. Tanácsok azoknak, akik még nem találtak megoldást. Hegedüs Tamás (IPR-Insights) írása.
Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizenegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2020 Bitport.hu Média Kft. Minden jog fenntartva.