SLA (Service Level Agreement) e garanzia di RPO/RTO

SLA (Service Level Agreement) e garanzia di RPO/RTO

La garanzia formale dei requisiti di business passa attraverso l’SLA, che traduce in vincoli contrattuali le performance attese. Per una PA, l’SLA non deve definire solo la disponibilità del servizio (es. 99,9%), ma anche i livelli di servizio su aspetti critici come la sicurezza, la conformità normativa e la trasparenza operativa. Assicurati che l’SLA includa esplicitamente i diritti di accesso ai log, le procedure di audit e le penalità in caso di inadempienza.

Il cuore della continuità operativa si misura con due indicatori chiave che devono essere definiti in SLA, in base ai requisiti di business dell’ente:

• RPO (Recovery Point Objective): indica la massima perdita di dati tollerabile, misurata in tempo (es. 15 minuti, 4 ore). Determina la frequenza degli snapshot e la tipologia di backup (diffenziali vs. continui). Una PA con processi critici spesso richiede RPO su valori bassi (es. < 1 ora).
• RTO (Recovery Time Objective): indica il tempo massimo per ripristinare un sistema o un ambiente critico dopo un guasto o un attacco (es. 4 ore, 24 ore). Condiziona la scelta tra soluzioni di failover automatico (alta disponibilità) e piani di disaster recovery manuali.

Attenzione: RPO e RTO sono obiettivi di business, non parametri tecnici. L’SLA deve specificare come e quando vengono misurati e attestati. Verificare che il fornitore implementi monitoraggio continuo della coerenza dei backup e pianifichi test di ripristino periodici (almeno semestrali), con reportistica disponibile per i responsabili di sicurezza e compliance dell’ente.

Interoperabilità e portabilità dei dati (lock-in vendor)

Oltre alla sicurezza e alla continuità, una PA deve valutare attentamente l’interoperabilità e la portabilità dei dati per prevenire il vendor lock-in (dipendenza da un fornitore unico).

La checklist operativa per questa sezione include:

• Formati di esportazione standard: Verificare che il fornitore supporti standard aperti (es. JSON, CSV, XML) e formati proprietari solo se documentati e facilmente convertibili.
• API e integrazioni: Assicurarsi che siano disponibili API documentate (RESTful/SOAP) per l’integrazione con sistemi interni e futuri, evitando piattaforme “closed ecosystem”.
• Clausole contrattuali: Inserire penali per il mancato rispetto degli standard di portabilità e garantire tempi di recesso per la migrazione dei dati.
• Prova di estrazione: Richiedere una demo pratica di estrazione completa dei dati di backup e del metadato associato.

La flessibilità è essenziale: una soluzione rigida oggi può impedire l’adozione di tecnologie future o complicare una fusione con altre amministrazioni.

Controllo dell’accesso e gestione degli amministratori

Controllo dell’accesso e gestione degli amministratori: il principio del privilegio minimo

La sicurezza dei dati di una Pubblica Amministrazione (PA) non dipende solo dalla robustezza degli algoritmi di crittografia o dalla regolarità dei backup. Il fattore umano e la gestione dei privilegi di accesso rappresentano spesso il pericoloso “collo di bottiglia” della sicurezza informatica. Un accesso non autorizzato, o un’amministrazione trascurata, può infatti compromettere in pochi minuti anni di dati raccolti e archiviati, rendendo vano qualsiasi sforzo di disaster recovery. Per questo motivo, all’interno di un progetto di gestione backup, il controllo dell’accesso e la gestione degli amministratori non sono opzioni, ma requisiti imprescindibili di compliance.

Il concetto fondamentale da applicare è il principio del privilegio minimo (PoLP). Questo principio stabilisce che ogni utente (o processo) debba avere i privilegi di accesso strettamente necessari per svolgere il proprio compito, e nulla più. In un contesto di backup, questo significa distinguere nettamente tra chi è autorizzato a gestire il sistema di backup (amministratori IT) e chi è autorizzato a recuperare i dati (richiedenti ordinari). Una confusione tra questi ruoli aumenta esponenzialmente il rischio di errori umani, come la cancellazione accidentale di un archivio, o di azioni malevole, come il furto di dati sensibili.

Per valutare se la soluzione di backup proposta dal fornitore rispetta questi standard, è necessario esaminare nel dettaglio le funzionalità di gestione degli accessi. Di seguito presentiamo una checklist operativa da utilizzare durante la valutazione tecnica e contrattuale.

1. Autenticazione Forte e Unificata (MFA e SSO)

Il primo controllo riguarda i meccanismi di autenticazione. Un semplice nome utente e password non sono sufficienti per proteggere repository di backup che contengono informazioni critiche.

• Autenticazione Multifattoriale (MFA): Verificare che l’accesso alla console di gestione del backup richieda obbligatoriamente l’utilizzo di un secondo fattore di autenticazione (app mobile, token hardware, SMS). Questo è essenziale per proteggere gli account amministrativi.
• Integrazione con SSO (Single Sign-On): La soluzione deve supportare protocolli come SAML 2.0 o OAuth 2.0 per integrarsi con l’identità digitale della PA (es. SPID per la Pubblica Amministrazione o Active Directory interno). Questo centralizza il controllo degli accessi e semplifica la revoca.
• Regole di complessità password: La console deve imporre policy di password complesse (min length, caratteri speciali, scadenza) configurabili dall’amministratore.

2. Gestione dei Ruoli e dei Permessi (RBAC)

Il sistema di backup deve offrire una gestione granulare dei ruoli (Role-Based Access Control). Non basta avere un utente “amministratore” e uno “standard”. La struttura deve rispecchiare le funzioni dell’organizzazione.

• Ruoli predefiniti e personalizzabili: Valutare la presenza di ruoli come “Amministratore Sistemista”, “Operatore Backup”, “Responsabile della Compliance” e “Utente Standard”. Ogni ruolo deve avere permessi specifiche (es. l’Operatore può avviare backup ma non cancellare repository; l’Utente Standard può richiedere recovery ma non accedere ad altri dati).
• Separazione dei compiti (SoD): La soluzione deve impedire tecnicamente che la stessa persona possa contemporaneamente eseguire il backup, verificarne l’integrità e gestire i permessi di accesso. Questo riduce il rischio di frodi interne.
• Accesso “Solo Lettura” per auditor: Assicurarsi che esista un ruolo con privilegi di sola lettura, ideale per il responsabile della sicurezza o per audit esterni, che non permetta modifiche alle configurazioni.

3. Tracciabilità e Audit Logging (Non-Repudiation)

