Permissões por papel (RBAC): quem pode ver e fazer o quê

No começo, o sistema tem "admin" e "usuário". Com o tempo, surgem exceções: o gerente pode aprovar descontos, o financeiro vê relatórios, o vendedor só vê os próprios clientes. Sem uma estrutura, as permissões viram if espalhados pelo código — e brechas.

RBAC: permissões por papel

Em vez de dar permissões a cada pessoa, você define papéis (vendedor, gerente, financeiro, administrador) com conjuntos de permissões (ver clientes, editar pedidos, aprovar desconto). Cada usuário recebe um ou mais papéis.

Dois níveis de controle

1. 1.O que pode fazer: criar, editar, excluir, aprovar.
2. 2.Sobre quais dados: só os próprios clientes, os da filial, os da empresa toda. Em SaaS, nunca dados de outra empresa (SaaS multi-tenant: isolando os dados de cada cliente).

Regras de ouro

• Verifique no backend, sempre. Esconder o botão no front é conveniência, não segurança.
• Negar por padrão: sem permissão explícita, sem acesso.
• Menor privilégio: cada papel com o mínimo necessário.
• Registro de ações sensíveis: quem aprovou, quem excluiu, quando.

Centralize

Uma função única de verificação (pode(usuario, 'aprovar', pedido)) é mais fácil de testar e auditar do que regras espalhadas — e se encaixa na Arquitetura em camadas no Node.js: como organizar Controllers, Services e Repositories.

Quando o RBAC não basta

Regras como "pode editar pedidos até R$ 5 mil" pedem permissões baseadas em atributos. Comece com papéis e evolua quando necessário.

Permissões são parte da LGPD na prática (LGPD para desenvolvedores: o que muda no código) e da segurança de agentes de IA (Prompt injection: o novo SQL injection).

A We Codex constrói sistemas com controle de acesso robusto. Veja Segurança Anti-Hacker ou fale com a gente.