Strategie di backup tra On-Prem e Cloud: valutazione costi-benefici per i CIO

La discussione sulle strategie di backup tra On-Prem e Cloud diventa in molte aziende concreta solo quando si verifica un incidente: ransomware, guasto dello storage, dati cancellati involontariamente o un audit con domande scomode. Per i CIOs e le direzioni IT il backup non è una disciplina puramente tecnica, ma una decisione costo-beneficio con effetto diretto sulla capacità operativa, sui rischi di responsabilità, sulla capacità di consegna e sul potere negoziale nei confronti dei provider.

Chi oggi parla di «Cloud» spesso intende automaticamente «meno lavoro». In pratica il lavoro si sposta: dalla fornitura di hardware e dalla rotazione dei supporti, verso classificazione dei dati, controlli di rete e di identità, controllo continuo dei costi, pianificazione dell’exit e – decisivo – capacità di ripristino verificabile. Questo contributo offre una logica decisionale strutturata che potete gestire come tema di management e governance: con opzioni chiare, blocchi di costo, rischi, responsabilità e evidenze verificabili in audit.

Strategie di backup tra On-Prem e Cloud nella pratica

I backup sono validi quando permettono un ripristino dimostrabile. Tutto il RESTo è archiviazione o conservazione dati – entrambi importanti, ma non coincidenti con la Business Continuity. La chiave è tradurre i requisiti in RTO e RPO:

• RTO (Recovery Time Objective): Quanto rapidamente un servizio deve tornare operativo affinché l’attività aziendale non subisca un danno inaccettabile?
• RPO (Recovery Point Objective): Qual è la perdita di dati massima accettabile (finestra temporale), misurata rispetto all’ultima copia coerente?

Queste due metriche condizionano l’architettura più di qualsiasi scelta di prodotto. Un RTO di 24 ore consente procedure diverse (es. nastro offsite) rispetto a un RTO di 2 ore (es. replica basata su snapshot più pipeline di ripristino rapide). Negli audit è centrale proprio questa tracciabilità: perché un metodo è «appropriato» e come viene verificata regolarmente la conformità?

Quadro decisionale per i CIOs: risolvere chiaramente tre conflitti di obiettivo

La maggior parte delle organizzazioni non fallisce per «tecnica», ma per conflitti di obiettivi non esplicitati. Per una decisione costo-beneficio sostenibile è necessario risolvere in modo documentato tre aree di tensione:

1) Sicurezza vs. operabilità (realtà del ransomware)

Gli attori ransomware prendono di mira in modo mirato backup, account amministrativi e cataloghi di backup. I «buoni» backup richiedono quindi non solo cifratura, ma anche protezione contro la manomissione (immutable, WORM) e separazione delle identità (account/chiavi separati, percorsi amministrativi distinti). Ogni semplificazione operativa può aprire una superficie d’attacco.

2) Pianificabilità dei costi vs. elasticità

On-Prem è tipicamente guidato dal capitale e dal ciclo di vita (CapEx + ammortamento, manutenzione, energia/spazio). Il Cloud è a consumo (OpEx), ma con componenti variabili: classe di storage, richieste API, indicizzazione, Egress (flusso di dati), Cross-Region-Replikation. La pianificabilità dei costi è raggiungibile, ma solo con governance (budget, tag, quote, report).

3) Compliance/residenza dei dati vs. gestione operativa

I requisiti normativi (per es. conservazione, tracciabilità, controllo degli accessi) spesso confliggono con una pratica di backup «semplice». La residenza dei dati non significa solo «scegliere una regione», ma anche: chi ha accesso? Dove risiedono le chiavi? Quali subfornitori sono coinvolti? Come si dimostra un exit? Queste domande devono essere coordinate in acquisti, security e operation.

Opzioni a confronto: On-Prem, Cloud, Hybrid – e quando quale variante ha senso

Backup on‑prem: controllo, ma pieno carico operativo

I backup on‑prem (repository di backup locale, eventuale secondo centro dati o nastro) offrono il massimo controllo sui percorsi dei dati e sulle latenze. Punti di forza tipici:

• Bassa latenza di RESTore nella rete locale, specialmente per grandi volumi di dati (VM-Images, file server).
• Chiara sovranità dei dati (controllo fisico, gestione delle chiavi propria, percorso di accesso dedicato).
• Profilo dei costi spesso pianificabile con precisione, quando il lifecycle e la pianificazione della capacità sono maturi.

Debolezze tipiche che in pratica provocano problemi:

