Un guasto improvviso dei sistemi informatici, un attacco ransomware che blocca gli accessi, un sovraccarico che blocca il portale cittadino: nel 2025, per le Pubbliche Amministrazioni italiane, un incidente informatico non è più un’ipotesi remota, ma un rischio operativo quotidiano. Le conseguenze vanno oltre il semplice disservizio tecnico: si traducono in interruzioni dei servizi ai cittadini, sanzioni normative, danni reputazionali e costi di ripristino che possono compromettere l’intero bilancio annuale. In questo scenario, la Disaster Recovery (DR) non è più un optional riservato ai grandi enti, ma un requisito fondamentale per garantire la continuità operativa (Business Continuity) e il rispetto dei livelli di servizio promessi.

La complessità della normativa (NIS2, GDPR, Codice dell’Amministrazione Digitale) e l’evoluzione delle minacce informatiche richiedono un approccio strutturato e proattivo. Non basta più disporre di un backup: è necessario avere un piano testato, tempi di ripristino definiti (RTO/RPO) e una governance chiara che sappia gestire la crisi in modo coordinato.

In questa guida completa, ti spieghiamo passo dopo passo come progettare ed implementare una strategia di Disaster Recovery efficace per la tua PA, dalla valutazione dei rischi al ripristino dei servizi critici, per garantire che la tua amministrazione rimanga operativa anche di fronte all’imprevisto.

Per approfondire come Culture Digitali Srl può supportare la tua PA nella definizione e nell’implementazione del piano di Disaster Recovery, contattaci per una consulenza dedicata.

Introduzione: L’imperativo della Resilienza nella Pubblica Amministrazione

La resilienza operativa è diventata l’imperativo assoluto per la Pubblica Amministrazione. Il passaggio dal concetto di semplice ripristino tecnico a quello di garanzia della continuità del servizio pubblico non è più opzionale: è un requisito legale, etico e di fiducia dei cittadini. Quando un incidente informatico (cyber attacco, guasto hardware, disastro naturale) blocca i servizi essenziali, l’impatto si misura in ore di inattività, perdita di dati critici e, soprattutto, nell’erosione della fiducia.

Garantire la business continuity dopo un incidente significa predisporre un’architettura tecnologica, organizzativa e procedurale che permetta di passare dalla condizione normale di funzionamento a una condizione di emergenza senza interruzioni significative dei servizi ai cittadini e alle imprese. Per la PA, questo implica la capacità di gestire simultaneamente la riparazione del danno (Disaster Recovery) e la continuazione delle operazioni critiche (Business Continuity), due processi distinti ma strettamente interconnessi. Il rischio di inazione è elevato: sanzioni amministrative per violazione del Codice dell’Amministrazione Digitale (CAD), perdita di dati irrecuperabili, sanzioni previste dalla normativa di cybersecurity (NIS2) e, non da ultimo, il danno di immagine verso i contribuenti.

In questo articolo, ti guideremo attraverso una roadmap pratica per costruire e mantenere un piano di Disaster Recovery e Business Continuity per la tua Pubblica Amministrazione. Analizzeremo come identificare le criticità, definire i Recovery Time Objective (RTO) e Recovery Point Objective (RPO) in linea con le normative vigenti, selezionare le soluzioni tecnologiche più adatte e, soprattutto, come gestire il fattore umano durante l’emergenza. L’obiettivo non è solo tecnologico: è trasformare la tua PA in un’organizzazione resiliente, capace di operare anche quando il sistema primario è sotto attacco o guasto.

Per supportarti in questo percorso, Culture Digitali Srl offre un’analisi gratuita della tua attuale maturità di resilienza. Contattaci per saperne di più e richiedere una consulenza dedicata.

Perché la Disaster Recovery (DR) non è più opzionale per le PA

Le Pubbliche Amministrazioni (PA) sono sempre più bersaglio di attacchi informatici e guasti sistemici che possono bloccare servizi essenziali per cittadini e imprese. Un downtime prolungato non è più accettabile: il rischio è paralizzare l’erogazione di servizi vitali, con conseguenze legali, sanzioni e una perdita di fiducia da parte degli utenti. Inoltre, normative come il GDPR e i requisiti di resilienza dei sistemi pubblici impongono di garantire la continuità operativa.

La Disaster Recovery (DR) diventa quindi strategica: non solo permette di ripristinare dati e sistemi in tempi rapidi, ma assicura che la PA possa continuare a operare anche durante un’emergenza. In assenza di un piano DR, il costo di un’interruzione prolungata supera quasi sempre l’investimento necessario per prevenirla.

Come esperti di sicurezza e continuità ICT, Culture Digitali Srl aiuta le PA a progettare e implementare piani di Disaster Recovery su misura, riducendo i rischi e garantendo stabilità.

Parla con i nostri esperti e scopri come proteggere la tua amministrazione

L’impatto degli incidenti informatici sui servizi al cittadino

Gli incidenti informatici che colpiscono la Pubblica Amministrazione (PA) non si limitano a causare danni tecnici, ma generano un impatto diretto e tangibile sulla vita dei cittadini. Quando i sistemi di pagamento, le piattaforme di prenotazione o i portali per l’accesso ai servizi pubblici vanno offline, si blocca l’erogazione di prestazioni essenziali come sanità, welfare e istruzione. Questo non è solo un disservizio: è una frattura nella fiducia tra cittadino e istituzione.

Il disagio si traduce in costi economici reali: ore di lavoro perse in code fisiche, ritardi nelle procedure amministrative, impossibilità di accedere a diritti o bonus. In scenari gravi, come un attacco ransomware, l’interruzione può protrarsi per giorni, con ripercussioni sulla sicurezza pubblica e sulla continuità operativa di servizi critici. Ogni minuto di downtime è un colpo alla trasparenza e all’efficienza dell’amministrazione, oltre che un danno reputazionale che si riflette sull’intero sistema-paese.

Per mitigare questi rischi, una strategia di Disaster Recovery mirata non è un lusso, ma una necessità per garantire che i servizi al cittadino rimangano accessibili e funzionali, anche in condizioni di crisi.

Il Quadro Normativo di Riferimento: GPAA, AgID e NIS2

Il Quadro Normativo di Riferimento: GPAA, AgID e NIS2

La continuità operativa delle Pubbliche Amministrazioni (PA) dopo un incidente informatico non è una mera opzione tecnica, bensì un obbligo normativo vincolante. Il quadro giuridico italiano ed europeo ha subito un’accelerazione significativa negli ultimi anni, imponendo standard di resilienza sempre più stringenti. Per la PA, ignorare queste prescrizioni significa esporsi a rischi di sanzioni amministrative pesanti, responsabilità erariale e, soprattutto, alla interruzione dei servizi essenziali erogati ai cittadini e alle imprese.

Il riferimento primario è la Generale Prescrizione per l’AgID (Agenzia per l’Italia Digitale) n. 1/2020, denominata “Piano di continuità operativa e di disaster recovery per le pubbliche amministrazioni” (GPAA). Questa disposizione ha rotto con il passato, stabilendo che la business continuity non è più una buona prassi, ma un requisito formale. L’AgID, nel ruolo di organismo di regolazione e promozione della trasformazione digitale, ha delineato i principi fondamentali che ogni PA deve adottare. Tra questi, spicca l’obbligo di adottare il Business Continuity Management System (BCMS) secondo lo standard ISO 22301 e di definire chiaramente i Recovery Time Objective (RTO) e Recovery Point Objective (RPO). L’RTO definisce il tempo massimo entro il quale un servizio critico deve essere ripristinato, mentre l’RPO indica la massima perdita di dati tollerabile, misurata temporalmente. La GPAA richiede inoltre la redazione e l’aggiornamento periodico di due documenti fondamentali: il Piano di Continuità Operativa (Piano CO) e il Piano di Disaster Recovery (Piano DR). Non si tratta di documenti statici, ma di piani vivi che devono essere sottoposti a verifiche e test periodici, inclusi i test di ripristino per validare l’efficacia delle procedure.

A completare il quadro normativo nazionale interviene il Regolamento sugli strumenti e i servizi digitali per la PA (Decreto Legislativo 82/2005 e successive integrazioni), che affida all’AgID il compito di definire le linee guida per la gestione dei sistemi informativi. In questo contesto, l’AgID ha pubblicato le Linee guida per la gestione dei sistemi informativi di pubblica amministrazione, che includono specifiche tecniche sulla sicurezza, sulla gestione dei dati e sulla architettura dei sistemi. La conformità a queste linee guida è essenziale per garantire l’interoperabilità e la sicurezza dei servizi digitali, elementi imprescindibili per una efficace continuità operativa.

Sul piano europeo, un impatto determinante per le PA (soprattutto quelle che operano in settori critici o forniscono servizi essenziali) è stato introdotto dalla Direttiva NIS2 (Network and Information Security 2), recepita in Italia con il Decreto Legislativo 24 agosto 2022, n. 138. La NIS2 amplia notevolmente l’ambito di applicazione rispetto alla precedente direttiva NIS, includendo esplicitamente molti settori della PA, come la gestione dei rifiuti, i trasporti pubblici, la fornitura di acqua potabile e la distribuzione di energia elettrica. Per le cosiddette “organizzazioni essenziali” (ricadute nella PA), la NIS2 impone l’adozione di misure di sicurezza “tecnicamente appropriate e proporzionate al rischio”. In caso di grave incidente informatico, le PA hanno l’obbligo di notificare l’evento alle autorità competenti (in Italia, il Ministero dell’Interno e il CSIRT Nazionale) entro termini stringenti: 24 ore per la segnalazione iniziale e 72 ore per un rapporto più dettagliato. La non conformità alla NIS2 comporta sanzioni amministrative che possono arrivare fino al 2% del fatturato mondiale dell’anno precedente, con un importo massimo che può superare i 10 milioni di euro per le organizzazioni essenziali. La NIS2 richiede inoltre che il top management (ad esempio, il dirigente responsabile del sistema informativo) approvi le misure di sicurezza e ne supervisioni l’attuazione, introducendo una responsabilità diretta che va oltre la mera delega tecnica.

Infine, il Codice della Cybersicurezza (D.Lgs. 105/2018) e il relativo Piano Nazionale di Cybersicurezza definiscono il quadro strategico nazionale, promuovendo l’adozione di misure di sicurezza avanzate e la resilienza dei sistemi informativi critici. Il Piano, periodicamente aggiornato, prevede azioni specifiche per le PA, tra cui il potenziamento della capacità di risposta agli incidenti e la diffusione della cultura della sicurezza.

La convergenza di questi quadri normativi (GPAA per la continuità operativa, AgID per la governance dei sistemi informativi, NIS2 per la sicurezza dei network e delle informazioni) crea un ecosistema di obblighi interconnessi. La business continuity non è più separata dalla sicurezza informatica; anzi, le due discipline si fondono. Un incidente di sicurezza (es. un ransomware) che causa una interruzione prolungata dei servizi viola non solo le regole di sicurezza (NIS2), ma anche gli obblighi di continuità operativa (GPAA). Di conseguenza, il Disaster Recovery Planning deve integrare sia le procedure tecniche di ripristino (backup, ridondanza, cloud) sia i protocolli di sicurezza per prevenire e contenere le minacce. Per le PA, la conformità normativa non è solo un adempimento burocratico, ma la base legale su cui costruire una resilienza digitale che garantisca la continuità dei servizi pubblici anche in condizioni di crisi.

Il Piano di Gestione della Continuità Operativa (GPAA) e le sue linee guida

Il Piano di Gestione della Continuità Operativa (GPAA) e le sue linee guida

Il cuore della continuità operativa nelle PA è il Piano di Gestione della Continuità Operativa (GPAA). Non si tratta di un semplice documento tecnico, ma di una mappa strategica che delinea azioni concrete per rilevare, contenere e gestire gli incidenti informatici, minimizzando l’interruzione dei servizi ai cittadini e alle imprese.

