Transformar um sistema interno em uma plataforma para vários clientes muda a responsabilidade sobre os dados. Uma tela pode parecer isolada por empresa enquanto uma exportação, uma busca ou um processo automático continua consultando registros de todas elas. O problema não é cosmético: é uma falha na fronteira de acesso.
Em um sistema multi-tenant, o isolamento precisa acompanhar leitura, escrita, arquivos, tarefas e integrações. Esconder registros na interface não substitui autorização no servidor e no armazenamento.
Empresa, usuário e papel são dimensões diferentes
Uma pessoa pode participar de duas empresas e exercer funções diferentes em cada uma. “Administrador” sem contexto é uma permissão ambígua. O sistema precisa identificar em qual organização a ação acontece e qual vínculo autoriza aquela operação.
Em um cenário hipotético de consultoria, um analista acompanha três clientes, mas o responsável financeiro acessa apenas um. Usar um campo global de perfil pode conceder mais acesso do que o necessário. Modele a associação entre usuário, organização e papel, com regras explícitas para mudança e revogação.
A fronteira deve existir perto do dado
A documentação do Supabase apresenta Row Level Security como mecanismo de políticas de acesso por linha no PostgreSQL. RLS pode compor o isolamento, mas sua eficácia depende das políticas e do papel utilizado na consulta. Credenciais privilegiadas e rotas que ignoram essa camada precisam de atenção própria.
Não aceite o identificador da empresa apenas porque o navegador o enviou. Um usuário pode alterar argumentos. O servidor deve conferir vínculo e contexto autorizado. A mesma regra vale para agentes de IA, integrações e processos agendados: um formato de entrada válido não demonstra direito de acesso.
| Superfície | Pergunta de revisão | Caso de teste |
|---|---|---|
| Listagem | O filtro é obrigatório no servidor? | Trocar o identificador da empresa |
| Detalhe | O registro pertence ao contexto autorizado? | Abrir URL de outro cliente |
| Exportação | A consulta mantém a mesma política? | Exportar com perfil restrito |
| Arquivo | O download confere autorização? | Reutilizar link em outra sessão |
| Tarefa automática | A empresa é carregada com segurança? | Processar dois clientes em sequência |
Cuidado com cache e processamento em segundo plano
Um cache com chave baseada apenas em “relatório mensal” pode reutilizar dados entre empresas. A chave precisa representar os elementos que mudam o resultado, inclusive contexto de acesso quando aplicável. Não basta separar a tela se a resposta já foi montada para outro usuário.
Tarefas em fila também precisam carregar identidade suficiente para executar a regra correta. Evite depender de uma variável global de “empresa atual” em processos que atendem múltiplas solicitações. O vínculo deve ser explícito e verificável no momento do processamento.
Se a permissão for revogada depois de a tarefa entrar na fila, defina o comportamento. Algumas operações devem verificar novamente antes de executar; outras dependem de uma autorização registrada para uma ação específica. A escolha precisa refletir risco e regra de negócio, não acontecer por acidente.
Acesso de suporte é um produto, não uma exceção invisível
A equipe técnica pode precisar investigar um chamado. Isso não justifica uma conta compartilhada com acesso irrestrito e sem registro. Defina quem pode acessar, em qual situação, por quanto tempo e com qual trilha de auditoria.
Uma abordagem útil é conceder acesso temporário e limitado ao problema relatado, com registro do responsável. Não replique dados de produção em ambientes de teste por conveniência. Use dados sintéticos ou minimizados quando possível e controle o ciclo de vida de qualquer cópia autorizada.
Como testar isolamento de forma verificável
Crie pelo menos duas organizações fictícias com dados parecidos. Use usuários com papéis diferentes e execute as mesmas operações por interface e API. A semelhança dos registros é intencional: ela ajuda a detectar consultas que retornam o primeiro resultado sem conferir o vínculo.
Teste leitura e alteração. Um sistema pode bloquear a listagem e ainda permitir atualizar um registro por identificador. Inclua também criação de relacionamentos, anexos, comentários e consultas agregadas. Uma contagem indevida pode revelar informação mesmo sem expor o registro completo.
Checklist de aceite
- Vínculos e papéis definidos por organização.
- Identificação da empresa validada no servidor.
- Políticas de leitura e escrita testadas separadamente.
- Exportações e arquivos incluídos na revisão.
- Cache e filas com contexto de acesso correto.
- Revogação de acesso exercitada em sessão ativa.
- Procedimento de suporte com rastreabilidade.
Perguntas frequentes
Toda empresa precisa de um banco separado?
Não. Bancos separados e tabelas compartilhadas têm implicações diferentes. A decisão depende de isolamento exigido, operação, custo e capacidade de manutenção, não apenas da quantidade de clientes.
Colocar tenant_id em todas as tabelas resolve?
É um elemento de modelagem, não uma garantia. Consultas, relacionamentos, políticas e tarefas precisam usar esse contexto corretamente.
O administrador da plataforma pode acessar tudo?
Isso precisa ser uma decisão explícita, restrita e auditável. Administração técnica não deve virar acesso irrestrito por padrão.
Referência e próximo passo
Consulte a documentação de RLS do Supabase para o mecanismo de políticas. Os cenários e o checklist deste artigo são recomendações editoriais para revisão de produto.
Se sua empresa quer atender vários clientes no mesmo sistema, veja o guia para transformar uma consultoria em SaaS e converse sobre desenvolvimento sob medida.
