Melhores práticas de segurança

Otimizar as configurações de conexão de banco de dados para reduzir os riscos de ataques à rede

1. Não vincule um EIP à sua instância do RDS for MySQL para acesso pela Internet.

   Não implemente sua instância na Internet ou em uma zona desmilitarizada (DMZ). Em vez disso, implemente-a em uma intranet e use roteadores ou firewalls para protegê-la. Não vincule um EIP à sua instância para acesso pela Internet para evitar acesso não autorizado e ataques DDoS. Se você vinculou um EIP à sua instância, é aconselhável desvinculá-lo. Se você precisar de um EIP, configure regras de grupo de segurança para restringir os endereços IP de origem que podem acessar sua instância.

2. Não use o número de porta padrão.

   As instâncias do RDS for MySQL usam a porta 3306 por padrão, que é mais vulnerável a ataques maliciosos. Altere o número da porta da sua instância de BD.

3. Restrinja os recursos disponíveis de um usuário de banco de dados.

   Se os recursos disponíveis para um usuário do banco de dados não forem restritos, o sistema poderá ficar sobrecarregado quando o usuário for atacado, causando DoS. A restrição de recursos disponíveis de um usuário de banco de dados pode impedir o consumo excessivo de recursos causado pela ocupação excessiva de recursos. Para evitar que a disponibilidade de serviço seja afetada em cenários de carga pesada, você precisa configurar os recursos disponíveis para um usuário de banco de dados com base no modelo de serviço usando as seguintes instruções SQL:

   alter user  '<user>'@'<hostname>' with max_queries_per_hour <queries_num>;
   alter user  '<user>'@'<hostname>' with max_user_connections <connections_num>;
   alter user  '<user>'@'<hostname>' with max_updates_per_hour <updates_num>;
   alter user  '<user>'@'<hostname>' with max_connections_per_hour <connections_per_hour>;

   • <user> indica o nome do usuário para o qual você deseja configurar os recursos.
   • <hostname> indica o nome do host.
   • <queries_num> indica o número máximo de consultas permitidas para o usuário por hora.
   • <connections_num> indica o número máximo de conexões permitidas para o usuário.
   • <updates_num> indica o número máximo de atualizações permitidas para o usuário por hora.
   • <connections_per_hour> indica o número máximo de conexões permitidas para o usuário por hora.
4. Não use o caractere curinga % para o nome do host.

   O nome do host especifica qual host tem permissão para se conectar ao seu banco de dados. O nome do host corresponde ao campo do host na tabela user. Se o nome do host estiver definido como o curinga %, o usuário aceitará conexões de qualquer endereço IP, aumentando os riscos de ataques ao banco de dados. Para minimizar os riscos de ataque, é aconselhável definir o endereço IP do host para um segmento de rede ou endereço IP específico.

5. Limite o tempo de espera de conexões de banco de dados ociosas.

   Cada conexão com um servidor do RDS for MySQL consome memória e o número máximo de conexões suportadas é limitado. Se o servidor do RDS for MySQL tiver um grande número de conexões ociosas, muita memória será consumida e o número máximo de conexões poderá ser atingido. Nesse caso, a mensagem de erro "too many connections" será reportada se uma nova conexão for estabelecida. Você precisa definir o tempo de espera para conexões ociosas para garantir que as conexões ociosas sejam limpas a tempo. Altere os valores de wait_timeout e interactive_timeout consultando Modificação de parâmetros de uma instância do RDS for MySQL.

6. Verifique se o SSL está ativado por padrão.

   Se o SSL não estiver configurado, os dados transmitidos entre o cliente MySQL e o servidor estarão em texto simples, o que é vulnerável a ataques de espionagem, adulteração e man-in-the-middle. Para melhorar a segurança da transmissão de dados, é recomendável adicionar o atributo REQUIRE SSL e configurar SSL para usuários do banco de dados.

   Você pode usar as seguintes instruções SQL:

   create user '<user>'@'<hostname>' REQUIRE SSL;
   alter user '<user>'@'<hostname>' REQUIRE SSL;

Gerenciar adequadamente as contas e senhas do banco de dados para reduzir os riscos de vazamento de dados

1. Altere periodicamente a senha do administrador.

   A conta de administrador de banco de dados padrão root tem permissões altas. É aconselhável alterar periodicamente a senha do usuário root consultando Redefinição da senha do administrador para restaurar o acesso a root.

2. Configure a complexidade da senha.

   Como coletor de informações, o sistema de banco de dados é facilmente alvo de ataques. Você precisa manter sua conta e senha de banco de dados seguras para evitar a divulgação. Além disso, é aconselhável configurar a complexidade da sua senha para evitar senhas fracas. Para obter detalhes, consulte "Configuração da complexidade da senha" em Segurança da conta do banco de dados.

3. Configure uma política de expiração de senha.

   Usar a mesma senha por muito tempo torna mais fácil para os hackers quebrarem ou adivinharem sua senha. É aconselhável configurar uma política de expiração de senha para restringir o tempo em que uma senha pode ser usada.

