Hardening de segurança do PostgreSQL (auditoria de estado, rede, TLS, autenticação, privilégios, audit, criptografia)

Este não é um guia de instalação: ele encontra e fecha as brechas de segurança de um servidor PostgreSQL em execução. Primeiro a Auditoria de estado, somente leitura, lista as brechas por severidade e indica para qual cartão cada achado leva; depois você fecha as áreas uma a uma ou todas em sequência: endereço de escuta, firewall e pg_hba; TLS e sslmode=verify-full no cliente; scram-sha-256 e bloqueio do login de postgres pela rede; desenho de roles e privilégios de PUBLIC; pgaudit e log centralizado; LUKS / pgcrypto; backup criptografado; sistema operacional; acompanhamento de versão. No final a auditoria roda de novo e os achados resolvidos saem da lista.

Topologia: Um único servidor PostgreSQL + servidor de aplicação (verificação do cliente); ambientes com replica/Patroni nas notas

Cenários

• Auditoria de estado: quais são minhas brechas? (somente leitura) — A primeira varredura a executar: pg_hba, endereço de escuta, TLS, senhas md5, superusuários, privilégios de PUBLIC, audit, permissões de arquivos e firewall; não altera nada.
• Hardening completo (todas as áreas em sequência) — Servidor recém-instalado ou que nunca passou por hardening: todas as áreas são aplicadas em uma ordem segura; o PostgreSQL é reiniciado uma ou duas vezes (é necessária uma janela de manutenção).
• Rede e conexões: quem pode se conectar de onde? (listen, firewall, pg_hba) — O PostgreSQL escuta em todas as interfaces, o pg_hba tem 0.0.0.0/0 ou trust, a porta está aberta para todos. Alterar listen_addresses exige reinicialização.
• Criptografar as conexões (TLS, sslmode=verify-full) — ssl = off ou os clientes não verificam o certificado; certificado do servidor, hostssl e verify-full no cliente. Basta um reload, sem downtime.
• Autenticação e senhas (scram-sha-256, login remoto do postgres) — Método md5/password, senhas com hash md5, o usuário postgres consegue entrar pela rede; migração para scram-sha-256 e conta pessoal de DBA. Sem downtime; as senhas são redefinidas.
• Privilégio mínimo: roles, PUBLIC e a conta da aplicação — A conta da aplicação é dona das tabelas ou é superusuário, qualquer um pode escrever no schema public; roles de leitura/escrita/dono e relatório de privilégios. Sem downtime.
• Audit: quem fez o quê? (pgaudit, log centralizado) — O auditor ou a equipe de segurança exige o registro das alterações de DDL e de roles; instalação do pgaudit e envio do log para um servidor central. É necessária uma reinicialização.
• Criptografar os dados em disco (LUKS / pgcrypto) — É exigida proteção contra roubo do disco ou do backup. O PostgreSQL não tem TDE nativo: LUKS no nível do disco (downtime para a migração) ou pgcrypto no nível da coluna.
• Segurança dos backups (backup criptografado, permissões) — Os arquivos de backup não estão criptografados ou ficam em um diretório que todos podem ler; criptografia do repositório do pgBackRest ou pg_dump + GPG, .pgpass e permissões de diretório. Sem downtime.
• Lado do sistema operacional (conta de serviço, permissões, core dump, SELinux) — A conta postgres tem senha utilizável, as permissões do diretório de dados estão frouxas, o SELinux está Permissive/Disabled. A configuração de core dump passa a valer na próxima reinicialização.
• Patches e versão: estou em uma versão suportada? — Verifica a versão, a data de fim do suporte e as atualizações minor pendentes; remete ao guia de patch para aplicá-las. Somente leitura.

Antes de começar

• O PostgreSQL … está em execução e é possível conectar como postgres a partir do próprio servidor (sudo -iu postgres psql) sem senha (local all postgres peer no pg_hba). Se a instalação foi feita com o guia de instalação do PostgreSQL, isso já está pronto.
• Diretório de dados …, diretório de configuração …; psql e pg_dump ficam em …. Estão no PATH do login shell do usuário postgres; ao chamá-los como root, use o caminho completo.
• Duas sessões SSH separadas abertas no servidor: em uma você aplica os passos; a outra (com sudo -iu postgres psql aberto) serve para desfazer se uma regra errada deixar você de fora. Depois de cada passo que restringe o acesso, teste a nova conexão em uma terceira sessão; não feche as sessões antigas até ver o teste funcionar.
• Janela de manutenção: o PostgreSQL será reiniciado nas áreas que você escolheu (listen_addresses, shared_preload_libraries, limite de core dump, migração de disco). A equipe da aplicação foi avisada.
• Você tem em mãos a lista de todas as aplicações que se conectam ao banco e os dados de conexão (IPs dos servidores, usuários, versões de driver). Antes de restringir, o passo de auditoria responde quem se conecta de onde; um cliente fora da lista não conseguirá se conectar depois da restrição.
• Existe um backup atual com restore testado (pgBackRest ou pg_dump). O hardening não toca nos dados, mas as alterações de roles/privilégios e a migração de disco estão sujeitas a erros que não podem ser desfeitos.