• Offsite è laborioso: gestione dei supporti, trasporto, stoccaggio, sito secondario o replica su WAN.
• Scalabilità richiede investimenti anticipati; i picchi di capacità sono costosi.
• Rischio ransomware: se server di backup e storage appartengono alla stessa dominio di identità e di rete, il backup è spesso anch’esso compromesso.

Cloud‑Backup: offsite per impostazione predefinita, ma nuove questioni di costi e controllo

I backup cloud (Object Storage, servizi di cloud backup o repository di backup propri in cloud) sono molto attraenti per l’offsite. Punti di forza:

• Separazione fisica dal proprio centro dati, utile in caso di perdita del sito.
• Scalabilità senza preavviso; lo storage cresce con il fabbisogno.
• Opzioni immutabili (es. Object‑Lock/meccanismi WORM) sono spesso realizzabili in modo tecnicamente solido.

Debolezze e trappole tipiche:

• Costi e tempi di RESTore: ripristini di grandi dimensioni possono diventare costosi e lenti per via della larghezza di banda e dei costi di egress.
• Governance più complessa: Identity & Access Management (IAM), gestione delle chiavi, logging, ruoli del provider, separazione dei tenant.
• Rischio di exit: la RESTituzione dei dati e il cambio di provider devono essere pianificati e testati in modo realistico.

Backup ibrido: standard operativo, ma solo con regole chiare

In molti ambienti l’ibrido (locale veloce + cloud/offsite robusto) è il compromesso migliore. Schema tipico: backup locali rapidi (per il ripristino operativo), più offsite cloud con immutabilità (per disastri e ransomware). Il vantaggio sussiste però solo se si prende decisioni chiare:

• Quali carichi di lavoro devono essere salvati esclusivamente in locale (es. latenza, classificazione dei dati)?
• Quali devono essere necessariamente offsite/immutabili (es. dati ERP/di produzione critici)?
• Come si evita che lo stesso percorso amministrativo possa distruggere sia la produzione sia il backup?

Calcolare costi e benefici con precisione: quali blocchi di costo i CIO spesso trascurano

Una decisione fondata richiede un modello dei costi che rappresenti la realtà – non solo il „prezzo dello storage per TB“. Nella pratica si è dimostrato utile suddividere in costi diretti, indiretti e costi di rischio/conseguenti.

Costi diretti (visibili nel budget)

• Storage: On-Prem (Disco/Nastro/Storage a oggetti), Cloud (classe di archiviazione, replicazione).
• Backup-Software/Subscriptions: Licenze, agenti, metriche di capacità.
• Rete: Collegamento WAN, VPN/Direct Connect, eventualmente linea secondaria.
• Compute per RESTore/Validation: ambienti di test, ripartenza nel Cloud, finestra di ripristino.

Costi indiretti (personale, tempo, processo)

• Onere operativo: patching, monitoring, gestione delle capacità, rotazione dei supporti, risoluzione dei guasti.
• Change Management: nuove applicazioni, nuove fonti dati, nuove policy, nuovi ruoli di accesso.
• Onere per audit e prove: registri, report, evidenze di ripristino, documentazione.

Costi di rischio e conseguenti (rilevanti per il CIO, spesso non nel budget IT)

• Fermo produttivo (ricavi, penali contrattuali, ritardi nelle consegne).
• Perdita di dati (ricostruzione, lavoro correttivo, conseguenze legali).
• Danno reputazionale e escalation fino al consiglio di amministrazione/agli organi di vigilanza.
• Potere negoziale del ransomware: senza un backup dimostrabilmente pulito e isolato la pressione aumenta in modo massiccio.

Per la decisione costo-beneficio è consigliabile un formato che regga anche nel comitato dei rischi: „Costi per classe RTO/RPO raggiunta“ più „rischio residuo“ (quali scenari RESTano critici nonostante il backup?).

Governance e responsabilità: chi decide cosa – e chi firma?

Il backup è un compito trasversale. Se le responsabilità non sono chiare si crea una situazione pericolosa: gestito tecnicamente, ma non legittimato dal punto di vista aziendale. È efficace una chiara attribuzione:

• Responsabile del servizio (Business/IT): definisce la criticità per il business, l’RTO/RPO accettabile, la classificazione dei dati.
• Operazioni IT: implementa le procedure, gestisce il monitoring, esegue test di ripristino, mantiene i runbook.
• Sicurezza: definisce i controlli minimi (immutabilità, MFA, segmentazione, chiavi, logging), verifica le superfici di attacco.
• Compliance/Protezione dei dati: verifica conservazione, accessi, politiche di cancellazione, residenza dei dati, aspetti relativi a paesi terzi.
• CIO/Responsabile IT: decide il livello obiettivo, il perimetro di budget, il rischio residuo accettabile, la strategia dei provider.

