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

Mennyit is keres most egy IT-szakember? Itt egy válasz...

A No Fluff Jobs állásportál friss felmérése szerint továbbra is sokat, és ezt most maguk az alkalmazottak erősítették meg.
 
Hirdetés

Van olyan tanácsadó, aki pénzt hoz?!

Pedig külső szemlélőként csak annyit mutat meg, hogy miből van hiány és miből van fölösleg. Ám ha szoftverlicencekről van szó, ez százmilliókat is érhet – megtakarításban.

Érdemes-e használt szoftvert venni a vállalatnak? És ha igen, hogyan? Egy biztos, nem úgy, mint egy használt autót.

a melléklet támogatója az IPR-Insights

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.