Backup cloud per aziende: come farlo e cosa chiede la legge

La risposta breve: il backup cloud per un'azienda è una copia di dati, server e configurazioni conservata in un servizio cloud e ripristinabile in tempi noti. Funziona se rispetta tre condizioni: almeno una copia che chi attacca non può cancellare (immutabile o offline), credenziali separate da quelle della produzione, test di ripristino periodici. Vale anche per Microsoft 365 e Google Workspace, dove il cestino non è un backup.

Cosa si intende per backup cloud aziendale

Dietro la stessa parola ci sono tre lavori diversi, e un'azienda mid-market di solito li ha tutti e tre:

• Server e macchine in sede copiati in cloud. È il backup server classico, con la destinazione spostata da un nastro o da un NAS a uno storage cloud.
• Workload che vivono già in cloud. Macchine virtuali, database e storage su AWS, Azure o Google Cloud, copiati con i servizi di backup del provider o con strumenti di terze parti.
• Applicazioni SaaS. Posta, file e siti su Microsoft 365 o Google Workspace, che molte aziende considerano già al sicuro perché stanno nel cloud.

Il terzo caso è quello che si trascura più spesso, quindi partiamo da lì.

Il provider non fa già il backup?

Il provider garantisce la disponibilità del servizio e la ridondanza della sua infrastruttura. Recuperare un file cancellato da un dipendente, una casella svuotata da un attaccante o una cartella cifrata da un ransomware è un'altra questione, e ha limiti precisi.

Un esempio documentato: in Google Workspace un file resta nel cestino di Drive per 30 giorni, poi viene eliminato. Dopo che l'utente ha svuotato il cestino, l'amministratore ha 25 giorni per recuperarlo; passato quel termine, scrive Google nella guida per gli amministratori, i file vengono rimossi dai sistemi e non sono più recuperabili. Se l'account dell'utente viene eliminato, i suoi file si recuperano entro 20 giorni.

Microsoft, dal canto suo, vende Microsoft 365 Backup come servizio separato, a consumo, per SharePoint, OneDrive ed Exchange Online, e lo presenta proprio per il ripristino dopo un ransomware o una cancellazione accidentale o malevola. Il fatto stesso che esista un prodotto dedicato dice che la conservazione standard non copre quei casi.

La regola pratica: per ogni servizio SaaS va scritto quanto indietro si può tornare oggi, per quale tipo di dato e con quali passaggi. Se la risposta è il cestino, il backup non c'è.

La regola 3-2-1, riletta per il cloud

La regola più citata si trova in una scheda prodotta nel 2012 per l'US-CERT e oggi pubblicata sul sito di CISA (Data Backup Options): tre copie di ogni file importante, cioè l'originale e due backup, su due tipi di supporto diversi, con una copia fuori sede. Il cloud risolve in modo naturale la copia fuori sede. Non risolve il resto.

Il punto debole è un altro: se la copia in cloud si raggiunge con le stesse credenziali, o dallo stesso account, della produzione, chi compromette la produzione compromette anche il backup. Nella #StopRansomware Guide (settembre 2023) CISA raccomanda backup offline e cifrati dei dati critici, e spiega che molte varianti di ransomware cercano i backup raggiungibili per cancellarli o cifrarli. Per i backup da cloud a cloud suggerisce di valutare un secondo fornitore, nel caso in cui tutti gli account presso lo stesso fornitore vengano colpiti.

Tradotto in scelte concrete:

• il backup sta in un account, una subscription o un progetto separato da quello di produzione;
• le identità che lo amministrano sono diverse da quelle che amministrano la produzione, con MFA e permessi minimi;
• almeno una copia non può essere cancellata prima della scadenza, nemmeno da un amministratore.

L'ultimo punto ha un nome: backup immutabile.

Backup immutabile: cosa garantisce e cosa no

Un backup immutabile è una copia che, per un periodo stabilito, non può essere modificata né cancellata. I tre provider principali lo offrono con meccanismi simili:

