La resilienza informatica viene sempre più spesso valutata in base a ciò che accade dopo che gli aggressori sono riusciti a penetrare nei sistemi. Le organizzazioni hanno investito ingenti risorse nella prevenzione, nel rilevamento e nella risposta, ma il ransomware, lo sfruttamento delle vulnerabilità, l’uso improprio delle credenziali, le configurazioni errate del cloud e la compromissione di sistemi di terze parti continuano a causare interruzioni delle operazioni.

Per molti team, la sfida della Recovery non consiste più semplicemente nel verificare se esistono dei backup, ma piuttosto se tali backup sono integri, protetti, convalidati e pronti a ripristinare i servizi critici quando non è più possibile fare affidamento sui sistemi di produzione.

Questa distinzione è importante perché gli attacchi informatici continuano a generare sia rischi per i dati che interruzioni operative. Secondo il Verizon 2026 Data Breach Investigations Report, il ransomware è stato coinvolto nel 48% delle violazioni, in aumento rispetto al 44% dell’anno precedente. Il rapporto ha inoltre rilevato che lo sfruttamento delle vulnerabilità è diventato il vettore di accesso iniziale più comune per le violazioni, salendo al 31%, mentre l’abuso delle credenziali è sceso al 13%.

Le attività di Backup and Recovery nel cloud devono supportare l’intero percorso, dal rilevamento al ripristino. Ciò inizia con l’identificazione di attività sospette prima che i dati compromessi vengano ripristinati. Prosegue con punti di Recovery protetti e immutabili che offrono ai team opzioni di Recovery utilizzabili quando i sistemi di produzione non sono più affidabili.

A questo punto, le organizzazioni hanno bisogno di un modo per verificare quali punti di ripristino siano integri e per ripristinare i carichi di lavoro critici nell’ordine corretto. Il risultato è una strategia di Recovery che aiuta i team a passare dalla risposta agli incidenti al ripristino operativo con maggiore sicurezza.

Perché il Backup and Recovery su cloud costituiscono una strategia di resilienza informatica?

Le strategie di backup tradizionali sono state progettate per aiutare le organizzazioni a riprendersi da guasti hardware, cancellazioni accidentali e interruzioni localizzate. Questi casi d’uso sono ancora importanti, ma oggi i requisiti di Recovery sono più ampi.

Gli attacchi informatici possono colpire contemporaneamente i carichi di lavoro di produzione, i sistemi di gestione delle identità, le configurazioni cloud, le applicazioni SaaS e gli ambienti di backup. Quando ciò accade, il Recovery non consiste semplicemente nel ripristinare una copia dei dati. Si tratta piuttosto di determinare quali sistemi siano affidabili, quali punti di ripristino siano rimasti integri e quali servizi debbano essere ripristinati per primi.

Ecco perché il Backup and Recovery nel cloud sono diventati una parte fondamentale della resilienza informatica. Una strategia moderna dovrebbe aiutare i team a individuare attività sospette, proteggere i dati di ripristino, verificare l’integrità dei backup e ripristinare le operazioni critiche secondo una sequenza controllata. Dovrebbe inoltre favorire l’esecuzione di test regolari, poiché un piano di ripristino che non è stato messo in pratica potrebbe non funzionare come previsto durante un incidente reale.

Ciò segna il passaggio dal backup inteso come polizza assicurativa alla recuperabilità intesa come capacità operativa. Le copie archiviate sono ancora importanti, ma costituiscono solo una parte dell’equazione di Recovery. I team devono inoltre avere la certezza che i dati di Recovery non siano stati alterati, che i flussi di lavoro di Recovery siano stati testati e che l’azienda sappia quali servizi devono essere ripristinati per primi.

Il Backup and Recovery nel cloud diventa più facile da comprendere se considerato come un ciclo di vita. Le cinque fasi riportate di seguito mostrano come le organizzazioni possano passare dal rilevamento precoce delle minacce al Recovery convalidato e al miglioramento della resilienza a lungo termine.

Fase 1: Individuare le minacce prima che il rischio di Recovery si diffonda

Recovery inizia prima che i sistemi vengano riportati allo stato precedente. In caso di incidente informatico, la priorità assoluta è capire se l’attività sospetta abbia interessato i dati di produzione, i dati di backup o entrambi.

Se i team eseguono il ripristino da un punto di ripristino compromesso, potrebbero reintrodurre nell’ambiente file danneggiati, tracce di malware o modifiche non autorizzate. Questo rischio rende il rilevamento delle minacce una parte importante del Backup and Recovery nel cloud, non solo una questione che riguarda le operazioni di sicurezza.

