RBAC e ABAC: Os modelos de controlo de acesso que deves conhecer

Introdução#

Controlo de acesso é um aspeto crítico da segurança em qualquer sistema. Assegura que apenas utilizadores autorizados podem aceder a recursos e realizar ações. O controlo de acesso baseado em papéis (RBAC) e o controlo de acesso baseado em atributos (ABAC) são dois dos modelos de controlo de acesso mais populares usados em sistemas modernos. Ambos os modelos são amplamente adotados e podem ser usados para impor políticas de controlo de acesso de forma eficaz. Mas o que são e como diferem?

Controlo de acesso baseado em papéis (RBAC)#

O controlo de acesso baseado em papéis (RBAC) foi introduzido pela primeira vez no início da década de 1990. A formalização do modelo é creditada a David Ferraiolo e Rick Kuhn num artigo publicado em 1992. Desde então, o RBAC tornou-se um dos modelos de controlo de acesso mais amplamente utilizados na indústria.

No RBAC, as políticas de controlo de acesso são baseadas em papéis, que são coleções de permissões. Os utilizadores são atribuídos a papéis (por exemplo, administrador, editor, visualizador), e os seus direitos de acesso são determinados pelas permissões (por exemplo, criar, editar, eliminar) para recursos específicos (por exemplo, ficheiros, bases de dados, aplicações). Simplifica a gestão de políticas de controlo de acesso ao agrupar utilizadores com base nos seus papéis e atribuir permissões a papéis. É simples adicionar ou remover utilizadores de papéis, e as alterações serão automaticamente refletidas nas políticas de controlo de acesso.

Componentes-chave do RBAC#

• Recurso: Um recurso é uma entidade que um utilizador pode aceder. Os recursos podem ser qualquer coisa, desde ficheiros, bases de dados, APIs ou qualquer outra entidade de sistema que precise ser protegida.
• Permissão: Uma permissão é uma ação específica que um utilizador pode executar num recurso. Por exemplo, criar, editar, eliminar, visualizar. A definição de permissões pode variar dependendo do sistema. Na maioria dos casos, as permissões são definidas ao nível do recurso com uma granularidade mínima.
• Papel: Um papel é uma coleção de permissões que define um conjunto de ações que um utilizador pode executar. Por exemplo, um papel de administrador pode ter permissões para criar, editar e eliminar recursos, enquanto um papel de visualizador pode ter permissão para visualizar recursos.
• Utilizador: Um utilizador é uma entidade que pode ser atribuída a um ou mais papéis. Os utilizadores são concedidos acesso a recursos com base nas permissões associadas aos papéis que lhes são atribuídos.

Variantes do RBAC#

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

• RBAC0: O modelo básico onde os utilizadores são atribuídos a papéis e os papéis são atribuídos a permissões.
• RBAC1: Adiciona o conceito de hierarquias de papéis. Os papéis podem herdar permissões de outros papéis. Também é conhecido como RBAC hierárquico.
• RBAC2: Adiciona restrições aos papéis. As restrições podem ser usadas para definir condições adicionais que devem ser satisfeitas para um utilizador ser atribuído a um papel. Também é conhecido como RBAC baseado em restrições.
• RBAC3: Combina as características do RBAC1 e RBAC2. Suporta tanto hierarquias de papéis quanto restrições.

Para mais informações sobre estas variantes, consulte modelos de RBAC e a sua evolução.

Prós do RBAC#

• Simplicidade: O RBAC é fácil de entender e implementar. Atribuir permissões a papéis e papéis a utilizadores é direto.
• Eficiência: Simplifica a gestão de políticas de controlo de acesso ao agrupar utilizadores com base nos seus papéis. É fácil adicionar ou remover utilizadores de papéis sem alterar as políticas de controlo 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 papéis, permissões e utilizadores. É fácil auditar e rever políticas de controlo de acesso.

Contras do RBAC#

• Rigidez: O RBAC pode ser rígido quando se trata de definir políticas de controlo de acesso complexas. Pode não ser adequado para sistemas onde as políticas de controlo de acesso precisam ser mais dinâmicas e sensíveis ao contexto.
• Granularidade: O RBAC pode carecer da granularidade necessária para um controlo de acesso mais detalhado. As políticas de controlo de acesso estão vinculadas a papéis bem definidos, e pode requerer um esforço extra para definir permissões a um nível mais granular.
• Explosão de Papéis: Em grandes organizações com estruturas de permissões complexas, o número de papéis pode crescer exponencialmente, levando à explosão de papéis. Gerir um grande número de papéis pode ser um desafio.

