Di solito ci prendiamo cura delle cose che apprezziamo, che si tratti di uno smartphone costoso o dei server dell'azienda. I dati sono una delle risorse più importanti dell'organizzazione e, sebbene non li vediamo, devono essere protetti con cura. Implementiamo la crittografia dei dati inattivi per crittografare i file di database o interi volumi che contengono i nostri dati. Implementiamo la crittografia dei dati in transito utilizzando SSL per assicurarci che nessuno possa annusare e raccogliere i dati inviati attraverso le reti. I backup non sono diversi. Non importa se si tratta di un backup completo o incrementale, memorizzerà almeno una parte dei tuoi dati. Pertanto, anche i backup devono essere crittografati. In questo post del blog, esamineremo alcune opzioni che potresti avere quando si tratta di crittografare i backup. Per prima cosa, diamo un'occhiata a come puoi crittografare i tuoi backup e quali potrebbero essere i casi d'uso per questi metodi.
Come crittografare il backup?
Crittografa file locale
Prima di tutto, puoi crittografare facilmente i file esistenti. Immaginiamo di avere un processo di backup che archivia tutti i backup su un server di backup. Ad un certo punto hai deciso che era giunto il momento di implementare l'archiviazione di backup fuori sede per il ripristino di emergenza. Per questo puoi utilizzare S3 o un'infrastruttura simile di altri provider cloud. Ovviamente, non vuoi caricare backup non crittografati ovunque al di fuori della tua rete affidabile, quindi è fondamentale implementare la crittografia dei backup in un modo o nell'altro. Un metodo molto semplice, che non richiede modifiche agli script di backup esistenti, consiste nel creare uno script che prenderà un file di backup, lo crittograferà e lo caricherà su S3. Uno dei metodi che puoi utilizzare per crittografare i dati è utilizzare openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordQuesto creerà un nuovo file crittografato, "backup_file.tar.gz.enc" nella directory corrente. Puoi sempre decifrarlo in un secondo momento eseguendo:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordQuesto metodo è molto semplice, ma presenta alcuni inconvenienti. Il più grande sono i requisiti di spazio su disco. Quando si crittografa come descritto sopra, è necessario mantenere sia il file non crittografato che quello crittografato e, di conseguenza, è necessario uno spazio su disco doppio rispetto alle dimensioni del file di backup. Naturalmente, a seconda delle tue esigenze, questo potrebbe essere qualcosa che desideri:mantenere i file non crittografati localmente migliorerà la velocità di ripristino, dopo che anche la decrittografia dei dati richiederà del tempo.
Crittografa il backup al volo
Per evitare la necessità di archiviare dati crittografati e non crittografati, potresti voler implementare la crittografia nella fase precedente del processo di backup. Possiamo farlo attraverso i tubi. Le pipe sono, in breve, un modo per inviare i dati da un comando all'altro. Ciò consente di creare una catena di comandi che elabora i dati. Puoi generare i dati, quindi comprimerli e crittografarli. Un esempio di tale catena potrebbe essere:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encPuoi anche usare questo metodo con xtrabackup o mariabackup. In effetti, questo è l'esempio della documentazione di MariaDB:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encSe lo desideri, puoi anche provare a caricare i dati come parte del processo:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mysecretpassword | tee -a mysqldump.gz.enc | nc 10.0.0.102 9991Di conseguenza, vedrai un file locale "mysqldump.gz.enc" e una copia dei dati verrà inviata a un programma che farà qualcosa al riguardo. Abbiamo usato 'nc', che trasmetteva i dati a un altro host su cui è stato eseguito quanto segue:
nc -l 9991 > backup.gz.encIn questo esempio abbiamo usato mysqldump e nc ma puoi usare xtrabackup o mariabackup e alcuni strumenti che caricheranno lo stream su Amazon S3, Google Cloud Storage o qualche altro provider cloud. Qualsiasi programma o script che accetta dati su stdin può essere utilizzato al posto di 'nc'.
Utilizza la crittografia incorporata
In alcuni casi, uno strumento di backup ha incorporato il supporto per la crittografia. Un esempio qui è xtrabackup, che può crittografare internamente il file. Sfortunatamente, mariabackup, anche se è un fork di xtrabackup, non supporta questa funzione.
Prima di poterlo utilizzare, dobbiamo creare una chiave che verrà utilizzata per crittografare i dati. Può essere fatto eseguendo il seguente comando:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup può accettare la chiave in formato testo normale (usando l'opzione --encrypt-key) o può leggerla da file (usando l'opzione --encrypt-key-file). Quest'ultimo è più sicuro poiché il passaggio di password e chiavi come testo normale ai comandi comporta la loro memorizzazione nella cronologia di bash. Puoi anche vederlo chiaramente nell'elenco dei processi in esecuzione, il che è piuttosto negativo:
root 1130 0.0 0.6 65508 4988 ? Ss 00:46 0:00 /usr/sbin/sshd -D
root 13826 0.0 0.8 93100 6648 ? Ss 01:26 0:00 \_ sshd: [email protected]
root 25363 0.0 0.8 92796 6700 ? Ss 08:54 0:00 \_ sshd: vagrant [priv]
vagrant 25393 0.0 0.6 93072 4936 ? S 08:54 0:01 | \_ sshd: [email protected]/1
vagrant 25394 0.0 0.4 21196 3488 pts/1 Ss 08:54 0:00 | \_ -bash
root 25402 0.0 0.4 52700 3568 pts/1 S 08:54 0:00 | \_ sudo su -
root 25403 0.0 0.4 52284 3264 pts/1 S 08:54 0:00 | \_ su -
root 25404 0.0 0.4 21196 3536 pts/1 S 08:54 0:00 | \_ -su
root 26686 6.0 4.0 570008 30980 pts/1 Sl+ 09:48 0:00 | \_ innobackupex --encrypt=AES256 --encrypt-key=TzIZ7g+WzLt0PXWf8WDPf/sjIt7UzCKw /backup/Idealmente, utilizzerai la chiave memorizzata in un file, ma poi c'è un piccolo problema di cui devi essere a conoscenza.
[email protected]:~# openssl rand -base64 24 > encrypt.key
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
.
.
.
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
encryption: unable to set libgcrypt cipher key - User defined source 1 : Invalid key length
encrypt: failed to create worker threads.
Error: failed to initialize datasink.Potresti chiederti qual è il problema. Diventerà chiaro quando apriremo il file encrypt.key in un editor esadecimale come hexedit:
00000000 6D 6B 2B 4B 66 69 55 4E 5A 49 48 77 39 42 36 72 68 70 39 79 6A 56 44 72 47 61 79 45 6F 75 6D 70 0A mk+KfiUNZIHw9B6rhp9yjVDrGayEoump.Ora puoi notare l'ultimo carattere codificato usando "0A". Questo è fondamentalmente il carattere di avanzamento riga, ma viene preso in considerazione durante la valutazione della chiave di crittografia. Una volta rimosso, possiamo finalmente eseguire il backup.
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1
xtrabackup: recognized client arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1 --databases-exclude=lost+found --ssl-mode=DISABLED
encryption: using gcrypt 1.6.5
181116 10:11:25 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
181116 10:11:25 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'backupuser' (using password: YES).
181116 10:11:25 version_check Connected to MySQL server
181116 10:11:25 version_check Executing a version check against the server...
181116 10:11:25 version_check Done.
181116 10:11:25 Connecting to MySQL server host: localhost, user: backupuser, password: set, port: not set, socket: /var/lib/mysql/mysql.sock
Using server version 5.7.23-23-57
innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 67108864
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
181116 10:11:25 >> log scanned up to (2597648)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 19 for mysql/server_cost, old maximum was 0
181116 10:11:25 [01] Encrypting ./ibdata1 to /backup/2018-11-16_10-11-25/ibdata1.xbcrypt
181116 10:11:26 >> log scanned up to (2597648)
181116 10:11:27 >> log scanned up to (2597648)
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/server_cost.ibd to /backup/2018-11-16_10-11-25/mysql/server_cost.ibd.xbcrypt
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/help_category.ibd to /backup/2018-11-16_10-11-25/mysql/help_category.ibd.xbcrypt
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/slave_master_info.ibd to /backup/2018-11-16_10-11-25/mysql/slave_master_info.ibd.xbcrypt
181116 10:11:28 [01] ...doneDi conseguenza ci ritroveremo con una directory di backup piena di file crittografati:
[email protected]:~# ls -alh /backup/2018-11-16_10-11-25/
total 101M
drwxr-x--- 5 root root 4.0K Nov 16 10:11 .
drwxr-xr-x 16 root root 4.0K Nov 16 10:11 ..
-rw-r----- 1 root root 580 Nov 16 10:11 backup-my.cnf.xbcrypt
-rw-r----- 1 root root 515 Nov 16 10:11 ib_buffer_pool.xbcrypt
-rw-r----- 1 root root 101M Nov 16 10:11 ibdata1.xbcrypt
drwxr-x--- 2 root root 4.0K Nov 16 10:11 mysql
drwxr-x--- 2 root root 12K Nov 16 10:11 performance_schema
drwxr-x--- 2 root root 12K Nov 16 10:11 sys
-rw-r----- 1 root root 113 Nov 16 10:11 xtrabackup_checkpoints
-rw-r----- 1 root root 525 Nov 16 10:11 xtrabackup_info.xbcrypt
-rw-r----- 1 root root 2.7K Nov 16 10:11 xtrabackup_logfile.xbcryptXtrabackup ha alcune altre variabili che possono essere utilizzate per ottimizzare le prestazioni della crittografia:
- --encrypt-threads consente la parallelizzazione del processo di crittografia
- --encrypt-chunk-size definisce un buffer funzionante per il processo di crittografia.
Se hai bisogno di decrittografare i file, puoi usare innobackupex con l'opzione --decrypt per questo:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Poiché xtrabackup non pulisce i file crittografati, potresti volerli rimuovere utilizzando la seguente riga:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneCrittografia di backup in ClusterControl
Con ClusterControl i backup crittografati sono a portata di clic. Tutti i metodi di backup (mysqldump, xtrabackup o mariabackup) supportano la crittografia. Puoi sia creare un backup ad hoc che preparare una pianificazione per i tuoi backup.
Nel nostro esempio abbiamo scelto un xtrabackup completo, lo memorizzeremo sull'istanza del controller.
Nella pagina successiva abbiamo abilitato la crittografia. Come affermato, ClusterControl creerà automaticamente una chiave di crittografia per noi. Questo è tutto, quando fai clic sul pulsante "Crea backup" verrà avviato un processo.
Il nuovo backup è visibile nell'elenco dei backup. È contrassegnato come crittografato (l'icona del lucchetto).
Ci auguriamo che questo post del blog ti fornisca alcune informazioni su come assicurarti che i tuoi backup siano crittografati correttamente.