Secondo le linee guida AGID, un GPAA efficace deve essere modulare, testato e costantemente aggiornato. Ecco i pilastri fondamentali da implementare:

• Analisi di impatto (BIA) e del rischio (RA): Identifica i sistemi critici (es. pagoPA, SPID, anagrafi) e quantifica l’impacto economico e reputazionale di un downtime, definendo i Recovery Time Objective (RTO) e Recovery Point Objective (RPO) target.
• Strategie di ripristino: Definisce le procedure per il backup, l’attivazione di siti ridondanti (Hot/Warm/Cold site) e l’uso del Cloud PA per garantire resilienza senza costi proibitivi.
• Organizzazione del Team di Crisi: Nomina chiaramente i ruoli (RUP, referenti IT, ufficio comunicazione) e le procedure di escalation in caso di gravità crescente.
• Comunicazione d’emergenza: Stabilisce canali predefiniti per informare le autorità (CERT-PA) e gli utenti finali, mantenendo la fiducia.

Il GPAA non è statico: richiede test periodici (table-top exercise e simulazioni) per validare l’efficacia delle procedure e garantire che il personale sia pronto all’azione.

I requisiti tecnici dell’AgID (Cloud e Data Center)

I requisiti tecnici dell’AgID (Cloud e Data Center)

Per garantire una DR efficace, le PA devono selezionare soluzioni tecnologiche allineate alle linee guida dell’Agenzia per l’Italia Digitale (AgID). Secondo il Cloud di Ministero e PA, la scelta ricade su tre modalità: Cloud Privato (on-premise), Cloud Pubblico o servizi di colocation in Data Center certificati.

• Infrastruttura e ridondanza: è obbligatorio garantire la ridondanza delle infrastrutture critiche (server, storage, reti) su due site distinti. Il sito di backup (replica) deve distare geograficamente da quello primario per mitigare rischi locali (terremoti, allagamenti).
• Requisiti di connettività: è necessaria una connessione dedicata ad alta banda (minimo 1 Gbps) tra i due siti per la sincronizzazione dei dati in tempo reale o quasi reale, evitando sovraccarichi sulla rete pubblica.
• Certificazioni dei Data Center: i fornitori devono garantire Data Center certificati secondo gli standard nazionali (Tier III o superiori) e internazionali (Uptime Institute, TIA-942). È essenziale la certificazione ISO/IEC 27001 per la sicurezza delle informazioni e la ISO/IEC 22301 per la Business Continuity, validata da enti terzi accreditati.
• Cloud e Sovranità: per le dati sensibili, AgID raccomanda soluzioni di Cloud Sovrano o Multi-Cloud con provider certificati NIS2 compliant, assicurando che i dati risiedano in territorio UE e che siano esclusi trasferimenti verso paesi terzi non sicuri.

Adottare queste specifiche tecniche non solo garantisce il rispetto normativo, ma permette di raggiungere gli obiettivi di RTO (Recovery Time Objective) e RPO (Recovery Point Objective) richiesti dalla continuità operativa.

L’influenza della Direttiva NIS2 e del perimetro di sicurezza nazionale cibernetica

L’evoluzione normativa italiana ha introdotto due pilastri fondamentali che impattano direttamente sulla resilienza dei sistemi informatici della Pubblica Amministrazione: la Direttiva NIS2 e il perimetro di sicurezza nazionale cibernetica.

La Direttiva NIS2, recepita nell’ordinamento italiano, allarga significativamente il campo di applicazione soggettivo ed obbliga le Amministrazioni critiche a garantire un livello di sicurezza adeguato ai rischi. Questo non si limita alla prevenzione, ma impatta direttamente sulle strategie di Disaster Recovery. Una business continuity plan (BCP) non può più considerare solo la perdita di dati, ma deve prevedere la gestione di incidenti cibernetici significativi, con tempi di notifica stringenti (24/72 ore) e procedure di ripristino che garantiscano la continuità operativa anche in presenza di compromissioni gravi.

Parallelamente, il perimetro di sicurezza nazionale cibernetica definisce un insieme di soggetti considerati strategici per la sicurezza nazionale. Per le Amministrazioni ricadenti in questo perimetro, il Disaster Recovery non è più solo una best practice tecnologica, ma un obbligo di legge con requisiti di resilienza elevatissimi. È necessario garantire la disponibilità dei servizi anche in condizioni di stress estremo, implementando strategie come il back-up in cloud sicuro in diversi location geografici e piani di continuità che siano testati periodicamente.

Integrare questi due framework normativi nella propria strategia di Disaster Recovery è essenziale non solo per evitare sanzioni pesantissime, ma per costruire un’infrastruttura digitale realmente resiliente.

Analisi di Rischio e Business Impact Analysis (BIA) nella PA

Analisi di Rischio e Business Impact Analysis (BIA) nella PA

Per una Pubblica Amministrazione, garantire la business continuity dopo un incidente informatico non è solo una questione tecnica, ma un obbligo di servizio verso i cittadini.
Il primo passo fondamentale, spesso sottovalutato, è l’analisi del rischio e la Business Impact Analysis (BIA).
Senza una valutazione strutturata, qualsiasi piano di Disaster Recovery (DR) si basa su supposizioni, rischiando di inefficacia nel momento critico.
In questo articolo esploriamo come condurre un’analisi di rischio efficace e quali sono i parametri essenziali della BIA per le Amministrazioni Pubbliche.

L’analisi di rischio nella PA deve considerare una molteplicità di fattori che vanno oltre la semplice probabilità tecnica di un guasto.
Bisogna valutare la criticità dei dati gestiti (dati anagrafici, sanitari, giudiziari), la dipendenza da fornitori esterni e, soprattutto, il danno reputazionale e sociale che un’interruzione prolungata del servizio può causare.
È necessario mappare il patrimonio informativo e identificare le dipendenze funzionali tra i diversi sistemi.

Definizione di RTO e RPO nel contesto pubblico

La Business Impact Analysis (BIA) si traduce nella definizione di due parametri critici: il RTO (Recovery Time Objective) e il RPO (Recovery Point Objective).
Nella PA, questi valori non sono scelti arbitrariamente, ma devono rispettare le normative vigenti e i livelli di servizio (SLA) promessi ai cittadini.

• RTO (Recovery Time Objective): È il tempo massimo entro il quale un servizio deve essere ripristinato dopo un guasto.
  Per un servizio di anagrafe, l’RTO potrebbe essere di poche ore, mentre per un archivio storico potrebbe estendersi a più giorni.
  Definire un RTO realistico richiede una valutazione del costo dell’indisponibilità del servizio.
• RPO (Recovery Point Objective): È la massima perdita di dati tollerabile, misurata in tempo.
  Se l’RPO è di 1 ora, significa che in caso di disaster, si accetterà la perdita dei dati prodotti nell’ultima ora.
  Per le PA, che gestiscono transaction in tempo reale, un RPO prossimo allo zero è spesso necessario.

Metodologia di analisi per le Amministrazioni

La conduzione della BIA richiede un approccio multidisciplinare che coinvolga non solo gli uffici ICT, ma anche i responsabili dei processi amministrativi.
Si consiglia di procedere per step definiti, garantendo tracciabilità e ripetibilità del processo.

1. Mappatura dei processi critici

Identificare quali processi, se interrotti, causano impatti immediati e irreparabili.
Ad esempio, la gestione dei pagamenti delle tasse o l’emissione di certificati digitali sono processi ad alta criticità.
È fondamentale classificare i processi in base alla gravità dell’impatto operativo, legale e finanziario.

2. Identificazione delle dipendenze IT

Ogni processo amministrativo si appoggia a specifiche applicazioni, database e infrastrutture di rete.
La BIA deve disegnare una mappa delle dipendenze: ad esempio, il processo di “gestione del personale” dipende dal database anagrafico, dal sistema di posta elettronica certificata e dalla connettività verso il Ministero dell’Economia.
Una discontinuità in uno qualsiasi di questi nodi compromette l’intero processo.

3. Calcolo dell’impatto economico e sociale

L’impatto di un fermo servizio nella PA si misura anche in termini di sanzioni normative e perdita di fiducia dei cittadini.
È utile quantificare l’impatto in scenari orari, giornalieri e settimanali.
Esempio: “Se il sistema di prenotazione sanitaria è giù per 24 ore, l’impatto è X ritardi nelle visite e Y ore/uomo perse dal personale”.

Errori comuni nella valutazione del rischio PA

Spesso le Amministrazioni cadono in errori ricorrenti che invalidano i piani di continuità.
Evitarli è cruciale per una resilienza effettiva.

• Sottovalutazione del rischio umano: L’errore operativo (es. cancellazione involontaria di un database) è più frequente degli attacchi esterni.
  La BIA deve includere percorsi di formazione e procedure di mitigazione dell’errore umano.
• Ignorare la supply chain: Molte PA dipendono da software gestionali in cloud o da fornitori di connettività.
  Se il fornitore esterno subisce un guasto, la PA è in difficoltà.
  È necessario richiedere ai fornitori certificazioni sulla propria capacità di Disaster Recovery e includerle nel contratto.
• Analisi statica: L’ambiente IT evolve rapidamente.
  Una BIA fatta due anni fa è ormai obsoleta.
  È necessario prevedere revisioni periodiche (almeno semestrali) per aggiornare la mappatura dei rischi e i valori di RTO/RPO.

Una volta completata la BIA, è possibile passare alla definizione dello scenario di disaster recovery e alla selezione della strategia tecnica più adatta, che sarà l’oggetto del prossimo paragrafo.
Ricordiamo che l’analisi di rischio non è un esercizio teorico, ma la base su cui costruire la resilienza della propria amministrazione.

Identificazione delle funzioni critiche e dei servizi essenziali

Identificazione delle funzioni critiche e dei servizi essenziali

La Business Continuity e la Disaster Recovery per le PA iniziano con una mappa chiara di cosa non può fermarsi. Non si tratta solo di proteggere i server, ma di assicurare la continuità dei servizi erogati ai cittadini e alle imprese, garantendo il rispetto dei diritti e degli obblighi normativi.

La prima regola è non fermarsi alle infrastrutture IT. Il rischio è cadere nella trappola tecnocentrica: si protegge il data center, ma il sistema di anagrafe, i pagamenti dei contributi o le prenotazioni sanitarie restano inaccessibili perché le procedure manuali non sono pronte.

Per identificare le criticità, segui questo approccio pratico in tre passi:

• Mappa i processi di business: elenca tutte le attività che generano valore per l’ente (es. emissione di certificati, gestione appalti, riscossione tributi). Coinvolgi i direttori di ogni settore: solo loro conoscono le dipendenze funzionali.
• Valuta l’impatto: per ogni processo, calcola l’impatto operativo, reputazionale e normativo in caso di sospensione. Usa una scala semplice (basso, medio, alto) considerando anche eventuali sanzioni o perdita di fondi.
• Stima i tempi di tolleranza: definisci il Recovery Time Objective (RTO) massimo e il Recovery Point Objective (RPO) accettabile per ogni funzione critica. Un’anagrafe potrebbe avere RTO di poche ore, mentre l’archivio storico documentale tollera diversi giorni.

CHECKLIST PRATICA: Per ogni servizio essenziale, chiediti: “Se questo servizio si ferma per 24 ore, qual è il danno per i cittadini? Quali procedure manuali attiviamo?” Questa analisi costituisce il fondamento per un piano di Disaster Recovery realmente efficace per le PA.

Definizione di RTO e RPO: parametri fondamentali per il ripristino

Nel contesto del Disaster Recovery per la Pubblica Amministrazione (PA), due parametri definiscono la strategia di ripristino: RTO e RPO. Rappresentano i pilastri su cui costruire un piano coerente con le esigenze di continuità operativa, vincoli normativi e budget disponibili.

