Universidade de BrasliaInstituto de Cincias Exatas

Departamento de Cincia da Computao

Controle de Acesso Baseado em Papis naInformatizao de Processos Judiciais

Andr Thiago Souza da SilvaHugo Vasconcelos Saldanha

Monografia apresentada como requisito parcialpara concluso do Bacharelado em Cincia da Computao

OrientadorProf. Pedro A. D. Rezende

Braslia2006

Universidade de Braslia UnBInstituto de Cincias ExatasDepartamento de Cincia da ComputaoCurso de Bacharelado em Cincia da Computao

Coordenador: Profa. Cludia Nalon

Banca examinadora composta por:

Prof. Pedro A. D. Rezende (Orientador) CIC/UnBProf. Luiz Antnio da Frota Mattos CIC/UnBSr. Paulo Roberto da Silva Pinto Secretrio de TI/STF

CIP Catalogao Internacional na Publicao

Andr Thiago Souza da Silva.

Controle de Acesso Baseado em Papis na Informatizao de Pro-cessos Judiciais/ Hugo Vasconcelos Saldanha, Andr Thiago Souzada Silva. Braslia : UnB, 2006.66 p. : il. ; 29,5 cm.

Monografia (Graduao) Universidade de Braslia, Braslia, 2006.

1. controle de acesso, 2. RBAC, 3. certificado, 4. LDAP,5. processo, 6. segurana

CDU 004

Endereo: Universidade de BrasliaCampus Universitrio Darcy Ribeiro Asa NorteCEP 70910900Braslia DF Brasil

Universidade de BrasliaInstituto de Cincias Exatas

Departamento de Cincia da Computao

Controle de Acesso Baseado em Papis naInformatizao de Processos Judiciais

Andr Thiago Souza da SilvaHugo Vasconcelos Saldanha

Monografia apresentada como requisito parcialpara concluso do Bacharelado em Cincia da Computao

Prof. Pedro A. D. Rezende (Orientador)CIC/UnB

Prof. Luiz Antnio da Frota Mattos Sr. Paulo Roberto da Silva PintoCIC/UnB Secretrio de TI/STF

Profa. Cludia NalonCoordenador do Bacharelado em Cincia da Computao

Braslia, 11 de agosto de 2006

AgradecimentosAo professor Pedro Rezende, por suas valiosas contribuies, sugestes eorientaes para a realizao desse trabalho.

Ao Renato Bigliazzi, por sua inestimvel colaborao na elicitao dosrequisitos.

Ao professor Luis Antnio da Frota Mattos, por ter se mostrado sempreprestativo, at mesmo em situaes difceis.

Aos meus pais, Jos Eusbio e Bernadete, pela educao e incentivo queme proporcionaram.

A Ana Cludia, pelo amor e compreenso que demonstrou durante osmeus momentos ausentes.

Aos meus pais, Saldanha e Ftima, que me ensinaram o valor do estudo,do trabalho e da honestidade, e por sempre me darem o suporte necessrio.

Aos meus irmos, Igor e Vitor, que conviveram comigo durante esse tra-balho.

A Elisa, pela pacincia e compreenso durante os momentos difceis.

ResumoO acesso justia por meio eletrnico tem aumentado bastante nos ltimosanos. Alm de permitir um maior acesso, a informatizao possibilita maiorceleridade no andamento da mesma. Com a disponibilizao das informa-es pertencentes a processos por meio eletrnico, necessrio implemen-tar um controle de acesso que reflita a legislao vigente correspondente.Este trabalho modela o controle de acesso a processos digitais de acordo como modelo RBAC, utilizando a ferramenta livre MACA, com uma modificaopara prover autenticao via certificados digitais.

O modelo RBAC foi escolhido por proporcionar maior facilidade na admi-nistrao das permisses a recursos em sistemas de grande porte, alm derefletir, na sua implementao, os papis existentes na organizao, facili-tando seu entendimento. A autenticao via certificados digitais propostapor utilizar criptografia forte, alm de haver uma tendncia pela adoo,por parte de rgos pblicos, do uso de certificados digitais, graas insti-tuio da Infraestrutura de Chaves Pblicas Brasileira (ICP-Brasil).

Palavras-chave: controle de acesso, RBAC, certificado, LDAP, processo,segurana

AbstractAccess to justice by eletronic means has increased greatly in the past fewyears. Besides allowing a greater access, it makes possible a greater agi-lity in its course. With information from legal proceedings more accessible,its important to implement an access control that implements the existinglegislation concerning the legal proceedings. The present work models anaccess control to eletronic legal proceedings according to RBAC proposedstardard, making use of MACA, with modifications to provide authentica-tion with digital certificates.

RBAC was chosen because it makes easy to administrate permissionsto resources in large scale systems. It also reflects the existings roles inthe organization, making its understanding easier. Authentication withdigital certificates is proposed because it makes use of strong cryptography,besides the existence of a tendency for the use of digital certificates by thepublic organizations, thanks to the creation of Infraestrutura de ChavesPblicas Brasileiras (ICP-Brasil).

Keywords: access control, RBAC, certificate, LDAP, legal proceedings, se-curity

Sumrio

Lista de Figuras 9

Captulo 1 Introduo 10

Captulo 2 Modelos de Controle de Acesso 152.1 Conceitos e Terminologia . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Autenticao e autorizao . . . . . . . . . . . . . . . . . 162.1.2 Usurios, sujeitos, objetos, operaes e permisses . . . 162.1.3 Princpio do menor privilgio . . . . . . . . . . . . . . . 172.1.4 Monitor de referncia . . . . . . . . . . . . . . . . . . . . 18

2.2 Polticas, modelos e mecanismos . . . . . . . . . . . . . . . . . 192.2.1 Modelo de Bell-LaPadula . . . . . . . . . . . . . . . . . . 192.2.2 Modelo Clark-Wilson . . . . . . . . . . . . . . . . . . . . 20

2.3 Consideraes sobre o controle de acesso compulsrio . . . . . 212.4 Consideraes sobre o controle de acesso discricionrio . . . . 22

Captulo 3 O modelo RBAC Role-Based Access Control 233.1 Viso Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Permisses . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Comparao entre papis e Listas de controle de acesso 253.1.3 Ativao de papis . . . . . . . . . . . . . . . . . . . . . 27

3.2 Definio formal . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Modelo RBAC do NIST . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Viso geral . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.2 O ncleo do RBAC . . . . . . . . . . . . . . . . . . . . . . 293.3.3 RBAC Hierrquico . . . . . . . . . . . . . . . . . . . . . 313.3.4 Componente de restries estticas do RBAC . . . . . . 323.3.5 Componente de restries dinmicas do RBAC . . . . . 32

Captulo 4 O MACA - Middleware de Autenticao e Controle deAcesso 334.1 Os contextos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 As regras de autorizao . . . . . . . . . . . . . . . . . . . . . . 344.3 O modelo de autorizao contextual do MACA . . . . . . . . . 354.4 Arquitetura e implementao do MACA . . . . . . . . . . . . . 364.5 O algoritmo de deciso de acesso do MACA . . . . . . . . . . . 39

Captulo 5 Modelo de acesso implementado como prova de con-ceito 415.1 O modelo de acesso proposto . . . . . . . . . . . . . . . . . . . . 425.2 Aspectos de implementao . . . . . . . . . . . . . . . . . . . . 47

5.2.1 Gerao de chaves . . . . . . . . . . . . . . . . . . . . . . 475.2.2 Autenticao bidirecional usurio-servidor MACA . . . 485.2.3 Autenticao bidirecional MACA - LDAP . . . . . . . . 52

5.3 Autorizaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Captulo 6 Desdobramentos 576.1 JuRisBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Documentaes . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Captulo 7 Concluso 64

8

Lista de Figuras

2.1 Viso do controle de acesso compulsrio . . . . . . . . . . . . . 22

3.1 Relacionamento entre usurios, papis e permisses . . . . . . 24

4.1 Arquitetura do MACA . . . . . . . . . . . . . . . . . . . . . . . 364.2 rvore de informaes de diretrio . . . . . . . . . . . . . . . . 374.3 Modelo de controle de acesso do SSC . . . . . . . . . . . . . . . 38

5.1 Fluxo de caminhamento do processo . . . . . . . . . . . . . . . 435.2 Hierarquia de papis considerada na implementao do mo-

delo de acesso aos processos . . . . . . . . . . . . . . . . . . . . 455.3 Do lado esquerdo esto representados os recursos acessveis,

com as respectivas operaes associadas.Do lado direito, asautorizaes contextuais associadas a cada papel. . . . . . . . 46

5.4 Tela de Autenticao . . . . . . . . . . . . . . . . . . . . . . . . 485.5 Utilizao do keystore para realizar a autenticao . . . . . . . 495.6 Verificao do retorno do mtodo authenticate() . . . . . . 505.7 Implementao do desafio do protocolo SSL no cliente . . . . . 515.8 Modificaes na classe PrincipalAuthenticator . . . . . . 515.9 Modificaes na classe User . . . . . . . . . . . . . . . . . . . . 525.10 Modificaes no cdigo do MACA para autenticao . . . . . . 545.11 Exemplo de acesso no sistema . . . . . . . . . . . . . . . . . . . 555.12 Cdigo do mtodo autorizaAcesso() . . . . . . . . . . . . . 555.13 Diagrama de seqncia com as interaes entre os objetos du-

rante a requisio de acesso a um determinado recurso . . . . 56

6.1 Tela Principal da Aplicao . . . . . . . . . . . . . . . . . . . . 586.2 Tela de Cadastro de Processo . . . . . . . . . . . . . . . . . . . 586.3 Tela de Cadastro de Parte . . . . . . . . . . . . . . . . . . . . . 596.4 Tela de Pesquisa de Processo . . . . . . . . . . . . . . . . . . . 596.5 Tela de Movimentao de Processo . . . . . . . . . . . . . . . . 606.6 Tela proibindo acesso ao mdulo de movimentao de processo 61

Captulo 1

Introduo

O acesso justia por meio eletrnico tem aumentado bastante nos ltimosanos. O uso de meio digitais no Judicirio, alm de possibilitar mais ummeio de acesso justia, prov uma maior celeridade na prestao jurisdi-cional. No faltam iniciativas, que se espalham por todo o pas. As inicia-tivas locais que vem sendo tomadas por tribunais brasileiros, individual eseparadamente, tm o intuito de agregar uma srie de valores sua pres-tao jurisdicional. Entre estes valores, esto a celeridade, a publicidade, aoperosidade, a praticidade e a universalidade. H tambm uma iniciativade mbito nacional para padrozinar a forma como essa informatizao disponibilizada, principalmente com relao ao sigilo e autenticidade dosdados produzidos nessas aplicaes.

Neste contexto, vrios tribunais j disponibilizam seus sites na Inter-net com informaes gerais sobre o andamento de processos e sentenas. possvel tambm cadastrar-se em algum desses sites e ser notificado auto-maticamente sempre que um processo de interesse seja movimentado.