Le moderne strategie di Recovery dovrebbero includere la visibilità sulle attività anomale nei carichi di lavoro, negli ambienti di backup e nei punti di Recovery. I team potrebbero dover indagare su segnali quali:

• Comportamento di crittografia insolito
• Picchi improvvisi di cancellazioni
• Modifiche impreviste dei privilegi
• Modelli di backup anomali
• Indicatori di malware

Questi segnali possono aiutare i team a capire dove un attacco potrebbe essersi diffuso e quali dati potrebbero richiedere un’ulteriore verifica prima del ripristino.

La tempistica è un altro fattore essenziale. Il Rapporto sulla difesa digitale 2025 di Microsoft ha rilevato che la maggior parte degli attacchi esaminati dal suo team di rilevamento e risposta (DART) presentava tempi di permanenza brevi, il che significa che i team di ripristino potrebbero non avere settimane a disposizione per comprendere la portata completa della compromissione prima che gli aggressori si spostino lateralmente, accedano a dati sensibili, interferiscano con i servizi o tentino di compromettere i sistemi di backup. Il contesto di rilevamento può aiutare i team a evitare di considerare ogni punto di ripristino ugualmente affidabile.

Il rilevamento delle minacce, di per sé, non elimina il rischio legato al Recovery. Contribuisce invece a rendere il processo di Recovery più consapevole. Quando un’attività sospetta viene individuata tempestivamente, le organizzazioni possono isolare i sistemi interessati, analizzare i dati compromessi ed evitare di ripristinare punti di ripristino che potrebbero reintrodurre la stessa minaccia.

Ciò offre ai team di sicurezza, IT e di Recovery un punto di partenza più chiaro per la fase successiva: proteggere i punti di ripristino integri prima che gli autori degli attacchi possano alterarli o rimuoverli.

Fase 2: Proteggere i punti di Recovery integri dagli attacchi

In caso di incidente informatico, i backup non sono semplici copie archiviate. Fanno parte del percorso di Recovery, il che significa che gli aggressori potrebbero tentare di comprometterli. Se i dati di backup vengono alterati, crittografati, eliminati o resi inaccessibili, l’organizzazione potrebbe perdere una delle sue migliori opzioni per ripristinare le operazioni senza dover fare affidamento su sistemi di produzione compromessi.

Ecco perché i punti di ripristino integri necessitano di una protezione a più livelli. Uno storage di backup immutabile e indelebile può aiutare a preservare i dati per un periodo di conservazione definito. Le copie fuori sede o isolate contribuiscono a garantire una separazione dall’ambiente di produzione. La crittografia, i controlli di accesso e le autorizzazioni basate sui ruoli aiutano a limitare chi può accedere o modificare le impostazioni di backup. Insieme, queste misure di sicurezza rendono più difficile per gli aggressori interferire con i dati di cui i team potrebbero avere maggiormente bisogno durante il ripristino.

L’obiettivo è preservare le opzioni di ripristino. Il rapporto Verizon del 2026 ha rilevato che il 69% delle vittime di ransomware nel proprio dataset non ha pagato il riscatto, in aumento rispetto al 65% dell’anno precedente. Il rapporto rileva inoltre che i pagamenti mediani del riscatto hanno continuato a diminuire, un fenomeno che attribuisce in parte al miglioramento delle misure difensive e alla maggiore resilienza delle vittime. I team hanno bisogno di backup integri che possano effettivamente utilizzare, in modo che il pagamento di un riscatto non sia l’unica via per tornare operativi.

La nota regola di backup 3-2-1 costituisce ancora una base utile: conservare tre copie dei dati, su due supporti o piattaforme diversi, con almeno una copia archiviata fuori sede o in un luogo isolato. Le moderne strategie di Backup and Recovery nel cloud spesso estendono tale modello con archiviazione immutabile, modelli air-gapped, conservazione basata su policy e copie replicate in ambienti cloud o ibridi.

Con punti di ripristino protetti a disposizione, i team possono restringere le opzioni di ripristino e passare alla fase di convalida con una visione più chiara di ciò che è pronto per essere ripristinato.

Fase 3: Verificare quali backup sono pronti per il ripristino

Disporre di backup non significa essere pronti per il ripristino. Prima di ripristinare i sistemi di produzione, i team devono sapere quali punti di ripristino sono utilizzabili, quali carichi di lavoro sono stati interessati e quali dipendenze devono essere ripristinate insieme a essi.

