Visão geral de como aumentar a proteção do MySQL

Nada de moleza: existem invasores que podem verificar toda a Internet em minutos e decifrar senhas facilmente em segundos. Às vezes, é necessário manter um banco de dados acessível por uma rede IP pública, mas isso deixa o banco de dados exponencialmente mais vulnerável. Uma maneira de reduzir os riscos do IP público é restringir o acesso ao banco de dados a um conjunto limitado de endereços IP.

Dito isso, a melhor solução é permitir apenas o acesso dentro de uma nuvem privada virtual (VPC) e apenas as conexões do operador dentro de um Bastion Host. No Google Cloud, essa solução é chamada de IP privado. Se a instância do MySQL estiver acessível apenas dentro de uma VPC, um invasor primeiro terá que violar a VPC antes de tentar violar sua instância.

Cada versão secundária do MySQL tem notas de versão e quase invariavelmente contêm uma seção sobre atualizações de segurança. Se a instância tiver várias versões desatualizadas, há várias versões de correções de segurança que o banco de dados não tem.

Além de corrigir problemas de segurança ao longo do tempo, o MySQL também apresenta vários recursos de segurança totalmente novos periodicamente. Por exemplo, o MySQL 8.0 introduziu muitas maneiras de aumentar a proteção dos esquemas e dos usuários do MySQL, como papéis, rastreamento de login com falha e geração de senhas aleatórias.

Digamos que você esteja trabalhando em um café e queira fazer algumas consultas e se conecta ao MySQL pela rede Wi-Fi gratuita da loja. Se você não usou a TLS (Transport Layer Security), está efetivamente gritando seu nome de usuário e senha por TCP (o Protocolo de controle de transmissão, um dos principais protocolos da Internet). Aplique a TLS na sua instância do MySQL e trabalhe com seu latte sem se preocupar se outros clientes estão espionando na rede.

Injeção de SQL

Geralmente, não é o banco de dados, mas o aplicativo, que é mais vulnerável a um ataque. Muitos aplicativos foram vítimas de ataques de injeção de SQL, em que um invasor insere entradas maliciosas que seu aplicativo considera uma instrução SQL válida. A melhor proteção contra esses ataques é usar instruções preparadas ao criar instruções SQL em vez de concatenar a entrada do usuário com instruções SQL.

Secrets no seu repositório

Incontáveis bancos de dados foram violados porque um desenvolvedor enviou acidentalmente o nome de usuário e a senha para o repositório de código-fonte. Use uma ferramenta como o Secret Manager do Google Cloud, que gerencia todos os tipos de secrets, incluindo a senha do banco de dados.

Como registrar senhas

Por fim, use as ferramentas de filtragem do framework para filtrar a senha do banco de dados dos registros do aplicativo. Os exemplos incluem os Filtros Log4j ou Rails ParameterFilter, mas a maioria dos frameworks de geração de registros têm um equivalente. Se não for o caso, você precisará garantir que os registros do seu aplicativo sejam seguros para que o banco de dados esteja seguro.

Considere usar a validação de senha para garantir que todas as senhas no seu banco de dados sejam suficientemente complexas. No caso de senhas de app, é necessário que elas sejam longas, complexas e rotacionadas com frequência. Os gerenciadores de secrets são especialmente úteis para que você não precise memorizar senhas complexas e que mudam com frequência. 

Se uma pessoa (e não um aplicativo) for usar um usuáriodo banco de dados, siga os padrões do NIST e priorize o comprimento acima de tudo. As datas de validade da senha e os requisitos de senha excessivamente complexos fazem com que as pessoas deleguem a memória em arquivos de texto simples e notas autoadesivas, o que prejudica todo o propósito dessas regras. 

Melhor ainda, considere usar a autenticação do IAM para usuários que não são do aplicativo. A autenticação do IAM delega o estabelecimento da conexão à oferta do Google Cloud. Isso significa que o risco é reduzido apenas para o usuário do IAM, e não para o usuário do IAM e do banco de dados.

Por fim, o hash padrão do MySQL é a senha do banco de dados, não o sal. Isso significa que os usuários com a mesma senha terão strings de autenticação idênticas, facilitando a identificação de senhas fracas com um ataque de tabela arco-íris. Observe como os dois usuários do MySQL a seguir têm a mesma authentication_string.

Defina a flag default_authentication_plugin como cache_sha2_password. Isso garante que dois usuários com a mesma senha tenham um hash diferente. Observe como os dois usuários têm valores diferentes de authentication_string no exemplo a seguir.

Limitar o acesso não significa apenas garantir o acesso externo, também significa auditar regularmente o acesso de dentro.

Faça a auditoria do seu aplicativo: se ele lê apenas nas tabelas de faturamento, produto e cliente, ele realmente precisa de acesso a todo o restante? Deixar o acesso raiz disponível ao banco de dados significa que um invasor pode causar danos enormes ao seu banco de dados. Pense em todos os requisitos da instância, liste os privilégios necessários e, em seguida, crie um usuário do banco de dados para cada um. Se um invasor violar seu banco de dados em um desses usuários, você terá limitado o escopo do dano.

Faça a auditoria dos usuários: quantos usuários do seu banco de dados realmente precisam de privilégios de administrador nas instâncias? Quantos desses usuários ainda estão na organização, estão vinculados a projetos inativos ou estão inativos? Os tokens de acesso podem vazar, e a ameaça interna é uma preocupação constante para a maioria dos sistemas. Certifique-se de ter o mínimo de usuários possível para ajudar a instância a se proteger dessa classe de problemas.

Faça a auditoria do "administrador": considere remover ou renomear os usuários como "raiz" ou "administrador". Eles são alvos fáceis para invasores. Se eles não existirem, seu sistema será um pouco mais difícil de ser violado. Isso é chamado de segurança por obscuridade. Embora não deva ser a primeira linha de defesa, isso pode adicionar uma fina camada de segurança ao banco de dados do MySQL.

Backups regulares de dados e planos de recuperação de dados verificáveis são essenciais para um gerenciamento de banco de dados íntegro. No entanto, mesmo com backups regulares, é possível perder todos os dados gravados após o último backup. Um dos benefícios do ecossistema do MySQL é a recuperação pontual (PITR, na sigla em inglês), que permite recuperar dados a qualquer momento. Para possibilitar a PITR, ative os registros binários nas instâncias do Cloud SQL para MySQL.

Se você já tiver feito todas as etapas acima, estará bem preparado e bem protegido. Por isso, nenhum design de segurança seria completo sem uma vigilância contínua (auditoria do banco de dados). Com o plug-in de auditoria do Cloud SQL para MySQL, é possível acompanhar comportamentos incomuns em caso de violações.

Feito tudo o que foi indicado acima, você terá tornado qualquer caminho para uma violação do banco de dados muito mais difícil para um invasor. Um invasor teria que violar seu aplicativo e esperar que o usuário do banco de dados dele tenha privilégios suficientes para o ataque ou precisaria violar sua VPC, encontrar um nome de usuário, descobrir a senha e esperar que o usuário tenha privilégios suficientes para executar o ataque. Enquanto isso, é possível ver os registros de auditoria ou de banco de dados do MySQL para monitorar qualquer comportamento comum no banco de dados e reagir de acordo com isso.

É isso que significa segurança incorporada ao design. Os invasores continuarão a descobrir maneiras de explorar máquinas. Por isso, é importante criar um sistema com o máximo de camadas de proteção possível para proteger seu banco de dados.