O que é RBAC (Controle de Acesso Baseado em Papéis)?

Controle de acesso baseado em papéis é um modelo de autorização em que permissões pertencem a papéis, e usuários só as recebem por meio de seus papéis. A indireção é a ideia inteira: nada é concedido diretamente a uma pessoa, então mudança organizacional vira mudança de dados — uma promoção é uma reatribuição de papel, não uma escavação arqueológica por grants espalhados. Proposto por Ferraiolo e Kuhn em 1992 como alternativa aos modelos discricionário e mandatório mais antigos, virou o padrão ANSI/INCITS 359 e o vocabulário default de autorização do software corporativo.

Principais pontos

Usuários, papéis, permissões — a indireção em ação

Permissões                  Papéis                   Usuários
─────────────               ─────────────            ─────────────
posts:read        ─┐
posts:write        ├──▶     Editor          ◀──────  Ada, Grace
posts:publish     ─┘
users:manage      ─┐
billing:view       ├──▶     Admin           ◀──────  Linus
posts:*           ─┘
posts:read        ────▶     Viewer          ◀──────  todos os demais

Ada publica porque Editor carrega posts:publish — reatribua o papel dela,
e toda permissão que ele carregava vai junto. Uma edição, não N.

Papéis como dados vivos, ligados às permissões de objetos:

// JavaScript / Node.js — Back4app JS SDK
// Roles as data: create a role, add members, grant through it
const roleACL = new Parse.ACL();
roleACL.setPublicReadAccess(true);
const editors = new Parse.Role('Editors', roleACL);
editors.getUsers().add(adaUser);
await editors.save();

// Grant by role, not by user — membership changes in one place
const post = new Parse.Object('Post');
const acl = new Parse.ACL(currentUser);  // owner entry
acl.setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// Flutter / Dart — Back4app Flutter SDK
// Roles as data: create a role, add members, grant through it
final roleACL = ParseACL()..setPublicReadAccess(allowed: true);
final editors = ParseObject('_Role')
  ..set('name', 'Editors')
  ..setACL(roleACL)
  ..addRelation('users', [adaUser]);
await editors.save();

// Grant by role, not by user — membership changes in one place
final post = ParseObject('Post');
final acl = ParseACL(owner: currentUser)  // owner entry
  ..setRoleWriteAccess('Editors', true);  // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// iOS / Swift — Back4app Swift SDK
// Roles as data: create a role, add members, grant through it
var editors = try ParseRole(name: "Editors")
let savedRole = try await editors.save()
try await savedRole.users.add([adaUser]).save() // membership = a relation

// Grant by role, not by user — membership changes in one place
var post = Post()
var acl = ParseACL()
acl.setReadAccess(user: currentUser, value: true)
acl.setWriteAccess(user: currentUser, value: true)   // owner entry
acl.setWriteAccess(roleName: "Editors", value: true) // RBAC meets the ACL
post.ACL = acl
try await post.save()

// Android / Kotlin — Back4app Android SDK
// Roles as data: create a role, add members, grant through it
val roleACL = ParseACL()
roleACL.publicReadAccess = true
val editors = ParseRole("Editors", roleACL)
editors.users.add(adaUser)
editors.save()

// Grant by role, not by user — membership changes in one place
val post = ParseObject("Post")
val acl = ParseACL(ParseUser.getCurrentUser()) // owner entry
acl.setRoleWriteAccess("Editors", true)        // RBAC meets the object's ACL
post.acl = acl
post.save()

O modelo NIST, do jeito certo

A maioria dos explicadores comprime o padrão em uma listinha; a estrutura real vale trinta segundos. O RBAC core define usuários, papéis, permissões — e sessions, o elemento esquecido: o usuário ativa um subconjunto dos seus papéis por session, e é assim que um admin navega com poderes de membro por padrão e escala de privilégio deliberadamente. As três regras do artigo original amarram tudo: agir só através de um papel, portar só papéis autorizados, fazer só o que o papel ativo permite. O RBAC hierárquico adiciona herança — papéis seniores englobam os juniores (Gerente ⊇ Funcionário), eliminando duplicação. O RBAC restrito adiciona separação de funções: regras estáticas proíbem de vez atribuições conflitantes (nunca criador-de-pagamento e aprovador-de-pagamento juntos); regras dinâmicas permitem a atribuição, mas proíbem ativar as duas em uma mesma session. E a clarificação mais afiada do NIST, rotineiramente distorcida: um grupo é uma coleção de usuários; um papel é uma coleção de permissões — o papel se define pelo que pode fazer, não por quem está nele.

RBAC vs. ACL vs. ABAC

