Disaster recovery per PMI: come strutturarlo in 7 passi

Inventario e analisi d'impatto

Si parte da un elenco dei servizi, non dei server: gestionale, posta, file condivisi, produzione, sito e-commerce, centralino. Per ciascuno si chiede a chi lo usa cosa succede se si ferma per un'ora, un giorno, una settimana. È la business impact analysis, e non deve essere un documento lungo: basta una tabella con servizio, responsabile, dipendenze e impatto del fermo.

Per dare un numero all'impatto si può usare il calcolatore del costo del downtime: serve a far capire alla direzione perché investire su un servizio e non su un altro.

RTO e RPO per ogni servizio

Due numeri decidono tutta l'architettura (RTO e RPO). L'RTO è il tempo massimo entro cui il servizio deve tornare disponibile. L'RPO è quanti dati si accetta di perdere, misurati in tempo: un RPO di 24 ore vuol dire che un backup notturno basta, un RPO di 15 minuti richiede replica o backup molto frequenti.

Non tutti i servizi meritano lo stesso livello: il gestionale può avere un RTO di quattro ore e l'archivio storico di tre giorni. Fissarli per iscritto evita di spendere troppo dove non serve e troppo poco dove serve. Il calcolatore RTO/RPO aiuta a verificare se l'infrastruttura attuale è in grado di rispettarli.

Architettura dei backup: 3-2-1-1-0

La regola 3-2-1 resta la base: tre copie dei dati, su due supporti diversi, una fuori sede. La variante 3-2-1-1-0 aggiunge due condizioni che oggi contano più delle altre: una copia immutabile o offline, che nessuno può modificare o cancellare per un periodo stabilito (storage WORM, object storage con blocco, nastro o disco scollegato, cioè air gap), e zero errori nella verifica dei backup.

Sulla frequenza si ragiona dall'RPO: backup completi periodici e incrementali tra un completo e l'altro, più snapshot dove servono punti di ripristino ravvicinati. Lo spazio necessario si stima con il calcolatore di dimensionamento dei backup.

Proteggere i backup dal ransomware

Un ransomware moderno cerca i backup prima di cifrare i server. Se il server di backup è nello stesso dominio Active Directory, con le stesse credenziali di amministratore, va giù insieme a tutto il resto. Le contromisure sono poche e precise:

• credenziali del sistema di backup separate da quelle di dominio, con autenticazione a più fattori;
• repository dei backup su una rete separata (VLAN dedicata o micro-segmentazione), raggiungibile solo dal server di backup;
• almeno una copia immutabile o offline, come al passo 3;
• una copia della configurazione del software di backup e delle chiavi di cifratura conservata fuori dall'infrastruttura.

La guida #StopRansomware della CISA mette i backup offline, cifrati e testati tra le prime misure di prevenzione. Per stimare tempi e costi di un ripristino dopo un attacco c'è il calcolatore del recupero da ransomware.

Scegliere dove ripartire

Avere i dati non basta: servono macchine su cui farli ripartire. Le strade sono tre. Ripristino sullo stesso hardware, se è ancora integro: costa poco ma non copre incendi o furti. Un secondo sito, anche modesto, con un host di riserva su cui il failover è già preparato. Oppure il cloud, dove le macchine virtuali vengono accese solo quando servono.

Negli ambienti virtualizzati il lavoro è molto più semplice: con VMware e Veeam, le piattaforme con cui lavoro di più, si possono tenere repliche delle macchine critiche pronte su un secondo host o in un datacenter esterno, e ripristinare una VM direttamente dal backup in pochi minuti. Dove l'RTO è molto basso si passa all'alta disponibilità, che però è un'altra cosa: protegge dal guasto, non dal ransomware, perché replica anche i dati cifrati.

Un runbook scritto

Il giorno del disastro nessuno ricorda le password, l'ordine di avvio dei server o il numero del fornitore della linea. Il runbook è il documento che lo ricorda al posto tuo: chi decide di dichiarare il disastro, chi viene chiamato e in che ordine, la sequenza di ripristino (prima rete e firewall, poi Active Directory e DNS, poi database e applicativi), dove si trovano credenziali e chiavi.

Va conservato anche su carta o comunque fuori dall'infrastruttura che deve aiutare a ripristinare. E va collegato al piano di escalation e alla procedura di notifica degli incidenti, se l'azienda rientra nella NIS2.

Test di ripristino, regolari e documentati

Un backup mai ripristinato è un'ipotesi. Il test minimo è recuperare qualche file e una macchina virtuale in un ambiente isolato, verificando che si avvii e che i dati siano coerenti. Una volta l'anno conviene una prova completa del runbook, con le persone che lo dovrebbero eseguire davvero, misurando i tempi contro l'RTO.

Ogni test si chiude con un verbale: data, cosa è stato ripristinato, quanto tempo è servito, cosa non ha funzionato. È la prova da mostrare a un auditor NIS2 o ISO 27001, ed è il modo più rapido per accorgersi che qualcosa è cambiato. Le simulazioni di crisi servono a testare anche la parte organizzativa.