Proteger seus dados é uma das tarefas mais importantes que devemos priorizar. O surgimento de regulamentações que exigem conformidade de segurança, como GDPR, HIPAA, PCI DSS ou PHI, exige que seus dados sejam armazenados com segurança ou transmitidos por fio.
No ClusterControl, valorizamos a importância da segurança e oferecemos uma série de recursos para proteger o acesso ao banco de dados e os dados armazenados. Uma delas é proteger seus backups de banco de dados, tanto em repouso quanto em trânsito. Em trânsito é quando o backup está sendo transferido pela Internet ou rede da origem para seu destino, enquanto em repouso é quando os dados são armazenados em armazenamento persistente. Neste blog, mostraremos como você pode usar o ClusterControl para criptografar seus dados de backup em repouso e em trânsito.
Criptografia em trânsito
Ao gerenciar backups por meio do ClusterControl, usando mysqldump ou Percona Xtrabackup/Mariabackup são gerenciados por padrão sem criptografia quando transmitidos pela rede. No entanto, o uso de TLS/SSL para criptografia de transmissão de dados é suportado pelo MySQL/MariaDB/Percona Server, assim como o Percona Xtrabackup, que oferece opções de SSL ao invocar o comando.
O ClusterControl habilita o SSL por padrão quando você implanta um cluster, mas não tem o controle para alternar instantaneamente e tornar seus dados criptografados durante a criação do backup. Você pode conferir nossos blogs anteriores para a abordagem manual usando ClusterControl ao criar seu cluster ou usando a maneira antiga de configurar manualmente o TLS/SSL no MySQL.
No ClusterControl, ao implantar um cluster, você pode verificar a aba de segurança ou este ícone
. 
Clicando no O botão
permitirá que você substitua o certificado que está sendo usado ou implantado pelo ClusterControl durante a implantação do seu recém-provisionado cacho. Você pode conferir este blog "Atualizado:Torne-se um DBA ClusterControl - SSL Key Management and Encryption of MySQL Data in Transit" para o qual mostramos como lidamos com as chaves. Basicamente, você pode navegar pelo lado esquerdo do ClusterControl e clicar em “Gerenciamento de Chaves”. Abaixo está um exemplo de Gerenciamento de Chaves no qual você pode criar e importar suas chaves existentes.
Ao criar um backup usando mysqldump como seu backup lógico, para criptografar seus dados, certifique-se de ter suas opções de SSL configuradas adequadamente.
O que vem a seguir?
Como temos nossos certificados criados, precisamos habilitar e configurar o SSL de acordo. Para garantir isso, você pode verificar via ClusterControl ou prompt de comando mysql. Veja imagens abaixo:
ou você pode verificar também na aba Performance e clicar em DB Variables como visto abaixo:
Observe que pode levar algum tempo para preencher em Performance -> DB Variables. Então, se você quiser verificar manualmente, você pode usar o prompt de comando mysql como abaixo:
Definir seu ssl_cipher pode adicionar mais proteção à segurança. Há uma lista de conjuntos de cifras se você executar SHOW GLOBAL STATUS LIKE 'Ssl_cipher_list'\G ou verifique aqui. Um conjunto de cifras é uma combinação de algoritmos de autenticação, criptografia e código de autenticação de mensagem (MAC). Eles são usados durante a negociação das configurações de segurança para uma conexão TLS/SSL, bem como para a transferência segura de dados.
Como o ClusterControl executará o mysqldump localmente nesse host, adicionando os seguintes parâmetros (veja abaixo) em seu arquivo de configuração do MySQL (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) irá criptografar quaisquer ações para dump SQL. Ver abaixo:
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pemVocê pode tentar monitorar usando tcpdump e pode ver abaixo em comparação com uma camada não criptografada versus criptografada usando TLS.
Com TLS/SSL:
Sem TLS/SSL:
Ao usar Percona XtraBackup ou Mariabackup no ClusterControl, não há suporte a TLS/SSL a partir deste momento quando o backup é transmitido pela rede. Ele usa socat que basicamente apenas abre uma porta em outro nó como meio de comunicação.
por exemplo
[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.Se você precisar de uma camada segura durante o transporte, poderá fazer isso manualmente usando as opções --ssl* durante a chamada do comando. Confira aqui o manual do Percona XtraBackup para mais informações. Ainda recomendamos obter seu certificado/chave de uma autoridade de certificação registrada.
Alternativamente, usando o ClusterControl, você pode criptografar seus dados antes de enviá-los pela rede, os pacotes enviados não são dados brutos, mas criptografados. Embora a criptografia dependa de repouso, discutiremos na próxima seção sobre isso.
Criptografia em repouso
No ClusterControl, ao criar seu backup, você tem a opção de criptografar seus dados. Ver abaixo:
Quando criptografado, o ClusterControl usará o “Advance Encryption Standard” AES-256-CBC. Veja o log de exemplo abaixo:
[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.Se você estiver armazenando seu backup na nuvem, por exemplo, com AWS S3, o S3 oferece três modos diferentes de criptografia do lado do servidor (SSE). Estes são SSE-S3, SSE-C ou SSE-KMS. A Amazon tem ótimos recursos de SSE para oferecer, que lidam com criptografia de dados em repouso. Você pode começar aqui, que aborda como o S3 usa o AWS KMS. Se você estiver movendo seu backup para um armazenamento baseado em volume ou bloco, a AWS também possui criptografia EBS usando o AWS KMS. Você pode verificar aqui para obter mais informações sobre isso.
O Microsoft Azure também possui recursos interessantes ao lidar com dados em repouso. Confira a página sobre “Criptografia do serviço de armazenamento do Azure para dados em repouso”. O Azure lida com as chaves em seu Azure Key Vault, da mesma forma que o AWS KMS. Para criptografia do Google para dados em repouso, você pode verificar aqui.
Ao armazenar backups de dados no local, você pode usar o LUKS (Linux Unified Key Setup) com a combinação de crypt ou dmcrypt. Eu não vou discutir sobre isso neste blog, mas esta é uma boa fonte para consultar:MySQL Encryption at Rest – Part 1 (LUKS). Para obter mais informações sobre criptografia de disco, esta página do ArchLinux “Criptografia de disco” é uma ótima fonte para começar.
Mais importante ainda, enquanto seus dados foram criptografados em repouso e em trânsito, sempre verifique se seu backup funciona. Um backup que não foi testado não é um backup se não funcionar quando a recuperação for necessária. Armazenar seu backup também enquanto criptografado deve ser descriptografado sem problemas, portanto, suas chaves devem ser armazenadas de forma privada e da maneira mais segura possível. Além disso, adicionar criptografia aos seus dados, como criptografia InnoDB ou SST (para Galera), adiciona mais segurança, mas não abordaremos isso neste blog.
Conclusão
Criptografar dados de backup em repouso e em trânsito são componentes vitais para conformidade com PHI, HIPAA, PCI DSS ou GDPR, para garantir que dados confidenciais transmitidos por fio ou salvos em discos não sejam legíveis por nenhum usuário ou aplicativo sem uma chave válida. Algumas regulamentações de conformidade, como PCI DSS e HIPAA, exigem que os dados em repouso sejam criptografados durante todo o ciclo de vida dos dados.
Aqui, mostramos como o ClusterControl oferece essas opções ao usuário final. A conformidade é uma tarefa enorme, porém, tocando muitas áreas diferentes. Os regulamentos também são atualizados com frequência, e os processos/ferramentas também precisam ser atualizados de acordo. Estamos melhorando continuamente diferentes áreas do ClusterControl para facilitar a conformidade. Gostaríamos de ouvir sua opinião sobre isso e como podemos melhorar.
