Controle de acesso baseado em função - Role-based access control

Na segurança de sistemas de computador, controle de acesso baseado em função ( RBAC ) ou segurança baseada em função é uma abordagem para restringir o acesso do sistema a usuários autorizados. É uma abordagem para implementar o controle de acesso obrigatório (MAC) ou controle de acesso discricionário (DAC).

O controle de acesso baseado em função (RBAC) é um mecanismo de controle de acesso neutro em relação a políticas definido em torno de funções e privilégios. Os componentes do RBAC, como permissões de função, função de usuário e relações de função de função, simplificam a execução de atribuições de usuário. Um estudo do NIST demonstrou que o RBAC atende a muitas necessidades de organizações comerciais e governamentais. O RBAC pode ser usado para facilitar a administração de segurança em grandes organizações com centenas de usuários e milhares de permissões. Embora o RBAC seja diferente das estruturas de controle de acesso MAC e DAC, ele pode impor essas políticas sem nenhuma complicação.

Projeto

Dentro de uma organização, as funções são criadas para várias funções de trabalho. As permissões para realizar certas operações são atribuídas a funções específicas. Membros ou equipe (ou outros usuários do sistema) recebem funções específicas e, por meio dessas atribuições, adquirem as permissões necessárias para executar funções específicas do sistema. Uma vez que os usuários não recebem permissões diretamente, mas apenas as adquirem por meio de sua função (ou funções), o gerenciamento dos direitos individuais do usuário torna-se uma questão de simplesmente atribuir funções apropriadas à conta do usuário; isso simplifica as operações comuns, como adicionar um usuário ou alterar o departamento de um usuário.

A interferência de controle de acesso baseado em função é um problema relativamente novo em aplicativos de segurança, onde várias contas de usuário com níveis de acesso dinâmico podem levar à instabilidade da chave de criptografia, permitindo que um usuário externo explore a vulnerabilidade do acesso não autorizado. Os aplicativos de compartilhamento de chaves em ambientes virtualizados dinâmicos têm mostrado algum sucesso ao abordar esse problema.

Três regras principais são definidas para RBAC:

  1. Atribuição de função: um sujeito pode exercer uma permissão apenas se o sujeito tiver selecionado ou tiver recebido uma função.
  2. Autorização de função: a função ativa de um sujeito deve ser autorizada para o sujeito. Com a regra 1 acima, esta regra garante que os usuários possam assumir apenas funções para as quais estão autorizados.
  3. Autorização de permissão: um sujeito pode exercer uma permissão somente se a permissão for autorizada para a função ativa do sujeito. Com as regras 1 e 2, esta regra garante que os usuários possam exercer apenas as permissões para as quais estão autorizados.

Restrições adicionais também podem ser aplicadas e as funções podem ser combinadas em uma hierarquia onde as funções de nível superior incluem permissões pertencentes às subfunções.

Com os conceitos de hierarquia de papéis e restrições, pode-se controlar o RBAC para criar ou simular o controle de acesso baseado em rede (LBAC). Assim, o RBAC pode ser considerado um superconjunto do LBAC.

Ao definir um modelo RBAC, as seguintes convenções são úteis:

  • S = Assunto = Uma pessoa ou agente automatizado
  • R = Função = Cargo ou cargo que define um nível de autoridade
  • P = Permissões = Uma aprovação de um modo de acesso a um recurso
  • SE = Sessão = Um mapeamento envolvendo S, R e / ou P
  • SA = Atribuição de Assunto
  • PA = Atribuição de Permissão
  • RH = Hierarquia de papéis parcialmente ordenada. RH também pode ser escrito: ≥ (A notação: x ≥ y significa que x herda as permissões de y.)
    • Um sujeito pode ter vários papéis.
    • Uma função pode ter vários assuntos.
    • Uma função pode ter várias permissões.
    • Uma permissão pode ser atribuída a várias funções.
    • Uma operação pode ser atribuída a várias permissões.
    • Uma permissão pode ser atribuída a muitas operações.

Uma restrição impõe uma regra restritiva sobre a herança potencial de permissões de funções opostas, portanto, ela pode ser usada para obter a separação de tarefas apropriada . Por exemplo, a mesma pessoa não deve ter permissão para criar uma conta de login e autorizar a criação da conta.

Assim, usando a notação de teoria de conjuntos :

  • e é uma permissão de muitos para muitos para a relação de atribuição de função.
  • e é um muitos para muitos sujeito à relação de atribuição de função.

Um sujeito pode ter várias sessões simultâneas com / em funções diferentes.

RBAC

Níveis padronizados

Veja também: Modelo NIST RBAC

O padrão NIST / ANSI / INCITS RBAC (2004) reconhece três níveis de RBAC:

  1. RBAC central
  2. RBAC hierárquico, que adiciona suporte para herança entre funções
  3. RBAC restrito, que adiciona separação de funções

Relação com outros modelos

RBAC é uma tecnologia de controle de acesso flexível cuja flexibilidade permite implementar DAC ou MAC . O DAC com grupos (por exemplo, conforme implementado em sistemas de arquivos POSIX) pode emular o RBAC. O MAC pode simular o RBAC se o gráfico de funções estiver restrito a uma árvore em vez de um conjunto parcialmente ordenado .

