11 etapas para proteger o SQL em 2023

Esteja você executando o SQL Server da Microsoft (que em breve será executado no Linux) ou o MySQL de código aberto, você precisa bloquear seus bancos de dados para manter seus dados privados e seguros. Essas 11 etapas o guiarão por alguns dos princípios básicos de segurança de banco de dados e como implementá-los. Combinado com uma configuração de servidor web reforçada, um servidor de banco de dados seguro impedirá que um aplicativo se torne um ponto de entrada em sua rede e evitará que seus dados acabem despejados na Internet. Ao provisionar um novo SQL Server, lembre-se de levar em consideração a segurança desde o início; Deve fazer parte do seu processo regular, não algo aplicado retroativamente, pois algumas medidas de segurança importantes exigem alterações fundamentais de configuração para servidores e aplicativos de banco de dados instalados de forma insegura.

1. Isole o servidor de banco de dados

Os servidores de banco de dados de produção devem ser isolados o máximo possível de outros aplicativos e serviços. Os servidores de banco de dados dedicados ocupam menos espaço e, portanto, atacam Os sistemas operacionais devem ser enxutos, com apenas os serviços necessários instalados e em execução. Não instale outros aplicativos, a menos que sejam exigidos pelo servidor de banco de dados.

Dependendo do tamanho do seu ambiente, você deve considerar colocar seu servidor SQL em um segmento de rede/VLAN restrito para que somente o tráfego autorizado possa passar para ele. Normalmente, apenas um servidor de aplicativos ou servidor web estará se comunicando diretamente com o banco de dados, portanto, políticas de rede bastante restritivas podem ser promulgadas para evitar conexões ilícitas. Isso deve ser óbvio, mas você nunca deve abrir seu servidor de banco de dados na Internet nas portas 1433/1434 (MSSQL) e 3306/3307 (MySQL).

2. Adapte a instalação do banco de dados

Tanto o MSSQL quanto o MySQL oferecem vários recursos adicionais, a maioria dos quais você provavelmente não precisará para nenhuma instância específica. Ao remover as peças que você não precisa, você reduz as possíveis incursões de exploração. Se você quiser manter um recurso por perto para brincar que ainda não está usando, faça-o em um ambiente de teste ou desenvolvimento — é melhor manter a produção bloqueada o máximo possível, especialmente antes de determinar quais efeitos um novo módulo pode ter em seu ambiente.

3. Mantenha-o atualizado

Tanto o MSSQL quanto o MySQL são corrigidos regularmente, portanto, certifique-se de manter sua versão atualizada. A maioria das vulnerabilidades exploradas é conhecida há mais de um ano, portanto, a instalação de patches de segurança em tempo hábil pode evitar a maioria dos ataques simplesmente selando essas falhas. Ter um cronograma e protocolo regulares de aplicação de patches pode ajudar a implementar atualizações em um ambiente de teste para que quaisquer efeitos negativos possam ser descobertos sem interromper a produção. Muitas lojas não têm esse luxo e voam pelo assento de suas calças, instalando atualizações diretamente na produção e esperando o melhor. Normalmente isso funciona, felizmente, mas quando isso não acontece, pode dar errado rapidamente, então, pelo menos, entenda suas opções e procedimentos de reversão, bem como exatamente o que o patch está mudando.

4. Restrinja os processos de banco de dados

O usuário sob o qual o serviço de banco de dados é executado determina o acesso que os processos de banco de dados têm para o restante do servidor, incluindo o sistema de arquivos, a capacidade de executar programas e assim por diante. Como acontece com a maioria dos aplicativos Linux, o MySQL normalmente será executado em uma conta de usuário mysql dedicada com permissões mínimas para o resto do servidor. Você pode verificar isso com um simples comando ps e certificar-se de que o MySQL não foi configurado para ser executado como root, o que definitivamente acontece, especialmente em circunstâncias extremas, solucionando uma interrupção, por exemplo, e não é reconfigurado depois que a crise foi evitada.

Mas em instalações do Windows, o MSSQL geralmente é executado como sistema local ou uma conta de administrador, permitindo que processos de banco de dados, incluindo procedimentos armazenados e interfaces de shell de comando, como xp_cmdshell, tenham acesso total. Idealmente, o MSSQL deve ser executado como uma conta local dedicada e não administradora com privilégios mínimos. Os assistentes de instalação mais recentes do MS podem até automatizar essa etapa para você, portanto, se você estiver instalando um servidor novo, certifique-se de configurar essa opção. Outros serviços SQL, como o SQL Agent, também devem ser executados como contas locais restritas, com permissões concedidas conforme necessário, por exemplo, para um diretório de backup.

A falha em executar essa etapa pode permitir que um servidor de banco de dados comprometido comprometa o restante da máquina e possivelmente se infiltre na rede.

5. Restrinja o tráfego SQL

Conforme mencionado na etapa um, os servidores de banco de dados normalmente têm apenas outro servidor (ou vários) conectados a ele. Se for esse o caso, o acesso ao servidor nas portas do banco de dados deve ser bloqueado em todos os outros lugares. Ao permitir apenas o tráfego SQL de e para endereços IP designados, você pode ter certeza de que um agente mal-intencionado ou cliente infectado dentro do firewall não prejudicará seu servidor. Em alguns casos, os clientes precisarão se conectar diretamente ao próprio servidor de banco de dados, por exemplo, com um aplicativo front-end de cliente espesso. A mesma lógica se aplica aqui, restringindo essas conexões SQL aos IPs específicos (ou pelo menos ao segmento IP) que precisam delas. Como esses são endpoints, certifique-se de protegê-los adequadamente, pois o malware pode verificar e atacar servidores SQL. Você pode lidar com isso com iptables no Linux, o firewall do Windows ou, de preferência, um dispositivo de firewall dedicado.