La compliance normativa (come il GDPR o i requisiti NIS2) richiede la tracciabilità di tutte le attività. In caso di incidente, deve essere possibile ricostruire esattamente cosa è successo e chi è stato responsabile.

• Log centralizzati e immutabili: Tutte le azioni (login, logout, avvio backup, modifica configurazione, tentativo di accesso negato) devono essere registrate. I log devono essere inviati a un sistema esterno o resi immutabili per evitare manipolazioni post-incidente.
• Dettaglio dell’azione: Il log deve specificare: chi (utente), cosa (azione), quando (timestamp), da dove (IP address) e l’esito (successo/insuccesso).
• Retention dei log: Verificare per quanto tempo i log di sicurezza vengono conservati. Per le PA, spesso è richiesto un periodo di conservazione esteso (es. 12-24 mesi) a fini di audit.
• Alerting in tempo reale: Configurare notifiche automatiche per eventi critici, come multipli tentativi di login falliti, accessi da IP sconosciuti o modifiche alle policy di backup.

4. Gestione del Ciclo di Vita degli Amministratori

La sicurezza non è statica; segue il ciclo di vita del personale. La soluzione di backup deve supportare processi automatici per l’onboarding e offboarding degli amministratori.

• Revoca immediata: In caso di dimissioni o trasferimento di un dipendente con accesso amministrativo, il sistema deve permettere la disattivazione dell’account in unico click, invalidando immediatamente tutte le sessioni attive.
• Rotazione delle credenziali: La piattaforma deve supportare o imporre la rotazione periodica delle chiavi di accesso e delle password amministrative.
• Accesso JIT (Just-In-Time): Soluzioni avanzate offrono l’accesso amministrativo solo su richiesta e per un tempo limitato (es. 1 ora), approvato da un secondo amministratore, riducendo la finestra di esposizione al rischio.

5. Accesso agli Archivi e Crittografia dei Dati

L’accesso al dato salvato deve essere protetto quanto l’accesso alla console di gestione.

• Separazione tra gestione e dati: Gli amministratori del sistema di backup non devono avere accesso diretto ai file non crittografati memorizzati nel repository. I dati devono essere cifrati almeno con standard AES-256.
• Gestione delle chiavi di crittografia: Verificare dove vengono gestite le chiavi di decrittazione. La best practice prevede che le chiavi siano gestite in un sistema esterno dedicato (HSM o Key Management Service) e non siano accessibili agli amministratori del backup stesso, a meno che non sia strettamente necessario per il recovery.
• MFA per il recovery: Qualsiasi operazione di ripristino di file critici deve richiedere l’autenticazione forte, anche se l’utente è già loggato nella console.

Casi Pratici di Implementazione

Scenario A (Amministrazione Scolastica): L’IT gestisce i backup dei server didattici. Un insegnante ha bisogno di recuperare un file eliminato per errore. Grazie al RBAC, l’insegnante accede a un portale self-service dove può richiedere il recovery del proprio folder specifico, senza accedere ai dati delle altre classi o ai sistemi amministrativi.

Scenario B (Azienda Sanitaria Locale – ASL): Il responsabile della sicurezza (DPO) deve verificare la conformità dei backup. Utilizzando un account con privilegi “Solo Lettura”, accede ai report di audit senza possibilità di modificare le impostazioni o avviare operazioni di ripristino, garantendo l’integrità delle evidenze durante l’audit.

Errori Comuni da Evitare

• Account condivisi: Mai condividere account amministrativi. Ogni operatore deve avere il proprio account nominativo per garantire la tracciabilità (accountability).
• Accesso permanente al cloud: Non conservare token di accesso o API key per lunghi periodi. Utilizzare soluzioni di accesso temporaneo dove possibile.
• Ignorare i log: Avere la funzionalità di logging è inutile se non si effettuano revisioni periodiche. Pianificare controlli mensili sui log di sicurezza.

Checklist Sintetica per il Fornitore

Prima di sottoscrivere un contratto, chiedi chiaramente:

1. Il sistema supporta MFA obbligatoria per tutti gli accessi amministrativi?
2. Sono disponibili ruoli predefiniti e personalizzabili per separare le funzioni (SoD)?
3. I log di sicurezza sono immutabili e inviati a un sistema esterno?
4. La crittografia dei dati è a 256-bit e le chiavi sono gestite in modo sicuro?
5. Esiste una procedura automatizzata per la revoca degli accessi?

Costi e Complessità

Implementare un controllo degli accessi rigoroso non aumenta significativamente i costi hardware, ma richiede un investimento in competenze. La complessità è bassa-moderata per soluzioni cloud-native (che spesso includono MFA integrata), ma cresce in ambienti on-premise complessi o in scenari ibridi. Tuttavia, il costo di una violazione dati dovuta a cattiva gestione degli accessi supera di gran lunga l’investimento iniziale nella configurazione corretta.

Un sistema di backup è sicuro tanto quanto il controllo che si ha su chi può accedervi. Non sottovalutare mai questo aspetto.

Conclusioni e Next Step

Il controllo dell’accesso e la gestione degli amministratori sono pilastri fondamentali per la compliance e la sicurezza dei dati nella Pubblica Amministrazione. Implementare il principio del privilegio minimo, abbinato a un’audit trail robusta e a un’autenticazione forte, non è solo una buona pratica tecnica, ma un obbligo normativo.

Prima di procedere con l’acquisto o l’implementazione di una soluzione di backup, assicurati che questi requisiti siano soddisfatti al 100%. Un approccio proattivo ti permette di identificare gap di sicurezza e di pianificare interventi correttivi senza fretta, evitando il rischio di dover gestire una crisi di sicure

Autenticazione a due fattori (2FA/MFA) e gestione delle identità

Autenticazione a due fattori (2FA/MFA) e gestione delle identità

Un backup protetto in modo inadeguato è un enorme rischio per la PA. Anche il miglior piano di backup fallisce se l’accesso ai dati è compromesso. Per questo motivo, l’autenticazione a due fattori (2FA) o multi-fattore (MFA) è una funzionalità non negoziabile per qualsiasi soluzione di backup destinata alla Pubblica Amministrazione. Questo meccanismo richiede, oltre alla password, un secondo fattore di verifica (come un codice temporaneo da app mobile o un token hardware) per autorizzare operazioni critiche, come la modifica delle impostazioni di conservazione, l’eliminazione degli snapshot o la gestione degli account amministrativi. In caso di furto delle credenziali, senza questo secondo fattore l’attaccante non potrebbe accedere ai dati salvati.