• RTO (Recovery Time Objective): è il tempo massimo entro il quale un sistema, un’applicazione o un processo critico deve essere ripristinato e operativo dopo un incidente. In termini pratici, misura quanto tempo la PA può permettersi di subire un’interruzione prima di subire danni irreversibili (reputazionali, operativi, sanzionatori). Un RTO breve richiede soluzioni ad alta automatizzazione e ridondanza, come il failover su un altro data center. Un RTO più lungo può accettare un ripristino tramite backup su supporti fisici.
• RPO (Recovery Point Objective): è la massima perdita di dati tollerabile, misurata in tempo, tra l’ultimo backup valido e il momento dell’incidente. Definisce “a che punto” si deve ripartire. Un RPO pari a 0 (near-zero data loss) implica sistemi di replica sincrona, costosi e complessi. Un RPO di 24 ore, invece, tollera la perdita dei lavori dell’ultimo giorno, accettando la necessità di operare manualmente su quanto fatto nell’intervallo.

Definire RTO e RPO non è un esercizio puramente tecnico, ma di governance: va allineato al valore del servizio, ai livelli di servizio (SLA) garantiti ai cittadini e ai requisiti normativi (es. NIS2 per la sicurezza delle reti e dei sistemi informativi). Sono fondamentali per valutare la resilienza della PA e la coerenza dell’investimento in cyber-resilience.

Mappatura delle dipendenze esterne (SaaS, fornitori, interconnessioni)

Mappatura delle dipendenze esterne (SaaS, fornitori, interconnessioni)

Il piano di Disaster Recovery (DR) per la PA deve estendersi oltre i propri server, includendo tutte le esternalizzazioni critiche. Un’analisi approfondita identifica:

• SaaS e cloud: servizi di posta, storage, piattaforme collaborative. Verificare gli SLA (Service Level Agreement) di disponibilità e i tempi di RTO/RPO.
• Fornitori e appaltatori: controllare i contratti per clausole di continuità operativa, obblighi di notifica incidente e procedure di failover.
• Interconnessioni e API: mappare i flussi dati verso banche, INPS, ACN, sistemi di pagamento. Assicurarsi di avere percorsi alternativi (backup linee, connessioni ridondanti).

Una mappatura chiara deve indicare per ogni fornitore il responsabile di contatto, gli impatti in caso di interruzione e le azioni da intraprendere.

Strategie di Disaster Recovery: Backups, Replication e Cloud

Backup: La Prima Linea di Difesa

Il backup rappresenta il pilastro fondamentale di qualsiasi strategia di Disaster Recovery (DR). Tuttavia, nella PA, non si può limitare a una semplice copia dei file. Per garantire la continuità operativa dopo un incidente, i backup devono seguire la regola del 3-2-1, adattata al contesto normativo italiano ed europeo.

Questa regola prevede:

• 3 copie dei dati: l’originale e almeno due copie.
• 2 supporti diversi: ad esempio, disco locale e nastro magnetico, o disco locale e storage in cloud.
• 1 copia off-site: memorizzata in una location fisica separata dall’infrastruttura principale.

Per le Amministrazioni Pubbliche, la scelta del backup su nastro (LTO – Linear Tape-Open) rimane una pratica validissima per l’archiviazione a lungo termine (cold storage) grazie alla sua immutabilità e resistenza ai ransomware. Tuttavia, per tempi di ripristino rapidi (RTO brevi), è necessario integrare questa soluzione con backup su disco ad alte prestazioni.

Azione Pratica: Configura la conservazione dei backup in modalità immutable (immodificabile) per un periodo definito. Questo impedisce la cifratura o la cancellazione dei dati da parte di software malevoli, una misura essenziale per la compliance con le linee guida NIS2 che richiedono una protezione robusta della catena di approvvigionamento digitale.

Replication vs. Backup: Differenze e Sinergie

Molti confondono la replica dei dati con il backup, ma hanno scopi e funzioni distinti che devono essere orchestrati insieme per una DR efficace.

• Backup: È una snapshot (istantanea) dei dati in un momento specifico. Serve a ripristinare lo stato precedente a un evento di perdita dati (cancellazione accidentale, corruzione). Ha RTO e RPO (Recovery Point Objective) più lunghi.
• Replication: È una copia sincrona o asincrona dei dati in tempo reale verso un secondo sistema. Se il primario fallisce, il secondario prende il controllo quasi istantaneamente. Ha RTO e RPO brevissimi.

Per una PA, la scelta strategica dipende dalla criticità del servizio. I servizi ad alta disponibilità (es. portali cittadini, sistemi di pagamento) richiedono una replica sincrona (o near-sincrona) verso un sito di disaster recovery (DR site). I sistemi meno critici (es. archivi documentali non accessibili al pubblico) possono affidarsi a backup incrementali giornalieri.

Caso d’uso nella PA: Un Comune deve garantire l’accesso al servizio di prenotazione appuntamenti online. Un failover automatico tramite replica garantisce che, in caso di guasto al datacenter primario, il sito rimanga operativo entro pochi minuti, evitando code fisiche in municipio e malcontento dei cittadini.

Il Cloud come Abilitatore di Disaster Recovery (DRaaS)

Il Cloud Computing ha democratizzato l’accesso a infrastrutture di Disaster Recovery, trasformandolo da costo capitale (CAPEX) a costo operativo (OPEX), un vantaggio significativo per i bilanci pubblici vincolati dalla programmazione triennale.

Il Disaster Recovery as a Service (DRaaS) permette di replicare le macchine virtuali (VM) e i dati dei server on-premise verso un ambiente cloud (es. Microsoft Azure, Google Cloud, AWS o cloud italiano certificato). In caso di emergenza, l’ambiente cloud diventa operativo attivando le repliche.

Vantaggi per la PA:

1. Rapidità di attivazione: Non serve costruire un secondo datacenter fisico. Il DRaaS è già pronto all’uso.
2. Pay-per-use: Si paga solo per le risorse di calcolo e storage consumate durante il test o l’effettiva attivazione del DR.
3. Georedundanza: Il cloud permette di posizionare il sito di ripristino in una diversa regione geografica, proteggendo da disastri naturali (es. terremoti, alluvioni) che potrebbero colpire la sede principale.

È cruciale, però, valutare la latenza di rete. Per la replica sincrona, è necessaria una connessione dedicata ad alta banda (es. Fibra Ottica dedicata) tra l’infrastruttura on-premise e il cloud provider.

Attenzione alla compliance: Se il cloud provider è estero (extra-UE), bisogna garantire il rispetto del GDPR e delle normative italiane sulla localizzazione dei dati sensibili (es. dati biometrici, giudiziari). Il Cloud italiano (es. Aruba Cloud, Seeweb, o il Cloud della PA gestito da Leonardo/Poste Italiane) spesso è la scelta preferita per la sovranità digitale.

Architettura ibrida e gestione dei costi

La soluzione ottimale per la maggior parte delle PA è l’approccio ibrido: mantenere i carichi di lavoro critici e ad alta frequenza di accesso on-premise (per questioni di latenza e controllo diretto), ma affidare al cloud la protezione a lungo termine e il DR.

Per gestire efficacemente i costi del DRaaS, è fondamentale distinguere tra RTO (Recovery Time Objective) e RPO (Recovery Point Objective):

• RTO: Quanto tempo impiega un sistema a tornare operativo dopo un incidente.
• RPO: Quanta dati si è disposti a perdere (es. 15 minuti, 1 ora, 1 giorno).

Strumenti come Backup Disaster Recovery (BDR) Appliances on-premise possono catturare snapshot ogni 15 minuti e inviarli cifrati al cloud. Questo riduce drasticamente l’RPO rispetto ai backup giornalieri tradizionali, minimizzando la perdita di dati in caso di attacco ransomware.

Consiglio Strategico: Non utilizzare il cloud solo come “cassaforte”. Utilizzalo per testare i piani di ripristino. Creare un ambiente isolato nel cloud per simulare un attacco ransomware permette di validare le procedure senza intaccare la produzione, riducendo il rischio operativo durante i test di Disaster Recovery.

Il 3-2-1 Rule e le politiche di backup per dati sensibili della PA

Il 3-2-1 Rule e le politiche di backup per dati sensibili della PA

Il principio base per una gestione efficace del backup nella PA è il modello “3-2-1-1”, evoluzione del classico 3-2-1: conservare 3 copie dei dati su 2 supporti diversi, con 1 copia offsite e (opzionale ma consigliato) 1 copia immutabile o in “air gap”.

Per la Pubblica Amministrazione, che gestisce dati sensibili (anagrafici, sanitari, fiscali), questa architettura è fondamentale per proteggersi da:

• Ransomware: una copia immutabile (non sovrascrivibile) permette il ripristino anche se l’attacco cifra tutti i dati accessibili.
• Guasti fisici: distribuire i backup su supporti diversi (es. disco NAS locale e cloud) mitiga il rischio di perdita totale.
• Catastrofi naturali o fisiche: la copia offsite (remota) garantisce la continuità operativa anche se la sede centrale è inagibile.

Policy operative consigliate per la PA:

1. Classificazione Dati: Definire Recovery Point Objective (RPO) e Recovery Time Objective (RTO) per ogni categoria di dato (es. dati critici: RTO < 4 ore, RPO < 15 minuti).
2. Test Periodici: Eseguire simulazioni di disaster recovery almeno trimestralmente per verificare l’integrità dei backup e i tempi di ripristino.
3. Audit e Log: Tracciare ogni operazione di backup/restore per garantire tracciabilità e conformità normativa (GDPR, NIS2).
4. Accessi Restrittivi: Applicare il principio del minimo privilegio: solo pochi soggetti autorizzati possono gestire o cancellare i backup.

Questa architettura non è solo tecnica: è una misura di sicurezza strategica che trasforma il backup da semplice copia a pilastro della resilienza organizzativa.

Sincronizzazione vs Replica Asincrona: scelte per la continuità

Sincronizzazione vs Replica Asincrona: scelte per la continuità

La scelta tra sincronizzazione e replica asincrona definisce il profilo di rischio di una PA in caso di guasto. Le due modalità incidono direttamente su RPO (Recovery Point Objective) e RTO (Recovery Time Objective), influenzando anche costi e impatto utente.

• Replica sincrona (RPO quasi zero): I dati vengono scritti contemporaneamente su più siti. Garantisce la coerenza assoluta, ma è costosa (latenza e banda dedicata) e introduce un rischio di “stallo” se la connessione tra i siti cade. Consigliata per archivi transazionali critici (es. anagrafi, pagamenti), dove la perdita di dati è inaccettabile.
• Replica asincrona (RPO variabile): I dati sono copiati con un ritardo (minuti/ore). È più economica e tollerante a guasti di rete, ma ammette una perdita di dati limitata. Ideale per dati operativi non ultra-critici (es. documentale, log) o per backup giornalieri. Il rischio è la disallineamento tra i siti in caso di incidente improvviso.

Best practice per le PA: Adottare un approccio ibrido. Sincronizzare i dati transaction-critical; replicare in asincrono i restanti dataset. Monitorare la latenza e testare regolarmente i failover per evitare sorprese.

Il Cloud per la DR: IaaS, DRaaS e la scelta del fornitore certificato

Il cloud computing rappresenta oggi la soluzione più flessibile e scalabile per implementare una strategia di Disaster Recovery moderna, superando i limiti e i costi delle infrastrutture fisiche dedicate. Per la Pubblica Amministrazione, la scelta del modello di servizio e del partner è un passaggio strategico che incide direttamente sulla resilienza e sulla conformità normativa.

I Modelli di Servizio Cloud per il DR: IaaS vs DRaaS

È fondamentale distinguere tra due approcci principali:

• Infrastructure as a Service (IaaS): La PA mantiene il pieno controllo sull’architettura di DR, installando e gestendo i propri software di replica e failover su infrastrutture virtuali fornite dal cloud provider. Offre massima personalizzazione ma richiede competenze interne specializzate.
• Disaster Recovery as a Service (DRaaS): È una soluzione “chiavi in mano”. Il fornitore gestisce l’intero processo – replica automatizzata, test, piano di ripristino e esecuzione del failover – come servizio gestito. Riduce drasticamente il carico operativo interno ed è ideale per organizzazioni con risorse IT limitate.

