Sentinel: um engenho Java para controle de acesso RBAC d

3 RBAC: Role-Based Access Control

Esta seo fornecer uma viso abrangente do que consiste RBAC, os problemas que visa atacar, como modelado, e suas principais caractersticas. Assume-se que o leitor tenha um mnimo de familiaridade com conceitos bsicos de controle de acesso como DAC e MAC.

3.1 Motivao e contexto

O controle de acesso em geral preocupa-se com determinar que usurios ou grupo de usurios podem realizar que operaes em que recursos computacionais. O problema fundamental que cada sistema e aplicao que inclui mecanismos de controle de acesso tem um mtodo prprio para criao e gerenciamento de usurios, grupos e principalmente uma significado particular de operao e objetos. Para muitas organizaes, o nmero de sistemas pode ser da ordem de centenas ou milhares, com o nmero de usurios variando de centenas a centenas de milhares, e o nmero de objetos a serem protegidos podem facilmente exceder os milhes. Como a utilizao de RBAC ajuda num contexto como esse? RBAC foi projetado para gerenciar centralmente privilgios ao prover uma camada de abstrao, conhecida como role (papel), mais alinhado estrutura da organizao. A noo central de RBAC que permisses so associadas papis, e usurios so associados aos seus papis corretos na organizao. Isso simplifica bastante a administrao e gerenciamento de permisses de acesso em grandes organizaes. Papis so criados para as vrias funes de negcio da organizao, e os usurios so associados a esses papis de acordo com suas responsabilidades e qualificaes. Usurios podem ser facilmente reassociados de um papel para outro. Papis podem receber novas permisses de acesso medida que novas aplicaes ou funcionalidades so adicionadas ao sistema, e permisses podem ser revogadas sempre que necessrio. Um papel apropriadamente entendido como uma construo semntica volta do qual a poltica de controle de acesso formulada. A coleo particular de usurios e permisses associadas a um papel transitria. O papel mais estvel porque as atividades e funes da organizao em geral mudam menos do que o conjunto de usurios ou de permisses. Isso torna a administrao de um sistema RBAC muito mais fcil e escalvel do que a de um sistema DAC, por exemplo, que precisa associar usurios a objetos diretamente, sem a construo do papel entre os dois, atuando como componente estabilizador. Diversos estudos mostram a eficcia deste tipo de abordagem [NISTR02]. Alm do forte motivo de facilitar o gerenciamento das permisses de acesso, um outro ponto motivador de RBAC a sua flexibilidade de adaptao a regras de acesso particulares de cada sistema, atravs do recurso de constraints, explicados em seo prpria. Isso permite expressar, na poltica de acesso do sistema, restries como a separao de deveres, em que um mesmo usurio no pode subverter a segurana do sistema ao exercer dois papis conflitantes ao mesmo tempo. Por exemplo, um mesmo usurio no poderia ser ao mesmo tempo o gerente de compras (que toma a deciso de realizar uma compra), e o gerente financeiro (que passa o cheque da compra), j que isso poderia abrir espao para fraudes em que ele indicaria uma compra fraudulenta e autorizaria a sua fatura por conta prpria. A separao de deveres um princpio clssico de segurana, utilizado extensamente no
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 16 de 51

Sentinel: um engenho Java para controle de acesso RBAC d mundo dos negcios, e possvel de ser expressado como regra de acesso em sistemas RBAC. A poltica de controle de acesso est incorporada em vrios componentes de RBAC, como as relaes papel permisso, usurio papel e papel papel. Estes componentes coletivamente determinar se um usurio particular ter permisso de acesso a um conjunto de dados oferecidos pelo sistema. O engenho RBAC pode ser configurado diretamente pelo administrador do sistema ou indiretamente por papis apropriados delegados por este administrador. A poltica em utilizao em um dado sistema advm do conjunto das configuraes dos vrios componentes RBAC realizadas pelo administrador do sistema. Alm disso, a poltica de controle de acesso pode evoluir incrementalmente ao longo do ciclo de vida do sistema um fato quase certo em sistemas de grande porte. A capacidade de modificar a poltica de acesso para atender s necessidades mutveis da organizao outro ponto forte do RBAC. RBAC neutro em termos de poltica, j que a sua configurao ir ditar qual a poltica em ao. Estudos [OSM00] [SM98] mostram que RBAC pode ser configurado para suportar polticas de controle de acesso advindas do MAC, como Bell-Lapadula; outros estudos mostram como RBAC pode ser utilizado para simular DAC em sistemas. Essa flexibilidade permite que um mesmo engenho possa ser utilizado tanto no mundo comercial quanto no mundo militar, apenas mudando as particularidades de adaptao para cada poltica. O leitor pode ento indagar: RBAC por si, um mecanismo de controle de acesso discrecionrio ou mandatrio ? Segundo [SCYF96], esta resposta depende da natureza e configurao dos papis, permisses e usurios no sistema RBAC. Entendendo mandatrio como significando que usurios individuais no tenham nenhuma escolha em relao a que permisses ou usurios so associados a um papel, e discrecionrio onde os usurios individuais podem tomar essas decises. Como dito anteriormente, RBAC um modelo por si s, sendo independente de poltica. Configuraes particulares de RBAC podem ter um forte componente mandatrio, enquanto outros podem ter um forte componente discrecionrio. Dito isso, a utilizao mais comum de engenhos RBAC de carter mandatrio, em que os usurios no tm controle, mas sem ter caractersticas de sistemas multinvel, com rtulos de segurana.

