Permissões no SaaS: autonomia sem acesso de administrador

Dar autonomia a quem usa seu SaaS começa por liberar o trabalho que essa pessoa precisa fazer. Quando qualquer exceção exige acesso de administrador, o cliente escolhe entre esperar alguém disponível e conceder mais poder do que gostaria.

Considere uma assistência técnica fictícia com duas filiais. É segunda-feira, um técnico faltou e Ana, coordenadora da unidade Centro, precisa redistribuir as visitas da manhã. Ela consegue consultar as ordens de serviço, mas só o administrador pode trocar o responsável. O dono da conta está em reunião. Os técnicos estão esperando.

O suporte sugere promover Ana a administradora. A manhã volta a andar, junto com uma pergunta: por que organizar a própria equipe também deveria liberar a configuração de todas as filiais? Acompanhar essa tarefa ajuda a desenhar permissões que deixem o cliente trabalhar com um acesso proporcional à responsabilidade dele.

A tarefa cabe em uma frase

O pedido inicial chegou como “preciso de acesso de administrador”. Na conversa seguinte, Ana explica o que aconteceu. Ela precisava trocar os técnicos de algumas visitas da unidade Centro, mantendo os horários combinados. Ninguém havia pedido que ela alterasse preços, convidasse funcionários ou mudasse configurações da empresa.

A equipe do SaaS passa a discutir uma capacidade concreta: redistribuir ordens de serviço da filial pela qual a pessoa responde. Essa frase já permite avaliar a solução. Ana consegue resolver a ausência? A alteração preserva as informações que ela não deve editar? O gerente entende o que está liberando?

O GitHub oferece um exemplo real dessa separação: uma pessoa pode receber permissão para administrar registros de GitHub Apps específicos, sem ganhar, por esse papel, autorização para instalar ou desinstalar aplicativos na organização. A documentação mostra como uma responsabilidade pode ter limites próprios. Veja a descrição de GitHub App managers.

Para Ana, a proposta é substituir aquela promoção emergencial por um perfil de coordenação com esse conjunto de tarefas. Se todos os coordenadores trabalham da mesma forma, um perfil compreensível evita que o gerente tenha de montar dezenas de combinações. A flexibilidade precisa ajudar também quem concede o acesso.

Defina quais ordens entram nesse acesso

A frase “pode redistribuir ordens” ainda deixa uma decisão aberta. Quais ordens? Ana conhece a operação do Centro. A outra filial tem sua própria coordenação, seus horários e seus técnicos. Um botão liberado para a empresa inteira resolveria a urgência com um alcance maior do que o combinado.

Para esse produto fictício, a proposta fica completa assim: Ana pode trocar o técnico responsável pelas ordens da filial Centro, dentro da empresa em que trabalha. A ação e os registros alcançados aparecem juntos quando o gerente concede a permissão. Ele consegue reconhecer a rotina que está autorizando.

Existe ainda a separação entre empresas clientes do SaaS. A orientação da OWASP para aplicações multitenant recomenda verificar, no servidor, se a identidade autenticada pode atuar na organização selecionada. Receber um identificador de empresa enviado pelo navegador não estabelece essa autorização.

A filial acrescenta uma regra de negócio dentro dessa fronteira. Imagine um gerente que acompanha as duas unidades e um coordenador que atende apenas uma. Ambos podem executar a mesma tarefa, com alcances diferentes. Essa distinção fica mais fácil de explicar quando a tela mostra “Redistribuir ordens: Centro”, em vez de um nome vago como “Acesso avançado”.

Mostre como resolver o bloqueio

Enquanto o acesso não é concedido, Ana precisa entender o que fazer. “Operação não permitida” deixa a visita parada e abre outra conversa com o suporte. Uma mensagem mais útil poderia dizer: “Seu perfil permite consultar estas ordens. Para redistribuí-las, solicite acesso de coordenação ao responsável pela sua conta.”

Se houver uma solicitação dentro do produto, ela pode levar a tarefa e a filial selecionadas para a pessoa autorizada a decidir. Ana não precisa descobrir o nome de uma permissão interna. O gerente recebe um pedido que consegue avaliar, com o alcance visível antes da aprovação.

Vale preservar a seleção das ordens para Ana retomar depois. Ao voltar, ela confere a situação atual e confirma a mudança. Durante a espera, outro coordenador pode ter encontrado uma solução. Executar automaticamente a intenção antiga criaria uma nova confusão na agenda.

Confira a permissão onde a mudança acontece

Esconder um botão organiza a interface, mas não protege a operação. A OWASP recomenda validar permissões em cada requisição e realizar o controle em uma camada confiável, como o servidor. Estar autenticado não autoriza toda ação disponível no sistema.

No ensaio dessa melhoria, a equipe cria ordens fictícias em cada filial e em outra empresa de teste. Ana deve conseguir redistribuir as do Centro. Pedidos para alterar as demais precisam ser recusados pelo servidor, inclusive quando enviados sem passar pelo botão. As ordens recusadas devem permanecer como estavam.

Esse ensaio dá conteúdo ao que o gerente leu na tela. A promessa de acesso à filial Centro precisa corresponder ao comportamento da aplicação. Se a regra só funciona no caminho mais comum, o rótulo transmite uma confiança que o produto ainda não entrega.

A cobertura termina, e o acesso acompanha

Na semana seguinte, Ana cobre as férias da coordenadora da outra filial. O trabalho mudou e existe motivo para ampliar seu alcance temporariamente. O gerente registra a cobertura e a data de término. Ao fim do período, Ana volta à responsabilidade habitual.

A equipe testa esse retorno com uma sessão já aberta: depois da revogação, uma nova tentativa de redistribuir ordens da filial coberta deve ser recusada. A documentação da OWASP sobre cache e isolamento reforça que dados em cache não dispensam autorização e que sua atualização precisa considerar esse risco.

Um registro do evento ajuda a entender uma mudança inesperada na agenda. A OWASP orienta registrar contexto suficiente sobre o evento, como momento, responsável, ação e resultado. Aqui, isso pode identificar quem redistribuiu uma ordem e em qual filial, sem copiar a descrição inteira do atendimento para o registro.

A fila volta a andar

Na próxima ausência de um técnico, Ana abre as ordens da sua unidade, ajusta os responsáveis e segue o dia. O dono da conta deixa de ser uma etapa obrigatória nessa rotina. O gerente continua responsável por decidir quem coordena cada filial.

Para encontrar uma melhoria assim no seu SaaS, retome um pedido recente de acesso de administrador. Descubra qual tarefa ficou parada e acompanhe a pessoa até concluí-la. Essa conversa pode revelar uma permissão pequena, com benefício bastante concreto: permitir que alguém faça o próprio trabalho sem esperar pela conta mais poderosa da empresa.