RBAC e ABAC: Os modelos de controle de acesso que você deve conhecer

Introdução#

Controle de acesso é um aspecto crítico de segurança em qualquer sistema. Ele garante que apenas usuários autorizados possam acessar recursos e executar ações. Controle de acesso baseado em funções (RBAC) e controle de acesso baseado em atributos (ABAC) são dois dos modelos de controle de acesso mais populares utilizados em sistemas modernos. Ambos os modelos são amplamente adotados e podem ser usados para aplicar políticas de controle de acesso de forma eficaz. Mas o que são eles e como diferem?

Controle de acesso baseado em funções (RBAC)#

Controle de acesso baseado em funções (RBAC) foi introduzido pela primeira vez no início dos anos 1990. A formalização do modelo é creditada a David Ferraiolo e Rick Kuhn em um artigo publicado em 1992. Desde então, o RBAC se tornou um dos modelos de controle de acesso mais amplamente usados na indústria.

No RBAC, as políticas de controle de acesso são baseadas em funções, que são coleções de permissões. Os usuários são atribuídos a funções (por exemplo, administrador, editor, visualizador), e seus direitos de acesso são determinados pelas permissões (por exemplo, criar, editar, excluir) para recursos específicos (por exemplo, arquivos, bancos de dados, aplicações). Isso simplifica o gerenciamento de políticas de controle de acesso agrupando usuários com base em suas funções e atribuindo permissões a funções. É simples adicionar ou remover usuários de funções, e as mudanças serão refletidas automaticamente nas políticas de controle de acesso.

Componentes principais do RBAC#

• Recurso: Um recurso é uma entidade que um usuário pode acessar. Recursos podem ser qualquer coisa, desde arquivos, bancos de dados, APIs ou qualquer outra entidade do sistema que precisa ser protegida.
• Permissão: Uma permissão é uma ação específica que um usuário pode realizar em um recurso. Por exemplo, criar, editar, excluir, visualizar. A definição de permissões pode variar dependendo do sistema. Na maioria dos casos, as permissões são definidas no nível do recurso com uma granularidade mínima.
• Função: Uma função é uma coleção de permissões que define um conjunto de ações que um usuário pode realizar. Por exemplo, uma função de administrador pode ter permissões para criar, editar e excluir recursos, enquanto uma função de visualizador pode ter permissão para visualizar recursos.
• Usuário: Um usuário é uma entidade que pode ser atribuída a uma ou mais funções. Os usuários recebem acesso a recursos com base nas permissões associadas às funções às quais estão atribuídos.

Variantes do RBAC#

Existem várias variantes do RBAC que estendem o modelo básico para acomodar requisitos de controle de acesso mais complexos:

• RBAC0: O modelo básico em que os usuários são atribuídos a funções e as funções são atribuídas a permissões.
• RBAC1: Adiciona o conceito de hierarquias de funções. As funções podem herdar permissões de outras funções. Também é conhecido como RBAC hierárquico.
• RBAC2: Adiciona restrições às funções. Restrições podem ser usadas para definir condições adicionais que devem ser satisfeitas para que um usuário seja atribuído a uma função. Também é conhecido como RBAC baseado em restrições.
• RBAC3: Combina os recursos do RBAC1 e RBAC2. Suporta tanto hierarquias de funções quanto restrições.

Para mais informações sobre essas variantes, consulte Modelos RBAC e sua evolução.

Prós do RBAC#

• Simplicidade: O RBAC é fácil de entender e implementar. Atribuir permissões a funções e funções a usuários é direto.
• Eficiência: Simplifica o gerenciamento de políticas de controle de acesso ao agrupar usuários com base em suas funções. É fácil adicionar ou remover usuários de funções sem alterar as políticas de controle de acesso. Especialmente em grandes organizações com estruturas de permissões bem definidas, o RBAC pode ser muito eficiente.
• Transparência: O RBAC fornece um mapeamento claro entre funções, permissões e usuários. É fácil auditar e revisar políticas de controle de acesso.