Oltre al 2FA, è fondamentale verificare come la soluzione gestisce le identità e i permessi (Identity and Access Management – IAM). Per una PA, questo significa supportare protocolli standard come SAML 2.0 o OAuth 2.0 per l’integrazione con l’Identity Provider esistente (es. Active Directory su dominio). È essenziale poter definire ruoli granulari: l’operatore IT deve solo eseguire il backup, mentre solo il responsabile della sicurezza o un delegato devono potere eseguire il restore completo o accedere ai dati “in chiaro” in caso di emergenza. Questa separazione dei compiti (SoD – Segregation of Duties) è un requisito chiave della normativa GDPR per evitare abusi interni.

Principio del minimo privilegio (Least Privilege) per gli operatori IT

La gestione dei backup nella Pubblica Amministrazione deve integrare il Principio del Minimo Privilegio (Least Privilege) per gli operatori IT. Questo significa che ogni account utente, servizio o applicazione deve avere accesso esclusivamente alle risorse strettamente necessarie per svolgere il proprio compito, e per il tempo richiesto. È una delle misure di sicurezza più efficaci per limitare i danni in caso di compromissione di un account.

Per implementare correttamente il Least Privilege nel contesto dei backup, la checklist operativa prevede:

• Segmentazione dei ruoli: distinguere chiunque abbia necessità di accedere ai dati di backup. Ad esempio, separare gli account dei gestori delle policy di backup da quelli di chi esegue il ripristino e da chi solo verifica lo stato degli snapshot. Nessun operatore deve avere diritti di amministratore di sistema completo se non è strettamente necessario.
• Accesso JIT (Just-In-Time): invece di concedere privilegi permanenti, utilizzare sistemi che abilitano l’accesso privilegiato solo al momento della necessità e per la durata dell’operazione, revocandolo automaticamente al termine. Questo riduce drasticamente la “superficie di attacco” nel tempo.
• Separazione dei compiti (Segregation of Duties): l’operatore che configura il backup non deve poterlo cancellare o criptare senza un secondo fattore di approvazione. Questo previene azioni malevole o errori umani catastrofici da parte di un singolo utente.
• Auditing e Log: tracciare in modo immutabile ogni azione eseguita sugli archivi di backup, chi l’ha eseguita e quando. È fondamentale per la compliance normativa e per le indagini forensi in caso di incidente.
• Protezione degli account di servizio: gli account usati dai software di backup non devono essere account utente standard. Devono essere configurati con password complesse, rotazione automatica delle chiavi e privilegi minimi specifici per la macchina o l’applicazione.

Questa architettura garantisce che, anche se le credenziali di un operatore vengono compromesse, l’attaccante non possa accedere all’intero patrimonio dati, né cancellare le copie di sicurezza per rendere inefficace un eventuale richiesta di riscatto (ransomware).

CTA Soft (Mid): Per verificare se la tua infrastruttura di backup rispetta il principio del minimo privilegio e le normative vigenti, esegui subito il tuo mini-assessment gratuito di sicurezza. Scopri i punti deboli in meno di 5 minuti.

Logging, audit trail e tracciabilità delle operazioni di backup

Il logging e l’audit trail sono pilastri fondamentali per garantire la tracciabilità e la compliance nella gestione dei backup, specialmente per le PA. Non basta sapere che un backup è stato eseguito; è essenziale documentare chi, quando, come e perché sono state svolte determinate operazioni. Questa tracciabilità è requisito irrinunciabile per il rispetto del GDPR (art. 32) e delle normative sulla Cybersecurity (es. NIS2), trasformando il semplice archivio di dati in un sistema di controllo auditabile.

Una soluzione adeguata deve offrire log dettagliati e immutabili che registrino ogni azione: dalla creazione dello snapshot all’eventuale ripristino, fino alle verifiche di integrità. È fondamentale che questi dati siano protetti da manomissioni e conservati secondo le tempistiche normative. Di seguito una checklist operativa per valutare le funzionalità di logging del tuo fornitore o soluzione interna.

Checklist: Requisiti di Logging e Audit Trail

• Granularità degli eventi: Il sistema registra tutte le operazioni critiche (creazione, modifica, eliminazione, ripristino backup) con orario, utente/IP e dettagli dell’azione?
• Immutabilità dei log: I log sono storati in modalità Write-Once-Read-Many (WORM) o cifrati con chiavi dedicate per evitare alterazioni post-evento?
• Integrazione SIEM: È possibile esportare i log in formato standardizzato (es. Syslog, JSON) verso il tuo sistema di monitoraggio centrale o Security Information and Event Management?
• Conservazione: Il fornitore garantisce periodi di conservazione dei log conformi alle normative di settore (minimo 24 mesi per molti enti pubblici)?
• Accesso e Ruoli: È possibile definire chi può visualizzare o esportare i log (es. separazione tra amministratori IT e responsabili della sicurezza)?

Verificare questi punti previene il rischio di sanzioni e garantisce trasparenza operativa.

Validazione, testing e continuità operativa

Validazione, testing e continuità operativa

Il backup, per definizione, non è un fine ma un mezzo. Il suo valore reale si misura in un unico, drammatico istante: quello del ripristino. A cosa serve avere un piano di backup impeccabile, conforme a norma e immutato nel tempo, se quando si verifica l’incidente (attacco ransomware, guasto hardware, errore umano) la procedura di recovery fallisce, impiega troppo tempo o, peggio, ripristina dati corrotti? Per una Pubblica Amministrazione, garantire la validità dei backup e la continuità operativa non è un’opzione, ma un obbligo di servizio pubblico e di rispetto del Codice dell’Amministrazione Digitale (CAD). In questa sezione analizziamo come costruire un processo di validazione robusto e come trasformare il disaster recovery da promessa scritta su un documento a competenza operativa concreta.

Perché il testing è l’unico modo per fidarsi dei propri backup

Molti responsabili IT cadono nella “sindrome dell’archivio”: considerano il backup un’operazione passiva di scrittura su nastro o su disco. In realtà, la gestione dei backup nella PA è un’attività di sicurezza informatica proattiva. I dati possono diventare irrecuperabili per motivi apparentemente banali: corruzione silenziosa dei file, bug nel software di backup durante l’aggiornamento, problemi di configurazione delle policy, esaurimento dello spazio di archiviazione non immediatamente percepito.

È fondamentale, quindi, strutturare una strategia di testing che non sia occasionale ma ciclica e documentata. Questa strategia si divide in livelli:

• Verifica di integrità (Integrity Check): operazione automatica quotidiana o settimanale che verifica che i file di backup siano leggibili e non corrotti. È un controllo di basso livello ma essenziale per scattare un’allerta se l’archivio è danneggiato.
• Restore parziale (File-Level Restore): simulazione di recupero di singoli file o cartelle. Obiettivo: verificare che la struttura dei dati sia accessibile e che i file ripristinati siano identici agli originali (usando checksum come MD5 o SHA-256). È il test più semplice da eseguire e dovrebbe avvenire settimanalmente.
• Restore completo di un sistema (Full System Restore): il test di qualità suprema. Consiste nel ripristinare un’intera macchina virtuale o fisica su un ambiente isolato (sandbox) per verificare che il sistema operativo, le applicazioni e i dati partano correttamente. Questo test va eseguito almeno trimestralmente o prima di ogni aggiornamento importante dell’infrastruttura.

Definire gli SLA: RPO e RTO per una PA efficiente

Non tutti i dati hanno la stessa criticità. In una PA, l’archivio storico di un ufficio protocollo ha requisiti diversi rispetto al database delle anagrafici in tempo reale. La validazione della soluzione di backup passa attraverso la definizione di parametri oggettivi misurabili: i Recovery Point Objective (RPO) e i Recovery Time Objective (RTO).

• RPO (Recovery Point Objective): indica la massima perdita di dati accettabile. Se l’RPO è di 4 ore, significa che, in caso di guasto, accettiamo di perdere al massimo i dati delle ultime 4 ore. Per rispettare questo obiettivo, la frequenza del backup deve essere inferiore a 4 ore (es. backup ogni 2 ore). Per i sistemi critici PA, l’RPO deve tendere a zero (con soluzioni di replica sincrona o backup continuo).
• RTO (Recovery Time Objective): indica il tempo massimo entro il quale un sistema o un servizio deve essere ripristinato e operativo. Se l’RTO è di 8 ore, l’ufficio deve riaprire entro quella finestra temporale. Per raggiungere un RTO basso, non basta avere i backup; serve avere l’hardware di ripristino pronto (o cloud, o Warm Site) e procedure automatizzate.

La validazione del fornitore o della soluzione interna deve verificare se l’infrastruttura proposta è in grado di garantire fisicamente questi tempi. Una soluzione basata solo su nastri LTO, ad esempio, garantisce un RPO eccellente (conservazione a lungo termine) ma ha un RTO molto elevato per via dei tempi di ripristino fisico. Un mix di backup locale (su NAS/Dischi) e cloud è spesso l’equilibrio vincente.

Il Piano di Disaster Recovery (PDR): la “scatola degli attrezzi” dell’amministratore

Il Piano di Disaster Recovery (PDR) non è il semplice “Manuale del Backup”. Il PDR è il documento che descrive *cosa* fare, *chi* deve farlo e *con quali risorse* quando l’evento critico si verifica. Per le PA, questo documento deve essere conosciuto da tutti i soggetti coinvolti (responsabile della sicurezza, dirigente, tecnici, fornitore).

Il PDR deve includere procedure step-by-step non ambigue. Ecco una mini-checklist operativa da inserire nel documento:

1. Identificazione dell’evento: Come capiamo che serve il DR? (Allerta monitoraggio, richiesta utente, report di sicurezza).
2. Escalation e contatti: A chi si dà l’allarme? (Responsabile IT interno, fornitore SOC/CERT, responsabile protezione dati DPO).
3. Isolamento: Se è un attacco malware, il primo passo è disinquinare la rete, non ripristinare subito (altrimenti si ri-infetterebbe il nuovo sistema).
4. Ripristino: Ordine di priorità dei sistemi. Si parte dal dominio (Active Directory/DNS) e dai sistemi di autenticazione, poi si passa ai database transazionali, infine ai dati di archivio.
5. Verifica e Allineamento: Verifica funzionale (il sistema parte?) e integrità dati (i dati sono quelli giusti?).
6. Chiusura: Documentazione dell’incidente e del tempo impiegato per il ripristino (per audit futuri e miglioramento RTO).

Costi, complessità e risorse necessarie per il testing

Valutare una soluzione di backup per la PA significa anche interrogarsi sui costi occulti del testing. Spesso si commette l’errore di calcolare solo il costo dell’hardware (CAPEX) o del canone cloud (OPEX), dimenticando il costo del tempo tecnico.

Il testing ha una complessità direttamente proporzionale alla diversità dell’ambiente IT. Ambiente eterogeneo (macchine virtuali, fisiche, database SQL e NoSQL, SaaS come Microsoft 365) richiede tool che supportino tutte queste tipologie. Se la soluzione di backup non prevede un ambiente “sandbox” automatico (ovvero un ambiente isolato dove avviare le VM di backup senza intaccare la produzione), il testing diventa un’operazione manuale, costosa e soggetta a errori.

Analisi costi/complessità:

• Bassa complessità (Archiviazione semplice): Backup su nastri o dischi esterni. Costo hardware basso, costo del testing (manuale) molto alto e RTO elevato. Sconsigliato per sistemi critici attivi.
• Media complessità (Backup locale + Cloud): Soluzione ibrida. Costo bilanciato. Il testing automatizzato del locale è facile; il testing del cloud dipende dalla banda (scaricamento dati). Attenzione ai costi di “egress” (uscita dati) dal cloud in caso di ripristino totale.
• Alta complessità (DRaaS – Disaster Recovery as a Service): Replica continua verso un data center secondario o cloud. Costo maggiore, ma automatizzazione quasi totale e RTO/RPO molto bassi. Spesso l’unica opzione valida per PA che non possono permettersi disservizi prolungati.

Il fattore umano è cruciale: chi esegue il test? Il team interno o un partner specializzato? Valutare soluzioni che includano il “Managed Backup” (gestione del backup e del testing da parte del fornitore) può essere più economico rispetto all’assunzione di personale specializzato full-time.

Aspetti normativi e di sicurezza nel processo di validazione

Il processo di validazione non deve violare la sicurezza. Un errore comune è considerare i dati di backup come “dati di serie B”. In realtà, contenendo copie dei dati originali, l’archivio di backup è un bersaglio primario per gli attacchi informatici e deve godere di una protezione pari, se non superiore, ai dati in produzione.

Durante il testing e la validazione bisogna assicurarsi che:

