--- term: 'Controle de Acesso Baseado em Papéis (RBAC)' seoTitle: 'RBAC Explicado: Papéis, Modelo NIST, Explosão de Papéis' headline: 'O que é RBAC (Controle de Acesso Baseado em Papéis)?' slug: controle-de-acesso-rbac category: auth-security shortDefinition: '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.' relatedTerms: - access-control-lists-acl - class-level-permissions-clp - identity-access-management-iam - row-level-security contrastsWith: - access-control-lists-acl aboutTerms: - 'Hierarquia de Papéis' - 'Separação de Funções' - 'Explosão de Papéis' faq: - question: 'O que é RBAC em termos simples?' answer: 'O acesso é concedido por função de trabalho, não por pessoa: as permissões pertencem a papéis — Editor, Admin, Suporte — e os usuários herdam o que seus papéis atribuídos carregam. Contratação, promoção e desligamento viram mudanças de papel em um lugar só, em vez de edições de permissão espalhadas por todo canto.' - question: 'Qual a diferença entre RBAC e ABAC?' answer: 'O RBAC decide a partir de papéis predefinidos; o controle baseado em atributos (ABAC) avalia atributos do usuário, do recurso e do contexto — departamento, sensibilidade, horário — no momento da requisição. RBAC é mais simples de entender e auditar; ABAC é mais fino e mais difícil de depurar. Sistemas maduros usam RBAC como base e adicionam condições de atributo onde o contexto realmente importa.' - question: 'Qual a diferença entre RBAC e ACL?' answer: 'A direção do vínculo: a ACL pendura entradas sujeito-permissão em cada objeto; o RBAC pendura permissões em papéis, valendo pelo sistema inteiro. Eles se compõem em vez de competir — uma entrada de ACL pode nomear um papel, e é assim que controle por objeto e gestão de membros em um lugar só coexistem.' - question: 'Quais são os modelos de RBAC?' answer: 'O padrão define o RBAC core (usuários, papéis, permissões, sessions), o RBAC hierárquico (papéis seniores herdam as permissões dos juniores) e o RBAC restrito (regras de separação de funções — restrições estáticas na atribuição, restrições dinâmicas sobre o que uma session pode ativar ao mesmo tempo).' - question: 'Quais são as três regras do RBAC?' answer: 'Da formulação original de 1992: um sujeito só age por meio de um papel selecionado (atribuição de papel); o sujeito precisa estar autorizado para aquele papel (autorização de papel); e uma ação só é permitida se o papel ativo tiver a permissão dela (autorização de permissão). Em resumo: nenhum acesso, exceto através de papéis.' - question: 'O que é explosão de papéis (role explosion)?' answer: 'O crescimento descontrolado quando cada exceção, projeto, região ou tenant gera um papel novo — Gerente-Projeto-A-Região-Oeste — até que os papéis superem os usuários em número e ninguém consiga auditar o sistema. A causa raiz é codificar atributos contextuais como papéis, em vez de tratá-los com condições ou entradas por objeto.' - question: 'RBAC é o mesmo que privilégio mínimo?' answer: 'Não — privilégio mínimo é o princípio, RBAC é um mecanismo para persegui-lo, e só a disciplina nos papéis conecta os dois. Um papel largo demais viola o privilégio mínimo por dentro do RBAC; delimitar papéis ao mínimo e revisá-los periodicamente é o que entrega o princípio de fato.' - question: 'O que é separação de funções no RBAC?' answer: 'Restrições que mantêm poderes conflitantes afastados: a separação estática impede que um usuário jamais acumule criador-de-pagamento e aprovador-de-pagamento; a dinâmica permite acumular, mas nunca ativar os dois na mesma session. É prevenção de fraude expressa como regra de papéis.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'NIST Role-Based Access Control project' url: 'https://csrc.nist.gov/projects/role-based-access-control' - name: 'Ferraiolo & Kuhn — Role-Based Access Control (1992)' url: 'https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf' - name: 'NISTIR 7316 — Assessment of Access Control Systems' url: 'https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7316.pdf' - name: 'OWASP Authorization Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html' cta: title: 'Papéis que você pode consultar' text: 'No Back4app, roles são objetos do banco: adicione membros com uma relation, aninhe papéis para ter hierarquia e conceda acesso via permissões de classe e ACLs de objeto — RBAC aplicado pela plataforma em toda requisição.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: role-based-access-control-rbac --- **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](https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf) 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 | Pergunta | Resposta | | --- | --- | | A indireção | Usuário → papel → permissão — nunca usuário → permissão direto | | Papel ≠ grupo | Um grupo coleciona *usuários*; um papel coleciona *permissões* | | Os níveis do modelo | Core · hierárquico (herança) · restrito (separação de funções) | | O modo de falha | Explosão de papéis — atributos virando papéis até os papéis superarem os usuários | | A composição | Papéis dentro de entradas de ACL: RBAC para a massa, ACLs para as exceções | ## Usuários, papéis, permissões — a indireção em ação ```text 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:** ```javascript // 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 // 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(); ``` **Swift:** ```swift // 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() ``` **Kotlin:** ```kotlin // 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. ```mermaid flowchart LR accTitle: Estrutura do RBAC com sessions e separação de funções accDescr: Usuários recebem papéis e ativam um subconjunto deles por session. Papéis carregam permissões e podem herdar de papéis juniores. Restrições de separação de funções limitam quais papéis podem ser atribuídos ou ativados juntos, e as permissões se aplicam a recursos. U["Usuário
Ada"] -->|"atribuídos"| R["Papéis
Editor · Auditor"] U -->|"ativa um subconjunto
por session"| S["Session
só Editor"] R -->|"herda"| RJ["Papel júnior
Viewer"] R ---|"restrição de SoD:
não junto com Approver"| X["Papel conflitante"] S -->|"permissões dos
papéis ativos"| P["posts:write
posts:publish"] --> D[("Recursos")] ``` ## RBAC vs. ACL vs. ABAC | | RBAC | [ACL](/glossary/pt/listas-de-controle-de-acesso-acl/) | ABAC | | --- | --- | --- | --- | | Permissões vinculadas a | Papéis | Cada objeto | Regras de atributo | | Pergunta nativa | O que esta *função* pode fazer? | Quem pode tocar *neste objeto*? | Isto é permitido *neste contexto*? | | Administração | Um lugar por papel | Por objeto | Por política | | Compartilhamento por objeto | Não consegue expressar | O jogo em casa dela | Expressável, verboso | | Auditar "o que a Ada pode fazer?" | Leia os papéis dela | Varra todos os objetos | Avalie todas as regras | | Modo de falha | Explosão de papéis | Proliferação de listas | Políticas opacas | 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](/glossary/pt/listas-de-controle-de-acesso-acl/), nunca com papéis por objeto; delimite papéis por [tenant](/glossary/tenant-isolation/) 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](/glossary/data-layer-vs-application-layer-security/), 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](/glossary/pt/permissoes-de-classe-clp/) e nas [políticas por linha](/glossary/pt/seguranca-em-nivel-de-linha/). ## Você deveria usar RBAC? Matriz de decisão | Situação | Tendência | | --- | --- | | O acesso segue a função de trabalho | RBAC — o jogo em casa dele | | Usuários compartilham registros individuais ad hoc | ACLs — papéis não expressam isso | | O contexto decide (hora, estado, tenant) | Condições de atributo sobre os papéis | | Poucos tipos de usuário, estáveis | RBAC com 3–7 papéis largos | | Organogramas profundos, times aninhados | Hierarquia de papéis — ou ReBAC em escala de verdade | | "Só admins e todo o resto" | Um gate de papel — não modele além disso | ## 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](/glossary/pt/permissoes-de-classe-clp/) para o traço largo e nas [entradas de ACL](/glossary/pt/listas-de-controle-de-acesso-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.