Un backup locale è meglio di nessun backup, ma non costituisce un piano di ripristino completo. Se il backup si trova sullo stesso server, array di storage, rete o sito del sistema di produzione, lo stesso incidente può colpire sia i dati attivi sia la loro copia di ripristino.
Questo è importante quando un ransomware cifra i file raggiungibili, quando un disco si guasta senza preavviso o quando un incendio, un'alluvione, un furto, un problema di alimentazione o un errore dell'operatore rende indisponibile un intero sito. L'azienda potrebbe avere ancora tecnicamente un backup, ma non necessariamente uno utilizzabile.
Per un'agenzia o una piccola impresa, non si tratta solo di un inconveniente informatico. Un ripristino non riuscito può bloccare la posta elettronica, la contabilità, i portali clienti, la consegna dei progetti, i file interni e le applicazioni aziendali. I clienti potrebbero subire ritardi o indisponibilità dei servizi prima ancora che l'azienda abbia individuato la causa.
Perché un backup locale può fallire insieme al server principale
Per backup locale si intende generalmente una copia conservata vicino al sistema che protegge. Può trattarsi di un secondo disco nello stesso server, di un'unità di backup collegata alla rete, di un NAS in ufficio o di un'altra macchina nella stessa sala server. Queste configurazioni possono rendere pratici i ripristini brevi e ordinari. Tuttavia, non garantiscono automaticamente la separazione da un incidente grave.
Il ransomware può raggiungere più dei dati di produzione
Gli operatori ransomware non si limitano sempre a cifrare il server principale. Una volta ottenute credenziali amministrative o dopo essersi spostati nella rete, possono cercare condivisioni di backup, storage collegato, console di gestione e punti di ripristino più vecchi. Se un backup locale è continuamente raggiungibile con le stesse credenziali, può essere cifrato, eliminato o corrotto deliberatamente.
Alcuni attacchi prendono di mira anche il software di backup e la sua configurazione. L'obiettivo è chiaro: eliminare la capacità dell'organizzazione di ripristinare i dati e aumentare quindi la pressione affinché paghi. Una seconda copia online, scrivibile e visibile dall'ambiente compromesso potrebbe non offrire una protezione significativa contro il ransomware.
L'eliminazione è grave quanto la cifratura. Un attaccante può rimuovere i punti di ripristino, svuotare le aree del cestino, disattivare i processi pianificati o modificare le impostazioni di conservazione. Anche un dipendente che cerca di contenere un incidente può eliminare i file sbagliati o scollegare lo storage nel momento meno opportuno. Un backup deve essere protetto sia dalle modifiche dannose sia da quelle accidentali.
I guasti hardware e dei dischi non rispettano le pianificazioni dei backup
Dischi rigidi, SSD, controller RAID, alimentatori e schede madri dei server possono guastarsi. Il RAID può mantenere operativo un server dopo il guasto di un disco, ma non è un backup: replica o distribuisce i dati nello stesso sistema, invece di creare una copia di ripristino indipendente.
Anche un disco di backup locale può guastarsi, soprattutto se funziona continuamente nello stesso ambiente o se non è stato monitorato e testato. Se il server e lo storage di backup condividono controller, alimentazione, stanza o sistema di raffreddamento, un singolo guasto può colpirli entrambi. Un processo di backup che segnala un esito positivo può comunque contenere file illeggibili o uno stato applicativo incompleto se i ripristini non vengono verificati.
Gli eventi che colpiscono i locali eliminano ogni copia vicina
Il rischio non è limitato agli attacchi informatici. Un furto può portare via contemporaneamente server e unità di backup. Un incendio può distruggere un ufficio o una sala del data center. Un'alluvione può danneggiare le apparecchiature di diversi piani o di un intero edificio. Un problema di alimentazione può mettere fuori uso produzione e storage locale, mentre una sovratensione può danneggiarli entrambi.
Anche se un dispositivo di backup locale sopravvive, l'azienda potrebbe non riuscire ad accedervi. L'edificio potrebbe essere chiuso, la rete non disponibile oppure le persone che sanno gestire il sistema potrebbero essere impegnate a loro volta nell'emergenza. La vicinanza fisica è utile per alcuni ripristini rapidi, ma diventa una debolezza quando la copia di ripristino non dispone di una separazione geografica o logica.
L'errore dell'operatore è un rischio per il ripristino
Gli errori umani sono cause comuni di perdita dei dati: una directory viene eliminata, una macchina virtuale viene sovrascritta, una policy di conservazione viene modificata oppure un processo di backup viene disattivato durante la manutenzione e mai riattivato. I sistemi locali spesso consentono a un amministratore con autorizzazioni estese di modificare sia i dati di produzione sia il loro backup.
Una progettazione ripristinabile presuppone che le persone commettano occasionalmente degli errori. Utilizza controlli di accesso separati, conservazione protetta, procedure chiare e test di ripristino, invece di affidarsi al fatto che un singolo amministratore ricordi ogni passaggio sotto pressione.
Backup locale, backup off-site e ripristino 3-2-1
I termini sono correlati, ma non intercambiabili. Un'azienda può avere più copie e mantenere comunque un piano di ripristino fragile se tutte le copie dipendono dallo stesso server, account, luogo o alimentatore.
Backup locale
Un backup locale è conservato nello stesso sito o nella stessa infrastruttura del server protetto. Il suo principale vantaggio è la velocità. Se un singolo file viene eliminato e il server resta in buone condizioni, il ripristino da uno storage vicino può essere più rapido del recupero dei dati attraverso una connessione di rete verso un'altra sede.
I suoi limiti sono altrettanto concreti:
- Può essere raggiunto dal ransomware tramite credenziali compromesse.
- Può essere distrutto o rubato insieme al server principale.
- Può dipendere dalla stessa elettricità, rete, amministratore o hardware.
- Può creare una falsa sensazione di sicurezza se nessun ripristino è stato testato.
Il backup locale può essere un livello utile, soprattutto per i ripristini operativi rapidi. Non dovrebbe essere l'unico livello. Un confronto più ampio tra limiti del backup locale e rischi del ripristino off-site chiarisce il punto centrale: una copia vicina non è automaticamente una copia indipendente.
Backup off-site
Un backup off-site è conservato lontano dall'ambiente di produzione. La separazione può essere fisica, logica o entrambe. Se il server dell'ufficio viene compromesso, i dati di ripristino non dovrebbero essere esposti attraverso lo stesso percorso ordinario. Se i locali subiscono danni, l'azienda dovrebbe comunque poter accedere al repository di backup da un'altra posizione.
La protezione off-site è più efficace quando comprende cifratura, accesso controllato, conservazione che non può essere riscritta facilmente e un processo di ripristino già sperimentato. La sola posizione non basta. Una copia conservata in un edificio diverso ma collegata con credenziali senza restrizioni può essere comunque vulnerabile a un attacco di rete.
Un approccio 3-2-1 realmente ripristinabile
Il principio 3-2-1 è una buona base:
- 3 copie: conservare i dati di produzione e almeno due copie aggiuntive.
- 2 tipi di storage o ambienti: evitare di collocare ogni copia sullo stesso tipo di sistema o percorso di accesso.
- 1 copia off-site: fare in modo che un incidente a livello del sito non elimini ogni opzione di ripristino.
Per la resilienza al ransomware, il modello richiede maggiori dettagli. Almeno una copia di ripristino dovrebbe essere isolata dall'accesso in scrittura ordinario e protetta dalle modifiche durante il periodo di conservazione. È qui che entra in gioco l'immutabilità. Un backup immutabile non può essere modificato o eliminato attraverso le normali operazioni durante il periodo di conservazione definito, riducendo la possibilità che un attaccante o un amministratore sotto pressione cancelli la cronologia di ripristino.
L'immutabilità non sostituisce il controllo degli accessi, la cifratura, il monitoraggio o i test. È uno dei controlli all'interno di una progettazione di ripristino. L'organizzazione deve inoltre sapere come autenticarsi, richiedere il ripristino, ottenere le chiavi necessarie e ricostruire i servizi che dipendono dai dati.
La cifratura e la custodia delle chiavi determinano la possibilità di ripristinare i dati
I dati di backup possono contenere anagrafiche clienti, fatture, contratti, credenziali, file sorgente, esportazioni della posta elettronica e informazioni personali. Conservare questi dati off-site senza cifratura crea un rischio per la riservatezza. La cifratura protegge i dati se i supporti di storage o i canali di accesso vengono esposti.
Tuttavia, la cifratura introduce una responsabilità pratica: qualcuno deve controllare la chiave. Se un provider detiene l'unica chiave utilizzabile, il cliente può avere un controllo indipendente più limitato sull'accesso ai propri dati di ripristino. Se la chiave viene persa, i dati di backup possono diventare permanentemente illeggibili anche se lo storage è integro.
Con Safenix, i backup vengono cifrati utilizzando una chiave che Safenix non conserva. Questa progettazione mantiene la custodia della chiave presso il cliente, invece di rendere il provider l'unica autorità in grado di decifrare i dati. La chiave deve quindi essere protetta, documentata e resa disponibile alle persone autorizzate quando è necessario un ripristino. Un'azienda dovrebbe definire chi ha accesso, dove vengono conservate le informazioni di emergenza sulla chiave e come trasferire l'accesso se l'amministratore abituale non è disponibile.
La pianificazione del ripristino dovrebbe rispondere a queste domande prima di un incidente:
- Chi è autorizzato a richiedere un ripristino?
- Chi può accedere alla chiave di cifratura?
- Come vengono verificate le richieste durante una crisi?
- Cosa succede se l'amministratore principale è malato, irraggiungibile o colpito dallo stesso incidente?
- I dati ripristinati possono essere utilizzati dall'applicazione oppure richiedono configurazioni e credenziali aggiuntive?
Una buona custodia delle chiavi bilancia sicurezza e disponibilità. Conservare una chiave sullo stesso server del backup cifrato vanifica lo scopo della separazione. Conservarla nella memoria di una sola persona crea un altro singolo punto di guasto.
Conservazione, RPO e RTO trasformano il backup in un piano di ripristino
La conservazione determina quanto indietro è possibile ripristinare
La conservazione è il periodo durante il quale vengono mantenuti i punti di ripristino. Una finestra breve può essere sufficiente per un'eliminazione accidentale, ma inutile se il ransomware rimane inosservato per diverse settimane. Una finestra più lunga offre all'organizzazione maggiori opportunità di trovare un punto di ripristino integro, soprattutto quando un attaccante ha modificato silenziosamente i file prima di attivare la cifratura.
La conservazione dovrebbe riflettere le esigenze dell'azienda. Un'agenzia potrebbe aver bisogno di vecchi file di progetto, documenti di fatturazione e materiali consegnati ai clienti. Un piccolo rivenditore o uno studio di servizi professionali potrebbe dover conservare i documenti finanziari e normativi molto più a lungo rispetto alle istantanee operative quotidiane. Il punto importante è decidere consapevolmente, invece di accettare un'impostazione predefinita mai verificata.
L'RPO definisce la perdita di dati accettabile
L'obiettivo del punto di ripristino, o RPO, è il periodo massimo di dati recenti che l'azienda è disposta a perdere. Se i backup vengono eseguiti una volta al giorno, un guasto del server potrebbe comportare la perdita di quasi un'intera giornata di lavoro. Se l'azienda può tollerare una perdita di un'ora al massimo, la pianificazione dei backup e la capacità della rete devono supportare una protezione più frequente.
L'RPO non è solo un'impostazione tecnica. Ha un costo. Backup più frequenti utilizzano più storage, larghezza di banda e tempo di elaborazione. L'obiettivo corretto dipende dal valore e dalla velocità di modifica dei dati, oltre che dalle conseguenze della loro ricreazione manuale.
L'RTO definisce il tempo di inattività accettabile
L'obiettivo del tempo di ripristino, o RTO, indica con quale rapidità un servizio deve tornare disponibile dopo un incidente. Ripristinare pochi file e ricostruire un intero server sono attività diverse. Un RTO dovrebbe tenere conto del trasferimento dei dati, della decifratura, della configurazione del sistema operativo, dell'installazione delle applicazioni, dell'attivazione delle licenze, delle modifiche DNS, dell'accesso degli utenti e della convalida.
Un'azienda che promette un ripristino rapido dei servizi deve conoscere le proprie dipendenze. Il server potrebbe dipendere da un database, da un servizio directory, da un relay di posta elettronica, da una regola firewall, da una licenza software, da un'API esterna o da una configurazione specialistica non contenuta nei dati di backup. Un backup può ripristinare perfettamente i file e lasciare comunque l'applicazione indisponibile.
Il test di ripristino distingue una copia da una vera capacità di recupero
Un processo di backup completato con successo dimostra soltanto che una procedura è terminata secondo quanto previsto dal software. Non dimostra che i file necessari siano presenti, che il backup sia coerente o che l'azienda possa operare dopo il ripristino.
I test di ripristino dovrebbero essere pianificati a diversi livelli:
- Ripristino dei file: ripristinare singoli documenti, caselle di posta o directory di progetto.
- Ripristino del sistema: ripristinare un server completo o una macchina virtuale su un'infrastruttura adeguata.
- Ripristino dell'applicazione: verificare che database, servizi, autorizzazioni e configurazione funzionino insieme.
- Convalida aziendale: chiedere agli utenti di svolgere attività realistiche e verificare che i dati siano completi.
I test dovrebbero registrare quanto tempo richiede ogni fase, quali credenziali sono necessarie e quali passaggi dipendono da una persona specifica. La procedura dovrebbe essere aggiornata dopo modifiche ai server, aggiornamenti software, riprogettazioni della rete e cambiamenti nelle responsabilità del personale.
I backup off-site protetti con cifratura, recupero dal ransomware, conservazione e test di ripristino possono essere valutati nell'ambito del più ampio servizio di backup e ripristino Safenix. La domanda rilevante non è semplicemente quanto storage sia incluso. È se la progettazione riduca il numero di decisioni che un piccolo team deve prendere durante un evento disruptive, mantenendo al contempo il controllo del cliente sui dati protetti.
Come un'agenzia o una piccola impresa può continuare a operare
Quando il server principale non è disponibile, il ripristino dovrebbe iniziare dalla definizione delle priorità, non dal panico. Occorre identificare i servizi che mantengono operativa l'azienda e quelli che possono attendere. Un ordine pratico potrebbe essere:
- Confermare l'incidente e isolare i sistemi interessati senza distruggere le prove o le opzioni di ripristino.
- Scegliere un punto di ripristino integro in base all'RPO e al probabile momento della compromissione.
- Ripristinare il server o l'applicazione più importante in un ambiente controllato.
- Verificare dati, accesso degli utenti e flussi di lavoro critici prima di ricollegare ampiamente il servizio.
- Fornire al personale e ai clienti una procedura operativa temporanea e chiara.
Le operazioni temporanee possono prevedere l'accesso in sola lettura ai dati essenziali, canali di comunicazione alternativi, la gestione manuale degli ordini o dei ticket oppure un'offerta di servizi ridotta. Il piano dovrebbe indicare chi comunica con i clienti, chi approva le soluzioni alternative e come vengono riconciliate le nuove transazioni dopo il ritorno dei sistemi.
Per un'agenzia, ciò potrebbe significare dare priorità ai file di progetto, alle comunicazioni con i clienti, ai registri delle ore e alla fatturazione. Per una piccola impresa, potrebbe significare ripristinare ordini, dati di magazzino, appuntamenti, sistemi finanziari o assistenza clienti. L'obiettivo non è sempre ripristinare ogni server contemporaneamente. È ripristinare prima i servizi che riducono l'impatto sui clienti e proteggono il flusso di cassa.
Le dipendenze del ripristino dovrebbero essere documentate separatamente dal backup stesso. È necessario mantenere un inventario dei ruoli dei server, dei dettagli di rete, dei responsabili delle applicazioni, delle informazioni sulle licenze, dei record DNS, dei contatti essenziali e degli accordi sulla custodia delle chiavi. Non bisogna dare per scontato che la persona che ha configurato il server sia disponibile durante un incendio, un attacco ransomware o una malattia improvvisa.
Il costo di affidarsi solo al backup locale
Una strategia esclusivamente locale sembra economica perché può utilizzare dischi e hardware già disponibili. Il costo nascosto emerge durante un guasto. Il personale potrebbe trascorrere giorni cercando di capire cosa è sopravvissuto, trovare una copia integra, ricostruire i sistemi e ricreare le informazioni mancanti. Apparecchiature d'emergenza, supporto specialistico, straordinari e vendite perse possono superare rapidamente il costo di una protezione off-site adeguata.
Il downtime influisce anche sulla fiducia. I clienti potrebbero non rispettare le scadenze, perdere l'accesso ai materiali consegnati o chiedersi se le informazioni riservate siano state protette. L'azienda potrebbe dover spiegare l'incidente, analizzare una possibile esposizione, informare le parti interessate e negoziare proroghe. Anche quando i dati vengono infine recuperati, l'impatto operativo e reputazionale può rimanere.
Il backup server off-site non garantisce che ogni incidente sarà privo di conseguenze. È un modo per ridurre il numero di eventi che si trasformano in perdita permanente dei dati e offrire all'azienda un percorso definito per tornare operativa. Il valore deriva dalla combinazione di separazione, cifratura, custodia delle chiavi sotto il controllo del cliente, conservazione immutabile, obiettivi RPO e RTO adeguati e test regolari di ripristino.
Costruire la resilienza intorno ai server sotto il tuo controllo
Safenix è adatto alle aziende che proteggono server sotto il proprio controllo, siano essi a supporto di un'agenzia, di un piccolo ufficio o di un'applicazione rivolta ai clienti. L'ambito è importante: non si tratta del backup di un sito ospitato su hosting condiviso, dove il cliente non controlla il server sottostante o il processo di backup. Un sito su hosting condiviso dovrebbe essere valutato sulla base delle soluzioni di backup e ripristino del provider di hosting.
Per un server sotto il tuo controllo, inizia mappando i dati e i servizi che dipendono da esso. Poi identifica cosa può coprire un backup locale, cosa deve essere conservato off-site, per quanto tempo i punti di ripristino devono rimanere immutabili, chi controlla la chiave di cifratura e come verrà testato un ripristino. Documenta le prime ore di un'interruzione con la stessa attenzione dedicata alla pianificazione dei backup.
Una copia locale può aiutarti a ripristinare rapidamente un piccolo errore. Una copia off-site isolata, cifrata e immutabile offre maggiori possibilità di recupero quando il problema è il server, la rete, i locali o un attaccante. Questa distinzione è alla base di una protezione pratica contro il ransomware e dei piani di disaster recovery.