Van egy viszonylag új és iparágtól függetlenül meglehetősen népszerű területe a vállalati informatikának: a mikroszolgáltatás-architektúra, ami a vállalaton belüli, harmadik felek elől elvileg elzárt API-k kockázatait is felszínre hozta. De mi köze a mikroszolgáltatásoknak az API-khoz?

A rugalmasság követelménye

A vállalati szoftverek fejlesztésénél éveken-évtizedeken át az volt a követendő út, hogy egy alkalmazásba minél több funkciót tudjanak egyesíteni. Számtalan előnye mellett ennek a monolitikus megközelítésnek voltak erős korlátai is a funkcióbővítés és a skálázhatóság terén. Ha új funkcióra volt szükség, mindig számolni kellett azzal, hogy az új fejlesztés a teljes alkalmazás stabilitására hatással lesz. Ugyanígy, amikor egyik napról a másikra lényegesen több felhasználót kellett kiszolgálni, mindig a teljes alkalmazást és az infrastruktúrát kellett felfelé skálázni.

A mikroszolgáltatások, megkerülendő a monolitikus rendszereknek ezt a két problémáját, más logikát követnek. Egy mikroszolgáltatás lehetőség szerint egy funkciót valósít meg. Mindegyik a saját környezetében fut, és API-n keresztül kommunikál. Így ha változtatni kell, elég csak az érintett mikroszolgáltatást és környezetét módosítani (pl. átméretezni). Ez azonban egyben azt is jelenti, hogy az API mint veszélyforrás belekerül a vállalat vérkeringésébe.

Egy 2018-as amerikai felmérés szerint ennek ahhoz hasonló hatása volt, mint a felhőszolgáltatások generálta shadow IT-nak. A felmérésben részt vevő vállalatoknál saját bevallásuk szerint átlagosan 300-400 API-t használtak az IT-rendszereikben (a válaszadók 25 százaléka egyébként ezernél is többet használt). Ugyanakkor 45 százalékuk nincs meggyőződve arról, hogy az IT-biztonsági csapatuk felismeri, ha illetéktelenek hozzáférnek (akár támadó szándékkal) az API-khoz, felük pedig abban sem biztos, hogy biztonsági csapata tud a szervezetben létező összes API-ról.

Ezek után nem meglepő az sem, hogy a válaszadók közel harmada nem tudott olyan esetről, hogy szervezetében történt-e API-val kapcsolatos incidens, akár csak támadási kísérlet. Ez utóbbi 2018-ban még leginkább azt jelezte, hogy az ilyen jellegű támadások nem is voltak a figyelem középpontjában. Ugyanakkor az is szépen kirajzolódott, hogy az API-biztonság olyan terület, ami szükségszerűen a vállalati IT-biztonság középpontjába került/kerül.

Így javítható az API-k biztonsága

Az alábbiakban sorra veszünk néhány intézkedést, amivel javítható az API-k biztonsága.

API-hitelesítés. Mivel az API potenciális kapu illetékteleneknek egy vállalat adataihoz, olyan iparági szabványnak számító autentikációs mechanizmusokat kell használni mint az OAuth/OpenID Connect vagy a TLS (Transport Layer Security). A monolitikus alkalmazásban a felhasználók és az engedélyek kezelése is rendszeren belül történik, így viszonylag könnyen ellenőrizhető, hogy kinek mire van jogosultsága. A mikroszolgáltatások esetében ez nem oldható meg, hanem kell valamiféle központi megoldás (JSON web token, API-gateway stb.).

Fel kell készülni a kódbefecskendezős támadásokra. Ez a támadási forma az OWASP tavalyi kockázati listáján is szerepel. Az ilyen támadási formánál a támadók rosszindulatú kódot küldenek az interpreternek egy parancs vagy lekérdezés részeként, és ezzel veszik rá nem engedélyezett parancs végrehajtására vagy autorizáció nélküli adathozzáférésre. Az API-kat már eleve úgy kell megtervezni, hogy esetükben nagyobb a valószínűsége az SQL-, RegEx-kódbefecskendezésen stb. alapuló támadásoknak. Emellett az API-k telepítés utáni monitorozását is meg kell oldani a kód védelme érdekében.

Monitorozni kell a titkosítatlan adatokat. Az API-k fontos szerepet játszanak az adatok titkosításában az egész adattovábbítási folyamat során. Ezért olyan eszközöket kell alkalmazni, melyek nyomon követik az adatok útját, megkeresik a lehetséges hibaforrásokat, és kikényszerítik az adattitkosítást, -maszkolást.

Védelmi intézkedések kell hozni a rosszindulatú kérések ellen. Olyan API-kat kell létrehozni, melyek folyamatosan értékelik a beérkező kéréseket, hogy azok megbízhatóak-e. Mivel a rosszindulatú támadásoknál egy visszautasított kérés után a támadók tovább próbálkoznak, célszerű korlátozó házirendet bevezetni kérések számát, elfogadásának időtartamát illetően. Segíthet még például a hash-alapú HMAC-hitelesítés vagy a rövid érvényességű tokenek használata is.

Önmagában egyik intézkedés sem csodaszer, de együttesen megfelelő eszközök bevetésével megteremthetik azt az alapot, ami javítja az API-kkal terhelt biztonság szintjét.