Per gli audit non conta che „qualcuno“ se ne occupi, ma che esista un modello operativo tracciabile: policy, eccezioni, cicli di revisione e test basati su evidenze.

Prospettiva audit: quali evidenze sono necessarie nella pratica

Sia revisione interna, revisore esterno o questionario cliente: si ripetono punti di verifica tipici. Se li coprite sistematicamente, il backup passa dall’intuito a una capacità dimostrabile.

Evidenze richieste quasi sempre

• Policy di backup: ambito, frequenza, conservazione, responsabilità, cifratura, offsite.
• Inventario sistemi / mappa dei dati: quali sistemi sono protetti, quali no e perché?
• Test di ripristino: registrazioni, risultati, scostamenti, azioni (incl. test successivo).
• Schema di accesso e gestione delle chiavi: chi può cancellare i backup, chi può eseguire il ripristino, come viene registrato?
• Resilienza al ransomware: componenti immutabili/air-gapped, identità separate, accessi di emergenza.
• Piano di exit (per il Cloud): rimpatrio dei dati, scadenze, ipotesi di costo, passaggi tecnici.

Inquadramento normativo (senza pedanteria sui riferimenti normativi)

Indipendentemente dallo specifico quadro normativo (settoriale, requisiti del cliente, governance interna) si riduce agli stessi principi fondamentali: disponibilità, integrità, riservatezza, tracciabilità e controlli adeguati. È essenziale che giustifichiate il termine «adeguati» in base al vostro fabbisogno di protezione: i sistemi critici ricevono obiettivi RTO/RPO più stringenti, un isolamento più robusto e test più frequenti.

Guide tecniche che semplificano le decisioni

La scelta concreta del prodotto è secondaria se le guide sono corrette. I seguenti meccanismi sono particolarmente rilevanti per il funzionamento:

Immutabilità e Air-Gap: due meccanismi di protezione diversi

Backup immutabili sono protetti tecnicamente contro modifiche/cancellazioni successive (simili a WORM). Questo offre una forte protezione contro il caso «l’amministratore cancella tutto», ma non protegge necessariamente da tutti gli scenari (per es. errata configurazione prima del lock, gestione delle chiavi compromessa o manipolazione del catalogo). Un Air-Gap implica una separazione operativa: i backup non sono raggiungibili dalla rete di produzione in modo temporaneo o permanente. L’Air-Gap può essere implementato fisicamente (nastro), logicamente (rete/account separati) o organizzativamente (ruoli separati, credenziali separate). Nella pratica, le combinazioni risultano più efficaci.

Crittografia: a riposo, in transito e gestione delle chiavi

«Cifrato» è privo di valore senza contesto. Verificate tre livelli: crittografia di trasporto (in transito), memorizzazione (a riposo) e gestione delle chiavi (chi controlla le chiavi, come sono regolate la rotazione e l’accesso d’emergenza). Per la compliance conta inoltre la registrazione degli accessi alle chiavi e il controllo a quattro occhi per le azioni particolarmente critiche.

Rete e identità: la parte sottovalutata dei backup in cloud

Molti disastri di ripristino non sono problemi di dati, ma problemi di rete e identità: rotte mancanti, porte bloccate, credenziali scadute, ruoli errati. Quando il backup va in cloud, il ripristino deve essere testato inclusi i percorsi di rete necessari, le dipendenze DNS e i ruoli IAM. Altrimenti verificate solo il „copiare i dati“, non il „ripristinare il servizio“.

Matrice decisionale: quali workload vengono salvati dove

Una matrice adatta a un CIO non si basa sulla tecnologia, ma sulle caratteristiche del workload. Utilizzate i seguenti criteri come modello standardizzato:

• Criticità: impatto su ricavi/sicurezza/reputazione in caso di indisponibilità
• Tasso di modifica dei dati: influisce su RPO e sul volume di trasferimento
• Volume dei dati: influisce sui tempi di ripristino e sui costi di egress
• Dipendenze: database + file + configurazione + segreti devono essere coerenti insieme
• Compliance: conservazione, obblighi di cancellazione, residenza dei dati, log degli accessi
• Modello di minaccia: obiettivo per immutabilità/Air-Gap, percorsi amministrativi separati

Assegnazioni tipiche (come punto di partenza, non come dogma):