O insight que a SERP dos fornecedores enterra: esses modelos se compõem, não competem. Papéis cuidam do acesso que segue a função; entradas de ACL cuidam das exceções por objeto — e a dobradiça é a ACE de papel, uma linha da ACL nomeando um role em vez de um usuário, dando controle em nível de objeto com gestão de membros em um lugar só. Condições de atributo entram por cima quando o contexto (hora, tenant, estado do registro) realmente decide. “Qual dos dois?” costuma ser a pergunta errada; “qual camada cuida de qual decisão?” é o design.

Explosão de papéis — o modo de falha

A doença característica do RBAC: cada exceção cunha um papel, e então cada projeto, região e tenant os multiplica — Gerente-Projeto-A-Regiao-Oeste-SomenteLeitura — até os papéis superarem os usuários e a resposta da auditoria a “quem pode fazer o quê?” virar “ninguém sabe”. A causa raiz é sempre a mesma: atributos contextuais codificados como papéis. As mitigações, em ordem: mantenha atributos fora dos nomes de papel (região e tenant são condições ou escopos, não papéis); trate compartilhamento por objeto com entradas de ACL, nunca com papéis por objeto; delimite papéis por tenant estruturalmente, e não por malabarismo de nomes; e audite — papéis que ninguém tem, permissões que nenhum papel usa e grants que ninguém lembra são deriva, e deriva é como o privilégio mínimo morre em silêncio. Uma heurística que funciona: se a lista de papéis não cabe mais em uma tela, o modelo está absorvendo trabalho que pertence a outra camada.

Desenhando papéis: top-down, bottom-up ou os dois

A parte que nenhum explicador ranqueado cobre: de onde os papéis vêm. O top-down os deriva da organização e dos seus processos — entreviste o negócio, nomeie as funções, atribua permissões mínimas; preciso, porém lento. O bottom-up os minera dos grants existentes — agrupe quem já tem o quê, e papéis candidatos caem no colo; rápido, mas lava erros do passado e os transforma em política. A prática é híbrida: minere candidatos, valide contra as funções e aplique o teste 80/20 — um punhado de papéis largos para o grosso da organização, exceções tratadas por ACLs ou condições em vez de papéis de butique. E uma regra de implementação que sobrevive a qualquer reorganização: o código deve verificar permissões, não nomes de papel — can('posts:publish'), não hasRole('Editor') — para que redefinir um papel seja uma mudança de dados, não um refactor, com enforcement no servidor, negando por padrão.

Casos de uso comuns

• Painéis de admin e back-offices — suporte, moderação, financeiro, superadmin: funções mapeiam limpo para papéis.
• Fluxos de conteúdo e publicação — autor, editor, publicador, com separação entre escrever e lançar.
• Permissões de time em SaaS B2B — owner/admin/membro/cobrança por workspace, delimitado por tenant.
• Operações sob compliance — separação de funções como restrição de papel aplicável, com a lista de membros como artefato de auditoria.
• O gate de papéis na camada de dados — papéis como o “quem” nas permissões em nível de classe e nas políticas por linha.

Você deveria usar RBAC? Matriz de decisão

Limitações e trade-offs

• Compartilhamento por objeto está fora do escopo. “Compartilhar este documento com a Ana” não tem resposta em RBAC que não seja um papel por documento — essa decisão pertence às ACLs.
• Mesmo papel, mesmos poderes. Dois Editores são indistinguíveis; nuance individual exige outra camada, não um papel quase-duplicado.
• Engenharia de papéis é trabalho real de fundação. Pulá-la produz papéis que não espelham nem a organização nem o modelo de risco — e são copiados para sempre.
• Papéis estáticos não veem risco dinâmico. A associação a um papel não enxerga horários incomuns, dispositivos novos ou estados sensíveis do registro; isso é território de atributos.
• Deriva é o estado estacionário. Sem recertificação periódica, o escopo dos papéis só cresce; a auditabilidade do RBAC é uma capacidade, não uma garantia.

Papéis no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Aqui os papéis são dados, não código: cada um é um objeto da classe _Role com uma relation users para os membros e uma relation roles para aninhamento — e aninhar é hierarquia de graça, já que membros de um papel filho herdam o que os papéis pais recebem. Os grants acontecem exatamente onde a seção de composição aponta: nomes de papel aparecem nas permissões em nível de classe para o traço largo e nas entradas de ACL por objeto para as exceções — as abas de código mostram as duas metades — com o Back4app aplicando o resultado em toda requisição REST, GraphQL e Live Query. Como roles são objetos consultáveis, gestão de membros, auditorias e telas de admin viram trabalho comum de banco de dados: prevenir explosão de papéis como hábito de modelagem, não como projeto de governança.