Configuração SSL/TLS

O TLS criptografa o tráfego do PostgreSQL entre clientes e servidores. Em redes em nuvem e híbridas, trate conexões não criptografadas como uma violação de política. O PostgreSQL 18.4 suporta TLS moderno com hostssl em pg_hba.conf e sslmode=verify-full nos clientes para confiança mútua verificada por nome de host.

Receita

# postgresql.conf
ssl = on
ssl_cert_file = '/etc/postgresql/server.crt'
ssl_key_file  = '/etc/postgresql/server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf - rejeita não-TLS de sub-redes de aplicativos
hostssl  all  all  10.20.0.0/16  scram-sha-256
hostnossl all all  0.0.0.0/0     reject

# String de conexão do cliente
psql "host=db.internal port=5432 dbname=orders user=app_api sslmode=verify-full sslrootcert=/etc/ssl/certs/ca.pem"

Quando usar isso:

Qualquer cliente que cruza uma rede não confiável (VPC peering, VPN, endpoint público)
Requisitos de conformidade para criptografia em trânsito
Postgres gerenciado onde você ainda deve definir sslmode nos aplicativos e rotacionar pacotes de CA

Exemplo de Trabalho

Primário auto-hospedado com certificado de servidor Let's Encrypt e clientes de aplicativo verificando o nome do host.

# Gera ou obtém certificado de servidor (autoassinado simplificado para laboratório)
openssl req -new -x509 -days 365 -nodes -text \
  -out server.crt -keyout server.key -subj "/CN=db.prod.internal"
chmod 600 server.key
chown postgres:postgres server.crt server.key

# postgresql.conf
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf
hostssl  orders  app_api  10.20.0.0/16  scram-sha-256

# DSN do aplicativo (exemplo Node pg)
export DATABASE_URL="postgresql://app_api@db.prod.internal:5432/orders?sslmode=verify-full&sslrootcert=/etc/app/ca.crt"

O que isso demonstra:

O servidor apresenta o certificado; os clientes exigem TLS via hostssl
verify-full verifica a CA e a correspondência do nome do host
Conexões não-TLS do CIDR do aplicativo são rejeitadas explicitamente

Mergulho Profundo

Matriz de Cliente sslmode

sslmode	Criptografa	Verifica CA	Verifica nome do host
`disable`	Não	Não	Não
`require`	Sim	Não	Não
`verify-ca`	Sim	Sim	Não
`verify-full`	Sim	Sim	Sim

Use verify-full para conexões de aplicativos de produção, a menos que um proxy gerenciado documente um modelo de confiança diferente.

Rotação de Certificado

# Recarregamento sem interrupção após a substituição de server.crt/server.key
pg_ctl reload -D /var/lib/postgresql/data
# Ou SQL:
SELECT pg_reload_conf();

Rotacione os certificados do servidor antes do vencimento (aviso de 30 dias). Atualize o sslrootcert do cliente quando a CA mudar.

Notas sobre Nuvem Gerenciada

Provedor	TLS do Servidor	Ação do Cliente
RDS / Aurora	Imposto em endpoints públicos	Baixar pacote de CA do RDS, `sslmode=verify-full`
Cloud SQL	Gerenciado pelo servidor	Use o conector ou parâmetros SSL do console
Neon / Supabase	TLS por padrão	Use a string de conexão fornecida com um mínimo de `sslmode=require`

Armadilhas

sslmode=require sem verificação de CA - criptografado, mas vulnerável a MITM com certificado malicioso. Correção: verify-full + CA fixada.
host + hostssl ambos permitindo o mesmo CIDR - os clientes podem voltar para texto simples se mal configurados. Correção: hostnossl ... reject para intervalos sensíveis.
Certificado de servidor expirado após renovação automática em disco - o Postgres não recarrega certificados dinamicamente em todas as plataformas. Correção: pg_reload_conf() no hook de renovação de certificado.
CN/SAN incorreto no certificado - verify-full falha com incompatibilidade de nome de host. Correção: o SAN do certificado inclui db.prod.internal exatamente como os clientes se conectam.
Terminação TLS apenas no PgBouncer - o salto entre o pooler e o Postgres pode ser em texto simples dentro da VPC. Correção: TLS para o Postgres também quando o modelo de ameaça inclui espionagem leste-oeste.
Java trust store sem a CA do RDS - os aplicativos falham com erros PKIX. Correção: importar o pacote de CA do provedor no truststore do JVM ou na imagem do contêiner.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
Private Service Connect / Apenas VPC	Nenhum endpoint público existe	Clientes fora da VPC precisam de acesso
Túnel SSH / VPN	Aplicativos legados não podem definir sslmode	Você pode corrigir o DSN do cliente corretamente
Certificados de cliente mTLS (`cert` auth)	Serviço a serviço com poucos clientes	Grande frota de instâncias de aplicativo dinâmicas
Apenas lista de permissão de IP	Camada extra com TLS	Como único controle (IPs podem ser falsificados internamente)

