Continuità e Ripristino: Il Restore che Nessuno ha Testato

Ogni dashboard di backup mostra spunte verdi. Job completati, policy di retention soddisfatta, storage utilizzato come previsto. Niente di tutto questo ti dice se riesci a portare un domain controller dal bare metal in meno di quattro ore durante un incidente reale. Il gap tra "backup riuscito" e "restore riuscito" è dove la maggior parte dei piani di continuità fallisce silenziosamente.

Perché la spunta mente

Il software di backup riporta successo quando finisce di scrivere byte su una destinazione. Non sa se quegli byte sono utilizzabili. Un backup di SQL Server può completarsi correttamente e comunque essere non ripristinabile perché la catena del transaction log si è rotta tre giorni prima e nessuno l'ha notato. Gli snapshot VM possono sembrare ok nella console mentre lo scrittore VSS sottostante ha silenziosamente fallito dentro il guest OS, producendo un'immagine crash-consistent (non application-consistent).

Gli operatori ransomware lo sanno. I gruppi che eseguono playbook stile Conti negli incidenti passati hanno deliberatamente preso di mira l'infrastruttura di backup — eliminando copie shadow con vssadmin delete shadows /all /quiet, disabilitando repository Veeam, crittografando target di backup basati su NAS raggiungibili via SMB. Se i tuoi backup vivono sullo stesso segmento di rete della produzione con credenziali di dominio che possono toccarli, sono un target, non una rete di sicurezza.

Costruisci un runbook di restore, non una policy di backup

Un piano di continuità ha bisogno di istruzioni di restore step-by-step scritte per qualcuno che non è la persona che normalmente lo fa. Scrivi:

• Ordine esatto di recovery (domain controller e DNS primo, poi app core, poi tutto il resto)
• Dove vivono le credenziali per la console di backup se anche il tuo password vault è down
• Il comando di restore specifico o il percorso della console, non "usa Veeam per ripristinare la VM"
• Durata prevista per sistema, basata su test reali misurati, non su numeri di marketing dei vendor

Per Veeam Backup & Replication, significa documentare i passi effettivi: apri la console, naviga a Backups > Disk, fai click destro sul restore point, scegli Instant VM Recovery o Full VM Restore a seconda dello scenario, e seleziona l'host di destinazione con abbastanza capacità libera. Se il tuo host primario è compromesso, hai bisogno di un secondo host isolato già identificato e licensiato.

Testa i restore su uno schedule, non su impulso

Scegli una rotazione. Ogni mese, ripristina un sistema critico a un VLAN isolato e valida che avvii, autentichi e serva i dati correttamente. Ogni trimestre, esegui un test di scope completo: ripristina il tuo domain controller, il tuo file server e il tuo database primario su infrastruttura isolata, poi fai a qualcuno fuori dal team di backup tentare di fare login e estrarre un report.

Per i database, non limitarti a ripristinare il file .bak — verificalo:

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

Poi ripristinalo effettivamente a un'istanza di test ed esegui DBCC CHECKDB su di essa. Un backup che passa VERIFYONLY può comunque contenere corruzione logica che emerge solo quando lo interroghi.

Per i sistemi Linux che usano qualcosa come Bacula o restic, testa il percorso di restore effettivo:

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

Poi fai un diff dei file di config ripristinati contro la produzione per confermare che nulla è silenziosamente caduto.

Copie immutabili e la regola 3-2-1-1

La classica regola 3-2-1 (tre copie, due tipi di media, uno offsite) ha bisogno di un aggiornamento per l'era del ransomware: 3-2-1-1, dove l'extra "1" è una copia immutabile o air-gapped. Object lock su storage compatibile S3 (Wasabi, Backblaze B2, o AWS S3 con Object Lock abilitato) previene cancellazione o modifica per una finestra di retention definita, anche per un account con credenziali admin. Configuralo con:

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

La modalità COMPLIANCE significa che nessuno, incluso l'account root, può accorciare la retention o cancellare gli oggetti anticipatamente. Questo importa quando l'attaccante ha domain admin.

Misura RTO e RPO con numeri reali, non supposizioni

Recovery Time Objective e Recovery Point Objective sembrano esercizi burocratici fino a quando un executive chiede "quanti dati perdiamo e quanto tempo siamo down." Cronometra i tuoi ultimi tre test di restore. Se il tuo target RPO è un'ora ma il tuo job di backup esegue solo ogni sei, hai un gap documentato, ed è meglio trovare quel gap in un esercizio da tavolo che durante un evento di crittografia effettivo alle 2 del mattino di un sabato.

Esegui il test, scrivi l'orario effettivo, e confrontalo con quello che hai promesso nel documento di disaster recovery. La differenza tra questi due numeri è lo stato reale del tuo piano di continuità.

Per approfondimenti sull'hardening dei sistemi che stai proteggendo e sulla costruzione di workflow di incident response, consulta i segmenti Blue Team e Digital Forensics correlati su Korra Studio.