Endurecimento de bancos de dados: PostgreSQL e MySQL em produção

Um banco de dados de produção é onde vivem as joias da coroa, o que faz do endurecimento de bancos de dados uma das atividades de maior alavancagem em que uma equipe defensiva pode investir. PostgreSQL e MySQL são robustos e, em estados padrão ou configurados às pressas, expõem mais do que deveriam. Este guia adota a visão do blue team: explica a superfície de exposição de um banco de produção, como ataques contra armazenamentos de dados costumam se desenrolar em alto nível e — o cerne — os controles, a telemetria e as detecções concretas que mantêm os dados confidenciais, íntegros e disponíveis. O enquadramento é entender para defender, não para explorar.

Por que o endurecimento de bancos importa#

Aplicações recebem patches, firewalls recebem regras e endpoints recebem EDR, mas o banco de dados costuma ficar atrás de tudo isso com uma postura de confiança por padrão. É exatamente por isso que ele é alvo: uma única credencial fraca, uma conta de aplicação com excesso de privilégios ou um backup sem criptografia pode entregar todo o conjunto de dados de uma vez. Endurecer o banco reduz o valor de qualquer outro ponto de apoio, porque mesmo um atacante que alcança o segmento de rede ainda enfrenta autenticação, privilégio mínimo, criptografia e monitoramento. Pense nisso como defesa em profundidade aplicada ao único ativo cujo comprometimento costuma ser o verdadeiro objetivo da intrusão.

A superfície de exposição de um banco de produção#

A superfície de exposição tem várias faces. Há a face de rede — a porta em que o motor escuta e quem pode alcançá-la. Há a face de autenticação — como as identidades se comprovam e quão fortes são essas provas. Há a face de autorização — o que cada papel pode ler, escrever ou administrar. Há a face de dados em repouso — arquivos, tablespaces e backups no disco. E há a face de observabilidade — se alguém notaria um acesso anômalo. Um banco endurecido estreita cada uma delas; uma instalação padrão deixa várias escancaradas, quase sempre escutando em todas as interfaces e confiando implicitamente em conexões locais.

Como ataques a bancos se desenrolam em alto nível#

Conceitualmente, uma intrusão direcionada aos dados costuma seguir um arco reconhecível. O adversário primeiro alcança uma posição de onde o banco é endereçável — um servidor de aplicação, um jump host ou uma porta exposta. Depois tenta autenticar-se, seja com credenciais reutilizadas encontradas em outro lugar, uma senha fraca ou padrão, ou uma conta de aplicação com mais direitos do que precisa. Já conectado, enumera esquemas e privilégios buscando o caminho mais curto para tabelas sensíveis ou para capacidade administrativa. Por fim, tenta extração em massa ou persistência. Cada etapa mapeia para um controle defensivo, por isso o endurecimento é melhor planejado como um conjunto de barreiras ao longo desse arco do que como um único muro.

Autenticação e controle de acesso#

Comece eliminando a confiança por padrão. No PostgreSQL, revise o pg_hba.conf para que nenhuma regra use o método trust exceto em sockets locais rigorosamente controlados, e prefira scram-sha-256 para autenticação por senha. No MySQL, remova contas anônimas e qualquer conta com senha vazia ou padrão, e prefira plugins de autenticação fortes. Dê a cada pessoa e a cada aplicação seu próprio papel nomeado — nunca um superusuário compartilhado. Onde a plataforma suportar, integre-se a um provedor de identidade central ou autenticação baseada em certificado de vida curta para que as credenciais sejam rotacionáveis e revogáveis. Aplique políticas de senha fortes e, para acesso administrativo, exija autenticação multifator no bastião diante do banco.

Exposição de rede e criptografia em trânsito#

Vincule o motor às interfaces específicas que ele deve servir, não a todos os endereços, e coloque-o em um segmento de rede privado alcançável apenas pela camada de aplicação e pelos bastiões administrativos. Use firewalls de host e grupos de segurança de rede como segunda barreira para que nem uma má configuração exponha a porta à rede mais ampla. Exija TLS em cada conexão e desative o fallback sem criptografia: no PostgreSQL imponha regras hostssl e defina ssl = on; no MySQL exija transporte seguro. Valide os certificados do lado do cliente para que um intermediário não possa rebaixar ou interceptar a sessão em silêncio. Trate qualquer conexão de banco em texto puro em produção como um incidente a corrigir, não uma comodidade a tolerar.

Privilégio mínimo e permissões de esquema#

Contas com excesso de privilégios são o achado mais comum em revisões de banco. Contas de aplicação frequentemente rodam como proprietárias ou superusuárias quando só precisam de select, insert, update e delete em um punhado de tabelas. Conceda o mínimo, revogue o resto e use herança de papéis para manter gerenciável. No PostgreSQL, seja deliberado com o esquema public e os privilégios padrão, e considere segurança em nível de linha para dados multi-inquilino. No MySQL, restrinja grants a bancos e tabelas específicos em vez de grants com curinga. Separe a conta que executa migrações da que serve tráfego, para que um comprometimento cotidiano da aplicação não confira automaticamente poder de alterar o esquema.

Criptografia em repouso e gestão de segredos#