• AWS Backup Vault Lock. In modalità governance il blocco può essere tolto da chi ha i permessi IAM adeguati. In modalità compliance, finito un periodo di ripensamento di almeno 3 giorni, né il cliente né AWS possono modificare o eliminare il vault finché contiene punti di ripristino, e i backup non si cancellano prima della fine del loro ciclo di vita, neppure dall'utente root.
• Azure Backup, immutable vault. L'immutabilità si attiva sul vault e blocca le operazioni che porterebbero alla perdita dei punti di ripristino. Finché è solo attiva si può disattivare; una volta bloccata diventa irreversibile, e Microsoft raccomanda di bloccarla dopo averne verificato l'impatto.
• Google Cloud Backup and DR, backup vault. Il vault ha una conservazione minima obbligatoria, da 1 giorno a 99 anni, durante la quale nessuno, Google compreso, può cancellare manualmente i backup. La conservazione si può bloccare, e da quel momento nessuno può ridurla, nemmeno il Project Owner.

Tre avvertenze, tutte scritte dai provider o da CISA:

1. Il blocco è per sempre, anche negli errori. AWS avverte che un punto di ripristino con conservazione illimitata, in un vault bloccato in modalità compliance, resta per sempre e continua a generare costi di storage. CISA invita a usare lo storage immutabile con cautela, perché per alcune normative non soddisfa i requisiti e una configurazione sbagliata può costare molto.
2. Immutabile non vuol dire indistruttibile. AWS precisa che, se l'account viene chiuso, resta sospeso 90 giorni con i backup intatti, poi il contenuto del vault viene cancellato anche con il blocco attivo. Per questo la copia immutabile sta meglio in un account dedicato.
3. Le parole contano. Microsoft distingue tra storage immutabile e storage append-only: il suo Microsoft 365 Backup impedisce di modificare i punti di ripristino ma non ne vieta la cancellazione, che lascia all'amministratore del servizio, con un periodo di 90 giorni per recuperarli dopo la disattivazione. Quando un fornitore scrive immutabile, si chiede cosa impedisce esattamente e a chi.

Backup dei server in cloud: dati, immagini, configurazioni

Per i server, in sede o in cloud, copiare i file non basta a ripartire. Servono tre livelli:

• i dati, con la frequenza che il business tollera di perdere;
• le immagini dei sistemi critici: CISA raccomanda di mantenere aggiornate delle golden image, modelli con sistema operativo e applicazioni già configurati da cui ricostruire rapidamente una macchina virtuale o un server;
• le configurazioni: per le risorse cloud CISA suggerisce l'infrastructure as code, con i template sotto controllo di versione e una copia offline. Anche ACN, come vedremo, chiede il backup dei dati e delle configurazioni.

Un server ripristinato su una configurazione di rete o di identità che non esiste più non riparte. Per questo il backup delle configurazioni va trattato come quello dei dati.

RPO, RTO e test di ripristino

Ogni scelta tecnica discende da due numeri. L'RPO è il punto nel tempo a cui i dati devono poter tornare, quindi quanti dati si accetta di perdere. L'RTO è il tempo entro cui un sistema deve tornare disponibile. Non li decide l'IT: escono dalla business impact analysis, che stabilisce quali attività sono critiche e quanto fermo è tollerabile. Come si leggono i due numeri, e cosa li determina, è spiegato in RPO e RTO: la differenza.

Il test di ripristino è il passaggio che si rimanda più volentieri. Un backup mai ripristinato è un'ipotesi: non si sa se è completo, se le chiavi di cifratura sono disponibili, quanto tempo richiede davvero. CISA chiede di verificare con regolarità disponibilità e integrità dei backup in uno scenario di disaster recovery, e le norme europee, come si vede sotto, vanno nella stessa direzione. Un test utile misura il tempo reale di ripristino e lo confronta con l'RTO, e coinvolge le persone che lo eseguirebbero durante una crisi.

Cosa chiedono NIS2, GDPR, DORA e ISO 27001

