Kérdés: Mi a különbség a zombi API-k és az árnyék API-k között?
Nick Rago, Field CTO, Salt Security: A zombi API-k és az árnyék API-k egy nagyobb kihívás melléktermékei, amellyel a vállalatok manapság küzdenek: az API terjeszkedésének.
Ahogy a vállalatok igyekeznek maximalizálni az API-khoz kapcsolódó üzleti értéket, az API-k elterjedtek. A digitális átalakulás, az alkalmazások mikroszolgáltatásokká történő korszerűsítése, az API-első alkalmazásarchitektúrák és a gyors, folyamatos szoftvertelepítési módszerek fejlődése elősegítette a szervezetek által létrehozott és használt API-k számának gyors növekedését. Ennek a gyors API-gyártásnak köszönhetően az API szétterülése több csapatban is megmutatkozott, akik több technológiai platformot (örökölt, Kubernetes, virtuális gépek stb.) használnak több elosztott infrastruktúrán (helyszíni adatközpontok, több nyilvános felhő stb.) keresztül. . Nem kívánt entitások, például zombi API-k és árnyék API-k akkor jelennek meg, amikor a szervezetek nem rendelkeznek megfelelő stratégiákkal az API terjeszkedésének kezelésére.
Egyszerűen fogalmazva, a zombi API egy szabadon hagyott API vagy API-végpont, amely elhagyott, elavult vagy elfelejtett. Egy ponton az API egy funkciót szolgált. Előfordulhat azonban, hogy erre a funkcióra már nincs szükség, vagy az API-t lecserélték/frissítették egy újabb verzióra. Ha egy szervezet nem rendelkezik megfelelő szabályozással a régi API-k verziózásával, elavulásával és megszüntetésével kapcsolatban, ezek az API-k a végtelenségig fennmaradhatnak – innen ered a zombi kifejezés.
Mivel lényegében feledésbe merültek, a zombi API-k nem kapnak folyamatos javítást, karbantartást vagy frissítést semmilyen funkcionális vagy biztonsági szempontból. Ezért a zombi API-k biztonsági kockázatot jelentenek. Valójában a Salt SecurityAz API biztonság állapota” jelentés a zombi API-kat nevezi meg a szervezetek első számú API biztonsági aggályaként az elmúlt négy felmérés során.
Ezzel szemben az árnyék API egy nyílt API vagy API-végpont, amelynek létrehozása és telepítése „radar alatt” történt. Az árnyék API-kat a szervezet hivatalos API-irányításán, láthatósági és biztonsági ellenőrzésein kívül hozták létre és helyezték üzembe. Következésképpen számos biztonsági kockázatot jelenthetnek, beleértve a következőket:
- Előfordulhat, hogy az API nem rendelkezik megfelelő hitelesítési és hozzáférési kapukkal.
- Előfordulhat, hogy az API helytelenül tesz közzé bizalmas adatokat.
- Előfordulhat, hogy az API biztonsági szempontból nem követi a bevált gyakorlatokat, így számos OWASP API Security Top 10 támadási fenyegetéseket.
Számos motiváló tényező áll annak hátterében, hogy egy fejlesztő vagy alkalmazáscsapat miért szeretne gyorsan telepíteni egy API-t vagy végpontot; azonban szigorú API-irányítási stratégiát kell követni az API-k bevezetésének módjára és idejére vonatkozó ellenőrzések és folyamatok érvényesítéséhez, függetlenül a motivációtól.
A kockázatokat növeli, hogy az API terjeszkedése, valamint a zombi és árnyék API-k megjelenése túlmutat a házon belül kifejlesztett API-kon. A csomagolt alkalmazások, SaaS-alapú szolgáltatások és infrastruktúra-összetevők részeként telepített és használt, harmadik féltől származó API-k szintén problémákat okozhatnak, ha nincsenek megfelelően leltározva, irányítva és karbantartva.
A zombi és az árnyék API-k hasonlóak biztonsági kockázatok. A szervezet meglévő API-vezérlőitől (vagy azok hiányától) függően az egyik kevésbé vagy több problémás lehet, mint a másik. A zombi és árnyék API-k kihívásainak leküzdésének első lépéseként a szervezeteknek megfelelő API-felderítési technológiát kell használniuk, hogy segítsék az infrastruktúrájukban telepített API-k leltárát és megértését. Ezenkívül a szervezeteknek olyan API irányítási stratégiát kell elfogadniuk, amely szabványosítja az API-k felépítését, dokumentálását, telepítését és karbantartását – a csapattól, a technológiától és az infrastruktúrától függetlenül.