Checklist per la Scelta del Fornitore Cloud Certificato

La selezione del partner non può basarsi solo sul prezzo. Per la PA, la compliance è prioritaria. Ecco i criteri da valutare:

• Certificazioni di Settore: Il provider deve operare da data center certificati AgID per i servizi cloud della PA, e possedere attestazioni come ISO 27001 (Sistemi di Gestione della Sicurezza delle Informazioni) e ISO 22301 (Business Continuity).
• SLA (Service Level Agreement) Trasparenti e Garantiti: Controllare i parametri contrattuali su RTO (Recovery Time Objective) e RPO (Recovery Point Objective) promessi, e le penali per il loro mancato rispetto.
• Sovranità e Localizzazione dei Dati: Accertarsi che i data center siano sul territorio nazionale o nell’UE, in linea con il GDPR e le circolari AgID sulla conservazione dei dati pubblici.
• Esperienza nel Settore Pubblico: Preferire fornitori con case history consolidate con Enti locali, ASL, Università, che comprendano i processi amministrativi e le gare d’appalto (Codice degli Appalti).

La migrazione verso soluzioni DR in cloud non è solo una questione tecnologica, ma un investimento sulla continuità del servizio pubblico. Affidarsi a un partner certificato e esperto significa trasformare un obbligo di resilienza in un vantaggio strategico di efficienza e modernizzazione.

Pianificazione e Documentazione del Piano di Disaster Recovery

Pianificazione e Documentazione del Piano di Disaster Recovery

La resilienza operativa di una Pubblica Amministrazione non nasce durante l’emergenza, ma nella fase di pianificazione e documentazione strategica. In un contesto in cui le interruzioni dei servizi possono avere ripercussioni dirette sui diritti dei cittadini e sulla stabilità socio-economica territoriale, un Piano di Disaster Recovery (PdR) ben strutturato rappresenta l’infrastruttura invisibile che garantisce la continuità. Non si tratta di un semplice documento tecnico da archiviare, ma di una roadmap dinamica che allinea requisiti normativi, obiettivi di business e risorse IT.

Il processo inizia con la definizione del quadro di riferimento e l’identificazione dei driver di business. È necessario chiedersi: quali servizi pubblici sono considerati “critici” per la cittadinanza? Per rispondere a questa domanda, l’approccio più efficace è la Business Impact Analysis (BIA), un’analisi che non si limita a valutare le conseguenze finanziarie (spesso nulle o trascurabili nel settore pubblico rispetto al privato), ma si concentra sul danno reputazionale, operativo e legale derivante dall’indisponibilità del servizio.

Attraverso la BIA, si determinano due parametri fondamentali:

• RTO (Recovery Time Objective): l’arco di tempo massimo entro il quale un processo o un sistema deve essere ripristinato per evitare impatti inaccettabili sulle attività;
• RPO (Recovery Point Objective): la quantità di dati massima accettabile di perdita, misurata in tempo (es. ultimi 15 minuti, ultime 4 ore).

Questi valori non sono scelti a caso, ma derivano da un’attenta analisi della tipologia di dato gestito. Ad esempio, un sistema di gestione del protocollo informatico potrebbe avere un RTO di 4 ore e un RPO di 1 ora, mentre il portale dei pagamenti online richiederebbe un RTO di 30 minuti e RPO quasi istantaneo (o “zero data loss”). Definire questi target è il primo passo per progettare un’infrastruttura di Disaster Recovery (DR) economicamente sostenibile e tecnicamente efficace.

Preparazione di una CTA Soft

La Documentazione del Piano di Disaster Recovery

Un piano di disaster recovery efficace deve essere un documento chiaro, conciso e accessibile anche in condizioni di stress elevato. Evita manuali di centinaia di pagine che rimarranno impolverati sugli scaffali. La documentazione ideale si articola su tre livelli gerarchici:

1. Manuale Strategico (livello direzionale): Definisce la governance della DR, le responsabilità dei ruoli chiave (Crisis Manager, IT Manager, Responsabile della Comunicazione), i criteri di attivazione della procedura e i rapporti con fornitori e autorità esterne (es. Presidenza del Consiglio, Dipartimento per la Trasformazione Digitale).
2. Manuale Tattico (livello tecnico-operativo): Contiene le procedure operative standard (SOP) passo-passo. Esempio: “Se il server centrale del protocollo è down, verificare la connessione alla rete locale. Se persa, attivare il failover verso il sito secondario in cloud. Verificare la risincronizzazione dei database.”
3. Manuale di Supporto (livello helper): Lista di contatti aggiornati, diagrammi di rete, schemi di configurazione, chiavi di licenza software e credenziali di accesso (gestite in modo sicuro tramite password manager aziendali).

Un elemento spesso trascurato nella documentazione PA è la comunicazione di crisi. Il piano deve includere template pre-definiti per comunicati stampa, avvisi per i cittadini sul portale istituzionale e notifiche interne al personale. Avere testi pronti da personalizzare permette di gestire l’opinione pubblica con tempestività, riducendo la diffusione di fake news in caso di blackout informatico.

Scenari di Disaster Recovery e Architetture Tecnologiche

La documentazione tecnica deve dettagliare l’architettura scelta per il ripristino. Le Pubbliche Amministrazioni, specialmente i piccoli Comuni, non hanno budget illimitati, per cui le soluzioni devono essere scalabili. Le opzioni più comuni includono:

1. Disaster Recovery Site (Sede di Ripristino)

Consiste nel mantenere una copia fisica o virtuale dell’infrastruttura IT in una location separata da quella primaria. Per le PA, questa soluzione può essere implementata tramite:

• Hosting Privato o Co-location: Server fisici in un data center diverso dall’ufficio principale.
• Cloud Pubblico o Ibrido: Sfruttando il Cloud Computing, si possono replicare le macchine virtuali su un altro data center geografico. Questo approccio offre maggiore flessibilità e riduce i costi hardware, essendo basato su un modello “pay-per-use”.

2. Replicazione Asincrona vs Sincrona

Nella documentazione tecnica, bisogna specificare il metodo di trasferimento dei dati:

• Replicazione Sincrona: I dati vengono scritti contemporaneamente sul sito primario e su quello secondario. Garantisce RPO zero, ma è costosa e introduce latenza. Adatta a database transazionali critici.
• Replicazione Asincrona: I dati vengono inviati al sito secondario con un leggero ritardo. È più economica e adatta a scenari dove una perdita di qualche minuto di dati è accettabile (es. archiviazione documentale).

Nel contesto PA, è fondamentale considerare la sicurezza dei dati durante la replica, specialmente se si utilizza un fornitore cloud esterno. La documentazione deve attestare la conformità al GDPR e al Codice dell’Amministrazione Digitale (CAD), garantendo che i dati sensibili dei cittadini siano cifrati sia in transito che a riposo.

Validazione e Manutenzione: Il Ciclo di Vita del PdR

Un piano di disaster recovery non è mai “finito”. La tecnologia evolve, i rischi cambiano e il personale si rinnova. La documentazione deve includere un calendario di manutenzione vincolante.

Test di Ripristino (Disaster Recovery Test)

La validazione è l’unico modo per assicurarsi che il piano funzioni. La documentazione dovrebbe prevedere diversi livelli di test, da svolgersi almeno annualmente:

1. Table-top Exercise (Walkthrough): Simulazione teorica di un incidente in una sala riunioni con i decisori. Si analizzano le decisioni senza toccare i sistemi.
2. Test di Funzionalità (Partial): Si verifica il ripristino di un singolo modulo applicativo (es. l’intranet) o di un sotto-sistema non critico durante il fine settimana.
3. Failover completo: Scalo totale dei servizi verso il sito di ripristino in orari prestabiliti (di norma notturni o festivi) per non disturbare i servizi erogati.

Ogni test deve produrre un Report di Audit documentante i tempi reali di ripristino rispetto agli RTO target, gli eventuali errori riscontrati e le azioni correttive. Questo report è fondamentale in caso di verifiche da parte della Corte dei Conti o di audit di sicurezza ISO 27001.

Revisone del Piano

Il documento deve prevedere una revisione formale almeno una volta l’anno o in seguito a:

• Introduzione di nuovi sistemi informativi;
• Cambiamenti significativi nell’organizzazione (es. fusione di due uffici);
• Evoluzioni normative (es. nuovi requisiti di cybersecurity come NIS2 per le PA critiche);
• Esito negativo di un test di ripristino.

La revisione non deve essere un semplice aggiornamento formale, ma una revisione critica della strategia. Ad esempio, se i test mostrano costantemente che il ripristino della posta elettronica certificata richiede troppo tempo, il piano deve essere modificato per ottimizzare quella specifica procedura, magari introducendo una soluzione di disaster recovery as-a-service gestita.

Responsabilità e Conformità Normativa

La documentazione del Piano di Disaster Recovery deve definire senza ambiguità le responsabilità (RACI Matrix):

• Responsabile (R): Colui che esegue l’azione (es. System Administrator).
• Accountable (A): Colui che risponde del risultato (es. Responsabile dell’Innovazione Digitale).
• Consultato (C): Esperti interni o esterni da consultare.
• Informato (I): Chi deve essere tenuto al corrente.

Per le Pubbliche Amministrazioni, la documentazione del piano di DR deve anche allinearsi al Piano Triennale per l’Informatica nella Pubblica Amministrazione (PTIPA) e agli indirizzi del Dipartimento per la Trasformazione Digitale. In particolare, la Direttiva n. 63/2024 sul cloud mira a spostare i sistemi delle PA verso ambienti cloud certificati, impattando direttamente su come vengono disegnati e documentati i piani di continuità. Il piano deve dimostrare come la migrazione cloud rispetti i requisiti di sicurezza e continuità.

Infine, la documentazione deve prevedere il collegamento con il Piano di Sicurezza Informatica (PSI). Disaster Recovery e Cybersecurity sono due facce della stessa medaglia: un attacco ransomware che cripta i dati richiede sia procedure di sicurezza per bloccare l’attacco sia procedure di DR per ripristinarli dai backup. Il documento unico di pianificazione deve chiarire come le due procedure interagiscono durante una crisi ibrida.

Preparazione di una CTA Hard

La tua PA è realmente protetta?

Molti piani di disaster recovery restano solo sulla carta. I nostri consulenti certificati OFFRONO un audit gratuito di valutazione della resilienza per verificare se la tua documentazione tecnica è allineata agli standard NIS2 e PTIPA, e se gli obiettivi RTO/RPO sono realmente raggiungibili.

Richiedi una call di 15 minuti oggi stesso. Analizzeremo la tua situazione attuale e ti forniremo un rapporto preliminare sui punti critici.

Prenota la tua valutazione gratuita

Integrazione con l’ecosistema dei fornitori e SLA

La pianificazione non si esaurisce all’interno dell’ente. La maggior parte delle PA ha una catena di fornitura complessa. La documentazione del PdR deve includere la gestione del terzismo.

È necessario redigere degli allegati tecnici specifici per ogni fornitore critico (ISP, gestore cloud, software house). Questi documenti devono specificare:

1. Le SLA (Service Level Agreement) garantite in termini di disponibilità e tempi di risposta in caso di incidente.
2. Le procedure di notifica incrociata: chi chiama chi all’avvenuta di un evento critico?
3. Le specifiche tecniche per il ripristino: ad esempio, se il fornitore di connettività garantisce un failover automatico verso una rete di backup (es. fibra su anello anulare).

Un errore comune è la mancanza di monitoraggio proattivo che attivi il piano di DR. La documentazione deve definire gli trigger automatici (es. “Se il monitoraggio rileva 10 minuti di inattività del database principale, invia alert al team DR e avvia lo script di failover”) e quelli manuali (es. “Allerta da parte di un cittadino sull’impossibilità di accedere al servizio online”).

