A proteção de dados é um dos aspectos mais significativos da administração de um banco de dados. Dependendo da estrutura organizacional, se você é um desenvolvedor, administrador de sistema ou DBA, se estiver gerenciando o banco de dados de produção, deverá monitorar os dados para acesso e uso não autorizados. O objetivo do monitoramento de segurança é duplo. Um, para identificar atividades não autorizadas no banco de dados. E dois, para verificar se os bancos de dados e suas configurações em toda a empresa estão em conformidade com as políticas e padrões de segurança.
Neste artigo, dividiremos o monitoramento de segurança em duas categorias. Um será relacionado à auditoria das atividades dos bancos de dados MySQL e MariaDB. A segunda categoria será sobre o monitoramento de suas instâncias para possíveis falhas de segurança.
Monitoramento baseado em políticas de consulta e conexão
A auditoria contínua é uma tarefa imperativa para monitorar seu ambiente de banco de dados. Ao auditar seu banco de dados, você pode se responsabilizar pelas ações realizadas ou pelo conteúdo acessado. Além disso, a auditoria pode incluir alguns componentes críticos do sistema, como os associados a dados financeiros para dar suporte a um conjunto preciso de regulamentos como SOX ou o regulamento GDPR da UE. Geralmente, isso é obtido registrando informações sobre operações de banco de dados no banco de dados em um arquivo de log externo.
Por padrão, a auditoria no MySQL ou MariaDB está desabilitada. Você e consegue isso instalando plugins adicionais ou capturando todas as consultas com o parâmetro query_log. O arquivo de log de consulta geral é um registro geral do que o MySQL está realizando. O servidor registra algumas informações nesse log quando os clientes se conectam ou desconectam e registra cada instrução SQL recebida dos clientes. Devido a problemas de desempenho e falta de opções de configuração, o general_log não é uma boa solução para fins de auditoria de segurança.
Se você usa o MySQL Enterprise, pode usar o plugin MySQL Enterprise Audit, que é uma extensão da versão proprietária do MySQL. O plug-in MySQL Enterprise Audit Plugin está disponível apenas com o MySQL Enterprise, que é uma oferta comercial da Oracle. Percona e MariaDB criaram suas próprias versões de código aberto do plug-in de auditoria. Por fim, o plug-in da McAfee para MySQL também pode ser usado com várias versões do MySQL. Neste artigo, vamos nos concentrar nos plugins de código aberto, embora a versão Enterprise da Oracle pareça ser a mais robusta e estável.
Características dos plug-ins de auditoria de código aberto do MySQL
Embora os plug-ins de auditoria de código aberto façam o mesmo trabalho que o plug-in Enterprise da Oracle - eles produzem saída com consultas e conexões de banco de dados - existem algumas diferenças arquitetônicas importantes.
Plugin de Auditoria MariaDB – O Plugin de Auditoria MariaDB funciona com MariaDB, MySQL (a partir da versão 5.5.34 e 10.0.7) e Percona Server. O MariaDB começou a incluir o plug-in de auditoria por padrão a partir das versões 10.0.10 e 5.5.37, e pode ser instalado em qualquer versão do MariaDB 5.5.20. É o único plugin que suporta Oracle MySQL, Percona Server e MariaDB. Está disponível na plataforma Windows e Linux. As versões a partir de 1.2 são mais estáveis e pode ser arriscado usar versões abaixo disso em seu ambiente de produção.
Plug-in de auditoria do McAfee MySQL – Este plug-in não usa a API de auditoria do MySQL. Ele foi atualizado recentemente para oferecer suporte ao MySQL 5.7. Alguns testes mostram que plugins baseados em API podem fornecer melhor desempenho, mas você precisa verificar isso com seu ambiente.
Percona Audit Log Plugin – Percona fornece uma solução de auditoria de código aberto que é instalada com o Percona Server 5.5.37+ e 5.6.17+ como parte do processo de instalação. Comparando com outros plugins de código aberto, este plugin tem mais recursos de saída de alcance, pois gera XML, JSON e para syslog.
Como ele possui alguns ganchos internos para o servidor para ser compatível com o plug-in da Oracle, ele não está disponível como um plug-in autônomo para outras versões do MySQL.
Instalação de plug-in baseada na extensão de auditoria MariaDB
A instalação de plugins MySQL de código aberto é bastante semelhante para as versões MariaDB, Percona e McAfee.
Percona e MariaDB adicionam seus plugins como parte dos binários padrão do servidor, então não há necessidade de baixar plugins separadamente. A versão Percona suporta oficialmente apenas seu próprio fork do MySQL, portanto, não há download direto do site do fornecedor (se você quiser usar este plug-in com o MySQL, precisará obter o plug-in de um pacote do servidor Percona). Se você gostaria de usar o plugin MariaDB com outros forks do MySQL, então você pode encontrá-lo em https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. O plug-in da McAfee está disponível em https://github.com/mcafee/mysql-audit/wiki/Installation.
Antes de iniciar a instalação do plugin, você pode verificar se o plugin está presente no sistema. A localização do plugin dinâmico (não requer reinicialização da instância) pode ser verificada com:
SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| plugin_dir | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+Verifique o diretório retornado no nível do sistema de arquivos para garantir que você tenha uma cópia da biblioteca do plug-in. Se você não tiver server_audit.so ou server_audit.dll dentro de /usr/lib64/mysql/plugin/, é mais provável que sua versão do MariaDB não seja suportada e deve atualizá-la para a versão mais recente.
A sintaxe para instalar o plugin MariaDB é:
INSTALL SONAME 'server_audit';Para verificar os plugins instalados, você precisa executar:
SHOW PLUGINS;
MariaDB [(none)]> show plugins;
+-------------------------------+----------+--------------------+--------------------+---------+
| Name | Status | Type | Library | License |
+-------------------------------+----------+--------------------+--------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| mysql_old_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| wsrep | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CSV | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CLIENT_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INDEX_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| TABLE_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| USER_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
...
| INNODB_MUTEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_SYS_SEMAPHORE_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| INNODB_TABLESPACES_SCRUBBING | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| Aria | ACTIVE | STORAGE ENGINE | NULL | GPL |
| SEQUENCE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| user_variables | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| FEEDBACK | DISABLED | INFORMATION SCHEMA | NULL | GPL |
| partition | ACTIVE | STORAGE ENGINE | NULL | GPL |
| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
| rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
| SERVER_AUDIT | ACTIVE | AUDIT | server_audit.so | GPL |
+-------------------------------+----------+--------------------+--------------------+---------+Se você precisar de informações adicionais, verifique a tabela PLUGINS no banco de dados information_schema que contém informações mais detalhadas.
Outra maneira de instalar o plugin é habilitar o plugin em my.cnf e reiniciar a instância. Um exemplo de configuração básica de plug-in de auditoria do MariaDB pode ser:
server_audit_events=CONNECT
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotate_size=1073741824
server_audit_file_rotations=8
server_audit_logging=ON
server_audit_incl_users=
server_audit_excl_users=
server_audit_output_type=FILE
server_audit_query_log_limit=1024A configuração acima deve ser colocada em my.cnf. O plug-in de auditoria criará o arquivo /var/log/mysql/audit.log que girará no tamanho de 1 GB e haverá oito rotações até que o arquivo seja substituído. O arquivo conterá apenas informações sobre conexões.
Atualmente, existem dezesseis configurações que você pode usar para ajustar o plug-in de auditoria MariaDB.
server_audit_events
server_audit_excl_users
server_audit_file_path
server_audit_file_rotate_now
server_audit_file_rotate_size
server_audit_file_rotations
server_audit_incl_users
server_audit_loc_info
server_audit_logging
server_audit_mode
server_audit_output_type
Server_audit_query_log_limit
server_audit_syslog_facility
server_audit_syslog_ident
server_audit_syslog_info
server_audit_syslog_priorityEntre eles, você pode encontrar opções para incluir ou excluir usuários, definir diferentes eventos de log (CONNECT ou QUERY) e alternar entre arquivo e syslog.
Para certificar-se de que o plug-in será ativado na inicialização do servidor, você deve definir
plugin_load=server_audit=server_audit.so nas configurações do my.cnf. Tal configuração pode ser adicionalmente protegida por server_audit=FORCE_PLUS_PERMANENT que irá desabilitar a opção de desinstalação do plugin.
UNINSTALL PLUGIN server_audit;
ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloadedAqui estão algumas entradas de amostra produzidas pelo plugin de auditoria MariaDB:
20180817 20:00:01,slave,cmon,cmon,31,0,DISCONNECT,information_schema,,0
20180817 20:47:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,19,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,18,0,DISCONNECT,information_schema,,0
20180819 17:19:19,slave,cmon,cmon,12,0,CONNECT,information_schema,,0
20180819 17:19:19,slave,root,localhost,13,0,FAILED_CONNECT,,,1045
20180819 17:19:19,slave,root,localhost,13,0,DISCONNECT,,,0
20180819 17:19:20,slave,cmon,cmon,14,0,CONNECT,mysql,,0
20180819 17:19:20,slave,cmon,cmon,14,0,DISCONNECT,mysql,,0
20180819 17:19:21,slave,cmon,cmon,15,0,CONNECT,information_schema,,0
20180819 17:19:21,slave,cmon,cmon,16,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0Relatório de alterações de esquema
Se você precisar rastrear apenas as alterações de DDL, poderá usar o Relatório Operacional do ClusterControl na Alteração de Esquema. O Relatório de Detecção de Alterações de Esquema mostra quaisquer alterações de DDL em seu banco de dados. Essa funcionalidade requer um parâmetro adicional no arquivo de configuração do ClusterControl. Se não estiver definido, você verá as seguintes informações:schema_change_detection_address não está definido em /etc/cmon.d/cmon_1.cnf. Uma vez que isso esteja em vigor, uma saída de exemplo pode ser como abaixo:
Ele pode ser configurado com uma programação e os relatórios enviados por e-mail aos destinatários.
ClusterControl:Agendar relatório operacional Avaliação de segurança do banco de dados MySQL
Verificação de atualização do pacote
Primeiro, começaremos com as verificações de segurança. Estar atualizado com os patches do MySQL ajudará a reduzir os riscos associados a vulnerabilidades conhecidas presentes no servidor MySQL. Você pode manter seu ambiente atualizado usando o repositório de pacotes dos fornecedores. Com base nessas informações, você pode criar seus próprios relatórios ou usar ferramentas como o ClusterControl para verificar seu ambiente e alertá-lo sobre possíveis atualizações.
O Relatório de Atualização do ClusterControl reúne informações do sistema operacional e as compara com os pacotes disponíveis no repositório. O relatório está dividido em quatro seções; resumo de atualização, pacotes de banco de dados, pacotes de segurança e outros pacotes. Você pode comparar rapidamente o que instalou em seu sistema e encontrar uma atualização ou patch recomendado.
ClusterControl:Relatório de atualização 
ClusterControl:detalhes do relatório de atualização Para compará-los manualmente, você pode executar
SHOW VARIABLES WHERE variable_name LIKE "version";Com boletins de segurança como:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- resultados?adv_search=true&cves=on&cpe_vendor=cpe%3a%2f%3aoracle&cpe_produ
https://www.percona.com/doc/percona-server/LATEST/release-notes/release-notes_index.html
https://downloads.mariadb.org/mariadb/+releases/
https://www.cvedetails.com/vulnerability-list/vendor_id-12010/Mariadb.html
https://www. cvedetails.com/vulnerability-list/vendor_id-13000/Percona.html
Ou repositórios de fornecedores:
No Debian
sudo apt list mysql-serverNo RHEL/Centos
yum list | grep -i mariadb-serverContas sem senha
Senhas em branco permitem que um usuário faça login sem usar uma senha. O MySQL costumava vir com um conjunto de usuários pré-criados, alguns dos quais podem se conectar ao banco de dados sem senha ou, pior ainda, usuários anônimos. Felizmente, isso mudou no MySQL 5.7. Por fim, ele vem apenas com uma conta root que usa a senha que você escolheu no momento da instalação.
Para cada linha retornada do procedimento de auditoria, defina uma senha:
SELECT User,host
FROM mysql.user
WHERE authentication_string='';Além disso, você pode instalar um plugin de validação de senha e implementar uma política mais segura:
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';Um bom começo pode ser:
plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT
validate_password_length=14
validate_password_mixed_case_count=1
validate_password_number_count=1
validate_password_special_char_count=1
validate_password_policy=MEDIUMObviamente, essas configurações dependerão das necessidades do seu negócio.
Monitoramento de acesso remoto
Evitar o uso de curingas em nomes de host ajuda a controlar os locais específicos a partir dos quais um determinado usuário pode se conectar e interagir com o banco de dados.
Você deve certificar-se de que cada usuário possa se conectar ao MySQL somente de hosts específicos. Você sempre pode definir várias entradas para o mesmo usuário, isso deve ajudar a reduzir a necessidade de curingas.
Execute a seguinte instrução SQL para avaliar essa recomendação (certifique-se de que nenhuma linha seja retornada):
SELECT user, host FROM mysql.user WHERE host = '%';Banco de dados de teste
A instalação padrão do MySQL vem com um banco de dados não utilizado chamado teste e o banco de dados de teste está disponível para todos os usuários, especialmente para os usuários anônimos. Esses usuários podem criar tabelas e gravar nelas. Isso pode se tornar um problema por si só - e as gravações adicionariam alguma sobrecarga e reduziriam o desempenho do banco de dados. Recomenda-se que o banco de dados de teste seja descartado. Para determinar se o banco de dados de teste está presente, execute:
SHOW DATABASES LIKE 'test';Se você notar que o banco de dados de teste está presente, isso pode ser que o script mysql_secure_installation que descarta o banco de dados de teste (assim como outras atividades relacionadas à segurança) não foi executado.
CARREGAR INFILE DE DADOS
Se o servidor e o cliente tiverem a capacidade de executar LOAD DATA LOCAL INFILE, um cliente poderá carregar dados de um arquivo local para um servidor MySQL remoto. O parâmetro local_infile determina se os arquivos localizados no computador do cliente MySQL podem ser carregados ou selecionados via LOAD DATA INFILE ou SELECT local_file.
Isso, potencialmente, pode ajudar a ler os arquivos aos quais o cliente tem acesso - por exemplo, em um servidor de aplicativos, pode-se acessar quaisquer dados aos quais o servidor HTTP tenha acesso. Para evitar isso, você precisa definir local-infile=0 em my.cnf.
Execute a seguinte instrução SQL e certifique-se de que o campo Valor esteja definido como OFF:
SHOW VARIABLES WHERE Variable_name = 'local_infile';Monitorar tablespaces não criptografados
A partir do MySQL 5.7.11, o InnoDB suporta criptografia de dados para tabelas armazenadas em tablespaces arquivo por tabela. Esse recurso fornece criptografia em repouso para arquivos de dados de tablespace físicos. Para examinar se suas tabelas foram criptografadas, execute:
mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';
+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test | t1 | ENCRYPTION="Y" |
+--------------+------------+----------------+Como parte da criptografia, você também deve considerar a criptografia do log binário. O servidor MySQL grava muitas informações em logs binários.
Validação de conexão de criptografia
Em algumas configurações, o banco de dados não deve ser acessível pela rede se todas as conexões forem gerenciadas localmente, por meio do soquete Unix. Nesses casos, você pode adicionar a variável ‘skip-networking’ em my.cnf. Skip-networking impede o MySQL de usar qualquer conexão TCP/IP, e somente o soquete Unix seria possível no Linux.
No entanto, esta é uma situação bastante rara, pois é comum acessar o MySQL pela rede. Em seguida, você precisa monitorar se suas conexões estão criptografadas. O MySQL suporta SSL como meio de criptografar o tráfego entre servidores MySQL (replicação) e entre servidores MySQL e clientes. Se você usa o cluster Galera, recursos semelhantes estão disponíveis - tanto a comunicação intra-cluster quanto as conexões com clientes podem ser criptografadas usando SSL. Para verificar se você usa criptografia SSL, execute as seguintes consultas:
SHOW variables WHERE variable_name = 'have_ssl';
select ssl_verify_server_cert from mysql.slave_master_info;É isso por enquanto. Esta não é uma lista completa, informe-nos se houver outras verificações que você está fazendo hoje em seus bancos de dados de produção.
