RBAC (Role-Based Access Control), ou controle de acesso baseado em funções, é o modelo em que cada pessoa recebe os acessos da função (role) que exerce na empresa, e não acessos concedidos um a um. Um analista financeiro ganha o pacote de acessos de “analista financeiro”; se muda de área, troca de pacote; se sai, perde tudo de uma vez.
Neste guia você vê como o RBAC funciona, exemplos práticos, um modelo de matriz RBAC, a diferença entre RBAC e ABAC e como implementar em 5 passos. Uma nota antes: no Brasil, RBAC também é a sigla do Regulamento Brasileiro da Aviação Civil, da ANAC. Aqui o assunto é controle de acesso em TI.
Resumo rápido
- O que é: acessos agrupados por função (role) e atribuídos a pessoas ou grupos.
- Para que serve: aplicar o princípio do menor privilégio sem gerenciar permissão por permissão.
- Matriz RBAC: a tabela que cruza funções e sistemas e diz o nível de acesso de cada função.
- RBAC x ABAC: o RBAC decide pela função; o ABAC, por atributos e contexto. Na prática, os dois se combinam.
- Onde falha: quando as funções não acompanham as mudanças do RH e quando os apps SaaS ficam fora do modelo.
O que é RBAC
RBAC é a sigla em inglês de role-based access control. Em português, controle de acesso baseado em funções (ou em papéis). A ideia é simples: em vez de decidir, pessoa por pessoa, o que cada um pode acessar, a empresa define funções e liga as permissões a elas. A pessoa herda as permissões da função que ocupa.
O modelo foi formalizado nos anos 1990 por pesquisadores do NIST, o instituto de padrões dos Estados Unidos, e virou norma americana em 2004 (ANSI INCITS 359). Hoje está em quase todo sistema corporativo: Microsoft Entra, Google Workspace, ERPs, CRMs, nuvens públicas e Kubernetes usam alguma forma de RBAC.
Os componentes do RBAC
O modelo formal tem três peças: usuários, permissões e roles. Na prática, os sistemas acrescentam uma quarta, o grupo:
- Usuários: as pessoas (e, às vezes, contas de serviço) que precisam de acesso.
- Permissões: a menor unidade de autorização, como “ver relatórios financeiros” ou “aprovar pagamento”.
- Roles (funções): agrupam permissões. Exemplos: “Analista de Financeiro”, “Admin de CRM”, “Suporte nível 1”.
- Grupos: agrupam pessoas, como “Time de Suporte”. Recebem uma ou várias roles. Os grupos dinâmicos são montados por regra (cargo, área, centro de custo) e se atualizam quando alguém muda de função.
Em uma frase: a role diz o que pode ser feito; o grupo diz quem pode fazer.
Como o RBAC funciona na prática
As permissões são organizadas em roles, e as roles são atribuídas a pessoas ou grupos. Quando uma role muda, todos que a possuem são atualizados de uma vez. Se o “Analista de Financeiro” precisa de acesso a um sistema novo, basta incluir esse acesso na role.
O RBAC se apoia em três ideias:
- Menor privilégio: cada função recebe só o necessário para o trabalho.
- Segregação de funções (SoD): combinações perigosas de acesso, como cadastrar e aprovar o mesmo pagamento, não ficam na mesma pessoa.
- Consistência: duas pessoas com a mesma função têm os mesmos acessos, e isso é fácil de provar numa auditoria.
Os quatro níveis do modelo NIST
O modelo do NIST descreve o RBAC em camadas. Saber em qual delas sua empresa está ajuda a planejar o próximo passo.
| Nível | O que acrescenta | Exemplo |
|---|---|---|
| RBAC básico (flat) | Usuários, roles e permissões | “Vendedor” acessa o CRM |
| RBAC hierárquico | Roles herdam permissões de outras | “Gerente de vendas” herda tudo de “Vendedor” e ganha aprovação de desconto |
| RBAC com restrições | Regras de segregação de funções | Quem tem “cadastrar fornecedor” não pode ter “aprovar pagamento” |
| RBAC simétrico | Revisão nos dois sentidos: o que cada role pode fazer e quais roles têm cada permissão | Descobrir quais roles dão acesso de admin no ERP |
Exemplos de RBAC
Alguns exemplos de como as roles aparecem no dia a dia:
- Financeiro: “Analista de contas a pagar” lança títulos no ERP; “Coordenador financeiro” aprova pagamentos acima de um valor; nenhuma das duas roles faz as duas coisas.
- Atendimento: “Suporte nível 1” vê tickets e dados básicos do cliente no CRM; “Suporte nível 2” também edita cadastro; só “Admin de CRM” exporta a base.
- Tecnologia: “Desenvolvedor” tem acesso de leitura em produção; “SRE” tem acesso de escrita, de preferência temporário e aprovado.
- Pessoas e RH: “Analista de DP” acessa a folha; “Gestor” vê só o próprio time no sistema de RH.
Modelo de matriz RBAC
A matriz RBAC é a tabela que cruza as funções com os sistemas e diz o nível de acesso de cada função. Ela é o documento que o auditor pede e o ponto de partida para automatizar. Um exemplo simplificado:
| Função | E-mail e Drive | CRM | ERP | Folha de pagamento | Nuvem (produção) |
|---|---|---|---|---|---|
| Vendedor | Membro | Usuário | — | — | — |
| Analista de contas a pagar | Membro | — | Lançar títulos | — | — |
| Coordenador financeiro | Membro | Leitura | Aprovar pagamentos | — | — |
| Analista de DP | Membro | — | — | Editar | — |
| Desenvolvedor | Membro | — | — | — | Leitura |
| SRE | Membro | — | — | — | Escrita (temporário, com aprovação) |
Três cuidados ao montar a sua:
- Comece pelas funções com mais pessoas. Elas cobrem a maior parte dos acessos com poucas linhas.
- Use o nível de acesso de cada sistema (membro, editor, admin), não só “tem ou não tem”.
- Marque os conflitos de segregação de funções na própria matriz, para a revisão encontrar rápido.
RBAC x ABAC: qual a diferença
O ABAC (attribute-based access control) decide o acesso por atributos da pessoa, do recurso e do contexto, como área, localização, horário ou classificação do dado. Os dois modelos costumam ser usados juntos.
| RBAC | ABAC | |
|---|---|---|
| Decide por | Função (role) da pessoa | Atributos da pessoa, do recurso e do contexto |
| Exemplo | “Analistas financeiros acessam o ERP” | “Analistas financeiros acessam o ERP em horário comercial e só dados da sua filial” |
| Implantação | Mais simples: começa com poucas roles | Mais complexa: exige atributos confiáveis e regras |
| Auditoria | Fácil de explicar e revisar | Mais difícil de revisar regra a regra |
| Melhor para | Base do controle de acesso na maioria das empresas | Exceções e cenários sensíveis ao contexto |
Na prática, muitas empresas usam grupos dinâmicos por atributo do RH (área, cargo, centro de custo) para aplicar roles automaticamente, o que junta o melhor dos dois. Outros modelos que aparecem na comparação são a ACL (lista de quem acessa cada recurso, comum em arquivos e pastas) e o PBAC (uma forma de ABAC escrita como políticas).
Como implementar RBAC em 5 passos
- Faça o inventário. Liste os sistemas e SaaS em uso e quem acessa cada um hoje, inclusive o que ninguém declarou.
- Defina as funções a partir do RH. Use cargo, área e centro de custo da folha como fonte, não planilhas paralelas.
- Monte a matriz RBAC. Para cada função, os sistemas e o nível de permissão. Comece pelas funções com mais pessoas.
- Automatize entrada, mudança e saída. A admissão aplica a role, a mudança de área troca, o desligamento remove tudo.
- Revise periodicamente. Campanhas de revisão por função ou por gestor, com evidência para o auditor.
Os desafios do RBAC em ambientes SaaS
- Explosão de roles: sem padrão, cada exceção vira uma role nova e o modelo perde o sentido.
- Acúmulo de privilégios: quem muda de área leva os acessos antigos junto (o chamado privilege creep).
- Apps fora do SSO: SaaS com contas locais ficam de fora das roles e das revisões.
- Escala: cada SaaS novo multiplica as combinações de função e permissão.
RBAC com a Niuco
Na Niuco, os grupos podem ser dinâmicos: montados por regra a partir de atributos do RH, como time, cargo e centro de custo, e recalculados a cada sincronização. Cada grupo reúne os softwares e a permissão em cada um (por exemplo, o perfil de usuário no GitHub). É a matriz RBAC mantida na própria plataforma, a partir do RH (folha de pagamento ou organograma).
Quando alguém entra num grupo, os workflows criam as contas nos softwares daquele grupo. Mudanças nos softwares de um grupo passam por aprovação e ficam no histórico do grupo. E as revisões de acesso, por software ou por gestor, registram cada decisão de manter ou revogar e geram a evidência para a auditoria. Veja como funciona a gestão de acessos e governança de identidade (IGA) da Niuco.
Perguntas frequentes sobre RBAC
O que significa RBAC?
RBAC significa role-based access control, ou controle de acesso baseado em funções. É o modelo em que os acessos são dados pela função da pessoa, e não individualmente.
O que é uma matriz RBAC?
É a tabela que cruza as funções da empresa com os sistemas e mostra o nível de acesso de cada função. Serve para documentar o modelo, revisar acessos e automatizar a concessão.
Qual a diferença entre RBAC e ABAC?
O RBAC decide pela função; o ABAC decide por atributos da pessoa, do recurso e do contexto (horário, localização, classificação do dado). O RBAC é mais simples de implantar e auditar; o ABAC cobre exceções mais finas.
Qual a diferença entre role e grupo?
A role agrupa permissões (o que pode ser feito). O grupo agrupa pessoas (quem pode fazer) e recebe uma ou várias roles.
RBAC ajuda em auditorias de segurança?
Ajuda, porque organiza o controle de acesso e o menor privilégio, que as auditorias cobram, e facilita revisar e provar quem tem acesso a quê. Sozinho, não garante conformidade: é preciso também revisão periódica e trilha de auditoria.
Como começar a implementar RBAC?
Pelo inventário dos sistemas e de quem acessa cada um. Depois, defina as funções a partir do RH, monte a matriz das funções com mais pessoas e automatize a entrada, a mudança e a saída.
