Numa aplicação B2B, decidir quem pode consultar, alterar ou aprovar um recurso afeta o produto, a operação e o risco. Um modelo demasiado simples pode conceder acesso em excesso; um modelo excessivamente detalhado pode ser difícil de administrar e explicar. A decisão entre papéis ou permissões contextuais não consiste em escolher uma etiqueta técnica: consiste em representar as regras reais do negócio de forma compreensível, verificável e sustentável.
A opção adequada depende do quanto o acesso varia entre utilizadores, recursos e situações, e de quem terá de gerir essas diferenças. Convém começar pelos casos reais, não por uma lista de controlos. Depois, é possível adotar o modelo mais simples que os abranja e definir sinais concretos para o fazer evoluir.
Autenticação e autorização respondem a perguntas diferentes
A autenticação verifica quem é o utilizador, por exemplo, através de uma sessão ou de um fornecedor de identidade. A autorização determina o que essa identidade pode fazer em relação a um recurso específico. Ter iniciado sessão não significa ter permissão para ver todas as faturas, projetos ou dados de uma empresa.
Para conceber a autorização, descreva cada decisão com quatro elementos: o interveniente, a ação, o recurso e as condições aplicáveis. Por exemplo: “uma pessoa com permissão de faturação pode descarregar faturas da sua organização”. Esta frase obriga a esclarecer se a permissão se aplica a todas as organizações, a uma organização selecionada ou apenas a determinados documentos.
Também convém definir desde o início o âmbito dos dados. Num produto utilizado por várias empresas clientes, uma verificação correta do papel não basta se a consulta devolver recursos de outro cliente. A autorização deve abranger tanto a ação como o acesso ao recurso e a sua pertença ao âmbito correspondente.
Permissões baseadas em papéis: clareza quando os padrões se repetem
No controlo de acesso baseado em papéis, ou RBAC, as permissões são agrupadas em papéis e os papéis são atribuídos aos utilizadores. Um papel como “administrador da organização” pode permitir gerir membros e configurações; outro, como “analista”, pode dar acesso de leitura a relatórios. A aplicação verifica se o papel do utilizador inclui a permissão necessária para a ação.
Esta abordagem funciona bem quando as funções ou responsabilidades do produto se repetem e as diferenças entre utilizadores são relativamente estáveis. Facilita a explicação do acesso na interface, a criação de perfis habituais e a revisão das atribuições. Também oferece um vocabulário comum às equipas de produto, suporte e tecnologia: é mais fácil discutir “editor” do que manter uma lista opaca de permissões individuais.
Mas os papéis não devem transformar-se automaticamente em etiquetas profissionais. A mesma pessoa pode ter responsabilidades diferentes em cada organização, e um papel global pode conceder acesso em excesso. É habitual que o papel tenha um âmbito: por exemplo, “administrador” dentro de uma organização, não em toda a plataforma. Defina com precisão quem atribui papéis, a que recursos se aplicam e se uma pessoa pode acumular vários papéis.
Escolha papéis quando as permissões formarem conjuntos reconhecíveis, mudarem pouco e puderem ser geridas sem criar um novo papel para cada exceção. Se as combinações se multiplicarem (“editor com acesso apenas a dois projetos, exceto durante uma aprovação”), talvez o papel esteja a tentar representar demasiadas dimensões.
Regras contextuais: acesso de acordo com o utilizador, o recurso ou a situação
Uma regra contextual tem em conta atributos além da identidade ou do papel. O acesso pode depender de quem solicita a ação, do recurso que pretende utilizar e das condições existentes. Por exemplo, pode permitir-se a edição de um projeto apenas se a pessoa pertencer à equipa atribuída e o projeto estiver em estado de rascunho. Esta abordagem é frequentemente associada ao controlo de acesso baseado em atributos, ou ABAC.
As regras contextuais são úteis quando os mesmos utilizadores têm permissões diferentes consoante os recursos ou quando o estado do negócio altera aquilo que é permitido. Podem representar a pertença a uma equipa, a propriedade de um registo, a classificação de dados ou uma fase de aprovação. Assim, evita-se criar um papel diferente para cada combinação de utilizador e recurso.
A flexibilidade tem um custo: as decisões tornam-se menos visíveis quando dependem de atributos dispersos ou de condições difíceis de explicar. Uma regra pode falhar porque o estado do recurso está desatualizado, falta um dado ou não foi definido o comportamento perante um valor desconhecido. Para cada condição, identifique a origem, o responsável, a atualização e o tratamento de erros. Se faltar um dado necessário para conceder acesso, a política deve recusar a ação de forma segura.
“Permissões contextuais” não significa necessariamente implementar um motor complexo. Pode tratar-se de uma verificação explícita de pertença e estado numa aplicação pequena. O importante é que a regra seja coerente, possa ser centralizada e testada, não que adote uma arquitetura específica.
Como comparar as abordagens em casos reais
Prepare uma matriz pequena com utilizadores representativos, ações e recursos. Inclua casos habituais e exceções: um utilizador de duas organizações, um recurso partilhado, uma pessoa que muda de equipa e uma ação de aprovação. Para cada linha, anote o resultado esperado e a respetiva justificação. Em seguida, compare quanto custa expressar e gerir as regras em cada abordagem.
- Variabilidade: as permissões dependem sobretudo de responsabilidades estáveis ou mudam consoante o recurso e o respetivo estado?
- Gestão: um administrador do cliente consegue compreender e manter as atribuições sem assistência técnica constante?
- Exceções: são ocasionais e controláveis ou repetem-se até formar um segundo sistema informal de papéis?
- Auditoria: conseguem explicar por que motivo uma operação foi permitida ou recusada e reconstituir que regra foi aplicada?
- Impacto dos erros: que dados ficariam expostos ou que operação seria bloqueada se uma condição fosse configurada incorretamente?
Não compare apenas o número de papéis ou regras. Um modelo com poucos elementos pode ser difícil de compreender se os seus efeitos se combinarem de forma implícita. Avalie também a experiência de quem configura o acesso e a facilidade de responder a uma pergunta de suporte: “porque é que esta pessoa não consegue abrir este documento?”.
Sinais de excesso e de complexidade prematura
É provável que os papéis estejam a crescer em excesso quando surgem nomes quase idênticos para pequenas variações, quando cada cliente pede um papel exclusivo ou quando as condições do recurso são codificadas como exceções dentro do papel. Também é um sinal de alerta ninguém conseguir explicar a diferença entre dois perfis sem consultar o código.
Em sentido contrário, as regras contextuais podem ser prematuras se quase todos os utilizadores partilharem as mesmas permissões, não existir uma necessidade de acesso por recurso e a equipa não dispuser de dados fiáveis para avaliar atributos. Nesse cenário, construir um sistema geral de políticas acrescenta pontos de falha e custos de manutenção sem resolver um problema real.
Use estes sinais como motivo para rever o modelo, não como uma ordem automática de migração. Agrupar papéis, clarificar âmbitos ou corrigir atribuições pode ser suficiente. Se as exceções representarem diferenças legítimas e recorrentes, então vale a pena conceber regras mais explícitas.
Evoluir sem quebrar as permissões existentes
Uma evolução gradual reduz surpresas. Primeiro, inventarie as permissões atuais e descreva os casos esperados com exemplos. Separe as políticas de autorização da apresentação da interface: ocultar um botão melhora a experiência, mas não substitui a verificação no servidor sempre que a ação é executada.
- Defina uma decisão central: estabeleça como se consulta se um interveniente pode realizar uma ação sobre um recurso, evitando verificações contraditórias espalhadas pela aplicação.
- Escreva testes de acesso: abranja casos permitidos e recusados, limites entre organizações, alterações de estado e atributos em falta. Reveja também as operações de leitura e escrita.
- Compare antes de substituir: durante a transição, avalie o novo modelo em paralelo com o anterior e registe discrepâncias sem conceder acesso adicional com base nessa comparação.
- Migre por casos delimitados: transfira uma ação ou um tipo de recurso, verifique os resultados com os responsáveis pelo negócio e mantenha uma forma controlada de reverter a alteração.
- Registe as decisões relevantes: conserve informações úteis para investigar recusas ou acessos sensíveis, evitando incluir dados pessoais desnecessários nos registos.
Antes da implementação, pergunte: quem pode conceder acesso e com que âmbito? O que acontece quando uma pessoa deixa de pertencer a uma equipa? Como se comporta o sistema se faltar um atributo? Uma organização pode aceder a recursos de outra? É possível explicar e testar cada exceção? Se não houver respostas claras, o passo seguinte é especificar as regras, não acrescentar mais papéis ou condições.
Como critério prático, comece com papéis quando as responsabilidades forem estáveis e fáceis de compreender. Acrescente regras contextuais quando uma necessidade recorrente depender de recursos ou circunstâncias que os papéis não representem bem. Em ambos os casos, dê prioridade a âmbitos explícitos, à recusa segura, aos testes e a uma gestão compreensível. O melhor modelo é o mais simples que represente as decisões reais do negócio e possa ser revisto quando estas mudarem.