Într-un atac ransomware, prima întrebare nu este doar „avem backup?”, ci „putem readuce aplicația într-o stare corectă?”. Pentru fișiere simple, răspunsul poate fi relativ direct: restaurezi documentele curate dintr-o copie sigură. Pentru baze de date, sisteme ERP, magazine online, CRM-uri sau aplicații care scriu continuu tranzacții, lucrurile sunt mai complicate.
Diferența importantă este între o copie de fișiere și un backup application-consistent. Microsoft explică în documentația despre Volume Shadow Copy Service că datele de business sunt adesea salvate în timp ce aplicațiile rulează, iar unele fișiere pot fi deschise sau într-o stare inconsistentă. VSS coordonează aplicația, serviciul de backup și zona de stocare pentru a crea o copie consistentă la un moment dat, fără oprirea aplicației, atunci când componentele suportă acest lucru.
De ce nu ajunge simpla restaurare a fișierelor
O bază de date nu este doar un folder cu fișiere. Ea are tabele, indecși, jurnale de tranzacții, cache în memorie și operațiuni aflate în curs. Dacă un backup prinde fișierele exact când o comandă de plată, o factură sau o actualizare de stoc este pe jumătate scrisă, restaurarea poate porni cu erori, cu date lipsă sau cu tranzacții care nu mai corespund între ele.
Pentru un magazin online, asta poate însemna comenzi vizibile fără plată asociată, stocuri greșite sau conturi de clienți într-o stare incertă. Pentru o firmă care folosește contabilitate, CRM sau aplicații interne, poate însemna ore sau zile pierdute în verificări manuale. Într-un incident ransomware, când presiunea este deja mare, aceste probleme pot bloca revenirea la lucru chiar dacă „backupul există”.
Ce înseamnă application-consistent backup
Un backup application-consistent încearcă să surprindă aplicația într-o stare logică, nu doar să copieze blocuri sau fișiere. În ecosistemul Windows, VSS poate cere aplicațiilor compatibile să își pregătească datele pentru snapshot: să finalizeze scrierile importante, să golească anumite buffer-e și să marcheze corect punctul de recuperare. În Azure Backup, Microsoft arată că pentru mașinile virtuale Windows se poate coordona cu VSS pentru snapshot-uri app-consistent, iar pentru anumite baze de date există soluții workload-aware, cum sunt cele pentru SQL Server sau SAP HANA.
Pe scurt, ideea este simplă: nu vrei doar o poză a discului, ci o copie pe care aplicația o poate înțelege la restaurare. Pentru sisteme tranzacționale, aceasta este diferența dintre „am recuperat niște fișiere” și „serviciul poate porni corect”.
Legătura directă cu ransomware
CISA recomandă organizațiilor să păstreze backupuri offline, criptate și să testeze regulat disponibilitatea și integritatea lor în scenarii de recuperare. Motivul este clar: multe variante de ransomware încearcă să găsească, să șteargă sau să cripteze backupurile accesibile. NIST subliniază, pentru firmele mici, că pregătirea pentru ransomware include protejarea datelor și a dispozitivelor, dar și capacitatea de răspuns și recuperare.
În practică, un plan bun de backup pentru ransomware trebuie să răspundă la trei întrebări. Prima: copia este protejată de atacator, de exemplu prin izolare, acces limitat sau stocare imuabilă unde este potrivit? A doua: copia este suficient de recentă pentru pierderea acceptabilă de date? A treia: aplicația restaurată chiar pornește și datele sunt coerente?
Ce ar trebui să verifice o firmă
Pentru aplicații critice, întreabă furnizorul sau echipa IT dacă backupul este file-consistent, crash-consistent sau application-consistent. Termenii pot suna tehnic, dar impactul este concret. Un backup crash-consistent poate semăna cu situația în care serverul a fost oprit brusc. Uneori aplicația își revine, alteori are nevoie de reparații. Un backup application-consistent este proiectat să reducă acest risc.
Apoi testează restaurarea, nu doar existența fișierului de backup. Testul ar trebui să includă pornirea aplicației într-un mediu separat, verificarea autentificării, deschiderea câtorva înregistrări recente, validarea rapoartelor și confirmarea că jurnalul de tranzacții nu semnalează probleme. Pentru baze de date importante, restaurarea trebuie documentată și repetată periodic.
Nu în ultimul rând, separă conturile de administrare. Dacă același cont care rulează serverul poate șterge și backupurile, ransomware-ul sau un atacator intrat în acel cont poate compromite și planul de recuperare. Accesul minim necesar, autentificarea multifactor și monitorizarea modificărilor la backup nu sunt detalii opționale.
Concluzia practică
În ransomware, backupul nu este o arhivă decorativă, ci ultimul mecanism de continuitate. Pentru fișiere obișnuite, restaurarea simplă poate fi suficientă. Pentru baze de date și aplicații tranzacționale, contează consistența aplicației, testarea restaurării și protejarea copiilor împotriva atacului. Dacă firma ta depinde de un sistem care încasează bani, ține stocuri, emite facturi sau păstrează date de clienți, verificarea backupului application-consistent ar trebui făcută înainte de incident, nu în timpul crizei.