Entretanto, essas iniciativas s contemplam funcionalidades de infor-mao e documentao. A digitalizao de processos ainda um caminho aser percorrido, porm j existem muitos esforos neste sentido:

O Supremo Tribunal Federal STF implementou o projeto e-STF quepermitiu a petio por meio eletrnico, fax ou similar; e o Projeto deInteligao Informatizada do Poder Judicirio o Infojus, que ofereceuma infra-estrutura em comum de redes de comunicao para os r-gos do Poder Judicirio. Alm disso, sua pgina na internet se colocacomo um dos dez melhores sistemas do Pas.

O Superior Tribunal de Justia STJ desenvolve estudos na tenta-tiva de eliminar o papel e utilizar o sistema on-line at mesmo parapeties.

O Projeto de Lei n. 5.828/2001, aprovado pela Cmara dos Deputados,dispe sobre a informatizao do processo judicial, admitindo o usode meio eletrnico na comunicao de atos e a transmisso de peasprocessuais.

10

Todo esse cenrio de informatizao citado deve respeitar, alm das boasprticas de segurana, a jurisprudncia existente. Ou seja, a justia in-formatizada deve ser um espelho, na medida do possvel, da justia domundo da vida. No andamento de um processo vrias regras processu-ais devem ser respeitadas: h todo um caminho por onde o processo devepassar, prazos a serem respeitados, alm de um conjunto determinado deatores jurdicos responsveis pelo andamento do processo, alguns habili-tados a decidir, sob determinadas condies, sobre os rumos que o mesmopode tomar.

De forma simplificada, o caminho do processo formado por um conjuntode estados pelo qual ele passa: Petio Inicial, Deferimento, Contestao,etc., com prazos a serem respeitados. Para fazer o processo caminhar porentre estados, h um conjunto de atores que devem atuar sobre o processo.Alm disso, a administrao de um processo extremamente afunilada aoredor da figura do Juiz, sendo que a maioria dos atos levam a sua assina-tura. o rito processual.

A informatizao do rito processual deve seguir as mesmas regras. Nessesentido, surge o problema de como controlar e administrar o acesso dos ato-res jurdicos aos processos. O controle de acesso importante no s para amanuteno do sigilo de informaes constantes no processo, quando apli-cvel, mas tambm para definir, dentre os atores jurdicos que possam vira cena, quais esto legal ou legitimamente autorizados, em determinadomomento, a realizar determinada ao sobre determinado processo.

Esse controle envolve no s aos atores jurdicos que atuam no trmitedo processo, mas tambm a intermediao de sistemas computacionais quepossibilitam o acesso de tais atores ao processo, para cumprimento do rito.Sistemas computacionais que, por sua vez, tambm tm suas regras e me-canismos de acesso, seus atores (usurios, administradores), etc., esses viade regra representados em vrias camadas de codificao.

Assim, o uso de tecnologia de informao em processos judiciais deve tercomo requisito bsico a definio de um modelo para o controle de acesso aprocessos que respeite a autonomia e as prerrogativas dos distintos atoresem diferentes sistemas de forma que, pelo menos idealmente, as relaese interdependncias internas dos sistemas o jurdico-fim e o tecnolgico-meio no interfiram de forma despropositada, indevida, subreptcia oudescontrolada um no outro.

Surgem, ento, questes relativas concepo de um tal modelo de con-trole de acesso, que possa satisfazer os requisitos citados. Podemos separaresses requisitos em dois grupos, ou instncias. A primeira refere-se auto-mao de decises sobre autorizar ou no o acesso em determinado modo adeterminado processo ou pea processual, e por qual lgica autorizativa. Asegunda referente ao processo de se administrar as polticas de controlede acesso, a partir das quais tais decises so executadas.

Sobre a lgica de autorizao, estratgias e diretrizes conflitantes po-dem ser aplicadas. Ademais, no domnio de aplicao em tela, ou seja, nainformatizao processual judiciria, tais conflitos refletem uma tenso na-tural entre o legal e o legtimo. Por um lado, o acesso ao processo deve ser

11

restrito s partes interessadas, respeitando os aspectos legais existentes(caminho do processo, restries de prazo) e definindo quais usurios estoaptos a realizar aes sobre determinados processos. Por outro lado, o con-trole de acesso no pode prejudicar a prestao do servio aos interessados,devendo garantir a celeridade da justia, que talvez seja o principal objetivoda informatizao de processos, e que respeita o princpio constitucional daeficincia1.

Desta forma, impor uma poltica muito proibitiva, ou engessada, querpela aplicao, pelo sistema ou por suas arquiteturas, acaba por prejudi-car no s o acesso ao servio informatizado, mas tambm, a mdio e longoprazos, o bom desempenho de quem responde pela informatizao; j umapoltica demasiadamente permissiva pode violar os aspectos legais envolvi-dos ou, pior, abrir novas brechas para fraudes processuais, ainda mais insi-diosas e potencialente difceis de erradicar, porque invisveis ou difceis derastrear. Assim, no escopo de um planejamento adequado informatizaodo judicirio, deve-se buscar um modelo adequado, onde cada autorizao concedida/proibida no momento exato, de acordo com a necessidade e o di-reito do usurio, levando em conta a situao (contexto) existente durante oacesso. Levando-se, tambm, em conta a complexidade ontolgica dos ritosprocessuais, um modelo que leve em conta a escalabilidade no espao deregras, prerrogativas, atores e aes que compem a poltica de segurana(da qual a de controle de acesso faz parte), que possa atender demandareal sem inviabilizar a administrao dessas polticas

Na administrao da poltica de controle de acesso, a questo da raci-onalidade se torna importante. Normalmente, um processo jurdico infor-matizado acessado em um sistema distribudo, constitudo de diversasaplicaes e diversas bases de dados, nas mais variadas plataformas, ondecada sistema j possui um modelo de controle de acesso. Conceber um mo-delo que integre tais diversidades, sem inviabiliz-las, um grande desafio.

Seria possvel conceber um mecanismo de administrao de polticas decontrole unificada, que integre de forma coerente os diferentes sistemas, en-globando suas funcionalidades sem inviabilizar sua eficcia no processo? claro que a resposta depende, em grande parte, das plataformas existentes,de seus regimes de padronizao e interfaces de programao e controle.Tanto melhor se possibilitem a interoperabilidade com outros sistemas eportabilidade a outras plataformas, principalmente no que se refere ao con-trole de acesso (Motta, 2003).

No obstante, para que esse controle de acesso seja realmente efetivo, aautenticao perante o mecanismo que prov esse servio unificado deve serfeita de maneira adequada, e de forma a forneer os meios mais abrangen-tes possveis de se aferir sua confiabilidade. Conceitualmente, para atingiresse requisito, o modelo deve fazer uso do mecanismo de autenticao atra-vs de criptografia assimtrica, com utilizao de certificados digitais, porser esse o mecansimo que demanda o mnimo possvel em relao a premis-sas de sigilo (Schneier, 1996). A instituio da Infraestrutura de Chaves

1Constituio Federal, artigo 37

12

Pblicas Brasileira (ICP-Brasil)2 veio aproximar ainda mais esse cenrionacionalmente, fazendo com que a criptografia assimtrica, alm da auten-ticao, seja utilizada para assinar documentos eletronicamente, provendoautenticidade, integridade e, quando aplicvel, o no repdio (Schneier,1996).

O objetivo principal do trabalho a construo de um modelo de controlede acesso baseado em papis (RBAC - Role-Based Access Control) contextu-alizado na informatizao de processos que contemple os requisitos apre-sentados, com o intuito de controlar o acesso a processos do Juizado Espe-cial . Como objetivo secundrios temos: adaptao da arquitetura do MACA(Modelo de Autorizao Contextual para o Controle de Acesso Baseado emPapis) (Motta, 2003) para conter autenticao via certificados digitais; e aimplementao de um sistema prottipo que possua os requisitos citados.

A escolha pelo controle de acesso baseado em papis justificada peloconjunto de caractersticas que esse modelo possui e que atendem os requi-sitos necessrios para a construo/implementao do modelo desejado.

Primeiramente, o modelo d suporte ao princpio do privilgio mnimo.Conforme esse princpio, para cada usurio no so atribudas permissesalm daquelas que ele precisa para a realizao de sua funo ou tarefa.Isso evita o problema de um indivduo ter a capacidade de realizar funesdesnecessrias; ou seja, um usurio s deve possuir as autorizaes indis-pensveis, mnimas para ele realizar as tarefas ou acessar os dados que elenecessita. Esta caracterstica fundamental no contexto de acesso aos pro-cessos informatizados, onde cada usurio, em um determinado momento,s pode ser autorizado a realizar as funes que se espera que ele realize enada mais.

Em segundo lugar, est a questo da administrao da poltica de segu-rana do sistema, conforme citamos anteriormente. O modelo de controlede acesso baseado em papis permite que a administrao da poltica sejacentralizada (Ferraiolo et al., 2003). Uma vez que os papis estejam defini-dos, e as transaes que esses papis podem realizar estejam estabelecidasdentro do sistema de acesso, estas transaes tendem a permanecer rela-tivamente constantes ao longo do tempo, evoluindo junto com o sistemade aplicaes. As atividades administrativas passam a ser, basicamente,a insero ou a revogao de membros no conjunto de papis especificadosdentro do sistema. Quando um indivduo entra na organizao, o adminis-trador simplesmente o insere em um ou mais papis existentes. Quando afuno de uma pessoa muda dentro da organizao, basta alterar os papisligados a essa pessoa. Quando uma pessoa deixa a organizao, todos osseus usurios que so membros de papis so removidos. Por fim, como ospapis so utilizados para categorizar autorizaes de funes organizaci-onais espec ficas, quando as autorizaes e responsabilidades das funesmudam, basta alterar as autorizaes associadas aos respectivos papis.

Ou seja, o controle de acesso baseado em papis facilita a administra-o centralizada por interpor os papis entre usurios e autorizaes, o que

2Medida Provisria n. 2.200-2, de 24 de Agosto de 2001

13

reduz a complexidade e o custo administrativo do controle de acesso, espe-cialmente quando comparado com outros modelos. Isso viabiliza a adminis-tra o de uma poltica de acesso detalhada, onde h um grande nmerode usurios e recursos que acessam mltiplos sistemas, situao em que seenquadra o contexto de processos informatizados.

Por fim, a existncia de aplicaes prticas do controle de acesso ba-seado em papis em grandes organizaes um outro fator determinantepara a escolha do modelo baseado em papis. A experincia do Institutodo Corao, em So Paulo, com mais de 2500 usurios fazendo uso, em umambiente distribudo, do MACA (Motta, 2003), que um software livre soblicena GPL, mostra que realmente possvel aplicar o modelo baseado empapis realidade.

Com a utilizao do MACA, busca-se explorar o potencial do modelo dedesenvolvimento colaborativo, sob regime de licenciamento livre, para al-canar maior eficincia no atendimento demanda instrumental de meca-nismos de segurana prprios para integrao e/ou informatizao de siste-mas processuais na esfera judiciria, atualmente reprimida, alavancando eprovendo assim a autonomia do usurio, em relao a fornecedores de com-ponentes, para controlar sua prpria poltica de segurana, autonomia estaque a prpria essncia desta segurana.

