Bizonyos tekintetben a való életben zajló változásokkal megegyező folyamatok mennek végbe a különböző informatikai területeken. Miközben ugyanis világunk minden korábban ismertnél globalizáltabbá válik, ez a tendencia, a központi tevékenységre való fókuszálás és a mellékszálak kiszervezése hasonló módon zajlik az IT területén. Ennek alapköve az API (Application Programming Interface, azaz alkalmazásprogramozási felület), hiszen ez az az univerzális kapcsoló elem a digitális transzformációs projektekben, amely összeköti a különböző alkalmazásokat, szolgáltatásokat egymással.

Jelentősége éppen emiatt folyamatosan nő. Szerepet vállal a B2B kommunikáció és a pénzügyi szolgáltatások piacának forradalmasításában, ahogy a modern ERP megoldások sincsenek meg nélküle. Túlzások nélkül kijelenthető, hogy alapvetően változtatja meg a szoftveripart. Egyre gyakrabban és bátrabban használjuk tehát az API-kat, ami azonban új típusú kockázatok megjelenését hozza magával.

Folyamatos támadás alatt

Az API-k ellen irányuló fenyegetések borzasztóan széles köre rémisztően hathat. Mivel minden egyes API egyedi, minden felhasználási módja is egyedi, az adott telepítésre alapuló kockázatot jelent. Lehetetlen vállalkozásnak tűnik az alkalmazásprogramozási felületek biztonságossá tétele – de csak első látásra.

Az API-kat célzó támadások zöme ugyanis három fő kategóriába sorolható. A paraméter-támadások az API-nak küldött adatok – úgymint URL-ek, lekérdezési paraméterek, HTTP headerek stb. – elemzésére alapulnak. Az azonosságot célzó kísérletek a felhasználóazonosítás, jogosultságkezelés és munkamenet követés (session tracking) gyengeségeit aknázzák ki. Szintén gyakori a közbeékelődéses (man-in-the-middle) támadási forma, melynek során az adatforgalom nem biztosított/titkosított információira utaznak a kiberbűnözők.

Milyen következményekkel jár egy rosszul, gyenge védelemmel megtervezett API? Például szolgáltatásmegtagadásra irányuló kísérletek (DDoS) áldozatául esik azért, mert a fejlesztők nem építik be az ezt meggátló korlátokat, vagy nem szűrik ki az ártó jellegű kérelmeket. A Netflix például saját magát hackelte meg, hogy felmérje, mekkora veszélyben vannak rendszerei.

Okoztak már súlyos incidenseket API-k. A McDonald’s India tavaly tavasszal egy hibás tervezésű API miatt került nagyon kellemetlen helyzetbe. 2,2 millió felhasználó adata szivárgott ki azért, mert egy alkalmazásprogramozási felület nem alkalmazott megfelelő hitelesítési eljárást.

Sajnos a fenti sor még hosszan folytatható, hiszen se szeri, se száma az API-kat célzó támadásoknak. A nagy kérdés azonban az, hogy lehet-e tenni valamit a veszély csökkentése érdekében? A rövid válasz az, hogy igen. De nézzük át kicsit részletesebben, hogy milyen út vezet az üdvözítő állapot felé!

Kihagyhatatlan lépések a biztonság felé vezető úton

Mint gyakorlatilag bármilyen IT rendszer létrehozásakor, úgy az API-k fejlesztése során is már alapoktól nagy hangsúlyt kell fektetni a biztonságos működésre. Ennek első eleme, hogy tudjuk, ki az, aki szeretne hozzáférni az erőforrásunkhoz – vagyis szükség van azonosításra. Szintje az adott felhasználástól függ, az ideiglenes azonosítástól a valódi személyazonosságig tart skála.

Ezt követi az engedélyezés folyamata, vagyis amikor arról kell megbizonyosodni, hogy az adott entitásnak van-e jogosultsága ahhoz a tevékenységhez, amihez éppen hozzáférést akar szerezni. SSO (Single Sign On) alkalmazásával egyesített biztonságot lehet elérni, vagyis csökkenthető az azonosítások száma, gördülékenyebbé válik a munkavégzés. Delegációval pedig az autentikáció folyamata szervezhető ki – a Facebook Connect szolgáltatása például közkedvelt módja a delegált azonosításnak.

Használat módjától függően lehet egy API privát, B2B partner API és nyilvános. Az első kategóriába a kizárólag belső használatra szánt programozói felületek tartoznak, melyek általános jellemzője a szegényes dokumentáció, a rossz vagy hiányzó karbantartás, és hogy gyakorlatilag teljes hiányzik a biztonsági réteg. A második tábort képviselő API-k a szerződéses partnereknek kínálnak hozzáférést a céges rendszerekhez. Itt már jóval nagyobb a szórás, egy-egy programozói interfész lehet jól dokumentált és biztonságos, de bőven akad példa ennek ellenkezőjére is.

A publikus API-k bárki számára elérhetővé teszik az adott szervezet szolgáltatását a felületen keresztül, vagyis a piac bármely szereplője integrálódhat hozzá a tulajdonos tudta és beleegyezése nélkül. Érdemes egyébként minden fejlesztést nyilvános API-ra vonatkozónak tekinteni, melynek egyes funkciói csak partnerek számára érhetők el. Így számos biztonsági kockázat – aluldokumentáltság, elhanyagoltság – egyszerűen kikerülhető.

Szűrés és titkosítás

Akad még néhány megfontolandó szempont, amivel fokozható az API-k biztonsága. Ahelyett például, hogy egyetlen node-dal zajlana az összes kérelem kiszolgálása, érdemes API routingot alkalmazni, amivel skálázhatóbb, a terheléseket könnyebben kezelni képes, költséghatékony és magas rendelkezésre állást biztosító rendszer alakítható ki.

A már említett közbeékelődéses támadások miatt szintén elengedhetetlen a titkosítás használata, hiszen ennek hiányában gyakorlatilag majdnem sarokig kitárt kapuk várják a jogosulatlan kíváncsiskodókat. Ugyanilyen tényező a tartalomszűrés, mivel a hagyományos védelmet megkerülő API-k nagyon komoly fejfájást tudnak okozni. Az ezen keresztül érkező vírusokat is meg kell állítani, ahogy a csalásokat, behatolási kísérleteket észlelő rendszerek is felesleges kiadássá válnak, ha egy gyenge API miatt kikerülhetők.

Nem egyszerű tehát biztonságos, de az elvárt működést megfelelően nyújtó alkalmazásprogramozási felületet létrehozni és fejleszteni. Ám, ahogyan láthattuk, nem is lehetetlen feladat. Néhány fontos tényező fejben tartásával, a 'biztonság mint a tervezés egyik alapköve' koncepció alkalmazásával számos későbbi bosszúság elkerülhető.

Az API-k támadhatóságának aktualitását az Európai Unió fizetési szolgáltatásokra vonatkozó PSD2 irányelvének bevezetése adja. Ezzel következő részeiben fogunk foglalkozni.