O Blueprint de Endurecimento de Segurança
A segurança do PostgreSQL não é um controle que você ativa, é uma pilha de camadas que cada uma assume que a camada abaixo delas pode ser contornada.
//
Busque em todas as páginas da documentação
A segurança do PostgreSQL não é um controle que você ativa, é uma pilha de camadas que cada uma assume que a camada abaixo delas pode ser contornada.
Esta página constrói o modelo mental que une essas camadas: identidade, autorização, transporte, armazenamento e auditoria, e explica por que o endurecimento de produção significa raciocinar sobre todas as cinco ao mesmo tempo, em vez de escolher uma favorita.
trust em pg_hba.conf ou uma senha de superusuário compartilhada, pode anular todos os outros controles no cluster.Um modelo de ameaças é simplesmente uma lista honesta de quem pode acessar seu banco de dados e o que eles poderiam fazer se o fizessem.
Para o PostgreSQL, essa lista geralmente tem quatro entradas: um atacante na rede, uma credencial vazada ou adivinhada, um insider malicioso ou descuidado, e um disco ou snapshot de backup roubado.
Cada entrada nessa lista mapeia para um controle diferente, que é a ideia central por trás da defesa em profundidade.
Autenticação responde "quem é você", e o mecanismo padrão do PostgreSQL é SCRAM-SHA-256, um protocolo de desafio-resposta que nunca envia a senha em si pela rede.
Autorização responde "o que você tem permissão para acessar", e é aplicada através de GRANT/REVOKE em objetos mais políticas opcionais de segurança em nível de linha (row-level security) para isolamento de tenant mais granular.
Criptografia de transporte (TLS) responde a uma pergunta completamente diferente: mesmo que a identidade e as permissões estejam corretas, alguém na rede pode ler ou adulterar os bytes em trânsito.
Criptografia em repouso protege os dados quando os controles de tempo de execução são irrelevantes, como quando um snapshot de disco ou um drive desativado cai nas mãos erradas.
A analogia útil é um prédio: autenticação é o crachá na porta, autorização é quais andares esse crachá desbloqueia, TLS é um caminhão de entrega trancado entre prédios, e criptografia em repouso é o cofre parafusado no chão dentro.
Nenhum desses substitui o outro, e um prédio com um ótimo cofre, mas uma porta da frente destrancada, não é seguro.
O PostgreSQL vem sem nenhuma dessas camadas configuradas agressivamente de fábrica, porque a instalação padrão é otimizada para o laptop de um desenvolvedor, não para um cluster de produção voltado para o público.
Essa lacuna entre "instala facilmente" e "seguro para expor" é exatamente o que um blueprint de endurecimento existe para fechar.
As camadas interagem em uma ordem específica toda vez que um cliente se conecta, e entender essa ordem explica a maioria das decisões de endurecimento.
Uma conexão primeiro cruza a camada de rede, onde regras de firewall, grupos de segurança e entradas pg_hba.conf decidem se a tentativa é sequer considerada.
Se a entrada exigir hostssl, a negociação TLS ocorre em seguida, estabelecendo um canal criptografado antes que qualquer credencial seja trocada.
Só então a autenticação é executada, onde SCRAM valida a prova do cliente contra o verificador salgado armazenado em pg_authid, nunca a senha em texto plano.
Uma vez que a sessão é estabelecida, cada instrução passa pela camada de autorização, onde o PostgreSQL verifica os privilégios de objeto e, se habilitado, avalia as políticas de segurança em nível de linha contra current_user.
O logging de auditoria fica ao lado de todo esse fluxo como um observador passivo, registrando conexões, desconexões e (dependendo da configuração) o texto da instrução para revisão forense posterior.
Essa ordenação importa porque uma fraqueza anterior na cadeia compromete tudo a jusante: uma entrada trust em pg_hba.conf ignora completamente a autenticação, tornando as concessões de nível de role irrelevantes para qualquer pessoa nesse caminho de rede.
-- Um mecanismo tornado concreto: a ordem das linhas em pg_hba.conf decide
-- qual método de autenticação realmente é executado para uma determinada conexão.
-- A primeira linha correspondente vence, as linhas posteriores nunca são avaliadas.
hostssl orders app_api 10.20.0.0/16 scram-sha-256
hostnossl orders app_api 0.0.0.0/0 rejectO trecho acima mostra por que a ordem das camadas é uma decisão de segurança em si: a primeira linha exige TLS e SCRAM para a sub-rede confiável, e a segunda linha rejeita explicitamente qualquer tentativa não-TLS de qualquer outro lugar, fechando a lacuna que uma regra ausente deixaria aberta.
Um erro comum de raciocínio é tratar essas camadas como redundantes em vez de complementares, assumindo que, como os roles são bloqueados, o TLS é opcional.
Na realidade, cada camada defende contra uma capacidade de ataque diferente, e pular uma apenas estreita o conjunto de ataques contra os quais você está protegido, em vez de tornar as outras desnecessárias.
Em escala, o blueprint se estende de um único banco de dados para como a identidade é centralizada e como os segredos são rotacionados em uma frota.
Empresas cada vez mais delegam a autenticação para LDAP, Kerberos ou tokens de IAM na nuvem em vez de senhas SCRAM estáticas, de modo que um único provedor de identidade governe o acesso em todos os serviços, não apenas no Postgres.
A segurança em nível de linha se torna fundamental em arquiteturas multi-tenant, onde um único esquema compartilhado atende a muitos clientes e o próprio banco de dados, não apenas o aplicativo, deve garantir o isolamento do tenant.
Frameworks de conformidade como SOC2, HIPAA e PCI DSS não introduzem novos controles técnicos, mas sim formalizam quais dessas camadas devem existir e como suas evidências (logs, revisões de concessão, atestados de criptografia) são retidas e auditadas.
A observabilidade da camada de segurança importa tanto quanto os próprios controles, porque um sistema perfeitamente configurado, mas não monitorado, não pode dizer quando um controle foi contornado ou uma credencial foi mal utilizada.
A governança de extensões é uma superfície de endurecimento frequentemente negligenciada: CREATE EXTENSION pode conceder capacidade significativa, então clusters de produção geralmente a restringem a uma lista de permissões e a uma role de migração privilegiada, em vez de deixá-la aberta para roles de aplicativo.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Senhas SCRAM estáticas | Simples, sem dependência externa | Rotação manual, proliferação de credenciais | Pequenas equipes, contas de serviço |
| Autenticação por certificado (mTLS) | Identidade forte por serviço | Ferramentas de rotação e revogação necessárias | Topologias de malha de serviço fixas |
| Autenticação por token de IAM na nuvem | Curta duração, centralmente revogável | Vinculado a um provedor de nuvem | Postgres gerenciado nativo AWS/GCP |
| Segurança em nível de linha | Aplica isolamento de tenant no próprio DB | Complexidade de planejamento de consulta e política | SaaS multi-tenant com esquema compartilhado |
| Logging de instruções pgaudit | Trilha de evidências completa em nível de instrução | Volume de log e risco de exposição de PII | Dados regulamentados, auditorias de conformidade |
Substituir qualquer entrada trust ou não autenticada em pg_hba.conf por hostssl mais scram-sha-256 fecha a exposição mais comum no mundo real.
Não, TLS apenas protege o caminho da rede; autenticação, autorização e logging de auditoria ainda precisam ser configurados independentemente.
A instalação padrão visa a ergonomia de desenvolvimento local, não a exposição à internet, então o endurecimento é tratado como uma responsabilidade no momento da implantação.
Autenticação (SCRAM, certificados, LDAP) prova a identidade no momento da conexão; autorização (GRANT, REVOKE, RLS) decide o que essa identidade pode fazer em cada instrução subsequente.
Apenas quando os tenants compartilham um único esquema ou role; bancos de dados ou esquemas totalmente isolados por tenant podem confiar na separação em nível de concessão.
Não, os runtimes de aplicativos devem usar uma role de privilégio mínimo, reservando superusuário para administração de "break-glass" e gerenciamento de extensões.
Logging amplo de instruções (via pgaudit ou log_statement = all) adiciona I/O e pode vazar literais sensíveis para os logs, então a maioria das equipes o limita a DDL e tabelas sensíveis específicas.
Ela defende um cenário que nenhum dos controles de tempo de execução cobre: um disco roubado, snapshot de volume ou mídia de backup desativada.
Eles removem o trabalho da camada de infraestrutura (patching, substrato de criptografia de disco), mas deixam roles, concessões, RLS e exposição em nível de consulta inteiramente para o cliente.
As equipes frequentemente tratam a certificação como prova de que o esquema está endurecido hoje, quando na verdade ela atesta processos e controles observados durante uma janela de auditoria.
O PostgreSQL usa a primeira linha correspondente para uma tentativa de conexão, então uma regra flexível colocada antes de uma regra estrita a substitui silenciosamente.
Restrinja CREATE EXTENSION a uma role de migração privilegiada e a uma lista de permissões explícita, pois as extensões podem introduzir nova superfície de ataque ou capacidade.
Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (major estável 18, linha de manutenção 17), PgBouncer 1.x e Patroni 3.x.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026