Proteger os dados no disco fecha o caminho em que um atacante ou um backup perdido entrega o conjunto de dados diretamente. Habilite criptografia em nível de armazenamento ou de sistema de arquivos para o diretório de dados e, sobretudo, criptografe os backups com chaves geridas separadamente do host do banco. Nunca embuta senhas de banco no código-fonte da aplicação nem em arquivos de configuração versionados; recupere-as em tempo de execução de um gerenciador de segredos com registro de acesso. Rotacione credenciais de forma programada e imediatamente após qualquer exposição suspeita. A regra mestra é que possuir um disco, um snapshot ou um arquivo de backup não deve bastar para ler os dados sem também possuir chaves mantidas sob controle separado.

Detecção: registro e monitoramento#

Endurecer sem detectar deixa você cego para as tentativas que passam. No PostgreSQL, habilite o registro de conexões e desconexões, registre autenticações falhas e considere a extensão pgaudit para auditoria em nível de instrução de objetos sensíveis. No MySQL, habilite o plugin de audit log e os logs geral ou de consultas lentas conforme apropriado, e capture eventos de login falho. Envie esses logs a um SIEM central e alerte para os sinais significativos: um pico de falhas de autenticação, um login de host inesperado ou em hora incomum, concessões de privilégio, volumes de resultado grandes ou incomuns sugestivos de extração em massa, e qualquer mudança na configuração de auditoria. Monitore a saúde da própria pipeline de logs.

Backup, recuperação e integridade#

Disponibilidade e integridade fazem parte da segurança, não são algo à parte. Mantenha backups testados e criptografados com retenção definida, e guarde ao menos uma cópia em um local que um atacante que comprometa o primário não consiga alcançar nem apagar. Ensaie a recuperação regularmente; um backup nunca restaurado é uma esperança, não um controle. Proteja os backups com a mesma disciplina de privilégio mínimo e monitoramento do banco vivo, porque um repositório de backups desprotegido é simplesmente uma segunda cópia, mais silenciosa, de tudo. Para resiliência a ransomware, armazenamento de backup imutável ou de escrita única garante que um invasor com acesso ao banco não possa também destruir os meios de recuperação.

Armadilhas comuns#

Erros recorrentes incluem deixar o motor escutando em todas as interfaces, manter contas administrativas padrão ou compartilhadas, conceder aos usuários da aplicação muito mais do que precisam, e armazenar strings de conexão com senhas embutidas em repositórios. As equipes frequentemente habilitam criptografia em trânsito mas nunca a impõem, de modo que os clientes caem em silêncio para texto puro. Outros criptografam o volume vivo mas deixam os backups em claro. Uma lacuna de detecção frequente é um registro que existe mas nunca é encaminhado nem revisado, servindo só na autópsia pós-incidente. Por fim, cuidado com atalhos por desempenho que desativam autenticação ou auditoria para um job em lote e nunca são reativados.

Checklist de endurecimento#

Um ponto de partida defensivo: (1) remover confiança por padrão, contas anônimas e padrão; (2) exigir credenciais fortes, rotacionadas e por identidade com MFA nos caminhos administrativos; (3) vincular a interfaces específicas dentro de um segmento privado atrás de firewalls de host e de rede; (4) exigir e validar TLS em cada conexão; (5) aplicar privilégio mínimo a cada papel e separar contas de migração e de execução; (6) criptografar dados em repouso e criptografar backups com chaves geridas separadamente; (7) puxar segredos de um gerenciador, nunca do controle de versão; (8) habilitar auditoria de conexões, de logins falhos e de instruções e encaminhá-la a um SIEM; (9) alertar para anomalias de autenticação, mudanças de privilégio e extração em massa; (10) manter backups testados, imutáveis e fora do primário e ensaiar a recuperação.

FAQ: criptografia em trânsito basta em uma rede privada?#

Não. Uma rede privada reduz a exposição mas não elimina movimento lateral, má configuração nem um insider no mesmo segmento. A criptografia em trânsito protege a sessão de interceptação e rebaixamento independentemente de onde esteja a fronteira de rede, e deve ser combinada com privilégio mínimo, criptografia em repouso e monitoramento. Defesa em profundidade assume que qualquer camada isolada, inclusive o perímetro de rede, pode falhar.

FAQ: a aplicação deve usar um superusuário por conveniência?#

Nunca em produção. Uma conta de aplicação deve deter apenas os direitos de manipulação de dados de que realmente precisa nos objetos específicos que toca. Rodar como superusuário significa que qualquer comprometimento da camada de aplicação — uma falha de injeção, um token roubado — vira imediatamente comprometimento total do banco. Separe contas para execução, migrações e administração para que o raio de ação de uma única credencial fique contido.

Conclusão#

Endurecer PostgreSQL e MySQL em produção é colocar barreiras ao longo de todo o caminho que um adversário percorreria em direção aos dados: autenticação que resiste à reutilização, isolamento de rede que limita o alcance, privilégio mínimo que contém qualquer ponto de apoio, criptografia que neutraliza discos e backups roubados, e detecção que transforma o acesso anômalo silencioso em um alerta ruidoso. Nada disso é exótico e, juntas, essas medidas transformam o ativo mais valioso do parque de um alvo mole em um alvo monitorado e defensável. Trate o checklist como vivo, revise-o após cada mudança e cada incidente, e verifique a configuração viva em vez de confiar na pretendida.