Avere un backup non significa necessariamente essere in grado di recuperare i propri dati. Prima di andare in ferie, aziende e team IT dovrebbero verificare non solo che le copie siano state eseguite, ma soprattutto che siano integre, accessibili e realmente ripristinabili.
Agosto è tradizionalmente il mese in cui molte aziende rallentano le proprie attività. Una parte del personale è in ferie, gli uffici sono meno presidiati e alcuni processi vengono gestiti con un livello di operatività ridotto, ma infrastrutture, applicazioni, server e sistemi informativi continuano a funzionare e continuano a produrre dati.
È proprio per questo che il periodo estivo può essere un buon momento per porsi una domanda semplice, ma fondamentale:
Se domani perdessimo un sistema critico, quanto tempo impiegheremmo davvero a tornare operativi?
La risposta non dipende soltanto dal fatto di avere un backup.
Dipende dalla capacità di ripristinarlo.
Backup e restore: due facce della stessa strategia
Il backup è una copia dei dati realizzata per consentirne il recupero in caso di perdita o indisponibilità, ma una copia, da sola, non garantisce la continuità operativa.
Un backup potrebbe essere:
• incompleto;
• troppo vecchio;
• corrotto;
• non accessibile;
• configurato in modo errato;
• compromesso insieme ai sistemi di produzione;
• impossibile da ripristinare nei tempi richiesti dal business.
Per questo il backup deve essere considerato all’interno di una strategia più ampia di Backup & Recovery.
Il vero obiettivo non è semplicemente conservare una copia dei dati, ma poterli recuperare in modo affidabile e nei tempi necessari.
Anche le indicazioni NIST più recenti sottolineano l’importanza di creare backup regolarmente, testarli e verificarne l’effettiva capacità di supportare il recovery.
Il backup che non hai mai ripristinato è davvero affidabile?
Questa è probabilmente la domanda più importante.
Un backup può risultare correttamente eseguito dal sistema e, allo stesso tempo, rivelarsi inutilizzabile nel momento in cui serve, per questo è necessario effettuare periodicamente dei restore test: simulazioni controllate che permettono di verificare che i dati possano essere effettivamente recuperati e che il processo di ripristino funzioni come previsto.
Non si tratta soltanto di controllare che il file esista ma assicurarsi realmente che il dato sia integro, leggibile e utilizzabile e, quando necessario, che anche applicazioni, configurazioni e dipendenze possano essere ripristinate correttamente.
NIST raccomanda esplicitamente di effettuare test periodici di restore per verificare sia il successo del ripristino sia il rispetto dei tempi di recupero previsti.
Quando il backup deve resistere anche al ransomware
Il problema diventa ancora più complesso in caso di attacco informatico.
In uno scenario ransomware, l’obiettivo dell’attaccante non è necessariamente soltanto cifrare i dati presenti sui sistemi di produzione. Se riesce ad accedere anche all’infrastruttura di backup, può tentare di compromettere o rendere inutilizzabili le copie necessarie al recovery.
La strategia di backup deve quindi considerare anche la resilienza rispetto agli attacchi cyber.
A seconda delle esigenze dell’organizzazione, questo può significare adottare copie:
• offline;
• segregate rispetto all’ambiente di produzione;
• protette da credenziali e autorizzazioni dedicate;
• cifrate;
• immutabili, quando appropriato;
• periodicamente verificate.
L’obiettivo è creare una copia che possa rimanere disponibile anche nel caso in cui l’ambiente principale venga compromesso.
RTO e RPO: quanto possiamo perdere e quanto possiamo aspettare?
Un altro errore frequente è parlare di backup senza parlare di tempo.
Non tutti i sistemi aziendali hanno la stessa criticità, per un’applicazione non essenziale, un’interruzione di alcune ore potrebbe essere gestibile. Per un sistema che supporta un processo produttivo, un servizio digitale o un’attività commerciale critica, anche pochi minuti possono avere conseguenze significative.
Qui entrano in gioco due parametri fondamentali:
RPO – Recovery Point Objective
Indica quanti dati l’organizzazione può permettersi di perdere in caso di incidente.
Se l’RPO è di quattro ore, ad esempio, la strategia di backup deve consentire di recuperare i dati fino a un punto compatibile con quella finestra temporale.
RTO – Recovery Time Objective
Indica invece quanto tempo può rimanere indisponibile un sistema prima che l’impatto diventi inaccettabile per il business.
RPO e RTO devono quindi essere definiti in funzione della criticità dei servizi e devono guidare la progettazione della strategia di backup e recovery.
In altre parole, non basta chiedersi:
“Abbiamo un backup?”
Bisogna chiedersi:
“Possiamo recuperare i dati che ci servono e tornare operativi entro il tempo che il business può sostenere?”
Prima delle ferie: il Backup & Restore Check
Il periodo estivo può essere anche l’occasione per fare un controllo mirato della propria strategia di recovery.
✓ Verificare gli ultimi backup
Non limitarsi alla presenza del job: controllare gli esiti e gli eventuali errori.
✓ Verificare la copertura
Tutti i sistemi e i dati realmente critici sono inclusi nella strategia?
✓ Eseguire un restore test
Provare concretamente a ripristinare almeno alcuni sistemi o dataset rappresentativi.
✓ Controllare la protezione delle copie
Le copie sono sufficientemente isolate dall’ambiente di produzione? Le credenziali di accesso sono adeguatamente protette?
✓ Verificare RPO e RTO
I tempi definiti sono ancora coerenti con le esigenze attuali del business?
✓ Controllare il piano di recovery
Le procedure sono aggiornate? Le responsabilità sono chiare? Le persone reperibili sanno cosa fare in caso di incidente?
✓ Documentare e migliorare
Ogni test di restore dovrebbe diventare un’occasione per individuare eventuali criticità e aggiornare procedure e documentazione.
Il recente NIST SP 1339 dedica particolare attenzione proprio alla necessità di integrare backup, test, procedure di recovery e lezioni apprese all’interno di un processo continuo di miglioramento.