Quando il sistema si ferma, il cittadino aspetta

Immaginate un Comune dove, improvvisamente, l'anagrafe smette di funzionare. O un ente regionale che perde l'accesso ai database sanitari per ore, o peggio, giorni. Non è uno scenario da film, ma una realtà a cui ogni amministratore pubblico deve fare i conti.

Il disaster recovery nella pubblica amministrazione non riguarda solo la tecnologia. Riguarda la continuità del servizio pubblico.

Troppo spesso si confonde il backup con il disaster recovery. Errore grave. Il backup è una copia dei dati; il disaster recovery è l'intero piano d'azione per rimettere in piedi l'infrastruttura quando tutto sembra perduto. C'è una differenza abissale tra avere i dati salvati e poterli effettivamente usare in tempi rapidi.

Proprio così.

La trappola della "falsa sicurezza"

Molte amministrazioni pensano di essere al sicuro perché effettuano backup giornalieri su server locali. Ma cosa succede se l'incendio, l'allagamento o un attacco ransomware colpiscono proprio quel data center? I dati sono lì, ma sono inaccessibili o compromessi.

La resilienza richiede una strategia distribuita. Non basta "copiare i file". Serve un'architettura che preveda siti di replica, possibilmente geograficamente distanti, per evitare che un singolo evento catastrofico cancelli sia l'originale che la copia.

Un dettaglio non da poco: il tempo.

In ambito PA, ogni minuto di downtime si traduce in code agli sportelli, pratiche bloccate e un danno d'immagine immenso. Qui entrano in gioco due concetti tecnici che però hanno risvolti politici e sociali enormi: l'RPO e l'RTO.

  • RPO (Recovery Point Objective): quanta perdita di dati possiamo tollerare? Se l'ultimo backup è di 24 ore fa, perderemo tutto il lavoro di un intero giorno. Accettabile? Difficilmente.
  • RTO (Recovery Time Objective): quanto tempo può stare fermo il servizio prima che diventi critico? Dieci minuti? Quattro ore? Due giorni?

Definire questi parametri non è un compito per l'informatico, ma per chi gestisce l'ente. È una scelta di priorità.

Ransomware: il nemico numero uno della PA

Gli attacchi informatici non sono più eventi rari. La Pubblica Amministrazione è un bersaglio appetibile perché gestisce moli di dati sensibili e, spesso, ha difese obsolete.

Il ransomware non si limita a criptare i file. I moderni malware cercano attivamente i backup per distruggerli prima di bloccare il sistema principale. Se il tuo piano di disaster recovery prevede un backup collegato permanentemente alla rete senza alcuna segregazione, sei vulnerabile.

La soluzione? L'immutabilità dei dati. I dati devono essere scritti in un formato che non può essere modificato o cancellato per un periodo prestabilito.

Questo crea un "rifugio sicuro" da cui ripartire, indipendentemente dalla gravità dell'attacco.

Strategie concrete per una PA resiliente

Non esiste una soluzione unica, ma ci sono pilastri fondamentali su cui costruire la strategia di disaster recovery pubblica amministrazione.

Innanzitutto, l'analisi del rischio. Non tutti i servizi hanno la stessa importanza. Il portale delle news del Comune può attendere qualche ora per il ripristino; il sistema di gestione delle emergenze o i pagamenti tributari no. Classificare le applicazioni in base alla criticità permette di ottimizzare le risorse, investendo dove il rischio è più alto.

Poi, la scelta dell'infrastruttura. Il cloud ibrido sta diventando lo standard. Mantenere alcuni dati on-premise per velocità e controllo, ma replicare tutto su un cloud certificato (magari in linea con le direttive AgID), garantisce che il servizio non dipenda da un unico punto di guasto fisico.

Ma la tecnologia è solo metà dell'opera.

Il fattore umano: il piano che nessuno legge

Ho visto troppi documenti di Disaster Recovery bellissimi, formattati perfettamente in PDF, ma che nessuno ha mai aperto. In caso di crisi, non c'è tempo per leggere un manuale di cento pagine.

Serve un Playbook. Un documento sintetico, quasi una checklist, che dica esattamente chi deve fare cosa, in quale ordine e come contattare i responsabili.

  • Chi dichiara lo stato di emergenza?
  • Chi attiva il sito di disaster recovery?
  • Come viene comunicato il disservizio ai cittadini per evitare il caos agli sportelli?

Senza un processo testato, il piano è solo carta. E la carta non ripristina i database.

Testare per non fallire

Un sistema di disaster recovery che non viene testato è un sistema che non funziona. Punto.

Molte PA temono di fare test di ripristino perché "potrebbero destabilizzare il sistema". È un ragionamento pericoloso. È preferibile scoprire un errore di configurazione durante una simulazione programmata che durante un vero attacco ransomware alle tre del mattino di un lunedì.

I test devono essere regolari e progressivi: dal semplice ripristino di un singolo file, al failover completo dell'intera infrastruttura su un sito secondario. Solo così si può avere la certezza che l'RTO dichiarato sia reale e non una stima ottimistica.

Conformità normativa e sicurezza

Operare nella PA significa muoversi in un quadro normativo rigido. GDPR, linee guida AgID, direttive europee sulla cybersecurity (come la NIS2). Il disaster recovery non è solo una buona pratica tecnica, è un obbligo di legge per chi gestisce dati sensibili dei cittadini.

La perdita definitiva di dati pubblici può portare a sanzioni pesanti e, soprattutto, a responsabilità legali per i dirigenti.

Implementare una strategia di disaster recovery significa quindi proteggere l'ente, ma anche proteggere chi lo guida. La sicurezza informatica non è un costo, è un investimento sull'affidabilità dell'istituzione stessa.

In fondo, la fiducia del cittadino nello Stato passa anche attraverso la capacità dello Stato di non perdere i suoi documenti e di garantire servizi che funzionano sempre, qualunque cosa accada.