Il ransomware fa più che cifrare i file di un singolo computer. Quando raggiunge un server aziendale, può diffondersi nelle cartelle condivise, abusare dei privilegi di amministratore, disattivare gli strumenti di sicurezza e cercare ogni sistema di backup connesso. Gli aggressori non vogliono soltanto interrompere le operazioni: cercano di eliminare la tua capacità di recuperare i dati senza pagare.
Per questo l'architettura di backup è parte integrante della protezione dei server dal ransomware. Un backup online, scrivibile e controllato dalle stesse credenziali dell'ambiente di produzione può essere attaccato insieme ai dati originali. Una copia presente solo su un disco locale può essere eliminata. Un provider di backup che può leggere i dati o reimpostare l'accesso senza la tua approvazione può diventare un ulteriore punto di pressione.
I backup a prova di ransomware si basano su separazione, accesso limitato, cifratura, controlli di conservazione e test regolari di ripristino. Questa guida si applica ai server di proprietà o sotto il controllo dell'azienda, inclusi server fisici, macchine virtuali e infrastrutture cloud dedicate. Non descrive un piano Safenix per siti web o database eseguiti su hosting condiviso. I clienti di hosting condiviso devono verificare quali backup esegue il provider e come viene gestito il ripristino.
Come il ransomware trasforma i backup in uno strumento di ricatto
Un attacco tipico inizia da un servizio esposto, una password rubata, un allegato dannoso o un'applicazione non aggiornata. Una volta entrato, l'aggressore cerca di aumentare i privilegi e muoversi lateralmente. I server sono particolarmente preziosi perché spesso contengono dati aziendali e offrono accesso ad applicazioni, condivisioni di file, database e sistemi di identità.
L'aggressore può trascorrere del tempo a esplorare l'ambiente prima di cifrare qualsiasi cosa. In questo periodo può individuare il software di backup, le console di gestione, le condivisioni di rete e i processi pianificati. Può rubare le credenziali utilizzate dagli agenti di backup o dagli amministratori, per poi attendere il momento in cui riuscirà a colpire contemporaneamente i sistemi di produzione e di ripristino.
Quando inizia la fase di cifratura, le conseguenze possono includere:
- File aziendali e dati applicativi diventano inaccessibili.
- Macchine virtuali, database o file server vengono cifrati o danneggiati.
- Gli agenti di backup e i servizi di gestione vengono arrestati.
- I dischi di backup locali e le condivisioni di rete vengono eliminati o cifrati.
- Le credenziali di ripristino vengono modificate o utilizzate per distruggere i punti di ripristino.
- I dati vengono copiati fuori dall'ambiente per estorcere un pagamento.
Per questo un'organizzazione può avere un processo di backup che ieri aveva segnalato un esito positivo e tuttavia non riuscire a recuperare i dati oggi. L'esistenza di un backup non equivale all'indipendenza del ripristino. La domanda importante è se un aggressore che controlla un server di produzione possa anche modificare, cancellare, leggere o rendere inaccessibile il backup.
Per approfondire prima di valutare un provider o riprogettare un piano di ripristino, cerca procedure di backup dei server resistenti al ransomware e confronta il modo in cui ogni approccio gestisce accesso, conservazione e ripristino.
Perché i backup locali e sempre connessi falliscono
Le copie locali sono esposte allo stesso incidente
Un disco USB, una seconda unità interna o un server di backup nello stesso ufficio possono essere utili per un recupero rapido, ma non sono sufficienti come unica protezione. Incendi, furti, problemi di alimentazione e guasti hardware possono colpire sia il server originale sia le sue copie locali. Il ransomware può avere la stessa portata se il dispositivo di backup è montato, mappato o accessibile tramite la rete.
Se un account di backup dispone dell'accesso in scrittura a un repository locale, il malware che utilizza quell'account può riuscire a eliminare le versioni storiche o sostituirle con file cifrati. Anche quando i dati non vengono cifrati, l'aggressore può semplicemente rimuovere il catalogo o la configurazione necessari per il ripristino.
I repository scrivibili offrono agli aggressori un obiettivo
Il software di backup normalmente deve scrivere nuovi punti di ripristino. È necessario per il normale funzionamento, ma crea un rischio quando il repository resta liberamente scrivibile troppo a lungo. Se un aggressore ottiene le credenziali utilizzate dal servizio di backup, potrebbe modificare o eliminare i punti esistenti oltre a crearne di nuovi.
I controlli di conservazione cambiano questo equilibrio. Un punto di ripristino bloccato o immutabile non può essere modificato o eliminato durante il periodo di protezione, anche se una credenziale amministrativa è stata compromessa. L'immutabilità non impedisce ogni tipo di incidente e non sostituisce i controlli di accesso o i test, ma elimina una delle azioni più dannose per l'attaccante: distruggere silenziosamente lo storico dei ripristini.
I sistemi connessi possono condividere lo stesso punto di guasto
Un sistema di backup gestito dalla stessa piattaforma di identità, dalla stessa workstation amministrativa o dallo stesso segmento di rete della produzione può ereditare la stessa compromissione. La gestione centralizzata è comoda, ma la comodità non dovrebbe significare che una sola password rubata controlli ogni copia dei dati.
L'infrastruttura di ripristino dovrebbe essere trattata come un confine di sicurezza separato. Meno percorsi ha un aggressore da un server di produzione al repository, meno è probabile che la compromissione di un server diventi una compromissione totale del ripristino.
Cosa comprende una strategia di backup multilivello contro il ransomware
Nessuna singola funzionalità rende un backup completamente a prova di ransomware. La resilienza nasce dalla combinazione di diverse misure di protezione.
Copie separate fuori sede
Un backup fuori sede crea distanza dall'incidente. Può proteggere da un evento nella sala server, da un'interruzione che colpisce l'intera sede o da un aggressore che ha assunto il controllo della rete locale. La separazione deve essere concreta: un repository che si trova tecnicamente altrove, ma viene amministrato tramite lo stesso account compromesso, potrebbe non offrire sufficiente indipendenza.
Safenix offre backup fuori sede per i server aziendali, con i dati di backup archiviati in Germania. Il servizio è destinato ai server controllati dal cliente, non ai siti ospitati su una piattaforma di hosting condiviso. Agenzie e piccole imprese dovrebbero mappare ogni server importante, identificarne dati e applicazioni e verificare che il design di backup scelto possa proteggere questi sistemi.
Conservazione immutabile
L'immutabilità significa che i punti di ripristino sono protetti da modifica o cancellazione per un periodo di conservazione definito. Tale periodo dovrebbe coprire l'intervallo durante il quale un attacco potrebbe rimanere inosservato. Se il ransomware era presente da diverse settimane prima della cifratura, un periodo di conservazione breve potrebbe preservare solo dati già compromessi.
Con Safenix, i dati di backup sono immutabili per tutta la durata del periodo di conservazione scelto. L'impostazione della conservazione merita quindi particolare attenzione. Non è soltanto una preferenza di archiviazione: è parte del piano di risposta agli incidenti.
Cifratura prima del trasferimento
La cifratura protegge la riservatezza dei dati di backup durante il trasferimento e l'archiviazione. È importante anche quando il repository si trova in una giurisdizione affidabile, perché gli operatori dello storage, gli account compromessi e gli insider non autorizzati non dovrebbero poter leggere automaticamente i file aziendali.
La cifratura è più efficace quando viene eseguita prima che i dati lascino l'ambiente controllato dal cliente e quando la chiave è gestita dal cliente. Safenix utilizza la cifratura prima del trasferimento e la chiave di cifratura è controllata dal cliente: Safenix non la conserva mai. Questo modello è progettato per impedire agli aggressori o al provider di leggere i dati di backup senza la chiave in possesso del cliente. Scopri di più sulle chiavi di cifratura gestite dal cliente e su come mantengono illeggibili i dati di backup per aggressori e provider.
La custodia della chiave comporta una responsabilità oltre a un vantaggio. Se l'azienda perde la chiave, potrebbe perdere la possibilità di decifrare i propri punti di ripristino. Le procedure per le chiavi dovrebbero includere archiviazione sicura, accesso limitato, responsabilità documentata e un processo di recupero testato. Una chiave non dovrebbe esistere solo nella memoria di un dipendente o sullo stesso server che il ransomware potrebbe compromettere.
Accesso con privilegi minimi
Gli account di backup dovrebbero avere solo le autorizzazioni necessarie per il loro compito specifico. Un account di servizio che può scrivere i dati di backup non ha necessariamente bisogno dell'autorizzazione per eliminare tutti i punti storici, amministrare il sistema operativo o accedere a server non correlati.
Tra i controlli pratici rientrano:
- Credenziali separate per gli agenti di backup, l'amministrazione del repository e l'amministrazione dei server.
- Autenticazione a più fattori per le interfacce di gestione, quando supportata.
- Accesso limitato per ruolo, dispositivo, rete e orario, ove opportuno.
- Rimozione degli account amministrativi inutilizzati e delle password condivise.
- Monitoraggio di cancellazioni insolite, modifiche alla conservazione o attività di accesso.
- Archiviazione sicura delle credenziali di ripristino al di fuori del server di produzione.
L'accesso dovrebbe essere riesaminato quando il personale lascia l'azienda, cambiano le responsabilità o un'agenzia perde un cliente. Un ex amministratore con credenziali di backup valide può essere pericoloso quanto un aggressore esterno.
Test di ripristino
Un processo di backup completato con successo dimostra che i dati sono stati scritti. Non dimostra che un'applicazione possa avviarsi, che un database sia coerente, che le credenziali funzionino o che l'azienda conosca la corretta sequenza di ripristino. I test trasformano un'ipotesi in una prova.
I test dovrebbero includere sia singoli file sia sistemi completi. Per un'applicazione critica, verifica che il server ripristinato si avvii, che i servizi partano, che i database si aprano, che le autorizzazioni degli utenti restino corrette e che i sistemi dipendenti riescano a connettersi. Registra il tempo necessario e gli eventuali passaggi manuali. Un ripristino che funziona solo quando un dipendente non disponibile ricorda una procedura non documentata non è un piano di recupero affidabile.
Come scegliere il periodo di conservazione corretto
La conservazione dovrebbe riflettere sia le esigenze operative sia il probabile tempo di permanenza dell'aggressore nell'ambiente. Conservare più versioni non è automaticamente meglio se l'azienda non può permettersi lo spazio di archiviazione o non sa identificare un punto di ripristino integro. Conservare troppe poche versioni può lasciare nessuna copia utilizzabile quando l'infezione viene scoperta.
Piccole imprese e agenzie dovrebbero considerare:
- Quanto rapidamente verrebbe rilevato il ransomware dopo la prima compromissione.
- Con quale frequenza cambiano i dati importanti e quanta perdita di dati è accettabile.
- Se norme legali, contrattuali o contabili richiedono la conservazione dei dati storici.
- Per quanto tempo potrebbe essere necessario riesaminare un progetto, una campagna o una transazione.
- Per quanto tempo l'azienda può operare mentre un sistema viene analizzato e ricostruito.
- Se il periodo di conservazione copre fine settimana, festività e assenze del personale.
Un approccio utile consiste nel definire un obiettivo del punto di ripristino, cioè l'età massima accettabile dei dati ripristinati, e un obiettivo del tempo di ripristino, ovvero il tempo accettabile per ripristinare il servizio. Aggiungi poi una conservazione storica sufficiente a tenere conto dei ritardi nel rilevamento. Un'azienda potrebbe aver bisogno di punti recenti frequenti per gli errori quotidiani e di punti protetti più vecchi per un evento ransomware.
La conservazione dovrebbe essere riesaminata dopo cambiamenti importanti, come l'aggiunta di un nuovo server, lo spostamento di un'applicazione, la modifica degli obblighi normativi o la scoperta che un attacco è rimasto inosservato più a lungo del previsto. L'immutabilità è utile solo quanto il periodo durante il quale i dati integri restano disponibili.
Come verificare i punti di ripristino prima di un incidente
La verifica dovrebbe essere una pratica ordinaria, non qualcosa da tentare per la prima volta durante un'interruzione. Inizia controllando che i processi pianificati vengano eseguiti per ogni server necessario e che gli errori generino un avviso che qualcuno abbia la responsabilità di analizzare.
Esamina un campione di punti di ripristino e conferma le date, lo stato di protezione e le dimensioni previste. Un backup insolitamente piccolo può indicare un volume mancante, un agente non funzionante o una directory esclusa. Un processo completato con successo ma privo di dati recenti non è un piano di ripristino efficace.
Esegui ripristini controllati secondo una pianificazione. Per i file, apri documenti rappresentativi e verifica le autorizzazioni. Per i database, utilizza un processo di recupero consapevole dell'applicazione e controlla la coerenza. Per i server completi, testa la procedura di ricostruzione o ripristino in un ambiente isolato, dove non possa interferire con la produzione.
Conserva un registro del ripristino contenente:
- Il server e l'applicazione coperti.
- Il punto di ripristino selezionato e il motivo per cui è stato considerato integro.
- La chiave e le credenziali necessarie, senza esporre questi segreti nel registro.
- I passaggi completati e il tempo impiegato.
- Eventuali errori, dipendenze o soluzioni manuali temporanee.
- Il responsabile incaricato di correggere i problemi.
Le prove ottenute da un test di ripristino aiutano inoltre un'agenzia a dimostrare ai clienti l'esistenza di controlli adeguati. È più credibile indicare quando è stato eseguito l'ultimo test di recupero che limitarsi a dire che i backup esistono.
Cosa fare con le credenziali di backup prima di un attacco
Proteggere le credenziali di backup richiede la stessa disciplina necessaria per proteggere gli account di amministratore del dominio. Non salvarle in testo semplice sul server che proteggono, in un foglio di calcolo non gestito o in una chat condivisa. Utilizza un gestore di password adeguatamente protetto o un processo controllato per la gestione dei segreti e assicurati che più di una persona autorizzata possa accedere alla procedura di ripristino senza creare una password ampiamente condivisa.
Separa l'accesso di emergenza da quello quotidiano. Il personale ordinario non dovrebbe disporre permanentemente dei diritti per eliminare i punti di conservazione o modificare i criteri del repository. Quando possibile, utilizza un accesso amministrativo soggetto ad approvazione o limitato nel tempo per le azioni ad alto impatto. Esamina i log di audit per rilevare modifiche alla conservazione, alle impostazioni di cifratura, alle destinazioni del repository e ai ruoli amministrativi.
Decidi inoltre come reagirà l'organizzazione se si sospetta che una credenziale sia stata rubata. La procedura può includere la disabilitazione dell'account, la rotazione dei segreti, la conservazione dei log, l'isolamento dei server e il contatto con l'amministratore del backup. Progettare questo processo durante la cifratura significa sprecare tempo prezioso.
Priorità durante un incidente ransomware
Il primo obiettivo è fermare ulteriori danni, non affrettarsi a eseguire un ripristino che potrebbe reintrodurre l'aggressore. Isola i server e gli endpoint coinvolti secondo il piano di risposta agli incidenti. Disconnetti i sistemi dalla rete quando opportuno, preserva le prove e coinvolgi i responsabili della sicurezza, dell'infrastruttura e delle decisioni legali o normative.
Successivamente, stabilisci ciò che è noto. Identifica quali server sono interessati, quando potrebbe essersi verificata la prima attività sospetta, quali credenziali sono state esposte e se i sistemi di backup sono stati consultati. Non dare per scontato che il punto di ripristino più recente sia sicuro. Scegli un punto basandoti sulle prove, sullo storico dei backup integri e sulla priorità aziendale del sistema.
Assegna la priorità ai sistemi secondo un ordine definito:
- Identità, autenticazione e servizi di rete fondamentali necessari per supportare il ripristino.
- Applicazioni critiche necessarie per fornire prodotti, servizi o funzioni legate alla sicurezza.
- Database e servizi file da cui dipendono tali applicazioni.
- Sistemi di comunicazione, finanziari e amministrativi.
- Sistemi meno critici e dati storici.
L'ordine esatto varia in base all'organizzazione. Un'agenzia potrebbe ripristinare prima i file di progetto e i sistemi rivolti ai clienti, mentre un piccolo produttore potrebbe dare priorità al controllo della produzione e all'inventario. Documenta le dipendenze prima di un incidente, così il sistema più visibile non viene ripristinato prima dei servizi di cui ha bisogno.
Quando i backup sono inaccessibili, danneggiati o nelle mani dell'aggressore
Se i backup sono inaccessibili, l'azienda potrebbe affrontare un'interruzione più lunga mentre ricostruisce account, infrastruttura e storage. Se sono danneggiati, il recupero potrebbe richiedere l'individuazione di un punto più vecchio e la verifica manuale di ogni sistema. Se l'aggressore ha ottenuto la chiave o controlla l'unica copia della chiave, i dati di backup cifrati potrebbero risultare illeggibili anche quando i file esistono ancora.
Possono inoltre esserci conseguenze legali, contrattuali e reputazionali. Scadenze dei clienti non rispettate, registri finanziari persi, obblighi di segnalazione relativi alla privacy e costi di recupero d'emergenza possono derivare da una strategia di backup inefficace. Pagare un riscatto non garantisce la decifratura completa, la cancellazione dei dati rubati o un ambiente sicuro dopo il ripristino.
La risposta pratica consiste nel preservare ciò che resta, coinvolgere specialisti quando necessario, informare le parti interessate in base agli obblighi applicabili e ricostruire dal punto di ripristino integro controllato in modo indipendente più affidabile disponibile. Proprio per questo la separazione fuori sede, la conservazione immutabile, le procedure per le chiavi gestite dal cliente e i test di ripristino devono essere predisposti prima dell'attacco.
Checklist pre-incidente per la resilienza dei server al ransomware
Usa questa checklist come punto di partenza per una revisione trimestrale e dopo modifiche significative all'infrastruttura:
- Elenca ogni server aziendale, applicazione, database e insieme di dati critici controllato dall'organizzazione.
- Conferma che ogni server necessario sia incluso nell'ambito del backup.
- Mantieni almeno una copia significativa fuori sede, separata dall'ambiente di produzione.
- Utilizza una conservazione immutabile o bloccata per il periodo definito dal piano di ripristino.
- Conferma dove avviene la cifratura e chi controlla la chiave di decifratura.
- Conserva il materiale della chiave in modo sicuro, con responsabilità documentata e una procedura di accesso testata.
- Utilizza credenziali di backup separate e con privilegi minimi e proteggi l'accesso alla gestione con un'autenticazione forte.
- Controlla gli avvisi relativi a processi falliti, dati mancanti, cancellazioni insolite e modifiche alla conservazione.
- Testa il ripristino di file, applicazioni e server completi secondo una pianificazione definita.
- Registra gli obiettivi del punto di ripristino, gli obiettivi del tempo di ripristino e le dipendenze dei sistemi.
- Documenta l'ordine per isolare, analizzare e ripristinare i sistemi.
- Assicurati che almeno due persone autorizzate sappiano come avviare il processo di ripristino.
- Rivedi la conservazione dopo cambiamenti nella capacità di rilevamento, nel volume dei dati o nei requisiti aziendali.
I backup dovrebbero ridurre il potere di ricatto dell'aggressore, non diventare un altro sistema che può controllare. Per le aziende che gestiscono server sotto il proprio controllo, la combinazione di archiviazione fuori sede in Germania, cifratura eseguita prima del trasferimento, una chiave che Safenix non conserva mai e immutabilità per il periodo di conservazione scelto offre una base più solida per il recupero. Aggiungi a questa base l'accesso con privilegi minimi e test regolari di ripristino: il ransomware diventerà un incidente grave da gestire, non una richiesta che decide se l'azienda può continuare a operare.