ČE LAHKO IZBRIŠEŠ TUDI VAROVALKO

Varnostne kopije sodijo med ukrepe, pri katerih je občutek varnosti pogosto večji od dejanske odpornosti. Podatek je kopiran, politika hrambe določena, obnovitev je bila morda celo preizkušena. Nadzorna plošča kaže uspešno opravilo in tehnično lahko drži prav vse: kopija obstaja in podatke je mogoče obnoviti. To pa še ne odgovori na pomembnejše vprašanje. Kaj se zgodi, če napadalec namesto same kopije doseže mehanizem, ki določa, kako dolgo bo ta kopija obstajala, kdo jo lahko izbriše in kdo lahko izklopi zaščito pred takšnim brisanjem?

Microsoftova analiza dejavnosti Storm-3168, objavljena 25. septembra 2026, ponuja precej konkreten razlog, zakaj bi morali to vprašanje postavljati pogosteje. V kompromitiranem okolju Azure napadalec ni izvajal samo destruktivnih operacij nad produkcijskimi viri. Poskušal je odstraniti tudi zaščitne ključavnice, povezane z Azure Site Recovery in Azure Backup. Poskusi po Microsoftovih ugotovitvah niso uspeli, vendar je že sama izbira tarče pomembna: poleg produkcije je bila v obseg napada vključena tudi infrastruktura, namenjena njeni zaščiti oziroma obnovi.

Sedem minut za produkcijo

Microsoft je v prizadetem okolju zaznal dva kompromitirana service principala. Eden je predvsem pregledoval infrastrukturo, drugi pa je pozneje izvajal odkrivanje virov, destruktivne operacije in zbiranje poverilnic. Za tukajšnjo zgodbo način začetne kompromitacije ni osrednji; pomembneje je, kaj je bilo mogoče storiti po pridobitvi ustreznih pravic.

Destruktivno zaporedje je trajalo približno sedem minut. V širšem 35- minutnem obdobju je Microsoft zabeležil več kot 150 operacij, povezanih z uničevanjem virov ali zbiranjem poverilnic. Med njimi je bilo več kot sto poskusov brisanja računov Azure Storage, večina napadenih računov pa je bila uspešno izbrisana. Izbrisani so bili tudi Azure Key Vault, Function App in App Service plan. Poskusi brisanja več podatkovnih baz Azure SQL so propadli zaradi uporabe nepodprte različice API-ja.

Nekaj računov Storage je preživelo zaradi Azure resource locks oziroma zaščite pred brisanjem na ravni računa. Prav v istem zaporedju pa je napadalec večkrat neuspešno poskušal odstraniti tudi Azure Site Recovery locks in Azure Backup protection lock, ki so ščitili določene vire. Microsoft je to vedenje uvrstil pod MITRE ATT&CK tehniko T1490 – Inhibit System Recovery.

Tu je razlika med običajno izgubo podatkov in destruktivnim napadom. Pri prvi potrebujemo dobro kopijo. Pri drugem moramo predvidevati, da bo nekdo poskušal vplivati tudi na način, kako bi škodo pozneje odpravili.

Microsoft dogodka ni opisal kot dokončno potrjen klasični ransomware incident. Ni zaznal ransom note in ni potrdil uspešnega odtoka podatkov. Kombinacijo uničevanja virov, poseganja v recovery mehanizme in zbiranja poverilnic pa je ocenil kot vedenje, skladno s taktikami, ki lahko podpirajo ransomware ali izsiljevalske operacije. Ta razlika je pomembna: dokazi kažejo na destruktivni namen in poseganje v možnosti obnovitve, ne pa na potrjeno izsiljevanje v konkretnem incidentu.

Obnova je lahko samostojna tarča

MITRE ATT&CK pod oznako T1490 združuje vedenje, pri katerem napadalec omejuje ali odstranjuje možnosti obnovitve sistema. V klasičnih okoljih to lahko pomeni brisanje Volume Shadow Copies ali backup katalogov, v virtualiziranih okoljih odstranjevanje posnetkov navideznih strojev, v oblaku pa izklapljanje backup politik, versioninga ter brisanje snapshotov, preteklih različic objektov ali drugih virov, namenjenih obnovi.

Princip je starejši od oblaka. Spremenila se je predvsem upravljavska ravnina.

V fizično ločenem okolju je bilo varnostno kopijo razmeroma preprosto razumeti kot nekaj, kar je od produkcije tudi administrativno oddaljeno. V oblaku so lahko produkcijski podatki in njihove varnostne kopije tehnično dobro ločeni, vendar se nad obema še vedno izvajajo operacije prek identitet, vlog, API-jev in centralnih upravljavskih storitev.

Zato ločena kopija in neodvisna pot do obnovitve nista nujno ista stvar.

Če oseba ali kompromitirana identiteta poleg produkcije nadzoruje tudi kritične nastavitve backup okolja, lahko fizična ali logična ločenost podatkov izgubi del svoje vrednosti. Napadalcu ni treba neposredno spreminjati podatkov v backup shrambi, če lahko vpliva na operacije, s katerimi se zaščita ustavi, retention zmanjša ali se sproži dovoljeno brisanje.

