Como você deve proteger seu banco de dados?

Shutterstock / hywards

Seu servidor de banco de dados geralmente contém seus dados mais confidenciais, como informações confidenciais do usuário. É importante implementar as práticas recomendadas de segurança para minimizar o risco de um invasor obter acesso ao seu banco de dados.

Este guia será específico para o MySQL, pois é o banco de dados mais comum, mas a maioria desses conceitos se aplicará a qualquer tipo de banco de dados; você precisará apenas de configurações diferentes para obter o mesmos efeitos.

Certifique-se de executar o mysql_secure_installation

O MySQL possui uma ferramenta interna que pode lidar com algumas tarefas básicas de segurança. Depois de instalar o MySQL, execute o seguinte comando no seu terminal:

 mysql_secure_installation 

Isso o guiará por algumas tarefas - definindo uma nova senha, removendo usuários anônimos e testando bancos de dados e desativando o login raiz remoto. Depois, ele recarregará a configuração do MySQL para você, então você deverá ver as alterações imediatamente.

Bloquear SSH

Isso tecnicamente não tem nada a ver com o próprio banco de dados; no entanto, seu banco de dados é tão seguro quanto o servidor em que está sendo executado, portanto, você deve tomar as medidas necessárias para bloquear o SSH e impedir a maioria dos vetores de ataque comuns.

Você pode ler o nosso guia completo sobre segurança SSH para saber mais, mas a essência disso são algumas etapas:

• Desative o login com senha, use apenas chaves SSH.
• Limite de taxa de tentativas de login com denyhosts para evitar força bruta.
• Acesso à lista de permissões para endereços IP confiáveis.
• Desabilite o login root no SSH 'desta maneira, os invasores precisam saber seu nome de usuário.
• Configure a autenticação multifator para SSH se você for realmente paranóico.

Execute um banco de dados autônomo em uma sub-rede privada

Em vez de executar um banco de dados local no mesmo servidor em que o nginx está executando, é melhor para segurança executar seu banco de dados em uma sub-rede privada que só pode ser acessada por outros servidores em sua nuvem privada. Muitos provedores de nuvem, incluindo a AWS, oferecem esses recursos.

A configuração fica assim:

Sua nuvem privada virtual (VPC) é simplesmente o contêiner em que todos os seus recursos da AWS executam. As coisas nessa nuvem podem conversar entre si em seus endereços IP privados, exatamente como os dispositivos em sua casa interagiriam.

Os servidores na sub-rede pública terão endereços IP públicos e serão acessíveis diretamente por qualquer pessoa. Os servidores na sub-rede privada não têm endereços IP públicos - apenas um endereço privado. No entanto, eles ainda podem acessar a Internet, usando a Conversão de endereços de rede, o mesmo método que dá ao computador acesso atrás de um roteador doméstico.

Isso significa que qualquer servidor iniciado na sub-rede privada ficará totalmente inacessível a partir de atacantes externos. A única maneira de acessar seu banco de dados é se o servidor da Web estiver comprometido e, mesmo assim, ainda exigiria uma escalação de privilégios.

Além dos benefícios de segurança, essa configuração também é muito mais fácil de escalar. Por exemplo, você pode ter quatro servidores Web executando o WordPress que se conectam a um único servidor de banco de dados autoritativo. Dessa forma, todos os quatro servidores da Web estão sincronizados e você pode facilmente aumentar e diminuir para atender à demanda, sem se preocupar com o banco de dados. Isso pode causar alguns problemas de desempenho devido à sobrecarga da rede, mas com o armazenamento em cache multicamada adequado, o problema é mínimo comparado aos benefícios da arquitetura.

Para fazer o MySQL aceitar apenas conexões de conexões privadas, você desejará usar uma máscara de rede em sua instrução GRANT. Isso não funciona com a notação CIDR, apenas a máscara de rede completa.

 CONCEDE TUDO NO banco de dados. * PARA 'usuário'@'10.0.1.0/255.255.255.0' IDENTIFICADO POR 'senha' 

Se você estiver executando apenas um servidor, deve vincular pelo menos seu banco de dados ao host local para que ele não esteja acessível a partir da Internet aberta.

Vincule ao host local se possível (ou pelo menos uma porta diferente)

Se você não estiver acessando o servidor de banco de dados a partir de outros processos em execução na própria máquina, poderá travá-lo para que não fique acessível pela rede. Obviamente, isso só funciona se você tiver um servidor executando tudo, e essa não é a melhor configuração em primeiro lugar.

Se você não pode ligar-se ao host local, é uma boa ideia alterar a porta padrão para outra coisa.

De qualquer forma, você pode fazer isso facilmente vinculando o MySQL ao localhost, o que significa que ele apenas escutará no endereço de loopback e não em nenhuma porta aberta. Abra /etc/mysql/my. conf no seu editor de texto favorito e adicione a seguinte linha na seção [mysqld]:

endereço de ligação

 = 127.0.0.1 

Você também pode alterar a porta padrão nesta mesma seção:

Porta

 = 5000 

Reinicie o MySQL e você verá as alterações.

Assista ao histórico do seu shell

A maioria das coisas que você faz no Linux é registrada. Se um invasor conseguir obter acesso a esses arquivos de log, poderá aumentar seus privilégios encontrando senhas armazenadas neles.

Isso pode acontecer de duas maneiras principais para o MySQL, ambas facilmente evitáveis. A primeira é quando você faz login no shell do MySQL e nunca deseja especificar a senha como argumento na linha de comando. Sempre deixe em branco e deixe o MySQL solicitá-lo.

 mysql -u raiz -p 

Caso contrário, é visível usando o comando history.

O MySQL também possui seu próprio arquivo de histórico, armazenado em ~ / . mysql_history. Obviamente, isso não registra a senha que você usa para efetuar o login, mas se você criou um novo usuário a partir da linha de comando do MySQL, essa instrução será registrada como senha e tudo. Você deseja limpar este arquivo como precaução se precisar modificar as contas de usuário.

 # cat / dev / null > ~ / . mysql_history 

Se você estiver na AWS, considere usar o RDS

O Serviço de Banco de Dados Relacional (RDS) da AWS é um banco de dados totalmente gerenciado na nuvem. Se você não deseja se preocupar com a segurança do banco de dados e apenas deseja uma solução implantável, o RDS (e todos os outros serviços de banco de dados gerenciados da AWS) eliminará a dor de cabeça.

O RDS usa o próprio sistema de gerenciamento de identidades e acessos (IAM) da AWS. O IAM gerencia permissões para tudo o que você faz na AWS. Todas as ações no console de gerenciamento, comandos da CLI e solicitações de API baseadas na Web devem passar pelo IAM. Qualquer ação será bloqueada se o usuário ou entidade que estiver executando não tiver permissão explícita para acessar o recurso fornecido. Além disso, o RDS é privado por padrão, então você não precisa se preocupar com ataques da Internet aberta.

Você ainda vai acabar usando a autenticação padrão de nome de usuário e senha do MySQL para se conectar ao próprio banco de dados, embora o IAM simplesmente proteja todo o resto do banco de dados, como a configuração. No entanto, você pode usar o Secrets Manager da AWS, que permite girar constantemente as chaves de segurança sem reimplementações de código, além de integrar a integração do RDS à inicialização.

Se desejar, também é possível ativar a autenticação do banco de dados IAM, o que permitirá ignorar completamente a autenticação por senha e apenas usar o IAM. No entanto, ele adiciona alguma sobrecarga e, como tal, é limitado a 200 novas conexões por segundo no MySQL.

Via: How to Geek