Molte aziende affermano di avere un backup perché un’attività viene eseguita ogni notte, un dispositivo di archiviazione contiene i file del giorno precedente o un server segnala che i suoi dati sono stati copiati. È un buon punto di partenza, ma non dimostra che l’azienda sia in grado di ripristinare le proprie attività.
Un backup è utile solo quando è disponibile, integro, protetto dallo stesso incidente che colpisce l’originale e utilizzabile entro il tempo che l’azienda può tollerare. Guasti hardware, ransomware, cancellazioni accidentali, corruzione del software e compromissione di un server possono rivelare vulnerabilità che restano invisibili finché tutto sembra funzionare normalmente.
La differenza pratica è tra possedere una copia di backup e avere una capacità di ripristino. La prima è un fatto tecnico. La seconda è un risultato operativo che dipende dal funzionamento coordinato di diversi controlli.
Una copia di backup non equivale a dati recuperabili
Una copia di backup può esistere ma essere comunque inutilizzabile. Potrebbe essere incompleta, danneggiata, troppo vecchia, cifrata dal ransomware, eliminata insieme ai dati sorgente o inaccessibile perché nessuno conosce le credenziali necessarie. L’applicazione di backup potrebbe inoltre segnalare un esito positivo anche se un determinato database, una macchina virtuale o una cartella importante sono stati esclusi dall’attività.
Ecco perché avere una copia di backup è diverso dal poter effettuare un ripristino. Il ripristino richiede fiducia nella copia, una procedura di recupero conosciuta e tempo e accessi sufficienti per completarla.
È utile distinguere tre concetti:
- Esistenza del backup: un’attività ha creato uno o più file, snapshot o versioni archiviate.
- Integrità del backup: i dati archiviati sono completi, leggibili e sufficientemente coerenti per essere ripristinati.
- Ripristino operativo: l’organizzazione può riportare sistemi e dati necessari a uno stato utilizzabile entro gli obiettivi di ripristino concordati.
Spesso le aziende verificano soltanto il primo punto. Gli altri due determinano se il backup protegge i ricavi, il servizio clienti e le attività quotidiane durante un incidente.
I rischi di conservare una sola copia di backup
Una singola copia crea un singolo punto di guasto. Anche se è separata dai dati di produzione, un errore, un dispositivo guasto, un problema di archiviazione o un’azione malevola possono eliminare l’unica via per tornare operativi.
La copia può guastarsi fisicamente
Dischi rigidi, dispositivi NAS, dischi rimovibili e controller di archiviazione possono guastarsi. Un dispositivo di backup può inoltre essere danneggiato da incendio, acqua, surriscaldamento o problemi elettrici. Se il server di produzione e l’unico dispositivo di backup si trovano nella stessa stanza, un singolo incidente fisico può colpirli entrambi.
Anche i supporti hanno una durata utile. Un disco letto raramente può guastarsi proprio quando serve effettuare urgentemente un ripristino. Un backup mai verificato non è necessariamente affidabile: potrebbe essere soltanto un’ipotesi non testata memorizzata su un dispositivo.
La copia può essere eliminata accidentalmente
I rischi di cancellazione non riguardano solo i file di produzione. Un amministratore potrebbe rimuovere il set di backup sbagliato, formattare un disco di backup o modificare un’impostazione di conservazione senza rendersi conto delle conseguenze. La sincronizzazione automatica può peggiorare la situazione: se cancellazioni e file danneggiati vengono replicati immediatamente, il backup potrebbe riprodurre fedelmente il problema invece di conservare una versione precedente.
La copia può essere raggiunta da un attaccante
Gli operatori di ransomware cercano comunemente i backup dopo aver ottenuto l’accesso a un server o a un account amministratore. Possono eliminare i cataloghi di backup, cifrare i repository, disabilitare gli agenti o usare credenziali rubate per accedere allo spazio di archiviazione. Un backup che utilizza lo stesso account di dominio, la stessa password o gli stessi permessi di rete dell’ambiente di produzione può essere esposto durante lo stesso attacco.
È particolarmente pericoloso perché un’attività di backup completata con successo può creare una falsa sensazione di sicurezza. L’attività potrebbe essere stata eseguita correttamente ogni notte, ma se un attaccante può modificare o cancellare il risultato, l’azienda potrebbe scoprire la vulnerabilità solo dopo che il sistema principale è stato cifrato.
La copia potrebbe essere troppo vecchia
Una copia di diverse settimane prima potrebbe ripristinare un server, ma non necessariamente l’azienda. L’organizzazione potrebbe perdere fatture, dati dei clienti, lavori di progetto, ordini o modifiche alla configurazione create dopo la realizzazione della copia. La quantità accettabile di dati persi è definita dall’obiettivo del punto di ripristino, o RPO.
L’RPO è una decisione aziendale espressa in termini di tempo. Un RPO di 24 ore significa che l’azienda accetta la possibilità di perdere fino a un giorno di modifiche. Un RPO di quattro ore è più esigente. La pianificazione dei backup deve riflettere questa aspettativa: un’attività notturna non può garantire con regolarità un punto di ripristino di quattro ore.
Perché la posizione del backup è importante
Un backup archiviato sullo stesso server dell’originale non è una copia di ripristino indipendente. Se il server si guasta, viene rubato, viene cifrato o viene configurato in modo errato, sia i dati originali sia il backup possono scomparire insieme.
Conservare il backup sulla stessa rete locale migliora la comodità, ma non elimina tutti i rischi condivisi. Un account amministratore compromesso, permessi comuni sulle directory, un attacco ransomware o un incidente che coinvolge l’intera rete possono raggiungere entrambi i sistemi. Le copie locali possono essere utili per un ripristino rapido, ma non dovrebbero costituire l’unico livello di protezione.
L’archiviazione esterna separa i dati dagli incidenti che colpiscono la sede del cliente o l’infrastruttura principale. Può inoltre ridurre l’impatto di furti locali, incendi, allagamenti e guasti hardware. La domanda importante non è semplicemente se un provider dica “backup cloud”, ma come la copia sia isolata, chi possa eliminarla, per quanto tempo vengano conservate le versioni e se i dati possano essere effettivamente ripristinati.
La crittografia protegge la riservatezza, ma la proprietà delle chiavi è importante
I dati di backup possono contenere informazioni personali, documenti finanziari, credenziali, codice sorgente e file dei clienti. La crittografia contribuisce a proteggere queste informazioni durante il trasferimento e l’archiviazione. Tuttavia, la crittografia è solida solo quanto il modo in cui vengono gestite le chiavi.
Se il provider del backup conserva la chiave di decrittazione, una compromissione dell’account o un accesso non autorizzato all’interno del servizio potrebbe potenzialmente esporre i dati. Se il cliente controlla la chiave e il provider non la possiede mai, il provider non può decrittare i contenuti del backup per conto del cliente. Questo migliora la riservatezza, ma crea anche una responsabilità: il cliente deve proteggere la chiave e assicurarsi che il personale autorizzato al ripristino possa accedervi quando necessario.
La gestione delle chiavi dovrebbe quindi essere documentata prima di un incidente. L’azienda dovrebbe sapere dove è conservata la chiave, chi può utilizzarla, come viene limitato l’accesso e cosa accade se l’amministratore principale non è disponibile. Un piano di ripristino che dipende dal laptop o dalla memoria di una sola persona non è un piano resiliente.
Conservazione e versioning determinano quanto indietro è possibile recuperare
Un solo backup completato con successo non basta quando il problema viene scoperto in ritardo. Corruzione, malware e modifiche accidentali possono rimanere inosservati per giorni o settimane. Se il sistema di backup conserva soltanto l’ultima versione, lo stato danneggiato potrebbe sostituire quello integro prima che qualcuno se ne accorga.
La conservazione definisce per quanto tempo le versioni del backup rimangono disponibili. Il versioning conserva più punti nel tempo, consentendo all’azienda di scegliere un punto di ripristino precedente all’incidente. Entrambi devono riflettere i rischi dell’organizzazione e il tempo che potrebbe essere necessario per rilevare un problema.
Per esempio, un’agenzia di design potrebbe scoprire che una directory di progetto è stata sovrascritta diversi giorni prima, dopo il reclamo di un cliente. Un piccolo rivenditore potrebbe aver bisogno dei dati precedenti a un’infezione ransomware rimasta inattiva per una settimana. In entrambi i casi, la copia più recente potrebbe essere quella sbagliata.
La conservazione dovrebbe essere valutata insieme ai requisiti legali, contrattuali e operativi. Conservare i dati indefinitamente non è automaticamente più sicuro: può aumentare i costi di archiviazione, l’esposizione alla privacy e il numero di copie da gestire. L’obiettivo è definire una finestra di conservazione ponderata, che supporti scenari di ripristino realistici.
L’immutabilità riduce il rischio di cancellazioni deliberate
Per immutabilità si intende che i dati di backup archiviati non possono essere modificati o eliminati durante un periodo di protezione definito. È una difesa preziosa contro ransomware e account amministratore compromessi, perché un attaccante che raggiunge l’ambiente di produzione non dovrebbe poter cancellare ogni punto di ripristino.
L’immutabilità non sostituisce la crittografia, l’archiviazione esterna o i test. Affronta però una specifica modalità di guasto: l’attaccante o l’amministratore che tenta di modificare il backup dopo la creazione della copia. Il periodo di protezione dovrebbe essere abbastanza lungo da coprire la finestra di conservazione su cui l’azienda fa affidamento.
Le aziende dovrebbero porre domande precise invece di accettare la parola “immutabile” senza ulteriori dettagli:
- L’immutabilità viene applicata a ogni versione conservata o solo ad alcuni dati?
- Un amministratore può accorciare il periodo di protezione o eliminare il repository?
- La protezione continua se il server sorgente è compromesso?
- Per quanto tempo vengono conservati i punti di ripristino?
- Quali dati e tipi di server sono inclusi?
Per i server controllati dal cliente, Safenix combina l’archiviazione esterna in Germania con chiavi di crittografia controllate dal cliente, che Safenix non possiede mai, e mantiene i backup immutabili per tutta la durata della finestra di conservazione. Le aziende che valutano un backup esterno gestito con conservazione, resilienza al ransomware e test di ripristino per i propri server dovrebbero comunque verificare che la configurazione scelta sia in linea con gli obiettivi di ripristino e le responsabilità interne.
Il test di ripristino dimostra che il backup funziona
Un’attività di backup completata dimostra che un processo è stato eseguito. Non dimostra che l’azienda possa avviare le applicazioni, aprire i database o recuperare i file di cui le persone hanno effettivamente bisogno.
Il test di ripristino trasforma un’ipotesi in una prova. Un test di base potrebbe ripristinare una selezione di file in una posizione separata e verificare che si aprano correttamente. Un test più utile include dati applicativi, permessi, coerenza del database e i passaggi necessari per riportare il servizio operativo.
Testa diversi scenari di ripristino
- Ripristino dei file: ripristinare un file eliminato o sovrascritto accidentalmente e verificarne il contenuto.
- Ripristino delle applicazioni: ripristinare i dati e la configurazione necessari per un’applicazione aziendale fondamentale.
- Ripristino del server: ricostruire o ripristinare un server completo dopo un guasto hardware o una corruzione del sistema.
- Ripristino a seguito di un incidente di sicurezza: verificare che sia possibile identificare versioni integre precedenti a un attacco ransomware.
Registra il risultato di ogni test. Indica quanto tempo è stato necessario, quali credenziali sono servite, se mancava qualche file e quali attività richiedevano competenze specialistiche. Un test che rivela un problema è utile: offre all’azienda la possibilità di correggere il processo prima di un’interruzione reale.
I test dovrebbero essere eseguiti dopo cambiamenti significativi all’infrastruttura e a intervalli regolari adeguati all’attività. Dovrebbero inoltre coinvolgere più persone di quella che ha configurato il backup. Se solo un tecnico sa come effettuare il ripristino, l’assenza o il ricambio del personale può diventare un rischio per il recupero.
Il tempo di ripristino è un requisito aziendale, non solo una metrica tecnica
L’obiettivo del tempo di ripristino, o RTO, indica la rapidità con cui un servizio deve tornare disponibile dopo un incidente. Un piccolo ufficio potrebbe tollerare l’assenza di un server documentale per un giorno, mentre un’agenzia che gestisce campagne clienti in corso potrebbe aver bisogno dei dati dei progetti critici molto prima. Non tutti i sistemi richiedono lo stesso RTO.
Chiediti cosa accade durante l’interruzione, non soltanto quanto dura l’esecuzione di un comando di ripristino. Il tempo totale di recupero può includere:
- Identificare l’incidente e selezionare un punto di ripristino integro.
- Ottenere l’accesso al servizio di backup e alla chiave di crittografia.
- Ripristinare il server, il database o i file.
- Reinstallare applicazioni, patch e dipendenze.
- Verificare permessi, integrazioni e coerenza dei dati.
- Confermare che il personale possa lavorare e che i clienti possano essere serviti.
Se la risposta è “lo capiremo quando il server si guasterà”, l’RTO è sconosciuto. Questa incertezza può costare più del servizio di backup stesso.
Una revisione pratica del backup per agenzie e piccole imprese
Utilizza i seguenti controlli per valutare la configurazione che attualmente protegge i tuoi server:
- Elenca i sistemi importanti. Includi server fisici, macchine virtuali, database, archivi di file, dati applicativi e file di configurazione. Non dare per scontato che un’immagine del server includa tutte le dipendenze esterne.
- Annota l’RPO per ogni sistema importante. Decidi quanto lavoro recente l’azienda può permettersi di perdere, quindi verifica che la frequenza dei backup lo consenta.
- Definisci un RTO in base all’impatto aziendale. Identifica quali servizi devono tornare operativi per primi e quali soluzioni temporanee sono disponibili.
- Verifica la separazione delle copie. Assicurati che almeno una copia di ripristino sia esterna e non dipenda dallo stesso hardware, dalla stessa stanza, rete o credenziali amministrative della produzione.
- Esamina i permessi di accesso. Determina se un account del server compromesso potrebbe leggere, modificare o eliminare i backup.
- Conferma la crittografia e la proprietà delle chiavi. Devi sapere chi può decrittare i dati e come il personale autorizzato potrebbe accedere alla chiave durante un’emergenza.
- Esamina conservazione e versioni. Assicurati che la finestra di conservazione copra il rilevamento tardivo di corruzione, malware o cancellazioni accidentali.
- Verifica la protezione contro la cancellazione. Cerca l’immutabilità o un altro controllo che impedisca a un attaccante di eliminare i punti di ripristino.
- Esegui un test di ripristino. Ripristina dati reali, misura il tempo e documenta ogni passaggio e problema.
- Assegna le responsabilità. Indica le persone responsabili del monitoraggio delle attività, della revisione degli avvisi, della gestione delle credenziali e della guida al ripristino.
Questi controlli sono utili anche quando un provider IT esterno gestisce l’infrastruttura. Il titolare dell’azienda resta responsabile di sapere cosa è protetto, con quale rapidità può essere ripristinato e se l’accordo rispetta gli obblighi contrattuali o normativi.
Quando è appropriato un servizio di backup esterno gestito
Gestire internamente i backup può essere ragionevole quando l’organizzazione dispone delle competenze, del tempo e di un’infrastruttura indipendente necessari per monitorare le attività, proteggere le credenziali, gestire la conservazione, mantenere le chiavi di crittografia e testare i ripristini. Il costo non riguarda soltanto lo spazio di archiviazione. Include procedure, disponibilità del personale, documentazione e verifiche periodiche.
Un servizio esterno gestito è appropriato quando è difficile mantenere costantemente queste responsabilità o quando le conseguenze della perdita di un server sono superiori a ciò che l’organizzazione può sostenere con tranquillità. Può offrire un metodo strutturato per proteggere i server controllati dall’azienda lontano dall’ambiente principale, riducendo al contempo la quantità di infrastruttura di backup che il cliente deve gestire direttamente.
Le agenzie dovrebbero inoltre valutare come separare clienti e progetti, con quale rapidità devono ripristinare le applicazioni condivise e chi è autorizzato ad approvare un ripristino. Le piccole imprese dovrebbero identificare i sistemi che consentono loro di operare e non pagare per una promessa vaga di protezione senza verificare ambito, conservazione e procedure di ripristino.
Safenix è progettato per server controllati dal cliente. Non è un piano di backup per un sito web che funziona su hosting condiviso, dove l’azienda non controlla il server sottostante o la configurazione del backup. Se un sito è ospitato su un servizio condiviso, il proprietario deve verificare cosa protegge il provider di hosting e se sia necessaria un’esportazione indipendente o una migrazione verso un ambiente controllato dal cliente.
Fai della recuperabilità uno standard
La domanda non è semplicemente: “Il backup è stato eseguito?”. Una verifica più solida chiede se esiste una versione integra, recente e protetta in una posizione separata, se un attaccante può eliminarla, se la chiave di crittografia è disponibile alle persone giuste e se il team ha dimostrato di saper effettuare un ripristino.
Una sola copia di backup può essere meglio di niente, ma non è una strategia di protezione completa. Separazione esterna, conservazione sensata, versioning, crittografia controllata dal cliente, immutabilità e test di ripristino ripetibili trasformano i dati di backup in una capacità di recupero. Questo è lo standard che agenzie e piccole imprese dovrebbero adottare prima che un incidente renda la risposta urgente.