Noções Básicas de Segurança

A segurança de produção do PostgreSQL começa com um modelo de ameaças: quem pode acessar a rede, como as credenciais são emitidas, se a injeção de SQL é possível e o que os usuários internos podem ler ou alterar. O PostgreSQL 18.4 oferece primitivas fortes (SCRAM, SSL, RLS, roles), mas os padrões são ajustados para desenvolvimento local, não para nuvem exposta à internet.

Receita

-- Role de aplicativo com privilégio mínimo (execute como administrador uma vez)
CREATE ROLE app_api LOGIN PASSWORD 'rotate-me' NOSUPERUSER NOCREATEDB NOCREATEROLE;
GRANT CONNECT ON DATABASE orders TO app_api;
GRANT USAGE ON SCHEMA public TO app_api;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_api;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT, INSERT, UPDATE ON TABLES TO app_api;

# Trecho do pg_hba.conf: TLS + SCRAM apenas para sub-redes de aplicativos
hostssl  orders  app_api  10.20.0.0/16  scram-sha-256

Quando usar isso:

• Integração de novo serviço antes do primeiro deploy em produção
• Revisão pós-incidente quando as credenciais ou os limites de rede não estavam claros
• Preparação para conformidade (SOC2, HIPAA) que exige controles de acesso documentados

Exemplo de Trabalho

Proteja uma API SaaS de banco de dados único: separe roles, revogue padrões públicos, force TLS.

-- 1. Revogar padrões perigosos em um novo banco de dados
REVOKE ALL ON DATABASE orders FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM PUBLIC;
 
-- 2. Role de aplicativo: apenas DML
CREATE ROLE app_api LOGIN PASSWORD 'use-vault-generated-secret'
  NOSUPERUSER NOCREATEDB NOCREATEROLE;
GRANT CONNECT ON DATABASE orders TO app_api;
GRANT USAGE ON SCHEMA public TO app_api;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_api;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_api;
 
-- 3. Role de migração: DDL apenas em CI (não em tempo de execução do aplicativo)
CREATE ROLE migrator LOGIN PASSWORD 'ci-only-secret' NOSUPERUSER;
GRANT CONNECT ON DATABASE orders TO migrator;
GRANT CREATE ON SCHEMA public TO migrator;
GRANT ALL ON ALL TABLES IN SCHEMA public TO migrator;
 
-- 4. Analista somente leitura (BI)
CREATE ROLE analyst_ro LOGIN PASSWORD 'bi-secret' NOSUPERUSER;
GRANT CONNECT ON DATABASE orders TO analyst_ro;
GRANT USAGE ON SCHEMA public TO analyst_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analyst_ro;

# postgresql.conf (gerenciado ou auto-hospedado)
ssl = on
password_encryption = scram-sha-256
log_connections = on
log_disconnections = on

O que isso demonstra:

• PUBLIC não é confiável por padrão
• O aplicativo em tempo de execução usa app_api apenas para DML, não superusuário
• DDL isolado para migrator usado em pipelines de implantação
• TLS e SCRAM são básicos, não extras opcionais

Mergulho Profundo

Modelo de Ameaças em Resumo

Como Funciona

• Autenticação (pg_hba.conf + pg_authid): o cliente prova a identidade; SCRAM armazena um verificador com salt, não a senha em texto plano.
• Autorização (GRANT/REVOKE, RLS): após o login, cada instrução é verificada em relação aos privilégios de objeto e políticas.
• Transporte (SSL/TLS): criptografa bytes em trânsito; verify-full também valida o nome do host do certificado do servidor.
• Auditoria (logging, pgaudit): registra quem se conectou e quais objetos foram acessados para investigações.

Notas do PostgreSQL

-- Confirma a role efetiva e search_path no início da sessão
SELECT current_user, session_user, current_setting('search_path');
 
-- Lista concessões perigosas
SELECT grantee, privilege_type, table_schema, table_name
FROM information_schema.role_table_grants
WHERE grantee IN ('PUBLIC', 'app_api')
ORDER BY 1, 2;

Armadilhas

• Usar o superusuário postgres na configuração do aplicativo - um comprometimento possui todo o cluster. Correção: role app_api dedicada com concessões mínimas.
• Deixar concessões PUBLIC em novos bancos de dados - qualquer login pode ler/escrever até que sejam revogadas. Correção: REVOKE ALL ON DATABASE ... FROM PUBLIC no runbook de provisionamento.
• trust ou md5 em pg_hba.conf - sem criptografia ou senha fraca em trânsito. Correção: hostssl + scram-sha-256 para todas as roles não locais.
• SQL construído via concatenação de strings - injeção clássica mesmo com ferramentas "internas". Correção: placeholders $1 em todos os drivers; nunca interpole a entrada do usuário.
• Mesma senha entre staging e produção - uma violação em staging se torna uma violação em produção. Correção: roles e segredos separados por ambiente; bloquear credenciais de produção em CI não produtivo.
• search_path excessivamente amplo - sequestro de objetos via schema malicioso. Correção: definir search_path por role: ALTER ROLE app_api SET search_path = app, public;

Alternativas

FAQs

Relacionado

• Configuração de SSL/TLS - criptografar conexões
• Autenticação SCRAM - hashing de senha
• pgaudit e Logging de Conformidade - trilhas de auditoria
• Criptografia em Repouso - proteção de disco e snapshot
• Melhores Práticas de Segurança - checklist operacional

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