Como definir permissões em um portal com várias unidades

Para definir permissões em um portal com várias unidades, combine quatro elementos: quem está usando, a qual unidade essa pessoa está vinculada, qual informação deseja acessar e o que pretende fazer. Um perfil chamado “gestor” deixa decisões demais em aberto. O projeto precisa esclarecer se esse gestor pode consultar, alterar, aprovar ou exportar cada tipo de registro, e em quais unidades.

Esse acordo deve existir antes de ampliar o portal. A proposta a seguir ajuda gestores e responsáveis técnicos a transformar responsabilidades da operação em regras verificáveis. Ela complementa o planejamento de uma área de franqueados útil, concentrando-se no limite de acesso entre pessoas e unidades.

Escreva a permissão como uma decisão de trabalho

Comece por uma tarefa, como acompanhar solicitações de material. Descreva quem precisa consultar o pedido, quem pode corrigi-lo e quem confirma sua conclusão. Depois repita o exercício para documentos, campanhas e relatórios. A mesma pessoa pode ter responsabilidades diferentes em cada um desses assuntos.

Use uma frase que a operação consiga revisar: “O gestor da unidade pode consultar os pedidos daquela unidade e corrigir os que ainda aguardam análise”. Essa descrição já permite perguntar quem altera um pedido aprovado e o que acontece quando alguém passa a responder por dois endereços.

A OWASP distingue autenticação de autorização: identificar uma pessoa no login não determina tudo o que ela pode fazer. A referência recomenda conceder apenas o acesso necessário, negar o que não foi autorizado e verificar permissões em cada requisição.

Para organizar as decisões, registre:

Tarefa e informação envolvida.
Papel da pessoa naquela tarefa.
Unidade ou conjunto de unidades permitido.
Ações autorizadas e condições para executá-las.
Quem aprova a concessão e quando o vínculo deve terminar.

Separe papel, vínculo e alcance

Considere um exemplo hipotético: uma rede tem as unidades A e B e uma equipe central de marketing. Uma gestora acompanha as duas unidades, enquanto cada atendente trabalha em apenas uma. A equipe central publica campanhas para a rede, mas não precisa consultar todos os documentos administrativos locais.

Um desenho possível seria permitir que os atendentes abram e acompanhem solicitações de sua unidade. A gestora poderia revisar as solicitações de A e B. O marketing administraria materiais de campanha e responderia aos pedidos que lhe foram encaminhados. Um documento restrito à gestão local seguiria outra regra, mesmo estando no mesmo portal.

Esse exemplo evita concentrar todas as decisões no rótulo “administrador”. Publicar uma campanha, convidar um colaborador e exportar registros são capacidades separadas. Para cada uma, a equipe deve justificar o alcance necessário. A pessoa que organiza materiais da rede não precisa receber, por consequência, poder para ampliar o próprio acesso.

O vínculo com duas unidades também deve ser explícito. Se a gestora deixar de atender A, a remoção desse vínculo precisa preservar o trabalho autorizado em B. Essa situação serve como um caso concreto para discutir o modelo antes de contratar ou desenvolver a solução.

Confira o limite no servidor

O filtro de unidade na tela ajuda a navegar. A proteção efetiva precisa continuar funcionando quando alguém abre um endereço diretamente ou quando outra aplicação consulta os dados. A OWASP orienta que a decisão de autorização ocorra no servidor ou em uma camada equivalente de confiança, sem depender apenas de controles no navegador.

Na conversa com a equipe técnica, peça que explique como o vínculo é verificado. O guia da OWASP para aplicações que atendem organizações distintas orienta tratar o identificador enviado pelo cliente apenas como seleção, validando se a pessoa tem acesso à organização escolhida. O mesmo princípio pode orientar um portal que precisa separar unidades, conforme seu modelo operacional.

Uma opção técnica é a segurança por linha do banco de dados, conhecida como RLS. A documentação do Supabase explica a combinação entre privilégios de operação e políticas que delimitam quais registros podem ser acessados. A escolha exige implementação e testes próprios; ativar um recurso não comprova, sozinho, que todas as regras do portal estão corretas.

Inclua anexos e exportações na mesma revisão

Volte ao exemplo da rede. Se um atendente não pode abrir uma solicitação de B, o PDF anexado a ela também precisa respeitar esse limite. Faça uma lista dos caminhos pelos quais a informação pode sair: tela, pesquisa, download, relatório e notificação.

O armazenamento merece uma conferência específica. No Supabase Storage, arquivos em buckets públicos, áreas de armazenamento configuradas para acesso público, podem ser lidos por quem possui o endereço. Buckets privados aplicam controle de acesso também ao download; há ainda URLs assinadas com validade limitada. Por isso, colocar um link dentro de uma página com login não torna o arquivo automaticamente privado.

Defina com o responsável técnico como links temporários serão usados e qual prazo atende à tarefa. Quando o documento precisa permanecer restrito, avalie o acesso direto ao arquivo, além da página que o apresenta.

Exportações pedem uma decisão adicional da operação: quem realmente precisa trabalhar fora do portal, com quais campos e para qual finalidade? Um relatório consolidado pode ser útil à gestão sem exigir que cada unidade receba os registros detalhados das demais.

Planeje mudanças de equipe

A concessão inicial é apenas uma parte da rotina. Defina quem comunica admissões, substituições temporárias e desligamentos. Registre a unidade, o papel, a aprovação e, quando houver, a data de encerramento do acesso.

Pergunte também quando uma mudança passa a valer para sessões já abertas. A documentação do Supabase sobre RLS alerta que informações de equipe armazenadas em um JWT, o token usado na autenticação, podem continuar antigas até sua atualização. O projeto deve escolher um mecanismo de revogação compatível com a consequência do acesso residual.

Uma cobertura de férias, por exemplo, deve indicar o período e as tarefas que a pessoa assumirá. Ao fim, confira o encerramento. Se a responsabilidade mudou de forma permanente, atualize o vínculo em vez de acumular exceções difíceis de explicar.

Transforme o acordo em critérios de aceite

Prepare contas demonstrativas e dados fictícios em um ambiente autorizado. Para o exemplo de A e B, peça uma demonstração destes resultados:

O atendente de A conclui a tarefa permitida em A.
O mesmo atendente não consegue consultar nem alterar um registro de B por acesso direto.
O arquivo restrito de B continua protegido fora da página do portal.
A gestora perde o acesso a A após a revogação, conforme o prazo definido, e mantém o acesso autorizado a B.
Uma exportação contém somente o alcance e os campos aprovados para aquele perfil.
Uma tentativa bloqueada deixa os dados originais intactos.

Registre o resultado esperado e a evidência de cada cenário. Inclua no aceite a explicação de como mudanças futuras nessas regras serão revisadas. O guia de segurança multi-tenant da OWASP reforça a verificação do isolamento entre organizações em diferentes partes da aplicação; aqui, a adaptação é usar as fronteiras reais do portal como referência.

Esse roteiro ajuda a especificar o escopo, mas não substitui uma revisão de segurança proporcional aos dados e às ações disponíveis. Na próxima conversa sobre um sistema interno B2B, leve uma tarefa, duas unidades e uma mudança de responsável. Resolver esse cenário por completo dá uma base concreta para avaliar a solução e suas permissões.