Logični air gap ni čarobna meja

Azure Backup vaulted podatke hrani v Microsoftovo upravljani subscription in tenant infrastrukturi, ločeni od produkcijskega okolja izvora. Microsoft to ločitev opisuje kot logical air gap in jo predstavlja kot pomemben del zaščite kopij pred neposredno kompromitacijo produkcijskega okolja.

Toda ista Microsoftova varnostna priporočila ob tem zahtevajo še dodatne plasti zaščite: multi-user authorization z Resource Guardom, nespremenljive oziroma immutable vaults, soft delete, najmanjše potrebne pravice in ločevanje administrativnih odgovornosti. Če bi sama izolacija shrambe rešila celoten problem, teh dodatnih mehanizmov ne bi potrebovali.

Soft delete je namenjen temu, da izbrisani backup podatki še določeno obdobje ostanejo obnovljivi. Microsoftova aktualna dokumentacija navaja nastavljivo obdobje od 14 do 180 dni. Immutable vault lahko prepreči spremembo ali brisanje backup podatkov v obdobju, ki ga določa politika hrambe; če je nespremenljivost tudi zaklenjena, njena nastavitev postane nepovratna. Gre za tri različne lastnosti. Logični air gap ločuje backup podatke od produkcijskega okolja. Soft delete daje dodatno časovno možnost za povrnitev izbrisanih podatkov. Zaklenjena nespremenljivost omejuje možnost spreminjanja oziroma predčasnega brisanja recovery points.

Nobena od teh oznak sama po sebi še ne pove, kako dobro je urejena administrativna ločitev.

Drugi ključ mora pripadati nekomu drugemu

Microsoft za posebej občutljive operacije Azure Backup ponuja Multi- user Authorization (MUA) z Resource Guardom. Kritična operacija na zaščitenem vaultu v takšni konfiguraciji ne temelji samo na pravicah administratorja backupa, ampak zahteva tudi ustrezno avtorizacijo na Resource Guardu.

Med operacijami, ki jih je mogoče oziroma jih je treba zaščititi, so izklop soft delete, odstranitev MUA zaščite, ustavitev zaščite z brisanjem podatkov, zmanjšanje retention politike, spremembe šifriranja in izklop nespremenljivosti. Natančen seznam je odvisen tudi od vrste vaulta in konfiguracije zaščitenih operacij.

Najpomembnejša lastnost Resource Guarda zato ni dodatno potrditveno okno, temveč ločitev pristojnosti.

Microsoft izrecno zahteva, da backup administrator nima vlog Contributor, Backup MUA Admin ali Backup MUA Operator na Resource Guardu, če naj MUA opravlja svojo varnostno funkcijo. Resource Guard je mogoče postaviti v drugo subscription ali celo drug tenant. V Microsoftovem modelu predstavlja različni tenant največjo stopnjo izolacije med backup administratorjem in varnostnim administratorjem.

S tem se bistveno spremeni model napada. Kompromitacija identitete, ki upravlja vault, še ne pomeni nujno tudi možnosti izvedbe vseh zaščitenih kritičnih operacij. Za te je treba pridobiti še ločeno avtorizacijo.

Prav zato je izraz multi-user authorization nekoliko manj pomemben od arhitekturne ideje v ozadju: ena sama administrativna domena ne bi smela hkrati predstavljati poti do produkcije in poti do odstranitve njenega zadnjega mehanizma za obnovo.

Test obnovitve lahko preverja premalo

Pri preverjanju varnostnih kopij običajno zastavimo smiselno vprašanje: ali lahko podatke obnovimo?

Obnovimo datoteko, bazo, navidezni strežnik ali aplikacijo, izmerimo RPO in RTO ter preverimo, ali postopek deluje. Brez tega backup ni veliko več kot obljuba.

Toda tak test večinoma poteka v trenutku, ko so backup sistem, njegove politike in administratorski dostopi še vedno pod našim nadzorom. Destruktivni incident zahteva še drugo vrsto preverjanja: ali

lahko napadalec pred obnovitvijo spremeni pogoje, zaradi katerih je obnovitev sploh mogoča?

Pri takem pregledu postanejo pomembna druga vprašanja. Kdo lahko izklopi soft delete ali zmanjša retention? Kdo lahko spremeni nastavitve nespremenljivosti? Kdo lahko ustavi zaščito in zahteva izbris podatkov? Ali ista privilegirana identiteta upravlja produkcijo in backup? Kdo lahko spreminja Resource Guard in kdo odobrava zaščitene operacije?

To niso vprašanja o kakovosti podatkovne kopije. So vprašanja o arhitekturi zaupanja okoli nje.

MITRE pri zaščiti pred T1490 zato ne priporoča samo rednega izdelovanja backupov. Kopije naj bodo shranjene zunaj izvornega sistema in zaščitene pred običajnimi potmi, po katerih jih lahko napadalec doseže in uniči. Za oblačna okolja MITRE med drugim omenja tudi kopiranje backupov v druge račune ali regije, kjer je to primerno.

