Backup e ransomware: perché il NAS dello studio non basta

In molti studi il backup del gestionale e delle cartelle dei clienti finisce su un NAS nello stesso ufficio, montato come unità di rete sui PC e raggiungibile con un account amministrativo del dominio. Contro il ransomware è la configurazione più fragile: chi ottiene quei privilegi cifra prima le copie, poi i dati di produzione. Il backup esisteva, ma non serve.

Come un ransomware raggiunge il NAS dello studio

Le fasi sono ricorrenti. L’attaccante entra con una credenziale rubata o un accesso remoto esposto, cerca un account con diritti di amministratore, poi elimina le copie locali di Windows con comandi come vssadmin delete shadows /all /quiet e scorre le condivisioni di rete. Un NAS mappato come lettera di unità, o accessibile con le stesse credenziali del dominio, è una cartella come le altre. Se il pannello di gestione del NAS è raggiungibile dalla rete degli uffici con una password debole, l’attaccante può anche cancellare gli snapshot direttamente.

Tre requisiti per un backup immutabile

• Credenziali separate: il software di backup scrive con un account dedicato, esterno al dominio, e il NAS non è montato su nessun PC. Il pannello di amministrazione ha una password propria e, dove possibile, il secondo fattore.
• Immutabilità: snapshot non cancellabili prima della scadenza, oppure archiviazione a oggetti con Object Lock in modalità compliance, che a differenza della modalità governance non può essere aggirata nemmeno dall’amministratore dell’account. In alternativa, un repository Linux “hardened” che applica l’immutabilità a livello di file system.
• Una copia fuori sede, presso un fornitore diverso da quello che ospita i dati di produzione, con credenziali che non compaiono su nessun PC dello studio.

È la logica 3-2-1 aggiornata: tre copie, due supporti diversi, una fuori sede, di cui almeno una immutabile o scollegata. Il periodo di blocco va scelto in base a quanto tempo può passare prima di accorgersi della cifratura, perché un ransomware può restare silente per giorni prima di attivarsi.

Il test di ripristino che quasi nessuno fa

Un backup mai ripristinato è un’ipotesi. Comandi come RESTORE VERIFYONLY su SQL Server confermano che il file è leggibile, non che il gestionale riparte. Una volta a trimestre conviene ripristinare il database su una macchina isolata, avviare l’applicazione, aprire una pratica recente e cronometrare tutto. Quel tempo è il vero RTO: dice per quanti giorni lo studio resterebbe fermo sotto una scadenza fiscale. La data dell’ultimo backup valido è invece l’RPO, il lavoro che andrebbe rifatto.

Le vie d’ingresso che precedono la cifratura sono descritte nella nota sull’accesso remoto allo studio. Per un’analisi del vero costo del fermo operativo e per le prime decisioni dopo un attacco, la checklist delle prime 48 ore è un buon punto di partenza.