Checklist di Sintesi per la Documentazione

Per verificare che la fase di pianificazione sia completa, la documentazione finale deve rispondere affermativamente a questi punti:

• È stata effettuata una Business Impact Analysis (BIA) aggiornata?
• Sono stati definiti RTO e RPO per ogni sistema critico?
• Il piano prevede una gerarchia di ripristino (cosa ripristinare per prima)?
• Esiste un piano di comunicazione di crisi?
• Le responsabilità sono chiaramente assegnate e i contatti sono aggiornati?
• Il piano è stato testato (failover) nelle ultime 12 mesi?
• Il piano è conforme al PTIPA e alle direttive sulla resilienza dei servizi pubblici?

In conclusione, la pianificazione e documentazione del Piano di Disaster Recovery per le PA non è un esercizio accademico, ma un atto di responsabilità istituzionale. Garantire che i servizi essenziali continuino a erogarsi anche di fronte a guasti tecnici o attacchi informatici significa tutelare la continuità democratica e i diritti dei cittadini. Un documento ben strutturato, testato e aggiornato è la miglior assicurazione contro l’incertezza del futuro digitale.

Struttura del Piano: da strategico a operativo

Struttura del Piano: da strategico a operativo

Un piano di Disaster Recovery (DR) efficace per la PA non si limita a liste di contatti o procedimenti tecnici, ma si articola su tre livelli distinti ma interconnessi.

• Livello Strategico: Definisce la visione d’insieme. Qui si stabiliscono gli obiettivi di business, la tolleranza al rischio e i requisiti normativi (come il NIS2). Si identificano le applicazioni mission-critical e si stabiliscono i Recovery Time Objective (RTO) e Recovery Point Objective (RPO) massimi accettabili, allineandoli alle risorse disponibili.
• Livello Tattico: Traduce la strategia in architettura. Si sceglie il sito di ripristino (secondario, cloud o misto), si pianificano le procedure di sincronizzazione dei dati e si definiscono i requisiti di banda. In questa fase si valuta il budget per infrastrutture e licenze e si pianificano i test di simulazione (es. simulazione di attacco ransomware).
• Livello Operativo: È il “cosa fare” in emergenza. Contiene procedure passo-passo per il failover, checklist per l’attivazione del team di crisi, flussi di comunicazione interni ed esterni e schemi di rollback. È il documento pratico che il personale tecnico deve seguire ore o minuti dopo l’incidente per ripristinare i servizi.

La chiave è la coerenza: ogni livello deve alimentare il successivo, garantendo che le decisioni strategiche siano traducibili in azioni operative efficaci.

Definizione dei Ruoli e delle Responsabilità (SIRT di ateneo, RAO)

La gestione efficace di un incidente di sicurezza informatica in un contesto PA richiede una definizione precisa dei ruoli e delle responsabilità, per evitare ambiguità operativa e garantire una risposta coordinata.

Al centro del modello operativo c’è il SIRT (Security Incident Response Team) di ateneo. Questo team interdisciplinare, composto da figure tecniche, legali e della comunicazione, è responsabile della gestione tecnica e tattica dell’incidente: analisi, contenimento, eradicazione e ripristino. Il SIRT agisce in prima linea, avviando il Disaster Recovery Plan e monitorando l’evoluzione della minaccia.

A livello strategico, il Responsabile dell’Assetto Organizzativo (RAO)

Questo modello a due livelli garantisce che la risposta tecnica sia rapida e informata, mentre le decisioni strategiche sono ponderate secondo una visione d’insieme. Una definizione chiara dei ruoli non è solo una best practice, ma un requisito normativo per garantire trasparenza, tracciabilità e una ripresa operativa il più possibile fluida dopo un evento critico.

Procedure di comunicazione e gestione delle crisi (PR)

Procedure di comunicazione e gestione delle crisi (PR)

In caso di incidente informatico, la gestione della comunicazione è cruciale per preservare la reputazione e la fiducia. Le procedure PR devono essere integrate nel piano di Disaster Recovery (DR) e testate regolarmente.

• Definizione dei ruoli e delle responsabilità: Designare un crisis manager e un portavoce autorizzato. Tutte le comunicazioni esterne devono passare attraverso canali ufficiali.
• Interlocutori interni ed esterni: Mappare i stakeholder (dipendenti, utenti, partner, autorità, stampa) e definire per ognuno i messaggi chiave, i tempi di risposta e i canali di comunicazione preferenziali.
• Comunicazione agli utenti: Fornire informazioni trasparenti, tempestive e non tecniche. Indicare il problema, l’impatto previsto e le azioni in corso, evitando speculazioni non verificate.
• Comunicazione interna: Mantenere i dipendenti informati per prevenire il disorientamento e garantire che possano fornire un servizio coerente ai clienti.
• Monitoraggio e aggiornamento: Utilizzare strumenti di social listening per monitorare la conversazione pubblica e rispondere rapidamente a domande e preoccupazioni.
• Comunicazione post-incidente: Pubblicare un post-mortem trasparente (dove appropriato) che spieghi le cause, le lezioni apprese e le misure adottate per prevenire futuri eventi.

Un piano di comunicazione ben strutturato non solo gestisce la crisi in atto, ma rafforza la resilienza dell’organizzazione. Per sviluppare protocolli PR su misura per la tua PA, contatta i nostri esperti per una consulenza.

Fasi di Attivazione e Ripristino (Failover e Failback)

Fasi di Attivazione e Ripristino (Failover e Failback)

L’obiettivo del piano di disaster recovery (DR) non è solo disporre di un piano cartaceo, ma attivare procedure operative chiare, testate e ripetibili che minimizzino i tempi di downtime. Quando si verifica un incidente critico – come un guasto hardware, un attacco ransomware o un’interruzione prolungata dei servizi – le fasi di attivazione e ripristino diventano il cuore della resilienza operativa della Pubblica Amministrazione. In questa sezione esploriamo le dinamiche del failover (passaggio di emergenza) e del failback (rientro controllato), con un focus pratico su tempistiche, responsabilità e azioni concrete.

Fase 1: Rilevamento e dichiarazione dell’evento

La prima linea di difesa è il sistema di monitoraggio proattivo. Non si tratta di guardare semplicemente se i server sono “on” o “off”, ma di identificare anomalie di performance, tentativi di intrusione o cambiamenti nello stato di salute dei servizi.

• Trigger di allarme: utilizzare soglie predefinite (es. CPU > 90% per 5 minuti, perdita di connettività verso il sito primario, fallimento di backup consecutivi).
• Verifica immediata: prima di dichiarare un disastro, il team di operazioni IT (o il fornitore certificato) deve validare l’evento con almeno due fonti indipendenti (es. ping e log di sistema) per evitare falsi positivi.
• Dichiarazione formale: un referente designato (tipicamente il CISO o il responsabile IT) emette la dichiarazione di “Disaster Triggered”, attivando di fatto il piano di DR. Questo momento è critico perché segna l’inizio del contatore dei tempi di RTO (Recovery Time Objective).

Esempio pratico: Un attacco ransomware cripta i dati di un database di anagrafe. Il sistema di backup differenziale segnala l’incoerenza dei dati. Il team IT verifica la compromissione, dichiara l’evento e avvia la procedura di failover al sito di disaster recovery (DR).

Fase 2: Attivazione del Failover (Passaggio al sito secondario)

Il failover consiste nel trasferire la continuità operativa dal sito primario (danneggiato o irraggiungibile) al sito di backup. L’obiettivo è ripristinare i servizi nel minor tempo possibile, anche a scapito di performance ridotte.

1. Verifica prerequisiti: prima di avviare il failover, controllare che il sito secondario sia in stato “standby” pronto, che le ultime replicazioni dei dati siano complete (RPO – Recovery Point Objective) e che le risorse computazionali siano sufficienti.
2. Avvio sequenziale dei servizi: non riavviare tutto contemporaneamente. Seguire una gerarchia definita:
   • Infrastruttura critica (DNS, directory services, autenticazione).
   • Servizi core per i cittadini (portali istituzionali, servizi di pagamento, booking appuntamenti).
   • Servizi interni (ERP, gestione documentale, posta elettronica).
3. Riconfigurazione dei punti di accesso: aggiornare i DNS (TTL basso pre-failover), i firewall, i certificati SSL e eventuali load balancer per instradare il traffico verso il sito secondario.
4. Test di funzionalità minimale: eseguire un set di test di regressione predefiniti per verificare che i servizi siano operativi. Non è necessaria la perfezione, ma la funzionalità base.

Tempistica indicativa: per un sito PA di medie dimensioni, il failover dovrebbe essere completato entro 2-4 ore, a seconda della complessità dell’ambiente. Se si supera l’RTO definito, è necessario attivare il Comitato di Crisi per comunicazioni esterne.

Fase 3: Operazioni in modalità Disaster Recovery

Una volta completato il failover, l’organizzazione opera in modalità DR. È fondamentale mantenere la tracciabilità di tutte le azioni.

• Monitoraggio intensivo: il sito secondario potrebbe avere performance inferiori o risorse limitate. È cruciale monitorare costantemente l’utilizzo di CPU, RAM e storage per prevenire nuovi disservizi.
• Comunicazione continua: il responsabile della comunicazione istituzionale deve informare dipendenti, cittadini e stakeholder con aggiornamenti periodici (es. ogni 2 ore). Utilizzare canali alternativi (social, SMS, radio) se la comunicazione digitale primaria è compromessa.
• Documentazione live: tutte le modifiche, decisioni e incidenti secondari devono essere registrati in un log condiviso (es. confluence, SharePoint o addirittura un foglio di calcolo condiviso in cloud). Questo è essenziale per il successivo report di post-mortem e per eventuali audit di controllo.

Fase 4: Analisi e preparazione al Failback

Il failback (rientro al sito primario) è la fase più delicata e spesso trascurata. Non è un semplice riavvio, ma una migrazione pianificata dei dati e dei servizi.

1. Valutazione del danno: prima di pianificare il rientro, il team di forensics digitale (o il fornitore certificato) deve stabilire la causa root del guasto e verificare che il sito primario sia “pulito” e sicuro. Se si tratta di un attacco, è necessario applicare patch, cambiare credenziali e validare l’integrità di tutti i sistemi.
2. Ricostruzione vs. Ripristino: in caso di danno hardware irreparabile, potrebbe essere necessario ricostruire l’ambiente primario da zero (Rebuild) piuttosto che ripristinare da backup (Restore). Questa decisione impatta i costi e i tempi.
3. Preparazione dei dati: i dati prodotti durante il periodo in DR (es. nuovi record di anagrafe, transazioni di pagamento) devono essere sincronizzati verso il sito primario. Questo processo richiede attenzione per evitare conflitti o perdite di informazioni.

Fase 5: Esecuzione del Failback

Il failback deve essere eseguito in orari di basso traffico (di notte o nel weekend) per minimizzare l’impatto sugli utenti.

1. Stop delle attività in DR: comunicare l’intervallo di manutenzione e bloccare temporaneamente l’inserimento di nuovi dati nel sistema secondario.
2. Sincronizzazione finale: eseguire l’ultima replicazione dei dati verso il sito primario. Verificare l’integrità dei dati con checksum e test di consistenza.
3. Avvio del sito primario: riattivare l’infrastruttura primaria in modalità “isolata” (senza traffico esterno). Eseguire test di integrazione e performance.
4. Riconfigurazione del traffico: aggiornare i DNS e i punti di ingresso per riindirizzare gradualmente il traffico verso il sito primario (strategia di “canary release” o blue/green deployment).
5. Monitoraggio post-failback: osservare attentamente il comportamento dei sistemi per le prime 24-48 ore per identificare eventuali anomalie.

Errore comune da evitare: non pianificare il failback e operare indefinitamente in DR. Questo aumenta i costi operativi (doppia licenza, doppia banda) e il rischio di degradazione dei servizi.

Checklist operativa (Esempio)

