Spørsmål: Hva er forskjellen mellom zombie APIer og shadow APIer?
Nick Rago, felt-CTO, Salt Security: Zombie APIer og shadow APIer representerer biprodukter av en større utfordring som bedrifter sliter med å takle i dag: API-spredning.
Ettersom selskaper søker å maksimere forretningsverdien knyttet til API-er, har API-er spredt seg. Digital transformasjon, appmodernisering til mikrotjenester, API-første app-arkitekturer og fremskritt innen raske kontinuerlige programvaredistribusjonsmetoder har drevet den høye veksten i antall APIer som er opprettet og i bruk av organisasjoner. Som et resultat av denne raske API-produksjonen har API-spredningen manifestert seg på tvers av flere team som utnytter flere teknologiplattformer (legacy, Kubernetes, VM-er, etc.) på tvers av flere distribuerte infrastrukturer (lokale datasentre, flere offentlige skyer, etc.) . Uønskede enheter som zombie-API-er og skygge-API-er dukker opp når organisasjoner ikke har de riktige strategiene på plass for å administrere API-spredning.
Enkelt sagt er et zombie-API et eksponert API eller et API-endepunkt som har blitt forlatt, utdatert eller glemt. På et tidspunkt tjente API en funksjon. Det kan imidlertid hende at funksjonen ikke lenger er nødvendig, eller API-en har blitt erstattet/oppdatert med en nyere versjon. Når en organisasjon ikke har de riktige kontrollene på plass rundt versjonering, avvikling og avvikling av gamle API-er, kan disse API-ene henge på i det uendelige - derav begrepet zombie.
Fordi de i hovedsak er glemt, mottar ikke zombie-API-er noen pågående oppdatering, vedlikehold eller oppdateringer i noen funksjons- eller sikkerhetskapasitet. Derfor blir zombie-API-ene en sikkerhetsrisiko. Faktisk er Salt Security “Status for API-sikkerhet” rapporten navngir zombie-API-er som organisasjoners API-sikkerhetsproblem nr. 1 i de fire siste undersøkelsene.
I motsetning til dette er et skygge-API et eksponert API eller et API-endepunkt hvis opprettelse og distribusjon ble gjort "under radaren." Shadow APIer er opprettet og distribuert utenfor en organisasjons offisielle API-styring, synlighet og sikkerhetskontroller. Følgelig kan de utgjøre en rekke sikkerhetsrisikoer, inkludert:
- API-en har kanskje ikke riktig autentisering og tilgangsporter på plass.
- API-en kan eksponere sensitive data på feil måte.
- API-en følger kanskje ikke beste praksis fra et sikkerhetssynspunkt, noe som gjør den sårbar for mange av de OWASP API Security Topp 10 angrepstrusler.
En rekke motiverende faktorer ligger bak hvorfor en utvikler eller et appteam ønsker å implementere et API eller endepunkt raskt. Imidlertid må en streng API-styringsstrategi følges for å håndheve kontroller og prosesser over hvordan og når en API blir distribuert uavhengig av motivasjonen.
I tillegg til risikoen strekker API-spredning og fremveksten av zombie- og skygge-API-er utover API-er utviklet internt. Tredjeparts APIer som er distribuert og brukt som en del av pakkede applikasjoner, SaaS-baserte tjenester og infrastrukturkomponenter kan også introdusere problemer hvis de ikke er riktig inventarisert, styrt og vedlikeholdt.
Zombie- og skygge-API-er utgjør lignende sikkerhetsrisiko. Avhengig av en organisasjons eksisterende API-kontroller (eller mangel på slike), kan den ene være mindre eller mer problematisk enn den andre. Som et første skritt for å takle utfordringene med zombie- og skygge-APIer, må organisasjoner bruke en skikkelig API-oppdagelsesteknologi for å hjelpe med å lagre og forstå alle API-ene som er distribuert i deres infrastruktur. I tillegg må organisasjoner ta i bruk en API-styringsstrategi som standardiserer hvordan APIer bygges, dokumenteres, distribueres og vedlikeholdes – uavhengig av team, teknologi og infrastruktur.