Antes do desenvolvimento do RBAC, o modelo Bell-LaPadula (BLP) era sinônimo de MAC e as permissões do sistema de arquivos eram sinônimo de DAC. Estes foram considerados os únicos modelos conhecidos para controle de acesso: se um modelo não fosse BLP, era considerado um modelo DAC e vice-versa. Pesquisas no final da década de 1990 demonstraram que o RBAC não se enquadra em nenhuma das categorias. Ao contrário do controle de acesso baseado em contexto (CBAC), o RBAC não examina o contexto da mensagem (como a origem de uma conexão). O RBAC também foi criticado por levar à explosão de funções, um problema em grandes sistemas corporativos que requerem controle de acesso de granularidade mais fina do que o que o RBAC pode fornecer, pois as funções são inerentemente atribuídas a operações e tipos de dados. À semelhança do CBAC, um sistema de controle de acesso baseado em relação de entidade (ERBAC, embora o mesmo acrônimo também seja usado para sistemas RBAC modificados, como o controle de acesso baseado em função estendido) é capaz de proteger instâncias de dados considerando sua associação ao sujeito executor.

Comparando com ACL

O RBAC difere das listas de controle de acesso (ACLs), usadas em sistemas de controle de acesso discricionário tradicionais, em que os sistemas RBAC atribuem permissões para operações específicas com significado na organização, ao invés de objetos de dados de baixo nível. Por exemplo, uma lista de controle de acesso poderia ser usada para conceder ou negar acesso de gravação a um arquivo de sistema específico, mas não ditaria como esse arquivo poderia ser alterado. Em um sistema baseado em RBAC, uma operação pode ser para 'criar uma conta de crédito' transação em um aplicativo financeiro ou para 'preencher um registro de teste de nível de açúcar no sangue' em um aplicativo médico. A atribuição de permissão para executar uma operação específica é significativa, porque as operações são granulares com significado dentro do aplicativo. O RBAC demonstrou ser particularmente adequado aos requisitos de separação de tarefas (SoD), que garantem que duas ou mais pessoas devem estar envolvidas na autorização de operações críticas. As condições necessárias e suficientes para a segurança de SoD no RBAC foram analisadas. Um princípio subjacente do SoD é que nenhum indivíduo deve ser capaz de violar a segurança por meio de privilégios duplos. Por extensão, nenhuma pessoa pode exercer uma função que exerça autoridade de auditoria, controle ou revisão sobre outra função exercida simultaneamente.

Então, novamente, um "modelo RBAC mínimo", RBACm , pode ser comparado a um mecanismo ACL, ACLg , onde apenas grupos são permitidos como entradas na ACL. Barkley (1997) mostrou que RBACm e ACLg são equivalentes.

Em implementações SQL modernas , como ACL do framework CakePHP , ACLs também gerenciam grupos e herança em uma hierarquia de grupos. Sob este aspecto, implementações específicas de "ACL moderno" podem ser comparadas com implementações específicas de "RBAC moderno", melhor do que "implementações antigas (sistema de arquivos)".

Para intercâmbio de dados e para "comparações de alto nível", os dados ACL podem ser convertidos em XACML .

Controle de acesso baseado em atributos

O controle de acesso baseado em atributos ou ABAC é um modelo que evolui do RBAC para considerar atributos adicionais além de funções e grupos. No ABAC, é possível usar atributos de:

  • o usuário, por exemplo, cidadania, autorização,
  • o recurso, por exemplo, classificação, departamento, proprietário,
  • a ação, e
  • o contexto, por exemplo, hora, local, IP.

ABAC é baseado em políticas no sentido de que usa políticas em vez de permissões estáticas para definir o que é permitido ou não permitido.

Uso e disponibilidade

O uso do RBAC para gerenciar os privilégios do usuário (permissões do computador) em um único sistema ou aplicativo é amplamente aceito como uma prática recomendada. Um relatório de 2010 preparado para o NIST pelo Research Triangle Institute analisou o valor econômico do RBAC para empresas e os benefícios estimados por funcionário de redução do tempo de inatividade do funcionário, provisionamento mais eficiente e administração de política de controle de acesso mais eficiente.

Em uma organização com uma infraestrutura de TI heterogênea e requisitos que abrangem dezenas ou centenas de sistemas e aplicativos, usar o RBAC para gerenciar funções suficientes e atribuir associações de funções adequadas torna-se extremamente complexo sem a criação hierárquica de funções e atribuições de privilégios. Os sistemas mais novos estendem o modelo NIST RBAC mais antigo para lidar com as limitações do RBAC para implantações em toda a empresa. O modelo NIST foi adotado como padrão pela INCITS como ANSI / INCITS 359-2004. Uma discussão de algumas das opções de design para o modelo NIST também foi publicada.

Veja também

Referências

Leitura adicional

  • David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). Controle de acesso baseado em funções (2ª ed.). Artech House. ISBN 978-1-59693-113-8.

links externos