MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Como criptografar seus backups MySQL e MariaDB


Costumamos cuidar de coisas que valorizamos, seja um smartphone caro ou os servidores da empresa. Os dados são um dos ativos mais importantes da organização e, embora não os vejamos, eles devem ser cuidadosamente protegidos. Implementamos criptografia de dados em repouso para criptografar arquivos de banco de dados ou volumes inteiros que contêm nossos dados. Implementamos criptografia de dados em trânsito usando SSL para garantir que ninguém possa farejar e coletar dados enviados pelas redes. Os backups não são diferentes. Não importa se este é um backup completo ou incremental, ele armazenará pelo menos uma parte de seus dados. Como tal, os backups também precisam ser criptografados. Nesta postagem do blog, examinaremos algumas opções que você pode ter quando se trata de criptografar backups. Primeiro, porém, vamos ver como você pode criptografar seus backups e quais podem ser os casos de uso para esses métodos.

Como criptografar seu backup?

Criptografar arquivo local


Em primeiro lugar, você pode criptografar facilmente os arquivos existentes. Vamos imaginar que você tenha um processo de backup armazenando todos os seus backups em um servidor de backup. Em algum momento, você decidiu que era a hora de implementar o armazenamento de backup externo para recuperação de desastres. Você pode usar o S3 ou infraestrutura semelhante de outros provedores de nuvem para isso. Obviamente, você não deseja fazer upload de backups não criptografados em qualquer lugar fora de sua rede confiável, portanto, é fundamental que você implemente a criptografia de backup de uma forma ou de outra. Um método muito simples, que não requer nenhuma alteração em seus scripts de backup existentes, seria criar um script que pegaria um arquivo de backup, criptografá-lo e enviá-lo para o S3. Um dos métodos que você pode usar para criptografar os dados é usar openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpassword

Isso criará um novo arquivo criptografado, ‘backup_file.tar.gz.enc’ no diretório atual. Você sempre pode descriptografá-lo mais tarde executando:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpassword

Este método é muito simples, mas tem algumas desvantagens. O maior deles são os requisitos de espaço em disco. Ao criptografar como descrito acima, você deve manter o arquivo não criptografado e o criptografado e, como resultado, precisará de um espaço em disco com o dobro do tamanho do arquivo de backup. Claro, dependendo dos seus requisitos, isso pode ser algo que você deseja - manter arquivos não criptografados localmente melhorará a velocidade de recuperação - afinal, descriptografar os dados também levará algum tempo.

Criptografar backup em tempo real


Para evitar a necessidade de armazenar dados criptografados e não criptografados, convém implementar a criptografia no estágio anterior do processo de backup. Podemos fazer isso através de tubos. Pipes são, em suma, uma forma de enviar os dados de um comando para outro. Isso possibilita a criação de uma cadeia de comandos que processa dados. Você pode gerar os dados, compactá-los e criptografar. Um exemplo dessa cadeia pode ser:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.enc

Você também pode usar esse método com xtrabackup ou mariabackup. Na verdade, este é o exemplo da documentação do MariaDB:
mariabackup --user=root --backup --stream=xbstream  | openssl  enc -aes-256-cbc -k mypass > backup.xb.enc

Se quiser, você pode até tentar fazer upload de dados como parte do 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 9991

Como resultado, você verá um arquivo local ‘mysqldump.gz.enc’ e a cópia dos dados será canalizada para um programa que fará algo a respeito. Usamos 'nc', que transmitia dados para outro host no qual o seguinte foi executado:
nc -l 9991 > backup.gz.enc

Neste exemplo, usamos mysqldump e nc, mas você pode usar xtrabackup ou mariabackup e alguma ferramenta que fará o upload do fluxo para o Amazon S3, Google Cloud Storage ou algum outro provedor de nuvem. Qualquer programa ou script que aceite dados em stdin pode ser usado em vez de 'nc'.

Usar criptografia incorporada


Em alguns casos, uma ferramenta de backup tem suporte embutido para criptografia. Um exemplo aqui é o xtrabackup, que pode criptografar o arquivo internamente. Infelizmente, o mariabackup, mesmo sendo um fork do xtrabackup, não suporta esse recurso.

Antes de podermos usá-lo, temos que criar uma chave que será usada para criptografar os dados. Isso pode ser feito executando o seguinte comando:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1Fhunjb

O Xtrabackup pode aceitar a chave em formato de texto simples (usando a opção --encrypt-key) ou pode lê-la do arquivo (usando a opção --encrypt-key-file). O último é mais seguro, pois passar senhas e chaves como texto simples para comandos resulta em armazená-los no histórico do bash. Você também pode ver claramente na lista de processos em execução, o que é bastante ruim:
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, você usará a chave armazenada em um arquivo, mas há uma pequena pegadinha da qual você deve estar ciente. 
[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.

Você pode se perguntar qual é o problema. Ficará claro quando abriremos o arquivo encrypt.key em um editor hexadecimal como o 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.

Agora você pode notar o último caractere codificado usando '0A'. Este é basicamente o caractere de alimentação de linha, mas é levado em consideração ao avaliar a chave de criptografia. Depois de removê-lo, podemos finalmente executar o 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]        ...done

Como resultado, teremos um diretório de backup cheio de arquivos criptografados:
[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.xbcrypt

O Xtrabackup tem algumas outras variáveis ​​que podem ser usadas para ajustar o desempenho da criptografia:
  • --encrypt-threads permite a paralelização do processo de criptografia
  • --encrypt-chunk-size define um buffer de trabalho para o processo de criptografia.

Se você precisar descriptografar os arquivos, você pode usar o innobackupex com a opção --decrypt para isso:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/

Como o xtrabackup não limpa arquivos criptografados, você pode removê-los usando o seguinte one-liner:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; done

Criptografia de backup no ClusterControl


Com o ClusterControl, os backups criptografados estão a apenas um clique de distância. Todos os métodos de backup (mysqldump, xtrabackup ou mariabackup) suportam criptografia. Você pode criar um backup ad hoc ou preparar uma programação para seus backups.

Em nosso exemplo, escolhemos um xtrabackup completo, vamos armazená-lo na instância do controlador.

Na página seguinte, habilitamos a criptografia. Conforme declarado, o ClusterControl criará automaticamente uma chave de criptografia para nós. É isso, ao clicar no botão “Criar Backup” um processo será iniciado.

O novo backup é visível na lista de backups. Ele está marcado como criptografado (o ícone de cadeado).

Esperamos que esta postagem do blog forneça algumas informações sobre como garantir que seus backups sejam criptografados corretamente.