POSTGRESQL · SEGURANÇA · LGPD

Segurança PostgreSQL e LGPD — Checklist Completo 2026.

HTI Tecnologia · Equipe TécnicaPublicado em julho de 202614–17 min de leitura

Segurança de PostgreSQL não termina em senha forte. Em ambientes que tratam dados pessoais, cada camada — role, conexão, linha, coluna, log, backup — precisa responder a uma pergunta objetiva da LGPD: quem pode acessar, o que acessou, quando, e como você prova? Este checklist é a base técnica que a HTI aplica em consultoria PostgreSQL e Health Checks focados em compliance.

O texto abaixo não é jurídico — é operacional. Cada item traz o comando, o parâmetro ou o padrão de configuração, e a conexão com o artigo da LGPD que ele endereça. Feito para DBA, arquiteto de dados e CTO que precisam sair da "conformidade no papel" para hardening real e auditável.

O QUE A LGPD EXIGE DO BANCO — TRADUZIDO EM CONTROLES TÉCNICOS

Quatro artigos da Lei nº 13.709/2018 concentram praticamente todas as obrigações que aterrissam no PostgreSQL:

Art. 6, VII (segurança): uso de medidas técnicas para proteger dados pessoais de acessos não autorizados — mapeia para roles, RLS, pg_hba, criptografia.
Art. 37 (registro): manutenção de registro das operações de tratamento — mapeia para pgAudit, log_statement, retenção controlada.
Art. 46 (proteção): medidas de segurança aptas a proteger dados pessoais de acessos, destruição, alteração — mapeia para backup, DR testado, criptografia em repouso.
Art. 48 (notificação): comunicação de incidente de segurança à ANPD e ao titular em prazo razoável — mapeia para monitoramento comportamental, detecção e runbook de incidente.

"Conformidade em LGPD não é ter os documentos assinados — é conseguir responder tecnicamente 'quem, quando, o quê' em 48 horas após um incidente."

ROLES, GRANT E PRIVILÉGIO MÍNIMO

O erro mais comum em ambientes PostgreSQL auditados: a aplicação conecta como postgres (superuser) ou como um usuário com SUPERUSER herdado. Isso destrói qualquer controle de segurança acima: RLS não se aplica, pgAudit registra "root", e qualquer SQL injection vira comprometimento total.

Padrão mínimo de roles em produção

-- Separação de responsabilidades por role

-- 1) Role dono do schema (não usada por aplicação)

CREATE ROLE app_owner NOLOGIN;

-- 2) Role de aplicação (login, sem CREATE/DROP)

CREATE ROLE app_user LOGIN PASSWORD '...' CONNECTION LIMIT 100;

GRANT USAGE ON SCHEMA public TO app_user;

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;

-- 3) Role de leitura (BI, relatórios, réplica de leitura)

CREATE ROLE app_readonly LOGIN PASSWORD '...';

GRANT USAGE ON SCHEMA public TO app_readonly;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;

-- 4) Role administrativa (DBA humano, NÃO usada por aplicação)

CREATE ROLE app_admin LOGIN PASSWORD '...' IN ROLE app_owner;

-- Default privileges para objetos futuros

ALTER DEFAULT PRIVILEGES IN SCHEMA public

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;

Auditar privilégios em uso

-- Roles com SUPERUSER ou atributos elevados (não deve haver login application)

SELECT rolname, rolsuper, rolcreatedb, rolcreaterole, rolreplication

FROM pg_roles

WHERE rolcanlogin = true

AND (rolsuper OR rolcreatedb OR rolcreaterole OR rolreplication);

☐
Aplicação NUNCA conecta como superuser ou dono do schema
Art. 6, VII — Segurança e privilégio mínimo
☐
Cada aplicação/serviço tem role próprio com escopo dedicado
Art. 6, VII — Segregação de responsabilidades
☐
Senhas de role rotacionadas em ciclo definido em política
Art. 46 — Medidas de proteção
☐
Acesso humano via role individual — nunca credencial compartilhada
Art. 37 — Rastreabilidade individual
☐
ALTER DEFAULT PRIVILEGES configurado para novos objetos
Art. 6, VII — Segurança contínua

pg_hba.conf — A PRIMEIRA BARREIRA

pg_hba.conf é o firewall de autenticação do Postgres. Ele decide quem pode conectar, de onde, em qual banco, com qual método. Um host all all 0.0.0.0/0 trust perdido em um arquivo torna todos os outros controles decorativos.

# pg_hba.conf — modelo seguro para produção

# TYPE DATABASE USER ADDRESS METHOD

local all postgres peer

hostssl app_db app_user 10.0.1.0/24 scram-sha-256

