Zakaj so Zombie API-ji in Shadow API-ji tako strašljivi?

Vprašanje: Kakšna je razlika med zombi API-ji in senčnimi API-ji?

Nick Rago, tehnični direktor na terenu, Salt Security: Zombie API-ji in senčni API-ji predstavljajo stranske produkte večjega izziva, s katerim se podjetja danes težko spopadajo: širjenje API-jev.

Ker si podjetja prizadevajo povečati poslovno vrednost, povezano z API-ji, so se API-ji razširili. Digitalna preobrazba, posodobitev aplikacij v mikrostoritve, arhitekture aplikacij, ki so prve na API-jih, in napredek v metodah hitrega neprekinjenega uvajanja programske opreme so spodbudili hitro rast števila API-jev, ki so jih ustvarile in uporabljajo organizacije. Zaradi te hitre produkcije API-jev se je širjenje API-ja pokazalo v več ekipah, ki uporabljajo več tehnoloških platform (stare, Kubernetes, VM-ji itd.) v več porazdeljenih infrastrukturah (lokalni podatkovni centri, več javnih oblakov itd.) . Neželene entitete, kot so zombi API-ji in API-ji v senci, se pojavijo, ko organizacije nimajo vzpostavljenih ustreznih strategij za upravljanje širjenja API-jev.

Preprosto povedano, zombi API je izpostavljen API ali končna točka API-ja, ki je opuščena, zastarela ali pozabljena. Na eni točki je API služil funkciji. Vendar ta funkcija morda ne bo več potrebna ali pa je bil API nadomeščen/posodobljen z novejšo različico. Ko organizacija nima ustreznega nadzora glede različic, opuščanja in ukinitve starih API-jev, lahko ti API-ji ostanejo na voljo za nedoločen čas - zato izraz zombi.

Ker so v bistvu pozabljeni, zombi API-ji ne prejemajo nobenih stalnih popravkov, vzdrževanja ali posodobitev v nobeni funkcionalni ali varnostni zmogljivosti. Zato zombi API-ji postanejo varnostno tveganje. Pravzaprav podjetje Salt Security “Stanje varnosti API-ja” Poročilo navaja zombi API-je kot prvo skrb organizacij glede varnosti API-jev v zadnjih štirih raziskavah.

V nasprotju s tem je senčni API izpostavljen API ali končna točka API-ja, katere ustvarjanje in uvedba sta bila izvedena "pod radarjem". Senčni API-ji so bili ustvarjeni in razporejeni zunaj uradnega upravljanja API-ja, vidnosti in varnostnih kontrol organizacije. Posledično lahko predstavljajo veliko različnih varnostnih tveganj, vključno z:

• API morda nima ustreznih vrat za preverjanje pristnosti in dostopa.
• API morda nepravilno razkriva občutljive podatke.
• API morda ne upošteva najboljših praks z varnostnega vidika, zaradi česar je ranljiv za številne Varnost OWASP API Top 10 grožnje z napadi.

Številni motivacijski dejavniki so v ozadju, zakaj bi razvijalec ali skupina aplikacij želela hitro uvesti API ali končno točko; vendar je treba slediti strogi strategiji upravljanja API-ja, da se uveljavi nadzor in postopek nad tem, kako in kdaj se API uvede ne glede na motivacijo.

Tveganjem je dodano širjenje API-jev ter pojav zombijev in senčnih API-jev, ki presegajo API-je, razvite v podjetju. API-ji tretjih oseb, ki so nameščeni in uporabljeni kot del paketnih aplikacij, storitev, ki temeljijo na SaaS, in infrastrukturnih komponent, lahko povzročijo tudi težave, če niso pravilno popisani, upravljani in vzdrževani.

Zombie in shadow API-ji predstavljajo podobno varnostna tveganja. Odvisno od obstoječih kontrol API-ja v organizaciji (ali odsotnosti le-teh) je lahko eden manj ali bolj problematičen od drugega. Kot prvi korak pri spopadanju z izzivi zombijev in senčnih API-jev morajo organizacije uporabiti ustrezno tehnologijo odkrivanja API-jev za pomoč pri inventarju in razumevanju vseh API-jev, nameščenih v njihovih infrastrukturah. Poleg tega morajo organizacije sprejeti strategijo upravljanja API-jev, ki standardizira način gradnje, dokumentiranja, uvajanja in vzdrževanja API-jev – ne glede na ekipo, tehnologijo in infrastrukturo.