Permissoes, Roles e Acesso por Recurso

O problema

Tem sistema que tenta resolver autorização com uma pergunta só:

“Esse usuário e admin?”

As vezes isso basta.

Muitas vezes, não.

Porque acesso real costuma depender de mais coisa:

• que ação esta sendo feita
• sobre qual recurso
• em qual tenant
• em qual estado do objeto

Quando tudo vira role genérica, a regra fica fácil de escrever e fácil de quebrar depois.

Modelo mental

Pense assim:

• role agrupa permissoes
• permissao representa capacidade
• autorização decide acesso num caso concreto

Ou, em termos mais práticos:

role ajuda a organizar. O backend ainda precisa decidir se aquela identidade pode executar aquela ação naquele recurso.

Essa ultima parte e a que separa um sistema simples de um sistema simplista.

Quebrando o problema

Role e atalho, não verdade final

admin, editor, viewer.

Esses nomes sao uteis para agrupar comportamento.

O problema começa quando a role passa a ser tratada como explicação completa de tudo.

admin de qual tenant? editor de qual projeto? viewer de qual recurso?

Sem esse contexto, a regra fica frouxa.

Acesso por recurso deixa a decisão mais honesta

Muita autorização real se parece mais com isto:

• usuário pode editar pedido se for do time certo
• usuário pode ver documento se pertencer ao tenant dono
• usuário pode cancelar transação só enquanto ela estiver pendente

Perceba que a regra depende de:

• identidade
• recurso
• estado
• contexto

Não só de um nome bonito de papel.

Permissao boa fala a linguagem da ação

Em vez de pensar só em cargo, vale pensar em operações:

• invoice:read
• invoice:update
• user:delete

Isso deixa a conversa sobre acesso mais clara.

Depois você pode agrupar essas capacidades em roles, se fizer sentido.

Não deixe a UI decidir sozinha

Se o frontend escondeu um botao, isso melhora UX.

Não prova acesso.

O backend ainda precisa validar a regra no recurso concreto.

Exemplo simples

Imagine um sistema B2B com vários tenants.

Você cria a role manager.

Tudo parece resolvido até a pergunta certa aparecer:

um manager pode editar qualquer pedido de qualquer tenant?

Se a resposta correta e “não, só do tenant dele”, entao a role sozinha não basta.

A autorização precisa verificar:

• identidade do usuário
• tenant do usuário
• tenant do pedido
• ação solicitada

Agora a regra fica menos elegante no quadro.

E bem mais correta no sistema.

Erros comuns

• Tratar role como resposta completa para qualquer caso.
• Usar isAdmin como atalho para driblar modelagem de acesso.
• Ignorar recurso e contexto na decisão.
• Espalhar regra de autorização pela UI inteira.
• Misturar permissao de negócio com conveniencia técnica.

Como um senior pensa

Quem tem mais experiência costuma desconfiar de regra ampla demais.

O raciocínio geralmente e:

“Antes de decidir acesso, eu quero saber sobre qual recurso estamos falando e qual contexto faz essa decisão mudar. Se a role não carrega isso sozinha, a regra precisa olhar mais fundo.”

Essa postura evita tanto permissao excessiva quanto modelo ingovernavel.

O que o entrevistador quer ver

Em entrevista, esse tema mede maturidade de autorização.

O avaliador quer ver se você:

• não depende só de role genérica
• entende acesso por recurso
• pensa em contexto e escopo
• consegue modelar regra sem teatro de RBAC

Uma resposta forte costuma soar assim:

“Eu uso role como agrupamento, mas a decisão final de autorização costuma depender da ação e do recurso concreto. Em sistema multi-tenant, por exemplo, não basta saber que o usuário e manager; eu preciso saber se ele pode agir sobre aquele recurso específico.”

Role organiza. Recurso decide.

Quanto mais real a regra de negócio, menos ela cabe inteira dentro de um isAdmin.