Nella Business Continuity post-pause la presenza di copie di sicurezza da sola non basta, occorre una verifica della loro integrità, accessibilità e reale capacità di ripristino. Prima dei picchi autunnali, testare i backup significa ridurre l’incertezza proprio quando il margine per gestire un’interruzione si restringe.
la pausa estiva come stress test mancato o occasione di prevenzione
pDurante l’estate, alcune Aziende riducono il ritmo operativo, altre mantengono attivi i servizi essenziali con team ridotti, turnazioni differenti o una minore presenza delle figure tecniche. In entrambi i casi, la ripartenza di settembre e ottobre può riportare rapidamente i sistemi a un’intensità elevata.p
È proprio in questa fase che la continuità operativa merita un controllo dedicato.
Un backup può risultare completato correttamente senza che ciò garantisca, da solo, il recupero di un’applicazione o di un servizio aziendale. La copia potrebbe essere incompleta, non aggiornata, non accessibile con le credenziali disponibili o incompatibile con l’ambiente in cui deve essere ripristinata.
La verifica, quindi, non dovrebbe limitarsi alla console di backup ma deve includere una prova concreta di recupero e una valutazione dei tempi necessari per tornare operativi.
Le indicazioni di CISA (Cybersecurity and Infrastructure Security Agency) raccomandano di mantenere copie di backup offline e cifrate e di verificarne regolarmente disponibilità e integrità attraverso scenari di disaster recovery. Anche il NIST sottolinea l’importanza di pianificare, mantenere e testare i backup in relazione alle esigenze specifiche dell’Azienda.
Dal backup al ripristino: la differenza che conta
Nel linguaggio IT, backup e recovery sono spesso associati, ma descrivono due momenti ben distinti.
- Backup: creare e conservare una copia dei dati o dei sistemi.
- Recovery: utilizzare quella copia per recuperare informazioni, applicazioni e servizi dopo un incidente.
In sostanza il backup è una misura di protezione, il ripristino è la prova della sua efficacia.
Pensiamo a un gestionale aziendale che contiene ordini, anagrafiche clienti e informazioni amministrative. Il sistema di backup può segnalare che la copia notturna è stata eseguita ma, se al momento del bisogno il database non si apre, mancano le credenziali necessarie o l’applicazione dipende da componenti non disponibili, il dato salvato non si traduce automaticamente in continuità operativa.
Che cosa verificare prima dei picchi autunnali
Un controllo efficace dovrebbe seguire un percorso ordinato, partendo dai servizi più importanti per il business.
1. Identificare ciò che non può fermarsi
Non tutti i sistemi hanno lo stesso impatto sull’Azienda. Prima di verificare i backup, occorre stabilire quali applicazioni, dati e infrastrutture siano essenziali per mantenere attiva l’operatività, per esempio sistemi ERP e gestionali, CRM e database clienti, posta elettronica e strumenti di collaborazione, file server e documentazione aziendale, applicazioni di produzione o di erogazione del servizio, configurazioni di rete, server e ambienti virtualizzati.
L’elenco deve considerare anche le dipendenze: un’applicazione può essere ripristinata correttamente, ma restare inutilizzabile se il database, il sistema di autenticazione o un servizio infrastrutturale necessario non è disponibile.
La priorità non dovrebbe essere determinata esclusivamente dalla quantità di dati salvati, ma dall’impatto che la loro indisponibilità avrebbe sulle attività aziendali.
2. Controllare che i backup siano aggiornati e integri
Naturalmente i backup devono essere aggiornati e integri
In questa fase è utile verificare:
- la data dell’ultima copia valida;
- la frequenza effettiva delle esecuzioni;
- eventuali job falliti o incompleti;
- la presenza di errori ricorrenti;
- la disponibilità dello spazio di archiviazione;
- la coerenza tra ciò che deve essere protetto e ciò che viene effettivamente incluso.
Un backup recente non è necessariamente un backup utilizzabile. Per questo l’integrità va verificata con controlli adeguati e, soprattutto, con prove di ripristino.
3. Verificare accessibilità e protezione delle copie
Le copie devono essere disponibili quando servono, ma non dovrebbero essere esposte senza adeguate protezioni agli stessi eventi che potrebbero compromettere i sistemi di produzione.
Un attacco ransomware, per esempio, può cercare di raggiungere anche i backup accessibili dalla rete, compromettendo la possibilità di recuperare i dati.
Per ridurre questo rischio, CISA raccomanda copie offline e cifrate, oltre a verifiche regolari della loro disponibilità e integrità. In base all’architettura adottata, possono essere valutati anche isolamento, immutabilità e separazione dei privilegi di accesso.
È importante, inoltre, verificare che le credenziali necessarie al ripristino siano disponibili e protette, senza dipendere esclusivamente da un account o da un sistema che potrebbe risultare compromesso durante un incidente.
4. Eseguire un test di ripristino reale
È un passaggio importante finalizzato alla verifica di integrità del backup.
Un test di restore, infatti, consiste nel recuperare dati o sistemi da una copia di backup, in un ambiente controllato, per verificare che il processo funzioni correttamente.
Il test può partire da un singolo file o da un database e arrivare, quando necessario, al ripristino di una macchina virtuale o di un servizio completo.
Durante la prova è opportuno verificare:
- che la copia selezionata sia leggibile;
- che i dati siano integri e coerenti;
- che il sistema ripristinato si avvii;
- che l’applicazione sia effettivamente utilizzabile;
- che le dipendenze necessarie siano disponibili;
- che il tempo di recupero sia compatibile con le esigenze operative.
Il NIST include i test di ripristino tra le attività utili a verificare l’integrità delle copie e ad aumentare la fiducia nelle capacità di recupero dell’Azienda.
Un test concluso con successo non dimostra che ogni possibile incidente sia gestibile. Dimostra, però, che uno scenario concreto è stato verificato e fornisce evidenze utili per migliorare il piano.
RTO e RPO: due parametri da conoscere prima di un incidente
Per valutare la tenuta dei backup, oltre a sapere che un ripristino è riuscito, bisogna anche capire quanto tempo ha richiesto e quanti dati è stato necessario recuperare.
Due parametri aiutano a tradurre queste esigenze in obiettivi misurabili: RTO e RPO.
RTO: Recovery Time Objective
È il tempo massimo di interruzione che l’Azienda si pone come obiettivo per recuperare un servizio.
Esempio: se l’RTO è di 4 ore, il piano deve puntare a ripristinare il servizio entro 4 ore dall’interruzione, secondo lo scenario definito.
RPO: Recovery Point Objective
È la quantità massima di perdita di dati, espressa come intervallo temporale, che l’Azienda considera tollerabile.
Esempio: con un RPO di 1 ora, l’obiettivo è poter recuperare dati con un punto di ripristino che non sia più vecchio di un’ora rispetto all’evento, nei limiti dello scenario definito.
RTO e RPO non sono valori da impostare in modo arbitrario. Devono essere concordati con chi conosce i processi aziendali e riflettere l’impatto di un’interruzione o della perdita di dati.
Un sistema può essere ripristinato correttamente, ma non rispettare l’RTO previsto. Oppure può tornare disponibile rapidamente, ma recuperare dati troppo vecchi rispetto all’RPO concordato.
In entrambi i casi, il test ha fatto emergere una criticità concreta: il piano esiste, ma deve essere adeguato alle necessità operative.
Il fattore umano: la continuità non si esaurisce nella tecnologia
La ripartenza autunnale coinvolge anche le persone che devono gestire eventuali anomalie.
Chi è autorizzato ad avviare il ripristino? Chi decide quali servizi recuperare per primi? Chi contatta il fornitore? Chi comunica l’impatto ai reparti coinvolti?
Un piano di continuità efficace deve chiarire responsabilità, procedure e modalità di comunicazione, affinché le attività tecniche siano coordinate con le decisioni operative.
È utile verificare anche la documentazione: procedure aggiornate, contatti dei referenti, credenziali di emergenza custodite in modo sicuro, dipendenze tecniche e istruzioni per il ripristino.
Le linee guida NIST sul recupero da eventi di cybersecurity sottolineano l’importanza della pianificazione, dei playbook, dei test e del miglioramento continuo sulla base delle evidenze raccolte.