Un backup recente potrebbe contenere i dati aziendali più aggiornati, ma potrebbe anche includere file danneggiati, modifiche non autorizzate o tracce di malware. Un backup più vecchio potrebbe essere più pulito, ma potrebbe causare una maggiore perdita di dati. La verifica aiuta i team a trovare il giusto compromesso basandosi su prove concrete anziché su supposizioni.

Questo lavoro inizia con la definizione dell’ambito dell’incidente. I team di sicurezza e IT devono capire quando sono iniziate le attività sospette, quali sistemi sono stati coinvolti e se sono stati interessati servizi di identità, database, condivisioni di file, applicazioni SaaS o configurazioni cloud.

Devono inoltre confermare se il punto di Recovery supporti l’applicazione nel suo complesso, non solo i dati sottostanti. Il Recovery di un database, ad esempio, può dipendere dalla disponibilità e dal corretto funzionamento di server applicativi, autorizzazioni, chiavi di crittografia, percorsi di rete e servizi di identità.

Gli ambienti di Recovery isolati possono aiutare i team a verificare tali condizioni prima di eseguire il ripristino in produzione. In un ambiente controllato, i team possono in tutta sicurezza:

• Analizzare i punti di Recovery selezionati.
• Esaminare le modifiche ai file.
• Verificare l’avvio dell’applicazione.
• Verificare l’accesso degli utenti.
• Verificare se i sistemi dipendenti funzionano come previsto.

La convalida dovrebbe anche guidare la sequenza di Recovery. I team potrebbero dover ripristinare prima i servizi di identità, poi l’infrastruttura di base, quindi le applicazioni mission-critical e infine i carichi di lavoro di supporto.

Testando i punti di Recovery prima del ripristino, possono restringere le opzioni e decidere quali sistemi sono pronti per essere ripristinati, quali necessitano di un’ulteriore revisione e quali dovrebbero rimanere isolati fino a quando il rischio non sarà compreso meglio.

La fase successiva è quella in cui tale decisione si traduce in azione: il ripristino dei sistemi, delle applicazioni e dei dati di cui l’azienda ha bisogno per primi.

Fase 4: Ripristinare le operazioni critiche nell’ordine corretto

Un piano di ripristino parte dallo stato operativo minimo necessario dell’organizzazione. Ciò significa identificare le persone, i sistemi, le applicazioni, i dati e i canali di comunicazione di cui l’azienda ha bisogno per funzionare a un livello di base durante un’interruzione.

Per alcune organizzazioni, ciò potrebbe iniziare con i servizi di identità e le comunicazioni con i dipendenti. Per altre, potrebbe dare priorità alle applicazioni rivolte ai clienti, ai sistemi di pagamento, ai sistemi clinici, alle operazioni di produzione o alle piattaforme logistiche. L’ordine dovrebbe riflettere l’impatto sul business, non solo la convenienza tecnica.

Le dipendenze sono il punto in cui molti piani di ripristino diventano più complessi. Un’applicazione può essere classificata come “critica”, ma dipende comunque dall’identità, dal DNS, dalla connettività di rete, dai database, dallo storage, dalle chiavi di crittografia, dalle API e dal monitoraggio. Se questi elementi non vengono ripristinati correttamente, l’applicazione potrebbe tornare online ma rimanere inutilizzabile. Ecco perché i team di Recovery hanno bisogno di una mappatura delle dipendenze prima di un incidente, non durante.

I runbook e i flussi di lavoro orchestrati aiutano a trasformare tali decisioni in passaggi ripetibili. Consentono di definire chi approva il ripristino, quale ambiente debba essere utilizzato, quali controlli debbano essere effettuati prima che venga ripristinato l’accesso all’ambiente di produzione e quando il livello successivo di sistemi possa tornare online. Ciò è importante quando i team di sicurezza, infrastruttura, applicazioni, cloud e aziendali lavorano tutti contemporaneamente.

Anche il Recovery richiede punti di controllo. Dopo il Recovery di ogni carico di lavoro principale, i team dovrebbero verificare che gli utenti possano autenticarsi, che i dati siano disponibili, che le integrazioni funzionino e che il monitoraggio sia attivo. Questi controlli aiutano a individuare i problemi prima che il Recovery si estenda al livello successivo di sistemi.

La velocità è ancora importante, ma lo è altrettanto il controllo. Un ripristino rapido può generare più lavoro se vengono ripristinati dati errati, se mancano i controlli di accesso o se un’applicazione viene ripristinata senza i sistemi necessari per il suo funzionamento. L’approccio più efficace consiste nel ripristinare per fasi, verificare che ogni servizio critico funzioni e poi continuare ad espandere Recovery man mano che l’ambiente si stabilizza.

Fase 5: Trasformare gli insegnamenti tratti dal Recovery in una continuità operativa più solida

