APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma ligação PostgreSQL atravessa rede, TLS, autenticação e autorização. O pg_hba.conf escolhe a primeira regra compatível com o tipo de ligação, origem, base e role. Uma password inválida não provoca tentativa da regra seguinte. Em Unix, alterações precisam de recarga; uma sessão antiga não demonstra que novas conexões passarão. A migração para SCRAM exige clientes compatíveis e novas passwords gravadas no formato adequado. Alterar password_encryption não converte os hashes existentes. Na libpq, verify-full verifica a cadeia de confiança e o nome do servidor; exigir apenas cifragem não cumpre necessariamente esse requisito. Mantém a confiança e o nome corretos em vez de contornar erros de certificado.
Aplicação guiada
Num batch fictício que muda de sub-rede, recolhe o erro completo e confirma a origem observada pelo servidor antes de alterar regras. Depois de autenticar, verifica CONNECT, USAGE no schema e privilégios nos objetos necessários. Grants atuais não resolvem acesso a tabelas futuras: default privileges dependem da role que cria os objetos. RLS deve ser ensaiada com a identidade de runtime, porque o owner normalmente ignora políticas; superusers e BYPASSRLS têm exceções próprias. A passagem a RUN deve identificar quem gere roles, rotação e revogação, como validar nova conexão e como reverter uma mudança sem ampliar o perímetro de acesso.
Uma sessão aberta antes da mudança continua ativa, mas a nova ligação do batch falha: testa o caminho novo, não a sessão antiga.
Armadilhas comuns
HBA como lista de fallback; TLS como SELECT; defaults como grants retroativos; teste RLS como owner.
Tópicos relacionados: Transações, bloqueios e retoma · Planos, índices e memória · Vacuum, configuração e capacidade
Valida rede, identidade e privilégios com uma conexão nova e representativa.
Referência: Authentication rule order · PostgreSQL 18 reference semantics;18.6 current stable at review