Nos prximos captulos, sero desenvolvidos os diversos conceitos perti-nentes modelagem do controle de acesso de processos judiciais: o conceitode controle de acesso propriamente dito, com a exposio de alguns modelosde uso consagrado e o RBAC; o padro de RBAC conforme proposto pelo Na-tional Institute of Science and Technology - NIST dos EUA; uma descrioda arquitetura do MACA e as modificaes realizadas; e uma exposio deuma modelagem do acesso a processos judiciais, mostrando a estrutura or-ganizacional e possveis papis do negcio, relacionados aos atores jurdicosdo domnio de aplicao especfico para o qual se implementou um prottipode sistema, com suas resposabilidades e autorizaes.

14

Captulo 2

Modelos de Controle de Acesso

2.1 Conceitos e TerminologiaO controle de acesso a maneira pela qual o acesso (utilizao, modifica-o, leitura, etc.) a determinado recurso concedido ou proibido de algumaforma (Ferraiolo et al., 2001). O controle de acesso pode no apenas de-finir quem tem acesso a um determinado recurso, mas tambm qual tipode acesso. O controle pode estar embutido dentro do sistema operacional,incorporado a aplicaes ou pode ser implementado por meio de pacotes desegurana. Pode, ainda, ser implementado internamente ao sistema com-putacional a ser protegido ou ser implementado em dispositivos externosao sistema.

O controle de acesso pode tomar diferentes formas. Alm de determi-nar se um usurio tem permisso para utilizar um recurso, o controle deacesso pode determinar quando e como esse recurso pode ser utilizado. Porexemplo, um usurio pode ter acesso a uma rede apenas durante o expe-diente da empresa. Um processo executado tem permisso somente paraler, e no para escrever, em um arquivo. Dependendo do nvel de seguranaexigido por uma organizao, um sistema corporativo pode exigir controlesmais complexos, como requerer dois uma mais funcionrios identificados nosistema ao mesmo tempo para realizar um operao de alto risco.

Sendo um dos vrios aspectos pertencentes a uma soluo de seguranacomputacional, o controle de acesso possui propsitos semelhantes aos de-mais mecanismos de segurana. Todos eles tm como objetivo garantir si-gilo, integridade e/ou disponibilidade de recursos. No controle de acesso, osigilo e/ou integridade da informao so crticos. Para a condio de sigilo necessrio que somente usurios autorizados tenham permisso para lera informao. J na condio de integridade, apenas usurios autorizadospodem alterar informaes de maneira tambm autorizada. Essas duascondies so bem claras no controle de acesso. Menos bvia a condiode disponibilidade, mas tambum possui um importante papel: um usu-rio que adquire acesso no autorizado a um sistema tem menos dificuldadepara torn-lo indisponvel.

Os objetivos do controle de acesso so comumente descritos em termos

15

de proteo para recursos do sistema contra acesso inapropriado ou inde-sejado de usurios. De uma perspectiva comercial, esse objetivo tambmpode ser descrito em termos de otimizar o compartilhamento dos recursose informaes. Afinal, a grande motivao da tecnologia de informao fazer com que as informaes estejam disponveis para usurios e aplica-es de maneira eficiente, alm de segura. Quanto maior for a capacidadede compartilhamento da informao, maior a produtividade e utilidade dosistema.

2.1.1 Autenticao e autorizaoAutorizao e autenticao so dois conceitos fundamentais na rea de con-trole de acesso. So conceitos distintos mas interdependentes, de forma quea autorizao a um determinado recurso , na verdade, dependente da au-tenticao.

Autenticao o processo que determina que a identidade mostrada porum usurio legtima. A autenticao baseada em um (ou mais de um)dos seguintes fatores:

Algo que sabemos, como por exemplo, uma senha ou nmero de iden-tificao pessoal;

Algo que possumos, como um carto inteligente ou uma chave;

Algo que somos ou uma caracterstica fsica como uma impresso di-gital, padro de retina ou uma caracterstica facial.

Enquanto a autenticao um processo de determinar quem somos parao sistema, autorizao determina o que podemos a fazer. Autorizao refere-se a uma deciso do tipo sim ou no que determina se um usurio temo acesso garantido a um recurso do sistema (Ferraiolo et al., 2003). Umsistema de informao deve manter alguma relao entre identificadoresde usurios e recursos do sistema, possivelmente anexando uma lista deusurios autorizados para os recursos ou armazenando uma lista de recur-sos acessveis com cada identificador de usurio.

De qualquer forma, deve-se notar que a autorizao necessariamentedepende da realizao da autenticao. Se o sistema no for capaz de tercerteza a respeito da identidade de determinado usurio, no haver umamaneira correta de determinar se o usurio deve ou no acessar o recurso.

2.1.2 Usurios, sujeitos, objetos, operaes e permis-ses

Praticamente qualquer modelo de controle de acesso pode ser formalmentedefinido utilizando as noes de usurios, sujeitos, objetos, operaes e per-misses, e as relaes entre estas entidades. Desta forma, importante acompreenso destes termos.

16

O termo usurio refere-se pessoa que interage com o sistema computa-cional. Em muitos projetos, possvel para um nico usurio possuir mlti-plos identificadores e estes identificadores podem estar ativos simultanea-mente e so os mecanismos de autenticao que possibilitam a ocorrnciadessa situao.

Um sujeito (subject) um processo de computador agindo em benefciode (ou comportando-se como) um usurio. Na realidade, toda e qualquerao de um usurio em sistema computacional realizada por meio de al-gum programa executando em um computador. Um usurio pode ter ml-tiplos sujeitos em execuo, mesmo se o usurio s possui um identificador(login). Por exemplo, enquanto um usurio acessa uma pgina na Web utili-zando um navegador, um agente de e-mail pode estar executando como umdaemon, consultando um determinado servidor periodicamente, em buscade novas mensagens. Cada um dos programas do usurio um sujeito, eo acesso realizado por cada um dos programas ser checado a fim de segarantir que o usurio que invocou os programas realmente tem acesso aeles.

Um objeto pode ser qualquer recurso acessvel em um sistema computa-cional, o que inclui arquivos, perifricos como impressoras, banco de dados,e at mesmo entidades de granularidade fina como campos individuais emregistros de banco de dados. Objetos so geralmente vistos como entidadespassivas que contm ou recebem informaes, embora seja possvel tratarprogramas, impressoras e outras entidades ativas como objetos.

Uma operao um processo ativo invocado por um sujeito. As opera-es podem ter diversos nveis de abstrao incluindo operaes maiscomuns como escrita, leitura, alterao at operaes mais complexas edependentes da natureza de cada sistema ou domnio de aplicao, comooperaes de movimentao de um processo judicirio, por exemplo.

Permisses (ou privilgios) so autorizaes para realizar alguma aono sistema, ou seja, refere-se a alguma forma de combinao entre um ob-jeto e uma operao. Uma determinada operao aplicada a dois objetosdiferentes representa duas permisses distintas e, de forma similar, duasoperaes diferentes aplicadas ao mesmo objeto representam duas permis-ses diferentes.

2.1.3 Princpio do menor privilgioO princpio do menor privilgio uma prtica administrativa de controlede acesso por meio da qual as permisses so associadas aos usurios de talforma que a cada usurio so dadas to somente as permisses necessriaspara realizar a funo que o projeta como usurio do sistema. O princpiodo menor privilgio evita o problema de um indivduo possuir a capacidadede realizar aes desnecessrias e potencialmente prejudiciais ao sistema,aes que podem surgir como um efeito colateral da associao de permis-ses desejadas. A grande discusso presente nesta rea de estudos comoassociar o conjunto de permisses configurveis no sistema ao agregado de

17

funes ou responsabilidades que correspondem a um papel de um usurio,ou a um sujeito que age em benefcio deste usurio.

O princpio do menor privilgio prov uma maneira racional de onde ins-talar os limites de separao que so providos pelo mecanismo de controlede acesso.

A aderncia estrita ao princpio do menor privilgio requer que um indi-vduo possua diferentes nveis de permisses em momentos diferentes, de-pendendo da tarefa ou funo sendo realizada. Deve-se reconhecer que emalguns ambientes e com algumas permisses, restringir permisses porqueelas so nominalmente desnecessrias pode ser inconveniente para o usu-rio ou colocar uma carga adicional sobre os administradores e complexidadeno sitema, aumentando a chance da ocorrencia de falhas de segurana dedifcil diagnstico. Entretanto, a permisso de privilgios excessivos quepotencialmente podem ser explorados para quebrar a proteo existente,seja por meio da integridade ou da confidencialidade, que possibilite ou atestimule o desvio de funo ou abuso de autoridade, sempre que possveldeve ser evitada.

2.1.4 Monitor de refernciaO monitor de referncia um conceito abstrato, em que as tentativas deacessos que sujeitos realizam em objetos so autorizadas baseados em in-formaes contidas em uma base de dados de controle de acesso (Ferraioloet al., 2003). O monitor de referncia representa a poro de um sistemaque responsvel pela garantia da poltica de segurana do sistema no quetange ao controle de acesso. O banco de dados de controle de acesso o res-ponsvel pela manuteno dessa poltica, em termos de atributos ligadosa sujeitos e a objetos e respectivos direitos de acesso. Quando um sujeitotenta realizar alguma operao em um determinado objeto, o monitor dereferncia deve realizar algum tipo de verificao, geralmente comparandoos atributos do sujeito com aqueles pertencentes ao objeto.

O monitor de referncia no estipula uma poltica especfica para o sis-tema e muito menos uma implementao em particular. O monitor de refe-rncia, entretanto, define um framework que tem sido muito utilizado para o projeto, desenvolvimento e implementao de sistemas de seguranae que tem funcionado como base de avaliao de grau de confiana que podeser associado a um sistema computacional.

Os requisitos abstratos de um monitor de referncia so descritos emtrs princpios fundamentais de implementao, mostrados a seguir.

1. Completude: o monitor de referncia deve sempre ser invocado e deveser impossvel de desvi-lo. Este princpio requer que um sujeito spossa referenciar um objeto invocando o monitor de referncia.

2. Isolamento: o monitor de referncia deve ser prova de falsificao.Este princpio afirma que a funo mediador de acesso intranspon-vel, ou sejam deve ser impossvel para um estranho ao sistema atacar

18

o mecanismo de controle de acesso de forma que afete o desempenhoda verificao de autorizao.

3. Verificabilidade: deve ser possvel de demonstrar que foi implemen-tado corretamente. Este princpio pode ser alcanado por meio decritrios de projeto e prticas de engenharia de software (Ferraioloet al., 2003). A idia que o monitor de referncia seja to pequenoe to simples quanto possvel, excluindo qualquer funcionalidade daqual a segurana do sistema no seja dependente e reduzindo-o a umpequeno conjunto de interfaces.