3.2 Papis e constraints

3.2.1 Papis
O conceito de papel vem sendo utilizado desde o incio dos anos setenta, em diversos sistemas e aplicaes. um conceito central ao modelo RBAC, sendo uma construo que modela funes organizacionais, unindo usurios e direitos de acesso correspondentes quele papel. Papis na organizao tem a tendncia de mudar muito menos do que usurios ou permisses de acesso, facilitando bastante a administrao. Uma pergunta extremamente freqente qual a diferena entre papis e grupos?. Grupos de usurios como unidades de controle de acesso so comumente providos em muitos sistemas de controle de acesso. A maior diferena entre o conceito de grupos e de papis que grupos so tipicamente tratados como uma coleo de usurios e no uma coleo de
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 17 de 51

Sentinel: um engenho Java para controle de acesso RBAC d permisses. Um papel tanto uma coleo de usurios, de um lado, e uma coleo de permisses no outro. O papel serve como um intermedirio para juntar essas duas colees.

Usurios

Permisses

Figura 1: relacionamento usurio - objeto

Usurios

Papel

Permisses

Figura 2: relacionamento usurio papel - objeto

Modelos mais modernos de RBAC prevem tambm a herana de papis em que usurios pertencentes a um papel filho herdam as permisses de acesso do papel pai. Por exemplo, uma empresa de software pode possuir o papel de Membro de projeto, com um conjunto bsico de direitos. Alm disso, pode possuir outros papis que herdam desse n papel: Engenheiro de testes e Engenheiro de software, cada um herdando os direitos bsicos do papel ascendente, e acrescentando um conjunto prprio de permisses de acesso. Herana mltipla tambm permitida, de modo que poderia existir um papel Gerente de projeto que herdasse os direitos de ambos os papis de engenharia. importante deixar claro que um usurio pode fazer parte de mais de um papel ao mesmo tempo, do mesmo modo que uma pessoa pode acumular funes em uma organizao. Alguns engenhos RBAC s permitem, todavia, que se entre no sistema escolhendo um nico papel de cada vez, de modo que seria necessrio escolher que conjunto de direitos sero necessrios no momento do login. Outros permitem que se possa entrar no sistema exercendo mais de um papel ao mesmo tempo, caso em que os direitos de acesso se acumulam.

3.2.2 Constraints
Constraints so um aspecto importante de RBAC, as vezes utilizadas como a principal justificao deste modelo de controle de acesso. Constraints so predicados que, aplicados a relaes e funes do modelo, retornam um valor aceito ou no aceito. Eles funcionam como um mecanismo poderoso para expressar polticas organizacionais de nvel mais alto, como separao de atividades, em que um usurio no pode exercer dois papis conflitantes, sendo considerados mutuamente exclusivos. Uma vez que dois papis so declarados mutuamente exclusivos, no necessrio preocupar-se tanto com a alocao de usurios a papis, com esta atividade podendo ser delegada com menos risco de comprometimento dos objetivos da poltica organizacional. Os constraints podem ser aplicados em vrios pontos do modelo RBAC, nas relaes entre usurios e papis (UA User Assignment) e entre papis e permisses (PA Permission Assignment). Alm disso, constraints tambm podem ser aplicados s sesses estabelecidas pelo usurio ao realizar o login no sistema.
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 18 de 51

