Kérdés: Hogyan biztosíthatják a szervezetek, hogy API-jaik ellenállóak legyenek a kompromisszumokkal szemben, a megnövekedett API-alapú támadásokkal szemben?
Rory Blundell, a Gravitee alapítója és vezérigazgatója: Bármilyen méretű és iparágban működő vállalkozások rutinszerűen a belső API-kra támaszkodnak az üzletági alkalmazásaik egyesítéséhez, illetve a külső API-kra, hogy adatokat vagy szolgáltatásokat oszthassanak meg szállítókkal, ügyfelekkel vagy partnerekkel. Mivel egyetlen API több alkalmazáshoz vagy szolgáltatáshoz is hozzáférhet, az API kompromittálása egyszerű módja annak, hogy minimális erőfeszítéssel kompromittálja az üzleti eszközök széles körét.
Az API-k népszerű támadási vektorokká váltak, és az API-támadások gyakorisága elképesztő mértékben megnőtt 681%, a legutóbbi adatok szerint a Salt Labs kutatása. Az API-k biztosításának első lépése a bevált gyakorlatok követése, például az OWASP javasolja a gyakori API biztonsági kockázatok elleni védelmet.
Az alapvető API biztonsági gyakorlatok azonban nem elegendőek az IT-erőforrások biztonságának megőrzéséhez. A vállalkozásoknak a következő további lépéseket kell tenniük API-juk védelme érdekében.
1. Alkalmazza a kockázatalapú hitelesítést
A vállalkozásoknak kockázatalapú hitelesítési irányelveket kell elfogadniuk, amelyek lehetővé teszik a biztonsági védelem érvényesítését fokozott kockázat esetén. Előfordulhat például, hogy egy API-kliensnek, amely már régóta jogos kéréseket ad ki egy kiszámítható mintát követve, nem kell minden kérésnél ugyanazt a hitelesítési szintet elvégeznie, mint egy új ügyfélnek, aki korábban még soha nem csatlakozott. De ha a régóta fennálló API-kliens hozzáférési mintája megváltozik – ha például a kliens hirtelen egy másik IP-címről kezd el kéréseket kiadni –, akkor szigorúbb hitelesítést igényelne okos módszer annak biztosítására, hogy a kérések ne egy feltört ügyféltől érkezzenek.
2. Adja hozzá a biometrikus hitelesítést
Bár a tokenek továbbra is fontosak az ügyfelek és kérések hitelesítésének alapvető eszközeként, mégis el lehet lopni. Emiatt a token alapú hitelesítés biometrikus hitelesítéssel való összekapcsolása intelligens módja az API biztonságának fokozásának. Ahelyett, hogy azt feltételeznénk, hogy bárki, aki rendelkezik API-tokennel, érvényes felhasználó, a fejlesztőknek úgy kell megtervezniük az alkalmazásokat, hogy a felhasználóknak ujjlenyomattal, arcleolvasással vagy hasonló módszerrel is hitelesíteniük kell magukat, legalábbis magasabb kockázatú környezetben.
3. A hitelesítés kényszerítése külsőleg
Minél összetettebbé válnak az API-hitelesítési sémák, annál nehezebb magán az alkalmazáson belül érvényesíteni a biztonsági követelményeket. Emiatt a fejlesztőknek arra kell törekedniük, hogy az API biztonsági szabályokat leválasztsák az alkalmazáslogikáról, és ehelyett külső eszközöket, például API-átjárókat használjanak a biztonsági követelmények érvényesítésére. Ez a megközelítés skálázhatóbbá és rugalmasabbá teszi az API biztonsági házirendeket, mivel könnyen implementálhatók és frissíthetők az API-átjárókon belül, nem pedig az alkalmazás forráskódján keresztül. És ami a legfontosabb, lehetővé teszi, hogy különböző szabályokat alkalmazzon a különböző felhasználókra vagy kérésekre a különböző kockázati profilok alapján.
4. Az API biztonságának egyensúlya a használhatósággal
Fontos, hogy a biztonság ne váljon a használhatóság ellenségévé. Ha az API-hitelesítési intézkedéseket túlságosan tolakodóvá vagy megterhelővé teszi, előfordulhat, hogy a felhasználók elhagyják az API-kat, ami éppen az ellenkezője annak, amit szeretne. Ennek elkerülése érdekében gondoskodjon arról, hogy az API biztonsági szabályok szigorúak legyenek, ha indokolt, de szükségtelen követelmények előírása nélkül.
Az API-kat célzó támadások nem mutatják a lassulás jelét. Az API-k tervezése és biztosítása során a fejlesztőknek túl kell lépniük az OWASP ajánlásain, hogy megnehezítsék az API kihasználását.
