Bár a PSD2 kapcsán váltak széles körben ismertté az API-kban rejlő kockázatok, nem kell külső, harmadik fél ahhoz, hogy ezek a kockázatok testet öltsenek.

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.

Hirdetés
Biztonság

Hatott a felháborodás: nem mér egyéni teljesítményeket a Productivity Score

A Microsoft bejelentette, hogy visszavesz a funkcióból: mostantól csak szervezeti szinten ad összesített adatokat a produktivitásról.
 
Hirdetés
Jó hír: ehhez rendelkezésre állnak a megfelelő eszközök. Az általánossá váló távmunka még jobban ráirányította a figyelmet, hogy az adatok biztosítása nem csak a cloud szolgáltatók, hanem legalább akkora részben a megrendelők felelőssége is.

a melléklet támogatója a Servergarden

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.