Una volta ripristinati i servizi critici, i team devono comunque capire cosa ha funzionato, cosa li ha rallentati e in quali punti il piano di Recovery non ha tenuto conto della realtà. È proprio questo follow-up che trasforma il Backup and Recovery nel cloud da un’attività di risposta a una pratica di resilienza continua.

Il primo passo consiste nell’analizzare il processo di Recovery stesso. I team dovrebbero porsi domande quali:

• Con quale rapidità i team hanno individuato attività sospette?
• È stato facile identificare i punti di Recovery validi?
• Quali fasi di convalida hanno richiesto più tempo del previsto?
• In quali punti i flussi di lavoro di ripristino hanno subito rallentamenti?
• Sono state coinvolte le persone giuste al momento giusto?

Queste risposte possono rivelare lacune che non sono sempre di natura tecnica. La Recovery può avere esito positivo e tuttavia evidenziare problemi relativi al processo decisionale, alla comunicazione, alle approvazioni o ai passaggi di consegne tra i team.

Tali risultati dovrebbero confluire direttamente nella prossima versione del piano di Recovery. Se un’applicazione critica dipendeva da un sistema non documentato, aggiornare la mappa delle dipendenze. Se i controlli di accesso hanno rallentato il ripristino, chiarire il processo di approvazione. Se i test di Recovery hanno tralasciato un carico di lavoro chiave, aggiungerlo alla prossima esercitazione. Se i dirigenti aziendali non avevano visibilità su ciò che era stato ripristinato e su ciò che era ancora offline, migliorare i canali di segnalazione e di escalation.

I test regolari sono ciò che garantisce la solidità di questo lavoro. Esercitazioni teoriche, ripristini isolati, test di Recovery in ambiente pulito e la convalida della Recovery cross-cloud aiutano i team a individuare i problemi prima che un incidente reale li costringa ad apprendere sotto pressione. Contribuiscono inoltre a fornire ai dirigenti prove più concrete di dove l’organizzazione è pronta e dove deve ancora lavorare.

Nel tempo, l’obiettivo è un programma di Recovery che diventi più efficace dopo ogni test e ogni incidente. I team sono meglio preparati, le fasi di Recovery sono comprese più a fondo e l’organizzazione dispone di un percorso più chiaro per mantenere operative le attività essenziali anche in caso di interruzioni.

Trasformare il Recovery dal cloud in resilienza aziendale

 Il Backup and Recovery nel cloud svolge oggi un ruolo più ampio rispetto alla semplice protezione tradizionale dei dati. Si tratta di un processo integrato che comprende l’individuazione dei rischi di Recovery, la protezione dei dati di backup, la verifica delle opzioni di Recovery corrette e il ripristino dei servizi critici quando gli ambienti di produzione non sono più affidabili.

In caso di incidente informatico, tali attività non possono essere gestite come fasi separate. Il contesto della minaccia dovrebbe determinare quali backup devono essere esaminati. La protezione dei backup dovrebbe preservare le opzioni di Recovery di cui i team potrebbero aver bisogno. La verifica dovrebbe stabilire cosa è pronto per il ripristino. Il ripristino dovrebbe ripristinare i servizi da cui dipende l’azienda in un ordine controllato.

Un backup inaffidabile, non testato o che non può essere ripristinato al momento giusto potrebbe non fornire all’azienda il risultato di cui ha bisogno. Un processo di ripristino che ignori l’identità, le dipendenze delle applicazioni o le priorità aziendali può lasciare i sistemi tecnicamente ripristinati ma operativamente incompleti.

L’approccio più ampio consiste nel considerare il Recovery come una pratica di resilienza continua. Ciò significa testare i piani prima che si verifichi un incidente, aggiornare le mappe delle dipendenze man mano che gli ambienti cambiano e utilizzare ogni esercitazione o evento di Recovery per migliorare la risposta successiva.

Le organizzazioni che si riprendono più rapidamente non sono necessariamente quelle con il maggior numero di copie dei dati. È fondamentale sapere quali dati sono utilizzabili, quali servizi sono più importanti e come ripristinarli in situazioni di emergenza.

La sfida consiste nel rendere la Readiness per il ripristino operativa quanto il rilevamento e la risposta. Il Backup and Recovery nel cloud forniscono una base pratica per questo lavoro quando vengono considerati come un percorso continuo che va dal rilevamento del rischio al ripristino delle attività aziendali.

Le organizzazioni dovrebbero sviluppare questa capacità per essere meglio preparate a ripristinare dati integri, recuperare i servizi critici e mantenere l’attività operativa in caso di interruzioni.