Melhores Práticas de Segurança do MySQL

Introdução

Neste laboratório, você aprenderá como aprimorar a segurança do seu banco de dados MySQL. Abordaremos práticas essenciais de segurança, incluindo a definição de uma senha para o usuário root, a criação de usuários dedicados de acordo com o princípio do menor privilégio, o gerenciamento de permissões de usuário e a remoção de contas anônimas. Ao final deste laboratório, você terá uma melhor compreensão de como proteger seu servidor MySQL contra vulnerabilidades comuns.

Proteger a Conta Root

Uma instalação padrão do MySQL frequentemente permite que o usuário root se conecte sem senha a partir da máquina local. Seu primeiro passo para proteger o MySQL é definir uma senha forte para a conta root.

Primeiro, abra o terminal do seu desktop.

Conecte-se ao servidor MySQL como o usuário root. Neste ambiente de laboratório, você pode usar sudo para se conectar sem senha.

sudo mysql -u root

Uma vez conectado, você verá o prompt do MySQL (mysql>).

Agora, defina uma senha para o usuário root. A instrução ALTER USER é usada para modificar contas de usuário. Substitua YourStrongPassword! por uma senha de sua escolha.

ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourStrongPassword!';

Este comando define uma senha para o usuário root ao se conectar a partir de localhost. Você deverá ver a seguinte saída, confirmando que o comando foi bem-sucedido:

Query OK, 0 rows affected (0.01 sec)

Em seguida, aplique as alterações de privilégio imediatamente usando o comando FLUSH PRIVILEGES.

FLUSH PRIVILEGES;

A saída será:

Query OK, 0 rows affected (0.00 sec)

Você agora definiu com sucesso uma senha para o usuário root. Embora você ainda possa usar sudo mysql -u root para se conectar, qualquer tentativa de conexão direta com mysql -u root -p agora exigirá a senha que você acabou de definir. Este é um primeiro passo crítico para proteger seu banco de dados.

Criar um Usuário e Banco de Dados Dedicados

Usar a conta root para aplicações é um risco de segurança porque ela possui permissões ilimitadas. Uma prática recomendada é criar usuários dedicados com privilégios limitados para cada aplicação. Neste passo, você criará um novo banco de dados e um usuário com acesso apenas a esse banco de dados.

Agora, crie um novo banco de dados para sua aplicação. Vamos chamá-lo de app_db.

CREATE DATABASE app_db;

Você deverá ver esta confirmação:

Query OK, 1 row affected (0.01 sec)

Em seguida, crie um novo usuário que sua aplicação usará para se conectar ao banco de dados. Chamaremos este usuário de app_user e atribuiremos uma senha a ele.

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'UserPassword123';

A saída será:

Query OK, 0 rows affected (0.01 sec)

Agora, conceda os privilégios necessários ao app_user. Para este exemplo, concederemos permissões SELECT e INSERT em todas as tabelas dentro do banco de dados app_db. Isso segue o princípio do menor privilégio, dando ao usuário apenas as permissões que ele precisa.

GRANT SELECT, INSERT ON app_db.* TO 'app_user'@'localhost';

Aplique as alterações limpando os privilégios.

FLUSH PRIVILEGES;

Você pode verificar os privilégios que acabou de conceder executando:

SHOW GRANTS FOR 'app_user'@'localhost';

A saída mostrará as permissões exatas para app_user:

+------------------------------------------------------------------+
| Grants for app_user@localhost                                    |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `app_user`@`localhost`                     |
| GRANT SELECT, INSERT ON `app_db`.* TO `app_user`@`localhost`     |
+------------------------------------------------------------------+
2 rows in set (0.00 sec)

Você criou com sucesso um banco de dados e um usuário dedicados com as permissões apropriadas.

Gerenciar Privilégios do Usuário

Os requisitos da aplicação podem mudar, e você pode precisar ajustar as permissões do usuário de acordo. Neste passo, você praticará a modificação de privilégios revogando uma permissão existente do app_user.