• [ ] Dichiarazione di Disaster avvenuta? (Sì/No)
• [ ] RTO/RPO target verificati? (Tempo stimato: 4 ore / 15 minuti)
• [ ] Sito secondario pronto? (Risorse allocate: CPU 80%, RAM 70%)
• [ ] Ultimo backup valido? (Timestamp: GG/MM/AAAA HH:MM)
• [ ] Piano di comunicazione attivato? (Responsabile: Nome Cognome)
• [ ] Log di evento avviato? (Posizione: Cloud Drive / Confluence)
• [ ] Test di failover eseguito nell’ultimo trimestre? (Risultato: Superato)

Consiglio finale: Le fasi di attivazione e ripristino sono essenzialmente un esercizio di gestione del cambiamento. La tecnologia è abilitante, ma il successo dipende dalla preparazione del personale, dalla chiarezza dei ruoli e dalla capacità di adattarsi a scenari imprevisti. Per questo motivo, Culture Digitali Srl raccomanda l’esecuzione di drill semestrali, simulando scenari realistici per testare non solo le procedure tecniche, ma anche la catena di comando e le procedure di comunicazione.

Trigger di attivazione: rilevamento e classificazione dell’incidente

Il Disaster Recovery per la Pubblica Amministrazione non parte in modo arbitrario, ma è attivato da segnali precisi che indicano un’anomalia critica. Il primo passo è la rilevamento dell’incidente, ovvero l’identificazione di un evento che minaccia la continuità operativa: un guasto hardware, un attacco ransomware, una perdita di dati, un’interruzione di servizi cloud o un disastro naturale.

Per una PA, è fondamentale che questo rilevamento sia automatico e contestualizzato. Non basta accorgersi che un server è giù: bisogna capire l’impatto su servizi critici come l’anagrafe, le casse comunali o le piattaforme telematiche. A questo scopo, si utilizzano soluzioni di monitoraggio continuo (Nagios, Zabbix, o strumenti cloud-based) e sistemi di Security Information and Event Management (SIEM) che aggregano log e allarmi da tutta l’infrastruttura IT.

Una volta rilevato, l’evento deve essere sottoposto a classificazione seguendo criteri definiti nel Piano di Disaster Recovery. La classificazione avviene tipicamente su due assi principali:

• Severità (gravità): L’incidente è minore (un singolo utente non accede), moderato (un intero ufficio è bloccato) o critico (il sistema centrale di raccolta tributi è inattivo)?
• Urgenza (tempo di intervento): Quanto rapidamente il servizio deve essere ripristinato? Qui si fa riferimento agli SLA (Service Level Agreement) e agli RTO (Recovery Time Objective) e RPO (Recovery Point Objective) definiti a priori.

Questo processo standardizzato permette di dare priorità alle risorse, evitando il caos e garantendo che la risposta sia proporzionata al reale impatto sulle funzioni amministrative e sui cittadini.

Procedura step-by-step per il Failover al sito secondario

Procedura step-by-step per il Failover al sito secondario

Per garantire una transizione rapida e ordinata al sito secondario, è fondamentale seguire un protocollo preciso e testato. Di seguito una procedura operativa pratica, utile per le amministrazioni pubbliche.

1. Attivazione allerta e decisione (0-15 minuti): L’Organismo di Gestione della Crisi (OGC) dichiara l’emergenza e autorizza il passaggio a Disaster Recovery. Si notifica immediatamente il provider di infrastruttura per l’attivazione formale del piano.
2. Sincronizzazione dati e integrità (15-45 minuti): Il team tecnico verifica l’ultimo checkpoint dei dati replicati. Si esegue un controllo di integrità (checksum) per confermare che la replica secondaria sia coerente e non corrotta.
3. Switch DNS e pubblicazione indirizzi (45-60 minuti): Si aggiornano i record DNS (A/CNAME) puntando al sito secondario. Si abbassa il TTL (Time To Live) giorni prima dell’evento per accelerare la propagazione globale. È prassi comune mantenere una pagina di maintenance informativa durante questa fase.
4. Verifica applicativa e onboarding (60-90 minuti): Una volta che il DNS si è propagato, il team esegue test funzionali critici:
   • Accesso agli uffici digitali e portali cittadini.
   • Elaborazione di pratiche telematiche.
   • Integrazione con servizi esterni (PagoPA, SPID/CIE, anagrafi).
5. Comunicazione e monitoraggio (Ongoing): Si comunica il rientro del servizio agli utenti e ai dipendenti. Si attiva il monitoraggio mirato sul sito secondario per individuare eventuali colli di bottiglia da ottimizzare immediatamente.

Il ritorno alla normalità (Failback) e validazione dell’integrità

Il ritorno alla normalità (Failback) e validazione dell’integrità

Il ripristino della normale operatività (failback) richiede un approccio metodologico per evitare la perdita di dati e garantire la continuità del servizio. Dopo aver verificato la stabilità dell’ambiente primario, si procede trasferendo i carichi di lavoro dal sito di disaster recovery al sito primario.

Il processo si articola in fasi specifiche:

• Validazione preliminare: esecuzione di test di integrità sui dati replicati (checksum e log di trasferimento).
• Sincronizzazione finale: blocco delle scritture sul DR e trasferimento dell’ultimo blocco di dati differenziale.
• Riattivazione dei servizi: avvio progressivo dei servizi applicativi, controllando la compatibilità delle versioni.
• Verifica funzionale: test di integrazione e carico per confermare che tutti i flussi operativi funzionino correttamente.

Checklist Validazione Integrità Dati

• Confronto hash dei database primario e secondario.
• Verifica della completezza dei log di transazione.
• Esecuzione di query di consistenza su dataset critici.
• Monitoraggio dei tempi di risposta dei servizi ripristinati.

Completata la fase di validazione, si disattivano i servizi di emergenza e si comunica formalmente il rientro alla normale operatività al management e agli utenti.

Rete, Infrastruttura e Sicurezza per la Business Continuity

Rete, Infrastruttura e Sicurezza per la Business Continuity

Il concetto di business continuity per le PA non si limita alla semplice disponibilità dei server o alla riparazione di un guasto tecnico. Si tratta di garantire la continuità operativa dei servizi essenziali per i cittadini e le imprese, anche in condizioni di stress estremo. Questo richiede un approccio strategico che integri la rete, l’infrastruttura IT e la sicurezza informatica in un unico ecosistema resiliente. Senza una base tecnologica solida, ogni piano di disaster recovery rischia di essere una mera dichiarazione d’intenti, incapace di resistere a un attacco informatico coordinato o a un guasto catastrofico.

Per le Pubbliche Amministrazioni, la resilienza parte dalla consapevolezza che la digitalizzazione ha spostato il baricentro dell’operatività su asset fisici e logici interconnessi. Un downtime non è solo un arresto dei sistemi, ma una sospensione del servizio pubblico. Ecco perché la progettazione dell’infrastruttura deve seguire il principio di defense in depth (difesa in profondità), dove ogni livello della pila tecnologica (rete, sistemi, dati, applicazioni) è protetto da meccanismi di sicurezza redundanti e controlli di accesso rigorosi.

Network Resilience: dalla Connettività alla Segmentazione

La rete è il sistema ciratorio della PA. Se il flusso di dati si interrompe, l’organismo entra in collasso. Una strategia di business continuity efficace inizia con l’architettura di rete. Non basta avere una connessione internet veloce; serve una architettura ridondante.

Il primo step è l’implementazione di due o più provider di accesso (ISP) con tecniche di load balancing e failover automatico. Se il primario va offline, il traffico deve essere reindirizzato istantaneamente verso il secondario senza interruzione per l’utente finale. Tuttavia, la vera sicurezza risiede nella segmentazione della rete interna.

• DMZ (Demilitarized Zone): Per i servizi esposti al pubblico (portali web, app cittadine), è essenziale collocarli in una zona demilitarizzata separata dalla rete interna aziendale. Questo impedisce che una vulnerabilità su un server web comprometta l’intera infrastruttura dati.
• VLAN e Micro-segmentazione: Separare il traffico per funzioni (es. rete server, rete workstation, rete VoIP, rete dispositivi IoT) limita la propagazione di malware. Un incidente in una VLAN non deve propagarsi alle altre.
• SD-WAN (Software-Defined Wide Area Network): Per le PA con sedi decentrate (uffici periferici, scuole, presidi sanitari), l’SD-WAN offre una gestione centralizzata della banda, ottimizzando il routing del traffico critico e garantendo crittografia end-to-end.

Un errore comune è trascurare la banda di upload. Molti piani di disaster recovery prevedono il ripristino da cloud, ma se la connessione in uplink è insufficiente, il trasferimento dei dati di backup può richiedere giorni, superando il Recovery Time Objective (RTO) prefissato.

Infrastruttura Ibrida e Hyperconvergente

L’infrastruttura fisica e virtuale deve essere progettata per tollerare i guasti. Il modello tradizionale (bare metal + macchine virtuali monolitiche) sta lasciando spazio a soluzioni più flessibili e resilienti.

Infrastruttura Ibrida (On-premise + Cloud):
Il modello ibrido è il compromesso ideale per le PA. I dati sensibili o ad alto livello di confidenzialità possono risiedere su server locali (on-premise), garantendo il controllo diretto sulla sovranità dei dati, mentre carichi di lavoro non critici o backup off-site vengono ospitati su cloud pubblici certificati (es. Cloud Italia o provider con data center in UE). Questo approccio permette di sfruttare l’elastictà del cloud per il Disaster Recovery as a Service (DRaaS), attivando ambienti di standby in pochi minuti invece di ricostruirli da zero.

Convergenza Iperconvergente (HCI):
Le soluzioni HCI (come Nutanix, VMware vSAN o soluzioni open source come Proxmox) combinano storage, calcolo e networking in un unico stack gestito software. Per una PA, l’HCI offre due vantaggi fondamentali per la continuità:

1. High Availability (HA): Se un nodo fisico si guasta, le macchine virtuali che ospitavano vengono ripristinate automaticamente sugli altri nodi del cluster. Il tempo di inattività è quasi nullo.
2. Semplificazione della replica: La replica asincrona dei dati verso un secondo sito (disaster recovery site) è integrata nella piattaforma, riducendo la complessità operativa.

Infine, l’Edge Computing sta diventando cruciale. Per le PA che gestiscono dispositivi IoT (sensori ambientali, intelligent lighting, videosorveglianza), elaborare i dati “al bordo” della rete riduce la latenza e, in caso di interruzione del collegamento verso il data center centrale, permette al sistema locale di operare in autonomia temporanea.

Sicurezza Informatica: Monitoraggio, Rilevamento e Risposta

L’infrastruttura di sicurezza non è più solo un firewall perimetrale. È un sistema dinamico di rilevamento e risposta. Per garantire la business continuity, la sicurezza deve essere proattiva, non reattiva.

SOC e SIEM (Security Operations Center & Security Information and Event Management):
Centralizzare i log di rete, server, database e dispositivi in un sistema SIEM è obbligatorio. Un SOC dedicato (interno o gestito da partner certificati) analizza questi dati 24/7 per individuare anomalie. La differenza tra un incidente gestito e un disastro sta nei tempi di rilevamento (Mean Time to Detect – MTTD). Un SIEM ben configurato può isolare una workstation infetta prima che il ransomware cifri l’intero NAS di backup.

Zero Trust Architecture:
Il modello “fidati ma verifica” è superato. Il principio Zero Trust assume che la rete sia già compromessa. Ogni accesso, interno o esterno, richiede autenticazione forte (MFA), controllo dell’integrità del dispositivo e privilegi minimi necessari (Least Privilege). Questo è vitale per le PA che gestiscono dati personali e sanitari. Se un account amministrativo viene compromesso, l’architettura Zero Trust limita i danni impedendo l’accesso a risorse non necessarie.

