RBAC: Níveis de Acesso no seu Projeto

RBAC, ou Role Based Access Control, é uma forma de arquitetar o sistema de login para que existam níveis de permissão diferentes dentro dele. O nome parece complicado, mas o conceito é simples de entender e dá pra aplicar em qualquer linguagem ou tecnologia, uma vez que você entende bem a lógica por trás.

Autenticação x autorização

Antes de falar de RBAC, é importante separar duas coisas que costumam ser confundidas: autenticação e autorização.

Autenticação é o processo de descobrir quem é o usuário. É quando alguém digita e-mail e senha, e o sistema confirma a identidade dessa pessoa.

Autorização é o processo de verificar se, uma vez logado, esse usuário pode acessar determinada página ou executar determinada ação. É uma verificação que acontece a cada tela, a cada clique.

Na maioria dos sistemas mais simples, essas duas etapas colapsam numa só: basta estar logado para acessar qualquer coisa. O RBAC entra exatamente para quebrar essa simplicidade e criar limites: só porque você está logado, não significa que você pode fazer tudo.

As três peças do RBAC

Para estruturar o RBAC, existem três conceitos que precisam ficar bem separados na sua cabeça:

Permissões: o que pode ser feito no sistema.
Funções (roles): grupos de permissões.
Usuários: pessoas que recebem uma ou mais funções.

Permissões

Permissões são divididas, de forma geral, em dois tipos: permissões de acesso (visualizar algo) e permissões de ação (adicionar, editar, deletar algo).

Pegando como exemplo um sistema de controle de estoque, as permissões relacionadas a produto poderiam ser:

produto:visualizar
produto:adicionar
produto:editar
produto:deletar

Dá pra ir tão fundo quanto o sistema precisar. É possível, por exemplo, ter uma permissão para visualizar informações básicas do produto e outra separada para visualizar dados mais sensíveis, como quantidade em estoque ou previsão de reposição. Esse processo de detalhar cada vez mais as permissões se chama granularização.

Funções

Uma função é literalmente um grupo de permissões com um nome. Em vez de atribuir permissões uma por uma para cada usuário, você cria uma função, associa as permissões que fazem sentido para ela, e depois atribui essa função ao usuário.

Usando o exemplo de um sistema de estoque:

Função	Permissões
Balcão	visualizar produto
Gerente	visualizar produto, editar produto
Dono	visualizar, adicionar, editar e deletar produto

Quem tem a função de balcão só consegue ver os produtos. Quem é gerente, além de ver, consegue editar. E o dono consegue fazer qualquer coisa.

Usuários

O usuário, por fim, recebe uma função (ou mais de uma, dependendo de como o sistema é desenhado). A partir da função atribuída, ele herda automaticamente as permissões daquela função.

Isso é o que torna o modelo prático de manter. Se um usuário que era gerente for rebaixado para balcão, você não precisa mexer nas permissões dele uma por uma. Basta trocar a função associada, e as permissões mudam junto.

Como isso aparece no código

Na prática, ao longo do sistema, você vai verificar constantemente se o usuário logado tem determinada permissão antes de mostrar algo ou executar alguma ação:

if (usuario.temPermissao("produto:editar")) {
  mostrarBotaoEditar();
}

O mesmo tipo de verificação se repete para decidir se uma página pode ser acessada, se um botão aparece na tela, ou se uma ação pode ser executada.

O ponto que mais gera falha de segurança

Aqui está o detalhe mais importante do artigo inteiro: a verificação de permissão precisa acontecer em todas as camadas do processo, não só numa delas.

Pega como exemplo o fluxo de adicionar um produto novo. Ele passa por, no mínimo, três pontos:

O botão que leva até a tela de adicionar produto.
A própria tela, com o formulário de cadastro.
O backend, que recebe os dados e efetivamente salva o produto.

Se você verificar a permissão só no botão, um usuário que descobrir a URL da tela de cadastro (por exemplo, pegando o link com um colega que tem acesso) consegue acessar a tela mesmo sem permissão, já que nada ali dentro barra ele.

Se você verificar no botão e na tela, mas esquecer do backend, um usuário mais técnico consegue simular a requisição diretamente para a rota que salva o produto, ignorando completamente a interface. Sem checagem no backend, o dado é salvo do mesmo jeito.

Por isso a regra é simples e não tem atalho: toda camada do sistema, do front ao back, precisa checar a permissão de forma independente. Isso vale ainda mais para ações que alteram dado (adicionar, editar, deletar) do que para as que só leem, porque um vazamento de leitura é ruim, mas um dado corrompido ou apagado por alguém sem permissão é bem mais grave.

Resumindo

RBAC é, no fundo, uma tabela de relacionamento entre três coisas: permissões, funções e usuários. Você define o que pode ser feito no sistema, agrupa essas ações em funções com nomes que fazem sentido para o seu negócio (balcão, gerente, dono, ou o que for), e atribui essas funções aos usuários.

A parte teórica é simples. A parte que exige atenção de verdade é lembrar de verificar a permissão em cada etapa do fluxo, sem confiar que travar só uma camada é suficiente.