Como implementar isolamento de dados perfeito em SaaS multi-tenant usando RLS do PostgreSQL + Prisma Middleware.
Isolamento precisa existir em mais de uma camada
Em um SaaS multi-tenant, um bug que troca o tenant atual pode expor dados de outra empresa. Filtrar por tenantId no código é necessário, mas não deve ser a única barreira. O banco também precisa negar consultas fora do contexto autorizado.
Modelo de dados e contexto da sessão
Uma abordagem comum mantém tenantId nas tabelas de negócio e define o tenant atual na sessão PostgreSQL durante cada transação. As políticas RLS usam esse valor para limitar SELECT, INSERT, UPDATE e DELETE.
- Toda entidade pertencente a uma empresa carrega tenantId.
- O contexto deve ser definido no início da transação.
- A conexão precisa ser limpa ou reutilizada com cuidado no pool.
- Operações administrativas exigem um caminho explícito e auditado.
Prisma sem esconder o limite da abstração
O Prisma organiza queries e tipos, mas RLS é uma responsabilidade do PostgreSQL. Middleware pode validar a presença do tenant e iniciar o contexto, porém não deve criar uma falsa sensação de segurança. Queries raw, migrations e jobs precisam obedecer à mesma regra.
Testes que realmente importam
Os testes devem tentar acessar dados de outro tenant de forma explícita. Também é importante validar transações concorrentes, workers, tarefas agendadas e caminhos de suporte. Segurança multi-tenant é comportamento verificável, não apenas uma coluna no schema.
- Consulta de tenant A com contexto de tenant B deve retornar vazio ou falhar.
- INSERT e UPDATE com tenant incorreto devem ser rejeitados.
- Jobs sem contexto devem falhar de forma segura.
- Migrations devem habilitar e forçar RLS nas tabelas protegidas.
Quer aplicar esta ideia no seu negócio?
Converse com a equipe CodetecVance sobre o contexto, o escopo e a solução mais adequada para sua operação.
Falar com a equipe