FAQs

TLS é suficiente sem SCRAM?

Não. TLS protege na rede; SCRAM protege o armazenamento do verificador de senha e a resposta ao desafio no login.

O PgBouncer precisa de TLS?

Sim, para cliente-para-pooler quando os clientes estão fora da VLAN do banco de dados. TLS de pooler-para-Postgres depende do seu modelo de ameaça leste-oeste.

Como testar TLS rapidamente?

psql "sslmode=require" e depois \conninfo. OpenSSL: openssl s_client -starttls postgres -connect host:5432.

Posso usar apenas TLS 1.3?

O PostgreSQL suporta TLS 1.2+. Defina ssl_min_protocol_version e verifique a compatibilidade da biblioteca cliente.

E quanto ao TLS de replicação?

Use hostssl para entradas de replicação e primary_conninfo com sslmode=verify-full em standbys.

Impacto no desempenho?

Pequeno em CPUs modernas com reutilização de sessão. O gargalo ainda são as consultas e o disco, não o handshake TLS em estado estável.

Certificados autoassinados em desenvolvimento?

sslmode=require é aceitável localmente. A produção deve usar uma CA adequada ou um pacote de provedor gerenciado.

Onde armazenar sslrootcert no K8s?

Monte a CA como um volume Secret; referencie o caminho em DATABASE_URL. Rotacione via implantação contínua.

A replicação lógica usa TLS?

Sim, quando a string de conexão define sslmode. Trate os links de replicação como tráfego de aplicativo.

Como isso interage com SCRAM?

Camadas ortogonais: TLS para transporte, SCRAM para autenticação de senha após o canal ser criptografado.

Relacionado

Noções Básicas de Segurança - modelo de ameaça
Autenticação SCRAM - autenticação de senha
Proxies de Conexão - saltos TLS do PgBouncer
Noções Básicas de Postgres Gerenciado - padrões TLS na nuvem
Melhores Práticas de Segurança - checklist de endurecimento

Versões da pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.

Configuração SSL/TLS

Receita

# postgresql.conf
ssl = on
ssl_cert_file = '/etc/postgresql/server.crt'
ssl_key_file  = '/etc/postgresql/server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf - rejeita não-TLS de sub-redes de aplicativos
hostssl  all  all  10.20.0.0/16  scram-sha-256
hostnossl all all  0.0.0.0/0     reject

# String de conexão do cliente
psql "host=db.internal port=5432 dbname=orders user=app_api sslmode=verify-full sslrootcert=/etc/ssl/certs/ca.pem"

Quando usar isso:

Qualquer cliente que cruza uma rede não confiável (VPC peering, VPN, endpoint público)
Requisitos de conformidade para criptografia em trânsito
Postgres gerenciado onde você ainda deve definir sslmode nos aplicativos e rotacionar pacotes de CA

Exemplo de Trabalho

Primário auto-hospedado com certificado de servidor Let's Encrypt e clientes de aplicativo verificando o nome do host.

# Gera ou obtém certificado de servidor (autoassinado simplificado para laboratório)
openssl req -new -x509 -days 365 -nodes -text \
  -out server.crt -keyout server.key -subj "/CN=db.prod.internal"
chmod 600 server.key
chown postgres:postgres server.crt server.key

# postgresql.conf
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf
hostssl  orders  app_api  10.20.0.0/16  scram-sha-256

# DSN do aplicativo (exemplo Node pg)
export DATABASE_URL="postgresql://app_api@db.prod.internal:5432/orders?sslmode=verify-full&sslrootcert=/etc/app/ca.crt"

O que isso demonstra:

O servidor apresenta o certificado; os clientes exigem TLS via hostssl
verify-full verifica a CA e a correspondência do nome do host
Conexões não-TLS do CIDR do aplicativo são rejeitadas explicitamente

Mergulho Profundo

Matriz de Cliente sslmode

sslmode	Criptografa	Verifica CA	Verifica nome do host
`disable`	Não	Não	Não
`require`	Sim	Não	Não
`verify-ca`	Sim	Sim	Não
`verify-full`	Sim	Sim	Sim

Use verify-full para conexões de aplicativos de produção, a menos que um proxy gerenciado documente um modelo de confiança diferente.

