Isolamento multi-tenant com RLS que aguenta teste hostil

Plataforma própria construída com isolamento por Row Level Security em PostgreSQL, com suíte de testes que tenta vazar dado entre tenants.

Situação inicial

Precisava de uma plataforma onde cada organização enxerga só os próprios dados, sem duplicar banco por cliente e sem confiar no filtro da aplicação.

Restrição real

Operação solo: nada que exija manutenção de dezenas de bancos. Custo de infraestrutura precisava caber em produto próprio, não em orçamento de projeto.

Decisão técnica e por quê

Isolamento no banco, com RLS por tenant, e não na camada de aplicação. Papéis em tabela separada, nunca no perfil do usuário, para evitar escalonamento de privilégio. Função security definer para checagem de papel, evitando recursão de política. Suíte de teste que roda como cada papel e falha o build quando uma consulta retorna linha de outro tenant.

O que eu faria diferente

Escrevi as primeiras políticas usando a tabela de perfis para saber o papel do usuário. Isso criou recursão de política e, pior, deixava o papel editável por quem tinha o perfil. Reescrevi com tabela de papéis separada e função security definer. É o erro que mais vejo em projeto alheio.

Nota técnica relacionada: RLS multi-tenant: o que quebra em testes

Próximo passo

Vale ocupar uma hora da sua agenda?

Se o problema é visão computacional, dado ou decisão automatizada que precisa sustentar auditoria, a conversa começa direto comigo. Sem camada intermediária.

Agendar conversa