Padrões GRANT/REVOKE

Os privilégios do PostgreSQL são explícitos por padrão. Novos objetos não concedem automaticamente acesso a roles de aplicação. Modele privilégios de esquema, tabela, coluna e sequência deliberadamente.

Receita

-- Caminho de leitura da aplicação
GRANT USAGE ON SCHEMA app TO app_readers;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_readers;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA app TO app_readers;
 
-- Caminho de escrita da aplicação (mais restrito)
GRANT USAGE ON SCHEMA app TO app_writers;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_writers;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA app TO app_writers;

Quando usar isso: Todo novo esquema, toda migração que cria tabelas e todo novo role de microsserviço.

Exemplo de Trabalho

CREATE SCHEMA app AUTHORIZATION app_owner;
 
CREATE ROLE app_api LOGIN PASSWORD 'vault';
CREATE ROLE app_ro LOGIN PASSWORD 'vault';
GRANT app_readers TO app_ro;
GRANT app_writers TO app_api;
 
-- Nível de tabela com restrição de coluna
CREATE TABLE app.users (
  id bigint PRIMARY KEY,
  email text NOT NULL,
  ssn_last4 char(4)  -- sensível
);
 
GRANT SELECT (id, email) ON app.users TO app_ro;
GRANT SELECT, INSERT, UPDATE ON app.users TO app_api;
REVOKE ALL ON app.users FROM PUBLIC;
 
-- Verificar privilégios efetivos
SELECT grantee, privilege_type, column_name
FROM information_schema.column_privileges
WHERE table_schema = 'app' AND table_name = 'users';

O que isso demonstra:

• USAGE no esquema é necessário antes do acesso à tabela
• GRANT SELECT (colunas) em nível de coluna oculta campos sensíveis de analistas
• REVOKE ALL FROM PUBLIC fecha a brecha padrão PUBLIC em clusters novos (ao endurecer)

Mergulho Profundo

Camadas de Privilégio

PUBLIC e ACLs Padrão

REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON DATABASE myapp FROM PUBLIC;
GRANT CONNECT ON DATABASE myapp TO app_readers;

• O PostgreSQL concede historicamente alguns direitos a PUBLIC no esquema public.
• Linhas de base endurecidas revogam PUBLIC e concedem explicitamente a roles de grupo.
• ALTER DEFAULT PRIVILEGES lida com objetos futuros (veja página dedicada).

Propriedade vs. Privilégios

• O proprietário do objeto ignora os privilégios para seus objetos (exceto RLS).
• Migrações devem ser executadas como app_owner NOLOGIN; a conexão em tempo de execução é como app_api.
• REASSIGN OWNED move a propriedade durante a renomeação de roles.

Armadilhas

• Esqueci USAGE do esquema - permission denied for schema app apesar do GRANT na tabela. Correção: GRANT USAGE ON SCHEMA app.
• Sequência não concedida - INSERT funciona com serial até a sequência esgotar em uma nova linha. Correção: GRANT USAGE, SELECT ON SEQUENCE.
• ALL TABLES não abrange tabelas futuras - Migração adiciona tabela; app retorna 403 até que o GRANT seja executado novamente. Correção: ALTER DEFAULT PRIVILEGES para o role do migrador.
• GRANT de coluna + SELECT * - App usa SELECT * e falha em colunas ocultas de forma inconsistente. Correção: Listas explícitas de colunas nas consultas do app.
• Superusuário na string de conexão - Privilégios irrelevantes; pesadelo de auditoria. Correção: Sempre role de app com privilégio mínimo.

Alternativas

FAQs

Relacionados

• Noções Básicas de Roles - modelo de role de grupo
• Privilégios Padrão - privilégios automáticos em novos objetos
• Row-Level Security - filtros de linha sobre os privilégios

Versões do Stack: 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+.