• Tier-1 (critico): possibilità di ripristino locali rapide + offsite immutabile/offline + esercitazioni regolari di ripristino
• Tier-2 (importante): locale o cloud, a seconda del volume di dati; offsite obbligatorio, immutabilità consigliata
• Tier-3 (di supporto): backup economicamente efficiente, RTO/RPO più lunghi, ma comunque capacità di ripristino dimostrabile

Test di ripristino come strumento di controllo: Come raggiungere „0″ in 3-2-1-1-0

La nota regola 3-2-1 (tre copie, due supporti, una offsite) viene oggi spesso estesa a 3-2-1-1-0: aggiunta una copia immutabile/offline e 0 errori nei test di ripristino verificati. La parte „0“ è la componente rilevante per il management: non servono backup perfetti, ma un processo che individui, dia priorità e risolva gli errori.

Cosa devono coprire i test di ripristino nella pratica

• Ripristino file (casi operativi): singoli file, permessi/ACL, stati di versione
• Ripristino applicazioni: database + dati applicativi coerenti, ordine di avvio, stati di configurazione
• Ripristino sistema: VM/server, avviabilità, driver, rete
• Scenario di disaster: riavvio da offsite/cloud incl. IAM, rete, DNS, segreti

Importante per l’auditabilità: ogni test richiede data, ambito, risultato, deviazioni, riferimento ticket e retest. In questo modo il backup diventa „verificabile“ invece che „asserito“.

Liste di controllo pratiche e modelli (utilizzabili per audit)

Checklist 1: rischi del backup cloud prima della messa in produzione

• RTO/RPO per servizio sono stati approvati e documentati?
• Esistono identità separate per il backup (account/tenant/subscription separati) e i diritti di amministratore sono ridotti al minimo?
• I meccanismi di immutabilità sono attivati e protetti contro errate configurazioni (es. Governance-Lock, ruolo separato)?
• La gestione delle chiavi è definita (rotazione, accesso d’emergenza, registrazione)?
• I costi di ripristino (egress, compute temporaneo) sono stati considerati nel modello di budget?
• Esiste un piano di uscita con passi tecnici e ipotesi su tempi/costi?
• È presente monitoraggio per i fallimenti di backup, deriva della policy di retention e stato di immutabilità?

Checklist 2: rischi del backup on-prem prima della messa in produzione

• L’offsite è implementato in modo da coprire perdita di sito e compromissione del dominio?
• Esiste segmentazione di rete (rete di backup) e percorsi amministrativi separati?
• I backup sono protetti contro cancellazione/manomissione (WORM/immutable o supporti offline)?
• La pianificazione della capacità, inclusi crescita e retention, è robusta (nessuna „riduzione silenziosa“ della retention)?

Modello: Policy minima di backup (struttura dei contenuti)

La seguente struttura si è dimostrata efficace per mantenere una policy breve ma verificabile:

• Ambito e termini (Backup vs. Archivio, RTO/RPO, Offsite, immutabile)
• Classificazione dei servizi (modello a tier) e responsabilità
• Frequenze di backup, retention, supporti/target (On-Prem/Cloud)
• Controlli di sicurezza (MFA, ruoli, chiavi, segmentazione, logging)
• Test di RESTore (frequenza, portata, evidenze, escalation)
• Processo di eccezioni (approvazione, durata, misure compensative)
• Ciclo di revisione (es. semestrale) e reporting alla direzione IT/comitato dei rischi

Artefatti di esempio concreti e copiabili (policies & passaggi di verifica)

I blocchi di sorgente seguenti sono intenzionalmente generici per servire come punto di partenza per standard interni. Non sostituiscono una configurazione dettagliata, ma aiutano nella redazione valida per l’audit.

# Beispiel: Backup-Kontrollanforderungen (Kurzstandard)
# Zweck: Mindestkontrollen für alle kritischen Services (Tier-1)

- Es existieren mindestens zwei administrative Rollen:
  (1) Backup-Operator (RESTore/Job-Management)
  (2) Backup-Security-Admin (Retention/Immutability/Policy-Änderungen)

- Backups werden verschlüsselt übertragen und verschlüsselt gespeichert.
  Schlüsselverwaltung: dokumentiert, rotierbar, Zugriffe protokolliert.

- Mindestens eine Kopie ist gegen Löschung/Manipulation geschützt (immutable oder offline).

- RESTore-Tests:
  - monatlich: Stichprobe File/DB-RESTore
  - quartalsweise: Applikations-RESTore in isolierter Testumgebung
  - jährlich: Desaster-Szenario aus Offsite inkl. Netzwerk/IAM

