Disaster Recovery per aziende: come ripristinare sistemi e dati dopo un attacco

Quando un’azienda subisce un incidente informatico serio la domanda da farsi non è solo “come evitare che accada di nuovo”, ma come tornare operativi nel più breve tempo possibile: ne parliamo in questo articolo.

Come presentato nella nostra panoramica sulla Cyber Security, per disaster recovery si intende la capacità dell’organizzazione di riportare in funzione sistemi e dati dopo un incidente informatico. Il termine è volutamente ampio: il incidente può essere un attacco esterno, un errore umano grave, un guasto infrastrutturale o un evento fisico che rende indisponibili server e servizi.

L’obiettivo non è semplicemente “avere un backup”: è garantire continuità operativa con tempi e modalità misurabili. In altre parole, il disaster recovery definisce quanto puoi permetterti di restare fermo e quanti dati puoi permetterti di perdere senza compromettere vendite, produzione, servizi o adempimenti normativi.

Il disaster recovery plan è il documento operativo che stabilisce:

• quali sistemi vanno ripristinati per primi
• con quali procedure
• in quali tempi
• con quali responsabilità
• e su quali risorse tecniche (backup, repliche, ambienti alternativi)

Lo scopo primario di un piano di disaster recovery è evitare che la ripartenza sia improvvisata. Durante un incidente grave, infatti, il caos è un moltiplicatore di danni: tempi lunghi, errori di priorità, interventi non coordinati.
Un buon DRP non deve essere un tomo teorico. Deve essere chiaro, testabile e aggiornato, perché in caso di attacco si usa davvero.

Un piano di disaster recovery efficace nasce da un processo molto concreto.

1. Identificare i servizi critici
   Non tutto ha lo stesso valore. Si parte da un inventario realistico: ERP, e-commerce, posta, file server, sistemi industriali, CRM, servizi cloud, ecc. Se serve, qui torna utile un lavoro preliminare di cyber risk assessment (tema che hai già affrontato in un altro cluster).
2. Definire priorità di ripristino
   Quali sistemi devono tornare su entro poche ore e quali possono aspettare? Le priorità vengono esplicitate nel piano, insieme ai dipendenti/team “owner” dei servizi.
3. Collegare le priorità alle misure tecniche
   Qui il legame con backup e disaster recovery è diretto: backup, repliche, ambienti secondari o DRaaS sono strumenti, ma devono servire priorità e obiettivi definiti prima.
4. Preparare le procedure operative
   Chi fa cosa quando scatta l’incidente? Quali check? Quali accessi? Quali escalation? Le procedure devono essere semplici e ripetibili, perché durante una crisi non si ha tempo di interpretare.
5. Test periodici
   Un disaster recovery plan esempio scritto bene ma mai testato non è un piano: è un’illusione. La prova pratica serve per scoprire gli errori prima del disastro e ridurre i tempi reali di ripristino.

Come abbiamo detto, affinché un piano di ripristino delle emergenze sia efficace deve essere misurabile nei suoi obiettivi. Le due metriche chiave per valutare un DRP sono:

RTO significato (Recovery Time Objective)
Il recovery time objective indica il tempo massimo accettabile di indisponibilità di un servizio.
Esempio pratico: “l’e-commerce deve tornare operativo entro 4 ore”

RPO (Recovery Point Objective)

Il recovery point objective definisce quanti dati si può perdere al massimo.
Esempio: “posso tollerare al massimo 30 minuti di dati non salvati”.

RTO e RPO non sono concetti “da IT”: sono decisioni di business. Perché stabiliscono il confine tra un fermo gestibile e un danno potenzialmente irreversibile.

Con infrastrutture ibride e workload distribuiti, cresce anche la ricerca su cloud disaster recovery. Il motivo è semplice: la replica in cloud o un ambiente secondario gestito permettono di ridurre costi e tempi rispetto a un secondo data center fisico.

DRaaS e disaster recovery as a service

Il disaster recovery as a service (DRaaS) è un modello in cui:

• i dati e le macchine critiche vengono replicati su un ambiente cloud
• il provider gestisce infrastruttura, automazioni e test
• l’azienda attiva il failover quando serve

Conviene soprattutto quando non si può sostenere un sito secondario interno oppure si hanno RTO/RPO stretti su servizi digitali. E’ un’ottima soluzione anche perché permette di fare test periodici senza avere ulteriori costi e garantisce la possibilità di monitoraggio continuo che può essere richiesta per esempio dalla NIS2.

Il disaster recovery per aziende non è un progetto secondario, ma una misura che separa un incidente costoso ma gestibile da una crisi capace di fermare il business per giorni. La sua importanza sta nella differenza tra “subire” un attacco informatico e ripartire nell’immediato.