Protezione degli Endpoint e Backup Immutabili:
I ransomware moderni attaccano prima i backup per rendere impossibile il ripristino. La soluzione sono i backup immutabili (o WORM – Write Once Read Many). Una volta scritti, i dati di backup non possono essere modificati o cancellati per un periodo prestabilito, neanche da un utente con privilegi di amministratore. Questo garantisce che, in caso di attacco, esista sempre una copia pulita dei dati su cui tornare.

Inoltre, le PA devono adottare strumenti di EDR (Endpoint Detection and Response) sui PC e server. A differenza degli antivirus tradizionali, gli EDR analizzano il comportamento dei processi. Se un utente apre un file macro malevolo che tenta di disabilitare l’antivirus o eseguire comandi PowerShell sospetti, l’EDR blocca l’attività e isola il terminale.

Strumenti Operativi per la Business Continuity

La teoria si traduce in pratica attraverso strumenti specifici che garantiscono la continuità operativa:

1. RPO e RTO Definiti: È impossibile garantire zero downtime. La PA deve definire i Recovery Point Objective (RPO), ovvero la perdita di dati massima tollerabile (es. 15 minuti), e i Recovery Time Objective (RTO), il tempo massimo per ripristinare il servizio (es. 4 ore). Questi valori guidano le scelte tecnologiche (es. backup ogni 15 minuti vs. giornalieri).
2. Virtualizzazione e Snapshot: Utilizzare tecnologie di snapshot frequenti (every 1-4 hours) permette di ripristinare interi server in minuti, eliminando la necessità di reinstallare sistemi operativi da zero.
3. DRaaS (Disaster Recovery as a Service): Per le PA con budget limitati per un secondo data center fisico, il DRaaS è la soluzione. Il provider gestisce l’infrastruttura di backup nel cloud. In caso di disastro, basta un click per “accendere” la replica del data center nel cloud e dirottare il traffico.
4. Geo-Redundancy: I dati devono essere replicati in aree geografiche diverse. Se un terremoto o un guasto alla rete nazionale colpisce la regione A, i dati devono essere disponibili nella regione B.

Checklist Operativa: Verifiche Trimestrali

Un piano di disaster recovery non scritto è carta straccia. Per essere efficace, deve essere testato costantemente.

• Test di Ripristino Parziale: Ogni trimestre, ripristinare un singolo server critico o un database di test per verificare l’integrità del backup e la velocità di recupero.
• Penetration Test e Vulnerability Assessment: Scansionare l’infrastruttura alla ricerca di vulnerabilità note (CVE) e testare la resistenza agli attacchi simulati.
• Simulazioni di Tabletop: Coinvolgere il personale IT e i responsabili dei servizi in simulazioni cartacee di incidenti (es. “Il data center è allagato”). Questo allinea le procedure tecniche con quelle organizzative.
• Aggiornamento degli inventari: Mantenere un registro aggiornato di hardware, software, licenze e dipendenze critiche (Service Dependency Map). Non si può ripristinare ciò che non si sa esistere.

Integrazione con il Personale e la Formazione

La tecnologia è inutile senza persone competenti. L’elemento umano è spesso il punto debole (es. phishing) ma anche la risorsa più preziosa durante una crisi.

Oltre alla formazione tecnica per gli amministratori di sistema, è cruciale formare il CERT (Computer Emergency Response Team) interno. Questo team multidisciplinare (IT, legale, comunicazione, dirigenti) deve sapere esattamente chi attivare e quali procedure seguire al verificarsi di un incidente. La comunicazione con i cittadini durante un downtime è fondamentale per mantenere la fiducia; l’infrastruttura deve prevedere canali di comunicazione alternativi (es. sistemi di messaggistica SMS o social media gestiti da un’infrastruttura separata) nel caso il portale web principale sia irraggiungibile.

Investire in una robusta infrastruttura di rete, un’architettura ibrida resiliente e una sicurezza proattiva non è un costo, ma un investimento nella continuità del servizio pubblico. Per le PA, garantire la business continuity significa garantire i diritti dei cittadini, anche nel mezzo di una crisi.

Per un’analisi personalizzata della tua infrastruttura e per ricevere una consulenza su come implementare una strategia di Disaster Recovery conforme alle normative vigenti, contatta oggi stesso i nostri esperti di Culture Digitali Srl.

Redondanza di connettività e gestione dei BGP per le PA

Redondanza di connettività e gestione dei BGP per le PA

Per una Pubblica Amministrazione, la continuità operativa dipende essenzialmente dalla disponibilità della connettività di rete. Un singolo guasto sul collegamento verso l’esterno (fornitore, data center) può bloccare l’erogazione di servizi digitali fondamentali come il portale SPID, le piattaforme di acquisto MePA o i servizi di back-office. La soluzione tecnica è la ridondanza di connettività, ovvero l’utilizzo di due o più link fisicamente separati verso due fornitori diversi. Questa configurazione garantisce che, in caso di interruzione di una linea, il traffico sia automaticamente reindirizzato sull’altra, mantenendo attivi i servizi essenziali. Il cuore di questo meccanismo è il protocollo BGP (Border Gateway Protocol), il sistema di routing che “decide” il percorso migliore per i dati. Una configurazione BGP avanzata per la PA non si limita a un semplice failover passivo, ma implementa strategie di bilanciamento del carico (load balancing) per utilizzare entrambe le connettività contemporaneamente, ottimizzando le prestazioni. È cruciale, inoltre, che la configurazione BGP sia progettata per essere multi-homed, ovvero indipendente dal provider specifico, e che preveda meccanismi di prevenzione dei loop e di filtraggio dei prefissi, proteggendo l’infrastruttura da errori di configurazione che potrebbero compromettere la raggiungibilità dei servizi.

Cybersecurity nella DR: protezione dei backup (immutabilità)

Nell’ambito del Disaster Recovery per la PA, la semplice disponibilità dei backup non basta: deve essere garantita l’integrità dei dati. Un rischio emergente è il ransomware, che oggi non cifra solo il primario, ma mira a criptare o cancellare anche le copie di sicurezza, rendendo la ripristino impossibile. Per neutralizzare questa minaccia, l’elemento critico è l’immutabilità dei backup.

L’immutabilità è una proprietà dei dati che impedisce la modifica, la cancellazione o la sovrascrittura per un periodo di tempo definito, nemmeno da parte di amministratori o ransomware. I formati come il WORM (Write Once, Read Many) e le politiche di retention blocche rendono ogni punto di backup una “fotografia” inalterabile. Questo approccio è fondamentale per le PA, poiché garantisce la disponibilità dei dati di recovery in caso di attacco, anche se compromesso l’ambiente operativo. Altre misure essenziali includono la separazione logica e fisica dei backup (3-2-1 rule), l’utilizzo di account di servizio con privilegi minimi e un’adeguata segmentazione di rete per isolare le aree di backup.

La corretta implementazione dell’immutabilità, combinata con politiche di backup testate, è la chiave per una business continuity resilient e conforme a normative come il Regolamento (UE) 2019/881 (ENISA) e le linee guida del NIS2, riducendo drasticamente il rischio di downtime prolungato e perdita di dati critici.

Accesso sicuro ai sistemi in modalitá di crisi (Zero Trust)

Accesso sicuro ai sistemi in modalità di crisi (Zero Trust)

In un contesto di Disaster Recovery, garantire l’accesso ai sistemi critici senza compromettere la sicurezza è fondamentale. Il modello Zero Trust è ideale: parte dal presupposto che nessun utente o dispositivo sia intrinsecamente affidabile, a prescindere dalla sua posizione (interna o esterna alla rete aziendale). In modalità crisi, quando gli utenti possono accedere da dispositivi non gestiti o reti pubbliche, questo principio diventa cruciale.

Per implementare Zero Trust durante un incidente, è necessario:

• Autenticazione MFA forte: obbligare l’uso di fattori multipli (password + token o biometria) per ogni accesso.
• Micro-segmentazione: limitare i permessi al minimo indispensabile (principio del privilegio minimo), isolando i sistemi recuperati dalla rete generale.
• Controllo continuo dei dispositivi: verificare lo stato di sicurezza del dispositivo (patch, antivirus) prima di concedere l’accesso.
• Accesso condizionale: basare l’autorizzazione su parametri contestuali (posizione, orario, rischio percepito).

Questa approccio non solo protegge i dati durante la ripristino, ma riduce il rischio di compromissioni laterali, essenziale per mantenere la business continuity in caso di attacco informatico.

CTA: Valuta la tua preparazione

L’accesso non sicuro in crisi è il principale punto di debolezza. Ti offriamo una consulenza rapida (15 minuti) per analizzare la tua attuale strategia di accesso e come renderla Zero Trust.

Test e Manutenzione del Piano di Disaster Recovery

Test e Manutenzione del Piano di Disaster Recovery: L’Unica Via per la Business Continuity

Un piano di Disaster Recovery (DR) scritto e archiviato in un cassetto è, a tutti gli effetti, un piano inutile. Nel caos di un incidente reale – un attacco ransomware, un guasto hardware critico, un errore umano – le procedure teoriche spesso si rivelano fragili. L’unica garanzia di business continuity per la PA risiede nella validazione costante del piano attraverso test rigorosi e nella sua manutenzione attiva. Senza questi due pilastri, la resilienza operativa resta un’aspirazione, non una realtà.

Perché il Test Non è Opzionale

Molti enti pubblici commettono l’errore di considerare il test del DR un evento annuale da “spuntare in lista”. In realtà, è un processo continuo che simula la complessità del mondo reale. Un test ben strutturato non verifica solo la tecnologia, ma anche la reattività umana, la chiarezza delle procedure e la capacità di comunicare efficacemente sotto stress.

Esempio pratico: Un comune medio ha simulato un attacco ransomware che ha cifrato i server di database. Durante il test, si è scoperto che la procedura di ripristino dal backup richiedeva l’accesso fisico al locale server, situato in una sede decentrata, non disponibile di notte o nel weekend. Il tempo di ripristino (RTO) previsto di 2 ore è diventato 12, vanificando l’obiettivo di business continuity. Questo solo grazie al test.

Tipologie di Test per la Pubblica Amministrazione

• Desktop Simulation (Walkthrough): Sessioni di discussione basate su scenari predefiniti. Ideali per allineare i team su ruoli e responsabilità senza toccare l’infrastruttura. Obiettivo: Verificare la comprensione del piano e la catena di comando.
• Test di Integrazione Parziale: Si avvia l’ambiente DR in isolamento (lato rete) per testare la sincronizzazione dei dati e l’accesso alle applicazioni critiche (es. portale cittadino, gestione anagrafica). Non si interrompe la produzione.
• Failover Reale (Full Switch): Il test più completo. Si interrompe deliberatamente il sito primario e si trasferisce il carico di lavoro al sito DR. È il solo modo per misurare tempi di recupero reali (RTO) e perdita di dati accettabile (RPO). Nota: Richiede una finestra di manutenzione concordata con gli utenti.

Quanto è resiliente la tua PA?

Un test ben progettato rivela criticità che l’analisi teorica non può catturare. Scopri se la tua organizzazione è pronta a gestire un incidente critico senza interruzioni prolungate dei servizi.

Prenota una sessione di discovery per il tuo piano DR

Manutenzione: Un Processo Dinamico, Non Statico

Il piano di Disaster Recovery è un documento vivo che deve evolvere con l’infrastruttura IT, le minacce informatiche e le normative. Una manutenzione trascurata porta rapidamente a un obsolescenza pericolosa. Le regole fondamentali sono:

• Aggiornamento dopo ogni cambiamento infrastrutturale: Nuovi server, migrazione cloud, introduzione di SaaS. Ogni modifica richiede un re-engineering del piano DR.
• Revisione delle procedure di comunicazione: I contatti cambiano. La lista di distribuzione per l’allerta deve essere verificata ogni 3 mesi.
• Adattamento al panorama delle minacce: Le tattiche degli attaccanti evolvono (es. doppia estorsione ransomware). Il piano deve includere protezioni per la reputazione e la gestione dei dati sensibili.
• Aggiornamento degli RTO/RPO: I requisiti di business cambiano. Un servizio prima considerato “non critico” potrebbe esserlo diventato. Le soglie devono essere ricalibrate.