1. Accesso limitato: Solo pochi utenti autorizzati possano avviare operazioni di ripristino o accedere agli archivi.
2. Crittografia: I dati sono crittografati sia “in transito” (durante l’invio al cloud o al sito di disaster recovery) sia “a riposo” (sul disco/nastro). La chiave di crittografia deve essere custodita separatamente (esci dal backup).
3. Immutabilità: L’ideale è utilizzare archiviazioni “immutable” (immodificabili). Questa funzionalità impedisce, per un periodo di tempo prestabilito, che anche un attaccante con credenziali amministrative possa cancellare o criptare i backup (difesa contro ransomware).
4. Separazione dei ruoli: Chi configura il backup non dovrebbe essere lo stesso che gestisce il ripristino finale senza supervisione, per prevenire errori interni o frodi.

Il rispetto di queste regole garantisce non solo la sicurezza, ma anche la conformità al GDPR e al “Codice in materia di protezione dei dati personali” per le PA, che richiede tracciabilità e sicurezza delle operazioni di trattamento, inclusa la fase di backup/restore.

La simulazione del guasto: l’unico test che conta

Per concludere il capitolo sulla validazione, bisogna parlare di simulazione completa. Spesso le PA eseguono “test di ripristino” che in realtà sono solo “test di lettura”: copiano un file dal backup e lo aprono. Questo non valida la continuità operativa.

Il vero test di maturità (Maturity Level) consiste nel simulare un guasto completo:

1. Spegnere l’ambiente di produzione di un sistema non critico (es. un portale intranet).
2. Avviare la procedura di Disaster Recovery ufficiale.
3. Misurare il tempo impiegato per avere il servizio online (RTO).
4. Verificare che gli utenti possano operare normalmente sull’ambiente ripristinato.
5. Documentare ogni discrepanza riscontrata (es. “il servizio di posta è ripartito, ma le firme digitali non sono presenti”).

Questo approccio permette di identificare i veri colli di bottiglia (banda di rete insufficiente, tempi di avvio macchina virtuali troppo lunghi, configurazioni manuali dimenticate) che emergono solo sotto stress reale. Per una Pubblica Amministrazione, eseguire questi test almeno una volta l

Simulazioni di disaster recovery: quanto spesso testare?

Le simulazioni di disaster recovery (DR) non sono un’attività opzionale ma un pilastro della resilienza operativa per le PA. Un piano di disaster recovery senza test periodici è, nella pratica, un documento teorico che non regge al primo stress reale.

Per rispondere alla domanda “quanto spesso?”, non esiste una frequenza unica: dipende dalla criticità dei sistemi, dalla complessità dell’infrastruttura e dai requisiti normativi (come il NIS2, che richiede una valutazione e test regolari dei piani di continuità). Tuttavia, una buona prassi diffusa suggerisce un approccio a livelli:

• Controlli funzionali (settimanali o mensili): Verifiche rapide per assicurarsi che le repliche di dati siano attive, gli snapshot siano completati correttamente e le connessioni siano integre. L’obiettivo è individuare guasti “silenziosi” prima che diventino emergenze.
• Test di disaster recovery (semestrali o annuali): Simulazioni più complesse che riproducono veri e propri incidenti (es. ransomware, guasto hardware massivo). È qui che si testano non solo la tecnologia, ma anche le procedure operative e le tempistiche di recupero (RTO/RPO).
• Test “fire drill” (annuali o biennali): Coinvolgono figure IT e non IT, simulando lo scenario di emergenza completo, inclusa la comunicazione con i stakeholder e le azioni di primo intervento.

La cadenza va adattata anche ai cambiamenti infrastrutturali: ogni aggiornamento significativo del sistema, migrazione cloud o cambio di fornitore richiede un test mirato.

Non dimenticare di documentare ogni risultato: una simulazione fallita è un’opportunità di miglioramento preziosa per allineare la tecnologia ai requisiti di sicurezza e continuità della tua PA.

Sei pronto a verificare quanto è solido il tuo piano di disaster recovery? Contattaci oggi per una simulazione guidata e una valutazione di compliance mirata.

Integrità dei dati: checksum e verifiche automatiche post-backup

Integrità dei dati: checksum e verifiche automatiche post-backup

Dopo il completamento dell’operazione di backup, il lavoro non è finito: è fondamentale garantire che i dati copiati siano integri e non corrotti. Un backup corrotto è inutile quanto un backup mancante. Per questo motivo, ogni soluzione di gestione backup per la PA deve integrare meccanismi di verifica dell’integrità.

Il metodo più affidabile è l’utilizzo di checksum crittografici (come SHA-256 o MD5). Durante il processo di backup, il software genera un’impronta digitale univoca dei file; al termine dell’operazione, ricalcola l’impronta e la confronta con quella originale. Se coincidono, l’integrità è garantita. Tuttavia, i dati possono degradare nel tempo, per problemi hardware o corruzione silenziosa.

Per questo motivo, le verifiche devono essere automatiche e periodiche. Le migliori soluzioni eseguono controlli di integrità schedulati (es. settimanali) su un campione dei dati archiviati, inviando alert immediati in caso di incongruenze. Questo approccio proattivo evita la scoperta dell’errore solo al momento del disaster recovery, quando ormai sarebbe troppo tardi.

Checklist operativa per la verifica dell’integrità:

• Il fornitore supporta checksum crittografici (SHA-256 o superiore)?
• È possibile attivare verifiche automatiche post-backup?
• Il sistema invia notifiche in caso di corruzione dati?
• Le verifiche periodiche sono configurabili per frequenza e scope?
• I report di integrità sono tracciabili e disponibili per audit?

Un approccio che include checksum e verifiche automatiche riduce il rischio di perdite dati irreversibili e garantisce che il tuo disaster recovery sia sempre effettivo. Per una soluzione di backup che metta al primo posto l’integrità dei dati della tua amministrazione, contattaci per una consulenza dedicata.

Backup fisici vs. virtuali: strategie ibride per PA complesse

Nelle Amministrazioni Pubbliche complesse, come Comuni di medie/grandi dimensioni o enti con sistemi misti (mainframe, server legacy, ambienti virtualizzati e cloud), la scelta tra backup fisici e virtuali non è un’alternativa binaria, ma un’opportunità per costruire una strategia ibrida resiliente.

Backup fisici: l’ancora di salvezza per dati critici e offline

Il backup fisico (o tradizionale) permane indispensabile per:

• Disaster Recovery di sistemi legacy: dove la virtualizzazione non è possibile o conveniente (es. mainframe o applicazioni monolitiche).
• WORM (Write Once Read Many) e air gap: supporti come LTO tape o dischi in modalità sola lettura garantiscono l’immunità da ransomware per archivi di lungo periodo (retention 10+ anni) richiesti dalla normativa sulla conservazione digitale.
• Recovery di granularità estrema: per ripristinare singoli file o database corrotti senza dover ricostruire intere macchine virtuali.