Sentinel: um engenho Java para controle de acesso RBAC d Constraints so um conceito, por definio, genrico, flexvel e dependente de implementao. Entre alguns exemplos do que pode ser feito com constraints esto: Excluso mtua o exemplo clssico de constraints para permitir a separao de deveres. Atuaria em cima da relao entre usurios e papis ou no estabelecimento da sesso; Permitir ou negar o acesso em determinados horrios, de acordo com uma poltica estabelecida seria um exemplo de constraint em cima da relao papel permisses: as permisses s seriam vlidas em determinados horrios. Permitir que um marinheiro de baixo escalo (com um papel correspondente) exera o papel de comandante de navio (um papel com privilgios mais altos) apenas se ele for o ltimo remanescente no barco, em caso de acidente por exemplo. Isso seria possvel com um constraint em cima da relao usurio papel. Um constraint na relao usurio papel forar uma quantidade mxima de pessoas por papel, um chamado cardinality constraint. Um exemplo de utilizao no caso de papel de um gerente de projeto, em que s deve existir uma pessoa exercendo-o. Permitir ou negar o acesso quando o usurio utilizar o sistema a partir de algumas origens especficas de mquinas no confiadas na rede, por exemplo. Isso seria caracterizado como um constraint em cima do estabelecimento da sesso do usurio.

Constraints tambm podem ser vistos como sentenas em alguma linguagem formal apropriada [AS00] [GI96], mas vrios estudos seminais da rea [SCYF96] fazem um tratamento informal do conceito, ficando uma modelagem mais especfica como sendo a cargo da implementao.

3.3 Modelos RBAC do NIST

RBAC ganhou gradualmente mais apoio da comunidade acadmica e comercial, com diversas implementaes aparecendo no mercado. Todavia, a inexistncia de um modelo padronizado para RBAC resultava em incerteza e ineficincia sobre seu significado e utilidade. Diversos trabalhos [SCYF96] [SFK00] [FBK99] comearam a propor um modelo padronizado para esse tipo de controle de acesso, que acabou resultando no modelo RBAC do NIST, o padro de fato para RBAC hoje. Esta seo traz a viso deste modelo, que utilizado na implementao do Sentinel. Notese que o padro definido pela NIST extenso e detalhado, sendo grande demais para reproduzir neste trabalho. Alm disso, no est no escopo deste trabalho as consideraes sobre modelos para administrao de sistemas RBAC. Desse modo, aqui sero expostos os pontos norteadores e principais classificaes do modelo, ficando o leitor interessado encarregado de consultar a literatura apropriada quando desejado.

3.3.1 Viso geral do modelo

RBAC um conceito rico e de certo modo aberto, indo de controles simples em um extremo a controles relativamente complexos e sofisticados no outro. Dessa forma, j foi reconhecido [SFK00] que um nico molde definitivo ou iria incluir demais ou excluir demais, de forma que o modelo RBAC organizado em quatro passos de recursos e funcionalidades crescentes. Estes nveis so cumulativos no sentido em que cada um inclui os requisitos do
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 19 de 51

Sentinel: um engenho Java para controle de acesso RBAC d nvel anterior da seqncia. Eles foram definidos e formalizados em um conjunto de artigos [SFK00] [SFGK01]. So eles: RBAC1: Core RBAC (tambm conhecido como Flat RBAC) RBAC2: Hierarchical RBAC RBAC3: Constrained RBAC

O recomendado da NIST para RBAC o RBAC3, o mais completo dos trs nveis.

3.3.2 RBAC1: Core RBAC

O Core RBAC ilustrado na Figura 3. Os recursos requeridos do Core RBAC so obrigatrios a qualquer implementao de RBAC, e so praticamente bvios. Este nvel prev apenas usurios, papis e permisses. Usurios (ou grupos de usurios) e permisses so

associados a papis.
Figura 3: Core RBAC

Uma permisso a aprovao de um modo de acesso em um ou mais objetos do sistema. Permisses so sempre positivas e conferem a capacidade do detentor da permisso a executar alguma operao no recurso do sistema. A natureza da permisso depende fortemente dos detalhes de implementao e da natureza do sistema. Por isso, um modelo geral de autorizao deve tratar, at certo ponto, as permisses como smbolos nointerpretados. A natureza exata das permisses em um sistema um ponto deixado em aberto por RBAC. Para exemplificar: Em um sistema operacional, as permisses poderiam envolver as operaes de leitura, escrita e execuo, e os objetos considerados como sendo arquivos; Em um sistema bancrio, as permisses poderiam envolver operaes mais complexas como dbito e crdito em um objeto representando uma conta bancria.

