O controle de acesso baseado em funções (RBAC) é um modelo de autorização dentro do IAM que define quem pode acessar quais recursos no seu aplicativo.

O RBAC aborda a questão essencial da autorização: "O que este usuário autenticado pode fazer?". Em vez de atribuir permissões individuais a cada usuário, você agrupa as permissões em funções. Atribua uma ou mais funções aos usuários, cada uma concedendo um conjunto definido de permissões. Essa abordagem simplifica o gerenciamento de usuários, aumenta a segurança e se adapta bem aos aplicativos modernos.

O modelo RBAC é definido pelo relacionamento entre usuários, funções e permissões.

• Usuário: uma pessoa física ou jurídica autenticada que busca acesso a um sistema.
• Permissão (ou privilégio): o direito granular de realizar uma ação específica em um recurso.
  Expresse as permissões como um par ação/recurso:
  • read:Patients
  • update:Settings
  • delete:Posts
• Função: um conjunto de permissões que define uma função ou um nível de acesso específico dentro do aplicativo (um único usuário pode ter várias funções).

Como funciona o RBAC?

Implemente o RBAC em três etapas lógicas:

1. Defina as permissões: determine o nível mais baixo de ações que um usuário pode realizar no aplicativo (por exemplo, create, read, update, delete para um determinado recurso).
2. Atribua permissões a funções: agrupe as permissões em funções lógicas (por exemplo, a função “Administrador” pode ter todas as permissões, enquanto a função “Visualizador” possui apenas permissões read).
3. Atribua funções aos usuários: conceda ao usuário as funções que se alinham às responsabilidades deles.

Quando um usuário inicia o acesso a um recurso, o sistema verifica as funções atribuídas a ele para determinar se, coletivamente, a pessoa possui as permissões necessárias.

O RBAC proporciona um equilíbrio entre simplicidade e segurança para aplicativos baseados em API.

• Gerenciamento simplificado: em vez de gerenciar permissões para milhares de usuários individuais, você gerencia um conjunto menor de funções. A alteração da permissão de uma função atualiza o acesso para todos os usuários atribuídos imediatamente.
• Clareza e auditabilidade: as funções do RBAC fornecem um mapeamento de privilégios de acesso legível por humanos e aplicável por máquina, facilitando a auditoria e o cumprimento do princípio de segurança do menor privilégio.
• Escalabilidade: à medida que um aplicativo cresce, faça a integração de novos usuários atribuindo funções existentes a eles, em vez de criar conjuntos de permissões novos e complexos.

Considere uma API típica de back-end de comércio eletrônico com os principais recursos: Produtos, Pedidos, Clientes e Análise.

Função, permissões e exemplos de usuários

Quando Priya (Gerente de Inventário) tenta:

• Visualizar uma lista de produtos: o acesso é concedido porque a função de Gerente de Inventário inclui a permissão read:Products.
• Editar a descrição de um produto: o acesso é concedido porque a função de Gerente de Inventário inclui a permissão update:Products.
• Visualizar dados pessoais de um cliente: o acesso é negado porque a função de Gerente de Inventário não inclui a permissão read:Customers.

Esse exemplo ilustra como as permissões são herdadas automaticamente pela função, oferecendo controle de acesso refinado sem exigir um mapeamento direto das permissões dos usuários.

Em plataformas de SaaS B2B, em que várias organizações de clientes compartilham a mesma infraestrutura de aplicativos, o RBAC passa a ter escopos por organização. Um usuário pode desempenhar funções diferentes em organizações diferentes.

Quando um usuário se autentica, o sistema de autorização deve avaliar não apenas "Qual é a função do usuário?", mas também "Qual é a função do usuário nesta organização específica?". O JWT inclui a identidade do usuário e um identificador da organização, garantindo a aplicação das permissões baseadas em função dentro do limite correto do locatário. Isso evita a elevação de privilégios entre organizações de clientes e mantém um isolamento rigoroso de dados em arquiteturas multilocatárias.

Embora o RBAC funcione bem para a maioria dos aplicativos, outros modelos de AuthZ podem ser mais adequados para cenários mais complexos.

O RBAC fornece uma autorização robusta para a maioria dos aplicativos, especialmente quando as permissões dos usuários estão alinhadas com as funções organizacionais definidas. Para a maioria dos aplicativos de SaaS B2B, o RBAC (potencialmente aprimorado com verificações básicas de atributos) fornece controle de acesso suficiente sem complexidade desnecessária.