- Nachweisführung:
  - jeder Test erzeugt ein Ticket mit Ergebnis, Abweichungen, Maßnahmen, Nachtest.

# Beispiel: Audit-Fragenkatalog (Auszug)

1) Welche Systeme sind NICHT im Backup-Scope? Wer hat das RESTrisiko genehmigt?
2) Wie wird verhindert, dass ein kompromittiertes Domain-Admin-Konto Backups löscht?
3) Wo ist die letzte erfolgreiche Wiederherstellung eines Tier-1-Services dokumentiert?
4) Wie wird die Einhaltung der Aufbewahrungsfristen technisch erzwungen?
5) Wie sieht der Exit-Plan aus der Cloud aus (Datenrückführung, Kosten, Zeit)?

# Beispiel: RESTore-Runbook-Struktur (ohne Produktbezug)

- Auslöser/Incident-Typ (Ransomware, Hardware-Defekt, Fehlbedienung, Standortausfall)
- Entscheidungsbaum: lokal RESTore vs. offsite RESTore vs. neu bereitstellen + RESTore
- Abhängigkeiten: DNS, Zertifikate, Secrets, IAM-Rollen, Netzwerksegmente
- Reihenfolge: DB -> Middleware -> Applikation -> Batch/Jobs -> Schnittstellen
- Validierung: Datenkonsistenz, Benutzerrechte, Transaktionsstände
- Kommunikation: Stakeholder, Zeitlinien, Dokumentation für Audit/Nachbereitung

Decisioni errate tipiche – e come evitarle

„Siamo nel cloud, quindi il backup è risolto“

Le SLA del cloud non sostituiscono un backup. Molti servizi piattaforma offrono ridondanza, ma non necessariamente il ripristino point-in-time, la conservazione a lungo termine o la protezione da errori logici (errata configurazione, cancellazione, ransomware tramite account compromessi). Chiarite esplicitamente: quali dati sono coperti dai meccanismi del provider e quali no?

„Abbiamo Offsite, quindi siamo al sicuro“

Offsite senza Immutability e senza identità separate può cadere in un attacco proprio come lo On-Prem-Repository. Decisiva è la separazione dei poteri: chi amministra la produzione non deve poter distruggere automaticamente i backup.

«Testiamo il ripristino solo una volta all’anno»

Un test annuale è meglio di niente, ma operativamente spesso insufficiente: cambi di personale, salti di versione, nuove dipendenze, nuove chiavi – tutto ciò porta a errori di ripristino silenti. Più sensato è un modello a livelli: test piccoli e frequenti combinati con rare esercitazioni di disastro su larga scala.

Piano di attuazione raccomandato in 6 passi (realizzabile in 90 giorni)

Per i CIO è importante disporre di una sequenza attuabile che riduca rapidamente i rischi e contemporaneamente costruisca governance.

1. Scope & Tiering: classificare i servizi, definire RTO/RPO per ciascun tier, rendere le eccezioni soggette ad approvazione.
2. Architettura target: decidere On-Prem/Cloud/Hybrid per ogni tier, Offsite/Immutability come standard minimo per il Tier-1.
3. Identity & Separation: ruoli separati, MFA, account/subscription separati, logging obbligatorio.
4. Retention & Kostenmodell: imporre tecnicamente la retention, includere i blocchi di costo (incl. RESTore/Egress) nel reporting.
5. Operationalizzare i test di RESTore: calendario dei test, runbook, evidenze (ticket/report), percorsi di escalation.
6. Audit-Readiness: finalizzare la policy, aggregare le evidenze, revisioni regolari (es. semestrali) nel comitato dei rischi.

Conclusione: la migliore strategia di backup è quella che possiate ripristinare regolarmente

La decisione costo-beneficio tra On-Prem e Cloud non è una questione di fede, ma dipende da obiettivi misurabili (RTO/RPO), dal modello di minaccia (Ransomware), dalla governance (ruoli, controlli, evidenze) e da un modello dei costi che incorpori la realtà del ripristino e la capacità di exit. In pratica l’approccio Hybrid è spesso il percorso più sostenibile: locale e veloce per l’operatività quotidiana, cloud/offsite robusto e immutable per il caso critico. È fondamentale gestire i backup come un processo ripetibile con test, responsabilità ed evidenze auditabili – così il backup passa dall’essere una “assicurazione sulla carta” a una resilienza operativa concreta.

Per questo tema sono importanti anche gli Offsite-Backup. Il contributo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.