Több oka is van annak, hogy az API-biztonság témája 2022 végéhez közeledve egyre inkább előkerül.
A Gartner még 2021 júliusában azt jósolta, hogy 2022-re az alkalmazásprogramozási felület (API) támadásai lesznek a leggyakoribb támadási vektorok, amelyek adatszivárgásokat okoznak a vállalati webalkalmazásokban.
Igaza volt az elemző cégnek? Azóta túl korai biztosat tudni Az OWASP még mindig összeszámolja az eredményeket.
Az API-támadások újra a hírekben vannak. Kiderül a valószínű bemeneti pont a Optus megsértése alantas REST API volt. És valaki kiszivárogtatta az összes adatot, amit elloptak a Twitter megsértése – amely egy API-t is tartalmazott.
Amikor beszélünk API biztonság, azokra az intézkedésekre és gyakorlatokra utalunk, amelyeket az API-k és az általuk továbbított adatok védelmére használunk. Aggódhatunk a jogosulatlan hozzáférés, a DDoS-re adott nemkívánatos reakciók miatt (egynél több API bukott le, és az alapul szolgáló rendszer teljesen nyitott és teljesen bizonytalan volt), vagy más rosszindulatú támadások miatt.
Van egy művészet az API-k biztonságossá tételében; enyhe érintésre, valamint a technikai és szervezési készségek finom kombinációjára van szükség ahhoz, hogy helyesen végezzük.
Technikai oldalon olyan intézkedéseket vizsgálunk, mint a hitelesítés és engedélyezés, a titkosítás, az automatizált tesztelés és a felügyelet. A szervezeti oldalon pontosan tudnia kell, hogy a szervezeti diagramon az API-t kiszolgálja, és ennek megfelelően kell személyre szabnia a hozzáférést. A külső API-k esetében tudnia kell, hogy mennyi adatnak kell elérhetővé válnia a külvilág számára, és hogyan kell ezeket az adatokat kezelni és bemutatni.
Hogyan védik az API-kat?
A műveletek józan rendje van, amikor megpróbálja biztonságossá tenni vállalata API-jait.
Először keresse meg és katalogizálja az összes API-t. Valóban csekély azoknak a vállalatoknak a száma, amelyek ezt ténylegesen megteszik, és naprakészen tartják API-készletüket. A fejlesztői kényelem, a gyors webhelyfejlesztés és az egyesített szolgáltatások felé való növekvő nyomás mind hozzájárulnak ahhoz, hogy a rejtélyes API-k hirtelen felbukkanjanak anélkül, hogy kötelező regisztrációs struktúra lenne.
Az ilyen típusú API-kúszás elkerülése érdekében mindegyiket központilag regisztrálni kell a következő információkkal:
- Név
- Az API felépítéséhez használt eszközök és csomagok
- Szerverek, amelyeken fut
- Azok a szolgáltatások, amelyek erre az API-ra támaszkodnak
- Minden érvényes használat és hibakód dokumentációja
- Tipikus teljesítménymutatók
- Várható üzemidő vagy állásidő ablakok
Mindezek az információk a kiberbiztonsági csapat által üzemeltetett adattárba kerülnek.
Másodszor, állítson be biztonsági és teljesítményautomatizálást minden API-hoz. Ezért kérte az összes információt, és így tart mindent biztonságban. A fejlesztők (és a DevOps csapat, a webcsapat stb.) által biztosított adatok felhasználásával a kiberbiztonsági és/vagy tesztelőcsapat olyan automatizálást állíthat össze, amely rendszeresen teszteli az API-t.
A funkcionális tesztek azért fontosak, mert megbizonyosodnak arról, hogy minden a várt módon működik. A nem funkcionális tesztek azért fontosak, mert az API megbízhatóságát és biztonságát vizsgálják. Ne feledje, hogy az API-knak biztonságosan meg kell hibázniuk. Nem elég tudni, hogy valaki felborult – ismerni kell a kudarc következményeit.
Végül adja hozzá az API-t a normál fenyegetésmegelőzési csomaghoz. Ha az API felépítéséhez használt eszközök vagy csomagok bármelyike hibásnak bizonyul, tudnia kell. Ha az általa használt protokollok bármelyike bizonytalannak bizonyul, amikor hibát észlel, le kell állítania az API-kat a csapattal, amíg meg nem lehet őket vizsgálni és újra fel lehet építeni.
Ezeket a dolgokat egyszer megtenni nagyszerű; A hosszú távú cél egy olyan programozási és biztonsági kultúra létrehozása, amely lehetővé teszi a teljesen katalogizált és dokumentált API-k karbantartását.
Megjegyzendő konkrét API-viselkedések
A toll tesztelésekor és egy API biztosításakor egyes technikák hasznosabbak, mint mások.
- Kezdje a viselkedéselemzéssel. Ez azt vizsgálja, hogy a valóság megfelel-e a dokumentációnak a hozzáférés szintjét, a használt protokollokat és portokat, a sikeres és sikertelen lekérdezések eredményeit, valamint azt, hogy mi történik a rendszer egészével, ha maga az API leáll.
- A következő a szolgáltatási szintek. Ez magában foglalja magának a folyamatnak a prioritását a kiszolgálón, a tranzakciós API-k sebességkorlátozását, a minimális és maximális kérés késleltetési beállításait, valamint a rendelkezésre állási ablakokat. Ezen részletek némelyike fontos a DDoS megelőzése (vagy tompítása) szempontjából. Mások hasznosak annak megfigyelésére, hogy vannak-e lassú memóriaszivárgások vagy szemétgyűjtési problémák, amelyek hosszú távú veszélyt jelenthetnek magának a kiszolgálónak az integritására.
- Hitelesítési és higiéniai problémák közvetlenül beszéljen az API felhasználói iránti bizalom szintjéről. Mint minden szolgáltatás esetében, a lekérdezéseket meg kell tisztítani, mielőtt elfogadják őket. Ez megakadályozza a kódbefecskendezést, a puffer túlcsordulást és hasonlókat.
Szükség van bizonyos szintű hitelesítésre olyan API-kkal, amelyeket egy adott felhasználói bázishoz terveztek. Ez azonban bonyolulttá válhat. Az összevonás olyan probléma, amellyel foglalkoznia kell, és meg kell határoznia, hogy mely központi azonosítási és hitelesítési kiszolgálókat fogadja el. Érdemes lehet kéttényezős hitelesítést alkalmazni a különösen érzékeny vagy erős API-khoz. És persze a hitelesítés manapság nem feltétlenül jelszó; A biometria egy érvényes módja az API-k leállításának. Röviden: Alkalmazza azokat a szabványokat, amelyeket ésszerűnek talál, és rendszeresen tesztelje az Ön által meghatározott korlátokat.
Végül a titkosításnak és a digitális aláírásnak a beszélgetés részét kell képeznie. Ha a weben van, akkor legalább TLS-ről beszélünk (ismételje meg a mantrát: TLS nélkül nem pihenünk!). Más interfészek is titkosítást igényelnek, ezért okosan válassza ki a protokollokat. Ne feledje, hogy a statikus információkat, legyen az adatbázis vagy valahol fájlkészlet, szintén titkosítani kell. Nincsenek lapos szövegfájlok sehol, bármilyen „ártatlan” is; só és hash legyen a szabvány. És az ellenőrző összegek kötelezőek, amikor ismert entitások (méret, tartalom stb.) fájlokat adnak vagy fogadnak.
Végül a kulcskezelést nehéz lehet helyesen megoldani. Ne várja el minden DevOps-felelőstől, hogy tökéletes digitális kulcs-megvalósítással rendelkezzen, amikor a kiberbiztonsággal foglalkozók egy tisztességes része félig saját maga végzi el. Ha kétségei vannak, menj vissza az OWASP Cheat Sheet-hez! Ez azért van ott.
Válasz egy API-támadásra
A fő szabály a következő: Ha az API meghibásodik, szüntesse meg a hozzáférést. A szolgáltatások semmilyen körülmények között nem hibázhatnak nyitott vagy hozzáférhető állapotban. Ne felejtse el a sebességkorlátozást, és a hibaüzenetek rövidek és általánosak legyenek. Ne aggódjon a mézesedények vagy API börtönök miatt – aggódjon a túlélés miatt.
Az egyedileg kialakított API-támadásokat úgy kell kezelni, mint bármely más feltörési kísérletet. Akár saját kezűleg, akár mesterséges intelligencia-elemzésen keresztül kapta el a kísérletet, kövesse az SOP-t. Ne vágjon bele, mert ez „csak” egy API.
Az API biztonság elválasztja a középszerű CISO-t, amely kizárólag az infrastruktúrára összpontosít, a mesteri CISO-tól, amely kezeli a tényleges üzleti fenyegetéseket és biztosítja a túlélést. Hozzon létre egy API-biztonsági rendszert, hozzon létre újrafelhasználható felület tesztelési automatizálást, és tartsa naprakészen API-készletét.