No entanto, o RBAC atinge seus limites quando as decisões de acesso exigem um contexto que as funções, por si só, não conseguem capturar. Caso seja necessário impor regras como “os usuários só podem editar documentos que eles mesmos criaram” ou “o acesso é restrito fora do horário comercial”, esses cenários envolvem relacionamentos com recursos ou atributos ambientais específicos. Nesses casos, os modelos ABAC ou ReBAC tornam-se necessários para evitar a criação de soluções alternativas complexas a partir do RBAC.

Nas arquiteturas modernas baseadas em API, os tokens de acesso impõem RBAC. Proteja suas APIs usando protocolos como OAuth 2.0 e OpenID Connect (OIDC). (No OAuth 2.0, os escopos representam permissões; traduza as funções em escopos ou reivindicações personalizadas dependendo da implementação do IdP.)

1. Autenticação (AuthN): o usuário faz login com um provedor de identidade (IdP).
2. Mapeamento de autorização: o IdP determina as funções do usuário e as permissões correspondentes com base no modelo de RBAC definido.
3. Emissão de token: o IdP gera um token de acesso JSON Web Token (JWT). A carga do JWT contém declarações, como funções, escopos ou atributos personalizados, que as APIs downstream usam para impor o RBAC.
4. Aplicação da API (AuthZ): quando o usuário faz uma chamada de API, a API de back-end valida o JWT. Em seguida, ela verifica as declarações de funções/permissões dentro do token para aplicar as regras de RBAC antes de conceder acesso a um recurso ou ação.

Essa abordagem baseada em token torna a API sem estado. Os dados de autorização necessários estão contidos no próprio token e são assinados criptograficamente.

Embora os JWTs ofereçam uma maneira escalável e sem estado de aplicar o RBAC carregando dados de função e permissão no token de acesso, siga estas práticas de segurança para evitar vulnerabilidades:

• Princípio do menor privilégio: atribua apenas as funções e permissões mínimas necessárias para a função de trabalho de um usuário.
• Tempo de vida e revogação do token: os tokens de acesso JWT são difíceis de revogar de forma imediata porque são validados localmente.
  • Recomendação: use tokens de acesso de curta duração (por exemplo, 15 a 60 minutos) e rotacione os tokens de atualização.
• Validação no servidor: valide cada JWT em cada solicitação, incluindo:
  • Integridade: verifique a assinatura do token.
  • Expiração: verifique a declaração exp.
  • Público: confirme se a declaração aud corresponde ao seu aplicativo.
  • Autoridade: verifique se a declaração iss corresponde ao emissor esperado.
  • Rotação de chaves: valide os tokens em relação ao JSON Web Key Set (JWKS) do IdP para possibilitar a rotação de chaves e manter a integridade da assinatura.
• Armazenamento de funções e permissões: inclua apenas as declarações de funções e permissões necessárias. Evite dados pessoais sensíveis.
• Armazenamento de tokens: nunca armazene tokens sensíveis em localStorage ou sessionStorage, pois isso pode levar a ataques de Cross-Site Scripting (XSS). Use cookies HttpOnly ou armazenamento de sessão no back-end.
• Lide com os erros de forma clara: quando a API receber uma solicitação, retorne códigos de status HTTP específicos com base no tipo de falha:
  • 401 Não autorizado: o usuário não conseguiu comprovar sua identidade (falha na autenticação — por exemplo, token ausente ou inválido).
  • 403 Proibido: a identidade do usuário é conhecida (autenticado), mas suas funções/permissões (RBAC) negam o acesso ao recurso ou à ação solicitada (falha de autorização).

Qual é o principal benefício do RBAC?

O RBAC permite um gerenciamento de usuários mais simples e uma melhor auditabilidade. Você gerencia um pequeno conjunto de funções em vez de uma matriz grande e complexa de permissões de usuários individuais.

O RBAC é um modelo de segurança robusto?

Sim, o RBAC é um modelo de autorização robusto e fundamental para aplicativos, onde as funções e permissões dos usuários são estáticas e previsíveis.

O RBAC trata de acesso condicional?

Não. Para acesso condicional baseado em fatores como hora, localização ou valor do recurso, utilize o controle de acesso baseado em atributos (ABAC). O RBAC concentra-se na função atribuída ao usuário.

O RBAC é um modelo excelente para controle de acesso, mas é apenas um componente de uma estratégia completa de gerenciamento de identidade e acesso. Explore nossa série Introdução ao IAM para mais informações sobre tópicos relacionados ao gerenciamento de identidade e acesso.

Saiba mais

Este material destina-se apenas a fins informativos gerais. Você é responsável por obter aconselhamento sobre segurança, privacidade, conformidade ou negócios de seus próprios consultores profissionais e não deve confiar exclusivamente nas informações aqui fornecidas.