Un job di backup riuscito dimostra che un’attività è terminata secondo i suoi controlli. Non dimostra che il servizio possa essere ricostruito dopo un incidente. La prova deve includere dati, configurazione, identità, dipendenze e tempi di riattivazione.
Obiettivo, pubblico e prerequisiti: produrre evidenze che un servizio possa essere ripristinato, non soltanto che il backup sia terminato. È rivolto a operatori IT e incident responder con copie autorizzate, ambiente isolato, criteri RPO/RTO e piano di pulizia.
Uso autorizzato: esegui il test su copie e ambienti assegnati, senza collegarli alla produzione. Non riattivare automaticamente account, job o integrazioni e non usare campioni di ransomware per validare il recupero.
Progettare contro il guasto comune
La guida StopRansomware di CISA raccomanda copie offline e cifrate dei dati critici e verifiche periodiche di disponibilità e integrità. Le copie accessibili da sistemi compromessi possono essere colpite. La guida invita anche a mantenere immagini e materiali utili alla ricostruzione.
Come valutazione operativa, chiedere quali credenziali possano leggere, modificare o eliminare le copie. Separare il controllo del backup dal workload riduce un possibile guasto comune, ma il risultato dipende dai permessi reali e dalle procedure di recupero. La sola presenza di un secondo account non garantisce isolamento.
RPO e RTO sul servizio
Il glossario NIST definisce RPO come il punto nel tempo cui i dati devono essere recuperati dopo un’interruzione. RTO descrive il tempo obiettivo per il recupero. Sono obiettivi da concordare con il servizio, non etichette del software di backup.
In uno scenario sintetico, un backup giornaliero può non soddisfare un requisito di perdita massima di un’ora. Il tempo per scaricare una copia non coincide necessariamente con quello per riattivare l’applicazione: database, code, DNS, certificati e identità possono ritardare il servizio. Misurare l’intero percorso.
Evidenze riproducibili: un esercizio di recupero isolato
- Definire servizio, punto di ripristino e criteri di successo prima della prova.
- Preparare un ambiente separato che non invii email, job o traffico verso sistemi di produzione.
- Recuperare copie, configurazione e chiavi attraverso il percorso autorizzato.
- Avviare le dipendenze nell’ordine documentato e verificare consistenza dei dati.
- Eseguire transazioni sintetiche e registrare tempi, errori e interventi manuali.
Per un database, verificare che la copia sia coerente con il metodo di backup e recupero adottato. Un insieme di file copiati durante scritture attive non è automaticamente un backup applicativamente consistente. La procedura deve richiamare le istruzioni del database effettivamente usato.
Immutabilità e cifratura non risolvono tutto
CISA contempla storage immutabile e protezioni di eliminazione, richiedendo attenzione alla configurazione. La cifratura protegge la riservatezza della copia, ma una chiave indisponibile impedisce il recupero. La retention blocca certe cancellazioni soltanto nei limiti del servizio e della policy applicata: testare i ruoli autorizzati e i percorsi di gestione.
Valutare anche le conseguenze di copie troppo brevi o troppo lunghe. Un punto recente può contenere una compromissione non ancora scoperta; una copia molto vecchia può non soddisfare il recupero richiesto. Definire una finestra con criteri espliciti, costo e requisiti di conservazione.
Mitigazioni: ripristinare senza reintrodurre il problema
La guida CISA invita a evitare di reinfettare sistemi puliti durante il recovery. Integrare il ripristino con l’indagine: determinare il punto plausibilmente affidabile, ricostruire componenti quando necessario e trattare le credenziali compromesse. Non riaprire automaticamente tutte le comunicazioni soltanto perché l’applicazione risponde.
Chiudere l’esercizio con RPO e RTO osservati, dipendenze mancanti e responsabilità dei correttivi. Una prova parziale deve dichiarare il proprio perimetro. Il prossimo esercizio dovrebbe verificare i punti falliti, evitando di ripetere soltanto il recupero che era già riuscito.
Fonti essenziali
Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.
AUTORE
Redazione ThreatHunting.it
Da piu' di 30 anni sono appassionato di computers e tecnologia. il mio primo programma lo sviluppai in Basic nel 1989, non era un gran che :).. ma quella voglia di scrivere codici non mi ha piu' lasciato …
COMMUNITY
Non ci sono ancora commenti. Puoi iniziare tu la conversazione.