Spørgsmål: Hvad er forskellen mellem zombie API'er og shadow API'er?
Nick Rago, Field CTO, Salt Security: Zombie API'er og shadow API'er repræsenterer biprodukter af en større udfordring, som virksomheder kæmper for at tackle i dag: API sprawl.
Efterhånden som virksomheder søger at maksimere den forretningsmæssige værdi forbundet med API'er, har API'er spredt sig. Digital transformation, app-modernisering til mikrotjenester, API-første app-arkitekturer og fremskridt inden for hurtige kontinuerlige softwareimplementeringsmetoder har fremmet den høje vækst i antallet af API'er, der er oprettet og i brug af organisationer. Som et resultat af denne hurtige API-produktion har API-sprawl manifesteret sig på tværs af flere teams, der udnytter flere teknologiplatforme (legacy, Kubernetes, VM'er osv.) på tværs af flere distribuerede infrastrukturer (lokale datacentre, flere offentlige skyer osv.) . Uønskede enheder såsom zombie API'er og skygge API'er dukker op, når organisationer ikke har de rigtige strategier på plads til at styre API sprawl.
Enkelt sagt er en zombie API en blotlagt API eller et API-endepunkt, der er blevet forladt, forældet eller glemt. På et tidspunkt tjente API'en en funktion. Den funktion er dog muligvis ikke længere nødvendig, eller API'en er blevet erstattet/opdateret med en nyere version. Når en organisation ikke har ordentlig kontrol på plads omkring versionering, udfasning og ophævelse af gamle API'er, kan disse API'er blive ved i det uendelige - derfor udtrykket zombie.
Fordi de i det væsentlige er glemt, modtager zombie API'er ingen løbende patch, vedligeholdelse eller opdateringer i nogen funktionel eller sikkerhedsmæssig kapacitet. Derfor bliver zombie-API'erne en sikkerhedsrisiko. Faktisk er Salt Securitys "Status for API-sikkerhed”-rapporten nævner zombie-API'er som organisationers største API-sikkerhedsbekymring over sine seneste fire undersøgelser.
I modsætning hertil er en shadow API en eksponeret API eller et API-endepunkt, hvis oprettelse og implementering blev udført "under radaren." Shadow API'er er blevet oprettet og implementeret uden for en organisations officielle API-styring, synlighed og sikkerhedskontrol. Følgelig kan de udgøre en lang række sikkerhedsrisici, herunder:
- API'en har muligvis ikke korrekt godkendelse og adgangsporte på plads.
- API'en kan udsætte følsomme data på en forkert måde.
- API'en overholder muligvis ikke bedste praksis fra et sikkerhedssynspunkt, hvilket gør det sårbart over for mange af de OWASP API Security Top 10 angrebstrusler.
En række motiverende faktorer ligger bag, hvorfor en udvikler eller app-team ønsker at implementere en API eller et slutpunkt hurtigt; dog skal en streng API-styringsstrategi følges for at håndhæve kontroller og processer over, hvordan og hvornår en API bliver implementeret uanset motivationen.
Ud over risiciene strækker API-sprawl og fremkomsten af zombie- og skygge-API'er sig ud over API'er, der er udviklet internt. Tredjeparts-API'er, der er implementeret og brugt som en del af pakkede applikationer, SaaS-baserede tjenester og infrastrukturkomponenter, kan også introducere problemer, hvis de ikke er korrekt opstillet, styret og vedligeholdt.
Zombie- og skygge-API'er udgør ens sikkerhedsrisici. Afhængigt af en organisations eksisterende API-kontroller (eller mangel på samme), kan den ene være mindre eller mere problematisk end den anden. Som et første skridt til at tackle udfordringerne ved zombie- og skygge-API'er skal organisationer bruge en ordentlig API-opdagelsesteknologi til at hjælpe med at opgøre og forstå alle de API'er, der er implementeret i deres infrastrukturer. Derudover skal organisationer vedtage en API-styringsstrategi, der standardiserer, hvordan API'er bygges, dokumenteres, implementeres og vedligeholdes - uanset team, teknologi og infrastruktur.