Checklist rapida (Fisico): Il supporto è dislocato in site diversi? È crittografato (AES-256)? Il ciclo di vita è gestito automaticamente? Il piano di test prevede verifiche fisiche semestrali?

Backup virtuali: agilità e integrazione cloud

Il backup virtualizzato è la scelta standard per ambienti VMware, Hyper-V e cloud.

• Instant Recovery: permette di riavviare macchine virtuali in minuti direttamente dal repository di backup, riducendo drasticamente i tempi di inattività (RTO).
• Integrazione cloud: ideale per il disaster recovery as a service (DRaaS) e per il backup su cloud obiettivo (immutable backup) per la protezione da ransomware.
• Efficienza: deduplicazione e compression avanzate riducono lo storage necessario e i costi di trasferimento dati (egress).

Checklist rapida (Virtuale): Il repository supporta la deduplicazione inline? È configurata la retention policy conforme al GDPR? Il backup è testato con recovery point objectives (RPO) definiti?

La strategia ibrida: il meglio di entrambi i mondi

Una PA complessa deve abbracciare un modello ibrido (3-2-1):

1. 3 copie dei dati: (Produzione + Backup locale + Backup remoto).
2. 2 supporti diversi: (Es. disco ad alta velocità per RTO bassi + Nastro/LTO per backup a lungo termine).
3. 1 copia offsite o immutabile: (Cloud o nastro esterno per compliance e sicurezza).

Integrare strumenti che gestiscano sia workload fisici che virtuali da un’unica console (unified data management) semplifica la compliance (ISO 27001, NIS2) e riduce l’operational overhead.

CTA Soft: Per una valutazione mirata, scarica la nostra checklist di autovalutazione per la compliance dei backup nelle PA.

Aspetti economici e procedure di acquisto

L’acquisto di un sistema di backup per la Pubblica Amministrazione non può prescindere da una valutazione economica e procedurale rigorosa, che garantisca non solo il massimo ritorno sull’investimento (ROI), ma soprattutto la piena conformità con il Codice dei Contratti Pubblici (D.Lgs. 50/2016) e il PNRR. Le procedure di acquisto sono il primo filtro per valutare la serietà e la compliance del fornitore.

Un primo aspetto economico da considerare è il modello di licenziamento. Le soluzioni per il backup non sono beni finiti, ma servizi in continua evoluzione. Chiediti se il fornitore propone una licenza perpetua (spesso soggetta a costi di manutenzione annuali crescenti) o un modello Subscription (SaaS o on-premise), che prevede un canone ricorrente annuale. Per la PA, il canone può essere più gestibile e trasparente, ma è fondamentale verificare la prevedibilità dei costi futuri.

Durante la valutazione economica, è essenziale applicare il concetto di Total Cost of Ownership (TCO). Non limitarti al costo della licenza iniziale; devi includere:

• Costi di implementazione e configurazione (professional services).
• Costi di formazione del personale IT.
• Costi di manutenzione e supporto tecnico (SLA).
• Costi nascosti per ripristino dati (egress fees) o per l’aggiunta di nuovi server.

Checklist Procedurale e Compliance:

Per garantire che l’acquisto sia conforme alle normative, verifica che il fornitore sia in grado di supportarti nelle seguenti procedure e requisiti documentali:

• Requisiti di partecipazione (Art. 83 Codice dei Contratti): Il fornitore deve possedere i requisiti generali di moralità e i requisiti speciali di capacità economico-finanziaria e tecnico-professionale. Richiedi il Certificato di Vigilanza della SOA (se l’importo supera le soglie comunitarie) o l’iscrizione al SOA per servizi informatici.
• Offerta economicamente più vantaggiosa (OEPV): Nelle gare sotto soglia comunitaria, la PA deve valutare l’offerta non solo sul prezzo, ma su criteri qualitativi. Assicurati che il fornitore possa dimostrare parametri qualitativi certificati (es. ISO 27001, ISO 9001) e che la soluzione tecnica offerta soddisfi i requisiti minimi richiesti nel bando.
• Trasparenza e Pubblicità: Per gli appalti sotto soglia (procedure sotto i 150.000 euro), la PA deve effettuare almeno 3 richieste di preventivo. Scegli un fornitore che fornisca preventivi dettagliati, chiari e conformi alla richiesta, per non incorrere in vizi procedurali.
• Scelta del Procedimento: Valuta se applicare il RDO (Richiesta di Offerta) o la procedura negoziata senza bando. Per l’acquisto di soluzioni cloud/saas, spesso si ricorre al mercato elettronico (MePA) o al Sistema Dinamico di Acquisizione (SDA).

Valutazione della Roadmap Tecnologica:

Un aspetto economico spesso trascurato è la “svalutazione tecnologica”. Una soluzione di backup troppo rigida potrebbe diventare obsoleta in pochi anni, costringendo la PA a investire nuovamente. Privilegia fornitori che garantiscono backward compatibility e che aggiornano la propria soluzione per supportare nuove versioni di OS e database, senza costi aggiuntivi sproporzionati.

Consiglio Pratico: Richiedi sempre un “Proof of Concept” (PoC) o un periodo di prova gratuito. Questo ti permette di testare la reale efficienza del backup e del ripristino nel tuo ambiente specifico, validando le performance promesse prima dell’acquisto definitivo.

Analisi Costo/Totale di Ownership (TCO) su 3-5 anni

Valutare il costo reale di una soluzione backup non significa guardare solo il prezzo di acquisto. L’analisi del Total Cost of Ownership (TCO) su 3-5 anni include:

• Costi diretti di acquisto e implementazione: licenze software, hardware (se on-premise), costi di configurazione e formazione del personale.
• Costi operativi (OpEx): gestione giornaliera, monitoraggio, manutenzione e aggiornamenti. Con soluzioni cloud, valuta attentamente i costi di storage e egresso dati, che possono variare notevolmente.
• Costi di disaster recovery: tempi di riattivazione (RTO) e perdita dati (RPO) in caso di incidente. Un tempo di ripristino più lungo significa maggiore fermo produttivo, con costi diretti e indiretti rilevanti per la PA.
• Costi di compliance: audit, certificazioni e aggiornamenti normativi. Le soluzioni che offrono reportistica automatizzata riducono il carico amministrativo.

Una soluzione con costi di acquisto più bassi potrebbe rivelarsi più costosa a causa di costi operativi elevati o di un disaster recovery inefficace. Calcola un budget che includa una stima conservativa per questi fattori su 3-5 anni. Per una stima personalizzata sul tuo caso, richiedi un confronto con i nostri esperti.