Estes princpios fornecem um guia arquitetural para o projeto e para oprocesso de desenvolvimento de um sistema de controle de acesso. O grauem que o sistema se relaciona com esses princpios serve como uma medidado nvel de confiana e correo dos controles de segurana do sistema.

2.2 Polticas, modelos e mecanismos

2.2.1 Modelo de Bell-LaPadulaO modelo de Bell-LaPadula (Bell and LaPadula, 1973) uma descrio for-mal dos caminhos permitidos para o fluxo da informao em um sistema. Oobjetivo do modelo identificar as formas de comunicao permitidas, emque importante a preservao de sigilo. O modelo tem sido utilizado paradefinir os requisitos de segurana para sistemas que tratam, concorrente-mente, dados com diferentes nveis de sensibilidade. Esse modelo servepara formalizar polticas de segurana multinvel.

Bell and LaPadula (1973) utilizam mquinas de estados finitos para aformalizao de seu modelo. So definidos vrios componentes da mquinade estados finitos, que definem, de maneira formal, o que significa um deter-minado estado ser seguro, e consideram as transies que so permitidasde tal forma que ao deixar um estado seguro, um estado inseguro nuncapossa ser alcanado.

No modelo, so includos nveis de segurana que refletem sistemas desegurana militar: cada sujeito possui um nvel de segurana mximo, ecada objeto tem uma classificao.

1. Propriedade da Segurana Simples: nenhum sujeito possui acesso deleitura a qualquer objeto que possua uma classificao maior que onvel de segurana do sujeito; e

2. A Propriedade Estrela (*): nenhum sujeito possui acesso de escritaa um objeto cujo nvel de segurana for diferente ao nvel correntedaquele sujeito; e nenhum sujeito possui direito de leitura em objetoscujo nvel de segurana seja maior que o nvel de segurana correntedaquele sujeito.

19

No modelo militar, a propriedade da segurana simples afirma que umusurio com um determinado nvel de segurana no possui a permissode leitura de informao cujo nvel esteja acima do seu; por exemplo, umusurio com nvel de segurana secreto no pode ler documentos classifi-cados como ultra-secretos. Da mesma forma, a propriedade estrela afirmaum usurio operando em determinado nvel de segurana s pode escreverinformao naquele nvel ou acima; por exemplo, se um usurio for iden-tificado como do nvel secreto, programas e processos operados por aqueleusurio no so permitidos escrever informaes em nveis de classificaomais baixos, como confidencial, mas podem escrever em nveis mais altos,como ultra-secreto.

2.2.2 Modelo Clark-WilsonClark and Wilson (1987) documentaram uma viso generalizada da polticade segurana comercial, demonstrando o quanto elas diferem das polticasde segurana militares. Eles propuseram dois princpios como os mais im-portantes na busca de garantia para manuteno da integridade: transa-es bem formadas e separao de responsabilidades.

Transaes bem formadas limitam a forma que os usurios podem mo-dificar os dados, assegurando que todos os dados que iniciem em um estadovlido permanecero vlidos aps a execuo da transao. A unidade b-sica de controle de acesso do modelo uma tripla, composta por usurio,procedimento de transformao e um item de dados confinado. Um proce-dimento de transformao uma transao e um item de dados confinado aquele cuja integridade deve ser preservada.

O princpio da separao de responsabilidades assegura a consistnciade mudanas realizadas em dados crticos, o que previne que usurios au-torizados realizem modificaes imprprias, contribuindo, assim, para a in-tegridade dos dados. A separao de responsabilidades aplicada por meioda diviso de operaes em diversas suboperaes e estabelecendo que dife-rentes pessoas realizem cada uma dessas suboperaes. Por exemplo, numprocesso de compra de uma determinada mercadoria envolvendo os passosde autorizao do pedido de compra e autorizao do pagamento; por meioda separao de responsabilidades, exige-se que cada uma das partes sejarealizada por uma pessoa diferente e que o segundo passo s se concretizeaps a ocorrncia do primeiro.

Diferentemente do modelo de segurana de Bell and LaPadula (1973),cuja mediao de acesso reside no ncleo do sistema, a abordagem de Clarkand Wilson (1987) impe o controle ao nvel da aplicao. Esta diferena resultante dos objetivos pretendidos por cada um dos modelos. O modelode segurana multinvel, cuja base o modelo de Bell-LaPadula, pretendecontrolar o fluxo de informao, definido em termos de operaes de leiturae escrita. J o modelo comercial de integridade, como definido por Clarkand Wilson (1987), deve assegurar que a informao s modificada deforma autorizada por pessoas autorizadas.

20

2.3 Consideraes sobre o controle de acessocompulsrio

O controle de acesso compulsrio uma poltica de acesso suportada por sis-temas que processam dados com elevada sensibilidade, como por exemploinformaes de governo ou dados sigilosos de corporaes.

Sistemas que provem o controle de acesso compulsrio devem associarrtulos de sensibilidade a todos os sujeitos (usurios, programas) e a to-dos os objetos (arquivos, diretrios, dispositivos, etc.) do sistema. O rtulode sensibilidade do usurio especifica o nvel de confiana associado queleusurio. O rtulo de sensibilidade de um objeto especifica o nvel de con-fiana que o usurio deve possuir para ser capaz de acessar aquele objeto.Desta forma, o controle de acesso compulsrio utiliza rtulos de sensibili-dade para determinar quem pode acessar qual informao no sistema.

Os rtulos em conjunto com o controle de acesso compulsrio implemen-tam uma poltica de segurana multinvel, como aquela formalizada porBell and LaPadula (1973).

Em um sistema de controle de acesso compulsrio, todas as decises deacesso so realizadas pelo sistema. A deciso para negar ou permitir oacesso a um objeto, como por exemplo um arquivo, envolve uma interaoentre as seguintes entidades:

O rtulo do sujeito:

SUPER SECRETO;

O rtulo do objeto por exemplo um arquivo A:

SECRETO;

Uma solicitao de acesso por exemplo, uma tentativa de leitura noarquivo.

Quando realizada a tentativa de leitura do arquivo A, o sistema com-para o rtulo de sensibilidade do sujeito com o rtulo do arquivo para deter-minar se o sujeito tem permisso de leitura do arquivo.

Para ser possvel a leitura de um objeto, o nvel de sensibilidade do su-jeito deve dominar o nvel de sensibilidade do objeto, ou seja, o rtulo dosujeito deve ser igual ou superar o rtulo do objeto. Por exemplo, se o rtulodo arquivo SECRETO, para ser possvel a leitura, o rtulo do sujeito deveser SECRETO ou maior do que SECRETO.

Para ser possvel a escrita, o nvel de sensibilidade do objeto deve domi-nar o nvel de sensibilidade do sujeito, ou seja, o rtulo do sujeito deve serigual ou inferior ao rtulo do objeto. Assim, se o rtulo do sujeito for SUPERSECRETO e o rtulo do objeto for SECRETO, o sujeito no pode escrever noobjeto.

A figura 2.1 ilustra esse princpio.

21

Figura 2.1: Viso do controle de acesso compulsrio

2.4 Consideraes sobre o controle de acessodiscricionrio

O controle de acesso discricionrio uma poltica de acesso a objetos base-ado na identidade de usurio e/ou grupos aos quais eles pertencem, possi-velmente configurveis atravs de permisses.

Em contraste com o controle de acesso compulsrio, onde o controle deacesso imposto pelo sistema, o controle de acesso discricionrio aplicadoconforme a prpria discrio do usurio que tenha direitos para tal, comopor exemplo, ao gravar um arquivo em seu diretrio de trabalho; com ocontrole de acesso compulsrio, pode-se escolher sobre o que fazer com osdados de sua propriedade; com o acesso compulsrio, isso no possvel.

O controle de acesso discricionrio no apenas permite ao usurio in-formar ao sistema quem pode acessar os seus dados, mas tambm permiteespecificar o tipo de acesso permitido. Por exemplo, o usurio pode desejarque todos do sistema sejam capazes de ler um arquivo em particular, massomente ele deve ser capaz de modificar aquele arquivo.

22

Captulo 3

O modelo RBAC Role-BasedAccess Control

3.1 Viso GeralNo controle de acesso baseado em papis (RBAC), o acesso a objetos de umsistema computacional baseado no papel que o usurio escolhe para exer-cer numa determinada sesso (Ferraiolo et al., 2003). O modelo RBAC , aomesmo tempo, uma abstrao e uma generalizao. Uma abstrao porqueno inclui propriedades que no so relevantes para a segurana. Uma ge-neralizao, pois diversos projetos ou modelos de controle de acesso podemser considerados uma interpretao, ou caso particular, do modelo baseadoem papis. Logo, o modelo RBAC til como uma base para o projeto dediversos sistemas de TI. Seu principal propsito consiste em facilitar a ge-rncia e manuteno das autorizaes de acesso no sistema, e a anlise devulnerabilidades necessria sua evoluo.

O modelo RBAC possui quatro sub-modelos:

RBAC ncleo (core RBAC), que abrange o conjunto bsico de funcio-nalidades presentes em todos os sistemas RBAC;

RBAC hierrquico (hierarchical RBAC), que inclui o conceito de hi-erarquia de papis, definida atravs de uma ordenao de papis;

RBAC com restries estticas (static constrained RBAC), que in-clui restries impostas na designao de papis; e

RBAC com restries dinmicas (dynamic constrained RBAC), queimpe restries na ativao de conjunto de papis que podem ser in-cludos como atributos do sujeito de um usurio.

No RBAC ncleo, so descritos cinco elementos administrativos:

1. usurios,

2. papis,

23

3. permisses, onde permisses so compostas de

4. operaes aplicadas a

5. objetos.

O conceito central no modelo o papel, onde o papel uma construosemntica em torno da qual cada poltica de segurana formulada. Asmais bsicas dessas relaes so as designaes de usurios e permisses.No RBAC, permisses so associadas a papis, e usurios so feitos mem-bros de papis, no sentido de poderem exerc-los. . Assim, podem exerceras permisses , atribudas a determinado papel, ao assumi-lo. A figura 3.1mostra o relacionamento entre usurios, papis e permisses. Na figura,usa-se as setas nas duas direes para indicar um relacionamento muitos-para-muitos. Por exemplo, um nico usurio pode se associar com um ouvrios papis, e um nico papel pode ter um ou vrios membros.

Figura 3.1: Relacionamento entre usurios, papis e permisses

Esse arranjo possibilita grande flexibilidade e granularidade para a atri-buio de permisses a papis, e de usurios a papis. Alm disso, o au-mento da flexibilidade no controle de acesso a recursos tambm fortifica aaplicao do princpio do privilgio mnimo.

Essa capacidade administrativa do modelo RBAC uma de suas maioresvirtudes. A administrao das informaes sobre autorizaes largamenteconhecida como um processo oneroso com um enorme e recorrente gasto.