Fases do guia

• Auditoria de estado (somente leitura) — Listar os achados dentro do banco · Listar os achados de schema e de função em cada banco · Auditar o lado do sistema operacional
• Antes de começar: ponto de retorno — Fazer uma cópia da configuração atual e das roles · Ativar o diretório de configuração adicional (conf.d)
• Privilégios — 1. Diagnóstico — Mostrar roles, ownership e privilégios de PUBLIC
• Privilégios — 2. Rede de segurança — Fazer um dump dos privilégios atuais
• Privilégios — 3. Aplicação — Criar as roles de grupo e as contas de login · Definir senhas para as novas contas de login · Configurar os privilégios de banco e de schema · Transferir os objetos da conta da aplicação para a role dona · Relatório de privilégios
• Privilégios — 4. Verificação — Verificar que a conta da aplicação não executa DDL e consegue gravar dados
• Privilégios — 5. Depois — Passar a ferramenta de migration para a role dona
• Autenticação — 1. Diagnóstico — Mostrar hashes de senha, métodos e contas
• Autenticação — 2. Rede de segurança — Verificar a compatibilidade dos drivers
• Autenticação — 3. Aplicação — Armazenar as novas senhas com scram-sha-256 · Carregar a configuração e redefinir as senhas das contas md5 · Trocar o método md5/password do pg_hba por scram-sha-256 · Bloquear o login do superusuário postgres pela rede · Criar a conta pessoal de DBA
• Autenticação — 4. Verificação — Verificar os hashes e a rejeição do superusuário pela rede · Login com scram a partir do servidor de aplicação e rejeição do postgres
• Autenticação — 5. Depois — Revisar contas não usadas e expiradas
• TLS — 1. Diagnóstico — Mostrar o estado atual do SSL e os clientes sem criptografia
• TLS — 2. Rede de segurança — Preparar o diretório de certificados
• TLS — 3. Aplicação — Criar uma CA de teste e o certificado do servidor · Criar a chave e a solicitação de assinatura de certificado (CSR) · Colocar no lugar o certificado assinado e a cadeia da CA · Verificar o certificado, a chave e a cadeia · Ativar o TLS no servidor · Carregar as configurações e verificar que o TLS foi ativado …
• TLS — 4. Verificação — Verificar que as conexões sem criptografia são rejeitadas
• TLS — 5. Depois: renovação do certificado — Procedimento de renovação do certificado
• Rede — 1. Diagnóstico: quem se conecta de onde? — Mostrar o endereço de escuta, as regras do pg_hba e os clientes ativos
• Rede — 2. Rede de segurança — Manter a sessão de retorno aberta
• Rede — 3. Aplicação — Restringir o endereço de escuta · Reescrever o pg_hba.conf com acesso mínimo · Verificar e carregar as regras · Abrir a porta no firewall apenas para as redes permitidas · Reiniciar o PostgreSQL para o endereço de escuta
• Rede — 4. Verificação — Testar uma conexão permitida e uma rejeitada a partir do servidor de aplicação
• Rede — 5. Depois — Monitorar as conexões rejeitadas
• Audit — 1. Diagnóstico — Mostrar as configurações de audit e de log
• Audit — 2. Rede de segurança — Verificar o local e o espaço livre do disco de log
• Audit — 3. Aplicação — Instalar o pacote do pgaudit · Adicionar o pgaudit às bibliotecas pré-carregadas e gravar as configurações · Reiniciar para ativar o pgaudit · Criar a extensão pgaudit · Encaminhar o log para o servidor central (rsyslog) · Retenção do arquivo de audit local (logrotate) …
• Audit — 4. Verificação — Fazer uma alteração de DDL e uma de role e vê-las no log
• Audit — 5. Depois — Monitorar tentativas de desligar o audit
• Backup — 1. Diagnóstico — Mostrar o estado de criptografia e as permissões dos backups
• Backup — 2. Rede de segurança — Preparar o local onde a chave de criptografia será guardada
• Backup — 3. Aplicação — Definir o novo repositório criptografado · Criar o repositório criptografado e fazer o primeiro backup full · Importar a chave pública GPG no servidor · Script de backup criptografado · Diretório de backup, permissões e teste manual · Agendar o backup criptografado (cron) …