Contras do RBAC#

• Rigidez: O RBAC pode ser rígido ao definir políticas de controle de acesso complexas. Pode não ser adequado para sistemas onde as políticas de controle de acesso precisam ser mais dinâmicas e sensíveis ao contexto.
• Granularidade: O RBAC pode não ter a granularidade necessária para um controle de acesso refinado. As políticas de controle de acesso estão vinculadas a funções bem definidas e pode ser necessário um esforço extra para definir permissões em um nível mais granular.
• Explosão de funções: Em grandes organizações com estruturas de permissões complexas, o número de funções pode crescer exponencialmente, levando a uma explosão de funções. Gerenciar um grande número de funções pode ser desafiador.

Controle de acesso baseado em atributos (ABAC)#

No final dos anos 2000, à medida que os sistemas se tornaram mais complexos e dinâmicos, mais e mais organizações começaram a adotar controle de acesso baseado em atributos (ABAC) como uma alternativa ao RBAC. Um marco notável na formalização do ABAC é a publicação da NIST Special Publication 800-162 em 2014.

O ABAC é um modelo de controle de acesso mais flexível em comparação ao RBAC. É um modelo de autorização que define políticas de controle de acesso com base nos atributos do usuário, recurso, ação e ambiente. Permite que as organizações definam políticas de controle de acesso detalhadas que possam se adaptar a diferentes contextos e condições.

Componentes principais do ABAC#

• Sujeito: Um sujeito é uma entidade que solicita acesso a um recurso. Pode ser um usuário, um dispositivo, uma aplicação ou qualquer outra entidade que precise acessar recursos.
• Recurso: Assim como no RBAC, um recurso é uma entidade que um sujeito pode acessar. Recursos podem ser arquivos, bancos de dados, APIs ou qualquer outra entidade do sistema.
• Ação: Uma ação é uma operação específica que um sujeito pode realizar em um recurso. Pode ser criar, ler, atualizar, excluir ou qualquer outra operação que precise ser controlada.
• Ambiente: O ambiente é o contexto em que a solicitação de acesso é feita. Pode incluir atributos como hora do dia, localização, rede, dispositivo, etc.
• Atributo: Um atributo é uma característica de um sujeito, recurso, ação ou ambiente. Atributos podem ser qualquer coisa, desde funções do usuário, departamento, localização, endereço IP, tipo de dispositivo, etc.
• Política: Uma política é uma regra que define as condições sob as quais o acesso é concedido ou negado. As políticas são definidas com base nos atributos.

Prós do ABAC#

• Flexibilidade: O ABAC pode acomodar políticas de controle de acesso complexas baseadas em múltiplos atributos. Permite que as organizações definam políticas detalhadas que possam se adaptar a diferentes contextos e condições.
• Dinâmico: As políticas do ABAC podem ser dinâmicas e sensíveis ao contexto. As decisões de controle de acesso podem ser feitas com base em atributos em tempo real, como localização, hora do dia, tipo de dispositivo, etc.
• Granularidade: O ABAC fornece controle de acesso refinado, permitindo que as organizações definam políticas com base em múltiplos atributos. Ao contrário de definir funções e permissões, as políticas baseadas em atributos podem ser mais granulares.

Contras do ABAC#

• Complexidade: O ABAC pode ser mais complexo de implementar e gerenciar em comparação ao RBAC. Definir atributos e políticas pode exigir mais esforço e expertise. Ao contrário do RBAC, onde funções e permissões são bem estruturadas, os atributos podem ser mais dinâmicos e assim, as políticas. Gerenciar um grande número de atributos e políticas em um sistema complexo pode ser um desafio. Um motor centralizado de avaliação de políticas é frequentemente necessário para avaliar as políticas.
• Desempenho: A avaliação de atributos pode impactar no desempenho, especialmente em ambientes em tempo real. Políticas baseadas em múltiplos atributos e condições em tempo real podem introduzir latência nas decisões de controle de acesso.

Tabela de comparação#

