Chi gestisce backup mantiene, in sostanza, una seconda copia spesso ancora più appetibile dei dati aziendali più importanti. Proprio per questo Backup-Verschlüsselung und Key-Management non è un „extra“ per la compliance, ma un requisito operativo: senza una cifratura accurata i repository offsite, l’archiviazione su nastro o l’object storage rappresentano una perdita di dati annunciata. Senza una gestione chiavi corretta, invece, i backup in caso di emergenza sono inutili, perché nessuno può più decifrarli.
Questa guida pratica è rivolta ad amministratori, ingegneri di sistema, operatori e fornitori di servizi IT tecnici. Focus: logica decisionale chiara, cause d’errore tipiche, passaggi di verifica e un’implementazione che non sacrifichi la capacità di RESTore al modello di sicurezza. Dove opportuno, definiamo i termini direttamente: „At REST“ indica la cifratura dei dati memorizzati, „In Transit“ la cifratura della trasmissione (di norma via TLS). „KMS“ (Key Management Service) è un servizio centrale per la gestione delle chiavi, „HSM“ (Hardware Security Module) è hardware che genera e utilizza le chiavi con protezione rafforzata.
Backup-Verschlüsselung und Key-Management in der Praxis
La cifratura dei backup mira primariamente alla riservatezza. Protegge dall’esfiltrazione di dati quando:
- I supporti di backup (disk, tape, supporti rimovibili) vengono persi o rubati,
- l’object storage (compatibile S3, archivi cloud) è configurato in modo errato,
- un attaccante ottiene accesso al repository di backup (p. es. server di backup compromesso o credenziali rubate).
Non sono invece risolti automaticamente l‘integrità e la disponibilità. Un backup cifrato può comunque essere manipolato, cancellato o reso inutilizzabile da ransomware. Per questo servono misure complementari: Immutable Storage (WORM/Object-Lock), strategie air-gap, identità separate, permessi rigorosi e, soprattutto, test di RESTore regolari.
Punto pratico importante: molti team cifrano „in qualche modo“, ma dimenticano di documentare il modello di minaccia. Poi si prendono decisioni sbagliate sul se cifrare lato client (prima dell’upload) o se la cifratura lato storage sia sufficiente (server-side encryption). La risposta dipende da chi si fida del sistema di storage e del relativo percorso di amministrazione.
Grundlagen: At REST, In Transit, Client-seitig vs. Repository-seitig
Nella pratica si incontrano di norma tre livelli:
- Cifratura del trasporto (In Transit): TLS protegge i dati durante il trasferimento tra backup-agent, proxy, repository e, se presente, cloud-gateway. Previene l’intercettazione in rete, ma non è efficace se il sistema di destinazione è compromesso.
- Cifratura a riposo (At REST) a livello di storage: ad es. cifratura nell’object storage o nel filesystem/volume (LUKS/BitLocker). Facile da attivare, ma le chiavi spesso risiedono nello stesso contesto amministrativo dello storage.
- Cifratura lato backup o lato client: i dati vengono cifrati prima della memorizzazione. Lo storage vede solo testo cifrato. Questo riduce il rischio del caso „l’amministratore dello storage può tutto“, ma aumenta i requisiti di key management e dei processi di RESTore.
Per molti ambienti è sensato combinare: TLS per il trasporto, cifratura lato backup per il contenuto e controlli dello storage (Immutable/Object-Lock) per la protezione dalle cancellazioni. È decisivo non limitarsi a dire „cifrato“, ma specificare con precisione dove e con quali chiavi avviene la cifratura.
Key-Management in der Realität: Was muss ein Betriebskonzept aBDEcken?
„Key-Management“ im esercizio significa più di una cassaforte sicura per una password. Comprende almeno:
- Generazione delle chiavi: fonte di entropia forte, algoritmi definiti (p. es. AES-256 per la crittografia simmetrica dei dati), responsabilità chiare.
- Conservazione delle chiavi: separata dal repository di backup, idealmente in un KMS o in un HSM.
- Controllo degli accessi: chi può cifrare, chi può decifrare e in quali condizioni (Break-Glass).
- Rotazione: sostituzione pianificabile delle chiavi senza perdita di dati e senza caos durante il ripristino.
- Versionamento: i backup devono essere associati in modo tracciabile a un identificatore di chiave.
- Ripristino: come si rende disponibile una chiave in caso di disastro, p. es. se i sistemi di identity vengono a mancare?
- Audit: registrazione degli accessi alle chiavi, idealmente resistente alle manomissioni.
Trappola tipica: le chiavi si trovano „praticamente“ sul server di backup in un file che a sua volta viene incluso nel backup. In tal caso la crittografia, in caso di attacco, è spesso solo un ostacolo per estranei, non per un attaccante con accesso al repository. Lobiettivo è una separazione tra percorso dei dati e percorso delle chiavi: i backup possono risiedere in molti luoghi, le chiavi no.
Envelope Encryption: Perché la crittografia dei backup moderna raramente è „una chiave per tutto“
In grandi ambienti si è affermata la Envelope Encryption. In questo schema ci sono due livelli di chiave:
- DEK (Data Encryption Key): una chiave simmetrica che cifra i dati di backup. Il DEK può essere generato per job, per set di backup o per oggetto.
- KEK (Key Encryption Key): una chiave „superiore“ che cifra il DEK (wrap/unwrap). Il KEK risiede nel KMS/HSM.
Il vantaggio: quando ruotate, tipicamente ruotate il KEK nel KMS, senza dover ricifrare ogni backup storico. Inoltre potete ottenere una granularit molto fine (p. es. un KEK per tenant), senza dover gestire manualmente un numero ingombrante di chiavi a lungo termine.
Quando fallisce questo approccio? Spesso quando il software di backup dichiara di „supportare il KMS“, ma in realt memorizza solo un secret statico nella configurazione, oppure quando gli strumenti di ripristino non riescono a raggiungere il KMS (p. es. nella rete di ripartenza isolata). Envelope Encryption vale tanto quanto il vostro percorso di ripristino.
Architettura pratica: separare il percorso delle chiavi, permettere il ripristino
Un quadro operativo solido spesso si presenta cos :
- Server di backup/proxy cifrano i dati prima di scriverli nel repository.
- I DEK vengono generati per set di backup e memorizzati insieme ai metadati (cifrati con il KEK).
- Il KEK risiede nel KMS/HSM; accesso solo tramite identit di servizio dedicate.
- L’ambiente di RESTore ha un accesso definito e limitato al KMS (o un fallback offline documentato).
- Il repository è inoltre protetto contro cancellazione/manipolazione (Immutable/Object-Lock, credenziali separate, amministratori separati).
Importante: „Amministratori separati“ non è un dogma, ma un efficace meccanismo di controllo. Se la stessa identità amministra lo storage, elimina i backup e può estrarre chiavi dal KMS, il danno in caso di compromissione è massimo.
Tipici scenari di errore (e perché spesso emergono solo al momento del ripristino)
1) Rotazione delle chiavi senza piano di ripristino
La rotazione viene attivata, ma nessuno verifica se i backup vecchi RESTano decifrabili. La causa è spesso un vincolo poco chiaro tra i metadati del backup e le versioni delle chiavi. Regola pratica: ogni backup deve avere un Key-Identifier (Key-ID + Version), che sia memorizzato insieme al set di backup e descritto nel runbook di RESTore.
2) „Crittografato“ significa: crittografia dello storage – ma l’amministratore può leggere tutto
La crittografia lato storage è utile, ma non protegge se l’attaccante o un insider dispone degli stessi privilegi di gestione. Per una reale separazione dei tenant o per dati critici, la crittografia lato client è spesso il requisito minimo realistico.
3) Le chiavi sono contenute nel backup stesso
Se si includono file di chiavi o passphrase nei backup, i backup risultano „crittografati“ ma non „protetti“. Separare rigidamente il materiale delle chiavi dai dati di backup. Se per ragioni pratiche è necessario usare file di chiavi: almeno al di fuori del repository, con ACL RESTrittive e uno strato aggiuntivo di protezione (es. OS-Credential-Store o KMS-Wrapper).
4) Il RESTore in caso di disastro fallisce a causa di IAM/Directory
Molti accessi al KMS dipendono da IAM/AD/SSO. Se in caso di disastro il backend di identità non è disponibile, le chiavi non saranno accessibili. Per questo è necessario un concetto di Break-Glass (accesso di emergenza), testato regolarmente e che non si risolva in un „ticket che nessuno trova“.
Implementazione in passaggi: checklist per i team di amministrazione
La sequenza seguente è intenzionalmente pragmatica: può essere adattata a On-Prem, ibrido o cloud.
Passaggio 1: definire classi di dati e obiettivi di backup
- Quali sistemi contengono dati personali, segreti aziendali, credenziali di accesso, materiale di chiavi?
- Quali backup vanno dove (repository disk locale, Offsite, object storage, Tape)?
- Quali requisiti RTO/RPO esistono (RTO = tempo di riavvio, RPO = perdita massima di dati in termini temporali)?
Perché è importante: non tutti i sistemi richiedono la stessa strategia crittografica. Ma non appena i backup lasciano il data center o più parti hanno accesso amministrativo, la separazione delle chiavi diventa rapidamente obbligatoria.
Passaggio 2: definire il livello di crittografia
- Minimo: TLS in transito + crittografia at-REST nel repository.
- Raccomandato in caso di rischio aumentato: crittografia lato client/backup + TLS + repository immutabile.
Trappole: „TLS attivo“ non è sinonimo di sicurezza. Verificate la validazione dei certificati, i protocolli/cipher consentiti e se la crittografia è effettivamente applicata ovunque (proxy, storage-gateway, percorsi di replica).
Passaggio 3: definire l’integrazione KMS/HSM e il modello dei ruoli
Definite ruoli invece di persone: Backup-Service (crittografa), RESTore-Operator (decrittografa secondo il processo), Security/Admin (Key-Policy), Auditor (solo log). Documentate quale identità può utilizzare quale Key, incluse le condizioni (es. solo dalla rete di RESTore, solo durante finestre di manutenzione).
Passo 4: progettazione dei metadati per le versioni delle chiavi
Ogni set di backup dovrebbe essere tracciabile e associato alle seguenti informazioni:
- Key-ID / versione della chiave (o KEK-ID + wrapped DEK)
- Algoritmo/modalità (p.es. AES-GCM, se utilizzato)
- Timestamp di generazione
- Versione del software di backup (per la pianificazione delle migrazioni)
Non è un esercizio accademico. Determina se fra 18 mesi sarete in grado di ripristinare un backup d’archivio in caso di audit.
Passo 5: definire il runbook di ripristino e il fallback
Un runbook è una guida passo-passo per gli operatori. Deve includere:
- Come viene fornito l’accesso al KMS nella rete di ripristino?
- Quali dipendenze esistono (DNS, NTP, percorsi di rete, regole firewall)?
- Come funziona la procedura di break-glass, incl. approvazione e registrazione?
- Come si verifica che i dati ripristinati siano corretti (integrità/avvio dell’applicazione)?
MySQL al centro: crittografia dei backup senza sorprese durante il ripristino
Nella categoria «MySQL» si osservano due percorsi tipici di backup: backup logici (p.es. mysqldump) e backup fisici (p.es. Percona XtraBackup o snapshot del filesystem basati sulle directory dei dati). I backup logici sono più portabili; quelli fisici sono in genere più veloci e più adatti a grandi volumi di dati. In entrambi i casi vale: la crittografia deve essere compatibile con il processo di ripristino.
Backup logici (mysqldump): crittografia praticabile tramite pipeline
I dump logici sono basati su testo/stream. Una pratica robusta è: generare il dump, comprimere, crittografare – e solo dopo archiviarlo. Vantaggio: si vede chiaramente che il repository contiene solo dati cifrati. Rischio: se gestite male le passphrase o la pipeline maschera errori, ve ne accorgerete solo al momento del ripristino.
Esempio (Linux): dump + compressione + crittografia simmetrica con OpenSSL. Qui è importante il gestione degli errori (set -euo pipefail), così che un dump interrotto non venga considerato ’salvato con successo‘.
#!/usr/bin/env bash
set -euo pipefail
umask 077
BACKUP_DIR="/srv/backups/mysql"
DATE_UTC="$(date -u +%Y%m%dT%H%M%SZ)"
OUT_FILE="${BACKUP_DIR}/mysqldump-${DATE_UTC}.sql.gz.enc"
# Passphrase nicht hart codieren: z. B. aus Secret-Store, Root-only Datei oder via KMS-Wrapper.
PASSPHRASE_FILE="/etc/backup/openssl-passphrase"
mkdir -p "${BACKUP_DIR}"
mysqldump --single-transaction --routines --events --triggers --all-databases
| gzip -1
| openssl enc -aes-256-cbc -salt -pbkdf2 -iter 200000
-pass file:"${PASSPHRASE_FILE}"
-out "${OUT_FILE}"
# Minimaler Sanity-Check: Datei existiert und ist nicht leer
test -s "${OUT_FILE}"Perché funziona: –single-transaction permette con InnoDB dump consistenti senza lock globali (InnoDB è il motore di storage MySQL più diffuso con log di transazione). La compressione riduce l’I/O, la crittografia protegge i dati a riposo. Quando fallisce: con database molto grandi mysqldump può essere troppo lento; inoltre i file di passphrase rappresentano un rischio se il backup-host viene compromesso. In ambienti più regolamentati sostituite la passphrase con un workflow DEK supportato da KMS.
Backup fisici (XtraBackup/Datei-Ebene): associare in modo coerente chiavi e metadati
I backup fisici copiano i file di dati e le informazioni di log. Sono veloci, ma meno «autoesplicativi». Per la crittografia è decisivo dove avviene la cifratura: nello strumento di backup, nel filesystem o solo nel repository.
Best Practice in esercizio: implementare la crittografia in modo che il ripristino sia possibile anche in una rete di riavvio isolata. Cioè: l’identificatore della chiave e la gerarchia di chiavi necessaria devono essere reperibili nei metadati del backup, senza dover cercare nella rete di produzione.
Troubleshooting: quando il ripristino fallisce a causa delle chiavi
Tipici sintomi e verifiche che si sono dimostrati efficaci in produzione:
- «Decryption failed»: Verificare che la versione della chiave sia corretta (rotazione), che venga raggiunto l’endpoint KMS giusto, che l’orario/NTP sia sincronizzato (alcune policy KMS dipendono dal tempo), e che il truststore TLS sia corretto.
- «Access denied» durante il key-unwrap: Verificare ruoli/policy. Spesso nella rete di ripristino manca l’identità di servizio corretta o la sorgente di rete non è autorizzata.
- Il backup è decifrabile, ma MySQL non si avvia: In questo caso non è un problema di chiavi, ma di consistenza (binlog mancanti, snapshot incompleto, processo di ripristino errato). Tuttavia accade spesso insieme, perché i team esercitano raramente il ripristino end-to-end.
Verifica che fa risparmiare tempo: pianificate almeno mensilmente un drill di ripristino che utilizzi esplicitamente i percorsi KMS/chiave. Non solo «il file si può decifrare», ma «MySQL si avvia e risponde a una query di controllo definita».
Controllare invece di sperare: rendere la crittografia dimostrabile
«Abbiamo attivato la crittografia» non è una metrica operativa. Utili sono verifiche semplici e ripetibili:
1) Verifica a riposo nel repository
Campione: nel repository sono presenti soltanto file ciphertext? È attiva la crittografia lato server? Ci sono errate configurazioni come bucket pubblici o ACL troppo ampie? Per l’object storage vanno considerati versioning e policy di Object Lock, se il vostro scenario di ransomware prevede la cancellazione.
2) Verifica in transito
Verificate i percorsi TLS (Backup-Agent → Proxy → Repository, Replicazione, canali di gestione). Una lacuna comune è un percorso non cifrato «interno» che successivamente, tramite accoppiamenti tra sedi, assume carattere WAN.
3) Verifica della gestione delle chiavi
- Esiste un ciclo di vita delle chiavi documentato (creazione, rotazione, disattivazione, cancellazione)?
- Ci sono log di audit per l’utilizzo delle chiavi?
- La procedura Break-Glass è documentata e testata?
4) Prova di ripristino (decisiva)
Pianificate i test di ripristino in modo che verifichino le dipendenze reali: KMS raggiungibile, identità disponibile, segmento di rete corretto, l’operatore può trovare gli artefatti giusti. Un test di ripristino eseguito „con diritti di amministratore in produzione“ dice poco sul caso reale.
Strategia di fallback: cosa fare se KMS o le chiavi non sono disponibili?
La realtà più dura in caso di disastro non è „troppa poca crittografia“, ma „troppa dipendenza“. Perciò serve una strategia di fallback che bilanci il livello di sicurezza e la ripresa operativa:
- Offline-Key-Escrow: un backup cifrato e strettamente controllato del KEK/Root-Key (a seconda del sistema) in un processo separato. Accesso solo secondo il principio delle quattro mani. Importante: Escrow non significa „chiave su USB nell’armadio“, ma custodia controllata con protocollazione.
- RESTore-KMS im DR-Standort: se avete due sedi, un secondo deployment KMS (con policy/chiavi replicate) può ridurre la dipendenza. Questo però deve essere testato, altrimenti è solo un diagramma.
- Degradazione temporanea: in casi eccezionali un processo può permettere di eseguire il ripristino in una rete isolata in cui le chiavi vengono rese disponibili. Questo è accettabile solo se la rete è realmente isolata e il processo è documentato in modo chiaro.
Trappole: „Facciamo Break-Glass tramite un account AD.“ Se AD è down, il Break-Glass non vale nulla. Il Break-Glass deve essere consapevolmente indipendente dalla causa di guasto più comune.
Dettagli operativi spesso dimenticati
Monitorare separatamente chiavi e backup
Il job di backup „verde“ non significa che il key-unwrap funzioni durante il ripristino. Integrate il monitoring con controlli delle chiavi: raggiungibilità del KMS, latenza, tassi di errore nelle operazioni di encrypt/decrypt, date di scadenza dei certificati (TLS verso il KMS).
Change-Management: i parametri crittografici sono parametri di compatibilità
Se modificate algoritmi, parametri KDF (p.es. iterazioni PBKDF2), modalità di cifratura o librerie, trattatelo come una modifica di interfaccia. Documentate da quale data quali parametri si applicano e verificate la retrocompatibilità nel laboratorio di ripristino.
Conservazione e cancellazione: la cancellazione delle chiavi è la cancellazione dei dati
Nella pratica si usa il „Crypto-Shredding“: quando una chiave viene cancellata, i dati diventano di fatto non più decifrabili. Questo può essere voluto (p.es. alla fine della retention), ma è pericoloso se accade involontariamente. Predisponete meccanismi di protezione chiari contro la cancellazione accidentale delle chiavi (p.es. quorum/approvazione, Soft-Delete, Recovery-Window).
Checklist operativa compatta: Go-Live e esercizio operativo
Go-Live
- Modello delle minacce documentato (esfiltrazione dati, insider, Ransomware, perdita della sede)
- Decisione: crittografia lato client vs. lato repository motivata
- Gerarchia delle chiavi definita (DEK/KEK), Key-IDs nel percorso dei metadati del backup
- Ruoli/identità definiti (Backup, RESTore, Admin, Audit), privilegi minimi
- TLS end-to-end verificato (incl. replicazione)
- Immutable/Retention-Controls attivati e testati (tentativo di cancellazione come caso di test)
- RESTore-Runbook creato, incl. rete DR, dipendenze, Break-Glass
- Primo RESTore-Drill riuscito (non solo decifratura, ma funzionamento del sistema)
Operatività continuativa (mensile/trimestrale)
- Ripristino a campione con percorso KMS (versioni delle chiavi, policy, rete)
- Revisione dei log di audit delle chiavi (accessi sospetti, tentativi falliti)
- Rotazione testata (ripristinabile: vecchio + nuovo)
- Certificati e truststore verificati (componenti KMS/backup)
- Documentazione aggiornata (ID chiavi, processi, responsabilità)
Conclusione: un backup è sicuro solo quando chiavi e ripristino operano insieme
La cifratura dei backup e il key management nella pratica sono «completi» solo se si combinano tre elementi: primo, una decisione chiara su dove viene eseguita la cifratura (e contro chi); secondo, un solido concetto di chiavi con separazione del percorso dati da quello delle chiavi; terzo, esercitazioni di ripristino regolari che verifichino le dipendenze reali. Soprattutto con MySQL la protezione tecnica si costruisce rapidamente – ma la capacità di ripristino a lungo termine dipende dai metadati, dalle versioni delle chiavi e da un runbook che funzioni anche sotto stress.
Se desiderate operazionalizzare ulteriormente la vostra strategia di backup: un passo successivo sensato è istituire esercitazioni di ripristino e controlli di validazione come processo consolidato, testando esplicitamente i percorsi di cifratura e KMS.
Anche la cifratura dei backup è rilevante per questo tema. Il contributo inquadra questi aspetti in modo chiaro e indica cosa è importante nella pratica quotidiana.