APRENDER. PRATICAR. EVOLUIR.Ligar defaults ao criador e ao momento
ALTER DEFAULT PRIVILEGES prepara permissões para objetos futuros. No ensaio, configurar SELECT para app_b nos objetos criados por deploy_owner permite consultar future_data, mas old_data continua inacessível. Outra tabela criada por other_owner também não recebe essa concessão. Um pipeline que muda de identidade entre migrações pode assim produzir um schema com acessos inconsistentes. Regista current_user no momento de criar o objeto e verifica o owner resultante. A correção pode exigir grants nos objetos existentes e defaults para criações futuras, cada um com âmbito explícito. Não assumas que uma única alteração repara retroativamente todo o histórico de migrações.
Separar grant de política de linhas
A conta app_a recebe SELECT, INSERT e UPDATE em positions. Quando RLS é ativado sem políticas, a leitura devolve zero linhas, apesar do grant. Depois de criar tenant_scope com tenant=current_user, app_a vê id 1 e app_b vê id 2. A política restringe o conjunto de linhas dentro da autorização SQL existente; não substitui os grants necessários à operação. Ao investigar zero resultados, confirma primeiro a identidade e a política, em vez de concluir que os dados foram apagados. No ensaio, o administrador confirma que as duas linhas continuam presentes. Essa observação privilegiada é diagnóstico, não prova do acesso permitido ao cliente.
Distinguir linha invisível de nova linha proibida
O teste de escrita usa três operações. Inserir uma linha de app_b através de app_a falha com 42501. Alterar o tenant da própria linha para app_b também falha. Atualizar id 2, que app_a não consegue ver, devolve zero linhas em RETURNING e deixa units inalterado. Estes resultados distinguem a filtragem da linha existente de WITH CHECK sobre a linha proposta. Não interpretes zero atualizações como sucesso funcional quando o pedido exigia alterar exatamente uma posição. Define como a aplicação verifica cardinalidade, comunica ausência de autorização ou de objeto e evita divulgar informação sobre outros clientes.
Escolher a identidade de teste certa
O owner lê inicialmente as duas linhas mesmo com RLS ativo. Depois de FORCE ROW LEVEL SECURITY, esse owner não vê linhas porque nenhuma tem o seu nome como tenant. Ao voltar ao superuser, as duas linhas ficam visíveis. O contraste demonstra que FORCE não transforma um superuser numa conta runtime sujeita à política. Para aceitar uma release, usa identidades sem ownership nem BYPASSRLS e verifica se conseguem mudar para roles privilegiadas. O ensaio inclui ligações LOGIN distintas para app_a e app_b, mas usa autenticação local trust; não valida que uma password, certificado ou serviço de identidade autorize o cliente correto.
Rever a composição das políticas
Uma revisão acrescenta broad_read, uma política permissiva de SELECT para app_a com USING(true). A política tenant_scope continua presente, mas app_a passa a ver ambos os clientes. As políticas permissivas aplicáveis combinam-se por OR. Acrescentar tenant_guard como restritiva limita novamente a leitura ao tenant de app_a, mesmo mantendo broad_read. A revisão deve considerar comando, roles e todas as políticas aplicáveis, não apenas o texto da política nova. Uma restrição de SELECT não demonstra o comportamento de INSERT ou UPDATE. Repete a matriz por operação e verifica o conjunto final, incluindo mudanças que ampliem permissões sem remover a política antiga.
Reconhecer operações fora do filtro
No último contraste, app_a recebe TRUNCATE e consegue esvaziar a tabela inteira apesar de RLS. O ensaio envolve a operação numa transação e executa ROLLBACK; o administrador confirma as duas linhas restauradas. A proteção por linha não limita TRUNCATE a um tenant. Esta permissão requer uma decisão separada e normalmente não pertence ao runtime deste exemplo. A reversão observada é transacional e controlada, sem crash ou recuperação de backup. Na aceitação, associa cada requisito à evidência concreta: leitura entre clientes, escrita proibida, identidade efetiva, criação futura e operações globais. Não uses este laboratório como certificação geral de segurança do serviço.
-- Only in the disposable lab; owner prepares policy and grants separately.
ALTER TABLE service.positions ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_scope ON service.positions
USING (tenant = current_user) WITH CHECK (tenant = current_user);
-- Connect as app_a, then compare allowed and forbidden operations.
SELECT id FROM service.positions;
UPDATE service.positions SET units=99 WHERE id=2 RETURNING id;Uma política tenant=current_user mostra uma linha por conta; uma segunda política permissiva USING(true) alarga a leitura.
Armadilhas comuns
Assumir defaults retroativos; usar o owner como prova de isolamento; juntar políticas permissivas como se fossem AND; conceder TRUNCATE.
Tópicos relacionados: Identidade efetiva e menor privilégio · Aceitação e recuperação de mudanças
A política deve ser testada com a identidade realista, o comando exato e operações negativas, mantendo os limites do ensaio.
Referência: Row security and bypass boundaries · PostgreSQL 18 reference semantics;18.6 current stable at review