hostssl app_db app_readonly 10.0.2.0/24 scram-sha-256

hostssl app_db app_admin 10.0.99.5/32 scram-sha-256 clientcert=verify-full

hostssl replication replicator 10.0.10.0/24 scram-sha-256

# NEGAR TUDO O RESTO explicitamente:

host all all 0.0.0.0/0 reject

host all all ::/0 reject

Detalhes que fazem diferença: hostssl (não host) força TLS; scram-sha-256 substitui o antigo md5; range CIDR restrito por perfil de acesso (aplicação vs DBA vs replicação); clientcert=verify-full para acesso administrativo — dupla autenticação (senha + certificado); regra final reject torna o comportamento explícito e auditável.

☐
Sem entradas trust em ambiente com dados pessoais
Art. 6, VII — Segurança de acesso
☐
Todas as conexões remotas usam hostssl (TLS obrigatório)
Art. 46 — Confidencialidade em trânsito
☐
Método scram-sha-256 (não md5) para autenticação por senha
Art. 6, VII — Medida técnica adequada
☐
Ranges CIDR restritos por perfil — sem 0.0.0.0/0 aberto
Art. 6, VII — Superfície de ataque mínima
☐
Alterações em pg_hba.conf versionadas em Git com revisão obrigatória
Art. 37 — Rastreabilidade de mudanças

ROW-LEVEL SECURITY — ISOLAMENTO POR LINHA

RLS filtra automaticamente linhas visíveis por role/sessão. Em SaaS multi-tenant, é o padrão para garantir que cliente A jamais leia dado de cliente B — mesmo com bug de autorização na aplicação. Em ambientes single-tenant com dados sensíveis, isola áreas do negócio (financeiro vê financeiro; RH vê RH).

-- RLS em tabela multi-tenant com session variable

ALTER TABLE clientes ENABLE ROW LEVEL SECURITY;

ALTER TABLE clientes FORCE ROW LEVEL SECURITY; -- aplica também ao owner

CREATE POLICY tenant_isolation ON clientes

USING (tenant_id = current_setting('app.current_tenant')::uuid);

-- Uso na aplicação, dentro da transação:

SET LOCAL app.current_tenant = '{tenant_uuid}';

SELECT * FROM clientes; -- retorna apenas do tenant setado

Armadilhas comuns de RLS

Esquecer FORCE ROW LEVEL SECURITY: por default, o dono da tabela ignora RLS — se sua aplicação for dona da tabela, RLS não faz nada. FORCE obriga.
Superuser bypass: superuser sempre ignora RLS. Motivo extra para aplicação nunca conectar como superuser.
Testar apenas com o mesmo role da aplicação: valide com role de leitor externo e usuário sem grants para confirmar que RLS bloqueia como esperado.
Política sem cláusula WITH CHECK: a policy filtra leitura, mas permite insert/update gravando linhas de outro tenant. Adicione WITH CHECK explícito.

☐
RLS ativa em toda tabela contendo dados pessoais em ambiente multi-tenant
Art. 6, VII — Segregação lógica de titulares
☐
FORCE ROW LEVEL SECURITY nas tabelas cujo owner é role de aplicação
Art. 6, VII — Prevenção de bypass
☐
Políticas com USING e WITH CHECK definidas separadamente
Art. 6, VII — Controle de leitura e escrita
☐
Cobertura de RLS testada em pipeline (integração contínua)
Art. 37 — Verificação contínua de controle

pgAudit — TRILHA AUDITÁVEL DE ACESSO

log_statement = 'all' registra tudo, mas é ruído puro em produção. pgAudit é a extensão-padrão para auditoria estruturada em Postgres: separa DDL, DML, ROLE, categoriza por classe e emite log parseável por SIEM. Recomendado por CIS Benchmark e usado por virtualmente toda operação Postgres com exigência regulatória.

# postgresql.conf — configuração mínima de pgAudit para ambiente com LGPD

shared_preload_libraries = 'pgaudit'

pgaudit.log = 'read, write, ddl, role, misc_set'

pgaudit.log_catalog = off # reduz ruído em pg_catalog

pgaudit.log_parameter = on # registra parâmetros usados

pgaudit.log_relation = on # registra relação acessada

pgaudit.log_statement_once = on # deduplica statement em batch

log_line_prefix = '%m [%p] %q%u@%d/%h ' # timestamp, pid, user, db, host

log_destination = 'stderr,jsonlog' # JSON facilita ingestão em SIEM

Auditoria só cumpre a LGPD quando o log sai do banco: envie para SIEM externo (Elastic, Splunk, Datadog, CloudWatch, Wazuh) com retenção definida em política e integridade preservada (write-once ou hash-chained). Log auditoria que fica no mesmo servidor do banco é apagado no primeiro comprometimento.

