Miksi Zombie-sovellusliittymät ja varjosovellusliittymät ovat niin pelottavia?

Kysymys: Mitä eroa on zombie-sovellusliittymien ja varjosovellusliittymien välillä?

Nick Rago, Field CTO, Salt Security: Zombie-sovellusliittymät ja varjosovellusliittymät ovat sivutuotteita suuremmasta haasteesta, johon yritykset kamppailevat tänään: API-haastumisen.

Yritysten pyrkiessä maksimoimaan API:ihin liittyvän liiketoiminnan arvon, API:t ovat yleistyneet. Digitaalinen muutos, sovellusten modernisointi mikropalveluihin, API-ensimmäiset sovellusarkkitehtuurit ja edistysaskeleet nopeissa jatkuvassa ohjelmistojen käyttöönottomenetelmissä ovat vauhdittaneet organisaatioiden luomien ja käytössä olevien API-määrien nopeaa kasvua. Tämän nopean API-tuotannon seurauksena API hajaantuminen on ilmennyt useissa tiimeissä, jotka hyödyntävät useita teknologia-alustoja (vanha, Kubernetes, VM:t jne.) useissa hajautetuissa infrastruktuureissa (paikalliset datakeskukset, useat julkiset pilvet jne.) . Ei-toivottuja kokonaisuuksia, kuten zombie-sovellusliittymiä ja varjosovellusliittymiä, ilmaantuu, kun organisaatioilla ei ole oikeita strategioita API-hajoamisen hallintaan.

Yksinkertaisesti sanottuna zombie-sovellusliittymä on paljastettu API tai API-päätepiste, joka on hylätty, vanhentunut tai unohdettu. Yhdessä vaiheessa API palveli tehtävää. Tätä toimintoa ei kuitenkaan ehkä enää tarvita tai API on korvattu/päivitetty uudempaan versioon. Kun organisaatiolla ei ole asianmukaista valvontaa vanhojen sovellusliittymien versioinnissa, käytöstä poistamisessa ja poistamisessa, kyseiset API:t voivat jäädä päälle loputtomiin – tästä syystä termi zombie.

Koska zombie-sovellusliittymät on pohjimmiltaan unohdettu, ne eivät saa mitään jatkuvaa korjauksia, ylläpitoa tai päivityksiä millään toiminnallisella tai suojauskapasiteetilla. Siksi zombie-sovellusliittymistä tulee turvallisuusriski. Itse asiassa Salt Securityn "API-suojauksen tila” raportissa mainitaan zombie-sovellusliittymät organisaatioiden nro 1 API-turvallisuushuoleksi neljän edellisen tutkimuksensa aikana.

Sen sijaan varjosovellusliittymä on paljastettu API tai API-päätepiste, jonka luominen ja käyttöönotto tapahtui "tutkan alla". Shadow API:t on luotu ja otettu käyttöön organisaation virallisen API-hallinnan, näkyvyyden ja suojauksen valvonnan ulkopuolella. Näin ollen ne voivat aiheuttaa monenlaisia ​​turvallisuusriskejä, mukaan lukien:

• API:lla ei ehkä ole asianmukaista todennus- ja pääsyportteja.
• API saattaa paljastaa arkaluontoisia tietoja väärin.
• API ei ehkä noudata parhaita käytäntöjä tietoturvan kannalta, mikä tekee siitä haavoittuvan monille OWASP API Security Top 10 hyökkäysuhkauksia.

Useat motivoivat tekijät ovat taustalla, miksi kehittäjä tai sovellustiimi haluaisi ottaa APIn tai päätepisteen nopeasti käyttöön. tiukkaa API-hallintastrategiaa on kuitenkin noudatettava, jotta voidaan valvoa ja käsitellä sitä, miten ja milloin API otetaan käyttöön motivaatiosta riippumatta.

Riskejä lisää sovellusliittymien hajaantuminen ja zombie- ja varjosovellusliittymien ilmaantuminen laajemmalle kuin talon sisällä kehitetyt API:t. Kolmannen osapuolen sovellusliittymät, jotka on otettu käyttöön ja joita käytetään osana paketoituja sovelluksia, SaaS-pohjaisia ​​palveluita ja infrastruktuurikomponentteja, voivat myös aiheuttaa ongelmia, jos niitä ei inventoida, hallita ja ylläpidetä asianmukaisesti.

Zombie- ja shadow API:t ovat samanlaisia turvallisuusriskit. Riippuen organisaation olemassa olevista API-säätimistä (tai niiden puutteesta), toinen voi olla vähemmän tai ongelmallisempi kuin toinen. Ensimmäisenä askeleena zombie- ja varjosovellusliittymien haasteisiin vastaamiseksi organisaatioiden on käytettävä asianmukaista API-etsintätekniikkaa, joka auttaa kartoittamaan ja ymmärtämään kaikkia niiden infrastruktuurissa käytettyjä API-liittymiä. Lisäksi organisaatioiden on otettava käyttöön API-hallintastrategia, joka standardoi sovellusliittymien rakentamisen, dokumentoinnin, käyttöönoton ja ylläpidon – tiimistä, tekniikasta ja infrastruktuurista riippumatta.