RBAC COM CONTEXTOS: MODELO DE CONTROLE DE ACESSO BASEADO EM PAPÉIS PARA SISTEMAS WEB UTILIZADOS POR VÁRIAS DIVISÕES DE UMA ORGANIZAÇÃO Eduardo Martins Guerra
Divisão de Ciência da Computação Instituto Tecnológico de Aeronáutica 12228-901 São José dos Campos – SP
guerraem@directnet.com.br
Rodrigo Cunha de Paiva Divisão de Ciência da Computação Instituto Tecnológico de Aeronáutica 12228-901 São José dos Campos – SP
rodrigocpaiva@hotmail.com
Clovis Torres Fernandes Divisão de Ciência da Computação Instituto Tecnológico de Aeronáutica 12228-901 São José dos Campos – SP
clovis@ita.br RESUMO
O modelo de controle de acesso baseado em papéis – RBAC, não se mostra suficiente para alguns requisitos de sistemas corporativos Web que são utilizados por diversas divisões de uma organização. Isso ocorre, porque não foi prevista no RBAC a autonomia das divisões no que diz respeito ao controle de acesso. Visando atender esse novo requisito, o modelo RBAC com contextos estende o modelo RBAC0, dividindo a atribuição de papéis dentro de contextos. A utilização deste novo modelo proposto facilita tanto o desenvolvimento de sistemas que necessitam atender este requisito quanto a administração distribuída das permissões diretamente nas diferentes divisões da organização.
ABSTRACT
The Role Based Access Control Models – RBAC, is not sufficient to implement some web corporative system requirements used by departments of an organization. This occurs because RBAC doesn’t favor department with personal autonomy to manage the access control. In order to satisfy this new requirement, the RBAC with contexts extends the RBAC0 providing a way to have a good access control managing in different departments. This new model makes the development of systems with this kind of requirement easier as well as the managing of access control in different departments of the organization.
1 INTRODUÇÃO
Muitas organizações hoje têm utilizado a Internet para disponibilizar sistemas corporativos Web para uso de suas várias divisões. Essa prática é muito comum em ambientes de empresas do tipo franquia-franquiado. O controle de acesso nesse tipo de ambiente possui algumas peculiaridades, tais como a confidencialidade das informações entre as divisões, fazendo com que uma divisão não tenha acesso às informações de outra. Outra característica é a necessidade de autonomia de cada divisão na atribuição de papéis.
Modelos tradicionais de controle de acesso, como o discricionário e compulsório, cujas autorizações são atribuídas diretamente ao usuário, não são viáveis para aplicações onde o número de usuários é muito grande. O controle de acesso baseado em papéis, RBAC – Role-Based Access Control [Ferraiolo et al, 2003], possui características que permitem uma maior escalabilidade e uma administração mais otimizada do controle de acesso. Porém, o RBAC não possui um mecanismo que permita a implementação de forma direta da divisão de acesso entre as divisões, necessárias no ambiente do tipo de sistema citado.
O objetivo deste artigo é apresentar uma solução para o problema de controle de permissões em diferentes divisões da organização. Nesta solução, o padrão RBAC foi estendido, de forma a dividir por contextos a atribuição de papéis. O contexto é uma entidade criada no modelo proposto e que pode representar cada divisão da organização.
A este modelo estendido deu-se o nome de RBAC com Contextos.
Este artigo está organizado da seguinte forma.
Na Seção 2 apresenta-se o domínio das aplicações citadas, descrevendo-se as peculiaridades no controle de acesso e a utilização do RBAC. Na Seção 3 apresenta-se o modelo RBAC com contextos e na Seção 4, os detalhes de sua implementação nos sistemas em que já foi utilizado.
Na Seção 5 mostra-se uma análise dos resultados obtidos e exemplos de aplicações no qual a utilização do modelo foi feita de forma adequada.
N Seção 6 compara-se o modelo proposto com o modelo de autorização contextual utilizado no InCor [Motta and Furuie, 2002a]. Finalmente, na seção 7 conclui-se o trabalho, trazendo-se sugestões de trabalhos futuros.
2 CONTROLE DE ACESSO EM APLICAÇÕES CORPORATIVAS
O controle de acesso é um dos itens de segurança ligado à confidencialidade das informações e acesso a operações. Ou seja, com controle de acesso objetiva-se não deixar que usuários não autorizados obtenham acesso a algo restrito ao acesso deles. Esse controle de acesso pode estar ligado diretamente à informação, como é o caso do controle de acesso em um banco de dados [Rosa et al, 2003], ou mesmo no acesso ao provedor da informação, como na utilização desse modelo entre objetos distribuídos [Obelheiro et al, 2001]. Nesses casos, a administração do acesso é configurada por uma pessoa especializada e ligada à área de informática, fato que não ocorre na administração de acesso em sistemas corporativos.
Nos dois casos citados acima, assim como em grande parte das implementações de sistemas de controle de acesso realizadas nos dias de hoje, o modelo utilizado é o RBAC [Ferraiolo et al, 2003].
A grande vantagem do RBAC em relação aos sistemas de controle de acesso que o precederam, está na administração das autorizações de acesso.
Nos modelos anteriores, as autorizações eram atribuídas diretamente aos usuários, o que, de acordo com o número de usuários envolvidos, dificulta a administração das autorizações, tornando esta abordagem pouco escalável. No modelo RBAC, as autorizações de acesso são associadas a um papel e estes papéis são atribuídos aos usuários.
Dessa forma, a administração do controle de acesso se torna mais simples e viável para sistemas com grande número de usuários, trazendo inclusive benefícios financeiros em sua utilização [NIST 2002].
A seguir será apresentado o modelo RBAC e sua utilização em sistemas corporativos Web utilizados por diversas divisões de uma mesma organização.
2.1 O Modelo RBAC
O RBAC é um padrão de modelo para controle de acesso ANSI INCITS 359/2004 [FERRAIOLO et al, 2001]. Existem quatro modelos relacionados com o RBAC [SANDHU et al, 1996], e eles diferem em alguns detalhes. O modelo base é o RBAC0, que pode ser observado na Figura 1.
Esse padrão possui quatro entidades principais:
U (Usuários), P (Papéis), A (Autorizações) e S (Sessões). O relacionamento UP caracteriza uma relação muitos para muitos entre usuários e papéis,
o que mostra que um usuário pode possuir simultaneamente mais de um papel. O relacionamento PA, também muitos para muitos, é que configura as autorizações que um determinado papel deve possuir. As sessões se relacionam com apenas um usuário por vez, mas permite a ativação de qualquer papel que estiver na relação UP com aquele usuário [FERRAIOLO et al, 1995].
É importante ressaltar que o modelo também caracteriza a autorização como um relacionamento entre os objetos para os quais o acesso é protegido e as formas de se acessar ou modificar esses objetos. Mas apesar disto, o padrão deixa em aberto a interpretação de usuário, papel e autorização para ser especificado em modelos mais detalhados.
O modelo RBAC1 introduz uma hierarquia entre papéis, que define uma relação de ordem entre os papéis, de forma a explicitar melhor as linhas de autoridade e responsabilidade de uma organização.
Já o modelo RBAC2 introduz as restrições entre papéis, com a intenção de evitar a concentração de poder nas mãos de um único usuário, visando minimizar a possibilidade de fraude ou dano acidental. O modelo mais completo, o RBAC3, não apresenta nenhuma novidade, apenas constitui a união da hierarquia de papéis do RBAC1 às restrições do RBAC2.
Segundo levantamentos de requisitos feitos, cada divisão da organização precisa de autonomia na administração dos papéis. Devido a esse motivo, foram identificados poucos papéis para cada divisão. Desta forma, foram consideradas desnecessárias a hierarquia e as restrições de papéis e o modelo RBAC0 foi utilizado como base da solução ao problema.
Figura 1 – Estrutura Esquemática do Modelo RBAC0, adaptado de [Motta and Furuie, 2002]
2.2 Utilização do RBAC em Sistemas com Divisões Na tentativa de se usar o modelo RBAC em sistemas corporativos Web [Barkley et al, 1997], utilizados por diversas divisões de uma mesma organização, alguns requisitos identificados não eram atendidos diretamente pela utilização desse modelo. Neste caso específico, a maior preocupação em relação ao acesso é o de uma divisão não ter acesso às informações de outra. Um exemplo, seria o fato de ser indesejável que usuários ligados a uma filial de uma franquia obtivessem acesso a informações financeiras de outra filial.
Uma preocupação secundária, mas nem por isso menos importante, são os níveis de acesso dentro de uma mesma divisão da organização. Dessa forma, é importante ressaltar que cada divisão necessita ter autonomia na atribuição de autorizações, existindo inclusive o caso de usuários que possuem funções diferentes em diferentes divisões necessitarem possuir o papel adequado dentro de cada divisão.
A necessidade de se repensar o modelo RBAC surgiu durante o levantamento de requisitos de sistemas desenvolvidos pelos autores. No momento desse levantamento, foram explicados para os conhecedores de domínio os conceitos compreendidos no modelo RBAC0 [SANDHU et al, 1996] para verificar a adequabilidade do mesmo.
Descobriu-se, ademais, que, devido à distribuição da administração de papéis, as pessoas que iriam administrar o acesso ao sistema, em sua grande maioria, eram leigas na área de informática. Dessa forma, caso a atribuição dos papéis não fosse algo intuitivo, muito provavelmente o sistema seria subutilizado e o custo do desenvolvimento do mesmo seria um investimento perdido.
Para a utilização direta do RBAC0 nesse tipo de aplicação, em que os dados se dividem por divisões da organização, seria preciso criar mecanismos para permitir a divisão do acesso aos dados de cada uma das divisões. Deveria haver uma distinção entre as autorizações de divisões diferentes e deveria haver papéis diferentes para cada divisão. Um exemplo seria existir uma autorização diferente para criação de cadastro na Filial A e na Filial B, existindo o papel Vendedor Filial A que teria a primeira autorização e o papel Vendedor Filial B que teria a segunda.
A administração de papéis feita de forma distribuída também seria mais complicada de ser implementada, de forma que um usuário administrador em uma divisão só poderia atribuir para outro usuário papéis que as autorizações estivessem contidas dentro das suas. Esta solução resultaria em uma implementação mais complexa e demorada, com a administração de papéis feita de forma não intuitiva, tornando esta abordagem inadequada para o sistema em questão.
A solução encontrada para todos esses requisitos foi estender o modelo RBAC para esse tipo de sistema, de forma a se adaptar a divisão do controle de acesso e a tornar mais intuitiva ao usuário a administração de papéis, sem prejuízo dos requisitos de segurança.
3 O MODELO RBAC COM CONTEXTOS
O objetivo do sistema de controle de acesso proposto é se adequar a um tipo de sistema utilizado por várias divisões dentro da mesma organização, tornando a administração de autorizações e papéis mais simples e mais intuitiva para o usuário. Por outro lado, não se deseja perder em funcionalidade, de forma a tornar o sistema de controle de acesso inadequado em relação aos requisitos de segurança.
O primeiro passo para tornar o sistema de controle de acesso adaptado ao tipo de aplicação, foi a introdução de uma nova entidade além das quatro já existentes no RBAC0. Essa nova entidade reflete as divisões existentes dentro da organização, para as quais se deseja a separação da atribuição de papéis, pois essa atribuição somente será válida dentro de um contexto. Por este motivo, a esta nova entidade foi dado o nome de Contexto (C), e na Figura 2 pode-se perceber como ela se relaciona com as outras entidades. A interpretação do contexto também vai depender da aplicação, mas algumas das interpretações feitas em sistemas já implementados são as seguintes: filiais, unidades e departamentos. Dessa forma, assim como feito com as outras entidades do RBAC, a interpretação para os contextos será deixada em aberto.
Nesse novo modelo, uma sessão é composta apenas por um usuário e um contexto por vez. Para que um usuário ative um novo contexto em uma sessão, é necessário que ele desative o contexto anterior. Dessa forma, o que existe é uma troca de contextos. Ou seja, uma sessão em um determinado momento é formada por apenas um usuário e um contexto.
O modelo mostrado permite que um usuário possua mais de um papel por contexto. Porém, em todas as aplicações em que se utilizou este modelo não foi necessária, de acordo com os requisitos de cada uma delas, a implementação desse caso. A divisão dos papéis por contexto eliminou grande parte da necessidade da ativação de mais de um papel por sessão, visto que, ao trocar de contexto, o usuário automaticamente faz a ativação do papel relacionado com o novo contexto, desativando o anterior. Este modelo estende o RBAC0, visto que o modelo RBAC com contexto se transforma no RBAC0 no caso de se possuir apenas um contexto.
Com a utilização dos contextos, foi possível realizar facilmente a implementação da autonomia desejada para as divisões da organização no que diz respeito à administração de papéis. Para os
usuários, a acumulação de papéis ficou mais clara, pois os papéis são por contexto, algo que acaba sendo mais intuitivo para o mesmo: “Eu possuo o papel de Administrador na Filial A e o papel de Supervisor na Filial B”. Pode-se dizer que o grande ganho do modelo RBAC com contextos do ponto de vista do usuário foi realizar uma simplificação que atende os requisitos de segurança, ao mesmo tempo em que facilita a compreensão do sistema. O impacto da facilidade de implementação se reflete em menor tempo de desenvolvimento, menor custo e, conseqüentemente, em melhor nível de manutenibilidade.
Com os contextos, as autorizações também ficam mais fáceis de serem definidas. As autorizações são resultado do relacionamento entre os objetos protegidos e as formas de acesso ao mesmo. Os contextos ajudam na definição de quais são os objetos para os quais aquela autorização está sendo concedida. Se, por exemplo, o objeto é o acesso às entradas e saídas na conta, o contexto ajuda na divisão dessas entradas e saídas, de forma que a autorização correspondente fica definida somente para as entradas e saídas relacionadas com
aquele contexto, ou seja, daquela filial ou unidade da organização. Isto ajuda na divisão dos objetos não só pelo seu tipo, no exemplo entradas e saídas na conta, mas também pelo contexto que está relacionado.
4 DETALHES DE IMPLEMENTAÇÃO
As aplicações implementadas funcionam de forma centralizada, utilizam interface Web e possuem uma arquitetura baseada em pelo menos 5 camadas: banco de dados, interface de persistência, camada de negócios, controle de interface e interface com o usuário. As informações relativas ao controle de acesso são armazenadas no banco de dados e a cada verificação de autorização, realizada nas camadas de negócio ou controle de interface conforme arquitetura server-pull [PARK et al, 2001], é efetuada uma consulta que retorna se o usuário possui ou não aquela autorização naquele contexto. A forma como os dados estão estruturados é bastante simples e pode ser vista na Figura 3.
Figura 2 – Modelo RBAC com Contextos
A partir do modelo entidade-relacionamento da Figura 3 pode-se verificar que ele implementa exatamente o modelo mostrado na Figura 2. A entidade UCP, que representa a ligação entre usuários, contextos e papéis, possui a identificação de papel como parte de sua chave primária. Isto nos mostra que é permitido a um usuário possuir mais de um papel por contexto. Nos sistemas implementados onde não houve a necessidade de haver um usuário possuindo mais de um papel por contexto, isto pode ser modificado facilmente, retirando o atributo PAP_ID da chave primária.
As informações armazenadas em uma sessão são apenas a identificação do usuário e a identificação do contexto. Sabendo qual autorização é necessária para executar uma ação, pode ser executada uma consulta que resolve dinamicamente os papéis do usuário no dado contexto e verifica se algum deles possui a autorização de acesso.
Para que a compreensão dos contextos fosse algo realmente intuitivo, a troca do contexto deveria ser algo claro e acessível para o usuário a qualquer momento. Para isto, em todas as aplicações implementadas, no cabeçalho ou no rodapé da interface era disponibilizada a lista de todos os contextos que aquele dado usuário possui, conforme mostrado na Figura 4. Nessa lista sempre ficava pré-selecionado o contexto da sessão corrente. Para a troca de contexto bastava a seleção de um outro contexto da lista.
5 APLICAÇÃO E RESULTADOS
O modelo proposto aqui, por ter vindo de uma necessidade prática, já se encontra implementado pelos seus autores e está em produção em diversos sistemas corporativos voltados para a Internet.
Nesta seção serão dados alguns exemplos de Figura 3 – Modelo Entidade Relacionamento do Modelo RBAC com Contextos
Usuário Conectado Nome: Edward War Contexto: Filial I
Logout Trocar Senha
Figura 4 – Exemplo de Interface para Troca de Contextos
aplicações desenvolvidas que utilizam o modelo proposto e serão comentados alguns resultados observados na utilização do modelo.
5.1 Aplicações
Nesta seção serão mostradas aplicações de diversos domínios de conhecimento que utilizaram o modelo proposto. As aplicações não precisam necessariamente ser Web para a utilização do modelo. O fato é que esse tipo de aplicação, por possuir a característica de poder facilmente ser acessada de vários lugares, favorece um cenário em que diversas divisões de uma mesma corporação acessem o sistema. E na verdade, é este cenário que foi observado como adequado para a utilização do modelo.
5.1.1 Sistema Corporativo para Controle de Rede de Escolas de Idiomas
O primeiro exemplo de sistema desenvolvido que utiliza o sistema proposto foi um sistema voltado para o controle e administração de uma rede de escolas de idiomas. O sistema é completamente voltado para a Internet, pois a rede de escolas possui unidades, a saber filiais ou franquias, espalhadas por todo o território do estado de São Paulo.
Para a implantação do controle de acesso neste caso, considerou-se o contexto como sendo cada uma das unidades da rede. As unidades nem sempre pertencem ao mesmo proprietário, sendo muito forte a necessidade da autonomia na atribuição de papéis.
5.1.2 Sistema Corporativo para Administração de Consolidadoras de Turismo e suas Agências
Outro exemplo de sistema no qual o modelo proposto foi utilizado foi um sistema para controle administrativo de consolidadoras de turismo e suas agências. De forma simplificada, as consolidadoras são distribuidoras de passagens aéreas e as agências são os pontos de venda dessas passagens. Nessa aplicação, o contexto é dividido em níveis, sendo o contexto de nível estratégico correspondente à consolidadora, e o de nível operacional, a suas diversas agências espalhadas por todo o território por onde opera.
Esse sistema fez uso intenso de atribuições de papéis para um determinado usuário em contextos diferentes. Isto ocorre, pois é muito comum um mesmo usuário possuir diferentes atribuições em várias agências. Um exemplo foi um usuário que era Administrador na consolidadora, atuar também como Supervisor em algumas agências.
5.1.3 Sistema Militar de Comando e Controle
O Sistema de Militar de Comando e Controle consiste no sistema de maior extensão de distribuição no qual o modelo proposto foi implementado. Uma peculiaridade deste sistema é o compartilhamento de informações entre diferentes contextos. A informação, apesar de ser compartilhada, implicava em responsabilidades diferentes dos contextos sobre a informação. Dessa forma, como a autorização é definida pelo objeto acessado e operação realizada com o objeto, se o tipo de acesso à informação for diferente, a autorização para o acesso à informação compartilhada pelos contextos também é diferente.
Esse tipo de comportamento é comum quando a aplicação troca “mensagens” entre contextos. Nesse caso, uma definição das operações que cada contexto pode possuir em relação à informação é essencial para que o acesso aos dados ocorra de forma adequada.
5.2 Análise dos Resultados
A introdução do conceito de contextos ajudou a tornar o controle de acesso e a distribuição de papéis entre as divisões da organização mais intuitiva para o administrador de autorizações.
Neste novo modelo, o usuário não se confunde com as autorizações que seu papel possui em cada divisão da organização e segue sua intuição sabendo que, dependendo de onde estiver e em qual contexto, poderá ter uma definição de papéis diferentes. Devido às experiências realizadas com os sistemas citados na Seção 5.1, pode-se confirmar que o modelo RBAC com Contextos se mostrou adequado aos requisitos de controle de acesso desses tipos de sistema.
No que diz respeito à implementação, o modelo se mostrou de fácil adaptabilidade a sistemas de diferentes domínios de conhecimento, com alto índice de reusabilidade. O modelo se mostrou eficiente para a proteção tanto do acesso quanto da modificação da informação, mostrando-se adequado para cenários militares e comerciais [Clark and Wilson, 1987], mantendo a informação restrita tanto entre as unidades militares, quanto entre franquias de uma mesma rede. Porém o maior ganho com certeza foi a adequabilidade do novo modelo ao tipo de aplicação que foi implementada, diminuindo a sobrecarga administrativa e o tempo de desenvolvimento, ocasionando em redução de custos [ISM, 2001].
6 COMPARAÇÃO DO MODELO PROPOSTO COM O DE AUTORIZAÇÃO CONTEXTUAIS
O modelo proposto neste artigo não foi a primeira abordagem na literatura para controle de acesso dependente de contexto. O modelo de autorização contextual para controle de acesso baseado em papéis proposto por Motta and Furuie,
[2002a] faz com que uma autorização seja positiva ou negativa, de acordo com regras que relacionam informações sobre o contexto em que aquela autorização está sendo solicitada. Esse modelo vem sendo utilizado no MACA, uma ferramenta de autorização e controle de acesso para o prontuário eletrônico de pacientes [Motta and Furuie, 2002b], que se encontra funcionando no Instituto do Coração do Hospital das Clínicas da Faculdade de Medicina da Universidade de São Paulo.
A diferença entre o modelo de autorizações contextuais e o RBAC com contextos está na forma com que o contexto se encaixa no modelo. No sistema de autorizações contextuais o contexto é algo dinâmico e extremamente granular, onde o mesmo é constituído de informações tais como hora, local e qual o paciente. Nesse modelo, o contexto se encaixa na autorização, que será positiva ou negativa, dependendo de regras que utilizam variáveis do contexto.
O modelo RBAC com contextos já trabalha com contextos fixos e mais amplos, como filiais e unidades de uma organização. No modelo proposto neste artigo, o contexto se encaixa no relacionamento entre usuários e papéis funcionando como um divisor entre o controle de acesso dos diferentes contextos. Como o contexto é algo bem mais amplo, faz sentido atribuir papéis dentro de cada contexto.
Apesar do objetivo de ambos os modelos ser o de diferenciar autorizações de acesso do mesmo tipo de informação de acordo com o contexto, os ambientes de utilização que tornam os modelos adequados para utilização são diferentes. O modelo de autorizações contextuais trabalha com contextos dinâmicos e granulares, bem como com uma definição dinâmica da autorização, enquanto o modelo RBAC com contextos trabalha com contextos fixos e amplos, bem como com a atribuição de papéis por contexto.
7 CONCLUSÃO
Este artigo mostrou um modelo RBAC com contextos, estendido do RBAC0 com o objetivo de implementação em sistemas corporativos para utilização por diversas divisões de uma organização. O modelo proposto tem por objetivo se adaptar ao tipo de aplicação descrita, sendo necessário e suficiente, sem que os requisitos de segurança sejam deixados de lado. Na apresentação do modelo adaptado foi mostrado que ele não utiliza as características mais avançadas do RBAC3, mas contém o modelo RBAC0.
O uso do modelo RBAC com contextos só foi validado neste tipo de aplicação, mas, dependendo do domínio, os contextos podem possuir um significado mais amplo, e pode ser utilizado como um recurso para dividir a atribuição de papéis. Este estudo de adequabilidade para utilização dos
contextos em outros tipos de sistema é algo que ainda não foi considerado, mas que pode ser tema de um experimento futuro. Casos especiais como hierarquia de contextos e a intersecção de informações entre contextos, foram problemas encontrados e solucionados de maneira particular em cada sistema, mas que precisam de uma análise mais profunda para a padronização de uma solução.
Teoricamente, também não há nada que impeça a adaptação do RBAC3 para o modelo proposto com contextos, porém para as aplicações implementadas isto não foi necessário. Para a implementação da hierarquia e das restrições de papéis no modelo RBAC com contextos, o que deve ser observado é que a hierarquia e as restrições devem abranger todos os papéis, pois estes existem independente dos contextos. Porém, como a atribuição de papéis ocorre atrelada a um contexto, as implicações dos relacionamentos entre papéis devem ser consideradas somente com os papéis atribuídos dentro de um mesmo contexto.
REFERÊNCIAS BIBLIOGRÁFICAS
BARKLEY J.; CINCOTTA A.V.; FERRAIOLO D.;, GAVRILA S.; KUHN D.R. "Role Based Access Control for the World Wide Web" , 20th National Computer Security Conference, 1997.
CLARK D.; WILSON D. “A Comparison of Commercial and Military Computer Security Policies”, Proc. IEEE Symp. Security and Privacy, pp. 184-194, 1987.
FERRAIOLO D.; CUGINI J.; KUHN D.R. "Role Based Access Control: Features and Motivations", Computer Security Applications Conference, 1995.
FERRAIOLO D.; SANDHU R. S.; GAVRILA S.;
KUHN D.R.; CHANDRAMOULI R. “Proposed NIST Standard for Role-Based Access Control”. ACM Transactions on Information and System Security , vol. 4, no. 3, August, 2001.
FERRAIOLO D.; KUHN D.R.;
CHANDRAMOULI R. “Role Based Access Control”, Artech House, 2003.
ISM, Information Security Magazine - "Access to Cost Savings: Role-based access control systems can save organizations time and money" – On-line em 16/07/2004 em http://infosecuritymag.techtarget.com/articles/ap ril01/cover.shtml.
MOTTA G. H. M. B.; FURUIE S. S. “Um Modelo de Autorização Contextual para Controle de Acesso Baseado em Papéis”, WSeg, 2002.
MOTTA G. H. M. B.; FURUIE S. S. “MACA:
Uma Ferramenta de Autorização e Controle de Acesso para o Prontuário Eletrônico de Pacientes”, VIII CBIS, 2002.
NIST “The Economic Impact of Role Based Access Control”, Research Triangle Institute, NIST Planning Report 02-01, 2002.
OBELHEIRO R.; WESTPAHL C.; FRAGA J.
“Controle de Acesso Baseado em Papéis para Sistemas Distribuídos CORBA”, SSI, 2001.
PARK J. S.; SANDHU R. S.; AHN G. J. “Role- based access control on the web”, ACM Transactions on Information and System Security (TISSEC), Volume 4, Issue 1, 37-71, February, 2001.
ROSA R. L.; MATTOS L. A. F. ; NASCIMENTO A. E. M. “Uma proposta metodológica para implantação do modelo RBAC em sistemas de banco de dados”, SSI, 2003.
SANDHU R. S.; COYNE E.J.; FEINSTEIN H.L.;
YOUMAN C.E. "Role-Based Access Control Models", IEEE Computer 29(2), 38-47, IEEE Press, 1996.
