O Center for Internet Security (CIS) publicou, na atualização mensal de benchmarks de setembro de 2026, a versão v2.0.0 do benchmark do PostgreSQL 17. A revisão traz correções de versão, mapeamentos atualizados para os CIS Controls e uma mudança que interessa a quem opera bancos em produção: uma nova recomendação passa a exigir senha em toda conta capaz de login. Equipes com instâncias PostgreSQL expostas a aplicações, containers e redes compartilhadas devem tratar o lançamento como gatilho para reauditar autenticação, privilégios e configuração de acesso ainda neste ciclo de mudanças.
O que muda no benchmark
O benchmark do PostgreSQL é o guia de configuração segura mantido por consenso da comunidade CIS, com recomendações prescritivas que servem de base para auditorias, compliance e imagens corporativas. A versão nova foi anunciada no blog oficial do CIS ao lado de dezenas de outros documentos revisados no mês, de Windows Server a navegadores. O changelog resume três frentes: atualizações para refletir mudanças de versão e correções de tickets, a nova recomendação de senha e o alinhamento dos mapeamentos de controles.
A recomendação inédita é a parte que muda o dia a dia da operação. Até agora, contas de login sem senha sobreviviam em ambientes legados, imagens antigas de container e migrações apressadas, porque nenhuma regra do documento as proibia de forma direta. O texto novo fecha essa brecha ao exigir credencial em qualquer conta com capacidade de autenticação, acompanhando o padrão observado em invasões reais contra bancos mal configurados: primeiro a conexão sem senha, depois o inventário de tabelas e esquemas, depois a exfiltração de dados e, em cadeias mais graves, o movimento lateral para outros sistemas que confiam na mesma rede.
O movimento do CIS é parte de uma ampliação consistente da cobertura de benchmarks da organização, que já alcança de servidores MCP a suítes corporativas. Para times que padronizam configuração por benchmark, a mensagem prática é acompanhar as revisões mensais como parte do ciclo de hardening, e não como evento anual.
Por que exigir senha importa
A exigência pode parecer óbvia, mas a documentação oficial do PostgreSQL explica por que ela precisa ser explícita. As senhas de usuários do banco ficam no catálogo de sistema pg_authid, gerenciadas com CREATE ROLE, ALTER ROLE ou o comando \password do psql. Quando uma conta nunca recebeu senha, o valor armazenado é nulo e a autenticação por senha sempre falha para ela — o que é seguro em tese, mas não é o cenário real de risco.
O risco real aparece quando a falha de autenticação por senha é compensada por linhas perigosas no pg_hba.conf, o arquivo que define quem conecta e com qual método. Uma linha com método trust assume que qualquer um que alcance o servidor está autorizado a acessar o banco com qualquer nome de usuário, inclusive superusuário. A documentação é direta: trust raramente é razoável para conexões TCP/IP que não venham do localhost. Contas sem senha combinadas com trust em redes de containers são a receita clássica de exposição silenciosa, sem log de invasão e sem alerta.
O hardening de banco não vive sozinho. A mesma disciplina que fecha autenticação no PostgreSQL precisa cobrir a telemetria do ambiente: sem log mínimo e centralizado, a equipe só descobre o acesso indevido quando o dado já vazou. Um padrão de visibilidade como o discutido no guia sobre logs que detectam, baseado no ENISA, complementa o benchmark e transforma configuração correta em capacidade de resposta.
Autenticação com SCRAM-SHA-256
Se a nova regra obriga senha em toda conta, a próxima pergunta é qual método de autenticação usar. A documentação oficial do PostgreSQL classifica o método scram-sha-256 como o mais seguro entre os métodos de autenticação por senha disponíveis. O esquema é do tipo challenge-response, descrito no RFC 7677, previne captura de senha em conexões não confiáveis e permite armazenar a credencial no servidor em forma de hash criptográfico.
O método md5 continua aceito por compatibilidade, mas o próprio manual do banco é categórico: o algoritmo MD5 não é mais considerado seguro contra atacantes determinados, e o método não protege caso o atacante roube o hash armazenado no servidor. Armazenamento de senha em texto puro, que existia em versões antigas, não é mais possível. A diferença entre md5 e scram-sha-256 deixou de ser preferência estética: é o padrão mínimo aceitável para qualquer instância que receba conexões de rede.
A migração tem procedimento documentado e exige ordem correta: primeiro confirmar que todas as bibliotecas cliente suportam SCRAM; depois definir password_encryption = ‘scram-sha-256’ no postgresql.conf; em seguida fazer todos os usuários definirem novas senhas, para que sejam armazenadas com o novo hash; e só então trocar as especificações de método no pg_hba.conf para scram-sha-256. Trocar a ordem bloqueia aplicações legadas e transforma uma melhoria de segurança em incidente de indisponibilidade.
Checklist de hardening PostgreSQL
| Prioridade | Ação | Verificação |
|---|---|---|
| P1 | Garantir senha definida em toda role com LOGIN, inclusive contas de serviço e replicas | Consultar pg_authid e bloquear roles sem senha: ALTER ROLE… NOLOGIN |
| P1 | Remover todo método trust do pg_hba.conf fora do socket local | grep trust pg_hba.conf em todos os nós, inclusive réplicas e standby |
| P1 | Migrar autenticação para scram-sha-256 | password_encryption no postgresql.conf e rehash de todas as senhas |
| P2 | Auditar superusuários e roles com privilégio excessivo | Revisar memberships e DEFAULT PRIVILEGES por esquema |
| P2 | Centralizar log de autenticação e conexões | log_connections, log_disconnections e destino de log monitorado |
| P2 | Aplicar o benchmark CIS completo com ferramenta de scan | Comparar saída do scan com o changelog da versão nova |
Como adotar sem quebrar produção
A adoção segura começa pelo inventário. Liste todas as roles com atributo LOGIN, separe contas humanas de contas de aplicação e marque as que não têm senha ou não autenticam por método verificável. Contas órfãs de projetos desativados devem receber NOLOGIN antes de qualquer outra mudança — é a ação de menor risco e maior retorno.
Em seguida, trate o pg_hba.conf como código: versione o arquivo, revise linha por linha e elimine trust de todas as entradas TCP/IP. Redes internas de orquestração não são exceção; são justamente o cenário em que um container comprometido alcança o banco em segundos. Onde a confiança precisa ser automática, prefira autenticação por certificado ou senha gerenciada a exceções de confiança implícita.
Por fim, agende a migração para SCRAM por ondas: bibliotecas cliente modernas suportam o método desde versões antigas, e o PostgreSQL permite a coexistência temporária de métodos por linha do pg_hba.conf. Teste uma aplicação de menor criticidade, meça falhas de autenticação nos logs e só então generalize. Times que já aplicam benchmark CIS em outras camadas, como o benchmark CIS para servidores MCP, podem incorporar o PostgreSQL ao mesmo processo de revisão mensal.
O benchmark v2.0.0 não cria vulnerabilidade nova nem exige reimplantação. Ele formaliza uma expectativa que ambientes maduros já cumpriam: nenhuma conta capaz de login sem credencial, nenhum método de autenticação legado em rede e nenhuma exceção de confiança sem dono documentado. Quem aplica as três P1 da tabela acima já cobre o essencial do que a versão nova exige.