Quando un sistema chiave all’interno della tua azienda smette di funzionare, la parte più difficile è sapere cosa ripristinare per primo, chi ha l’accesso per farlo, quale backup sia attendibile e per quanto tempo la tua azienda può continuare a lavorare senza quel sistema.
È proprio qui che molte piccole e medie imprese (PMI) scoprono il divario tra avere dei backup e disporre di un vero e proprio piano di ripristino. Un backup può contenere i dati di cui hai bisogno, ma non decide l’ordine di ripristino, non assegna le responsabilità, non verifica se il ripristino funziona e non risolve il problema delle credenziali di amministratore mancanti durante un’interruzione.
Un piano di disaster recovery IT fornisce una struttura a questo processo prima che si verifichi un’interruzione. Definisce quali sistemi sono più importanti, con quale rapidità devono essere ripristinati, quanta perdita di dati l’azienda può tollerare, quali strategie di prevenzione della perdita di dati implementare, chi è responsabile di ciascuna fase di ripristino e come vengono protette le credenziali critiche. Questa chiarezza può evitare che un incidente informatico si trasformi in un periodo di inattività prolungato, in perdite di entrate o in una crisi operativa più ampia.
Cos’è un piano di disaster recovery IT?
Business continuity vs disaster recovery IT
Cosa deve coprire il tuo piano di disaster recovery IT
Cosa deve definire il tuo piano di disaster recovery IT
Recupero delle credenziali: lo scenario di disaster recovery trascurato
Modello di piano di disaster recovery
Come testare il tuo piano di disaster recovery IT
Costruire il ripristino attorno a sistemi, dati e accessi
Cos’è un piano di disaster recovery IT?
Un piano di disaster recovery IT è un processo documentato per il ripristino dei sistemi tecnologici dopo un’interruzione. Si concentra sul livello IT dell’azienda: dati, applicazioni, dispositivi, infrastrutture, servizi cloud, accessi amministratore, backup e le persone responsabili del ripristino.
Un piano di ripristino IT pratico dovrebbe rispondere a domande come:
- Quali sistemi devono essere ripristinati per primi?
- Quanti tempi di inattività può tollerare l’azienda?
- Quanta perdita di dati è accettabile?
- Dove sono archiviati i backup?
- Chi può ripristinare i sistemi?
- Quali credenziali di amministratore sono necessarie?
- In che modo il team confermerà che i sistemi ripristinati siano sicuri e utilizzabili?
- In che modo l’azienda comunicherà con il personale e i clienti se i canali principali sono offline?
Un piano di disaster recovery dovrebbe andare oltre la gestione degli attacchi informatici: deve coprire i problemi quotidiani come guasti hardware, credenziali smarrite ed eliminazioni accidentali. Deve inoltre coprire le interruzioni dei servizi esterni, come i disservizi delle piattaforme cloud o degli strumenti SaaS, le configurazioni errate e l’abbandono di dipendenti chiave senza il trasferimento dei permessi di accesso critici.
Il ripristino non è qualcosa da progettare durante un’interruzione. Deve essere pianificato, assegnato a un responsabile, comunicato e testato prima che la tua azienda debba farvi affidamento.
Business continuity vs disaster recovery IT
La business continuity e il disaster recovery IT vengono spesso trattati come la stessa cosa, ma risolvono problemi diversi.
La business continuity consiste nel mantenere l’azienda operativa durante un’interruzione. Copre la comunicazione con i clienti, i flussi di lavoro temporanei, le responsabilità del personale, il coordinamento con i fornitori e le decisioni su quali servizi devono continuare anche se i sistemi normali non sono disponibili.
Il disaster recovery IT si concentra sulla tecnologia alla base di quel lavoro. Definisce il modo in cui sistemi, dati, applicazioni, backup e accessi amministratore verranno ripristinati affinché l’azienda possa tornare in sicurezza alle normali attività.
Ad esempio, considera un’interruzione del CRM. Un piano di business continuity può spiegare come i team di vendita o di supporto continuano a servire i clienti mentre il CRM è offline. Il piano di ripristino IT spiega chi contatta il fornitore, quali dati devono essere ripristinati, quale backup o esportazione è disponibile, quali credenziali sono necessarie e in che modo il team conferma che il sistema è sicuro da usare di nuovo.
Per molte PMI, il divario si manifesta solo durante un incidente. Le persone sanno chi contatterebbe i clienti, ma non chi può ripristinare il sistema di fatturazione. Sanno che esistono i backup, ma non se sia mai stato testato un ripristino. Sanno che di solito un dipendente gestisce l’IT, ma non cosa succede se quella persona non è disponibile o dove sono archiviate le password di amministratore se quella persona non è rintracciabile.
Cosa deve coprire il tuo piano di disaster recovery IT
Un piano di disaster recovery IT efficace non deve essere eccessivamente lungo, ma deve essere sufficientemente specifico da poter essere eseguito durante una situazione di stress.
Recovery Time Objective
Il Recovery Time Objective, o RTO, definisce la rapidità con cui un sistema deve essere ripristinato. Un sistema di pagamento potrebbe dover essere ripristinato entro poche ore, mentre un pannello di controllo per la reportistica interna può tollerare un’interruzione più lunga.
Stabilisci gli RTO in base all’impatto aziendale, non in base alle preferenze tecniche, perché il costo dei tempi di inattività è un problema sia aziendale che tecnico. Chiediti quali sistemi influiscono sulle entrate, sugli impegni con i clienti, sugli obblighi legali, sulla sicurezza e sulla produttività dei dipendenti.
Recovery Point Objective
Il Recovery Point Objective, o RPO, definisce quanta perdita di dati è accettabile, il che aiuta a stabilire le giuste strategie di prevenzione della perdita di dati (DLP). Se un sistema ha un RPO di un’ora, i backup o la replica devono supportare il ripristino fino a circa quel punto.
Se l’RPO è di un giorno, l’azienda accetta un divario maggiore. L’RPO aiuta anche a determinare la frequenza dei backup, perché più breve è l’RPO, più frequenti devono essere i backup. I sistemi critici necessitano quindi di backup più frequenti rispetto ai sistemi a bassa priorità.
Livelli di priorità del sistema
Non tutti i sistemi devono essere ripristinati contemporaneamente. Un piano di disaster recovery per una piccola impresa dovrebbe dividere i sistemi in livelli di priorità.
- Livello 1: sistemi richiesti per le operazioni principali, la sicurezza, le comunicazioni o le entrate.
- Livello 2: sistemi importanti che possono tollerare brevi tempi di inattività.
- Livello 3: sistemi a priorità inferiore che possono essere ripristinati una volta che l’azienda è stabile.
I tipici sistemi di livello 1 possono includere email, provider di identità, gestore di password, sistemi finanziari, database dei clienti, archiviazione cloud e piattaforme di comunicazione.
Strategia di backup
La tua strategia di backup dovrebbe definire:
- Di cosa viene eseguito il backup e con quale frequenza
- Dove sono archiviati i backup
- Chi può accedervi
- Come viene testato il ripristino
L’NCSC ha inoltre pubblicato(nuova finestra) i principi per i backup resistenti ai ransomware per le soluzioni di backup cloud e on-premise, sottolineando che, per impostazione predefinita, i dati sottoposti a backup non sono resistenti ai ransomware e devono essere valutati rispetto a questa minaccia.
Una solida strategia di backup di solito include backup offline o immutabili per i dati critici, test regolari, passaggi di ripristino documentati e credenziali separate per l’amministrazione del backup.
Ruoli e responsabilità
Un piano di disaster recovery dovrebbe indicare i responsabili, non solo i compiti. Se una sola persona detiene tutta la conoscenza del ripristino, l’azienda corre un rischio legato al personale oltre a un rischio IT. Definisci chi:
- Guida il ripristino
- Ripristina i sistemi
- Contatta i fornitori
- Approva l’accesso di emergenza
- Comunica internamente
- Documenta le decisioni
Cosa deve definire il tuo piano di disaster recovery IT
| Componente | A cosa risponde |
| RTO | Con quale rapidità deve essere ripristinato ciascun sistema? |
| RPO | Quanti dati può permettersi di perdere l’azienda? |
| Livelli di priorità | Quali sistemi devono essere ripristinati per primi e quali possono attendere? |
| Strategia di backup | Di cosa viene eseguito il backup, dove è archiviato e se il ripristino è stato testato? |
| Ruoli e responsabilità | Chi guida il ripristino, ripristina i sistemi, contatta i fornitori e approva le modifiche di emergenza? |
Recupero delle credenziali: lo scenario di disaster recovery trascurato
Il disaster recovery spesso si concentra su dati, server e backup. Ma nella pratica, il ripristino può fallire perché il team non può accedere ai sistemi necessari per ripristinare le operazioni.
Il recupero delle credenziali si chiede:
- Chi ha accesso agli account di amministratore?
- Dove sono archiviate le credenziali di backup?
- Quali account possono ripristinare i sistemi critici?
- Cosa succede se una password viene persa, compromessa o è in possesso di qualcuno non disponibile?
- Le credenziali di emergenza sono protette e verificate?
- L’accesso può essere revocato e riassegnato rapidamente?
Se le credenziali di backup sono archiviate nel browser di un dipendente, i codici di recupero sono conservati in una nota privata o le password di amministratore condivise circolano in chat, l’azienda potrebbe non essere in grado di effettuare un ripristino pulito durante un incidente.
Un gestore di password aziendale aiuta a ridurre questo rischio centralizzando le credenziali critiche in cassefori crittografate, assegnando l’accesso in base al ruolo e semplificando la revoca o la riassegnazione dell’accesso quando qualcuno lascia l’azienda o cambiano le responsabilità. Proton Pass for Business aiuta i team a generare password efficaci, archiviare le credenziali in modo sicuro, utilizzare la condivisione sicura e tenere gli accessi sensibili fuori da chat e fogli di calcolo.
Come gestore di password per i team IT, Proton Pass supporta la gestione centralizzata delle credenziali, le policy sulle password, la condivisione sicura, report e log, il provisioning SCIM e le integrazioni SSO. Questo rende il recupero delle credenziali più gestibile perché l’accesso ai sistemi critici non dipende da una sola persona, da un unico profilo del browser o da una password non documentata.
Modello di piano di disaster recovery
Un piano di disaster recovery funziona al meglio quando è abbastanza specifico da guidare l’azione durante un’interruzione, ma abbastanza semplice da essere utilizzato dal team sotto pressione. Per le PMI, il modello dovrebbe concentrarsi sugli elementi essenziali: cosa deve essere ripristinato, con quale rapidità, da quale backup, da chi e con quali credenziali.
1. Scopo
Definisci quali sistemi, servizi, posizioni, dispositivi e dati sono coperti dal piano.
Copia del modello: Questo piano di disaster recovery IT copre i sistemi, i dati, i servizi, le credenziali e i fornitori necessari per ripristinare le operazioni critiche di [Company Name] dopo un’interruzione tecnologica.
2. Inventario dei sistemi critici
Elenca i sistemi su cui fa affidamento la tua azienda e assegna i livelli di priorità.
Copia del modello: I sistemi critici saranno raggruppati in Livello 1, Livello 2 e Livello 3 in base all’impatto aziendale, al recovery time objective, al recovery point objective e alla dipendenza da altri sistemi.
3. Obiettivi di ripristino
Definisci RTO e RPO per ciascun sistema prioritario.
Copia del modello: Ciascun sistema deve avere un recovery time objective e un recovery point objective documentati. Questi obiettivi devono essere rivisti almeno una volta all’anno e dopo importanti modifiche al sistema.
4. Processo di backup e ripristino
Documenta dove sono archiviati i backup, con quale frequenza vengono eseguiti, chi può accedervi e come funzionano i test di ripristino.
Copia del modello: I backup devono essere protetti da accessi non autorizzati, archiviati separatamente dai sistemi principali laddove appropriato e testati regolarmente. Le procedure di ripristino devono essere documentate per i sistemi di Livello 1.
5. Recupero delle credenziali e degli accessi
Definisci dove sono archiviate le credenziali critiche e chi può accedervi durante il ripristino.
Copia del modello: Le credenziali di amministratore, le credenziali di backup, i codici di recupero e l’accesso ai fornitori necessari per il disaster recovery devono essere archiviati in una cassaforte crittografata approvata. L’accesso deve essere limitato ai ruoli autorizzati e verificato dopo modifiche di ruolo, offboarding ed esercitazioni di ripristino.
6. Ruoli ed escalation
Definisci i responsabili del ripristino, i sostituti e i percorsi di escalation.
Copia del modello: Ogni ruolo di ripristino deve avere un responsabile principale e un responsabile di backup. Il piano deve identificare chi guida il ripristino, chi ripristina i sistemi, chi contatta i fornitori, chi comunica gli aggiornamenti e chi approva le modifiche di emergenza.
7. Piano di comunicazione
Definisci in che modo l’azienda comunica internamente ed esternamente durante un’interruzione dell’IT.
Copia del modello: Durante un evento di ripristino, gli aggiornamenti interni verranno condivisi tramite [canale approvato]. Le comunicazioni esterne a clienti, fornitori, assicuratori o autorità di regolamentazione devono essere approvate da [ruolo/team].
8. Frequenza di test e revisione
Definisci la frequenza con cui il piano viene testato e aggiornato.
Copia del modello: Questo piano di disaster recovery verrà testato almeno [annualmente/due volte all’anno] e rivisto dopo incidenti importanti, modifiche al sistema, cambi di fornitore o esercitazioni di ripristino fallite.
Come testare il tuo piano di disaster recovery IT
Un piano di disaster recovery diventa utile solo quando è stato testato in condizioni simili a un’interruzione reale. Un backup esistente ma mai ripristinato rimane solo un’ipotesi. Un ruolo di ripristino noto a una sola persona rimane una dipendenza. Una credenziale di amministratore che nessuno riesce a trovare durante un’interruzione rimane un blocco.
All’inizio i test non devono essere complessi. Per la maggior parte delle PMI, l’obiettivo è dimostrare che l’azienda è in grado di ripristinare i sistemi corretti, con le persone giuste, utilizzando le credenziali corrette, entro un lasso di tempo realistico.
1. Esercitazione teorica
Scegli uno scenario probabile, come un ransomware che colpisce i file condivisi, un’interruzione dell’archiviazione cloud, l’eliminazione accidentale dei dati dei clienti o la perdita improvvisa dell’accesso a un account di amministratore. Analizza cosa farebbe il team nella prima ora, chi guiderebbe le operazioni, quali fornitori verrebbero contattati, a quali sistemi verrebbe data priorità e quali informazioni mancherebbero.
2. Test di ripristino
Seleziona un File critico, un database, una casella email o un’esportazione di sistema e conferma che possa essere ripristinato in uno stato utilizzabile. Verifica se i dati ripristinati sono abbastanza recenti, se i permessi funzionano ancora e se il team sa dove si trova il backup.
3. Test regolari
Come base pratica, le PMI dovrebbero testare il piano almeno una volta all’anno, in linea con le linee guida NIST nella Special Publication 800-34 Revisione 1(nuova finestra), e più spesso dopo importanti modifiche ai sistemi o ai fornitori.
4. Test di recupero delle credenziali
Conferma che le persone autorizzate possano accedere agli account amministratore di backup, agli account amministratore cloud, ai portali dei fornitori, ai codici di recupero e alle credenziali di emergenza senza fare affidamento sul browser di un dipendente, su note private o sulla memoria. L’obiettivo non è esporre inutilmente password sensibili, ma confermare che il modello di accesso funzioni ancora quando l’azienda è sotto pressione.
Dopo ogni test, documenta cosa è fallito, cosa ha richiesto troppo tempo e assegna un responsabile specifico e una scadenza per ogni correzione. Un buon test non è quello in cui tutto va alla perfezione, ma quello che rivela i punti deboli mentre l’azienda ha ancora il tempo di risolverli.
Costruire il ripristino attorno a sistemi, dati e accessi
Un piano di disaster recovery IT utile fornisce all’azienda un ordine di ripristino, un insieme di responsabili, una visione realistica dei tempi di inattività accettabili e un modo per mantenere la business continuity e riottenere l’accesso ai sistemi che mantengono il lavoro in movimento.
Per le PMI, questo potrebbe fare la differenza tra una breve interruzione e un blocco prolungato. Se l’email, il software finanziario, l’archiviazione cloud, i sistemi dei clienti o gli account amministratore non sono disponibili, il team deve sapere cosa viene prima, chi può agire e quali credenziali sono necessarie per ripristinare l’accesso in sicurezza.
Ecco perché la pianificazione del ripristino dovrebbe coprire contemporaneamente sistemi, dati e accessi. I backup possono ripristinare i File, ma le credenziali sono ciò che consente al team di riprendere il controllo dei sistemi necessari per il ripristino. Login di amministratore, portali dei fornitori, account di backup, codici di recupero e credenziali operative condivise devono essere tutti protetti, organizzati e disponibili per le persone giuste quando qualcosa va storto.
Un gestore di password aziendale aiuta a rafforzare questa parte del piano. Con le credenziali critiche archiviate in cassefori di password crittografate e condivise solo con persone autorizzate, l’azienda dipende meno dal browser di un singolo dipendente, da note private o dalla memoria durante un evento di ripristino.
