A segurança dos dados é uma prioridade nos dias de hoje. Às vezes, é imposto por regulamentos externos, como PCI-DSS ou HIPAA, às vezes é porque você se preocupa com os dados de seus clientes e sua reputação. Existem vários aspectos de segurança que você precisa ter em mente - acesso à rede, segurança do sistema operacional, concessões, criptografia e assim por diante. Nesta postagem do blog, daremos 10 dicas sobre o que observar ao proteger sua configuração do MySQL ou MariaDB.
1. Remover usuários sem 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. Isso mudou no MySQL 5.7 que, por padrão, vem apenas com uma conta root que usa a senha que você escolheu no momento da instalação. Ainda assim, existem instalações do MySQL que foram atualizadas de versões anteriores e essas instalações mantêm os usuários legados. Além disso, o MariaDB 10.2 no Centos 7 vem com usuários anônimos:
MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host | password |
+------+-----------------------+----------+
| | localhost | |
| | localhost.localdomain | |
+------+-----------------------+----------+
2 rows in set (0.00 sec)Como você pode ver, eles são limitados apenas ao acesso do localhost, mas, independentemente, você não deseja ter usuários assim. Embora seus privilégios sejam limitados, eles ainda podem executar alguns comandos que podem mostrar mais informações sobre o banco de dados - por exemplo, a versão pode ajudar a identificar outros vetores de ataque.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.2.11-MariaDB MariaDB Server
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 12 min 14 sec
Threads: 7 Questions: 36 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 11 Queries per second avg: 0.049
--------------Observe que usuários com senhas muito simples são quase tão inseguros quanto usuários sem senha. Senhas como “senha” ou “qwerty” não são realmente úteis.
2. Acesso remoto restrito
Em primeiro lugar, o acesso remoto para superusuários - isso é feito por padrão ao instalar o MySQL (5.7) ou MariaDB (10.2) mais recente - apenas o acesso local está disponível. Ainda assim, é bastante comum ver superusuários disponíveis por vários motivos. O mais comum, provavelmente porque o banco de dados é gerenciado por humanos que desejam facilitar seu trabalho, para adicionar acesso remoto aos seus bancos de dados. Esta não é uma boa abordagem, pois o acesso remoto facilita a exploração de vulnerabilidades de segurança potenciais (ou verificadas) no MySQL - você não precisa obter uma conexão com o host primeiro.
Outro passo - certifique-se de que cada usuário possa se conectar ao MySQL apenas de hosts específicos. Você sempre pode definir várias entradas para o mesmo usuário ([email protected], [email protected]), isso deve ajudar a reduzir a necessidade de curingas ([email protected]’%’).
3. Remover banco de dados de teste
O banco de dados de teste, por padrão, 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ó - qualquer gravação adicionaria alguma sobrecarga e reduziria o desempenho do banco de dados. Atualmente, após a instalação padrão, apenas o MariaDB 10.2 no Centos 7 é afetado por isso - Oracle MySQL 5.7 e Percona Server 5.7 não possuem o esquema 'teste' disponível.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)Claro, ainda pode acontecer que seu MySQL 5.7 tenha sido atualizado de versões anteriores nas quais o esquema 'teste' não foi removido - você deve cuidar disso e verificar se você o criou.
4. Ofuscar o acesso ao MySQL
É bem conhecido que o MySQL roda na porta 3306, e seu superusuário é chamado de ‘root’. Para tornar as coisas mais difíceis, é bastante simples mudar isso. Até certo ponto, este é um exemplo de segurança através da obscuridade, mas pode pelo menos impedir as tentativas automatizadas de obter acesso ao usuário 'root'. Para alterar a porta, você precisa editar my.cnf e definir a variável 'port' para algum outro valor. Quanto aos usuários - após a instalação do MySQL, você deve criar um novo superusuário (GRANT ALL … WITH GRANT OPTION) e remover as contas ‘[email protected]’ existentes.
5. Segurança de rede
Idealmente, o MySQL não estaria disponível através da rede e todas as conexões seriam tratadas localmente, através do soquete Unix. Em algumas configurações, isso é possível - nesse caso, você pode adicionar a variável 'skip-networking' em my.cnf. Isso impedirá o MySQL de usar qualquer comunicação TCP/IP, apenas o soquete Unix estaria disponível no Linux (pipes nomeados e memória compartilhada em hosts Windows).
Na maioria das vezes, porém, essa segurança rígida não é viável. Nesse caso, você precisa encontrar outra solução. Primeiro, você pode usar seu firewall para permitir tráfego apenas de hosts específicos para o servidor MySQL. Por exemplo, hosts de aplicativos (embora eles devam estar bem em alcançar o MySQL por meio de proxies), a camada de proxy e talvez um servidor de gerenciamento. Outros hosts em sua rede provavelmente não precisam de acesso direto ao servidor MySQL. Isso limitará as possibilidades de ataque em seu banco de dados, caso alguns hosts em sua rede sejam comprometidos.
Se acontecer de você usar proxies que permitem a correspondência de expressões regulares para consultas, você pode usá-los para analisar o tráfego SQL e bloquear consultas suspeitas. Muito provavelmente seus hosts de aplicativos não devem executar “DELETE * FROM your_table;” em uma base regular. Se for necessário remover alguns dados, ele pode ser executado manualmente, localmente, na instância do MySQL. Você pode criar essas regras usando algo como ProxySQL:bloquear, reescrever, redirecionar essas consultas. MaxScale também oferece a opção de bloquear consultas com base em expressões regulares.
6. Plug-ins de auditoria
Se você estiver interessado em coletar dados sobre quem executou o quê e quando, existem vários plugins de auditoria disponíveis para o MySQL. Se você usa o MySQL Enterprise, pode usar o MySQL Enterprise Audit, que é uma extensão do MySQL Enterprise. Percona e MariaDB também têm sua própria versão de plugins de auditoria. Por fim, o plug-in da McAfee para MySQL também pode ser usado com diferentes versões do MySQL. De um modo geral, esses plugins coletam mais ou menos os mesmos dados - eventos de conexão e desconexão, consultas executadas, tabelas acessadas. Tudo isso contém informações sobre qual usuário participou de tal evento, de qual host ele se conectou, quando aconteceu e assim por diante. A saída pode ser XML ou JSON, portanto, é muito mais fácil analisá-la do que analisar o conteúdo geral do log (mesmo que os dados sejam bastante semelhantes). Essa saída também pode ser enviada para o syslog e, ainda, algum tipo de servidor de log para processamento e análise.
7. Desabilitar LOAD DATA INFILE
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. Isso, potencialmente, pode ajudar a ler os arquivos aos quais o cliente tem acesso - por exemplo, em um servidor de aplicativos, pode-se acessar qualquer arquivo ao qual o servidor HTTP tenha acesso. Para evitar isso, você precisa definir local-infile=0 no my.cnf
8. Privilégios de arquivo
Você deve ter em mente que a segurança do MySQL também depende da configuração do sistema operacional. MySQL armazena dados na forma de arquivos. O servidor MySQL grava muitas informações nos logs. Às vezes, essas informações contêm dados - log de consulta lenta, log geral ou log binário, por exemplo. Você precisa garantir que essas informações sejam seguras e acessíveis apenas aos usuários que precisam acessá-las. Normalmente, isso significa que apenas o root e o usuário sob cujos direitos o MySQL está sendo executado devem ter acesso a todos os arquivos relacionados ao MySQL. Na maioria das vezes é um usuário dedicado chamado 'mysql'. Você deve verificar os arquivos de configuração do MySQL e todos os logs gerados pelo MySQL e verificar se eles não podem ser lidos por outros usuários.
9. SSL e criptografia de dados em trânsito
Impedir que as pessoas acessem os arquivos de configuração e log é uma coisa. A outra questão é garantir que os dados sejam transferidos com segurança pela rede. Com exceção de configurações onde todos os clientes são locais e usam soquete Unix para acessar o MySQL, na maioria dos casos, os dados que formam um conjunto de resultados para uma consulta saem do servidor e são transferidos para o cliente pela rede. Os dados também podem ser transferidos entre servidores MySQL, por exemplo, via MySQLreplication padrão ou dentro de um cluster Galera. O tráfego de rede pode ser rastreado e, por esses meios, seus dados seriam expostos.
Para evitar que isso aconteça, é possível usar SSL para criptografar o tráfego, tanto do lado do servidor quanto do lado do cliente. Você pode criar uma conexão SSL entre um cliente e um servidor MySQL. Você também pode criar uma conexão SSL entre seu mestre e seus escravos, ou entre os nós de um cluster Galera. Isso garantirá que todos os dados transferidos sejam seguros e não possam ser rastreados por um invasor que obteve acesso à sua rede.
A documentação do MySQL cobre em detalhes como configurar a criptografia SSL. Se você achar muito complicado, o ClusterControl pode ajudá-lo a implantar um ambiente seguro para replicação MySQL ou cluster Galera em apenas alguns cliques:
10. Criptografia de dados em repouso
Proteger dados em trânsito usando criptografia SSL resolve apenas parcialmente o problema. Você precisa cuidar também dos dados em repouso - todos os dados armazenados no banco de dados. A criptografia de dados em repouso também pode ser um requisito para regulamentações de segurança como HIPAA ou PCI DSS. Essa criptografia pode ser implementada em vários níveis - você pode criptografar todo o disco no qual os arquivos estão armazenados. Você pode criptografar apenas o banco de dados MySQL por meio da funcionalidade disponível nas versões mais recentes do MySQL ou MariaDB. A criptografia também pode ser implementada no aplicativo, para que ele criptografe os dados antes de armazená-los no banco de dados. Cada opção tem seus prós e contras:a criptografia de disco pode ajudar apenas quando os discos são fisicamente roubados, mas os arquivos não seriam criptografados em um servidor de banco de dados em execução. A criptografia do banco de dados MySQL resolve esse problema, mas não pode impedir o acesso aos dados quando a conta root está comprometida. A criptografia no nível do aplicativo é a mais flexível e segura, mas você perde o poder do SQL - é muito difícil usar colunas criptografadas em cláusulas WHERE ou JOIN.
Todos os tipos de MySQL fornecem algum tipo de criptografia de dados em repouso. O MySQL da Oracle usa Transparent Data Encryption para criptografar tablespaces InnoDB. Isso está disponível na oferta comercial do MySQL Enterprise. Ele fornece uma opção para criptografar espaços de tabela InnoDB, outros arquivos que também armazenam dados de alguma forma (por exemplo, logs binários, log geral, log de consulta lenta) não são criptografados. Isso permite que a cadeia de ferramentas (MySQL Enterprise Backup, mas também xtrabackup, mysqldump, mysqlbinlog) funcione corretamente com essa configuração.
A partir do MySQL 5.7.11, a versão da comunidade do MySQL também obteve suporte para criptografia de tablespace InnoDB. A principal diferença em comparação com a oferta corporativa é a maneira como as chaves são armazenadas - as chaves não estão localizadas em um cofre seguro, o que é necessário para conformidade regulatória. Isso significa que a partir do Percona Server 5.7.11, também é possível criptografar o tablespace InnoDB. No recém-publicado Percona Server 5.7.20, foi adicionado suporte para criptografar logs binários. Também é possível integrar com o servidor Hashicorp Vault por meio de um plugin keyring_vault, combinando (e até estendendo - criptografia de log binário) os recursos disponíveis na edição MySQL Enterprise da Oracle.
MariaDB adicionou suporte para criptografia de dados na versão 10.1.3 - é uma implementação separada e aprimorada. Ele oferece a possibilidade de criptografar não apenas os espaços de tabela do InnoDB, mas também os arquivos de log do InnoDB. Como resultado, os dados são mais seguros, mas algumas das ferramentas não funcionam nessa configuração. O Xtrabackup não funcionará com redo logs criptografados - MariaDB criou um fork, MariaDB Backup, que adiciona suporte para criptografia MariaDB. Há também problemas com mysqlbinlog.
Não importa qual versão do MySQL você use, desde que seja uma versão recente, você terá opções para implementar a criptografia de dados em repouso por meio do servidor de banco de dados, garantindo que seus dados estejam adicionalmente protegidos.
Proteger o MySQL ou o MariaDB não é trivial, mas esperamos que essas 10 dicas o ajudem ao longo do caminho.
Resumo
No cenário atual, a segurança dos dados é a principal prioridade de todo administrador de banco de dados. Seja sua motivação a conformidade com os requisitos regulatórios ou a proteção de seus clientes e a reputação de sua empresa, essas dez dicas para proteger seus bancos de dados MySQL e MariaDB ajudarão você a proteger ainda mais sua infraestrutura e a proporcionar tranquilidade.
Existem várias medidas a serem consideradas ao garantir que sua infraestrutura de banco de dados seja segura. Nesta postagem, abordamos os fundamentos, como criptografia de dados, controles de acesso à rede, autenticação e privilégios de usuários, segurança do sistema operacional e muito mais.
Softwares de automação de gerenciamento de banco de dados, como ClusterControl, podem ser uma ótima ferramenta para auxiliar em seus esforços gerais de segurança de banco de dados. Se você está procurando um mergulho mais profundo em cada etapa que deve seguir para proteger seus bancos de dados MySQL, não deixe de conferir a Parte 1 e a Parte 2 de nossa série sobre Como proteger o MySQL. Para se manter informado sobre outras práticas recomendadas de gerenciamento de banco de dados, siga-nos no Twitter, LinkedIn e assine nosso boletim informativo para atualizações.
