Mobilalkalmazás fejlesztésnél egy sima e-kereskedelmi alkalmazásnál a bejelentkezés egy felhasználónév és jelszó kérdése. Egy pénzügyi szektorbeli mobilalkalmazásnál ez a kérdés hirtelen jogi, szabályozói és architektúrális problémává válik egyszerre.
Ez nem túlbonyolítás , ez a valóság. És ha valaki alábecsüli, azt drágán, extra időkkel fizeti meg a projekt közepén.
Miért nem elég a mobilalkalmazásoknál a "felhasználónév + jelszó"?
A PSD2 irányelv (Payment Services Directive 2) bevezette az erős ügyfél-hitelesítés (SCA - Strong Customer Authentication) fogalmát az EU-ban. A lényeg: fizetési vagy érzékeny pénzügyi műveletnél legalább két, egymástól független faktort kell igazolni - valamit amit a felhasználó tud (jelszó, PIN), valamit amit birtokol (telefon, hardver token), és/vagy valamit ami ő maga (ujjlenyomat, arcfelismerés). Ezt nevezzük "hétköznapi nyelven" kétfaktoros azonosításnak.
Ez nem opcionális kényelmi funkció. Ez jogi elvárás minden olyan alkalmazásnál, amely fizetési vagy befektetési műveleteket kezel. (Persze részben kényelmi is, mert sok felhasználó nagyon "kedveli", illetve biztonságérzzetet ad nekik a kétfaktoros mód.)
A gyakorlatban ez azt jelenti: a mobilalkalmazás architektúrájának a tervezés legelső napjától tartalmaznia kell egy erős, skálázható authentikációs réteget - nem egy utólag hozzácsatolt modult. Ennek természeteen a belső szabályzatokban is meg kell jelenniük. Tapasztalatunk szerint "felülről" nézve a 2 faktoros hitelesítés mindig ugyanaz, de a valóságban sok a cégszintű egyedi szabály. (PL: minden x-ik belépés uátn nem lehet biometrikus azonosítással belépni, hanem meg kell adni a kódot, vagy első belépésnél mi legyen a protokoll, vagy külön engedélyezni kell a biometrikus azonosítást az ügyfélnek vagy sem, vagy bizonyos tranzakcióknál nem engedélyezzük a biometrikus azonosítást, vagy mi történjen, pontosan, amikor lejár a jelszó) Ezwkben a réslzetkérdésekben sok eltérés van cégenként az authentikációs szabályokban és folyamatban. Az compliance officer-eknek azért mindenhol van egy kis szabadságuk a szabályozásban....Műszakilag pedig, ezek az apróságok sok feladatot jelenthetnek.
A tipikus hiba - authentikáció mint utógondolat
Sokszor látjuk ezt a mintát: a fejlesztés a felhasználói felülettel és az üzleti logikával indul, az authentikáció pedig "majd a végén" kerül be. Ez működik egy egyszerű alkalmazásnál. Egy pénzügyi szektorbeli mobilappnál viszont ez az architektúra újratervezését jelentheti a projekt vége felé, amikor ez a legdrágább. (Sokszor ez a majd a végén csak annyit jelent, hogy nem besélzjük meg a pontos részleteket, amelyek nem tűnnek nagy dolognak, vagy fontosnak, csak uátna egy beépülő 3rd party modulnál esetleg már nagyon nem lesz mindegy, hogy eészen pontosan hogyan is működik az authentikáció, milyen műszaki paraméterekkel stb.. (PL: Nem enged a 3rd party bizonyos megoldásokat....) Na ezeket a kérdéseket előre kell tisztázni, mert a teljes projekttel összemrhető extra átfutási időt jelenthet az utólagios módosítás.
Az ok egyszerű: az erős ügyfél-hitelesítés nem csak a bejelentkezésnél jelenik meg. Megjelenik minden érzékeny műveletnél , tranzakció indításánál, limit módosításnál, személyes adat változtatásnál. Ha ez nincs végiggondolva az architektúra tervezésekor, a "hol kell újra hitelesíteni" kérdés minden funkciónál újra felmerül, és inkonzisztens megoldásokhoz vezet.
Hogyan oldottuk meg egy valós projektben - Keycloak-alapú megközelítés
Egy pénzügyi szolgáltató ügyféloldali mobilalkalmazásánál a kétfaktoros azonosítást Keycloak-alapú identity és access management megoldással valósítottuk meg.
Miért Keycloak:
Nyílt forráskódú, de enterprise-szintű identity management megoldás, ami azt jelenti, hogy nincs licencköltség, ugyanakkor a funkcionalitása kiállja a pénzügyi szektor elvárásait. Beépített TOTP-alapú (Time-based One-Time Password) kétfaktoros hitelesítést támogat - a felhasználó egy authenticator alkalmazással (pl. Google Authenticator) generált, időalapú kódot ad meg a jelszó mellett. Azontúl, hogy az ügyfél ezt támogatta, mi is jó megoldásnak tartjuk, egyrészt azért mert jó technológiai laapokat ad, másrészt pedig lehet hozzá elégséges szaktudást és műszaki leírást találni. (Sokszor ez még fontosabb faktor, mint a tényleges mászaki paraméterek...)
A gyakorlati megvalósítás:
A felhasználó első bejelentkezéskor regisztrálja az authenticator alkalmazását , ez a "birtoklás" faktor. Minden bejelentkezéskor a jelszó ("tudás" faktor) mellett meg kell adnia az aktuális, időalapú kódot is. Kritikus műveleteknél, pl. tranzakció indításánál - a rendszer újra kérheti a második faktort, konfigurálható feltételek alapján. (A biometrikus azonosítást, mint fektort pedig az ügyfélélmény érdekében engedélyzzük.)
Az architektúrális előny:
A Keycloak nem csak az authentikációt oldja meg , a jogosultságkezelést (authorization) is központosítja. Ez azt jelenti, hogy a "ki mit láthat és mit tehet" logika nem az alkalmazás kódjába van szétszórva, hanem egy központi, auditálható rendszerben kezelt. Ez pénzügyi szektorbeli compliance szempontból kritikus előny , egy audit során sokkal könnyebb bemutatni és igazolni a hozzáférés-kezelést. További előny, hogy a keycloak architektúrát, mint különálló alapinfrastruktőra lehet menedzselni, így a fejlesztői cspattól elkülönülten, egy üzemeltető team tudja felügyelni a rendszert. Megítélésünk szerint ez egészséges munka-, és felelőségmegosztást ad. Az alkalmazás oldaláról pedig egy hívható kvázi "black box"., és nem kell hard kódolni a kódbázisba.
Amit a fejlesztés során tanultunk
A UX és a biztonság feszültségben áll - kezelni kell. Minden extra hitelesítési lépés súrlódást jelent a felhasználói élményben. A megoldás nem a biztonság csökkentése, hanem a kockázatalapú megközelítés: alacsony kockázatú műveleteknél (pl. egyenleg megtekintése) egyszerűbb a folyamat, magas kockázatú műveleteknél (tranzakció, limit módosítás) szigorúbb.
A biometrikus azonosítás jó kiegészítő, nem helyettesítő. Az ujjlenyomat vagy arcfelismerés kényelmes, de az eszközön tárolt biometrikus adat és a szerver oldali hitelesítés összekapcsolása gondos tervezést igényel , ez nem "csak bekapcsoljuk" funkció. Amint korábban is írtuk, sok apró részletszabályt lehet és kell definiálni, amely determinálja a megvalósítást....szóval nem lehet elnagyolni az implementáció ezen részét...mindent pontosan definiálni kelll. (Tapasztalat az is, hogy a szabályok élesítés után, a gyakorlati tapasztalatok alapján sok finomhangolást igényel.)
A recovery folyamat ugyanolyan kritikus, mint maga a hitelesítés. Mi történik, ha a felhasználó elveszíti a telefonját, amin az authenticator app fut? Ha erre nincs átgondolt, biztonságos folyamat, a support csapat fog ezzel küzdeni , sokszor biztonsági kompromisszumok árán.
Amit a FrontX-nél másképp csinálunk
Minden pénzügyi szektorbeli mobilalkalmazás-fejlesztésünknél az authentikációs architektúra a tervezés első lépései között szerepel — nem az utolsók között. Ez azt jelenti, hogy a compliance elvárásokat (PSD2, erős ügyfél-hitelesítés) már a wireframe és API-tervezési fázisban figyelembe vesszük, nem a fejlesztés végén próbáljuk "beilleszteni."
Ha pénzügyi szektorbeli mobilalkalmazás fejlesztése előtt állsz, ahol az authentikáció architektúrája még nyitott kérdés — szívesen konzultálunk: Frontx.hu/kapcsolat
Gyakran ismételt kérdések
Az erős ügyfél-hitelesítés azt jelenti, hogy fizetési vagy érzékeny pénzügyi műveletnél legalább két, egymástól független faktort kell igazolni: valamit amit a felhasználó tud (jelszó), valamit amit birtokol (telefon, token), és/vagy valamit ami ő maga (biometrikus azonosító). Ez jogi elvárás az EU-ban minden fizetési vagy befektetési műveletet kezelő alkalmazásnál.
Miért érdemes Keycloak-ot használni pénzügyi szektorbeli mobilalkalmazásnál?
A Keycloak nyílt forráskódú, enterprise-szintű identity és access management megoldás licencköltség nélkül. Beépített TOTP-alapú kétfaktoros hitelesítést támogat, és központosítja a jogosultságkezelést is . ami compliance és audit szempontból jelentős előny egy szétszórt, egyedi implementációval szemben. (E mellett megfelelő tudás, implementációs tapasztalat is elérhető a keycloak kapcsán a magyar piacon.)
Mikor kell újra kérni a második hitelesítési faktort egy mobilalkalmazásban?
Kockázatalapú megközelítést érdemes alkalmazni: alacsony kockázatú műveleteknél (egyenleg megtekintése) elegendő az egyszeri bejelentkezéskori hitelesítés, magas kockázatú műveleteknél (tranzakció indítása, limit módosítás) érdemes újra kérni a második faktort. Ez véleményünk szerint üzleti döntés kell, hogy legyen, inden szervezetnek meg kell hozni a kétfaktoros hitelesítésre vonatkozó szabályait.
Miért kell az authentikációt a fejlesztés legelején megtervezni, nem a végén?
Mert az erős ügyfél-hitelesítés nem csak a bejelentkezésnél jelenik meg, hanem minden érzékeny műveletnél. Ha ez nincs végiggondolva az architektúra tervezésekor, a projekt későbbi szakaszában drága, inkonzisztens utólagos módosításokat igényel. (A sok apró részletszabály sok műszaki kihívást hozhat, amelyet jó már a projekt elején látni, különen a projekt sokkal hosszabb leshet...)
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. Linkedin profil