Il Ruolo della Documentazione e del Registro delle Modifiche

Mantenere traccia di ogni aggiornamento è fondamentale per la compliance (es. NIS2, GDPR) e per l’audit. Un semplice registro cronologico che annoti data, autore, motivazione e impatto di ogni modifica al piano DR garantisce trasparenza e auditabilità.

Criteri di Frequenza e Automazione

La frequenza dei test dipende dalla criticità del servizio e dalla complessità dell’ambiente. Tuttavia, l’automazione è il fattore abilitante per una manutenzione sostenibile.

• Test di integrazione continui: Script automatizzati che verificano giornalmente la connettività verso il sito DR e l’integrità dei backup.
• Scenario-based testing: Esecuzione semestrale di scenari specifici (es. guasto storage, perdita connettività WAN) su ambienti pre-produttivi.
• Failover annuale obbligatorio: Obbligatorio per servizi critici, preferibilmente in orari a basso impatto operativo.

Hai dubbi sulle tempistiche di ripristino?

Definire obiettivi realistici di RTO e RPO è il primo passo per un piano DR efficace. Valutiamo insieme l’adeguatezza delle tue tempistiche rispetto alla business continuity della tua amministrazione.

Richiedi un’analisi delle criticità

Errore Comune: Testare solo l’infrastruttura, non le persone

Il problema: Molti enti si concentrano esclusivamente sulla tecnologia (backup, replicazione, failover) trascurando l’elemento umano. Spesso manca una chiara definizione dei ruoli durante l’emergenza (chi attiva il piano? chi comunica con i cittadini? chi gestisce i media?).

Come evitarlo: Inserire nei test specifici esercitazioni di ruolo (Role-Playing). Simulare comunicazioni di crisi, interazioni con il Sindaco o con gli uffici stampa. Assicurarsi che tutti i responsabili conoscano le procedure di attivazione e abbiano accesso ai documenti di crisi anche offline.

Costi, Tempi e Complessità della Manutenzione DR

Investire nel test e nella manutenzione ha un costo, ma è infinitamente inferiore al costo di un downtime prolungato o di una violazione dei dati.

• Costi diretti (Bassa/Media complessità): Ore-uomo interne per la pianificazione ed esecuzione dei test. Strumenti di automazione (es. soluzioni di DRaaS – Disaster Recovery as a Service) possono ridurre drasticamente il carico manuale.
• Costi indiretti (Bassa complessità): Possibile breve fermo servizio durante i test di failover (se non ben orchestrato). Costo reputazionale se il test fallisce e diventa pubblico (rischio mitigato con una comunicazione interna trasparente).
• Complessità (Alta): Dipende dall’eterogeneità delle applicazioni legacy tipiche della PA e dalla distribuzione geografica delle sedi. Ambienti ibridi (on-premise + cloud) richiedono orchestratori specifici per garantire coerenza durante il ripristino.

Nota: Il risparmio evitando i test porta a costi esponenziali in caso di incidente reale. Una soluzione DRaaS gestita può trasformare costi fissi in costi operativi (OpEx) scalabili.

Checklist Rapida: Strumenti per il CTO della PA

Prima di chiudere il capitolo, ecco una mini-lista per avviare subito il miglioramento del tuo piano DR. Segui questi passaggi per mettere a fuoco le criticità immediate:

1. Rivedi l’ultima data di test: Se è passata più di 12 mesi, pianifica un nuovo scenario entro 30 giorni.
2. Verifica i contatti dell’emergency team: Chiama ogni responsabile per confermare disponibilità e canali alternativi.
3. Testa il ripristino di un singolo file critico: Non serve un failover totale. Verifica che il backup sia accessibile e integro.
4. Aggiorna il registro delle modifiche: Annota qualsiasi cambiamento avvenuto negli ultimi 6 mesi (software, hardware, procedure).
5. Valuta un backup offline o immutabile: Gli attacchi ransomware moderni cifrano anche i backup collegati in rete. Proteggi l’ultimo livello di difesa.

La business continuity non è un traguardo, ma un ciclo continuo di preparazione, test e miglioramento. Iniziare oggi con un semplice test di integrazione o una revisione dei contatti è il primo passo per garantire che, quando l’imprevisto accade, la tua PA continui a funzionare.

Tipologie di test: Desktop, Simulation, Full Failover

Tipologie di test: Desktop, Simulation, Full Failover

Garantire l’efficacia del piano di Disaster Recovery (DR) per la Pubblica Amministrazione richiede test regolari, ciascuno con un obiettivo specifico e un impatto diverso sull’operatività. Le tre modalità principali sono Desktop, Simulation e Full Failover.

• Test Desktop (Walkthrough): È un esame analitico e non operativo, condotto a tavolo con i partecipanti chiave (IT, legali, dirigenti). Si simulano scenari di crisi tramite domande e risposte per verificare la coerenza del piano, l’efficacia dei flussi comunicativi e la chiarezza dei ruoli. È un test “a freddo”, ideale per l’aggiornamento della documentazione e la formazione del personale senza interrompere i servizi.
• Test Simulation (Simulation): Prevede l’attivazione di componenti specifiche del sistema di DR in ambiente controllato, spesso in un’area di test isolata. Non coinvolge l’ambiente di produzione, ma permette di verificare tecnicamente la replicazione dei dati, il ripristino delle applicazioni e l’automazione degli script di recovery. È un test “a caldo” mirato a validare i componenti tecnici.
• Test Full Failover: È il test più completo e invasivo. Consiste nel disabilitare l’ambiente primario e trasferire completamente l’operatività (failover) verso il sito di DR, inclusi sistemi, dati e utenti finali. Dopo un periodo di verifica, si esegue il ripristino inverso (failback). Questo test valida la capacità dell’intera organizzazione di operare in modalità DR, ma richiede una pianificazione precisa e un’ampia finestra di manutenzione.

Budget e risorse: come pianificare i costi di test e aggiornamento

La pianificazione dei costi per il Disaster Recovery (DR) nella Pubblica Amministrazione non deve essere un ostacolo, ma un investimento strategico. Per garantire la business continuity, è fondamentale riservare una quota specifica del budget annuale a test di simulazione e aggiornamenti, evitando l’errore di considerarli spese una tantum.

Una strategia efficace prevede l’allocazione di risorse per tre attività chiave:

• Test di simulazione: allocare fondi per esercitazioni periodiche (es. annuali) per verificare l’efficacia del piano di DR. Questo costo copre le ore del personale IT e l’utilizzo di ambienti di test.
• Aggiornamento tecnologico: riservare una percentuale del budget IT (solitamente tra il 10% e il 15%) per l’aggiornamento di software, licenze e infrastrutture di backup, garantendo la compatibilità con le nuove minacce cyber.
• Formazione del personale: investire in corsi di aggiornamento per gli amministratori di sistema e i responsabili della sicurezza, fondamentali per gestire correttamente gli strumenti di DR.

È consigliabile utilizzare framework come il TCO (Total Cost of Ownership) per valutare non solo i costi diretti, ma anche quelli indiretti (fermo macchina, perdita di dati). In questo modo, si giustifica l’investimento dimostrando il rapporto costo-beneficio di una continuità operativa garantita.

CTA Soft: Per valutare i costi specifici per la tua PA, scarica la nostra checklist gratuita per il calcolo del budget DR.

Ciclo di vita del Piano e aggiornamento post-incidente

Il Piano di Disaster Recovery (PDR) non è un documento statico ma un ciclo continuo. Dopo ogni incidente (o esercitazione) è fondamentale avviare una fase di aggiornamento e miglioramento. L’analisi post-incidente (Post-Incident Review) deve catturare le lezioni apprese: cosa ha funzionato, cosa ha fallito, tempi di ripristino reali vs. target.

Questi dati alimentano l’aggiornamento del PDR, che deve includere revisioni pianificate (almeno annuali) per allinearsi ai nuovi requisiti normativi e alle evoluzioni tecnologiche. Il ciclo si chiude con una nuova fase di test per validare le modifiche.

Garantire la resilienza operativa richiede un approccio dinamico. Una soluzione DR non aggiornata diventa rapidamente obsoleta e rischia di non essere efficace nell’emergenza.

Monitoraggio e Continua Miglioramento

Strumenti di monitoraggio e alerting proattivo

Metriche di performance e reporting per l’organizzazione

Metriche di performance e reporting per l’organizzazione

Per dimostrare il valore del Disaster Recovery e garantire il miglioramento continuo, è fondamentale monitorare metriche concrete e generare report chiari per l’organizzazione. Le metriche chiave (KPI) devono allinearsi agli obiettivi di business e agli SLA contrattuali.

• RPO (Recovery Point Objective): Misura la perdita massima di dati accettabile. Monitorare quanto ci si avvicini a zero è vitale.
• RTO (Recovery Time Objective): Indica il tempo massimo per ripristinare i servizi. È il dato che interessa direttamente la business continuity.
• MTTR (Mean Time to Repair): Tempo medio necessario per riparare un guasto, indicatore dell’efficienza del team tecnico.
• Costo dell’interruzione: Stimare l’impatto economico reale dei tempi di inattività.

Il reporting non deve essere solo tecnico, ma tradurre i dati IT in rischi di business comprensibili. Utilizzare dashboard visive e report periodici aiuta il management a comprendere la postura di sicurezza e a giustificare gli investimenti. Uno strumento di analisi avanzato permette di incrociare questi dati e simulare l’impatto di guasti specifici.

Questo approccio basato sui dati trasforma il Disaster Recovery da costo necessario a strategic asset per la resilienza operativa.

Conclusioni: Verso una cultura resiliente nella PA

Domande Frequenti (FAQ)

Cos’è il GPAA (Piano di Gestione della Continuità Operativa) e perché è obbligatorio per le PA?

Il GPAA è il documento strategico richiesto dalla Linea Guida AgID n. 2 che definisce le procedure per garantire la continuità operativa in caso di crisi. È obbligatorio per tutte le amministrazioni che gestiscono servizi essenziali e deve essere approvato dal Direttore o dirigente responsabile, integrandosi con il Piano di Sicurezza della PA.

Qual è la differenza tra Disaster Recovery (DR) e Business Continuity (BC)?

La Business Continuity è il concetto ampio che garantisce la continuità dei processi aziendali durante qualsiasi interruzione. Il Disaster Recovery è la parte tecnica della BC specificamente focalizzata sul ripristino dell’IT e delle infrastrutture tecnologiche entro tempi definiti (RTO/RPO).

Come si determina l’RTO (Recovery Time Objective) e l’RPO (Recovery Point Objective) in una PA?

Si determinano tramite la Business Impact Analysis (BIA): si identificano i servizi critici (es. pagamento tasse, anagrafe) e si calcola il danno massimo accettabile in termini di tempo di fermo (RTO) e perdita di dati (RPO). Per servizi pubblici essenziali, spesso RTO è di poche ore e RPO è vicino a zero.

È possibile usare il Cloud pubblico per la Disaster Recovery della PA?

Sì, secondo le Linee Guida AgID il Cloud è incoraggiato per le PA, purché si utilizzino servizi certificati (Cloud Provider iscritti all’Elenco degli provider Cloud) e si rispettino le regole di residenza dei dati (sovrani). Il Cloud è ideale per siti secondari (DR site) senza costi di hardware fisico.

Come cambia la Disaster Recovery con l’entrata in vigore della Direttiva NIS2?

La NIS2 amplia l’ambito di applicazione ai settori essenziali e aumenta gli obblighi di notifica e resilienza. Le PA devono garantire non solo il ripristino tecnico ma anche una gestione degli incidenti più rapida, con sanzioni più severe in caso di mancata conformità e pianificazione di scenari di crisi.

Contattaci

contattaci per saperne di più