6. Use privilégios mínimos ao atribuir permissões

Os usuários de banco de dados, como os usuários de qualquer sistema, devem ter apenas o acesso necessário para desempenhar suas funções, também conhecido como princípio do privilégio mínimo. Fique longe de "TODAS" concessões no MySQL e da associação à função sysadmin no MSSQL, se possível. Considere conceder acesso de leitura a exibições em vez de diretamente a tabelas, para proteger campos confidenciais, se necessário. Procedimentos armazenados, planos de manutenção e outras tarefas automatizadas devem ser executados como usuários dedicados com o conjunto de permissões apropriado. Essa medida impede que qualquer parte do servidor de banco de dados, ou qualquer usuário mal-intencionado ou comprometido, destrua todo o sistema. Muitas vezes, as instruções do aplicativo farão com que você coloque seus usuários em uma função de administrador de acesso total. Isso é contra as práticas recomendadas gerais e normalmente representa uma programação desleixada que requer mais acesso do que deveria ou um desejo de remover a segurança das considerações de suporte, nenhuma das quais tem o melhor interesse de seus dados em mente, portanto, sempre considere como a implementação de contas de aplicativo pode afetar sua resiliência geral.

7. Defina uma senha de administrador forte

No MSSQL, a conta sa é usada sempre que a autenticação de modo misto é selecionada. A Microsoft recomenda o uso da autenticação integrada do Windows, mas muitos aplicativos exigem o modo misto para dar suporte a seus usuários de banco de dados e cadeias de conexão. Se você tiver a autenticação de modo misto habilitada, certifique-se de proteger a conta sa com uma senha complexa para evitar que ela seja forçada por força bruta.

Da mesma forma, o usuário root do MySQL deve ter uma senha complexa. Se alguém estiver verificando seu servidor de banco de dados, a primeira coisa que fará é tentar fazer login como a conta de administrador padrão, portanto, a falha em bloqueá-la pode resultar em comprometimento total do sistema.

8. Auditar logins de banco de dados

Parte do registro e monitoramento geral deve incluir auditoria de logon para seu banco de dados SQL. No mínimo, esses registros serão úteis em situações forenses, mas se monitorados regularmente ou mesmo integrados a um sistema de notificação automatizado, logins repetidos com falha podem alertar sobre ataques e outros problemas antes que eles se tornem críticos, permitindo que você desative usuários comprometidos ou altere suas senhas, enquanto o registro de logins bem-sucedidos mantém um registro de quais administradores, Usuários e aplicativos se conectaram, ajudando na solução de problemas e no gerenciamento de mudanças.

9. Proteja seus backups

Adivinha? Seus backups têm os mesmos dados que seus bancos de dados de produção e precisam ser protegidos com tanto cuidado quanto o próprio servidor. Isso pode significar bloquear diretórios de backup, restringir o acesso ao servidor ou armazenamento que hospeda os dados, segurança física da mídia removível, acesso à rede a backups e revisar quem tem acesso para executar e acessar backups. Só não se esqueça de que os backups fazem parte do seu ecossistema de dados quando se trata de segurança ou alguém pode simplesmente passar pela janela aberta para contornar a porta barricada.

10. Proteja-se contra injeção de SQL

Quando um aplicativo da Web aceita a entrada do usuário e a envia para o banco de dados, os dados não higienizados podem "injetar" código malicioso no servidor e executar tarefas não autorizadas, incluindo a obtenção de acesso total ao shell, dependendo da configuração do servidor. Chamada de injeção de SQL, existem várias maneiras de mitigar esses ataques, incluindo a etapa 6 acima, restringindo a capacidade dos usuários de executar tarefas não autorizadas, mas há realmente apenas uma maneira de evitá-los, que é utilizar procedimentos armazenados em vez de consultas SQL diretas para interação com webapp.

Os procedimentos armazenados aceitam apenas parâmetros pré-estabelecidos e só podem executar funções muito específicas, portanto, impedem a injeção de dados em uma consulta SQL bruta. Essa tem sido a prática recomendada há muitos anos, mas muitos aplicativos de produção ainda executam código com vulnerabilidades SQL, uma das vulnerabilidades mais comumente exploradas na Internet.

11. Visibilidade contínua

Obter tudo configurado e configurado com segurança pode evitar muitos problemas no futuro. Mas a única maneira de garantir que seu sistema de banco de dados permaneça seguro é ter visibilidade constante de seu estado de configuração, com testes sendo executados em uma política criada por você. Dessa forma, você será notificado quando algo mudar, digamos, um novo usuário de banco de dados adicionado como administrador de sistema ou com permissões db_owner. Sem algo assim, você está essencialmente adivinhando que nada mudou desde a última verificação, ou mesmo se quiser ter certeza, você precisa coletar manualmente suas informações de configuração, o que é demorado e, em última análise, inútil, pois realizar a mesma verificação no futuro exigiria uma replicação desse esforço. O UpGuard oferece visibilidade contínua dos sistemas de banco de dados SQL, bem como do restante de seus servidores e dispositivos de rede.