Microsoft Azure APIM portaalis avastati haavutus, mis võimaldab kontode loomise. Analüüsirame, miks kasutajaliidese piirangud ei asenda pärist autorisatsiooni.

Kujutlege ette olukorda, kus ettevõtte turvajuht on veendunud, et uued kasutajad ei saa nende API-portaali liituda, sest registreerimisnupp on lihtsalt kadunud. See on klassikaline näide sellest, kuidas visuaalne kontrollitunne võib anda valset turvatunnet. Hiljutised avastused Microsoft Azure API Managementi (APIM) arendajaportaali seoses on tõestanud, et see, mida kasutaja ei näe, ei ole tingim없이 kaitstud.

Visuaalne peitmine vs tegelik autorisatsioon

Azure APIM-i arendajaportaal on võimsatööriist API-dokumendatsiooni avaldamiseks ja võtmete haldamiseks. Kuid disainiviga võimaldab ründajatel luua kontosid sellistes tenantites, kus administraatorid on registreerimise visuaalselt keelanud. See ei ole tarkvara koodis olev juhuslik viga, vaid pigem arhitektuurne läbenemine, kus kasutajaliidese (UI) ja backend-i API-te vahel on autorisatsiooni lapp.

Kui administraator valib portaali seadetest registreerimise keelamise, siis eemaldab süsteem lihtsalt registreerimisvidžid portaali esilehelt. Kuid backend-i registreerimispunktid jäävad aktiivseks. See tähendab, et keegi, kes oskab kasutada lihtsaid tööriistu nagu curl või brauseri arendajatoolsid, saab saata registreerimispalbe otse serverile, aegama visuaalse liidese.

Miks nuppude peitmine on vaid viisakus, mitte turvalisus

See Azure'i juhtum on suurem näide probleemist, mida tarkvariarenduses nimetatakse permission-based UI-ks. Paljud arendajad teevad vea, usaldes, et kui kasutaja ei näe teatud nuppu (näiteks Delete või Admin), siis ta ei saa seda funktsiooni kasutada. Tegelikkuses on nuppu peitmine vaid hea kasutajakogemuse (UX) element, et vältida asjatuid 403-veke ja segadust.

Tegelik turvalisus toimub serveris. Autorisatsioon (AuthZ) on protsess, kus server kontrollib iga sissetuleva päringu puhul, kas selleks on õigus, sõltumata sellest, milline liides päringu saatis. Kui server usaldab kliendilt tulnud infot või eeldab, et kasutaja ei tea API-endpointi aadressi, on süsteem haavatav. Kasutajaliidese peitmine ei ole autorisatsioon, vaid lihtsalt viisakus kasutaja suhtes.

Basic authentication kui nõrk lüke

Azure APIM toetab mitmeid identiteedimudeleid, sealhulgas lihtsat Basic authenticationi (kasutajanimi ja parool). Just see mudel on käesoleva haavutuse puhul kriitiline. Microsoft on juba varem soovitanud tootmiskeskkondades hüljata sisseehitatud Basic auth ja ülemine Entra ID-le (endine Azure AD) või teiste moodsa identiteedihaldussüsteemidele.

Kui Basic authentication on aktiveeritud, on backend-i registreerimispunktid avatud ja võtavad vastu uusi kasutajakontode loomise palbeid. See loob riski, et ründaja saab luua kontode ristsektorialise (cross-tenant) võrgustiku, mis võib viia tellimuskvõtmete lekkmiseni ja lolegevama API-juurudeni. Probleemi on kirjeldatud kui haldusplaneerimise piiranguna, mis tähendab, et vastutus süsteemi kõvendamise eest jääb tenantide omanikele.

Andmete lekke riskid ja cross-tenant haavutused

Selle tüüpi haavutused ei ole isoleeritud juhtumid. Tänapäevased küberrünnakud keskenduvad üha rohkem veebirakenduste disainivekudele, mitte operatsioonisüsteemide haavutustele. Üks kriitilisemaid riskidest on cross-tenant andmete avalikustamine, kus rakendus saadab API kaudu rohkem infot, kui kasutajaliides ekraanile kuvab.

Cross-tenant andmete avalikustamine tekib siis, kui veebirakendus saadab tahtmatult infot, mis kuulub teistele kasutajatele või organisatsioonidele, kuigi liides seda infot peidab.

Seda saab saavutada, analüüsides võrguliiklust või kasutades brauseri DevToolsi. Kui backend ei tee ranget kontrolli selle üle, kas päringu esitaja on just selle ressursi omanik, võib üks autentitud kasutaja pääseda teiste klientide andmeteni. Sertifikaatide ja krüpteerimise nõrgused võivad seda protsessi veelgi kiirendada, kui salasekretid on ekslikult kliendile downloadable koodi sisse kirjutatud.

Kuidas ettevõtted end kaitseks võtta

Kuna tegemist on disainipõhise piiranguga, ei kao probleem automaatselt ühe uuendusega. Ettevõtted, kes kasutavad Azure APIM-i, peaksid tegutsema järgmiselt:

Esiteks tuleb kriitiliselt üle vaadata identiteedihaldus. Kõik Basic authenticationi võimalused tuleks asendada Entra ID-ga või teise turvalise identiteedipakkujaga. Teiseks on vaja mõista, et iga API-endpoint peab omama oma iseseisvat autorisatsioonikontrolli. Kolmandaks on soovitatav rakendada pidevat monitoringut, et märkada ebatavalisi registreerimispäringuid, mis ei tule ametlike kanalite kaudu.

Mida see tähendab Eesti ja Balti riikide ettevõtetele

Eesti on tuntud kui e-riik ja meie digiekosüsteem on üks maailma avatumaid ja API-põhisemaid. See teeb meid aga konkurentsivõjelisemaan, kuid samas ka haavatavamaks selliste arhitektuuriliste vigade suhtes. Balti riikide ettevõtted, kes on kiiresti üle läinud pilvelahendustele ja kasutavad Azure'i oma teenuste skaleerimiseks, peavad teadma, et pilvepakkuja vaigenäete (default settings) usaldamine ei ole turvastrateegia.

Seoses Euroopa Liidu AI Act-iga ja rangemate andmekaitsenõudrustega muutub API-turvalisus juriidiliseks küsimuseks. Kui ettevõte lubab cross-tenant andmete lekke tõttu ligipääsu klientide andmetele, ei ole see enam lihtsalt tehniline viga, vaid tõsine rikkumine, mis võib привести suurte trahvidele. Eestis, kus e-valitsuse ja äriandmete integratsioon on sügav, on API-põhine turvalisus kriitilise tähtsusega.

Balti riikide startup-kultuur, mis hindlab kiirust ja agilityt, langeb sageli "nuppude peitmise" lõksu, et kiiremini toodet turule saada. Kuid see Azure'i juhtum on meeldetuletus: turvalisus peab olema ehitatud backend-i südamikku, mitte lisatud kui viimane kiht kasutajaliidesele. Meie digitaalse liidu jätkusuutlikkus sõltub sellest, kas me suudame liikuda visuaalsest turvatunnetest reaalse, null-usaldus (Zero Trust) arhitektuurini.

Korduma kippuvad küsimused

---

Allikad: Windowsforum, Nazarboyko, Esentry ·