Auditoria seletiva por objeto (menos ruído)

-- Auditar somente as tabelas realmente sensíveis, via ROLE dedicado

CREATE ROLE audit_target NOLOGIN;

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE clientes, pagamentos, saude TO audit_target;

ALTER ROLE app_user SET pgaudit.role = 'audit_target';

-- Agora só ações do app_user sobre essas 3 tabelas geram log pgAudit

☐
pgAudit ativa registrando ao menos read, write, ddl, role
Art. 37 — Registro das operações de tratamento
☐
Logs enviados para SIEM externo com retenção mínima de 12 meses
Art. 37 — Integridade e disponibilidade do registro
☐
Alertas sobre operações sensíveis roteados para plantão 24/7
Art. 48 — Detecção de incidente
☐
Acesso ao SIEM registrado — auditoria do auditor
Art. 37 — Cadeia de custódia

CRIPTOGRAFIA EM TRÂNSITO, EM REPOUSO E EM COLUNA

Três camadas independentes — omitir qualquer uma cria vetor de vazamento:

Em trânsito: TLS obrigatório via ssl = on + ssl_cert_file/ssl_key_file, ssl_min_protocol_version = 'TLSv1.2' ou superior, cifras modernas apenas. Aplicações devem usar sslmode=verify-full.
Em repouso: criptografia de disco (LUKS em bare-metal; AWS EBS encryption, Azure Disk Encryption, GCP CMEK em cloud) ativa em todo volume que armazena datafiles, WAL e backup. TDE nativa não existe em Postgres open-source — a criptografia é feita em camada de storage.
Em coluna (opcional/sensível): pgcrypto para campos especialmente sensíveis (CPF, cartão, dados de saúde). pgp_sym_encrypt() com chave gerenciada em KMS externo. Aceita custo de performance em troca de proteção mesmo em cenário de dump vazado.

☐
TLS 1.2+ obrigatório em toda conexão remota (hostssl + ssl_min_protocol)
Art. 46 — Confidencialidade em trânsito
☐
Criptografia de disco ativa em datafiles, WAL, tablespaces e backups
Art. 46 — Proteção contra acesso físico não autorizado
☐
Colunas especialmente sensíveis com pgcrypto e chave em KMS externo
Art. 46 — Proteção adicional para dados sensíveis
☐
Certificados renovados automaticamente com alerta antes de expirar
Art. 6, VII — Continuidade da medida técnica

BACKUP, RETENÇÃO E DIREITO AO ESQUECIMENTO

Backup criptografado, armazenado fora da mesma conta/tenant de produção, restaurado em teste periódico. E — muito ignorado em ambientes brasileiros — retenção definida em política: guardar tudo para sempre viola o princípio da necessidade (Art. 6, III) e cria passivo em eventual incidente. Direito ao esquecimento (Art. 18, VI) obriga o controlador a eliminar dados do titular a pedido; se o backup guarda esses dados por 10 anos sem processo de expiração, você não consegue cumprir.

☐
Backup criptografado com pgBackRest ou Barman (chave gerenciada)
Art. 46 — Proteção do dado em repouso
☐
Backup armazenado em conta/tenant separado da produção
Art. 46 — Segregação de blast radius
☐
Restore testado em ambiente isolado nos últimos 90 dias
Art. 46 — Disponibilidade auditável
☐
Retenção de backup definida em política e aplicada automaticamente
Art. 6, III — Necessidade e finalidade
☐
Processo documentado para atender pedido de eliminação incluindo backup
Art. 18, VI — Direito ao esquecimento

MONITORAMENTO COMPORTAMENTAL E RESPOSTA A INCIDENTE

LGPD (Art. 48) exige comunicar incidente à ANPD e ao titular em prazo razoável — a ANPD tem sinalizado 3 dias úteis como referência. Isso é impossível se você só descobre o vazamento pelo cliente ou pela imprensa. Monitoramento comportamental (não só métrica de infra) é o que faz a detecção acontecer durante o incidente, não depois.

Padrões a monitorar em nível de banco: SELECT em massa fora do horário; dump inesperado de tabela sensível; criação de role com privilégio elevado; alteração de pg_hba.conf; falhas repetidas de autenticação; queries com padrão de data exfiltration (paginação sequencial de grande volume). Em ambientes operados pela HTI, isso é feito com DBSnoop — ferramenta comportamental proprietária que rastreia desvios além de CPU/RAM, aplicável a Postgres, MySQL, SQL Server e Oracle.

