A segurança é fundamental hoje em toda a TI. De tempos em tempos, ouvimos falar de ataques de ransomware ou vazamentos de dados que têm origem em bancos de dados ou infraestrutura de TI não protegidos. Você pode se perguntar:quais são as melhores práticas na arquitetura do ambiente MySQL para que você possa se sentir seguro em relação aos seus dados? Se sim, este blog é para você. Lembre-se de que não abordaremos o tópico totalmente - isso se encaixaria mais em um whitepaper do que em um blog. Faremos o possível para mencionar os aspectos mais importantes da segurança do seu banco de dados MySQL. A ideia por trás deste blog é que o leitor saiba o que não sabe e ajude a identificar os tópicos e palavras-chave para futuras pesquisas. Ilustraremos isso com capturas de tela do nosso produto, ClusterControl, que vem com um vasto conjunto de recursos, incluindo alguns relacionados à segurança do banco de dados.
Rede
Primeiro de tudo, temos que implantar o MySQL em algum lugar. Seja uma instância autônoma, replicação assíncrona de réplica primária ou uma das topologias de replicação síncrona mais avançadas, como Galera ou InnoDB Cluster. Não importa o que seja, ele deve ser protegido no nível da rede. O banco de dados contém os dados, que, muito comumente, são o ativo mais valioso de toda uma organização.
Protegendo o acesso
As instâncias de banco de dados nunca devem estar localizadas na rede pública. Os segmentos de rede nos quais os bancos de dados são configurados devem ser acessíveis apenas a partir de um número limitado de outras redes. A regra geral é - um determinado nó deve ser capaz de acessar a rede de banco de dados? Se a resposta for não, as redes devem ser separadas.
Claro, tudo depende da configuração exata, mas nos casos mais comuns, onde você tem camadas de aplicativo, proxy, cache e banco de dados, a configuração mais típica seria que apenas o proxy deveria ser capaz para acessar o banco de dados. Todas as outras entidades devem ser configuradas de forma que acessem o banco de dados apenas via camada proxy. Este design é bom de várias maneiras. Além do aumento da segurança, também ajuda a ocultar a complexidade da camada de banco de dados do aplicativo.
A camada proxy deve seguir a topologia do banco de dados e deve lidar com as falhas do nó do banco de dados e as alterações na topologia. O aplicativo, conectando-se à camada de proxy, deve sempre ser capaz de alcançar um nó de banco de dados de trabalho relevante para o tipo de solicitação. O mesmo acontece com a camada de cache. Ele pode ser implementado na camada de proxy, alguns proxies como o ProxySQL permitem solicitações de cache dentro do proxy, mas se for uma camada separada construída em torno de, por exemplo, memcache ou Redis, ele sempre deve acessar o banco de dados por meio da camada de proxy.
Outro tipo de nós que pode precisar ter acesso direto à camada de banco de dados são os nós de gerenciamento - aqueles que são usados pelas equipes operacionais para gerenciar os bancos de dados. A razão é simples:algumas das tarefas de manutenção podem exigir acesso direto aos bancos de dados. Podem ser scripts de automação de tarefas, rolando playbooks do Ansible em toda a frota de banco de dados ou outras tarefas. Nesse caso, obviamente, medidas de segurança devem estar em vigor para garantir que apenas as pessoas que tenham acesso possam fazer login nesse nó de gerenciamento.
Outro tipo possível de nós (embora os nós de gerenciamento também possam ser usados para isso) que podem exigir acesso ao banco de dados são os nós envolvidos na coleta de métricas e apresentá-las aos usuários - estamos falando aqui de monitoramento e atividades de alerta.
VPN
Para qualquer tipo de camada de banco de dados abrangendo vários datacenters, você deve considerar o uso de VPN para conectá-los. Conexões abertas e não criptografadas pela rede WAN é algo que nunca deveria acontecer. Mesmo configurar a criptografia SSL não é a melhor opção, pois exigiria a abertura do acesso entre a camada do banco de dados e a WAN - as conexões SSL entre os nós do banco de dados exigem que eles possam se conectar diretamente. A VPN resolve esse problema adicionando um intermediário que cria uma maneira segura de conectar segmentos da rede da camada de banco de dados.
A VPN também deve ser obrigatória para qualquer tipo de acesso de usuário à rede da organização, pois implementa conectividade segura entre uma estação de trabalho e a rede de produção.
Firewall
É claro que, ao proteger a rede, devemos considerar o uso do firewall. De um modo geral, cada nó de banco de dados deve receber apenas conexões de um conjunto definido de fontes - nomes de host e portas. Mesmo os segmentos de rede “necessários” não devem ter acesso total à rede do banco de dados, mas apenas às portas necessárias. Se o proxy precisar se conectar apenas à porta do banco de dados, não há razão para ele poder acessar qualquer outra porta nos nós do banco de dados. Observe também que você não deve usar as portas padrão. É, obviamente, segurança por obscuridade - afinal a porta está aberta em algum lugar, mas ajuda a lidar com pelo menos algumas das intrusões de segurança que usam scripts automatizados. Isso não impedirá alguém que está determinado a obter o acesso, mas pode atrasá-lo (quando combinado com detecção de varredura de porta e medidas anti-varredura) enquanto impede o sucesso de ataques automatizados.
Segurança do banco de dados
A rede é a primeira linha de defesa, existem outras medidas de segurança e boas práticas que você pode usar para melhorar ainda mais sua segurança. Alguns deles podem ser implementados no próprio banco de dados.
Usuários e hosts
Os próprios bancos de dados podem ser usados para implementar controle de acesso e restrições. Para começar, você pode implementar o controle de acesso baseado em host, impedindo que outros hosts além da pequena lista de nós efetuem login no banco de dados. Claro, se você usou um firewall para limitar o acesso, isso pode soar como uma duplicata, mas ainda é uma boa ideia limitar o acesso no próprio banco de dados - você nunca sabe quando, por acidente, um firewall será desabilitado. Nesse caso, você ainda tem uma segunda camada de proteção.
O que você deseja implementar aqui é uma lista de usuários e hosts do banco de dados que têm permissão para acessar o banco de dados. Provavelmente, o que você deve acabar tendo é um ou mais usuários com acesso concedido de hosts localizados na camada de proxy. O nível de detalhamento do controle de acesso que você pode ter depende do sistema de banco de dados que você possui. O MySQL, por exemplo, não permite controle detalhado sobre as máscaras de rede - ele apenas usa /32, /24, /16 ou /8. No PostgreSQL, por outro lado, você pode usar qualquer tipo de máscara de rede.
Subsídios
Se é isso que seu banco de dados permite, cada um dos usuários deve ter um conjunto definido de concessões - garantindo que os privilégios atribuídos a eles sejam os mínimos necessários para que o usuário execute as ações que ele deve fazer . Os sistemas de banco de dados podem ter diferentes conjuntos de privilégios e diferentes níveis deles. Normalmente, temos vários níveis de privilégios - global, afetando todo o servidor de banco de dados, nível de esquema - determinado usuário pode ter privilégios diferentes atribuídos a esquemas diferentes. Você pode ter privilégios em uma tabela ou até mesmo em nível de coluna. Como mencionamos anteriormente, o objetivo é criar o conjunto mínimo de privilégios para cada usuário. Você provavelmente desejará ter pelo menos um usuário com altos privilégios - ele seria usado para gerenciar o banco de dados. Esse usuário deve ser estritamente limitado quando se trata de conectividade. Ele não deve (e, na verdade, nenhum dos usuários não deve) ter permissão para se conectar de qualquer local - deve ser um host local ou algum nó de gerenciamento específico, dedicado à execução de operações no banco de dados.
Gerenciamento de senha
Cada usuário no banco de dados deve ter uma senha definida. Este é um acéfalo. A senha deve ser armazenada em forma de hash. Você deve garantir que, para armazenar as senhas, esteja usando o algoritmo de hash mais seguro que seu banco de dados tem a oferecer. As senhas não devem ser fáceis de adivinhar nem devem ser vulneráveis ao ataque de dicionário. Alguns sistemas de banco de dados, como o MySQL, permitem definir com precisão os requisitos que suas senhas devem atender para que sejam usadas. Letras maiúsculas e minúsculas, números, caracteres especiais, comprimento da senha - tudo isso é importante e se você puder aplicar algumas políticas em torno da força da senha, você deve fazer isso. Outra parte importante é a rotação de senha. As senhas não devem ser criadas uma vez por toda a vida útil do banco de dados, você deve ter uma política de rotação de senhas. Novamente, alguns dos sistemas de banco de dados podem impor isso para você. O usuário administrativo pode criar novas contas de usuário com a rotação de senha aplicada. Ele também pode forçar a rotação de senhas para um determinado usuário.
Registros de auditoria
Alguns dos sistemas de banco de dados oferecem logs de auditoria - a idéia é coletar o máximo possível de informações sobre a atividade no banco de dados. Quem e quando fez o quê? Qual consulta foi executada, por quem? Quem tentou fazer login, mas falhou? De qual host? Idealmente, os logs contendo essas informações seriam armazenados fora dos nós do banco de dados. Você pode transmiti-los para seu servidor de log central para proteção, processamento adicional e melhores recursos de pesquisa.
Segurança SQL
Mencionamos usuários e hosts, mas o ataque também pode ocorrer de uma fonte diferente. Se seu aplicativo não estiver protegido adequadamente e a entrada não for validada corretamente, você pode estar enfrentando ataques originados em seu site. Estamos falando aqui sobre injeção de SQL. Nesse caso, os firewalls não são realmente úteis, pois a consulta se originou de uma fonte válida (seu servidor web e, em seguida, nó proxy). Atribuir concessões pode realmente ajudar a prevenir alguns desse tipo de ataque, mas não é uma solução ideal - afinal sua aplicação, na maioria dos casos, precisará de um usuário que possa remover ou modificar o conteúdo do banco de dados. Tal usuário, quando explorado, pode ser usado para causar danos. Existem várias maneiras pelas quais você pode tentar combater o tratamento.
firewall SQL
A maneira mais simples de fazer isso é implementando o firewall SQL. Pode ser realizado em diferentes níveis e em diferentes lugares. Uma das opções é usar balanceadores de carga para isso. Alguns deles vêm com essa funcionalidade pelo menos facilmente alcançável, se ainda não estiver implementada. A ideia por trás disso é construir uma lista de consultas que seu aplicativo executa e depois configurar seu proxy para passar apenas por esse tipo de tráfego. Não é o ideal, pois você terá que mantê-lo a tempo, adicionando novas consultas e removendo as antigas que não são mais usadas. Por outro lado, tal conjunto de regras impedirá que qualquer consulta não autorizada chegue ao banco de dados.
Detecção de injeção de SQL
Outra opção possível seria implementar a detecção de injeção de SQL na camada proxy. Existem algumas soluções, ProxySQL entre outras, que podem ser configuradas para tentar detectar injeção de SQL no tráfego que está passando por elas. Claro, tudo isso é baseado em heurística, então pode resultar em falsos positivos, mas pode ser uma boa adição ao firewall SQL.
No passado, discutimos como você pode implementar o firewall SQL e a detecção de injeção de SQL usando ProxySQL, um balanceador de carga que pode ser implantado a partir do ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Segurança de dados
Finalmente, a segurança dos dados. Discutimos até agora como se pode fortalecer o banco de dados, como limitar o acesso a ele e como evitar diferentes tipos de ataques vindos do próprio aplicativo. Ainda devemos considerar a proteção dos dados em si. Isso pode ter várias camadas. Segurança física - se você possui o datacenter, verifique se ele está devidamente bloqueado. Se você usa provedores de ISP externos ou provedores de nuvem, certifique-se de que eles tenham protocolos de segurança adequados quando se trata de acessar o hardware. Então temos um servidor, VM ou como você estiver usando. Os dados ficam no disco, armazenados localmente no servidor. Os dados estão sendo transferidos entre o aplicativo, o proxy e o banco de dados. Os dados são transferidos entre os nós do banco de dados por meio de replicação. Os dados estão sendo armazenados fora do local como backups. Esses dados devem ser protegidos.
Backups
Os backups devem sempre ser criptografados. A chave de criptografia deve ser mantida com cuidado e alternada regularmente.
Dados em trânsito
Os dados transferidos devem ser criptografados. Certifique-se de ter configurado seu aplicativo, camada proxy e banco de dados para usar SSL ou TSL. Todos os meios de transferência de dados entre os nós do banco de dados também devem ser protegidos e criptografados. O objetivo é tornar inútil qualquer tipo de sniffing de rede.
Dados em repouso
Finalmente, os próprios dados, armazenados no nó do banco de dados. Ele também deve ser criptografado. Existem alguns métodos que você pode usar ao abordar esse tópico. Primeiro, a criptografia no nível do host. O volume no qual o banco de dados tem seu diretório de dados pode ser criptografado (e descriptografado na inicialização). Os bancos de dados também costumam vir com recursos de criptografia. O que pode ser criptografado depende da solução exata e do tipo e versão do banco de dados, mas em alguns casos as opções são bastante extensas. Criptografia de tablespace, criptografia de log, às vezes até criptografia das estruturas na memória. Se você fizer isso corretamente, acessar o nó do banco de dados não será suficiente para acessar os dados.
Conclusão
Como mencionamos anteriormente, este blog não pretende ser um guia prático sobre segurança de banco de dados, mas abordamos a maioria dos aspectos que você deve considerar ao arquitetar seu ambiente de banco de dados e esperamos você achará este guia útil.