O RBAC1 define duas relaes bsicas: a relao entre usurios e papis (UA User Assignment), e a relao entre papis e permisses. Ambas so relaes many-to-many. O modelo RBAC no discorre sobre revogao de permisses ou de usurios de papis.
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 20 de 51

Sentinel: um engenho Java para controle de acesso RBAC d

3.3.3 RBAC2: Hierarchical RBAC

RBAC hierrquico ilustrado na Figura 4 - ele difere do RBAC1 somente na introduo da hierarquia de papis denominada como relao RH. Hierarquias de papis so comuns na discusso acadmica e na maior parte das implementaes existentes hoje.

Figura 4: Hierarchical RBAC

Hierarquias de papis so uma maneira natural de estrutura papis de forma a representar as responsabilidades de organizaes. Como exemplo disso, temos a Figura 5.

Figura 5: exemplo de hierarquia de papis e seus usurios

Matematicamente, hierarquias de papis so uma ordem parcial, possuindo propriedades de reflexo, transitividade e anti-simetria. Um usurio de um determinado papel possui todas as permisses de acesso que os papis inferiores a ele, do qual ele herda.
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 21 de 51

Sentinel: um engenho Java para controle de acesso RBAC d

3.3.4 RBAC3: Constrained RBAC

RBAC nvel 3 mostrado na Figura 6 e Figura 7, e adiciona o recurso de constraints, explicados anteriormente, ao modelo RBAC. Os constraints podem estar associados relao usurio papel e papel permisso ou ativao de papis dentro de sesses do usurio no sistema. O conceito de constraint genrico, como visto anteriormente. Por isso, o RBAC3 s especifica um tipo de constraint obrigatrio a ser apresentado pelo sistema: a separao de deveres, referente ao particionamento de tarefas e privilgios entre diferentes papis de modo a garantir que um nico usurio no tenha poder demais nas mos, diminuindo o risco de abuso. Apesar de s especificar esse tipo de constraint, qualquer outro tipo de constraint pode ser implementado, de acordo com as polticas de cada organizao e as caractersticas do engenho de controle de acesso. O nvel 3 de RBAC do padro prev dois tipos de separao de deveres: esttico e dinmico.

Separao de deveres esttico

Esse tipo de separao de deveres visa diminuir o conflito de interesses em um sistema baseado em papis ao no permitir que um mesmo usurio pertena a dois papis considerados mutuamente exclusivos. Exemplos desse tipo de papel j foram fornecidos anteriormente. A separao esttica porque ela sempre est ativa no sistema, agindo na relao usurio papel: se um usurio autorizado como membro de um papel, ele proibido de ser membro de um papel conflitante. Constraints so herdados na hierarquia de papis.

Figura 6: constraints para separao esttica de deveres (SSD)

Separao de deveres dinmico

Esse tipo de separao de deveres fornece a capacidade de tratar situaes de conflitos de interesse no momento em que o usurio estaria entrando no sistema como pertencente a
Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br Pgina 22 de 51

Sentinel: um engenho Java para controle de acesso RBAC d um papel. Ou seja, o constraint age sobre o estabelecimento da sesso do usurio dentro do sistema. Com a separao de deveres dinmica possvel que um usurio pertena a um conjunto de papis que no constituem conflito de interesse quando utilizados de modo independente, mas gerem preocupao se utilizados em conjunto.

Figura 7: constraints para separao dinmica de deveres (DSD)

Por exemplo, um usurio pode pertencer ao mesmo tempo aos papis Caixa e Supervisor de caixa, onde o supervisor tem a permisso de aceitar correes e retiradas maiores do caixa que guarda o dinheiro. Neste caso, uma mesma pessoa pode exercer os dois papis, mas no ao mesmo tempo: estar logado no sistema como Caixa e Supervisor de caixa permitiria-o retirar dinheiro sem uma inspeo de terceiros. Com a separao dinmica de deveres esse tipo de situao tratada. O usurio seria obrigado a escolher um dos dois papis para estar logado no sistema, no podendo utilizar ao mesmo tempo os direitos de ambos.

Autor: Cristiano Lincoln de Almeida Mattos lincoln@tempest.com.br Orientador: Andr Medeiros Santos alms@cin.ufpe.br

Pgina 23 de 51