Reforçar o gerenciamento de permissões para reduzir os riscos relacionados

1. Não crie procedimentos ou funções armazenados como administrador.

   Procedimentos e funções armazenados são executados como criadores por padrão. Se você criar procedimentos e funções armazenados como administrador, os usuários comuns poderão executá-los por meio da escalação de privilégios; portanto, não use o administrador para criar procedimentos ou funções armazenados.

2. Revise e fortaleça as configurações de permissão.

   Verifique se as seguintes configurações de permissão atendem aos requisitos de segurança. Se elas não atenderem aos requisitos de segurança, fortaleça as configurações.

   • Verifique se apenas o administrador pode executar operações na tabela mysql.user.
   • Verifique se a permissão Process_priv só pode ser concedida ao administrador.
   • Verifique se a permissão Create_user_priv só pode ser concedida ao administrador.
   • Verifique se a permissão Grant_priv só pode ser concedida ao administrador.
   • Verifique se a permissão Reload_priv só pode ser concedida ao administrador.
   • Verifique se a conta de replicação tem apenas a permissão replication slave.
   • Verifique se o usuário de monitoramento de métricas de banco de dados tem apenas a permissão replication client.

   Exemplo: se um usuário não-administrador tiver a permissão Process, execute a seguinte instrução SQL para revogar a permissão Process:

   revoke process on *.* from <your_account>;

   No comando anterior, <your_account> indica o nome do usuário cuja permissão Process precisa ser revogada.

Ativar a auditoria de banco de dados para retrocesso pós-evento

A função de auditoria do banco de dados registra todas as operações do usuário no banco de dados em tempo real. Ao registrar, analisar e relatar o acesso do usuário ao banco de dados, a auditoria do banco de dados ajuda a gerar relatórios de conformidade e a rastrear acidentes, melhorando a segurança dos ativos de dados. Para obter detalhes, consulte Ativação da auditoria de SQL.

Configurar o backup de dados para garantir a confiabilidade dos dados

1. Ative backup de dados.

   O RDS for MySQL disponibiliza backups automatizados e manuais. Você pode periodicamente fazer backup de bancos de dados. Se um banco de dados estiver com defeito ou os dados estiverem danificados, você poderá restaurar o banco de dados usando backups para garantir a confiabilidade dos dados. Para obter detalhes, consulte Backups de dados.

2. Configure uma política de limpeza de binlog.

   Binlogs aumentam continuamente à medida que os serviços são executados. Você precisa configurar uma política de limpeza para impedir a expansão do disco. Configure o período de retenção binlog consultando Definição de um período de retenção local para binlogs do RDS for MySQL.

Criptografar dados antes do armazenamento

Para melhorar a segurança dos dados do usuário, é aconselhável ativar a criptografia do lado do servidor. Depois que a criptografia do lado do servidor for habilitada, os dados serão criptografados no servidor antes de serem armazenados quando você criar uma instância de banco de dados ou expandir o espaço de armazenamento, reduzindo os riscos de vazamento de dados.

Fortalecer parâmetros sensíveis

1. Defina local_infile como 0.

   Se local_infile for definido como 1, o cliente de banco de dados poderá usar a sintaxe load data local para carregar arquivos locais em tabelas de banco de dados. Por exemplo, quando um servidor Web funciona como um cliente de banco de dados para se conectar a um banco de dados, se o servidor Web tiver uma vulnerabilidade de injeção de SQL, um invasor pode usar o comando load data local para carregar arquivos confidenciais no servidor Web para o banco de dados, causando vazamento de informações. É aconselhável definir local_infile como 0 consultando Modificação de parâmetros de uma instância do RDS for MySQL.

2. Defina o parâmetro sql_mode como um valor que contenha STRICT_ALL_TABLES.

   Ao tentar lançar um ataque, um atacante pode inserir vários parâmetros de forma tentativa e erro. Se o servidor se adaptar a instruções incorretas, os dados do banco de dados podem ser vazados. Portanto, STRICT_ALL_TABLES é recomendado. Mesmo que ocorra um erro em outras linhas que não a primeira linha, a instrução será descartada assim que um valor de dados inválido for encontrado. Esse método garante ao máximo que as informações do banco de dados não sejam divulgadas. É recomendável definir sql_mode como um valor que contenha STRICT_ALL_TABLES consultando Modificação de parâmetros uma instância de RDS for MySQL.

Usar a versão mais recente do banco de dados para melhorar a experiência e a segurança

A comunidade do MySQL divulga irregularmente vulnerabilidades recentemente descobertas. O RDS for MySQL avalia os riscos reais das versões do kernel do banco de dados e lança novas versões do kernel do banco de dados de acordo. Para melhorar a usabilidade e a segurança do sistema de banco de dados, é aconselhável usar a versão mais recente do banco de dados.

Usar outros serviços de nuvem para segurança de dados adicional

Para obter recursos de segurança de dados estendidos, é aconselhável usar Database Security Service (DBSS).