A segurança dos dados é crucial em tempos de GDPR, PCI DSS ou HIPPA. Para cumprir os regulamentos, é preciso ter extrema cautela sobre como os dados devem ser armazenados e protegidos. Os dados, normalmente, podem estar em repouso ou em trânsito. Dados em trânsito são os dados transferidos de ou para o banco de dados. Os resultados da consulta enviados ao cliente ou aplicativo ou dados replicados entre nós do cluster são exemplos de casos em que os dados estão em trânsito. Costumamos proteger os dados nesse estado usando conexões criptografadas SSL ou TLS entre os nós do banco de dados ou o banco de dados e o cliente.
Do outro lado do espectro, temos dados em repouso - diríamos que a maioria dos dados está, em determinado momento, em repouso. Estamos falando aqui de dados armazenados em disco em tablespaces, diferentes estruturas de dados (gcache buffer, redo logs) e logs (binary e relay logs). Vamos dar uma olhada nas considerações sobre esse assunto no MariaDB.
O que criptografar no MariaDB?
Idealmente, você precisa criptografar tudo. Bancos de dados armazenam dados em diferentes lugares e de diferentes maneiras, como mencionado acima. O maior conjunto de dados é armazenado em tablespaces - este é o local “final” onde os dados são armazenados. Obviamente, é possível criptografar tablespaces - caso contrário, todo o recurso seria inútil. O MariaDB pode armazenar os dados em um tablespace compartilhado, vários deles ou cada tabela pode ser armazenada em um tablespace separado - todos esses cenários são suportados. Os usuários têm algum nível de flexibilidade ao escolher o que criptografar. Você pode criptografar tudo, tabelas individuais ou tudo, exceto algumas tabelas individuais.
Registro de redo do MariaDB InnoDB
Outra estrutura que armazena os dados é o log de redo do InnoDB. O redo log do InnoDB é um local onde os dados são gravados após a atualização de uma determinada linha. Os dados do log de redo eventualmente serão transferidos para o tablespace, mas por um tempo o log de redo do InnoDB contém todas as modificações que aconteceram recentemente. Como você pode imaginar, esses dados também são críticos e devem ser protegidos - MariaDB permite criptografar o log de redo do InnoDB.
Registros binários do MariaDB
Logs binários (assim como logs de retransmissão) armazenam informações sobre consultas executadas que modificam os dados. Como as informações incluídas nos permitem reconstruir o estado atual de uma linha que sofreu modificação, essa é outra forma de dados que devem ser protegidos e criptografados. Os logs binários e de retransmissão podem ser criptografados no MariaDB.
cache do Galera
O cache do Galera (gcache) é um buffer em disco no Galera Cluster que armazena as informações sobre as modificações executadas. Ele é usado em caso de falha de nó ou problemas temporários de rede para permitir que os nós que se unem ao cluster se recuperem usando apenas os dados que estão faltando, evitando a transferência de todo o conjunto de dados. Semelhante aos logs binários ou logs de redo, o gcache contém a lista de modificações e, como tal, pode ser usado para recuperar e reunir partes de dados. Na versão comunitária do MariaDB Galera Cluster, o gcache não pode ser criptografado. Essa opção fica disponível na versão Enterprise do MariaDB Galera Cluster.
O que não pode ser criptografado no MariaDB?
Ainda há alguns lugares onde podem aparecer pedaços de dados que não podem ser criptografados, pelo menos por enquanto, no MariaDB. Em primeiro lugar, os logs de erros podem conter amostras de consultas que podem expor alguns dados. É impossível criptografar logs de erros, mas é possível redirecionar o log de erros para o syslog e implementar algum mecanismo de proteção fora do MariaDB.
Logs do plug-in de auditoria
Plugin de auditoria também gera log - este log pode conter informações confidenciais, incluindo as consultas exatas que foram executadas no banco de dados. Não é possível criptografar este log, mas ele pode ser redirecionado para o syslog e criptografar lá.
Registros de consulta
Logs de consultas gerais e lentas - esses logs conterão consultas (ou pelo menos amostras delas) que foram executadas pelo MariaDB. A partir de agora, não é possível criptografar esses logs.
pool de buffer InnoDB
Memória - MariaDB executa criptografia apenas para as páginas armazenadas em disco. Todos os dados armazenados no buffer pool do InnoDB não serão criptografados. O buffer pool do InnoDB destina-se a manter as linhas recentemente modificadas ou acessadas pela consulta SELECT - essas linhas obviamente conterão amostras de dados. A partir de agora, não há opção para criptografar o buffer pool do InnoDB no MariaDB. Por favor, tenha em mente que seria necessário acesso ao sistema para ler a memória ao vivo. Não é uma tarefa trivial, embora também não seja impossível de realizar.
Lembre-se de que abordamos as opções de criptografia incluídas no MariaDB. Há sempre a possibilidade de usar outra camada de criptografia. Por exemplo, criptografar todo o armazenamento tornará os logs não legíveis para qualquer pessoa que tenha acesso físico ao disco. Por outro lado, não protegerá os dados de alguém que possa fazer login no sistema.
Compatibilidade com ferramentas externas
Outra coisa a considerar é a compatibilidade. Se você decidir criptografar seu MariaDB, lembre-se de que isso pode afetar a maneira como você opera. Não é possível usar ferramentas externas como XtraBackup ou mysqlbinlog para processar os dados e criar um backup ou lidar com logs binários. Você terá que se ater às ferramentas criadas pelo MariaDB (como Mariabackup), que são escritas com o mecanismo de criptografia em mente. Eles podem lidar com os dados em repouso, a criptografia é implementada no MariaDB.
Planejando o processo de criptografia
Esta seção não discutirá o processo em detalhes, mas analisa o que você deve considerar ao planejar a criptografia, como recursos e tempo. A utilização da CPU aumentará, assim como a atividade de E/S durante o processo. Do ponto de vista do usuário, tudo se resume às definições de configuração e, em seguida, à execução de comandos ALTER para reconstruir e criptografar as tabelas existentes. Para bancos de dados grandes, isso por si só pode ser um desafio significativo que exigiria planejamento. As alterações de esquema podem ser um fardo sério, e é recomendável usar ferramentas como pt-online-schema-change para reduzir o impacto delas nos sistemas de produção e obter melhor controle sobre o processo.
Considerações finais
Como mencionamos, os dados são essenciais para todas as organizações e é crucial garantir que os dados estejam seguros e protegidos. A criptografia dos dados em repouso é um dos elementos importantes em todo o quadro. Adoraríamos ouvir de você sobre sua experiência com criptografia de dados em repouso no MariaDB. Se você gostaria de compartilhar seus pensamentos, você é bem-vindo para deixar um comentário abaixo.
