Összeállításunk előző részében röviden összegeztük azokat a változásokat, melyek a felhős IT-biztonság területén a közelmúltban bekövetkeztek. A hatást kisebb-nagyobb mértékben mindannyian érezzük, hiszen szinte mindenki használ vagy vállalkozásként, vagy végfelhasználóként felhős szolgáltatást. Bár nem áll rendelkezésre pontos statisztika arról, hogy a cégek átlagosan hány szolgáltató publikus felhőjét használják párhuzamosan, a különböző részinformációk alapján piacelemzők 2 és 3 közöttire becsülik a számot.

Arról még kevesebb tudásunk van, hogy mi a helyzet a magyar piacon. A Deloitte és a BellResearch egy idei, az IVSZ megbízásából készített elemzése (Felhőtechnológiák Magyarországon: Gazdasági hatástanulmány, PDF) például az általában idegen tollakkal ékeskedő Statista adataira hivatkozva adja meg a magyar publikus felhőpiac árbevételi előrejelzéseit. Valószínűsíthető tehát, hogy a tanulmány megrendelőjének, a hazai IKT-szakma első számú lobbiszervezetének sincsenek mély ismeretei erről a piacról. (Az adathiányra és a rendelkezésre álló információk ellentmondásosságára egyébként a tanulmány is utal.)

Egy azonban bizton állítható: a (publikus) felhőhasználat általánosságban nő, és a növekedés forrása elsősorban a nagyvállalatok felhőbe költözése. Ez hatással volt a felhős biztonsági megoldások iránti kereslet növekedésére is. Mint a magyar elemzésben olvasható: "a vírusirtó programok, amelyek általánosan elterjedtek a hazai vállalkozásoknál, az erős online komponensük (frissítés, adatok beküldése) miatt szintén tekinthetők válaszadói oldalról felhőalapú alkalmazásoknak – noha a valódi, felhőalapú hálózati megoldásokhoz kapcsolódó biztonsági megoldások ennél messze komplexebbek és magasabb szintűek, célcsoportjuk is számottevően szűkebb".

Felértékelődő API-biztonság

A felhő hatása az üzleti alkalmazásokra – természetesen elnagyoltan és erős megszorításokkal – így írható le. Monolit on-premise alkalmazásait egyre több szervezet cseréli mikroszolgáltatás architektúrán alapuló megoldásokra, serverless alkalmazásokra stb. Ezek használatához azonban API-kra (alkalmazásprogramozói felület) van szükség. API-k segítségével történik az adatcsere különböző mikroszolgáltatások között vagy egy app és a felhasználó között. API-k biztosítják például third-party fejlesztőknek, hogy alkalmazásaikba beépíthessék a közösségi platformok (Facebook, X stb.) egyes funkcióit és így tovább. Ha úgy tetszik, az API-k segítenek megvalósítani, digitális formában leképezni egy vállalkozás üzleti logikáját.

A kiberbűnözők pedig hamar felfedezték: itt egy új támadási felület keletkezett. Az OWASP (Open Worldwide Application Security Project) a fejleményekre 2019-ben egy API-biztonsági útmutatóval reagált, melyet tavaly frissített. Bár az API-k elleni támadások végrehajtása komolyabb szakértelmet igényel, mint mondjuk egy szolgáltatásként igénybe vett DDoS támadás vagy spam-kampány, de az elérhető haszon szintén nagyobb. Ez az API-k elleni támadások gyarapodásában is tükröződik.

A Radware első félévre vonatkozó jelentése szerint az API-k elleni támadások száma 22 százalékkal nőtt 2023 azonos időszakához viszonyítva. Az incidensek mintegy harmadánál különböző ismert és nulladik napi sérülékenységeket használtak ki a támadók.

Alapkészlet a védekezéshez

A szervezetek leggyakrabban két alapvető eszközt alkalmaznak az üzleti folyamataikba egyre mélyebben beágyazódó API-k védelmére: API-gatewayeket és/vagy WAAP (Web Application and API Protection) megoldásokat.

Az API-gateway köti össze a felhasználót a háttérszolgáltatással. Kezeli az API-hívásokat, azokat a megfelelő szolgáltatáshoz irányítja, valamint kikényszeríti a házirendeket. Azaz menedzseli a forgalmat, hitelesít és engedélyez, valamint biztosítja az alapvető biztonsági funkciókat (fehérlistát IP-címek nyilvántartása, naplózás, DoS-védelem stb.).

A WAAP-megoldások egy szinttel feljebb, az alkalmazásrétegben dolgoznak: védik a webes alkalmazásokat. Ehhez meglehetősen összetett eszközkészletet használnak, így a fenyegetések széles skálája ellen alkalmazhatók. Általánosságban egy WAAP.eszközben van webalkalmazás-tűzfal, amely véd a leggyakoribb webes támadástípusok ellen (SQL injekció, a cross-site scripting stb.). Van benne API-specifikus védelem, és felismeri az automatizált támadásokat (rosszindulatú botok) is. Egyre több szállító tesz WAAP-eszközébe gépi tanulási modult, amely valós idejű adatok segítségével veszi fel a harcot a támadókkal (pl. anomáliafigyelés).

