Scenariul se repetă la fel în fiecare incident: la 03:00 noaptea un atacator intră printr-un VPN expus sau un cont RDP cu parolă slabă, se mișcă lateral în rețea câteva zile fără să fie observat și, înainte să cripteze fișierele de producție, face un singur lucru — șterge backup-urile. Abia apoi pornește criptarea. Dimineața, IMM-ul descoperă că are și serverul blocat, și copiile de siguranță inutile.
Asta este realitatea ransomware-ului modern: nu mai e suficient să ai backup. Trebuie să ai un backup pe care nimeni, nici măcar un administrator compromis, nu îl poate șterge sau modifica pentru o perioadă garantată. Acela este backup-ul imutabil, iar pentru un IMM care procesează facturi, comenzi sau date de pacienți, este diferența dintre o pauză de câteva ore și falimentul.
În acest ghid îți arăt concret ce înseamnă imutabilitatea, cum aplici corect regula 3-2-1 (și varianta ei modernă), cum izolezi copiile și ce pași urmează un IMM pregătit în primele ore după un atac.
1. De ce cedează backup-ul clasic în fața ransomware
Majoritatea IMM-urilor cred că sunt protejate pentru că au „backup". Problema e unde și cum. Atacatorii care folosesc ransomware nu mai criptează doar la întâmplare — operează ca o echipă, fac recunoaștere și caută explicit infrastructura de backup, pentru că știu că o restaurare reușită le anulează cererea de răscumpărare.
Iată tiparele de backup care cad cel mai des:
- NAS-ul mapat ca drive de rețea — dacă serverul vede backup-ul ca pe o literă de disc (
Z:\), atunci și ransomware-ul îl vede. Criptează fișierele de pe NAS exact ca pe restul. - Backup pe același domeniu / aceleași credențiale — un cont de administrator de domeniu compromis are acces și la consola de backup. Atacatorul șterge job-urile și retenția cu câteva clickuri.
- Snapshot-uri pe același hypervisor — utile pentru greșeli umane, inutile când întreg host-ul ESXi/Hyper-V este compromis (un vector tot mai frecvent).
- Cloud sync ≠ backup — OneDrive, Google Drive sau Dropbox sincronizate înseamnă că fișierele criptate se propagă în cloud. Sincronizarea replică dezastrul, nu te salvează de el.
Sincronizare nu înseamnă backup. Un fișier sincronizat în cloud care a fost criptat local va deveni criptat și în cloud în câteva secunde. Backup-ul presupune versiuni istorice, imuabile, la care criptarea de azi nu ajunge.
2. Ce este, de fapt, un backup imutabil
Un backup imutabil este o copie de date care, odată scrisă, nu mai poate fi modificată sau ștearsă pentru o perioadă definită — indiferent cine dă comanda. Nici administratorul, nici un cont compromis, nici malware-ul care rulează cu privilegii maxime. Mecanismul tehnic se numește de regulă WORM (Write Once, Read Many).
Cum se obține imutabilitatea în practică
- Object Lock în storage compatibil S3 — servicii precum Wasabi, Backblaze B2 sau Amazon S3 oferă un „lock" la nivel de obiect. Setezi o retenție (de exemplu 14 sau 30 de zile) și, până la expirare, obiectul nu poate fi suprascris sau șters, chiar dacă cineva are cheile API.
- Repository imutabil în software-ul de backup — Veeam pe Linux hardened repository, Veeam cu Object Lock în cloud, sau soluții similare care marchează blocurile ca imuabile.
- Snapshot-uri imutabile pe storage enterprise — multe soluții NAS/SAN moderne permit snapshot-uri „locked" pe care nici administratorul nu le poate șterge înainte de termen.
- Bandă LTO scoasă din librărie — varianta clasică de air-gap fizic: caseta deconectată nu poate fi atinsă de niciun atac de la distanță.
Punctul esențial: imutabilitatea trebuie să fie garantată de platforma de storage, nu doar o setare „read-only" în software-ul de backup. O simplă bifă de tip „protejat" pe care o poate scoate cineva cu drepturi de admin nu este imutabilitate reală.
Acces inițial (phishing / RDP / VPN) → mișcare laterală 2-10 zile → exfiltrare de date pentru șantaj dublu → ștergerea backup-urilor accesibile → criptarea producției → nota de răscumpărare. Backup-ul imutabil este singura verigă pe care atacatorul nu o poate rupe în pasul al patrulea.
3. Regula 3-2-1 și varianta 3-2-1-1-0
Regula 3-2-1 este fundamentul oricărei strategii serioase de backup și se citește simplu:
- 3 copii ale datelor (producția + 2 backup-uri)
- 2 tipuri diferite de medii de stocare (de exemplu disc local + cloud / bandă)
- 1 copie păstrată în altă locație (offsite)
În contextul ransomware, regula a fost extinsă la 3-2-1-1-0, adăugând două cerințe critice:
- 1 copie offline sau imutabilă (air-gapped / WORM)
- 0 erori la verificarea restaurării — backup-ul testat, nu doar presupus că merge
| Strat | Unde | Rol principal | Imutabil? |
|---|---|---|---|
| Copia 1 (producție) | Server / VPS | Date live | Nu |
| Copia 2 (local) | NAS / repository on-prem | Restaurare rapidă | Recomandat |
| Copia 3 (offsite) | Cloud S3 cu Object Lock | Recuperare după dezastru | Da (obligatoriu) |
În practică, pentru un IMM tipic, configurația funcțională este: backup local pe un repository izolat pentru restaurări de zi cu zi (RTO mic), plus o copie offsite imutabilă în cloud cu Object Lock, ca plasă de siguranță anti-ransomware. Pentru proiectarea corectă a acestor straturi, lucrăm pe partea de infrastructură IT și storage împreună cu echipa de securitate cibernetică.
Setează retenții diferite pe straturi: zilnice 14-30 de zile pentru restaurări rapide, plus copii săptămânale/lunare imutabile pe 3-12 luni. Multe atacuri stau „latente" în rețea câteva săptămâni — o retenție prea scurtă te lasă fără un punct curat de restaurare.
4. Izolare reală: air-gap, WORM și conturi separate
Imutabilitatea rezolvă jumătate din problemă (nu se poate șterge). Izolarea rezolvă cealaltă jumătate: atacatorul nu trebuie să ajungă deloc la consola de backup. Combinația dintre cele două este ceea ce face un IMM cu adevărat rezilient.
Air-gap logic și fizic
Air-gap înseamnă că backup-ul nu este accesibil în mod direct din rețeaua de producție. Fizic, este o bandă LTO scoasă din unitate. Logic, este un repository cloud accesibil doar prin chei API dedicate, niciodată mapat ca drive și niciodată în același domeniu cu serverele.
Conturi și credențiale separate
- Consola de backup are conturi proprii, care NU sunt parte din Active Directory de producție.
- Autentificare multifactor (MFA) obligatorie pe portalul de cloud și pe software-ul de backup.
- Cheile API de scriere către storage-ul imutabil nu permit ștergerea (principiul „append-only").
- Alertă imediată la orice încercare de modificare a politicii de retenție.
Hardened repository
Un repository de backup pe Linux întărit (servicii minime, SSH restricționat, fără acces din rețeaua principală) este mult mai greu de compromis decât un share Windows. Pe acest server, software-ul de backup deține controlul exclusiv asupra fișierelor — nici contul de root nu le poate șterge înainte de expirarea imutabilității.
5. Recuperarea după un atac: ordinea corectă a pașilor
Backup-ul imutabil îți garantează că ai de unde restaura. Dar recuperarea greșit executată poate reinfecta mediul curat. Ordinea contează enorm:
- Izolează, nu opri orbește. Deconectează din rețea sistemele afectate, dar păstrează-le pornite pentru analiză forensică dacă e posibil. Oprirea poate distruge dovezi din memorie.
- Identifică vectorul. Nu restaura înainte să știi cum a intrat atacatorul — altfel restaurezi pe aceeași gaură deschisă și ești criptat din nou.
- Construiește un mediu curat. Servere noi / reinstalate, parole rotite complet, MFA peste tot, înainte de orice restaurare.
- Restaurează din copia imutabilă, alegând un punct anterior compromiterii (de aici contează retenția lungă).
- Scanează datele restaurate înainte de a le reconecta la producție.
- Repune treptat în funcțiune și monitorizează intens primele zile.
Dacă backup-urile au fost și ele afectate sau parțial corupte, intervine recuperarea specializată: în multe cazuri se pot extrage date din volume parțial criptate sau din snapshot-uri reziduale. Aici lucrăm pe partea de recuperare date, dar mesajul onest este că prevenția prin imutabilitate costă de zeci de ori mai puțin decât o recuperare de urgență.
Plata răscumpărării nu garantează decriptarea și te marchează ca țintă „plătitoare". Un backup imutabil testat înseamnă că nu ajungi niciodată în poziția de a negocia. Verifică întâi ce poți restaura.
6. Ce trebuie să facă un IMM, concret
Dacă ești manager sau IT-ist într-un IMM și vrei să închizi acest risc, iată pașii în ordinea în care contează:
- ✅ Inventariază ce date sunt critice (facturare, ERP, baze de date clienți, e-mail) și definește pentru fiecare RPO și RTO realiste.
- ✅ Implementează regula 3-2-1-1-0, cu cel puțin o copie offsite imutabilă (Object Lock în cloud).
- ✅ Separă complet credențialele de backup de Active Directory de producție și activează MFA.
- ✅ Setează retenții în trepte (zilnice scurte + lunare imutabile mai lungi).
- ✅ Testează restaurarea real, lunar — o restaurare completă de probă, nu doar verificarea că job-ul „a rulat".
- ✅ Documentează un plan de răspuns la incident: cine sună, ce deconectează, de unde restaurează.
- ✅ Combină backup-ul cu igienă de securitate de bază: patching, segmentare de rețea, EDR și filtrare e-mail.
Backup-ul imutabil nu este un produs pe care îl bifezi și uiți de el — este o disciplină. Dar este, fără exagerare, cea mai bună investiție de reziliență pe care o poate face un IMM. Restul măsurilor de securitate reduc probabilitatea unui atac; backup-ul imutabil testat reduce impactul la aproape zero. Vezi și opțiunile noastre de protecție anti-ransomware sau detaliile de cost pe pagina de prețuri.