Controlo 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 o controlo 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 controlo de acesso mais flexível em comparação com o RBAC. É um modelo de autorização que define políticas de controlo de acesso com base nos atributos do utilizador, recurso, ação e ambiente. Permite que as organizações definam políticas de controlo de acesso granulares que podem adaptar-se a diferentes contextos e condições.

Componentes-chave do ABAC#

• Sujeito: Um sujeito é uma entidade que solicita acesso a um recurso. Pode ser um utilizador, um dispositivo, uma aplicação ou qualquer outra entidade que precise aceder a recursos.
• Recurso: Tal como no RBAC, um recurso é uma entidade que um sujeito pode aceder. Os recursos podem ser ficheiros, bases de dados, APIs ou qualquer outra entidade de sistema.
• Ação: Uma ação é uma operação específica que um sujeito pode realizar num recurso. Pode ser criar, ler, atualizar, eliminar ou qualquer outra operação que precise ser controlada.
• Ambiente: O ambiente é o contexto em que o pedido de acesso é feito. 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. Os atributos podem ser qualquer coisa, desde papéis de utilizador, 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 controlo de acesso complexas que são baseadas em múltiplos atributos. Permite que as organizações definam políticas granulares que podem adaptar-se a diferentes contextos e condições.
• Dinâmico: As políticas de ABAC podem ser dinâmicas e sensíveis ao contexto. As decisões de controlo 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 controlo de acesso granular ao permitir que as organizações definam políticas com base em múltiplos atributos. Ao contrário da definição de papéis 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 gerir em comparação com o RBAC. Definir atributos e políticas pode requerer mais esforço e expertise. Ao contrário do RBAC, onde papéis e permissões estão bem estruturados, os atributos podem ser mais dinâmicos e assim as políticas também. Gerir um grande número de atributos e políticas num sistema complexo pode ser um desafio. Um motor centralizado de avaliação de políticas é muitas vezes necessário para avaliar as políticas.
• Desempenho: A avaliação de atributos pode impactar o desempenho, especialmente em ambientes em tempo real. As políticas baseadas em múltiplos atributos e condições em tempo real podem introduzir latência nas decisões de controlo de acesso.

Tabela de comparação#

Na tabela de comparação, é claro que o RBAC é mais adequado para sistemas com estruturas de permissão bem-definidas e onde as políticas de controlo de acesso são relativamente estáticas. Por outro lado, o ABAC é mais adequado para sistemas onde as políticas de controlo de acesso precisam ser dinâmicas, sensíveis ao contexto e extremamente detalhadas.

Exemplos#

Cenário: Um sistema hospitalar que precisa gerir o acesso a registos de pacientes para diferentes membros da equipa.

• Funcionários: Médicos, Enfermeiros, Administradores
• Recursos: Registos de Pacientes
• Permissões: Ler, Escrever, Eliminar

Caso 1#

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

1. Os médicos podem ler e escrever registos de pacientes.
2. Os enfermeiros podem ler registos de pacientes.
3. Os administradores podem ler, escrever e eliminar registos de pacientes.

Modelo RBAC#

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

A avaliação do controlo de acesso é direta:

• GET /patient-records: utilizador.permissão.inclui('ler')
• POST /patient-records: utilizador.permissão.inclui('escrever')
• DELETE /patient-records: utilizador.permissão.inclui('eliminar')

Modelo ABAC#

Neste caso, o ABAC pode ser um exagero, mas ainda pode ser usado para definir políticas pormenorizadas com base em atributos como departamento, papel, etc.

Atributos:

• utilizador.papel: médico, enfermeiro, admin
• recurso.nome: registo-de-paciente
• ação: ler, escrever, eliminar

Políticas:

• Política 1: Permitir acesso de leitura com base em utilizador.papel e recurso.nome
  • sujeito: Utilizador com papel médico, enfermeiro, admin
  • recurso: Recurso com nome registo-de-paciente
  • ação: ler
  • efeito: permitir
  • justificação: "Permitir acesso de leitura a registos de pacientes para todos os papéis"
• Política 2: Acesso a edição para médicos e administradores
  • sujeito: Utilizador com papel médico, admin
  • recurso: Recurso com nome registo-de-paciente
  • ação: escrever
  • efeito: permitir
  • justificação: "Permitir acesso de escrita a registos de pacientes para médicos e administradores"
• Política 3: Acesso a eliminação para administradores
  • sujeito: Utilizador com papel admin
  • recurso: Recurso com nome registo-de-paciente
  • ação: eliminar
  • efeito: permitir
  • justificação: "Permitir acesso de eliminação a registos de pacientes para administradores"

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

Comparação#

Neste caso, as políticas de controlo de acesso são simples e bem estruturadas. Apenas requer uma verificação de permissão a um único nível para determinar se um utilizador tem acesso a um recurso. Imagine que o sistema hospitalar tem uma estrutura mais complexa com múltiplos departamentos, papéis e permissões:

• Num modelo RBAC, o processo de avaliação de controlo de acesso do recurso registos de pacientes continuará simples e direto, seja o utilizador tem a permissão de ler, escrever ou eliminar;
• O ABAC, por outro lado, precisa envolver atributos adicionais como id-de-departamento и id-de-médico. E se um dispositivo IoT precisar aceder aos registos de pacientes? Será necessário introduzir um novo atributo id-de-dispositivo na avaliação da política. E se for necessário conceder a permissão ler temporariamente a um médico estagiário?

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

Caso 2#

Mesmo sistema hospitalar, agora vamos introduzir um novo papel paciente e um novo atributo id-do-paciente.

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

1. Os médicos podem ler e escrever registos de pacientes.
2. Os enfermeiros podem ler registos de pacientes.
3. Os administradores podem ler, escrever e eliminar registos de pacientes.
4. Os pacientes podem ler os seus próprios registos.

Modelo RBAC#

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

Agora a avaliação do controlo de acesso é um pouco mais complexa, especialmente para a ação ler de registo de paciente:

• GET /patient-records: utilizador.permissão.inclui('ler')
• POST /patient-records: utilizador.permissão.inclui('escrever')
• DELETE /patient-records: utilizador.permissão.inclui('eliminar')
• GET /patient-records/:id-do-paciente: utilizador.permissão.inclui('ler-próprio') && utilizador.id === id-do-paciente || utilizador.permissão.inclui('ler')

Modelo ABAC#

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

Atributos:

• utilizador.papel: médico, enfermeiro, admin, paciente
• utilizador.id: id-do-paciente
• recurso.nome: registo-de-paciente
• recurso.id-do-paciente: id-do-paciente
• ação: ler, escrever, eliminar

Políticas:

• Política 1: Permitir acesso de leitura a todos os registos de pacientes
  • sujeito: Utilizador com papel médico, enfermeiro, admin
  • recurso: Recurso com nome registo-de-paciente
  • ação: ler
  • efeito: permitir
  • justificação: "Permitir acesso de leitura a registos de pacientes para todos os funcionários e o próprio paciente"
• Política 2: Permitir acesso de escrita a todos os registos de pacientes para médicos e administradores
  • sujeito: Utilizador com papel médico, admin
  • recurso: Recurso com nome registo-de-paciente
  • ação: escrever
  • efeito: permitir
  • justificação: "Permitir acesso de escrita a registos de pacientes para médicos e administradores"
• Política 3: Permitir acesso de eliminação a todos os registos de pacientes para administradores
  • sujeito: Utilizador com papel admin
  • recurso: Recurso com nome registo-de-paciente
  • ação: eliminar
  • efeito: permitir
  • justificação: "Permitir acesso de eliminação a registos de pacientes para administradores"
• Política 4: Permitir acesso de leitura aos próprios registos de pacientes
  • sujeito: Utilizador com papel paciente
  • recurso: Recurso com nome registo-de-paciente
  • ação: ler
  • condição: utilizador.id === recurso.id-do-paciente
  • efeito: permitir
  • justificação: "Permitir acesso de leitura aos próprios registos de pacientes"

Comparação#

Neste caso, as políticas de controlo de acesso são mais complexas e sensíveis ao contexto. O processo de avaliação de controlo de acesso do recurso registos de pacientes exigirá múltiplos níveis de verificações de permissão para determinar se um utilizador tem acesso a um recurso.

• Num modelo RBAC, o processo de avaliação de controlo de acesso do recurso registos de pacientes exigirá múltiplos níveis de verificações de permissão para determinar se um utilizador tem acesso a um recurso. Por exemplo, para determinar se um paciente tem acesso aos seus próprios registos, o sistema precisa verificar se o utilizador tem a permissão ler-próprio e se o id do utilizador coincide com o id do paciente.
• Num modelo ABAC, o processo de avaliação de controlo de acesso pode ser mais direto. As políticas podem ser definidas com base nos atributos do utilizador, recurso e ação. Por exemplo, para determinar se um paciente tem acesso aos seus próprios registos, o motor de políticas pode avaliar a política com base no id do utilizador e no id do paciente.

Neste caso, o ABAC pode ser uma melhor opção. O ABAC é mais adequado para sistemas onde as políticas de controlo de acesso precisam ser dinâmicas, sensíveis ao contexto e extremamente detalhadas.

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ão bem-definidas e onde as políticas de controlo de acesso são estáticas. O ABAC é mais adequado para sistemas onde as políticas de controlo de acesso precisam ser dinâmicas, sensíveis ao contexto e extremamente detalhadas. 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 controlo de acesso.