»Immutable« mora opisovati lastnost, ne nalepke

Podobna previdnost velja za izraz immutable backup. Pomembno ni samo, da izdelek ali arhitektura uporablja besedo immutable, temveč kaj v konkretni implementaciji dejansko ni mogoče spremeniti, koliko časa ta lastnost velja in kdo jo lahko izklopi.

Azure Backup na primer omogoča zaklep nespremenljivosti vaulta. Microsoft pri tem izrecno navaja, da zaklep naredi nastavitev nespremenljivosti nepovratno, s čimer se zmanjša možnost, da bi jo napadalec po pridobitvi privilegiranega dostopa preprosto izključil. MUA lahko dodatno zaščiti določene kritične operacije, vendar morajo biti za to pravilno ločene tudi pravice nad Resource Guardom.

Enak princip velja zunaj Azure. Dober recovery dizajn se ne ustavi pri vprašanju, kje so kopije shranjene. Preveriti mora tudi, ali je iz kompromitirane produkcije mogoče doseči njihove upravljavske vmesnike, poverilnice, politike hrambe, nespremenljivost in postopke končnega brisanja.

Fizični air gap je ena oblika ločevanja. Logični air gap je druga. Ločena administrativna domena doda novo plast, prav tako ločene identitete in dodatna avtorizacija za destruktivne spremembe.

Nobena od teh tehnik ni univerzalna rešitev. Skupni cilj pa je zelo konkreten: kompromitacija produkcijskega okolja naj sama po sebi ne zagotovi tudi nadzora nad mehanizmom, s katerim bi ga morali pozneje obnoviti.

Skupna odvisnost je vidna šele, ko gre kaj narobe

Centralizirano upravljanje je pri običajnem delovanju učinkovito. Manj računov, manj vlog in ena administrativna pot lahko zmanjšajo kompleksnost.

Pri incidentu ima ista poenostavitev lahko nasproten učinek. Če ena identiteta ali ena administrativna domena doseže produkcijske vire in ključne recovery kontrole, dva tehnično ločena sistema še ne pomenita dveh neodvisnih obrambnih slojev. Še vedno sta lahko odvisna od istega zaupanja.

Storm-3168 tega problema ni ustvaril in tudi ni dokazal uspešnega uničenja Azure Backup podatkov. Pokazal pa je nekaj dovolj pomembnega: napadalec je med uničevanjem produkcijskih virov poskušal odstraniti tudi zaščitne ključavnice, povezane z obnovo, Microsoft pa je njegovo vedenje zato med drugim preslikal v tehniko T1490 – Inhibit System Recovery. Nekatere druge varovalke, predvsem resource locks in zaščita pred brisanjem na delu Storage računov, so medtem dejansko preprečile del destruktivnih operacij.

Pri naslednjem pregledu backup okolja zato ni dovolj preveriti, koliko kopij imamo, kdaj je bila izdelana zadnja in koliko časa potrebujemo za obnovitev. Enako pomembno je ugotoviti, kdo lahko spremeni pogoje, pod katerimi bodo te kopije preživele incident.

Šele takrat lahko ločimo med tem, da backup obstaja, in tem, da imamo tudi dejansko neodvisno pot do obnovitve.

Varnostna kopija postane neodvisna varnostna meja šele takrat, ko napadalec, ki obvladuje produkcijo, ne obvladuje tudi poti do njene obnove.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZOdpornost obnovitve je odvisna tudi od administrativne neodvisnosti: kopija je manj vredna, če kompromitirana identiteta lahko poseže v njene zaščitne mehanizme.

RAZISKAVE0

DOKUMENTACIJA4

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-10-04

Viri

1. 01ADVISORYMicrosoft
   Microsoft Security Research.Storm-3168: Agentic-driven cloud attacks using compromised service principals, 25. september 2026. Primarni vir za časovni potek, obseg destruktivnih operacij, poskuse poseganja v Azure Site Recovery in Azure Backup zaščitne ključavnice ter Microsoftovo razmejitev med opaženimi dejstvi in ransomware- aligned vedenjem.
2. 02PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn.Secure your Azure Backup deployment. Dokumentacija za logical air gap, MUA z Resource Guardom, immutable vaults, soft delete ter druge kontrole Azure Backup. Dokument je bil nazadnje posodobljen 29. septembra 2026.
3. 03PRIMARY DOCUMENTATIONMicrosoft
   Microsoft Learn.Multiuser Authorization Using Resource Guard – Azure Backup. Tehnična dokumentacija za ločevanje vlog, zaščitene operacije ter možnost umestitve Resource Guarda v drugo subscription ali tenant okolje.
4. 04STANDARDMITRE
   MITRE ATT&CK.T1490 – Inhibit System Recovery in M1053 – Data Backup. Referenčni okvir za tehnike onemogočanja obnovitve ter zaščito kopij pred dostopom in uničenjem po kompromitaciji sistema.