Continuitate și recuperare: Restaurarea pe care nimeni nu a testat-o

Fiecare tablou de bord al copiilor de siguranță arată bifele verzi. Sarcinile completate, politica de retenție satisfăcută, spațiul de stocare utilizat după cum se aștepta. Nimic din asta nu te spune dacă poți readuce un domain controller de pe metal gol în mai puțin de patru ore în caz de incident real. Golul dintre "copia de siguranță reușită" și "restaurare reușită" este locul unde majoritatea planurilor de continuitate eșuează în tăcere.

De ce bifa minciește

Software-ul de copiere de siguranță raportează succes când termină de scris octeți la o destinație. Nu știe dacă acei octeți sunt utilizabili. O copie de siguranță SQL Server poate fi completată corect și totuși să fie nerestaurabilă pentru că lanțul jurnalului de tranzacții s-a rupt cu trei zile mai devreme și nimeni nu a observat. Snapshot-urile VM pot arăta bine în consolă în timp ce VSS writer-ul din OS-ul invitat a eșuat în tăcere, producând o imagine consecventă în caz de cădere (nu consecventă din punct de vedere al aplicației).

Operatorii de ransomware știu asta. Grupuri care rulează playbook-uri în stil Conti în incidente anterioare au țintit deliberat infrastructura de copiere de siguranță — ștergând copiile umbra cu vssadmin delete shadows /all /quiet, dezactivând depozitele Veeam, criptând țintele de copiere de siguranță bazate pe NAS care erau accesibile peste SMB. Dacă copiile tale de siguranță se află pe același segment de rețea ca producția cu acreditări de domeniu care pot le atinge, sunt o țintă, nu o rețea de siguranță.

Construiește un runbook de restaurare, nu o politică de copiere de siguranță

Un plan de continuitate are nevoie de instrucțiuni de restaurare pas cu pas scrise pentru cineva care nu este persoana care de obicei o face. Notează:

• Ordinea exactă de recuperare (controlerii de domeniu și DNS mai întâi, apoi aplicațiile de bază, apoi totul altceva)
• Unde se află acreditările pentru consola de copiere de siguranță dacă camera de coduri de acces este și ea nefuncțională
• Comanda de restaurare specifică sau calea consolei, nu "folosește Veeam pentru a restaura VM-ul"
• Durata așteptată pe sistem, pe baza testelor măsurate cu adevărat, nu cifrele de marketing ale furnizorului

Pentru Veeam Backup & Replication, asta înseamnă documentarea pașilor reali: deschide consola, navighează la Backups > Disk, fă clic dreapta pe punctul de restaurare, alege Instant VM Recovery sau Full VM Restore în funcție de scenariu, și selectează gazda țintă cu suficientă capacitate liberă. Dacă gazda ta principală este și ea compromisă, ai nevoie de o a doua gazdă, izolată, deja identificată și licențiată.

Testează restaurări pe o programare, nu la voia cuiva

Alege o rotație. În fiecare lună, restaurează un sistem critic pe un VLAN izolat și validează că se lansează, se autentifică și servește date corect. În fiecare trimestru, execută un test cu domeniu complet: restaurează controllerul de domeniu, serverul de fișiere și baza de date principală pe infrastructură izolată, apoi cere cuiva din afara echipei de copiere de siguranță să încerc să se conecteze și să tragă un raport.

Pentru baze de date, nu doar restaura fișierul .bak — verifică-l:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

ApoiRestorează-l de fapt la o instanță de test și rulează DBCC CHECKDB împotriva lui. O copie de siguranță care trece VERIFYONLY poate totuși conține corupție logică care apare doar când o interogezi.

Pentru sisteme Linux folosind ceva de genul Bacula sau restic, testează calea de restaurare reală:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

ApoiCompară fișierele de configurare restaurate cu producția pentru a confirma că nimic nu a scăzut în tăcere.

Copii imuabile și regula 3-2-1-1

Regula clasică 3-2-1 (trei copii, două tipuri de media, o copie offshore) are nevoie de o actualizare pentru era ransomware: 3-2-1-1, unde "1" suplimentar este o copie imuabilă sau deconectată de aer. Object lock pe stocare compatibilă cu S3 (Wasabi, Backblaze B2, sau AWS S3 cu Object Lock activat) previne ștergerea sau modificarea pentru o fereastră de retenție definită, chiar și de către un cont cu acreditări administrative. Configurează-l cu:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Modul COMPLIANCE înseamnă că nimeni, inclusiv contul root, nu poate scurta retenția sau șterge obiectele mai devreme. Asta contează când atacatorul are admin de domeniu.

Măsoară RTO și RPO cu numere reale, nu ghiciri

Recovery Time Objective și Recovery Point Objective sună ca exerciții de hârtie până când un executive întreabă "cât de mult date pierdem și cât timp suntem nefuncționali." Cronometrează ultimele trei restaurări de test. Dacă ținta RTO este o oră dar sarcina de copiere de siguranță se execută doar la fiecare șase, ai un decalaj documentat, și e mai bine să găsești acel decalaj într-un exercițiu tabelar decât în timpul unui eveniment real de criptare la 2 dimineața sâmbătă.

Execută testul, notează ora reală pe ceas, și compară-o cu ceea ce ai promis în documentul de recuperare după dezastru. Diferența dintre acele două numere este starea reală a planului de continuitate.

Pentru mai mult despre consolidarea sistemelor pe care le protejezi și construirea fluxurilor de răspuns la incidente, verifică segmentele Blue Team și Digital Forensics conexe pe Korra Studio.