Sob o modelo RBAC, usurios so designados a papis baseado na suacompetncia, autoridade e responsabilidades. Essas associaes de usu-rios a papis podem ser facilmente revogadas e novas podem ser estabele-cidas com a mesma facilidade. Com o RBAC, as permisses no so dadasaos usurios individualmente. Ao invs disso, permisses so associadascom os papis, um conjunto bem menor que o de usurios em grandes orga-nizaes. Novas associaes entre permisses e papis podem ser criadasenquanto antigas so removidas na medida que as funes organizacionaismudam e evoluem. Esse relacionamento entre os papis do modelo RBACe os papis exercidos na organizao facilita grandemente o entendimentoe o gerenciamento de permisses: os administradores de sistema podematualizar os papis sem ter que atualizar permisses para cada usurio dosistema individualmente.

24

3.1.1 PermissesAo modelar um sistema de controle de acesso, os administradores de siste-mas podem tratar as permisses como um conceito abstrato que se refere ligao arbitrria entre operaes e objetos, levando em considerao, emalguns casos, processos e valores. O conjunto de permisses designado a umpapel d o potencial para que tarefas, funes, ou outra abstrao qualquerrelativa a trabalho, sejam executadas. Designar um usurio a um papelconfere a habilidade de execut-las.

Permisses designadas a um determinado papel refletem polticas deter-minadas pela organizao que possui o sistema, tanto em relao ao mtodode acesso ao objeto como tambm em relao ao que acessado no objeto.Para entender as polticas em relao ao mtodo de acesso, basta saber queexiste a possibilidade de que um papel possa s ler dados e outro s escre-ver dados. Outra possibilidade um papel poder somente criar dados, masno edit-los, enquanto outro pode somente editar depois de os dados j es-tarem criados. Em relao ao acesso, um determinado papel pode acessartodos os dados de um arquivo texto, porm, outro pode acessar s um dostrechos do documento.

As permisses ainda podem refletir outros aspectos como regras impos-tas pelas condies do ambiente, como por exemplo, expresso por metadadosou ontologias aplicveis ao recurso em foco. Num exemplo em domnio deaplicao especfico, quando um mdico deve ser autorizado apenas a divul-gar somente o resultado de certos exames, no podendo divulgar os examespor inteiro, pois a porosidade de um ambiente em rede e erros humanospodem violar a privacidade do paciente. Permisses pdem refletir tambmleis e regulamentos quando, por exemplo, uma enfermeira est autorizadaapenas a adicionar novas entradas no pronturio de um paciente, mas nomodificaes no registro.

3.1.2 Comparao entre papis e Listas de controle deacesso

Uma lista de controle de acesso (access control list ACL) contem os no-mes dos sujeitos autorizados a acessar o objeto ao qual ela se refere, e assuas respectivas permisses de acesso. Por exemplo, quando um usuriodeseja acessar um determinado arquivo, o sistema faz uma busca na ACLdeste arquivo por uma entrada que corresponda ao usurio. Se a encontra,verifica se a operao requisitada faz parte do conjunto de permisses queesse usurio possui para acesso ao arquivo. Em caso positivo, o acesso serconcedido.

O privilgio de criao e manuteno das ACLs de um sistema dependedo conceito de proprietrio da informao (ou do recurso) do modelo decontrole de acesso aplicado. Em sistemas que aplicam polticas discricio-nrias, o proprietrio do objeto seu criador, o qual tem o privilgio deadministrar o acesso a esse objeto. J nos sistemas que suportam polticasno discricionrias, a propriedade de todos os objetos centralizada pelos

25

administradores do sistema. Para aumentar a eficincia na administrao,a entrada de uma ACL pode ser, alm de um nico sujeito, um grupo deles,cujos membros, conseqentemente, tero as mesmas permisses de acessoao objeto correspondente. Isso evita a repetio na atribuio de permis-ses.

Basicamente, um papel pode ser considerado semelhante a um grupo.Um papel representa um ou mais usurios, e um usurio membro de umou mais papis. Da mesma forma, possvel associar uma permisso a v-rios grupos e papis, assim como um grupo ou papel pode possuir vriaspermisses. Neste nvel de entendimento no se percebem diferenas en-tre papis e grupos de usurio. Contudo, h uma variedade de diferenasentre seus significados nos modelos de acesso e entre seu uso nas imple-mentaes.

Uma diferena essencial est no fato de que o conceito de grupo es-pecfico de cada implementao. Por exemplo, em alguns sistemas UNIX,somente um grupo pode ser associado a cada arquivo. Outros sistemas ope-racionais permitem a associao de vrios grupos. Ainda h aqueles queno permitem a um usurio fazer parte de mais de um grupo.

J no modelo RBAC, o papel um elemento central e est definido emtermos de um conjunto de propriedades fixas, no importando a sua imple-mentao. Uma dessas propriedades a relao muitos-para-muitos entrepapis e usurios e entre papis e permisses. Neste caso, para que umgrupo possa ser considerado como uma implementao do conceito de pa-pel do modelo RBAC, sua estrutura no pode restringir o nmero: de gru-pos que poderiam ser criados; de usurios que possam ser membros de umgrupo; de grupos que o usurio pode pertencer simultaneamente; de gruposincludos na lista de controle de acesso de um objeto. Ainda, no RBAC ousurio estar, numa sesso, sempre exercendo algum papel, cujas permis-ses no seriam combinadas de forma fixa com as de seus outros possveispapis, como seria o caso com grupos, ao acessar um recurso.

Sendo o RBAC um modelo, e no um mecanismo, pode ser implementadoem diversos tipos de sistema para incluir gerncia de redes e empreendi-mentos com um escopo que vai muito alm de apenas um sistema operaci-onal ou aplicao. Papis e usurios so tratados como entidades globaisque possuem relao com permisses dos diferentes sistemas onde o mo-delo aplicado, tornando a administrao mais simples, eficiente e menospropensa s falhas no controle de autorizao mais sutis.

Por fim, o conceito principal do modelo RBAC so os relacionamentosdos papis. Alm de possuir os relacionamentos com usurios e permisses,que servem como uma construo semntica na qual as polticas de controlede acesso so formuladas, existe ainda as relaes de hierarquia e heranaentre papis, e os relacionamentos de restrio esttica e dinmica, carac-tersticas no existentes entre as implementaes de grupos.

26

3.1.3 Ativao de papisDa mesma maneira que vrios outros tipos de modelos, o RBAC inclui oconceito de sujeitos e objetos. De modo geral, as propriedades e mapeamen-tos definidos pelo modelo RBAC podem ser divididos em duas componentesseparadas, mas dependentes: uma esttica e outra dinmica. A compo-nente esttica, discutida resumidamente at aqui, aquela que no possuirelacionamentos que envolvem o conceito de sujeito. Quando aplicamos po-lticas de segurana dinamicamente em um sistema, usamos a noo desujeitos, que so entidades ativas cujo acesso a papis, operaes e objetos,deve ser controlado. Um sujeito agindo em nome de um usurio efetua to-das as suas requisies. referenciado unicamente por um identificador,usado para determinar se o referente est autorizado a exercer um papele, se estiver, poder ativ-lo. Um usurio pode estar associado com inme-ros sujeitos a qualquer momento. Cada sujeito pode ter uma combinaodiferente de papis ativados. Essa funcionalidade mantm o princpio doprivilgio mnimo, j que um usurio que est associado com vrios papispode ativar um conjunto de papis mnimo para realizar as atividades decada sujeito.

3.2 Definio formalO modelo RBAC possui uma definio formal, dada por Ferraiolo and Kuhn(1992). Para cada sujeito, o papel ativo aquele que o sujeito est usandonaquele momento:

PA(s : sujeito) = papel ativo do sujeito s}

Cada sujeito pode ser autorizado a agir como um ou mais papis:

PAu(s : sujeito) = {papis autorizados para sujeito s}

Cada papel pode ser autorizado a realizar uma ou mais transaes:

TA(p : papel) = {transaes autorizadas para papel p}

Sujeitos podem executar transaes. O predicado exec(s, t) ver-dadeiro se, e somente se, o sujeito s pode executar a transao t naquelemomento; caso contrrio, falso:

exec (s : sujeito, t : transao) = {verdadeiro sujeito s pode executar transao t}

Um sujeito pode executar uma transao somente se o sujeito selecionouou foi designado a um papel:

s : sujeito, t : transao exec(s,t) PA(s) 6=

27

O papel ativo de um sujeito deve estar autorizado para aquele sujeito:

PA(s) PAu(s)Um sujeito pode executar uma transao somente se a transao est

autorizada para o papel ativo do sujeito

s : sujeito, t : transao exec(s,t) t TA(PA(s)) importante notar que est ltima regra condicional permite que ou-

tras restries possam ser colocadas na execuo de transaes.

3.3 Modelo RBAC do NIST

3.3.1 Viso geralO padro proposto pelo NIST (Ferraiolo et al., 2001) foi projetado com oobjetivo de prover uma definio autoritativa de funcionalidades bem acei-tas do RBAC, para o uso em sistemas de gerenciamento de autorizaes. Opadro estruturado em duas partes, descritas como se segue:

Um modelo de referncia, definido como uma coleo de quatro com-ponentes do modelo RBAC: o ncleo, o hierrquico, o de restrio es-ttica e o de restrio dinmica. Os componentes do modelo existempara fornecer um vocabulrio padro de termos relevantes para defi-nir um extenso conjunto de funcionalidades do RBAC.

Uma especificao funcional que projeta o modelo de referncia emum conjunto congruente de componentes funcionais, onde cada compo-nente define requisitos especficos de operaes administrativas paracriar e manter os conjuntos e relaes do RBAC, funes de reviso efuncionalidades do sistema correspondentes ao respectivo componentedo modelo.

O padro descreve uma abordagem lgica ao definir pacotes de compo-nentes funcionais, onde cada pacote corresponde a um segmento de ambi-ente ou mercado diferente. O conceito bsico que cada componente possaopcionalmente ser selecionado para ser includo em um pacote com apenasuma execuo - componente ncleo do RBAC deve estar includo em todosos pacotes.

Na definio de pacotes funcionais, o ncleo do RBAC nico pelo fato deque fundamental e deve ser includo em todos os pacotes. Inclusive, paraalguns ambientes, a sua seleo j suficiente. O componente hierrquico dividido em duas partes: hierarquias de papis gerais e limitadas. Ocomponente de restries estticas tambm est dividido em duas partes:restries estticas e restries estticas com a presena de hierarquias.Por fim, o componente de restries dinmicas no possui nenhuma divisoe escolhido por inteiro ou no.

Cada componente do modelo de referncia definido pelos seguintessubcomponentes:

28

um conjunto de conjuntos bsicos de elementos;

um conjunto de relaes RBAC envolvendo esses conjuntos de elemen-tos;

um conjunto de funes mapeadoras que geram instncias de mem-bros de um conjunto de elementos para uma dada instncia de umoutro conjunto de elementos.

A especificao funcional do RBAC esboa a semntica de vrias funesque so necessrias na criao e manuteno dos componentes do modeloRBAC (conjuntos de elementos e suas relaes), como tambm no suportede funes do sistema. As trs categorias de funes em uma especificaofuncional do RBAC e seu propsito so descritas como se segue:

Funes administrativas: Criao e manuteno de conjuntos de ele-mentos e suas relaes na construo dos vrios componentes do mo-delo RBAC;

Funes de suporte do sistema: Funes que so necessrias pela im-plementao do RBAC para auxiliar na construo do modelo RBAC(por exemplo, atributos de sesso e lgica de deciso para o acesso);

Funes de inspeo: Funes que revisam os resultados das aescriadas pelas funes administrativas.

3.3.2 O ncleo do RBACNo componente ncleo do RBAC as funes administrativas so descritascomo se segue:

Criao e manuteno de conjuntos de elementos: os conjuntos bsicosde elementos so USERS (usurios), ROLES (papis), OPS (operaes)e OBS (objetos). Desses conjuntos, os ltimos dois so consideradospredefinidos pelo sistema de informao sobre o qual o RBAC desen-volvido;

Criao e manuteno de relaes: as duas principais relaes so adesignao de usurios a papis (user-to-role assignment - UA) e adesignao de permisses a papis (permission-to-role assignment -PA). As funes de criao e remoo de instncias das relaes UAso AssignUser (criao) e DeassignUser (remoo). Para as re-laes PA, as funes necessrias so GrantPermission (criao) eRevokePermission (remoo).

As funes de suporte so necessrias para a gerncia de sesses e natomada de decises do controle de acesso. Um papel ativo necessrio naregulao do controle de acesso para um usurio durante uma sesso. Afuno que cria a sesso estabelece um conjunto padro de papis ativos

29

para o usurio no incio da sesso. O usurio pode ento alterar a com-posio desse conjunto padro durante a sesso adicionando ou removendopapis. As funes relacionadas com a adio e remoo de papis ativos eoutras funes auxiliares so as seguintes:

CreateSession: Cria um sesso de usurio e fornece ao usurio umconjunto padro de papis;

AddActiveRole: Adiciona um papel como um papel ativo para a ses-so atual;

DropActiveRole: Remove um papel do conjunto de papis ativos dasesso atual;

CheckAccess: Determina se um processo da sesso tem permissopara realizar a operao requerida em um objeto.

As funes de inspeo so aquelas que permitem ao administrador dosistema verificar todos os usurios relacionados com um determinado papelbem como os papis relacionados com um determinado usurio. Alm disso,tambm permitem que o administrador verifique os resultados das funesde suporte ao determinar os atributos de sesso (papis ativos e permis-ses). Algumas das funes so opcionais (O) na implementao do RBAC,outras so mandatrias (M). Elas so descritas abaixo:

AssgnedUsers (M): retorna o conjunto de usurios designados a umdeterminado papel;

AssignedRoles (M): retorna o conjunto de papis designados a umdeterminado usurio;

RolePermissions (O): retorna o conjunto de permisses dadas a umdeterminado papel;

UserPermissions (O): retorna o conjunto de permisses que um de-terminado usurio tem a partir dos seus papis;

SessionRoles (O): retorna o conjunto de papis ativos associados sesso;

SessionPermissions (O): retorna o conjunto de permisses dispo-nveis na sesso (i. e., a unio de todas as permisses designadas aospapis ativos da sesso);

RoleOperationsOnObject (O): retorna o conjunto de operaes umdado papel pode realizar em um dado objeto;

UserOperationsOnObjects (O): retorna o conjunto de operaes umdado usurio podem realizar em um dado objeto.

30

3.3.3 RBAC HierrquicoNesse componente esto presentes todas as funes administrativas queexistem no RBAC ncleo. No entanto, a funo DeassignUser deve ser re-definida porque com a presena de hierarquias de papis um usurio podeherdar uma autorizao para um papel mesmo no estando diretamentedesignado para este papel. Logo, a hierarquia permite que usurios her-dem permisses de papis que esto abaixo do seu papel na hierarquia. Aquesto : o usurio somente pode ser removido de uma relao com umpapel diretamente designado a ele, ou pode ser removido de uma relaocom um papel herdado? A resposta fica a cargo da implementao e no descrita no padro.

As funes administrativas adicionais do componente hierrquico sorelativas a criao e manuteno de relaes de hierarquia entre papis. Asoperaes consistem em criar ou remover uma relao de hierarquia entredois papis existentes em um conjunto de papis, ou adicionar um novopapel hierarquia, posicionando-o apropriadamente. O nome e o propsitodessas funes so descritas como se segue:

AddInheritance: estabelece uma nova relao de herana imediataentre dois papis;

DeleteInheritance: remove uma relao de herana imediata en-tre dois papis;

AddAscendant: cria um novo papel e coloca-o como ascendente ime-diato de um papel;

AddDescendant: cria um novo papel e coloca-o como descendenteimediato de um papel.

As funes de suporte do componente hierrquico so aquelas do ncleodo RBAC, com a mesma funcionalidade, contudo as funes CreateSessione AddActiveRole, por causa da hierarquia de papis, precisam ser rede-finidas. Da mesma forma, as funes de inspeo do ncleo do RBAC tam-bm so vlidas para o componente hierrquico. Em adio, algumas fun-es so redefinidas pelo fato de que os conjuntos de relaes entre papis eusurios no possuem apenas elementos diretamente associados, mas tam-bm aqueles advindos das relaes de hierarquia de papis. As funes sodefinidas abaixo:

AuthorizedUsers: retorna o conjunto de usurios diretamente asso-ciados a um papel bem como aqueles usurios que esto associados apapis que herdam esse papel;

AuthorizedRoles: retorna o conjunto de papis diretamente asso-ciados a um usurio bem como aqueles papis herdados pelos papisdiretamente associados ao usurio.

31

Alm disso, as funes de inspeo relativas s permisses associadasa usurios e papis devem ser igualmente redefinidas considerando-se asrelaes de hierarquia.

3.3.4 Componente de restries estticas do RBACPara um modelo RBAC com restries estticas que no inclui hierarquiade papis, as funes administrativas devem conter todas aquelas que es-to no ncleo do RBAC. Contudo, a funo AssignUser deve incorporar afuncionalidade de verificao e garantia que a designao de um papel parao usurio no viola qualquer uma das restries estticas associadas a ela.

As relaes de restrio esttica consistem em um trip: SSD_Set_Name,nome que indica a transao ou processo no qual uma associao de umusurio a um determinado conjunto de papis simultaneamente deve serrestringida; role_set, conjunto de papis constituintes da relao de res-trio esttica; SSD_Card, que define a cardinalidade do subconjunto con-tido em role_set a qual a associao simultnea de papis deve ser res-tringida. Portanto, as funes administrativas relacionadas a criao e ma-nuteno de uma relao de restrio esttica so operaes para:

criar e remover uma instncia de uma restrio esttica (CreateSSDSete DeleteSSDSet);

adicionar e remover papis ao conjunto de papis da restrio esttica(AddSSDRoleMember e DeleteSSDRoleMember);

configurar o parmetro de cardinalidade da restrio (SetSSDCardinality).

Para o caso de modelos RBAC com hierarquia de papis, as funesacima produzem o mesmo resultado com uma nica exceo: restries re-lacionadas hierarquia de papis devem ser levadas em conta ao aplicaruma dessas funes.

3.3.5 Componente de restries dinmicas do RBACA semntica para a criao de instncias de restries dinmicas idn-tica quela das restries estticas. Enquanto as restries estticas soaplicadas no momento da designao de papis ao usurio (e tambm nacriao de hierarquia de papis), as restries dinmicas so aplicadas nomomento da ativao do papel por um usurio durante uma sesso.

As funes administrativas para restries dinmicas so: criao e re-moo de instncias de restries dinmicas (CreateDSDSet e DeleteDSDSet);incluso e remoo de papis do conjunto de papis da restrio dinmica(AddDSDRoleMember e DeleteDSDRoleMember); e configurao de cardi-nalidade dos papis da restrio dinmica (SetDSDCardinality).

As funes de suporte para criao de sesso (CreateSession) e ativa-o de papis (AddActiveRole e DropActiveRole) devem ser modifica-das para aplicar as restries dinmicas no momento em que so chamadas.

32

Captulo 4

O MACA - Middleware deAutenticao e Controle de

Acesso

Este captulo apresenta o MACA Middleware de Autorizao e Controle deAcesso, a ferramenta que foi utilizada como servidor de controle de acessopara o prottipo desenvolvido. O MACA uma ferramenta com cdigoaberto e licena livre que implementa um modelo de autorizao contextualpara o controle de acesso baseado em papis. Uma autorizao contextualusa informaes ambientais disponveis durante o momento de acesso paradecidir se um usurio tem ou no o direito de acessar um recurso, e deque modo.

Este captulo est dividido da seguinte forma: a seo 4.1 explica o quevem a ser um contexto do MACA; a seo 4.2 define o que so regras deautorizao; a seo 4.3 apresenta o modelo de autorizao do MACA; aseo 4.4 apresenta aspectos de arquitetura e de implementao do MACA;por fim, apresentada uma viso geral do algoritmo de deciso de acessodo MACA.

4.1 Os contextosUm contexto qualquer informao que pode ser utilizada para distinguire caracterizar uma entidade (pessoa, lugar, objeto) considerada relevantepara a interao entre um usurio e uma aplicao, incluindo-se a o prpriousurio e a prpria aplicao. O contexto denota informaes ambientaispara decidir se um acesso ser permitido ou proibido, no momento em queo usurio tenta efetu-lo.

No MACA, h o contexto do usurio corrente (aquele que iniciou umasesso e que solicita uma autorizao de acesso); o contexto temporal, cominformaes sobre hora e data; o contexto de rede, com informaes de redese de comunicao; e outros contextos que podem ser livremente definidos eimplementados pelos formuladores e administradores da poltica de acesso.

As informaes disponveis em um contexto so recuperadas de acordo

33

com a sintaxe ., onde o primeiro termo de-signa o nome do contexto e o segundo termo pode designar:

uma varivel contextual, como, por exemplo, a varivel nome do con-texto do usurio (usuarioCtx.nome) ou um dia da semana do con-texto temporal (dtCtx.dia_semana);

um conjunto contextual, como, por exemplo, o conjunto de dias teisda semana do contexto temporal (dtCtx.dias_teis); ou

uma funo contextual, como, por exemplo, a funo advCtx.assiste(umCodParte, usuarioCtx.registro_profissional), que informase a parte identificada por umCodParte assistida pelo usurio cor-rente identificado pela varivel usuarioCtx.registro_profissional.

Deve-se lembrar que os contextos devem refletir, com alto nvel de abs-trao, as entidades e os relacionamentos existentes entre elas no ambienteonde o acesso realizado, a fim de facilitar a definio das polticas.

