ANÚNCIO

~/questoes/programacao

O que é RBAC (Role-Based Access Control) em um sistema de autenticação?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Aula de referência Nest.js e API REST: Autenticação e Autorização na Prática
Para fixar

RBAC: Controle de Acesso Baseado em Papéis

Conceito central

RBAC (Role-Based Access Control) é um modelo de autorização que organiza as permissões do sistema através de papéis (roles) como admin, user e guest. Em vez de atribuir permissões individuais a cada usuário, você define o que cada papel pode fazer, e depois associa os usuários a esses papéis. Isso torna o gerenciamento de permissões muito mais simples e escalável.

Por que essa resposta faz sentido

A resposta correta define RBAC como um sistema que controla permissões através de papéis. Isso está alinhado com a verdadeira função do RBAC: criar uma estrutura de autorização flexível onde diferentes grupos de usuários (papéis) possuem diferentes níveis de acesso conforme seus papéis no sistema.

Armadilhas comuns

  • Confundir RBAC com autenticação: RBAC é autorização (o que você pode fazer), não autenticação (quem você é).
  • Pensar que RBAC substitui hashing de senhas: os dois trabalham juntos, mas endereçam problemas diferentes.
  • Achar que RBAC é complexo demais: na prática, é muito mais simples gerenciar 3 ou 4 papéis do que permissões individuais para 1000 usuários.

Entenda as alternativas

A

Essa alternativa descreve corretamente o RBAC. O sistema define papéis (admin, user, guest) e atribui permissões a cada papel, não a usuários individuais. Quando um usuário recebe um papel, herda automaticamente todas as permissões daquele papel.

B

Essa alternativa confunde RBAC com criptografia. RBAC não é um protocolo de criptografia e não substitui o hashing de senhas. Hashing de senhas e RBAC são conceitos separados que trabalham juntos em um sistema de autenticação robusto.

C

Essa alternativa descreve algo semelhante a um sistema de backup ou cache de tokens, não RBAC. RBAC não armazena cópias de tokens; ele apenas define regras sobre quem pode acessar o quê dentro da aplicação.

D

Essa alternativa mistura conceitos de segurança de senhas (salting) com armazenamento de tokens. RBAC não é um padrão de salting e não está relacionado a como tokens são armazenados no banco de dados.

Dica prática: No Nest.js, implemente RBAC criando um enum com os papéis (ADMIN, USER, GUEST) e um decorator customizado como @Roles('admin') nas rotas que precisam proteção. Um guard valida o papel do usuário no token JWT antes de permitir acesso à rota.

Revise pensando: Se você tem 1000 usuários em sua aplicação e precisa mudar as permissões do papel 'moderador', quantas operações de banco de dados você faria com RBAC comparado a permissões individuais?