A partir da tabela de comparação, fica claro que o RBAC é mais adequado para sistemas com estruturas de permissões bem definidas e onde as políticas de controle de acesso são relativamente estáticas. Por outro lado, o ABAC é mais adequado para sistemas onde as políticas de controle de acesso precisam ser dinâmicas, sensíveis ao contexto e granulares.

Exemplos#

Cenário: Um sistema hospitalar que precisa gerenciar o acesso a registros de pacientes para diferentes membros da equipe.

• Equipe: Médicos, Enfermeiros, Administradores
• Recursos: Registros de pacientes
• Permissões: Ler, Escrever, Excluir

Caso 1#

As políticas de controle de acesso são relativamente simples:

1. Médicos podem ler e escrever registros de pacientes.
2. Enfermeiros podem ler registros de pacientes.
3. Administradores podem ler, escrever e excluir registros de pacientes.

Modelo RBAC#

Neste caso, o RBAC é simples e eficaz. Podemos definir funções para médicos, enfermeiros e administradores, e atribuir as permissões apropriadas a cada função.

A avaliação de controle de acesso é direta:

• GET /registros-de-pacientes: user.permission.includes('read')
• POST /registros-de-pacientes: user.permission.includes('write')
• DELETE /registros-de-pacientes: user.permission.includes('delete')

Modelo ABAC#

Neste caso, o ABAC pode ser exagero, mas ainda pode ser usado para definir políticas detalhadas baseadas em atributos, como departamento, função, etc.

Atributos:

• user.role: médico, enfermeiro, admin
• resource.name: registro-de-paciente
• action: ler, escrever, excluir

Políticas:

• Política 1: Permitir acesso de leitura baseado em user.role e resource.name
  • sujeito: Usuário com função médico, enfermeiro, admin
  • recurso: Recurso com nome registro-de-paciente
  • ação: ler
  • efeito: permitir
  • racional: "Permitir acesso de leitura a registros de pacientes para todas as funções"
• Política 2: Acesso de edição para médicos e admins
  • sujeito: Usuário com função médico, admin
  • recurso: Recurso com nome registro-de-paciente
  • ação: escrever
  • efeito: permitir
  • racional: "Permitir acesso de escrita a registros de pacientes para médicos e admins"
• Política 3: Acesso de exclusão para admins
  • sujeito: Usuário com função admin
  • recurso: Recurso com nome registro-de-paciente
  • ação: excluir
  • efeito: permitir
  • racional: "Permitir acesso de exclusão a registros de pacientes para admins"

Para cada requisição de leitura/escrita/exclusão, o motor de políticas avalia todas as políticas relevantes com base nos atributos e toma uma decisão de controle de acesso.

Comparação#

Neste caso, as políticas de controle de acesso são simples e bem estruturadas. Requer apenas uma verificação de permissão em um único nível para determinar se um usuário tem acesso a um recurso. Suponha que o sistema hospitalar tenha uma estrutura mais complexa com múltiplos departamentos, funções e permissões:

• Em um modelo RBAC, o processo de avaliação de controle de acesso do recurso de registros de pacientes permaneceria simples e direto, se o usuário possui a permissão de ler, escrever ou excluir;
• O ABAC, por outro lado, precisa envolver atributos adicionais como department-id e doctor-id. E se um dispositivo IoT precisar acessar os registros de pacientes? Será necessário introduzir um novo atributo device-id na avaliação das políticas. Como seria conceder a permissão de ler temporariamente a um médico estagiário?

Em conclusão, o RBAC é uma escolha melhor. O RBAC é simples e eficiente para sistemas com estruturas de permissões bem definidas e onde as políticas de controle de acesso são estáticas.

Caso 2#

Mesmo sistema hospitalar, agora vamos introduzir uma nova função paciente e um novo atributo patient-id.

As políticas de controle de acesso são:

1. Médicos podem ler e escrever registros de pacientes.
2. Enfermeiros podem ler registros de pacientes.
3. Administradores podem ler, escrever e excluir registros de pacientes.
4. Pacientes podem ler seus próprios registros.

