Az API-alapú adatátvitel olyan gyors, hogy csak kevés idő van arra, hogy megállítsuk a nagyon rossz dolgok gyors megtörténtét
Az integráció rohanásában ezek az enyhén védett számítógépek közötti portálok gyors adatátvitelt tesznek lehetővé a rendszerek között, hogy gazdagítsák és megjelenítsék az adatokat a digitális hálózaton keresztül. De az enyhén védett rész lehetővé teszi az adatok hatalmas felszívását az API-részletek visszafejtésével és a szifon elindításával. Mivel az API-alapú adatátvitel nagyon gyors, csak kevés idő áll rendelkezésre a nagyon rossz dolgok gyors megtörténtének megelőzésére.
Itt a RSA konferencia, több munkamenet és gyártó próbált rávenni bennünket, hogy hogyan tömjük be ezeket a gyakran rosszul biztosított digitális lyukakat.
Az API-k védelme érdekében meg kell találnia a sebezhetőségeiket, mielőtt a rosszfiúk megtennék. Ismét ugyanazokat az eszközöket használja támadó és védő egyaránt. A különbség az, hogy sokkal nagyobb valószínűséggel kap értesítést, ha a webalkalmazásának biztonsági problémája van, mint a nyilvános API-jának, bár az utóbbi legalább akkora kárt okozhat.
Noha van némi átfedés a hagyományos webalkalmazás-teszttel, az API-k eltérően működnek, és különböző kérdéseket és válaszokat várnak el a manapság annyira elterjedt gépek közötti alkalmazásokban.
Például az API-k olyan strukturált adatok blokkjait várják el, amelyek megfelelnek valamilyen interoperábilis szabványnak, amelyet más számítógépes rendszerek könnyen emészthetnek. Strukturált kézfogásos hitelesítést is elvárnak a számítógépek között, vagy néha egyáltalán nem.
Utógondolat
Egy RSA résztvevőkkel teli, sok API-val teli szobában, amikor megkérdezték, hányan tudták, hogy mindegyiket teljesen levédték, egy tábornok az ajtóhoz vándorolt, hogy hívja a biztonsági csapatot. Ez így megy.
Az egyenlet „javítás és tesztelés építés közben” oldalán egy eladó Javasolja az API dinamikus tesztelését a szoftverfejlesztési ciklus során, mielőtt bármit is telepítenek. Egy remek Docker-tárolóval bevezetheti, amely minden API-iterációt lát, amelyen a fejlesztők dolgoznak, és menet közben teszteli őket. Ez jó módja annak, hogy megbizonyosodjon arról, hogy véletlenül sem építi meg a következő legjobb hátsó ajtót.
Hogyan találják meg a rosszfiúk a nem biztonságos API-kat? Elég gyakran csak a dokumentációt olvasom. A szabványos API-felületekbe egy olyan fájl van beépítve, amely mintegy címtárszolgáltatást alkot, és felvázolja az összes helyet, ahol titkos dolgokat kereshet. Ily módon a szkennerek automatizálhatják az adatok rekurzív vizsgálatát.
Az API-k nem csak a nyilvános hálózatokkal szembesülnek – gyakran az üzlet középpontjában állnak, csendben kereskednek „megbízható” információkkal, például az épület HVAC-rendszereinek statisztikájával, de oldalirányú mozgási lehetőségeket is kínálnak, amint rosszfiúk betörnek a hálózatba. A szállítók felismerik, hogy termékeik csak egy része a szervezet digitális környezetének, és képesnek kell lenniük másokkal való integrációra, ezért kifejlesztenek egy API-t, hogy jól kommunikáljanak a többi telepített technológiával.
Ez azt is jelenti, hogy a belső biztonsági csapatok természetesebb, megbízható szemmel fordulnak az ilyen típusú forgalom felé. De a zsarolóvírus-készítők pontosan ezt a hozzáférést szeretnék megszerezni.
Ezenkívül, mivel manapság rengeteg IoT-eszköz van szétszórva a vállalat körül, ezek az eszközök API-kat nyitnak meg olyan dolgokhoz, mint a szoftverfrissítések, adatfolyamok és jelentési funkciók más csomópontok számára. Ily módon megvehető egy sérülékenység, amely lehetővé teszi a rossz szereplők számára, hogy eszközről eszközre ugráljanak.
A vállalati termékek rajokból származó API-hívások gyors elterjedése teljesen új módja annak, hogy gondolkodjunk arról, hogy mit kell védeni, és ha figyelmen kívül hagyjuk a nagyon valós, gyakran észrevétlen támadási felületet, hatalmas adathalmazt fenyeget annak a veszélye, hogy teherautó-rakományokba pumpálják a hátulról. elülső vagy oldalsó ajtó, kevés idővel észrevenni, és kevesebb idővel reagálni.