4.2 As regras de autorizaoUma regra de autorizao relaciona informaes contextuais em expresseslgicas que especificam uma poltica de acesso para um objeto protegido. Asregras so definidas numa linguagem de expresses lgicas capaz de recu-perar os valores provenientes de variveis, conjuntos e funes contextuaispara relacion-las por meio de operadores aritmticos (+, -, *, %), relacio-nais (>, =,

Nesse caso, o valor do identificador umDia depende do momento em quea aplicao solicita o acesso. Para que a regra se torne vlida, o identifi-cador deve se subordinar a um contexto ou ser declarado explicitamentecomo um parmetro de uma regra. A regra anterior torna-se uma regrabem formada se for definida da seguinte forma,

exp-abs(umDia){

umDia in dtCtx.dia_semana}

A palavra reservada exp-abs indica a definio de uma expresso pa-rametrizada; o parmetro formal umDia denota um dia qualquer, que passado como argumento no momento de avaliao da regra.

Para uma regra parametrizada ser avaliada, necessrio que uma listade argumentos correspondentes aos parmetros formais seja definida. Po-dem ser passados como argumentos de uma regra parametrizada valoresprimitivos (booleanos, inteiros, texto); variveis, conjuntos e funes con-textuais; e demais expresses da linguagem, inclusive regras parametriza-das.

4.3 O modelo de autorizao contextual do MACAConforme j dito, o MACA estende a especificao do controle de acesso ba-seado em papis, com o acrscimo de autorizaes contextuais, de autoriza-es positivas e negativas, de autorizaes fortes e fracas, da possibilidadede revogar-se autorizaes e da separao de responsabilidades esttica edinmica baseadas em conflitos fortes e fracos entre autorizaes.

No MACA, uma autorizao positiva (+) aquela que concede um acesso.J uma autorizao negativa (-) , por sua vez, aquela que probe expli-citamente o acesso. Quando o acesso proibido para a maioria dos papisdescendentes, uma autorizao negativa deve ser usada no papel ascen-dente. De maneira similar, quando o acesso permitido para a maioria dospapis descendentes, uma autorizao positiva deve ser definida no papelascendente. Por exemplo: considere que, em uma hierarquia de papis, amaioria dos papis tem o direito de pesquisar um processo; ento, essa au-torizao deve ser definida como positiva no papel ascendente, a fim de queos descendentes herdem essa autorizao. De forma anloga, suponha queapenas uma minoria da descendncia tenha a capacidade de proferir umasentena; assim, essa autorizao pode ser definida como negativa no pa-pel ascendente e redefinida como positiva apenas nos papis que possuemo privilgio de execut-la.

Uma autorizao pode, ainda, ser do tipo fraca ou forte. Autorizaesfortes estabelecem polticas absolutas, que no podem ser revogadas, en-quanto as fracas so utilizadas para definir polticas mais permissivas.

35

Desta forma, autorizaes fortes e fracas podem ser utilizadas para resol-ver conflitos. As autorizaes fortes devem ser utilizadas para protegerrecursos considerados crticos, que envolvam conflitos de interesses. Napresena de uma autorizao forte em um papel, esta no pode ser redefi-nida nos papis descendentes; quando da existncia de conflitos entre au-torizaes fortes, opta-se por negar o acesso. As autorizaes fracas soutilizadas para definir polticas que podem ser revogadas, permitindo queautorizaes possam ser redefinidas em papis descendentes; quando daocorrncia de conflitos entre autorizaes fracas, prevalecer aquela queconcede o acesso.

4.4 Arquitetura e implementao do MACA

Figura 4.1: Arquitetura do MACA

A arquitetura ilustrada na figura 4.1 especifica os componentes de soft-ware e de comunicao para suportar a implementao do MACA. ummodelo cliente-servidor multicamada com os seguintes componentes prin-cipais: um servidor LDAP, encarregado de manter a base de gerncia de in-formaes de segurana (BIGS); um servidor de segurana, encarregado deoferecer servios de autenticao de usurio, de deciso de acesso recur-sos, etc.; e finalmente, as aplicaes clientes que requisitam estes serviosde segurana. Foram adotados, na arquitetura, padres de processamentoaberto e distribudos. A seguir, detalhado cada um desses componentes.

A BIGS mantm os perfis de segurana para proteo da aplicao cli-ente, tais como, autorizaes de acesso, papis, representaes dos recur-

36

sos protegidos e dos usurios, dados para autenticao, relacionamentospapis-usurios, papis-autorizaes, etc. Essas informaes so armaze-nadas em um servio de diretrio hierarquizado, cujo acesso e esquemasde descrio de dados so padronizados atravs do protocolo LDAP. Esque-mas de dados preexistentes no LDAP so utilizados no armazenamento deinformaes sobre usurios (nome, e-mail, etc.), papis (nome, descrio,membros, etc.) e recursos (nome, descrio, localizao, etc.).

Todo acesso BIGS realizado atravs do protocolo LDAP sobre TLS(Transport Layer Security) para assegurar confidencialidade e integridadena comunicao. As informaes persistentes do MACA foram representa-das com esquemas do protocolo LDAP verso 3, sendo que o modelo de da-dos que representa o MACA foi implementado no software (verso 2.3.11)de cdigo fonte aberto OpenLDAP.

Figura 4.2: rvore de informaes de diretrio

O servio de diretrios LDAP consiste em um conjunto de servios dediretrios interconectados que se comunicam por meio do protocolo LDAPpara atender as requisies (pesquisa, comparao, insero, remoo, etc.)de clientes. O diretrio organiza as informaes numa estrutura hierarqui-zada, denominada rvore de Informaes de Diretrio (AID), numa versosimplificada do modelo de dados X500 (fig. 4.2). Cada entrada na AID cor-responde a um registro armazenado. A estrutura de dados de uma entrada determinada pelas classes de objeto a que ela pertence; essa classe es-pecifica os tipos de atributos de uma entrada que pertence classe. Cadaentrada identificada unicamente numa AID pelo seu Distinguished Name

37

(DN). O DN similar ao caminho completo que identifica unicamente umarquivo num sistema de arquivos.

Cabe ao servidor de segurana oferecer servios transientes do MACAcomo autenticao, autorizao e controle de acesso s aplicaes clientes,dentre outros servios de segurana. Ele integra o servio de segurana doCORBA (SSC), o servio de deciso para acesso a recursos (RAD Facility)e o servio de autorizao do MACA.

O SSC oferece interfaces padronizadas para autenticao de usurios,gerncias de sesses e outros servios de segurana. O RAD Facility espe-cifica um servio padro de deciso de acesso a recursos capaz de suportardiferentes polticas de acesso. O servio do MACA implementa o modelode autorizao contextual para o controle de acesso baseado em papis quedecide o acesso aos recursos com base na poltica armazenada na BIGS enos contextos disponveis no momento do acesso.

A integrao entre o MACA e o SSC requer implementaes das interfa-cesPrincipalAuthenticator e Credentials. PrincipalAuthenticatorrealiza a autenticao (por meio do mtodo authenticate), verificando avalidade da identidade usurio no servidor LDAP. Caso seja bem sucedida,a autenticao resulta na criao de uma instncia de Credentials, quepermite solicitar ao MACA a execuo de tarefas relacionadas a sesso dousurio, como por exemplo, obter os papis de um usurio.

Com o usurio autenticado (e com sua credencial criada) o controle deacesso imposto pelo ORB (Object Request Broker) s chamadas de opera-es das interfaces dos objetos CORBA servidores (vide figura refmodelo).Assim, o ORB atua como um monitor de referncia que impe, obrigatori-amente, o controle de acesso. Ele utiliza uma implementao da interfaceAccessDecision do SSC para obter, do MACA, os privilgios de acessoconferidos pelos papis do usurio.

Figura 4.3: Modelo de controle de acesso do SSC

O RAD Facility utiliza o servio de autorizao do MACA como poltica

38

de acesso para proteger os recursos das aplicaes clientes. A interface doobjetoAccessDecision do RAD Facility padroniza o modo como as aplicaesclientes (objeto alvo) solicitam autorizaes para um usurio acessar umrecurso. As interaes entre o cliente, o objeto CORBA servidor e o serviode deciso do RAD Facility d-se da seguinte maneira:

1. Um cliente solicita que o objeto servidor (objeto alvo) a execuo deuma operao.

2. Durante a execuo da operao, o objeto servidor solicita ao objetoAccessDecision uma autorizao para executar a operao. Podemhaver parmetros, que sero utilizados para decidir o acesso.

3. O objeto AccessDecision retorna um valor booleano indicando se aautorizao foi concedida ou proibida.

4. Com base no retorno de AccessDecision, o objeto servidor responde aplicao cliente, completando a execuo da operao solicitada, seo acesso foi autorizado, ou ento, interrompendo a execuo e sinali-zando para o cliente que o acesso foi proibido.

4.5 O algoritmo de deciso de acesso do MACAO algoritmo de deciso de acesso do MACA recebe os seguintes parmetrosde entrada:

a operao a executar (opr),

o objeto protegido (obj), a lista de parmetros de autorizao (params), e

a referncia da sesso (session_ref).

E retorna como sada um valor booleano indicando se o acesso deve serpermitido ou proibido. Os passos a seguir so executados durante o algo-ritmo:

1. Caso o conjunto de papis ativveis do usurio seja vazio, o acesso negado (retorna falso) e o algoritmo pra.

2. Caso contrrio, verifica-se existe alguma autorizao vlida, forte, as-sociada a algum papel ativo ou ativvel do usurio que proba a exe-cuo da operao opr no objeto obj. Caso existe, o acesso negado(retorna falso) e o algoritmo pra.

39

3. Caso o algoritmo no tenha parado, ento verifica-se a existncia dealguma autorizao vlida, forte, associada a algum papel ativo ouativvel do usurio que permita executar a operao opr no objetoobj. Caso exista, o acesso concedido (retorna verdadeiro), o eventualpapel inativo ativado na sesso session_ref e o algoritmo pra.

4. Caso o algoritmo no tenha parado, ento verifica-se a existncia dealguma autorizao vlida, fraca, associada a algum papel ativo oupara ativao do usurio que permita executar a operao opr noobjeto obj. Caso exista o acesso concedido (retorna verdadeiro), oeventual papel inativo ativado na sesso session_ref e o algo-ritmo pra.

5. Caso o algoritmo no tenha parado, ento o acesso negado (retornafalso) e o algoritmo pra.

Note-se, pela execuo dos passos algoritmo, que as autorizaes fortes enegativas prevalecem sobre as demais autorizaes, inclusive as eventuaisautorizaes equivalentes, fortes e positivas. Por sua vez, autorizaes for-tes prevalecem sobre as autorizaes fracas equivalentes e as autorizaesfracas positivas prevalecem sobre as autorizaes fracas negativas equiva-lentes.

40

Captulo 5

Modelo de acessoimplementado como prova de

conceito

Esse captulo apresenta uma implementao de controle de acesso baseadoem papis para processos judiciais virtuais, restrita a uma rea especficado domnio de aplicao jurdica. O objetivo desta implementao servirde prova de conceito da racionalidade da soluo em middleware propostapor sua arquitetura, tendo como foco imediato sua evoluo para um pro-ttipo piloto nesta rea. A soluo em middleware aqui proposta visa aracionalidade em dois sentidos.

No primeiro sentido, abstrato, busca-se explorar o potencial do modeloRBAC para alcanar maior eficincia na gerncia de polticas de seguranademandadas, de um lado, por regulamentao complexa das regras de ne-gcio (norma processual), e por outro, por altos nveis de adaptabilidade,esclabilidade e sensibilidade nos requisitos de controle operacional das apli-caes (informatizao do judicirio, sob os influxos da SICP-izaoT)

No segundo sentido, concreto, busca-se explorar o potencial do modelode desenvolvimento colaborativo, sob regime de licenciamento livre, paraalcanar maior eficincia no atendimento demanda instrumental de me-canismos de segurana prprios para integrao e/ou informatizao de sis-temas processuais na esfera judiciria, atualmente reprimida, alavancandoe provendo assim a autonomia do usurio, em relao a fornecedores decomponentes, para controlar sua prpria poltica de segurana, autonomiaesta que a prpria essncia desta segurana.

Da a adaptao do projeto MACA, software sob licena GPL original-mente desenvolvido para controle de acesso a sistemas de pronturios m-dicos, para atender aos requisitos de segurana especficos do domnio deaplicao em tela.

A seo 5.1 apresenta o modelo de acesso proposto. A seo 5.2 apre-senta aspectos de implementao.

41

5.1 O modelo de acesso propostoA soluo apresentada cobre os processos judiciais autuveis em JuizadosEspeciais Cveis de primeira instncia.

Os Juizados Especiais foram criados pela Lei 9099 de 1995 (http://www.trf2.gov.br/juizados/9099jef.htm). So rgos da Justia (Po-der Judicirio) que servem para resolver as pequenas causas com rapidez,de forma simples, sem despesas e sempre buscando um acordo entre aspartes. O artigo 3 da Lei 9099 exposto a seguir esclarece qual acompetncia dos Juizados Especiais Cveis.

"Art. 3 O Juizado Especial Cvel tem competncia para concili-ao, processo e julgamento das causas cveis de menor comple-xidade, assim consideradas:I - as causas cujo valor no exceda a quarenta vezes o salriomnimo;II - as enumeradas no art. 275, inciso II, do Cdigo de ProcessoCivil;III - a ao de despejo para uso prprio;IV - as aes possessrias sobre bens imveis de valor no exce-dente ao fixado no inciso I deste artigo.(...)"

A escolha pelo Juizado Especial Cvel se justifica pela simplicidade epela facilidade de aplicao de um procedimento virtual para seus atos pro-cessuais. Os Juizados Especiais tm dentre seus princpios processuais ainformalidade e a celeridade, buscando obter a rpida soluo de confli-tos utilizando menos recursos processuais, e com execuo efetiva e clere.Desta forma, a virtualizao do processo objetivo desejvel nos JuizadosEspeciais, pois, alm de diminuir gastos (como por exemplo, na tramita-o de papelada) permite a automatizao de boa parte do caminhamentodo processo, repassando ao sistema computadorizado a execuo de certastarefas e a implementao do fluxo processual, o que pode resultar na ace-lerao de sua execuo.

Para implementar o processo jurdico virtual autuvel em Juizados Es-peciais Cveis, visando esta prova de conceito, foi adotado um fluxo simplifi-cado de caminhamento do processo. Este fluxo apresentado na figura 5.1.

O fluxo, de maneira geral, mostra as etapas pelas quais um processocaminha, desde a entrada do pedido de autuao at o seu arquivamento.

Cada uma dessas etapas pode ser executada por uma pessoa diferente;por exemplo, o autor do processo ou o advogado deste pode entrar com apetio inicial; o Conciliador o responsvel por dirigir a Audincia de Con-ciliao; o Juiz quem profere a sentena, etc.

A modelagem desenvolvida baseia-se no modelo de controle de acessobaseado em papis (RBAC). Como j foi sinalizado na introduo deste ca-ptulo, a natureza da lide processual a torna candidata natural a esse tipo

42

Figura 5.1: Fluxo de caminhamento do processo

de modelagem, j que a prpria existncia de atores jrdicos predicadapor conjuntos de prerrogativas processuais e normativas, cujo carter di-nmico atinge no s a vida til do sistema processual, mas muitas vezestambm o prprio processo.

Para aplicao do modelo de acesso proposto, foram definidos serviosforenses que podem ser acessados pelas pessoas que lidam com os proces-sos, no desempenho de suas funes (papis, no RBAC). Estes servios sodescritos a seguir.

Servio de Cadastro: permite cadastrar: um processo, quando da au-tuao de uma petio inicial;cadastrar partes do processo; editar da-dos de partes do processo; remover partes do processo.

Servio de Pesquisa: permite a pesquisa por processos (segundo osfiltros nmero do processo, nome de partes ou advogados), a pesquisapor partes e a pesquisa por advogados.

Servio de Movimentao Processual: permite movimentar um pro-

43

cesso, segundo o fluxo de processo apresentadoOu seja, desde a autu-ao da petio inicial at a baixa/arquivamento do processo.

Servio de Acompanhamento e Auditoria: permite acompanhar o pro-cesso em suas diversas fases e visualizar as aes realizadas no pro-cesso (e quem as realizou).

O acesso a esses servios deve atender a poltica de acesso definida atra-vs de regras. Essa poltica procura respeitar os requisitos do Juizado Es-pecial Cvel, e espelhar, na medida do possvel, as funes existentes em umJuizado e suas normas processuais. Ela apresentada, em linhas gerais, aseguir.

Somente usurios devidamente autenticados (com o uso de certifica-dos digitais) podem acessar o sistema.

Conforme o controle de acesso baseado em papis, cada usurio deveestar associado a um papel, para poder executar um servio forensepermitido quele papel. A figura 5.2 apresenta a hierarquia de papisque foi utilizada no modelo proposto, onde procurou-se representar oscargos existentes em uma vara desse tipo de Juizado.

Nessa hierarquia, houve a tentativa de, na medida do possvel, levar-seem conta as relaes de responsabilidade e autoridade existentes quer noscostumes ou nas normas processuais. Com o objetivo de formar uma hierar-quia inicial simples, mas passvel de evoluo, optou-se apenas por retrataros cargos que lidam diretamente com a movimentao do processo. Houve,ainda, a preocupao de definio de papis genricos, como os papis Usu-rio, Analista Judicirio e Tcnico Judicirio, que possuem autorizaes queso herdadas pelos papis mais especializados.

Os atos praticados so pblicos, o que implica que todos os usurioslegtimos do sistema podem ver os movimentos realizados e podempesquisar por processos.

Somente usurios com papis que participam em um processo (parteou advogado) e determinados funcionrios do Juizado podem ver osdocumentos que so peas de um processo.

Os advogados s podem adicionar documentos, interpor recursos, etc.em processos nos quais representam partes. Alm disso, dentro dosprazos processuais em que cabe parte representada manifestar-senos autos.

Os juzes podem estabelecer e estender prazos, como por exemplo: pra-zos para a Audincia de Conciliao e prazos para interposio de re-cursos.

Somente juzes podem determinar a baixa de um processo, desde queno obstado por norma processual impeditiva.

44

Figura 5.2: Hierarquia de papis considerada na implementao do modelode acesso aos processos

A figura 5.3 ilustra a poltica de acesso definida. So mostrados os re-cursos principais e as autorizaes ligadas aos principais papis.

45

Figura 5.3: Do lado esquerdo esto representados os recursos acessveis,com as respectivas operaes associadas.Do lado direito, as autorizaescontextuais associadas a cada papel.

46

5.2 Aspectos de implementaoEsta seo trata de aspectos de implementao do prottipo desenvolvido.O prottipo foi implementado na plataforma Java 2 SE, verso 5. Aquisero discutidos aspectos relativos a autenticao e aspectos relativos a au-torizaes.

O MACA, na verso utilizada (3.2.2c), s fornece suporte para autentica-o baseada em senha e nome de usurio. Para adequar a forma de autenti-cao quela que ser demandada em implementaes piloto que busquemtestar e eventualmente atender demandas de imformatizao e/ou integra-o com servios existente, sob o regime normativo de uma infra-estruturade chaves pblicas, optou-se por estend-lo para permitir a autenticaovia certificados digitais e chaves privadas correspondentes.

Alm de buscar cobrir o potencial de demanda deste importante mo-mento da Justia Brasileira, a utilizao de certificados para autenticao,nesse tipo de arquitetura, abre a possibilidade para utilizao de camposespecficos (extenses X.509) na alocao de papis, na deciso de se permi-tir ou se negar acesso de um usurio autenticado a um determinado servio(Seo 6.3). Ademais, implementaes-piloto de prottipos desta arquite-tura podem tambm servir de base para prova de conceito ou para homo-logao de normas em considrao por uma ICP qual esteja subordinadao Juizado correspondente. Desta forma, fez-se necessria a modificao nocdigo do MACA para satisfazer essa necessidade de projeto.

Assim, foi-lhe acrescentada mais uma forma de autenticao, chamadaX509_CERTIFICATE.

Quando X509_CERTIFICATE repassado ao MACA, durante a execu-o do protocolo de autenticao por uma aplicao-cliente, isso indica quea autenticao ser realizada via certificado digital . No prottipo imple-mentado, assume-se que o certificado, (e a respectiva chave privada) estoarmazenados em um keystore.

Para a criao do keystore, a ser utlizado nos testes do prottipo imple-mentado, foi utilizada a ferramenta keytool do Java, que um gerencia-dor de keystores de chaves privadas e certificados, incluindo bibliotecas degerao de chaves.

5.2.1 Gerao de chavesA seguir, apresentada o cdigo para a criao de um certificado com essaferramenta.

keytool -genkey -alias usuario -keyalg RSA -keystoreuser_keystore

Enter keystore password: passwordWhat is your first and last name?[Unknown]: UsuarioWhat is the name of your organizational unit?

47

[Unknown]: Seo XYZWhat is the name of your organization?[Unknown]: Tribunal de Pequenas CausasWhat is the name of your City or Locality?[Unknown]: BrasliaWhat is the name of your State or Province?[Unknown]: DFWhat is the two-letter country code for this unit?[Unknown]: BRIs CN=Usuario, OU=Seo XYZ, O=Tribunal de PequenasCausas,

L=Braslia, ST=DF, C=BR correct?[no]: yesEnter key password for (RETURN if same as keystore password):

Isso cria um certificado auto-assinado com as correspondentes chavespblicas e privadas e os armazena no keystore user_keystore.

5.2.2 Autenticao bidirecional usurio-servidor MACAO prottipo, durante a autenticao, pede que o usurio informe o seu keys-tore (veja figura 5.4).

Figura 5.4: Tela de Autenticao

A figura 5.5 ilustra como a aplicao utiliza o keystore para realizar aautenticao.

48

Figura 5.5: Utilizao do keystore para realizar a autenticao

De posse do caminho do arquivo que representa o keystore (varivelksPath), o keystore carregado. A seguir, o certificado obtido(keystore.getCertificate()), a partir do alias encontrado no keystore(assume-se que o keystore s contenha uma entrada). O objeto que re-presenta o