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.

É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.