Rotação de Certificado

# Recarregamento sem interrupção após a substituição de server.crt/server.key
pg_ctl reload -D /var/lib/postgresql/data
# Ou SQL:
SELECT pg_reload_conf();

Rotacione os certificados do servidor antes do vencimento (aviso de 30 dias). Atualize o sslrootcert do cliente quando a CA mudar.

Notas sobre Nuvem Gerenciada

Provedor	TLS do Servidor	Ação do Cliente
RDS / Aurora	Imposto em endpoints públicos	Baixar pacote de CA do RDS, `sslmode=verify-full`
Cloud SQL	Gerenciado pelo servidor	Use o conector ou parâmetros SSL do console
Neon / Supabase	TLS por padrão	Use a string de conexão fornecida com um mínimo de `sslmode=require`

Armadilhas

sslmode=require sem verificação de CA - criptografado, mas vulnerável a MITM com certificado malicioso. Correção: verify-full + CA fixada.
host + hostssl ambos permitindo o mesmo CIDR - os clientes podem voltar para texto simples se mal configurados. Correção: hostnossl ... reject para intervalos sensíveis.
Certificado de servidor expirado após renovação automática em disco - o Postgres não recarrega certificados dinamicamente em todas as plataformas. Correção: pg_reload_conf() no hook de renovação de certificado.
CN/SAN incorreto no certificado - verify-full falha com incompatibilidade de nome de host. Correção: o SAN do certificado inclui db.prod.internal exatamente como os clientes se conectam.
Terminação TLS apenas no PgBouncer - o salto entre o pooler e o Postgres pode ser em texto simples dentro da VPC. Correção: TLS para o Postgres também quando o modelo de ameaça inclui espionagem leste-oeste.
Java trust store sem a CA do RDS - os aplicativos falham com erros PKIX. Correção: importar o pacote de CA do provedor no truststore do JVM ou na imagem do contêiner.

Alternativas

Alternativa	Usar Quando	Não Usar Quando
Private Service Connect / Apenas VPC	Nenhum endpoint público existe	Clientes fora da VPC precisam de acesso
Túnel SSH / VPN	Aplicativos legados não podem definir sslmode	Você pode corrigir o DSN do cliente corretamente
Certificados de cliente mTLS (`cert` auth)	Serviço a serviço com poucos clientes	Grande frota de instâncias de aplicativo dinâmicas
Apenas lista de permissão de IP	Camada extra com TLS	Como único controle (IPs podem ser falsificados internamente)

FAQs

TLS é suficiente sem SCRAM?

Não. TLS protege na rede; SCRAM protege o armazenamento do verificador de senha e a resposta ao desafio no login.

O PgBouncer precisa de TLS?

Sim, para cliente-para-pooler quando os clientes estão fora da VLAN do banco de dados. TLS de pooler-para-Postgres depende do seu modelo de ameaça leste-oeste.

Como testar TLS rapidamente?

psql "sslmode=require" e depois \conninfo. OpenSSL: openssl s_client -starttls postgres -connect host:5432.

Posso usar apenas TLS 1.3?

O PostgreSQL suporta TLS 1.2+. Defina ssl_min_protocol_version e verifique a compatibilidade da biblioteca cliente.

E quanto ao TLS de replicação?

Use hostssl para entradas de replicação e primary_conninfo com sslmode=verify-full em standbys.

Impacto no desempenho?

Pequeno em CPUs modernas com reutilização de sessão. O gargalo ainda são as consultas e o disco, não o handshake TLS em estado estável.

Certificados autoassinados em desenvolvimento?

sslmode=require é aceitável localmente. A produção deve usar uma CA adequada ou um pacote de provedor gerenciado.

Onde armazenar sslrootcert no K8s?

Monte a CA como um volume Secret; referencie o caminho em DATABASE_URL. Rotacione via implantação contínua.

A replicação lógica usa TLS?

Sim, quando a string de conexão define sslmode. Trate os links de replicação como tráfego de aplicativo.

Como isso interage com SCRAM?

Camadas ortogonais: TLS para transporte, SCRAM para autenticação de senha após o canal ser criptografado.

Relacionado

Noções Básicas de Segurança - modelo de ameaça
Autenticação SCRAM - autenticação de senha
Proxies de Conexão - saltos TLS do PgBouncer
Noções Básicas de Postgres Gerenciado - padrões TLS na nuvem
Melhores Práticas de Segurança - checklist de endurecimento

Versões da pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.

Configuração SSL/TLS

Buscar na documentação

Configuração SSL/TLS