Perché le API Zombie e le Shadow API sono così spaventose?

Domanda: Qual è la differenza tra API zombie e API shadow?

Nick Rago, CTO sul campo, Salt Security: Le API zombie e le API shadow rappresentano i sottoprodotti di una sfida più ampia che le aziende oggi faticano ad affrontare: la diffusione incontrollata delle API.

Mentre le aziende cercano di massimizzare il valore aziendale associato alle API, le API proliferano. La trasformazione digitale, la modernizzazione delle app in microservizi, le architetture delle app API-first e i progressi nei metodi di distribuzione rapida e continua del software hanno alimentato la crescita ad alta velocità del numero di API create e utilizzate dalle organizzazioni. Come risultato di questa rapida produzione di API, la loro espansione si è manifestata tra più team che sfruttano più piattaforme tecnologiche (legacy, Kubernetes, VM, ecc.) su più infrastrutture distribuite (data center locali, più cloud pubblici, ecc.) . Entità indesiderate come le API zombie e le API shadow emergono quando le organizzazioni non dispongono delle strategie adeguate per gestire la proliferazione delle API.

In poche parole, un'API zombie è un'API esposta o un endpoint API che è stato abbandonato, obsoleto o dimenticato. Ad un certo punto, l'API ha svolto una funzione. Tuttavia, tale funzione potrebbe non essere più necessaria oppure l'API è stata sostituita/aggiornata con una versione più recente. Quando un'organizzazione non dispone di controlli adeguati sul controllo delle versioni, sulla deprecazione e sulla disattivazione delle vecchie API, tali API potrebbero persistere indefinitamente, da qui il termine zombie.

Poiché sono sostanzialmente dimenticate, le API zombie non ricevono patch, manutenzione o aggiornamenti continui in termini funzionali o di sicurezza. Pertanto, le API zombie diventano un rischio per la sicurezza. In effetti, Salt Security "Stato della sicurezza API"Il rapporto definisce le API zombie come la principale preoccupazione delle organizzazioni in materia di sicurezza delle API negli ultimi quattro sondaggi.

Al contrario, un'API shadow è un'API esposta o un endpoint API la cui creazione e distribuzione sono state eseguite "sotto il radar". Le API shadow sono state create e distribuite al di fuori dei controlli ufficiali di governance, visibilità e sicurezza delle API di un'organizzazione. Di conseguenza, possono comportare un’ampia varietà di rischi per la sicurezza, tra cui:

• L'API potrebbe non disporre di autenticazione e porte di accesso adeguate.
• L'API potrebbe esporre dati sensibili in modo improprio.
• L'API potrebbe non aderire alle migliori pratiche dal punto di vista della sicurezza, rendendola vulnerabile a molti dei rischi Sicurezza dell'API OWASP Top 10 minacce di attacco.

Alla base del motivo per cui uno sviluppatore o un team di app vorrebbe implementare rapidamente un'API o un endpoint sono una serie di fattori motivanti; tuttavia, è necessario seguire una rigorosa strategia di governance delle API per applicare controlli e processi su come e quando un'API viene distribuita, indipendentemente dalla motivazione.

In aggiunta ai rischi, la diffusione delle API e l’emergere di API zombie e shadow vanno oltre le API sviluppate internamente. Anche le API di terze parti distribuite e utilizzate come parte di applicazioni in pacchetto, servizi basati su SaaS e componenti dell'infrastruttura possono introdurre problemi se non adeguatamente inventariate, governate e mantenute.

Le API Zombie e Shadow si presentano in modo simile rischi per la sicurezza. A seconda dei controlli API esistenti di un'organizzazione (o della loro mancanza), uno potrebbe essere meno o più problematico dell'altro. Come primo passo per affrontare le sfide delle API zombie e shadow, le organizzazioni devono utilizzare una tecnologia di rilevamento delle API adeguata per aiutare a inventariare e comprendere tutte le API distribuite nelle loro infrastrutture. Inoltre, le organizzazioni devono adottare una strategia di governance delle API che standardizzi il modo in cui le API vengono create, documentate, distribuite e mantenute, indipendentemente dal team, dalla tecnologia e dall'infrastruttura.