Gare pubbliche e codice degli appalti: come specificare i requisiti

Quando si bandisce una gara pubblica per la gestione dei backup, è fondamentale tradurre i requisiti tecnici e di sicurezza in criteri di aggiudicazione chiari e misurabili, nel pieno rispetto del Codice degli Appalti (D.Lgs. 36/2023). Una specifica vaga o ambigua, infatti, apre la strada a contestazioni e soluzioni non conformi.

Per evitare il “principio della precisione linguistica”, il capitolato tecnico deve declinare i requisiti in modo oggettivo. Ecco una mini-checklist operativa da integrare nel bando o nella lettera d’invito:

• Requisiti minimi di sicurezza: richiedere esplicitamente l’encryption in transit e at rest con algoritmi standard (es. AES-256), specificando che la gestione delle chiavi deve essere separata dall’ambiente di backup.
• Conformità normativa: imporre il rispetto del GDPR per il trattamento dei dati personali e, nel caso di PA, delle regole sull’archiviazione digitale (CAD). Per le PA che gestiscono dati sensibili, specificare che il fornitore deve operare con data center ubicati in UE (anche se il provider è extra-UE, i dati devono risiedere in UE).
• Indicatori prestazionali (KPI): definire parametri misurabili come il Recovery Point Objective (RPO) massimo consentito (es. 1 ora) e il Recovery Time Objective (RTO) per il ripristino completo (es. 24 ore), obbligando il fornitore a fornire dashboard in tempo reale per il monitoraggio.
• Continuity e resilienza: chiedere esplicitamente la disponibilità del servizio (SLA) superiore al 99,9% e la pianificazione di test di disaster recovery semestrali, documentati e certificati.

Nella valutazione delle offerte, il criterio dell’offerta economicamente più vantaggiosa è preferibile al semplice prezzo più basso. Assegna punti aggiuntivi a chi offre soluzioni con backup immutabili (per la protezione contro i ransomware) o con ispezione automatizzata dell’integrità dei file (hash checking).

Infine, ricorda di inserire nel contratto la clausola di risoluzione per inadempienza in caso di mancato rispetto degli SLA e l’obbligo di fornire report di compliance annuali. Questo approccio garantisce non solo il miglior prezzo, ma la massima sicurezza per i dati dell’ente.

Conclusioni e road map di implementazione

Conclusioni e road map di implementazione

La gestione dei backup per la Pubblica Amministrazione ha smesso di essere un semplice compito tecnico per diventare una leva strategica di continuità operativa, resilienza e fiducia dei cittadini. Abbiamo analizzato i punti critici, i requisiti normativi e i criteri di selezione; ora è il momento di tradurre tutto in azioni concrete. Di seguito, una road map operativa per strutturare e accelerare il percorso di compliance, minimizzando il rischio operativo e massimizzando il ritorno sull’investimento.

Dall’analisi all’azione: primi passi rapidi (30 giorni)

La prima fase deve essere focalizzata sulla messa a fuoco del quadro attuale e sulla definizione delle priorità. Senza un punto di partenza chiaro, ogni scelta tecnologica rischia di essere inefficace o costosa.

• Inventario e mappatura dei dati: identificare tutte le fonti dati critiche (archivi documentali, database gestionali, sistemi GIS, Piattaforme Digitale) e classificarle per criticità (Dati Critici, Dati Operativi, Dati di Supporto).
• Valutazione dello stato di compliance: applicare la checklist pratica per valutare soluzioni e compliance che abbiamo delineato. Utilizza il modello a punteggio per avere una fotografia oggettiva dei gap (es. RPO/RTO, crittografia, immutabilità).
• Definizione del budget di riferimento: stimare il Total Cost of Ownership (TCO) annuo, includendo non solo il costo dell’infrastruttura di backup, ma anche le ore di manutenzione, le verifiche periodiche e eventuali costi di ripristino in caso di simulazione di disaster recovery.
• Formazione del team: designare un responsabile del progetto (spesso il Responsabile della Protezione dei Dati o il Dirigente IT) e coinvolgere la funzione Acquisti fin dall’inizio per allineare la procedura di gara ai requisiti tecnici.

Fase 2: Progettazione e definizione della Strategia di Backup (30-60 giorni)

Una volta identificati i gap, è necessario disegnare l’architettura target e selezionare il fornitore o la soluzione.

• Definizione della politica di backup: stabilire frequenze (es. quotidiano per dati transazionali, settimanale per archivi), tipologia (full, incrementale, differenziale) e finestre di backup per non compromettere le performance di daytime.
• Progettazione della 3-2-1-1-0 Rule: garantisce almeno 3 copie dei dati, su 2 supporti diversi (es. disco e nastro/cloud), con 1 copia off-site o in cloud immutabile, 1 copia offline/aria-gapped e 0 errori nei test di verifica.
• Selezione della soluzione tecnologica: valutare soluzioni che supportino le backup immutabili e la crittografia end-to-end (almeno AES-256). Per le PA, è fondamentale verificare la sovranità dei dati: la soluzione deve essere ospitata in data center ubicati in UE o, preferibilmente, in Italia, per aderire alle linee guida europee sulla localizzazione dei dati.
• Redazione del capitolato tecnico di gara: includere requisiti stringenti su SLA, compliance al Regolamento (UE) 2022/2554 (DORA) per gli enti finanziari e al NIS2 per quelli critici, oltre a clausole penali in caso di mancata adozione delle misure di sicurezza richieste.

Fase 3: Implementazione e Test (60-120 giorni)

La fase operativa è critica. Un backup non testato è un backup inesistente.

• Deploy e configurazione: installazione dell’agente di backup, configurazione delle policy e integrazione con gli alerting (via email, SMS o ticketing system).
• Automazione dei processi: eliminare la gestione manuale dei supporti fisici dove possibile, affidando la rotazione e la verifica all’automazione del software.
• Test di ripristino (Drill): eseguire almeno due simulazioni complete all’anno. La prima deve testare il ripristino di singoli file (RTO breve), la seconda il ripristino dell’intero sistema operativo/DB (RTO esteso). Non affidarti alla teoria: il disaster recovery è un esercizio pratico.
• Verifica della cifratura e chiavi: assicurarsi che le chiavi di crittografia siano custodite in modo separato (es. HSM o gestore di chiavi dedicato) e che l’accesso sia tracciato.

Fase 4: Monitoraggio, Manutenzione e Ottimizzazione (Ciclico)

La compliance non è un progetto “una tantum”, ma un processo continuo.