Nem kell veszélyes kódot bevinni

Van azonban egy olyan támadási forma, amely ellen önmagában a gateway és a WAAP csak korlátozottan véd: az ún. üzleti logika megsértésén alapuló támadásokkal (Business Logic Attack, BLA) szemben együtt sikeresebbek lehetnek. Az üzleti logika az üzlet agya: meghatározza a felhasználói felület működését, a felület és az adatbázisok interakcióját. Leírja például, hogy egy bank adott hitelnél hogyan számít kamatot, egy szolgáltatás hogyan kalkulálja az ügyfélkedvezményt stb., és ezeket az adatok szintjén is végigviszi, azaz az üzleti logika szabályai alapján különböző műveleteket hajt végre az adatokon (az üzleti logika biztonsági szempontú leírásához érdemes átkattintani az alkalmazásbiztonsági megoldásokra specializálódott Imperva oldalára). De mi köze ehhez az API-knak?

Az alkalmazásban az üzleti logikát az a kódréteg reprezentálja, amely meghatározza az adatok feldolgozásának és a végfelhasználó számára történő bemutatásának módját. Az API-knak ebben van kulcsszerepük. Segítségükkel lehet az üzleti logikát könnyen és gyorsan módosítani, skálázni horizontálisan (új mikroszolgáltatások és konténerek bekapcsolása, terheléselosztás, gyorsítótárazás stb.) és vertikálisan (API-végpontok sebességének, a kérések számának korlátozása, kód és algoritmus finomhangolása, hardveres erőforrások bővítése stb.).

Ahhoz, hogy az üzleti logika (végső soron a vállalkozás üzleti modellje) jól működjön, kritikus feltétel, hogy konzisztens adatok álljanak rendelkezésére. Szükség van továbbá a részvevők folyamatos kontrolljára: felhasználói szerepkörök létrehozásával és azokhoz rendelt engedélyekkel meg kell határozni, hogy milyen szerepkörben lévő közreműködő milyen adathoz milyen jogosultsággal férhet hozzá. Végül, de nem utolsósorban garantálni kell, hogy az adatok módosítása megfeleljen az üzleti szabályoknak, és észszerű legyen (pl. ne lehessen megadni negatív értéket raktárkészletre). Mindezek tükrében könnyen belátható, hogy az üzlet szempontjából mennyire kritikus, ha ezt az üzleti logikát éri támadás.

Ezeknek a támadásoknak a rákfenéje az, hogy nehezen detektálhatók. A támadó ugyanis nem a rendszert, hanem "csak" az üzleti szabályokat, folyamatokat manipulálja. Azaz a hagyományos eszközök (pl. tűzfal) szempontjából nem változik semmi. Az alkalmazás vagy rendszer továbbra is legitim funkciókat használ: kamatot számít, utal, kedvezményt kalkulál stb. Ha például kiberbűnözők meghekkelik egy bank utalási rendszerét, hogy az online banki felületen vagy mobil appban a saját számlák közötti utalások végcélja a támadók számlája legyen, a banki rendszer funkcionális szempontból korrektül működik, nincs benne káros kód, amit pl. egy víruskereső kiszúrhatna, nincs illegális hozzáférési kísérlet stb. De a tranzakció az üzleti logika szempontjából hibás, hiszen a kimenete helytelen.

Ki kell használni a szinergiákat

Az ilyen támadásokat több különböző védelmi eszköz, például az API-gatewayek és a WAAP-ok összehangolásával lehet megoldani. Az API-gateway biztosítja a kritikus biztonsági ellenőrzéseket (forgalomkezelésre, hozzáférés-szabályozás). Ha jól konfigurálták, akkor csak a legális forgalmat engedi hozzáférni a háttérszolgáltatásokhoz. Ám a forgalom természetét az üzleti logika szempontjából nem vizsgálja.

Ezen a ponton lép be a WAAP: elemezi az API-hívásokat, hogy azonosíthassa a BLA-kra utaló viselkedési mintákat. Nézi például az API-hívások sorrendjét és gyakoriságát, így viszonylag nagy biztonsággal felismeri, ha támadók megkísérlik manipulálni egy API üzleti logikáját.

A két eszköz integrációjának vannak egyéb járulékos előnyei is: például átfogóbb védelmet nyújt a jogosulatlan kéréseken alapuló összetettebb támadásokkal szemben, a WAAP-ok kontextuális intelligenciája segíti az API-átjáró biztonsági házirendjének a finomhangolását.