☐
Monitoramento comportamental ativo, não só métrica de infra
Art. 48 — Detecção de incidente em tempo real
☐
Alerta 24/7 roteado para plantão real (não caixa de e-mail)
Art. 48 — Resposta em prazo razoável
☐
Runbook de incidente com passos de contenção, análise e notificação
Art. 48 — Resposta estruturada
☐
Post-mortem documentado após cada incidente e revisão trimestral
Art. 37 — Melhoria contínua

CHECKLIST FINAL — VERSÃO PARA COMPARTILHAR

Consolidação por categoria. Use como base para reunião com CISO, DPO ou auditoria externa:

☐ Aplicação sem privilégios de superuser ou de owner do schema.
☐ Roles individuais para cada humano com acesso ao banco.
☐ pg_hba.conf sem trust; hostssl + scram-sha-256 em todas as entradas.
☐ TLS 1.2+ obrigatório; certificados válidos e monitorados.
☐ Criptografia de disco ativa em datafiles, WAL e backup.
☐ RLS ativa e FORCE em tabelas com dados de múltiplos titulares.
☐ pgAudit configurada (read/write/ddl/role) enviando log para SIEM externo.
☐ Retenção de log definida em política e aplicada automaticamente.
☐ Backup criptografado, off-site, com restore validado nos últimos 90 dias.
☐ Política de retenção de dados aplicada (não guardar para sempre).
☐ Processo documentado para atender direito de eliminação (inclui backup).
☐ Monitoramento comportamental 24/7 com alerta roteado para plantão real.
☐ Runbook de incidente com prazo alinhado ao Art. 48 (comunicação à ANPD).
☐ Health Check independente executado nos últimos 12 meses.

PRÓXIMO PASSO

Seu PostgreSQL passa nesse checklist?

Auditoria de segurança PostgreSQL alinhada à LGPD — roles, pg_hba, RLS, pgAudit, criptografia, retenção. Relatório com achados por severidade e roadmap acionável.

Solicitar Health Check PostgreSQL focado em LGPD→🛡 Segurança de Banco de Dados — visão do serviço↗💬 WhatsApp — Fale com um Expert PostgreSQL agora↗

PERGUNTAS FREQUENTES

A LGPD exige criptografia obrigatória no PostgreSQL?

A LGPD (Art. 46) exige adoção de medidas técnicas de segurança apropriadas ao risco — não cita 'criptografia' como palavra literal, mas em qualquer análise de risco envolvendo dados pessoais em produção, criptografia em trânsito (TLS/SSL) é considerada baseline e criptografia em repouso é fortemente esperada. Na prática: TLS obrigatório sempre; criptografia de disco (LUKS, EBS encryption, TDE gerenciado) obrigatório em dados sensíveis; criptografia de coluna (pgcrypto) para dados especialmente sensíveis (CPF, cartão, saúde). A ausência dessas medidas em incidente com vazamento pesa contra o controlador em análise da ANPD.

Row-Level Security (RLS) substitui autorização na aplicação?

Não — complementa. RLS é última barreira: se a aplicação tiver bug de autorização ou credencial vazar, RLS impede que um usuário leia dados de outro tenant. Em SaaS multi-tenant, RLS baseada em role ou em session variable (via SET LOCAL app.current_tenant) é o padrão para isolar linhas por cliente. Continua sendo obrigatório validar autorização também na camada da aplicação (defense in depth). RLS mal escrita, com FORCE ausente no proprietário da tabela, dá falsa sensação de segurança — teste sempre com role diferente de superuser.

pgAudit é obrigatório para conformidade LGPD?

Não é citado explicitamente na LGPD, mas o Art. 37 exige que o controlador mantenha registro das operações de tratamento e o Art. 46 pede medidas de segurança. Sem trilha auditável de acesso a dados pessoais, é praticamente impossível responder a: 'quem acessou o CPF do titular X entre janeiro e março?' — pergunta padrão em requerimento de titular ou em análise de incidente. pgAudit (ou logging equivalente centralizado com retenção e integridade) é o padrão de mercado. Configuração mínima: pgaudit.log = 'read, write, ddl, role' com envio dos logs para SIEM externo com retenção definida em política.

Quanto tempo devo reter logs de acesso ao banco para LGPD?

A LGPD não estipula prazo específico para logs de acesso — o prazo deriva da política interna de retenção, do princípio da necessidade (Art. 6, III) e das exigências de outros regimes que se apliquem (Marco Civil da Internet exige 6 meses para logs de aplicação; setores regulados como financeiro e saúde têm prazos próprios de 5 a 20 anos). Baseline razoável: 12 meses de logs quentes acessíveis para investigação + 5 anos de logs frios em storage imutável para atender auditoria. Retenção maior que 12 meses de logs contendo dados pessoais requer justificativa e base legal — não guarde por default.