RBAC0

No conceito base do RBAC, não é vista a parte de hierarquia e restrições. Este modelo é caracterizado pela definição inicial dos usuários, papéis e permissões e pelas interações entre eles.

2.3.1.2.1.1 Papel

Sandhu (1997, pag. 3) denota um papel, ou role, como uma construção semântica, a qual é acrescida de políticas de controle de acesso. Este papel é visto como mais estável pois nas organizações têm a tendência de mudar muito pouco as atividades exercidas, e mesmo assim os usuários e permissões que estão interligados aos papéis são transitórios. Um papel também representa uma competência do usuário associado a ela, uma autoridade ou até responsabilidade. (SANDHU, 1997, pag.5).

Por ser um conceito mais antigo que o próprio controle de acesso, o papel tem uma grande variação e amplitude, porém deve-se focar na perspectiva do controle de acesso. (SANDHU, 1997, pag. 3).

2.3.1.2.1.2 Permissão

A permissão, ou permission, refere-se ao acesso a um ou vários objetos na organização, ela também é vista como um privilégio ou direito de acesso ao determinado objeto. Uma permissão a um objeto concede determinadas ações, como na sua manipulação. Uma permissão pode se referir a uma pequena ação em cima de um objeto, ou ao total acesso a uma determinada rede, desta forma deve-se entender a permissão a ser criada. O modelo RBAC não possui permissão negativa, apenas não é concedido o acesso. (SANDHU, 1997, pag. 5). A permissão, portanto, poderá ser vista por diversas formas dependendo da sua ação, como acesso a uma tabela, coluna, arquivos de sistema ou até atribuição de acesso. (PAVLICH-MARISCAL, et al, 2005).

2.3.1.2.1.3 Objeto

É um dado, um recurso disponível no sistema acessado. (SANDHU, 1997, pag. 5).

2.3.1.2.1.4 Usuário

O usuário, ou user, é representado pela pessoa física que irá ganhar o acesso, porém também pode ser caracterizado como uma máquina inteligente que exerça a mesma função que a pessoa física. (SANDHU, 1997, pag. 5)

2.3.1.2.1.5 Interações

O modelo de RBAC0 possui duas interações com os papéis, os usuários associados, caracterizado por user assignment (UA), e as permissões associadas, como permission assignment (PA), estas relações podem ser de um para um à vários para vários, desta forma um papel poderá ter um ou vários usuários ligados a ele, e este papel poderá ter

uma permissão ou várias permissões de acesso. Ainda neste contexto um usuário poderá estar relacionado a vários papéis, assim como uma permissão. Estas ligações que caracterizam o RBAC, colocando o papel como intermediário impedindo a ligação direta de usuários com as permissões. (SANDHU, 1997, pag. 7).

2.3.1.2.1.6 Sessão

Para cada acesso de um usuário no sistema, este estará ligado a uma sessão, um usuário poderá ter várias sessões abertas caso acesse por diferentes telas ou instâncias da aplicação. Um usuário após ter acesso ao sistema, só conseguirá mudar de papel caso saia da sessão e realize um novo acesso ao sistema, ou caso seja desconectado por inatividade. (SANDHU, 1997, pag. 7).

2.3.1.2.2 RBAC1

A base do modelo RBAC1 é a introdução da hierarquia nos papéis, desta forma é possível refletir a estrutura organizacional separadas pelas suas autoridades e responsabilidades. Por convenção é visto os papéis com maior autoridade na parte superior, conforme figura 4, e os papéis com menor autoridade na parte inferior. As permissões têm uma propriedade de herança entre os papéis na hierarquia, como visto na imagem 4, além de possuir as suas próprias permissões o desenvolvedor júnior possui todas as permissões que o estagiário possui, já o supervisor do projeto possui tanto as permissões do desenvolvedor júnior como as do técnico de testes mais as suas próprias. (SANDHU, 1997).

Figura 4 – Hierarquia entre os papéis de um projeto

Fonte: Sandhu (1997, pag. 9)

Também é possível delimitar as permissões herdadas na hierarquia, como visto na figura 4, o supervisor do projeto herda as permissões do técnico de testes. Caso exista uma permissão que deva ser atribuída ao técnico mas não deve ser atribuída ao supervisor, cria-se um papel superior ao técnico de testes, o técnico de testes 2. Desta forma será atribuída a permissão a este papel, o supervisor continuará a ter as permissões do técnico herdadas porém sem as permissões do técnico 2. Os técnicos de teste que necessitarem a permissão serão ligados ao técnico 2, continuando também a herdar todas as permissões do técnico (SANDHU, 1997, pag. 10)

2.3.1.2.3 RBAC2

No modelo conceitual RBAC2 aparece a questão das restrições, por exemplo estas possibilitam a separação de deveres de uma organização. Com a criação de restrições usuários não poderão ser ligados a papéis mutuamente exclusivos, como no setor financeiro um usuário não pode possuir o papel de responsável pela compra e pela quitação, evitando assim que fraudes venham a acontecer. As restrições também possibilitam a limitação de acessos administrativos e a centralização desses acessos aos gestores responsáveis. (SANDHU, 1997, pag. 11).

Estas restrições de exclusão mútua, separando os deveres na organização, podem ser utilizadas também em permissões, não sendo possível um papel ser ligado a permissão para solicitar e assinar cheques. Desta forma as restrições possibilitam que permissões com grande poder dentro da organização possuam um controle maior na sua liberação, limitando-a. (SANDHU, 1997, pag.13)

2.3.1.2.4 RBAC3

O modelo conceitual RBAC3 abrange todos os três modelos anteriores, tendo toda a questão dos usuários, papéis, permissões e sessões, as suas interações, a questão de hierarquia e a questão de restrições. Pelo fato de conter tanto a hierarquia como a questão de restrições a sua implementação é mais difícil e requer um cuidado maior para que um conceito não impeça a execução e o funcionamento do outro. Por outro lado ao serem utilizados estes conceitos em conjunto permitem uma maior segurança e separação dos papéis e permissões, podendo separar uma equipe em hierarquia limitando o número e o ingresso de determinados papéis ou permissões. (SANDHU, 1997, pag. 14-15)

É possível visualizar o modelo RBAC3 na figura 5 com as interações, papéis, usuários, permissões e onde a hierarquia e as restrições entram em ação.

Figura 5 – Modelo conceitual RBAC3

2.3.1.3 Administrative RBAC97

No modelo RBAC percebe-se a dificuldade em limitar a administração de atribuições em poucos usuários, com a necessidade de se centralizar este controle para manter um padrão alto de segurança foram criadas variações do RBAC. (SANDHU, 1997, pag. 17). Como descrito por Sandhu (1997, pag.18) “Descentralizar os detalhes da administração do RBAC sem perder o controle central sobre o quadro de políticas é um atual desafio para arquitetos e designers de sistemas”.

Um modelo desta administração é a de Moffet e Sloman que definem o elaborado controle com papéis de domínio, gerentes, donos e chefes administrativos que não possuem um controle total, mas sim pequenas atribuições que necessitam de colaboração e aprovação entre eles nas atribuições. (SANDHU, 1997, pag. 18).

Desta forma, para se ter o controle das atribuições dos papéis e das permissões aparecem dois novas variantes, os papéis administrativos, ou administrative roles (AR), e as permissões administrativas, ou administrative permissions (AP). (SANDHU, 1997, pag 18).