Vamos supor que o app_user agora só deva ser capaz de ler dados (SELECT), mas não adicionar novos dados (INSERT). Você precisa revogar o privilégio INSERT.

Use a instrução REVOKE para remover o privilégio INSERT do app_user no banco de dados app_db.

REVOKE INSERT ON app_db.* FROM 'app_user'@'localhost';

Você verá a seguinte confirmação:

Query OK, 0 rows affected (0.00 sec)

Aplique as alterações limpando os privilégios.

FLUSH PRIVILEGES;

Agora, verifique se o privilégio foi revogado verificando novamente os grants do usuário.

SHOW GRANTS FOR 'app_user'@'localhost';

A saída agora deve mostrar que o app_user possui apenas o privilégio SELECT no app_db. O privilégio INSERT foi removido.

+--------------------------------------------------------------+
| Grants for app_user@localhost                                |
+--------------------------------------------------------------+
| GRANT USAGE ON *.* TO `app_user`@`localhost`                 |
| GRANT SELECT ON `app_db`.* TO `app_user`@`localhost`         |
+--------------------------------------------------------------+
2 rows in set (0.00 sec)

Isso demonstra como gerenciar efetivamente as permissões do usuário para se adaptar às mudanças nos requisitos de segurança.

Remover Contas de Usuário Anônimas

Por padrão, algumas instalações do MySQL criam contas de usuário anônimas, que possuem um nome de usuário vazio. Essas contas representam um risco de segurança porque podem permitir acesso não autorizado. É uma prática de segurança crítica verificar e removê-las, se existirem.

Você pode identificar usuários anônimos consultando a tabela mysql.user em busca de entradas com um nome de usuário em branco.

SELECT User, Host FROM mysql.user WHERE User = '';

Se usuários anônimos existirem, esta consulta os listará. Uma instalação nova no Ubuntu pode incluir um, mas versões mais recentes do MySQL/MariaDB frequentemente não possuem usuários anônimos por padrão.

Se você vir resultados como:

+------+-----------+
| User | Host      |
+------+-----------+
|      | localhost |
+------+-----------+
1 row in set (0.00 sec)

Então você deve remover o usuário anônimo com a instrução DROP USER, especificando tanto o nome de usuário (que é uma string vazia '') quanto o host:

DROP USER ''@'localhost';

Você deverá ver esta confirmação:

Query OK, 0 rows affected (0.01 sec)

No entanto, se sua consulta retornar um conjunto vazio como:

Empty set (0.00 sec)

Isso significa que não há usuários anônimos em seu banco de dados, o que já é seguro. Neste caso, se você tentar remover um usuário anônimo inexistente, receberá um erro:

ERROR 1396 (HY000): Operation DROP USER failed for ''@'localhost'

Este erro é esperado se nenhum usuário anônimo existir, e você pode prosseguir com segurança.

Após verificar a existência de usuários anônimos e removê-los, se necessário, limpe os privilégios para garantir que quaisquer alterações sejam aplicadas:

FLUSH PRIVILEGES;

Verifique novamente se nenhum usuário anônimo permanece executando a consulta SELECT:

SELECT User, Host FROM mysql.user WHERE User = '';

Esta consulta deve retornar um conjunto vazio, confirmando que não existem usuários anônimos:

Empty set (0.00 sec)

Você verificou e abordou com sucesso uma potencial vulnerabilidade de segurança em seu servidor. Agora você pode sair do shell do MySQL.

exit;

Resumo

Neste laboratório, você aprendeu e aplicou várias práticas recomendadas essenciais de segurança do MySQL. Você protegeu com sucesso a conta root com uma senha, criou um usuário de aplicação dedicado com permissões limitadas com base no princípio do menor privilégio, gerenciou o acesso do usuário revogando privilégios e verificou e abordou potenciais contas de usuário anônimas.

Ao implementar essas medidas de segurança fundamentais, você pode melhorar significativamente a postura de segurança do seu banco de dados MySQL e protegê-lo contra acesso não autorizado e ameaças potenciais.