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.

Biztonság

Közelít az 1000 milliárdhoz a kínai Amazon

Az Alibaba sok szempontból hasonlít amerikai vetélytársára, ám lényeges különbségek is akadnak az üzleti modelljükben.
 
Hirdetés

Van olyan tanácsadó, aki pénzt hoz?!

Pedig külső szemlélőként csak annyit mutat meg, hogy miből van hiány és miből van fölösleg. Ám ha szoftverlicencekről van szó, ez százmilliókat is érhet – megtakarításban.

Elvben mindenki egyetért azzal, hogy egy vállalat informatikája optimális méretű és működésű kell legyen. A helyes arányok megtalálása azonban nehéz, különösen a szoftvereknél.

a melléklet támogatója az IPR-Insights

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.