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.

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.

Resumo

• Endurecimento de segurança é a prática de empilhar controles independentes (identidade, autorização, transporte, armazenamento, auditoria) de modo que nenhuma falha única exponha dados.
• Por que Importa: Uma única camada mal configurada, como uma linha trust em pg_hba.conf ou uma senha de superusuário compartilhada, pode anular todos os outros controles no cluster.
• Conceitos Chave: autenticação, autorização, criptografia de transporte, criptografia em repouso, defesa em profundidade, trilha de auditoria.
• Quando Usar: Qualquer banco de dados acessível pela internet, qualquer sistema que contenha dados regulamentados (PCI, HIPAA, SOC2), e qualquer esquema multi-tenant compartilhado entre clientes.
• Limitações / Trade-offs: Cada camada adicionada custa complexidade operacional, latência ou atrito para o desenvolvedor, então o endurecimento é um orçamento a ser gasto deliberadamente, não uma lista de verificação a ser preenchida cegamente.
• Tópicos Relacionados: protocolos de autenticação, segurança em nível de linha (row-level security), logging de conformidade, gerenciamento de chaves de criptografia.

Fundamentos

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.

Mecânicas e Interações

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     reject

O 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.

Considerações Avançadas e Aplicações

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.

Equívocos Comuns

• "TLS significa que o banco de dados está seguro." - TLS protege apenas os dados em trânsito; não diz nada sobre quem pode se autenticar ou o que eles podem acessar uma vez conectados.
• "Segurança em nível de linha substitui a autorização do aplicativo." - RLS é uma segunda linha de defesa para uma role de banco de dados compartilhada, não um substituto para as próprias verificações de regras de negócios do aplicativo.
• "Superusuário é apenas uma conta de conveniência." - superusuário ignora RLS e a maioria das verificações de privilégio, então usá-lo como credencial de aplicativo colapsa todas as outras camadas neste blueprint.
• "Postgres gerenciado cuida da segurança para mim." - o provedor protege o hipervisor e o substrato de armazenamento, mas roles, concessões, políticas RLS e exposição em nível de consulta permanecem inteiramente responsabilidade do cliente.
• "Certificação de conformidade significa que o esquema está endurecido." - um relatório SOC2 atesta processos e controles em um ponto no tempo, não que cada tabela tenha as concessões corretas hoje.
• "Criptografia em repouso impede ameaças internas." - criptografia em repouso protege contra mídia roubada, não contra um insider autenticado com acesso de consulta legítimo.

FAQs

Relacionados

• Noções Básicas de Segurança - o ponto de partida em nível de receita para roles, concessões e regras de pg_hba.
• Autenticação SCRAM - uma análise mais aprofundada da camada de autenticação descrita aqui.
• Configuração SSL/TLS - a camada de criptografia de transporte na prática.
• pgaudit & Logging de Conformidade - a camada de auditoria para cargas de trabalho regulamentadas.
• Criptografia em Repouso - o controle da camada de armazenamento para cenários de mídia roubada.
• Visão Geral do PostgreSQL Gerenciado - como este blueprint muda em uma plataforma gerenciada.

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.