L'archiviazione di backup fuori sede dovrebbe essere una parte fondamentale del piano di ripristino di emergenza di qualsiasi organizzazione. La capacità di archiviare i dati in una posizione fisica separata, dove potrebbero sopravvivere a un evento catastrofico che distrugge tutti i dati nel data center principale, garantisce la sopravvivenza dei dati e la continuità della tua organizzazione. Un servizio di archiviazione cloud è un metodo abbastanza buono per archiviare i backup fuori sede. Non importa se stai utilizzando un provider cloud o se stai semplicemente copiando i dati su un data center esterno, la crittografia del backup è un must in questi casi. In uno dei nostri blog precedenti, abbiamo discusso di diversi metodi per crittografare i backup. Oggi ci concentreremo su alcune best practice relative alla crittografia di backup.
Assicurati che i tuoi segreti siano al sicuro
Per crittografare e decrittografare i tuoi dati devi utilizzare una sorta di password o chiave. A seconda del metodo di crittografia (simmetrico o asimmetrico), può essere un segreto sia per la crittografia che per la decrittografia oppure può essere una chiave pubblica per la crittografia e una chiave privata per la decrittografia. Ciò che è importante, dovresti tenerli al sicuro. Se ti capita di utilizzare la crittografia asimmetrica, dovresti concentrarti sulla chiave privata, quella che utilizzerai per decrittografare i backup.
Puoi archiviare le chiavi in un sistema di gestione delle chiavi o in un deposito:ci sono numerose opzioni sul mercato tra cui scegliere come Amazon KMS o Hashicorp's Vault. Anche se decidi di non utilizzare tali soluzioni, dovresti comunque applicare pratiche di sicurezza generiche, ad esempio per garantire che solo gli utenti corretti possano accedere alle tue chiavi e password. Dovresti anche considerare la preparazione degli script di backup in modo da non esporre chiavi o password nell'elenco dei processi in esecuzione. Idealmente, mettili nel file invece di passarli come argomento ad alcuni comandi.
Considera la crittografia asimmetrica
La principale differenza tra crittografia simmetrica e asimmetrica è che mentre si utilizza la crittografia simmetrica sia per la crittografia che per la decrittografia, si utilizza una singola chiave o password. Ciò richiede standard di sicurezza più elevati su entrambe le estremità del processo. Devi assicurarti che l'host su cui crittografare i dati sia molto sicuro poiché una perdita della chiave di crittografia simmetrica consentirà l'accesso a tutti i tuoi backup crittografati.
Se invece utilizzi la crittografia asimmetrica, hai due chiavi:la chiave pubblica per crittografare i dati e la chiave privata per la decrittazione. Questo rende le cose molto più semplici:non devi preoccuparti della chiave pubblica. Anche se fosse compromesso, non consentirà comunque alcun tipo di accesso ai dati dai backup. Devi concentrarti solo sulla sicurezza della chiave privata. È più semplice:molto probabilmente stai crittografando i backup su base giornaliera (se non più frequente) mentre il ripristino avviene di tanto in tanto, rendendo possibile archiviare la chiave privata in una posizione più sicura (anche su un dispositivo fisico dedicato). Di seguito è riportato un esempio molto rapido su come utilizzare gpg per generare una coppia di chiavi e utilizzarla per crittografare i dati.
Innanzitutto, devi generare le chiavi:
[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
"Krzysztof Ksiazek (Backup key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.Questo ha creato chiavi sia pubbliche che private. Successivamente, vuoi esportare la tua chiave pubblica da utilizzare per crittografare i dati:
gpg --armor --export [email protected] > mybackupkey.ascSuccessivamente, puoi usarlo per crittografare il tuo backup.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupInfine, un esempio di come puoi utilizzare la tua chiave primaria (in questo caso è archiviata nel keyring locale) per decrittografare i tuoi backup:
[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5
You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)
gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
"Krzysztof Ksiazek (Backup key) <[email protected]>"Ruota le tue chiavi di crittografia
Indipendentemente dal tipo di crittografia che hai implementato, simmetrica o asimmetrica, devi pensare alla rotazione della chiave. Prima di tutto, è molto importante disporre di un meccanismo in atto per ruotare i tasti. Questo potrebbe essere utile in caso di violazione della sicurezza e dovresti cambiare rapidamente le chiavi che usi per la crittografia e la decrittografia del backup. Naturalmente, in caso di violazione della sicurezza, è necessario considerare cosa accadrà con i vecchi backup crittografati utilizzando chiavi compromesse. Sono stati compromessi, sebbene possano essere ancora utili e necessari secondo l'obiettivo del punto di ripristino. Sono disponibili un paio di opzioni, tra cui la ricrittografia o lo spostamento in una localizzazione non compromessa.
Accelera il processo di crittografia parallelizzandolo
Se hai un'opzione per implementare la parallelizzazione del processo di crittografia, considerala. Le prestazioni di crittografia dipendono principalmente dalla potenza della CPU, quindi consentire a più core della CPU di lavorare in parallelo per crittografare il file dovrebbe comportare tempi di crittografia molto inferiori. Alcuni degli strumenti di crittografia offrono tale opzione. Uno di questi è xtrabackup che ha un'opzione per utilizzare la crittografia incorporata e parallelizzare il processo.
Quello che stai cercando sono le opzioni "--encrypt-key" o "--encrypt-key-file" che abilitano la crittografia incorporata. Mentre lo fai puoi anche definire "--encrypt-threads" e "--encrypt-chunk-size". In secondo luogo aumenta un buffer funzionante per la crittografia, in primo luogo definisce quanti thread devono essere utilizzati per la crittografia.
Naturalmente, questa è solo una delle soluzioni che puoi implementare. Puoi ottenerlo usando gli strumenti della shell. Un esempio qui sotto:
[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream |split -b 60M - backup ; ls backup* | parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'Questa non è affatto una soluzione perfetta in quanto devi sapere in anticipo quanto sarà grande, più o meno, il backup per dividerlo in un numero predefinito di file che corrispondono al livello di parallelizzazione che vuoi ottenere (se vuoi usare 2 CPU core, dovresti avere due file, se vuoi usare 4 core, 4 file ecc.). Richiede anche uno spazio su disco che sia il doppio della dimensione del backup, poiché inizialmente genera più file utilizzando la divisione e quindi la crittografia crea un altro set di file crittografati. D'altra parte, se le dimensioni del tuo set di dati sono accettabili e desideri migliorare le prestazioni di crittografia, questa è un'opzione che puoi prendere in considerazione. Per decrittografare il backup dovrai decrittografare ciascuno dei singoli file e quindi utilizzare "cat" per unirli insieme.
Verifica i tuoi backup
Non importa come implementerai la crittografia di backup, devi testarla. Prima di tutto, tutti i backup devono essere testati, crittografati o meno. I backup potrebbero non essere completi o potrebbero essere danneggiati da qualche tipo. Non puoi essere sicuro che il tuo backup possa essere ripristinato fino a quando non esegui effettivamente il ripristino. Ecco perché la verifica regolare del backup è d'obbligo. La crittografia aggiunge maggiore complessità al processo di backup. I problemi possono presentarsi al momento della crittografia, ancora una volta:bug o problemi tecnici possono danneggiare i file crittografati. Una volta crittografato, la domanda è se è possibile decrittografarlo e ripristinarlo?
Dovresti avere un processo di test di ripristino in atto. Idealmente, il test di ripristino verrebbe eseguito dopo ogni backup. Come minimo, dovresti testare i tuoi backup un paio di volte all'anno. Sicuramente devi testarlo non appena è stata introdotta una modifica nel processo di backup. Hai aggiunto la compressione al backup? Hai cambiato il metodo di crittografia? Hai ruotato la chiave di crittografia? Tutte queste azioni potrebbero avere un impatto sulla tua capacità di ripristinare effettivamente il backup. Pertanto dovresti assicurarti di testare l'intero processo dopo ogni modifica.
ClusterControl può automatizzare il processo di verifica, sia su richiesta che programmato dopo ogni backup.
Per verificare un backup esistente, devi solo selezionare quello dall'elenco, fare clic sull'opzione "Ripristina" e quindi eseguire la procedura guidata di ripristino. Innanzitutto, devi verificare quale backup desideri ripristinare.
Quindi, nel passaggio successivo, dovresti selezionare l'opzione di ripristino e verifica.
È necessario passare alcune informazioni sull'host su cui si desidera testare il ripristino. Deve essere accessibile tramite SSH dall'istanza ClusterControl. Puoi decidere di mantenere il server di test di ripristino attivo e funzionante (e quindi scaricare alcuni dati parziali da esso se desideri eseguire un ripristino parziale) o spegnerlo.
Il passaggio finale consiste nel verificare se hai fatto le scelte corrette. Se sì, puoi avviare il processo di verifica del backup.
Se la verifica è stata completata correttamente, vedrai che il backup è contrassegnato come verificato nell'elenco dei backup.
Se si desidera automatizzare questo processo, è possibile anche con ClusterControl. Quando pianifichi il backup puoi abilitare la verifica del backup:
Questo aggiunge un altro passaggio nella procedura guidata di pianificazione del backup.
Anche qui devi definire l'host che vuoi utilizzare per i test di ripristino del backup, decidere se vuoi installare il software su di esso (o forse l'hai già fatto), se vuoi mantenere attivo il server di ripristino e se vuoi testare il backup subito dopo che è stato completato o forse vuoi aspettare un po'.