NIS2 e misure ACN

L'art. 24, comma 2, lett. c) del D.Lgs. 138/2024 include tra gli elementi che le misure devono comprendere almeno la "continuità operativa, ivi inclusa la gestione di backup, il ripristino in caso di disastro, ove applicabile, e gestione delle crisi". Le misure di base della determinazione ACN 379907/2025 lo traducono nella misura PR.DS-11, "I backup dei dati sono creati, protetti, mantenuti e verificati":

• per i soggetti importanti (allegato 1): backup periodici dei dati e delle configurazioni, coerenti con i piani di continuità operativa e di ripristino in caso di disastro, e, per almeno i sistemi informativi e di rete rilevanti, anche copie di backup offline, con procedure documentate;
• per i soggetti essenziali (allegato 2) si aggiungono, sempre per almeno i sistemi rilevanti, la riservatezza e l'integrità dei backup, assicurate con la protezione fisica dei supporti o con la cifratura, e la verifica periodica dell'utilizzabilità dei backup mediante test di ripristino, svolta in accordo agli esiti della valutazione del rischio.

Il quadro completo degli obblighi è nella nostra guida alla NIS2.

GDPR

L'art. 32, paragrafo 1, lett. c) del GDPR cita tra le misure adeguate "la capacità di ripristinare tempestivamente la disponibilità e l'accesso dei dati personali in caso di incidente fisico o tecnico", e la lett. d) aggiunge una procedura per testare regolarmente l'efficacia delle misure. Come si documentano lo spieghiamo nell'articolo sulle misure di sicurezza dell'art. 32.

DORA

Per banche, assicurazioni e altre entità finanziarie, l'art. 12 del Regolamento (UE) 2022/2554 chiede politiche di backup che definiscano il perimetro dei dati e la frequenza minima in base alla criticità, test periodici delle procedure di backup e di ripristino e, quando il ripristino avviene sui propri sistemi, sistemi fisicamente e logicamente segregati da quelli di origine.

ISO/IEC 27001:2022

Il backup corrisponde al controllo 8.13 dell'Annex A, Information backup. In audit si guardano la politica, l'evidenza che i backup girano e l'evidenza che i ripristini sono stati provati.

Come impostare il backup cloud aziendale

1. Fai l'inventario di cosa va copiato: server, workload cloud, tenant SaaS, configurazioni, chiavi di cifratura.
2. Fissa RPO e RTO per sistema, partendo dalla business impact analysis.
3. Separa il backup dalla produzione: account o progetto dedicato, identità diverse, MFA, permessi minimi.
4. Rendi immutabile almeno una copia, scegliendo con cura la durata prima di bloccarla.
5. Copri il SaaS con un backup vero, non con il cestino o la sola conservazione.
6. Cifra i backup e conserva le chiavi in modo che siano disponibili anche durante un incidente.
7. Prova il ripristino a intervalli fissi, misura i tempi reali e conserva l'evidenza.
8. Controlla la configurazione del backup come qualsiasi altra risorsa cloud: un bucket di backup esposto o un ruolo troppo ampio annullano il resto. I casi più frequenti sono negli errori di configurazione cloud.

In sintesi

Il backup cloud funziona quando almeno una copia è separata dalla produzione, non può essere cancellata prima della scadenza e viene ripristinata davvero, a intervalli fissi. NIS2, GDPR e DORA, con parole diverse, vanno nella stessa direzione: backup legati alle esigenze di continuità del business e capacità di ripristino da provare con test periodici, obbligatori per DORA e per i soggetti NIS2 essenziali. Nella ISO/IEC 27001:2022 il backup ha un controllo dedicato, l'8.13.

I backup in cloud sono risorse cloud come le altre, con permessi e identità che li possono raggiungere. Se vuoi sapere cosa è esposto nel tuo cloud e con quali permessi, puoi partire dalla fotografia del cloud con Wiz, di cui AmagisTech è partner: collegamento via API, senza agenti, a partire da una call di 20 minuti con un advisor cloud.