• Dashboard di monitoraggio: utilizzare strumenti di reporting che mostrino lo stato di completion dei backup, l’integrità dei dati e le anomalie rilevate.
• Audit periodici: revisione trimestrale dei log di accesso e semestrale della policy di backup per adeguarla all’evoluzione del patrimonio dati.
• Aggiornamento normativo: monitorare l’evoluzione del DORA e delle direttive NIS2 per adeguare tempestivamente le policy di sicurezza.

Conclusione: verso una resilienza certificata

Implementare una gestione dei backup conforme per la PA significa trasformare un obbligo normativo in un vantaggio competitivo: garantire servizi continui, proteggere i dati dei cittadini e ridurre l’esposizione a multe salate (fino al 2% del fatturato globale per il DORA o al 10 milioni di euro per il NIS2). La strada richiede precisione, ma i benefici in termini di sicurezza e fiducia istituzionale sono inestimabili.

Non aspettare che un incidente validi le tue scelte. Agisci ora.

Tabella di marcia: dalla valutazione al go-live

Tabella di marcia: dalla valutazione al go-live

Una pianificazione dettagliata è fondamentale per evitare interruzioni e garantire che ogni fase sia allineata ai requisiti normativi della tua PA. Ecco una roadmap pratica per implementare una soluzione di backup efficace e conforme in 5 passaggi chiave:

• 1. Analisi e pianificazione (Settimana 1-2): Mappatura dei dati critici e dei sistemi da proteggere. Definizione degli obiettivi di RTO (Tempo di Ripristino Obiettivo) e RPO (Punto di Ripristino Obiettivo) in base alla business continuity.
• 2. Scelta della soluzione (Settimana 3-4): Valutazione tecnica delle soluzioni (locale, cloud ibrido, SaaS) e selezione del fornitore. Verifica dei certificati di conformità (ISO 27001, NIS2) e dei livelli di servizio (SLA).
• 3. Configurazione e Sicurezza (Settimana 5-6): Configurazione delle policy di backup, crittografia dei dati (in transito e a riposo) e definizione dei criteri di accesso basati sui ruoli (RBAC). Attivazione del 3-2-1 rule (3 copie, 2 supporti, 1 remoto).
• 4. Test di Ripristino (Settimana 7): Esecuzione di drill di ripristino periodici su dati simulati per validare l’integrità e la velocità delle operazioni. Documentazione dei risultati per audit futuri.
• 5. Go-Live e Monitoraggio (Settimana 8): Attivazione della soluzione in produzione e impostazione di dashboard di monitoraggio e alerting proattivi per garantire la continuità operativa.

Questa roadmap ti permette di gestire il progetto in modo strutturato, minimizzando i rischi legati alla transizione.

Formazione del personale e sensibilizzazione interna

Una soluzione tecnica, per quanto avanzata, è solo efficace se le persone che la utilizzano ne comprendono il funzionamento e ne rispettano i protocolli. La formazione del personale e la sensibilizzazione interna sono elementi cardine per garantire che la policy di backup non rimanga solo un documento, ma diventi una pratica quotidiana.

È fondamentale educare il personale su concetti chiave come la differenza tra backup, sincronizzazione e archiviazione, e sulla criticità di non salvare dati sensibili su supporti locali non protetti. La formazione deve coprire procedure operative chiare: come effettuare un ripristino corretto in caso di necessità, a chi segnalare anomalie e quali sono le sanzioni previste in caso di negligenza (ad esempio, la mancata adesione alla policy aziendale). Per il personale amministrativo, è cruciale una formazione specifica sul trattamento dei dati pubblici e sulle normative GDPR.

Una checklist pratica per la sensibilizzazione interna dovrebbe includere:

• Definizione di una policy scritta e accessibile, che delinei chiaramente le responsabilità di ciascun ruolo (dall’impiegato all’amministratore di sistema).
• Sessioni di formazione periodiche e obbligatorie, ad esempio annuali o semestrali, con aggiornamenti specifici in caso di cambi normativi o tecnologici rilevanti.
• Simulazioni di disaster recovery per testare la prontezza del team nel ripristinare i dati critici senza incorrere in perdite.
• Canali di comunicazione dedicati per segnalare tempestivamente tentativi di phishing o sospetti accessi non autorizzati, che potrebbero compromettere l’integrità del backup.

Investire nella competenza delle persone riduce drasticamente il rischio di errore umano, la prima causa di perdita dati secondo gli studi di settore.

Domande Frequenti (FAQ)

Le PA possono utilizzare servizi di backup su cloud pubblico come AWS o Azure?

Sì, ma solo attraverso il Mercato Elettronico delle PA (MePA) o il Pas (Piattaforma Appalti Servizi) e rispettando i requisiti di sovranità dei dati. Le PA devono assicurarsi che i data center si trovino nell’Unione Europea o in paesi con adeguate garanzie (es. Clauses Contractual Standard – CCS). AgID fornisce elenchi di servizi cloud conformi.

Qual è la differenza tra RPO e RTO e perché sono fondamentali per una PA?

RPO (Recovery Point Objective) indica la massima perdita di dati tollerabile (es. 1 ora), mentre RTO (Recovery Time Objective) indica il tempo massimo entro cui ripristinare i servizi. Per le PA che erogano servizi essenziali (sanità, anagrafe), RPO e RTO devono essere definiti contrattualmente e verificati con test periodici.

È obbligatorio cifrare i backup delle PA?

Il GDPR (Art. 32) impone misure tecniche adeguate alla natura dei dati. Per i dati sensibili o giudiziari, la crittografia è quasi sempre obbligatoria, sia in transito (SSL/TLS) che a riposo (AES-256). Inoltre, le chiavi di crittografia devono essere gestite separatamente dai dati per evitare accessi non autorizzati.

Quanto dura il periodo di conservazione dei log di backup?

I log di audit e tracciabilità delle operazioni di backup devono conservarsi generalmente per almeno 24 mesi, in linea con le normative sulla trasparenza amministrativa e sulle verifiche fiscali. Tuttavia, per i dati sensibili, si applicano i termini previsti dalla normativa specifica di settore.

Cosa succede se il fornitore di backup fallisce o viene acquisito?

Il contratto deve prevedere una clausola di ‘exit strategy’. Il fornitore deve garantire la restituzione dei dati in formati standard (es. VMDK, OVF, SQL dump) senza costi aggiuntivi e nel tempo contrattualizzato (tipicamente 30 giorni). L’utilizzo di formati aperti previene il lock-in vendor.

Contattaci

contattaci per saperne di più