Fråga: Vad är skillnaden mellan zombie-API:er och shadow-API:er?
Nick Rago, Field CTO, Salt Security: Zombie-API:er och shadow API:er representerar biprodukter av en större utmaning som företag kämpar för att ta itu med idag: API-sprawl.
När företag försöker maximera affärsvärdet som är förknippat med API:er har API:er ökat. Digital transformation, appmodernisering till mikrotjänster, API-första apparkitekturer och framsteg inom snabba kontinuerliga programvarudistributionsmetoder har drivit på den snabba tillväxten av antalet API:er som skapas och används av organisationer. Som ett resultat av denna snabba API-produktion har API-spridningen visat sig över flera team som utnyttjar flera teknikplattformar (legacy, Kubernetes, VMs, etc.) över flera distribuerade infrastrukturer (lokala datacenter, flera offentliga moln, etc.) . Oönskade enheter som zombie-API:er och shadow-API:er uppstår när organisationer inte har de rätta strategierna på plats för att hantera API-sprawl.
Enkelt uttryckt är ett zombie-API ett exponerat API eller en API-slutpunkt som har blivit övergiven, föråldrad eller glömd. Vid ett tillfälle tjänade API:et en funktion. Men den funktionen kanske inte längre behövs eller så har API:et ersatts/uppdaterats med en nyare version. När en organisation inte har ordentliga kontroller på plats kring versionshantering, utfasning och avskaffande av gamla API:er, kan dessa API:er dröja kvar på obestämd tid - därav termen zombie.
Eftersom de i princip är bortglömda, får zombie-API:er inga pågående korrigeringar, underhåll eller uppdateringar i någon funktionell eller säkerhetskapacitet. Därför blir zombie-API:erna en säkerhetsrisk. Faktum är att Salt Securitys "Tillstånd för API-säkerhet”-rapporten namnger zombie-API:er som organisationers nummer 1 API-säkerhetsproblem under sina senaste fyra undersökningar.
Däremot är ett shadow API ett exponerat API eller en API-slutpunkt vars skapande och distribution gjordes "under radarn." Shadow API:er har skapats och distribuerats utanför en organisations officiella API-styrning, synlighet och säkerhetskontroller. Följaktligen kan de utgöra en mängd olika säkerhetsrisker, inklusive:
- API:et kanske inte har korrekt autentisering och åtkomstgrindar på plats.
- API:et kan exponera känslig information på ett felaktigt sätt.
- API:et kanske inte följer bästa praxis ur säkerhetssynpunkt, vilket gör det sårbart för många av de OWASP API Security Topp 10 attackhot.
Ett antal motiverande faktorer ligger bakom varför en utvecklare eller ett appteam skulle vilja distribuera ett API eller en slutpunkt snabbt; dock måste en strikt API-styrningsstrategi följas för att genomdriva kontroller och processer över hur och när ett API distribueras oavsett motivation.
Utöver riskerna sträcker sig API-utbredning och uppkomsten av zombie- och skugg-API:er längre än API:er som utvecklats internt. Tredjeparts API:er som distribueras och används som en del av paketerade applikationer, SaaS-baserade tjänster och infrastrukturkomponenter kan också skapa problem om de inte inventeras, styrs och underhålls på rätt sätt.
Zombie- och shadow-API:er poserar liknande säkerhetsrisker. Beroende på en organisations befintliga API-kontroller (eller brist på sådana), kan den ena vara mindre eller mer problematisk än den andra. Som ett första steg för att ta itu med utmaningarna med zombie- och shadow-API:er måste organisationer använda en riktig API-upptäcktsteknik för att hjälpa till att inventera och förstå alla API:er som används i deras infrastrukturer. Dessutom måste organisationer anta en API-styrningsstrategi som standardiserar hur API:er byggs, dokumenteras, distribueras och underhålls – oavsett team, teknik och infrastruktur.