Modelo RBAC#

Neste caso, além da antiga permissão de ler, precisamos introduzir uma nova permissão ler-próprio. Podemos definir funções para médicos, enfermeiros, administradores e pacientes, e atribuir as permissões apropriadas a cada função.

Agora a avaliação de controle de acesso é um pouco mais complexa, especialmente para a ação de ler os registros de pacientes:

• GET /registros-de-pacientes: user.permission.includes('read')
• POST /registros-de-pacientes: user.permission.includes('write')
• DELETE /registros-de-pacientes: user.permission.includes('delete')
• GET /registros-de-pacientes/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

Modelo ABAC#

Agora vamos atualizar os atributos e políticas no modelo ABAC para acomodar os novos requisitos.

Atributos:

• user.role: médico, enfermeiro, admin, paciente
• user.id: patient-id
• resource.name: registro-de-paciente
• resource.patient-id: patient-id
• action: ler, escrever, excluir

Políticas:

• Política 1: Permitir acesso de leitura a todos os registros de pacientes
  • sujeito: Usuário com função médico, enfermeiro, admin
  • recurso: Recurso com nome registro-de-paciente
  • ação: ler
  • efeito: permitir
  • racional: "Permitir acesso de leitura a registros de pacientes para todos os funcionários e o próprio paciente"
• Política 2: Permitir acesso de escrita a todos os registros de pacientes para médicos e admins
  • sujeito: Usuário com função médico, admin
  • recurso: Recurso com nome registro-de-paciente
  • ação: escrever
  • efeito: permitir
  • racional: "Permitir acesso de escrita a registros de pacientes para médicos e admins"
• Política 3: Permitir acesso de exclusão a todos os registros de pacientes para admins
  • sujeito: Usuário com função admin
  • recurso: Recurso com nome registro-de-paciente
  • ação: excluir
  • efeito: permitir
  • racional: "Permitir acesso de exclusão a registros de pacientes para admins"
• Política 4: Permitir acesso de leitura aos próprios registros de pacientes
  • sujeito: Usuário com função paciente
  • recurso: Recurso com nome registro-de-paciente
  • ação: ler
  • condição: user.id === resource.patient-id
  • efeito: permitir
  • racional: "Permitir acesso de leitura aos próprios registros de pacientes"

Comparação#

Neste caso, as políticas de controle de acesso são mais complexas e sensíveis ao contexto. O processo de avaliação de controle de acesso do recurso de registros de pacientes exigirá vários níveis de verificações de permissão para determinar se um usuário tem acesso a um recurso.

• Em um modelo RBAC, o processo de avaliação de controle de acesso do recurso de registros de pacientes exigirá vários níveis de verificações de permissão para determinar se um usuário tem acesso a um recurso. Por exemplo, para determinar se um paciente tem acesso aos próprios registros, o sistema precisa verificar se o usuário possui a permissão de ler-próprio e se o id do usuário corresponde ao id do paciente.
• Em um modelo ABAC, o processo de avaliação de controle de acesso pode ser mais direto. As políticas podem ser definidas com base nos atributos do usuário, recurso e ação. Por exemplo, para determinar se um paciente tem acesso aos próprios registros, o motor de políticas pode avaliar a política com base no id do usuário e no id do paciente.

Neste caso, o ABAC pode ser uma escolha melhor. O ABAC é mais adequado para sistemas onde as políticas de controle de acesso precisam ser dinâmicas, sensíveis ao contexto e granulares.

Conclusão#

A escolha entre RBAC e ABAC depende dos requisitos específicos do sistema. O RBAC é mais adequado para sistemas com estruturas de permissões bem definidas e onde as políticas de controle de acesso são estáticas. O ABAC é mais adequado para sistemas onde as políticas de controle de acesso precisam ser dinâmicas, sensíveis ao contexto e granulares. Na prática, as organizações podem optar por usar uma combinação de ambos os modelos para alcançar o nível desejado de controle de acesso.