Universidade de Braslia

Instituto de Cincias Exatas

Departamento de Cincia da Computao

Controle de Acesso Baseado em Papis na

Informatizao de Processos Judiciais

Andr Thiago Souza da Silva

Hugo Vasconcelos Saldanha

Monografia apresentada como requisito parcial

para concluso do Bacharelado em Cincia da Computao

Orientador
Prof. Pedro A. D. Rezende

Braslia
2006

Universidade de Braslia UnB

Instituto de Cincias Exatas
Departamento de Cincia da Computao
Curso de Bacharelado em Cincia da Computao

Coordenador: Prof a. Cludia Nalon

Banca examinadora composta por:

Prof. Pedro A. D. Rezende (Orientador) CIC/UnB
Prof. Luiz Antnio da Frota Mattos CIC/UnB
Sr. 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 Processos Judiciais/ Hugo Vasconcelos Saldanha, Andr Thiago Souza
da 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 Braslia

Campus Universitrio Darcy Ribeiro Asa Norte
CEP 70910900
Braslia DF Brasil

Universidade de Braslia
Instituto de Cincias Exatas
Departamento de Cincia da Computao

Controle de Acesso Baseado em Papis na

Informatizao de Processos Judiciais

Andr Thiago Souza da Silva

Hugo Vasconcelos Saldanha

Monografia apresentada como requisito parcial

para 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 Pinto
CIC/UnB
Secretrio de TI/STF
Prof a. Cludia Nalon
Coordenador do Bacharelado em Cincia da Computao

Braslia, 11 de agosto de 2006

Agradecimentos
Ao professor Pedro Rezende, por suas valiosas contribuies, sugestes e
orientaes para a realizao desse trabalho.
Ao Renato Bigliazzi, por sua inestimvel colaborao na elicitao dos
requisitos.
Ao professor Luis Antnio da Frota Mattos, por ter se mostrado sempre
prestativo, at mesmo em situaes difceis.

Aos meus pais, Jos Eusbio e Bernadete, pela educao e incentivo que
me proporcionaram.
A Ana Cludia, pelo amor e compreenso que demonstrou durante os
meus 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 trabalho.
A Elisa, pela pacincia e compreenso durante os momentos difceis.

Resumo
O acesso justia por meio eletrnico tem aumentado bastante nos ltimos
anos. Alm de permitir um maior acesso, a informatizao possibilita maior
celeridade no andamento da mesma. Com a disponibilizao das informaes pertencentes a processos por meio eletrnico, necessrio implementar um controle de acesso que reflita a legislao vigente correspondente.
Este trabalho modela o controle de acesso a processos digitais de acordo com
o modelo RBAC, utilizando a ferramenta livre MACA, com uma modificao
para prover autenticao via certificados digitais.
O modelo RBAC foi escolhido por proporcionar maior facilidade na administrao das permisses a recursos em sistemas de grande porte, alm de
refletir, na sua implementao, os papis existentes na organizao, facilitando seu entendimento. A autenticao via certificados digitais proposta
por utilizar criptografia forte, alm de haver uma tendncia pela adoo,
por parte de rgos pblicos, do uso de certificados digitais, graas instituio da Infraestrutura de Chaves Pblicas Brasileira (ICP-Brasil).
Palavras-chave: controle de acesso, RBAC, certificado, LDAP, processo,
segurana

Abstract
Access to justice by eletronic means has increased greatly in the past few
years. Besides allowing a greater access, it makes possible a greater agility in its course. With information from legal proceedings more accessible,
its important to implement an access control that implements the existing
legislation concerning the legal proceedings. The present work models an
access control to eletronic legal proceedings according to RBAC proposed
stardard, making use of MACA, with modifications to provide authentication with digital certificates.
RBAC was chosen because it makes easy to administrate permissions
to resources in large scale systems. It also reflects the existings roles in
the organization, making its understanding easier. Authentication with
digital certificates is proposed because it makes use of strong cryptography,
besides the existence of a tendency for the use of digital certificates by the
public organizations, thanks to the creation of Infraestrutura de Chaves
Pblicas Brasileiras (ICP-Brasil).
Keywords: access control, RBAC, certificate, LDAP, legal proceedings, security

Sumrio
Lista de Figuras

Captulo 1 Introduo
Captulo 2 Modelos de Controle de Acesso
2.1 Conceitos e Terminologia . . . . . . . . . . . . . . . . . . .
2.1.1 Autenticao e autorizao . . . . . . . . . . . . . .
2.1.2 Usurios, sujeitos, objetos, operaes e permisses
2.1.3 Princpio do menor privilgio . . . . . . . . . . . .
2.1.4 Monitor de referncia . . . . . . . . . . . . . . . . .
2.2 Polticas, modelos e mecanismos . . . . . . . . . . . . . .
2.2.1 Modelo de Bell-LaPadula . . . . . . . . . . . . . . .
2.2.2 Modelo Clark-Wilson . . . . . . . . . . . . . . . . .
2.3 Consideraes sobre o controle de acesso compulsrio . .
2.4 Consideraes sobre o controle de acesso discricionrio .

10
.
.
.
.
.
.
.
.
.
.

15
15
16
16
17
18
19
19
20
21
22

Captulo 3 O modelo RBAC Role-Based Access Control

3.1 Viso Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Permisses . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Comparao entre papis e Listas de controle de acesso
3.1.3 Ativao de papis . . . . . . . . . . . . . . . . . . . . .
3.2 Definio formal . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Modelo RBAC do NIST . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Viso geral . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 O ncleo do RBAC . . . . . . . . . . . . . . . . . . . . . .
3.3.3 RBAC Hierrquico . . . . . . . . . . . . . . . . . . . . .
3.3.4 Componente de restries estticas do RBAC . . . . . .
3.3.5 Componente de restries dinmicas do RBAC . . . . .

23
23
25
25
27
27
28
28
29
31
32
32

Captulo 4 O MACA - Middleware de Autenticao e Controle de

Acesso
4.1 Os contextos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 As regras de autorizao . . . . . . . . . . . . . . . . . . . . . .
4.3 O modelo de autorizao contextual do MACA . . . . . . . . .
4.4 Arquitetura e implementao do MACA . . . . . . . . . . . . .
4.5 O algoritmo de deciso de acesso do MACA . . . . . . . . . . .

33
33
34
35
36
39

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

Captulo 5 Modelo de acesso implementado como prova de conceito

5.1 O modelo de acesso proposto . . . . . . . . . . . . . . . . . . . .
5.2 Aspectos de implementao . . . . . . . . . . . . . . . . . . . .
5.2.1 Gerao de chaves . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Autenticao bidirecional usurio-servidor MACA . . .
5.2.3 Autenticao bidirecional MACA - LDAP . . . . . . . .
5.3 Autorizaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41
42
47
47
48
52
54

Captulo 6 Desdobramentos
57
6.1 JuRisBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Documentaes . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Captulo 7 Concluso

64

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 . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 rvore de informaes de diretrio . . . . . . . . . . . . . . . . 37
4.3 Modelo de controle de acesso do SSC . . . . . . . . . . . . . . . 38
5.1 Fluxo de caminhamento do processo . . . . . . . . . . . . . . .
5.2 Hierarquia de papis considerada na implementao do modelo de acesso aos processos . . . . . . . . . . . . . . . . . . . .
5.3 Do lado esquerdo esto representados os recursos acessveis,
com as respectivas operaes associadas.Do lado direito, as
autorizaes contextuais associadas a cada papel. . . . . . . .
5.4 Tela de Autenticao . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Utilizao do keystore para realizar a autenticao . . . . . . .
5.6 Verificao do retorno do mtodo authenticate() . . . . . .
5.7 Implementao do desafio do protocolo SSL no cliente . . . . .
5.8 Modificaes na classe PrincipalAuthenticator . . . . . .
5.9 Modificaes na classe User . . . . . . . . . . . . . . . . . . . .
5.10 Modificaes no cdigo do MACA para autenticao . . . . . .
5.11 Exemplo de acesso no sistema . . . . . . . . . . . . . . . . . . .
5.12 Cdigo do mtodo autorizaAcesso() . . . . . . . . . . . . .
5.13 Diagrama de seqncia com as interaes entre os objetos durante a requisio de acesso a um determinado recurso . . . .
6.1
6.2
6.3
6.4
6.5
6.6

Tela Principal da Aplicao . . . . . . . . . . . . . . . . . . . .

Tela de Cadastro de Processo . . . . . . . . . . . . . . . . . . .
Tela de Cadastro de Parte . . . . . . . . . . . . . . . . . . . . .
Tela de Pesquisa de Processo . . . . . . . . . . . . . . . . . . .
Tela de Movimentao de Processo . . . . . . . . . . . . . . . .
Tela proibindo acesso ao mdulo de movimentao de processo

43
45
46
48
49
50
51
51
52
54
55
55
56
58
58
59
59
60
61

Captulo 1
Introduo
O acesso justia por meio eletrnico tem aumentado bastante nos ltimos
anos. O uso de meio digitais no Judicirio, alm de possibilitar mais um
meio de acesso justia, prov uma maior celeridade na prestao jurisdicional. No faltam iniciativas, que se espalham por todo o pas. As iniciativas locais que vem sendo tomadas por tribunais brasileiros, individual e
separadamente, tm o intuito de agregar uma srie de valores sua prestao jurisdicional. Entre estes valores, esto a celeridade, a publicidade, a
operosidade, a praticidade e a universalidade. H tambm uma iniciativa
de mbito nacional para padrozinar a forma como essa informatizao
disponibilizada, principalmente com relao ao sigilo e autenticidade dos
dados produzidos nessas aplicaes.
Neste contexto, vrios tribunais j disponibilizam seus sites na Internet com informaes gerais sobre o andamento de processos e sentenas.
possvel tambm cadastrar-se em algum desses sites e ser notificado automaticamente sempre que um processo de interesse seja movimentado.
Entretanto, essas iniciativas s contemplam funcionalidades de informao e documentao. A digitalizao de processos ainda um caminho a
ser percorrido, porm j existem muitos esforos neste sentido:
O Supremo Tribunal Federal STF implementou o projeto e-STF que
permitiu a petio por meio eletrnico, fax ou similar; e o Projeto de
Inteligao Informatizada do Poder Judicirio o Infojus, que oferece
uma infra-estrutura em comum de redes de comunicao para os rgos do Poder Judicirio. Alm disso, sua pgina na internet se coloca
como um dos dez melhores sistemas do Pas.
O Superior Tribunal de Justia STJ desenvolve estudos na tentativa de eliminar o papel e utilizar o sistema on-line at mesmo para
peties.
O Projeto de Lei n. 5.828/2001, aprovado pela Cmara dos Deputados,
dispe sobre a informatizao do processo judicial, admitindo o uso
de meio eletrnico na comunicao de atos e a transmisso de peas
processuais.
10

Todo esse cenrio de informatizao citado deve respeitar, alm das boas
prticas de segurana, a jurisprudncia existente. Ou seja, a justia informatizada deve ser um espelho, na medida do possvel, da justia do
mundo da vida. No andamento de um processo vrias regras processuais devem ser respeitadas: h todo um caminho por onde o processo deve
passar, prazos a serem respeitados, alm de um conjunto determinado de
atores jurdicos responsveis pelo andamento do processo, alguns habilitados a decidir, sob determinadas condies, sobre os rumos que o mesmo
pode tomar.
De forma simplificada, o caminho do processo formado por um conjunto
de estados pelo qual ele passa: Petio Inicial, Deferimento, Contestao,
etc., com prazos a serem respeitados. Para fazer o processo caminhar por
entre estados, h um conjunto de atores que devem atuar sobre o processo.
Alm disso, a administrao de um processo extremamente afunilada ao
redor da figura do Juiz, sendo que a maioria dos atos levam a sua assinatura. o rito processual.
A informatizao do rito processual deve seguir as mesmas regras. Nesse
sentido, surge o problema de como controlar e administrar o acesso dos atores jurdicos aos processos. O controle de acesso importante no s para a
manuteno do sigilo de informaes constantes no processo, quando aplicvel, mas tambm para definir, dentre os atores jurdicos que possam vir
a cena, quais esto legal ou legitimamente autorizados, em determinado
momento, a realizar determinada ao sobre determinado processo.
Esse controle envolve no s aos atores jurdicos que atuam no trmite
do processo, mas tambm a intermediao de sistemas computacionais que
possibilitam o acesso de tais atores ao processo, para cumprimento do rito.
Sistemas computacionais que, por sua vez, tambm tm suas regras e mecanismos de acesso, seus atores (usurios, administradores), etc., esses via
de regra representados em vrias camadas de codificao.
Assim, o uso de tecnologia de informao em processos judiciais deve ter
como requisito bsico a definio de um modelo para o controle de acesso a
processos que respeite a autonomia e as prerrogativas dos distintos atores
em diferentes sistemas de forma que, pelo menos idealmente, as relaes
e interdependncias internas dos sistemas o jurdico-fim e o tecnolgicomeio no interfiram de forma despropositada, indevida, subreptcia ou
descontrolada um no outro.
Surgem, ento, questes relativas concepo de um tal modelo de controle de acesso, que possa satisfazer os requisitos citados. Podemos separar
esses requisitos em dois grupos, ou instncias. A primeira refere-se automao de decises sobre autorizar ou no o acesso em determinado modo a
determinado processo ou pea processual, e por qual lgica autorizativa. A
segunda referente ao processo de se administrar as polticas de controle
de acesso, a partir das quais tais decises so executadas.
Sobre a lgica de autorizao, estratgias e diretrizes conflitantes podem ser aplicadas. Ademais, no domnio de aplicao em tela, ou seja, na
informatizao processual judiciria, tais conflitos refletem uma tenso natural 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 esto
aptos a realizar aes sobre determinados processos. Por outro lado, o controle de acesso no pode prejudicar a prestao do servio aos interessados,
devendo garantir a celeridade da justia, que talvez seja o principal objetivo
da informatizao de processos, e que respeita o princpio constitucional da
eficincia1 .
Desta forma, impor uma poltica muito proibitiva, ou engessada, quer
pela aplicao, pelo sistema ou por suas arquiteturas, acaba por prejudicar no s o acesso ao servio informatizado, mas tambm, a mdio e longo
prazos, o bom desempenho de quem responde pela informatizao; j uma
poltica demasiadamente permissiva pode violar os aspectos legais envolvidos ou, pior, abrir novas brechas para fraudes processuais, ainda mais insidiosas e potencialente difceis de erradicar, porque invisveis ou difceis de
rastrear. Assim, no escopo de um planejamento adequado informatizao
do judicirio, deve-se buscar um modelo adequado, onde cada autorizao
concedida/proibida no momento exato, de acordo com a necessidade e o direito do usurio, levando em conta a situao (contexto) existente durante o
acesso. Levando-se, tambm, em conta a complexidade ontolgica dos ritos
processuais, um modelo que leve em conta a escalabilidade no espao de
regras, prerrogativas, atores e aes que compem a poltica de segurana
(da qual a de controle de acesso faz parte), que possa atender demanda
real sem inviabilizar a administrao dessas polticas
Na administrao da poltica de controle de acesso, a questo da racionalidade se torna importante. Normalmente, um processo jurdico informatizado acessado em um sistema distribudo, constitudo de diversas
aplicaes e diversas bases de dados, nas mais variadas plataformas, onde
cada sistema j possui um modelo de controle de acesso. Conceber um modelo que integre tais diversidades, sem inviabiliz-las, um grande desafio.
Seria possvel conceber um mecanismo de administrao de polticas de
controle unificada, que integre de forma coerente os diferentes sistemas, englobando 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 e
portabilidade a outras plataformas, principalmente no que se refere ao controle de acesso (Motta, 2003).
No obstante, para que esse controle de acesso seja realmente efetivo, a
autenticao perante o mecanismo que prov esse servio unificado deve ser
feita de maneira adequada, e de forma a forneer os meios mais abrangentes possveis de se aferir sua confiabilidade. Conceitualmente, para atingir
esse requisito, o modelo deve fazer uso do mecanismo de autenticao atravs de criptografia assimtrica, com utilizao de certificados digitais, por
ser esse o mecansimo que demanda o mnimo possvel em relao a premissas de sigilo (Schneier, 1996). A instituio da Infraestrutura de Chaves
1

Constituio Federal, artigo 37

12

Pblicas Brasileira (ICP-Brasil)2 veio aproximar ainda mais esse cenrio

nacionalmente, fazendo com que a criptografia assimtrica, alm da autenticao, seja utilizada para assinar documentos eletronicamente, provendo
autenticidade, integridade e, quando aplicvel, o no repdio (Schneier,
1996).
O objetivo principal do trabalho a construo de um modelo de controle
de acesso baseado em papis (RBAC - Role-Based Access Control) contextualizado na informatizao de processos que contemple os requisitos apresentados, com o intuito de controlar o acesso a processos do Juizado Especial . Como objetivo secundrios temos: adaptao da arquitetura do MACA
(Modelo de Autorizao Contextual para o Controle de Acesso Baseado em
Papis) (Motta, 2003) para conter autenticao via certificados digitais; e a
implementao de um sistema prottipo que possua os requisitos citados.
A escolha pelo controle de acesso baseado em papis justificada pelo
conjunto de caractersticas que esse modelo possui e que atendem os requisitos 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 permisses
alm daquelas que ele precisa para a realizao de sua funo ou tarefa.
Isso evita o problema de um indivduo ter a capacidade de realizar funes
desnecessrias; ou seja, um usurio s deve possuir as autorizaes indispensveis, mnimas para ele realizar as tarefas ou acessar os dados que ele
necessita. Esta caracterstica fundamental no contexto de acesso aos processos informatizados, onde cada usurio, em um determinado momento,
s pode ser autorizado a realizar as funes que se espera que ele realize e
nada mais.
Em segundo lugar, est a questo da administrao da poltica de segurana do sistema, conforme citamos anteriormente. O modelo de controle
de acesso baseado em papis permite que a administrao da poltica seja
centralizada (Ferraiolo et al., 2003). Uma vez que os papis estejam definidos, e as transaes que esses papis podem realizar estejam estabelecidas
dentro do sistema de acesso, estas transaes tendem a permanecer relativamente constantes ao longo do tempo, evoluindo junto com o sistema
de aplicaes. As atividades administrativas passam a ser, basicamente,
a insero ou a revogao de membros no conjunto de papis especificados
dentro do sistema. Quando um indivduo entra na organizao, o administrador simplesmente o insere em um ou mais papis existentes. Quando a
funo de uma pessoa muda dentro da organizao, basta alterar os papis
ligados a essa pessoa. Quando uma pessoa deixa a organizao, todos os
seus usurios que so membros de papis so removidos. Por fim, como os
papis so utilizados para categorizar autorizaes de funes organizacionais espec ficas, quando as autorizaes e responsabilidades das funes
mudam, basta alterar as autorizaes associadas aos respectivos papis.
Ou seja, o controle de acesso baseado em papis facilita a administrao centralizada por interpor os papis entre usurios e autorizaes, o que
2

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

13

reduz a complexidade e o custo administrativo do controle de acesso, especialmente quando comparado com outros modelos. Isso viabiliza a administra o de uma poltica de acesso detalhada, onde h um grande nmero
de usurios e recursos que acessam mltiplos sistemas, situao em que se
enquadra o contexto de processos informatizados.
Por fim, a existncia de aplicaes prticas do controle de acesso baseado em papis em grandes organizaes um outro fator determinante
para a escolha do modelo baseado em papis. A experincia do Instituto
do Corao, em So Paulo, com mais de 2500 usurios fazendo uso, em um
ambiente distribudo, do MACA (Motta, 2003), que um software livre sob
licena GPL, mostra que realmente possvel aplicar o modelo baseado em
papis realidade.
Com a utilizao do MACA, busca-se explorar o potencial do modelo de
desenvolvimento colaborativo, sob regime de licenciamento livre, para alcanar maior eficincia no atendimento demanda instrumental de mecanismos de segurana prprios para integrao e/ou informatizao de sistemas processuais na esfera judiciria, atualmente reprimida, alavancando e
provendo assim a autonomia do usurio, em relao a fornecedores de componentes, para controlar sua prpria poltica de segurana, autonomia esta
que a prpria essncia desta segurana.
Nos prximos captulos, sero desenvolvidos os diversos conceitos pertinentes modelagem do controle de acesso de processos judiciais: o conceito
de controle de acesso propriamente dito, com a exposio de alguns modelos
de uso consagrado e o RBAC; o padro de RBAC conforme proposto pelo National Institute of Science and Technology - NIST dos EUA; uma descrio
da arquitetura do MACA e as modificaes realizadas; e uma exposio de
uma modelagem do acesso a processos judiciais, mostrando a estrutura organizacional e possveis papis do negcio, relacionados aos atores jurdicos
do domnio de aplicao especfico para o qual se implementou um prottipo
de sistema, com suas resposabilidades e autorizaes.

14

Captulo 2
Modelos de Controle de Acesso
2.1

Conceitos e Terminologia

O controle de acesso a maneira pela qual o acesso (utilizao, modificao, leitura, etc.) a determinado recurso concedido ou proibido de alguma
forma (Ferraiolo et al., 2001). O controle de acesso pode no apenas definir quem tem acesso a um determinado recurso, mas tambm qual tipo
de acesso. O controle pode estar embutido dentro do sistema operacional,
incorporado a aplicaes ou pode ser implementado por meio de pacotes de
segurana. Pode, ainda, ser implementado internamente ao sistema computacional a ser protegido ou ser implementado em dispositivos externos
ao sistema.
O controle de acesso pode tomar diferentes formas. Alm de determinar se um usurio tem permisso para utilizar um recurso, o controle de
acesso pode determinar quando e como esse recurso pode ser utilizado. Por
exemplo, um usurio pode ter acesso a uma rede apenas durante o expediente da empresa. Um processo executado tem permisso somente para
ler, e no para escrever, em um arquivo. Dependendo do nvel de segurana
exigido por uma organizao, um sistema corporativo pode exigir controles
mais complexos, como requerer dois uma mais funcionrios identificados no
sistema ao mesmo tempo para realizar um operao de alto risco.
Sendo um dos vrios aspectos pertencentes a uma soluo de segurana
computacional, o controle de acesso possui propsitos semelhantes aos demais mecanismos de segurana. Todos eles tm como objetivo garantir sigilo, integridade e/ou disponibilidade de recursos. No controle de acesso, o
sigilo e/ou integridade da informao so crticos. Para a condio de sigilo
necessrio que somente usurios autorizados tenham permisso para ler
a informao. J na condio de integridade, apenas usurios autorizados
podem alterar informaes de maneira tambm autorizada. Essas duas
condies so bem claras no controle de acesso. Menos bvia a condio
de disponibilidade, mas tambum possui um importante papel: um usurio que adquire acesso no autorizado a um sistema tem menos dificuldade
para 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 indesejado de usurios. De uma perspectiva comercial, esse objetivo tambm
pode ser descrito em termos de otimizar o compartilhamento dos recursos
e informaes. Afinal, a grande motivao da tecnologia de informao
fazer com que as informaes estejam disponveis para usurios e aplicaes de maneira eficiente, alm de segura. Quanto maior for a capacidade
de compartilhamento da informao, maior a produtividade e utilidade do
sistema.

2.1.1

Autenticao e autorizao

Autorizao e autenticao so dois conceitos fundamentais na rea de controle de acesso. So conceitos distintos mas interdependentes, de forma que
a autorizao a um determinado recurso , na verdade, dependente da autenticao.
Autenticao o processo que determina que a identidade mostrada por
um 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 identificao pessoal;
Algo que possumos, como um carto inteligente ou uma chave;
Algo que somos ou uma caracterstica fsica como uma impresso digital, padro de retina ou uma caracterstica facial.
Enquanto a autenticao um processo de determinar quem somos para
o sistema, autorizao determina o que podemos a fazer. Autorizao referese a uma deciso do tipo sim ou no que determina se um usurio tem
o acesso garantido a um recurso do sistema (Ferraiolo et al., 2003). Um
sistema de informao deve manter alguma relao entre identificadores
de usurios e recursos do sistema, possivelmente anexando uma lista de
usurios autorizados para os recursos ou armazenando uma lista de recursos acessveis com cada identificador de usurio.
De qualquer forma, deve-se notar que a autorizao necessariamente
depende da realizao da autenticao. Se o sistema no for capaz de ter
certeza a respeito da identidade de determinado usurio, no haver uma
maneira correta de determinar se o usurio deve ou no acessar o recurso.

2.1.2

Usurios, sujeitos, objetos, operaes e permisses

Praticamente qualquer modelo de controle de acesso pode ser formalmente

definido utilizando as noes de usurios, sujeitos, objetos, operaes e permisses, e as relaes entre estas entidades. Desta forma, importante a
compreenso destes termos.
16

O termo usurio refere-se pessoa que interage com o sistema computacional. Em muitos projetos, possvel para um nico usurio possuir mltiplos identificadores e estes identificadores podem estar ativos simultaneamente e so os mecanismos de autenticao que possibilitam a ocorrncia
dessa situao.
Um sujeito (subject) um processo de computador agindo em benefcio
de (ou comportando-se como) um usurio. Na realidade, toda e qualquer
ao de um usurio em sistema computacional realizada por meio de algum programa executando em um computador. Um usurio pode ter mltiplos sujeitos em execuo, mesmo se o usurio s possui um identificador
(login). Por exemplo, enquanto um usurio acessa uma pgina na Web utilizando um navegador, um agente de e-mail pode estar executando como um
daemon, consultando um determinado servidor periodicamente, em busca
de novas mensagens. Cada um dos programas do usurio um sujeito, e
o acesso realizado por cada um dos programas ser checado a fim de se
garantir que o usurio que invocou os programas realmente tem acesso a
eles.
Um objeto pode ser qualquer recurso acessvel em um sistema computacional, o que inclui arquivos, perifricos como impressoras, banco de dados,
e at mesmo entidades de granularidade fina como campos individuais em
registros de banco de dados. Objetos so geralmente vistos como entidades
passivas que contm ou recebem informaes, embora seja possvel tratar
programas, impressoras e outras entidades ativas como objetos.
Uma operao um processo ativo invocado por um sujeito. As operaes podem ter diversos nveis de abstrao incluindo operaes mais
comuns como escrita, leitura, alterao at operaes mais complexas e
dependentes da natureza de cada sistema ou domnio de aplicao, como
operaes de movimentao de um processo judicirio, por exemplo.
Permisses (ou privilgios) so autorizaes para realizar alguma ao
no sistema, ou seja, refere-se a alguma forma de combinao entre um objeto e uma operao. Uma determinada operao aplicada a dois objetos
diferentes representa duas permisses distintas e, de forma similar, duas
operaes diferentes aplicadas ao mesmo objeto representam duas permisses diferentes.

2.1.3

Princpio do menor privilgio

O princpio do menor privilgio uma prtica administrativa de controle

de acesso por meio da qual as permisses so associadas aos usurios de tal
forma que a cada usurio so dadas to somente as permisses necessrias
para realizar a funo que o projeta como usurio do sistema. O princpio
do menor privilgio evita o problema de um indivduo possuir a capacidade
de realizar aes desnecessrias e potencialmente prejudiciais ao sistema,
aes que podem surgir como um efeito colateral da associao de permisses desejadas. A grande discusso presente nesta rea de estudos como
associar 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 instalar os limites de separao que so providos pelo mecanismo de controle
de acesso.
A aderncia estrita ao princpio do menor privilgio requer que um indivduo possua diferentes nveis de permisses em momentos diferentes, dependendo da tarefa ou funo sendo realizada. Deve-se reconhecer que em
alguns ambientes e com algumas permisses, restringir permisses porque
elas so nominalmente desnecessrias pode ser inconveniente para o usurio ou colocar uma carga adicional sobre os administradores e complexidade
no sitema, aumentando a chance da ocorrencia de falhas de segurana de
difcil diagnstico. Entretanto, a permisso de privilgios excessivos que
potencialmente podem ser explorados para quebrar a proteo existente,
seja por meio da integridade ou da confidencialidade, que possibilite ou at
estimule o desvio de funo ou abuso de autoridade, sempre que possvel
deve ser evitada.

2.1.4

Monitor de referncia

O monitor de referncia um conceito abstrato, em que as tentativas de

acessos que sujeitos realizam em objetos so autorizadas baseados em informaes contidas em uma base de dados de controle de acesso (Ferraiolo
et al., 2003). O monitor de referncia representa a poro de um sistema
que responsvel pela garantia da poltica de segurana do sistema no que
tange ao controle de acesso. O banco de dados de controle de acesso o responsvel pela manuteno dessa poltica, em termos de atributos ligados
a sujeitos e a objetos e respectivos direitos de acesso. Quando um sujeito
tenta realizar alguma operao em um determinado objeto, o monitor de
referncia deve realizar algum tipo de verificao, geralmente comparando
os atributos do sujeito com aqueles pertencentes ao objeto.
O monitor de referncia no estipula uma poltica especfica para o sistema e muito menos uma implementao em particular. O monitor de referncia, entretanto, define um framework que tem sido muito utilizado
para o projeto, desenvolvimento e implementao de sistemas de segurana
e que tem funcionado como base de avaliao de grau de confiana que pode
ser associado a um sistema computacional.
Os requisitos abstratos de um monitor de referncia so descritos em
trs princpios fundamentais de implementao, mostrados a seguir.
1. Completude: o monitor de referncia deve sempre ser invocado e deve
ser impossvel de desvi-lo. Este princpio requer que um sujeito s
possa 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 intransponvel, ou sejam deve ser impossvel para um estranho ao sistema atacar
18

o mecanismo de controle de acesso de forma que afete o desempenho

da verificao de autorizao.
3. Verificabilidade: deve ser possvel de demonstrar que foi implementado corretamente. Este princpio pode ser alcanado por meio de
critrios de projeto e prticas de engenharia de software (Ferraiolo
et al., 2003). A idia que o monitor de referncia seja to pequeno
e to simples quanto possvel, excluindo qualquer funcionalidade da
qual a segurana do sistema no seja dependente e reduzindo-o a um
pequeno conjunto de interfaces.
Estes princpios fornecem um guia arquitetural para o projeto e para o
processo de desenvolvimento de um sistema de controle de acesso. O grau
em que o sistema se relaciona com esses princpios serve como uma medida
do nvel de confiana e correo dos controles de segurana do sistema.

2.2
2.2.1

Polticas, modelos e mecanismos

Modelo de Bell-LaPadula

O modelo de Bell-LaPadula (Bell and LaPadula, 1973) uma descrio formal dos caminhos permitidos para o fluxo da informao em um sistema. O
objetivo do modelo identificar as formas de comunicao permitidas, em
que importante a preservao de sigilo. O modelo tem sido utilizado para
definir os requisitos de segurana para sistemas que tratam, concorrentemente, dados com diferentes nveis de sensibilidade. Esse modelo serve
para formalizar polticas de segurana multinvel.
Bell and LaPadula (1973) utilizam mquinas de estados finitos para a
formalizao de seu modelo. So definidos vrios componentes da mquina
de estados finitos, que definem, de maneira formal, o que significa um determinado estado ser seguro, e consideram as transies que so permitidas
de tal forma que ao deixar um estado seguro, um estado inseguro nunca
possa ser alcanado.
No modelo, so includos nveis de segurana que refletem sistemas de
segurana militar: cada sujeito possui um nvel de segurana mximo, e
cada objeto tem uma classificao.
1. Propriedade da Segurana Simples: nenhum sujeito possui acesso de
leitura a qualquer objeto que possua uma classificao maior que o
nvel de segurana do sujeito; e
2. A Propriedade Estrela (*): nenhum sujeito possui acesso de escrita
a um objeto cujo nvel de segurana for diferente ao nvel corrente
daquele sujeito; e nenhum sujeito possui direito de leitura em objetos
cujo nvel de segurana seja maior que o nvel de segurana corrente
daquele sujeito.
19

No modelo militar, a propriedade da segurana simples afirma que um

usurio com um determinado nvel de segurana no possui a permisso
de leitura de informao cujo nvel esteja acima do seu; por exemplo, um
usurio com nvel de segurana secreto no pode ler documentos classificados como ultra-secretos. Da mesma forma, a propriedade estrela afirma
um usurio operando em determinado nvel de segurana s pode escrever
informao naquele nvel ou acima; por exemplo, se um usurio for identificado como do nvel secreto, programas e processos operados por aquele
usurio no so permitidos escrever informaes em nveis de classificao
mais baixos, como confidencial, mas podem escrever em nveis mais altos,
como ultra-secreto.

2.2.2

Modelo Clark-Wilson

Clark and Wilson (1987) documentaram uma viso generalizada da poltica

de segurana comercial, demonstrando o quanto elas diferem das polticas
de segurana militares. Eles propuseram dois princpios como os mais importantes na busca de garantia para manuteno da integridade: transaes bem formadas e separao de responsabilidades.
Transaes bem formadas limitam a forma que os usurios podem modificar os dados, assegurando que todos os dados que iniciem em um estado
vlido permanecero vlidos aps a execuo da transao. A unidade bsica de controle de acesso do modelo uma tripla, composta por usurio,
procedimento de transformao e um item de dados confinado. Um procedimento de transformao uma transao e um item de dados confinado
aquele cuja integridade deve ser preservada.
O princpio da separao de responsabilidades assegura a consistncia
de mudanas realizadas em dados crticos, o que previne que usurios autorizados realizem modificaes imprprias, contribuindo, assim, para a integridade dos dados. A separao de responsabilidades aplicada por meio
da diviso de operaes em diversas suboperaes e estabelecendo que diferentes pessoas realizem cada uma dessas suboperaes. Por exemplo, num
processo de compra de uma determinada mercadoria envolvendo os passos
de autorizao do pedido de compra e autorizao do pagamento; por meio
da separao de responsabilidades, exige-se que cada uma das partes seja
realizada por uma pessoa diferente e que o segundo passo s se concretize
aps 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 Clark
and Wilson (1987) impe o controle ao nvel da aplicao. Esta diferena
resultante dos objetivos pretendidos por cada um dos modelos. O modelo
de segurana multinvel, cuja base o modelo de Bell-LaPadula, pretende
controlar o fluxo de informao, definido em termos de operaes de leitura
e escrita. J o modelo comercial de integridade, como definido por Clark
and Wilson (1987), deve assegurar que a informao s modificada de
forma autorizada por pessoas autorizadas.
20

2.3

Consideraes sobre o controle de acesso

compulsrio

O controle de acesso compulsrio uma poltica de acesso suportada por sistemas que processam dados com elevada sensibilidade, como por exemplo
informaes de governo ou dados sigilosos de corporaes.
Sistemas que provem o controle de acesso compulsrio devem associar
rtulos de sensibilidade a todos os sujeitos (usurios, programas) e a todos os objetos (arquivos, diretrios, dispositivos, etc.) do sistema. O rtulo
de sensibilidade do usurio especifica o nvel de confiana associado quele
usurio. O rtulo de sensibilidade de um objeto especifica o nvel de confiana que o usurio deve possuir para ser capaz de acessar aquele objeto.
Desta forma, o controle de acesso compulsrio utiliza rtulos de sensibilidade para determinar quem pode acessar qual informao no sistema.
Os rtulos em conjunto com o controle de acesso compulsrio implementam uma poltica de segurana multinvel, como aquela formalizada por
Bell and LaPadula (1973).
Em um sistema de controle de acesso compulsrio, todas as decises de
acesso so realizadas pelo sistema. A deciso para negar ou permitir o
acesso a um objeto, como por exemplo um arquivo, envolve uma interao
entre 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 no
arquivo.
Quando realizada a tentativa de leitura do arquivo A, o sistema compara o rtulo de sensibilidade do sujeito com o rtulo do arquivo para determinar se o sujeito tem permisso de leitura do arquivo.
Para ser possvel a leitura de um objeto, o nvel de sensibilidade do sujeito deve dominar o nvel de sensibilidade do objeto, ou seja, o rtulo do
sujeito deve ser igual ou superar o rtulo do objeto. Por exemplo, se o rtulo
do arquivo SECRETO, para ser possvel a leitura, o rtulo do sujeito deve
ser SECRETO ou maior do que SECRETO.
Para ser possvel a escrita, o nvel de sensibilidade do objeto deve dominar o nvel de sensibilidade do sujeito, ou seja, o rtulo do sujeito deve ser
igual ou inferior ao rtulo do objeto. Assim, se o rtulo do sujeito for SUPER
SECRETO e o rtulo do objeto for SECRETO, o sujeito no pode escrever no
objeto.
A figura 2.1 ilustra esse princpio.
21

Figura 2.1: Viso do controle de acesso compulsrio

2.4

Consideraes sobre o controle de acesso

discricionrio

O controle de acesso discricionrio uma poltica de acesso a objetos baseado na identidade de usurio e/ou grupos aos quais eles pertencem, possivelmente configurveis atravs de permisses.
Em contraste com o controle de acesso compulsrio, onde o controle de
acesso imposto pelo sistema, o controle de acesso discricionrio aplicado
conforme a prpria discrio do usurio que tenha direitos para tal, como
por exemplo, ao gravar um arquivo em seu diretrio de trabalho; com o
controle de acesso compulsrio, pode-se escolher sobre o que fazer com os
dados de sua propriedade; com o acesso compulsrio, isso no possvel.
O controle de acesso discricionrio no apenas permite ao usurio informar ao sistema quem pode acessar os seus dados, mas tambm permite
especificar o tipo de acesso permitido. Por exemplo, o usurio pode desejar
que todos do sistema sejam capazes de ler um arquivo em particular, mas
somente ele deve ser capaz de modificar aquele arquivo.

22

Captulo 3
O modelo RBAC Role-Based
Access Control
3.1

Viso Geral

No controle de acesso baseado em papis (RBAC), o acesso a objetos de um

sistema computacional baseado no papel que o usurio escolhe para exercer numa determinada sesso (Ferraiolo et al., 2003). O modelo RBAC , ao
mesmo tempo, uma abstrao e uma generalizao. Uma abstrao porque
no inclui propriedades que no so relevantes para a segurana. Uma generalizao, pois diversos projetos ou modelos de controle de acesso podem
ser considerados uma interpretao, ou caso particular, do modelo baseado
em papis. Logo, o modelo RBAC til como uma base para o projeto de
diversos sistemas de TI. Seu principal propsito consiste em facilitar a gerncia e manuteno das autorizaes de acesso no sistema, e a anlise de
vulnerabilidades necessria sua evoluo.
O modelo RBAC possui quatro sub-modelos:
RBAC ncleo (core RBAC), que abrange o conjunto bsico de funcionalidades presentes em todos os sistemas RBAC;
RBAC hierrquico (hierarchical RBAC), que inclui o conceito de hierarquia de papis, definida atravs de uma ordenao de papis;
RBAC com restries estticas (static constrained RBAC), que inclui restries impostas na designao de papis; e
RBAC com restries dinmicas (dynamic constrained RBAC), que
impe restries na ativao de conjunto de papis que podem ser includos 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 construo
semntica em torno da qual cada poltica de segurana formulada. As
mais bsicas dessas relaes so as designaes de usurios e permisses.
No RBAC, permisses so associadas a papis, e usurios so feitos membros de papis, no sentido de poderem exerc-los. . Assim, podem exercer
as permisses , atribudas a determinado papel, ao assumi-lo. A figura 3.1
mostra o relacionamento entre usurios, papis e permisses. Na figura,
usa-se as setas nas duas direes para indicar um relacionamento muitospara-muitos. Por exemplo, um nico usurio pode se associar com um ou
vrios 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 atribuio de permisses a papis, e de usurios a papis. Alm disso, o aumento da flexibilidade no controle de acesso a recursos tambm fortifica a
aplicao do princpio do privilgio mnimo.
Essa capacidade administrativa do modelo RBAC uma de suas maiores
virtudes. A administrao das informaes sobre autorizaes largamente
conhecida como um processo oneroso com um enorme e recorrente gasto.
Sob o modelo RBAC, usurios so designados a papis baseado na sua
competncia, autoridade e responsabilidades. Essas associaes de usurios a papis podem ser facilmente revogadas e novas podem ser estabelecidas com a mesma facilidade. Com o RBAC, as permisses no so dadas
aos usurios individualmente. Ao invs disso, permisses so associadas
com os papis, um conjunto bem menor que o de usurios em grandes organizaes. Novas associaes entre permisses e papis podem ser criadas
enquanto antigas so removidas na medida que as funes organizacionais
mudam e evoluem. Esse relacionamento entre os papis do modelo RBAC
e os papis exercidos na organizao facilita grandemente o entendimento
e o gerenciamento de permisses: os administradores de sistema podem
atualizar os papis sem ter que atualizar permisses para cada usurio do
sistema individualmente.

24

3.1.1

Permisses

Ao modelar um sistema de controle de acesso, os administradores de sistemas podem tratar as permisses como um conceito abstrato que se refere
ligao arbitrria entre operaes e objetos, levando em considerao, em
alguns casos, processos e valores. O conjunto de permisses designado a um
papel d o potencial para que tarefas, funes, ou outra abstrao qualquer
relativa a trabalho, sejam executadas. Designar um usurio a um papel
confere a habilidade de execut-las.
Permisses designadas a um determinado papel refletem polticas determinadas pela organizao que possui o sistema, tanto em relao ao mtodo
de acesso ao objeto como tambm em relao ao que acessado no objeto.
Para entender as polticas em relao ao mtodo de acesso, basta saber que
existe a possibilidade de que um papel possa s ler dados e outro s escrever dados. Outra possibilidade um papel poder somente criar dados, mas
no edit-los, enquanto outro pode somente editar depois de os dados j estarem criados. Em relao ao acesso, um determinado papel pode acessar
todos os dados de um arquivo texto, porm, outro pode acessar s um dos
trechos do documento.
As permisses ainda podem refletir outros aspectos como regras impostas pelas condies do ambiente, como por exemplo, expresso por metadados
ou ontologias aplicveis ao recurso em foco. Num exemplo em domnio de
aplicao especfico, quando um mdico deve ser autorizado apenas a divulgar somente o resultado de certos exames, no podendo divulgar os exames
por inteiro, pois a porosidade de um ambiente em rede e erros humanos
podem violar a privacidade do paciente. Permisses pdem refletir tambm
leis e regulamentos quando, por exemplo, uma enfermeira est autorizada
apenas a adicionar novas entradas no pronturio de um paciente, mas no
modificaes no registro.

3.1.2

Comparao entre papis e Listas de controle de

acesso

Uma lista de controle de acesso (access control list ACL) contem os nomes dos sujeitos autorizados a acessar o objeto ao qual ela se refere, e as
suas respectivas permisses de acesso. Por exemplo, quando um usurio
deseja acessar um determinado arquivo, o sistema faz uma busca na ACL
deste arquivo por uma entrada que corresponda ao usurio. Se a encontra,
verifica se a operao requisitada faz parte do conjunto de permisses que
esse usurio possui para acesso ao arquivo. Em caso positivo, o acesso ser
concedido.
O privilgio de criao e manuteno das ACLs de um sistema depende
do conceito de proprietrio da informao (ou do recurso) do modelo de
controle de acesso aplicado. Em sistemas que aplicam polticas discricionrias, o proprietrio do objeto seu criador, o qual tem o privilgio de
administrar o acesso a esse objeto. J nos sistemas que suportam polticas
no 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 acesso
ao objeto correspondente. Isso evita a repetio na atribuio de permisses.
Basicamente, um papel pode ser considerado semelhante a um grupo.
Um papel representa um ou mais usurios, e um usurio membro de um
ou mais papis. Da mesma forma, possvel associar uma permisso a vrios grupos e papis, assim como um grupo ou papel pode possuir vrias
permisses. Neste nvel de entendimento no se percebem diferenas entre papis e grupos de usurio. Contudo, h uma variedade de diferenas
entre seus significados nos modelos de acesso e entre seu uso nas implementaes.
Uma diferena essencial est no fato de que o conceito de grupo especfico de cada implementao. Por exemplo, em alguns sistemas UNIX,
somente um grupo pode ser associado a cada arquivo. Outros sistemas operacionais permitem a associao de vrios grupos. Ainda h aqueles que
no permitem a um usurio fazer parte de mais de um grupo.
J no modelo RBAC, o papel um elemento central e est definido em
termos de um conjunto de propriedades fixas, no importando a sua implementao. Uma dessas propriedades a relao muitos-para-muitos entre
papis e usurios e entre papis e permisses. Neste caso, para que um
grupo possa ser considerado como uma implementao do conceito de papel do modelo RBAC, sua estrutura no pode restringir o nmero: de grupos que poderiam ser criados; de usurios que possam ser membros de um
grupo; de grupos que o usurio pode pertencer simultaneamente; de grupos
includos na lista de controle de acesso de um objeto. Ainda, no RBAC o
usurio estar, numa sesso, sempre exercendo algum papel, cujas permisses no seriam combinadas de forma fixa com as de seus outros possveis
papis, como seria o caso com grupos, ao acessar um recurso.
Sendo o RBAC um modelo, e no um mecanismo, pode ser implementado
em diversos tipos de sistema para incluir gerncia de redes e empreendimentos com um escopo que vai muito alm de apenas um sistema operacional ou aplicao. Papis e usurios so tratados como entidades globais
que possuem relao com permisses dos diferentes sistemas onde o modelo aplicado, tornando a administrao mais simples, eficiente e menos
propensa s falhas no controle de autorizao mais sutis.
Por fim, o conceito principal do modelo RBAC so os relacionamentos
dos papis. Alm de possuir os relacionamentos com usurios e permisses,
que servem como uma construo semntica na qual as polticas de controle
de acesso so formuladas, existe ainda as relaes de hierarquia e herana
entre papis, e os relacionamentos de restrio esttica e dinmica, caractersticas no existentes entre as implementaes de grupos.

26

3.1.3

Ativao de papis

Da mesma maneira que vrios outros tipos de modelos, o RBAC inclui o

conceito de sujeitos e objetos. De modo geral, as propriedades e mapeamentos definidos pelo modelo RBAC podem ser divididos em duas componentes
separadas, mas dependentes: uma esttica e outra dinmica. A componente esttica, discutida resumidamente at aqui, aquela que no possui
relacionamentos que envolvem o conceito de sujeito. Quando aplicamos polticas de segurana dinamicamente em um sistema, usamos a noo de
sujeitos, que so entidades ativas cujo acesso a papis, operaes e objetos,
deve ser controlado. Um sujeito agindo em nome de um usurio efetua todas as suas requisies. referenciado unicamente por um identificador,
usado para determinar se o referente est autorizado a exercer um papel
e, se estiver, poder ativ-lo. Um usurio pode estar associado com inmeros sujeitos a qualquer momento. Cada sujeito pode ter uma combinao
diferente de papis ativados. Essa funcionalidade mantm o princpio do
privilgio mnimo, j que um usurio que est associado com vrios papis
pode ativar um conjunto de papis mnimo para realizar as atividades de
cada sujeito.

3.2

Definio formal

O modelo RBAC possui uma definio formal, dada por Ferraiolo and Kuhn
(1992). Para cada sujeito, o papel ativo aquele que o sujeito est usando
naquele 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) verdadeiro se, e somente se, o sujeito s pode executar a transao t naquele
momento; 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 selecionou
ou 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 outras restries possam ser colocadas na execuo de transaes.

3.3
3.3.1

Modelo RBAC do NIST

Viso geral

O padro proposto pelo NIST (Ferraiolo et al., 2001) foi projetado com o
objetivo de prover uma definio autoritativa de funcionalidades bem aceitas do RBAC, para o uso em sistemas de gerenciamento de autorizaes. O
padro estruturado em duas partes, descritas como se segue:
Um modelo de referncia, definido como uma coleo de quatro componentes do modelo RBAC: o ncleo, o hierrquico, o de restrio esttica e o de restrio dinmica. Os componentes do modelo existem
para fornecer um vocabulrio padro de termos relevantes para definir um extenso conjunto de funcionalidades do RBAC.
Uma especificao funcional que projeta o modelo de referncia em
um conjunto congruente de componentes funcionais, onde cada componente define requisitos especficos de operaes administrativas para
criar e manter os conjuntos e relaes do RBAC, funes de reviso e
funcionalidades do sistema correspondentes ao respectivo componente
do modelo.
O padro descreve uma abordagem lgica ao definir pacotes de componentes funcionais, onde cada pacote corresponde a um segmento de ambiente ou mercado diferente. O conceito bsico que cada componente possa
opcionalmente ser selecionado para ser includo em um pacote com apenas
uma execuo - componente ncleo do RBAC deve estar includo em todos
os pacotes.
Na definio de pacotes funcionais, o ncleo do RBAC nico pelo fato de
que fundamental e deve ser includo em todos os pacotes. Inclusive, para
alguns ambientes, a sua seleo j suficiente. O componente hierrquico
dividido em duas partes: hierarquias de papis gerais e limitadas. O
componente 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 diviso
e escolhido por inteiro ou no.
Cada componente do modelo de referncia definido pelos seguintes
subcomponentes:
28

 um conjunto de conjuntos bsicos de elementos;

um conjunto de relaes RBAC envolvendo esses conjuntos de elementos;
um conjunto de funes mapeadoras que geram instncias de membros de um conjunto de elementos para uma dada instncia de um
outro conjunto de elementos.
A especificao funcional do RBAC esboa a semntica de vrias funes
que so necessrias na criao e manuteno dos componentes do modelo
RBAC (conjuntos de elementos e suas relaes), como tambm no suporte
de funes do sistema. As trs categorias de funes em uma especificao
funcional do RBAC e seu propsito so descritas como se segue:
Funes administrativas: Criao e manuteno de conjuntos de elementos e suas relaes na construo dos vrios componentes do modelo RBAC;
Funes de suporte do sistema: Funes que so necessrias pela implementao 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 aes
criadas pelas funes administrativas.

3.3.2

O ncleo do RBAC

No componente ncleo do RBAC as funes administrativas so descritas

como se segue:
Criao e manuteno de conjuntos de elementos: os conjuntos bsicos
de elementos so USERS (usurios), ROLES (papis), OPS (operaes)
e OBS (objetos). Desses conjuntos, os ltimos dois so considerados
predefinidos pelo sistema de informao sobre o qual o RBAC desenvolvido;
Criao e manuteno de relaes: as duas principais relaes so a
designao de usurios a papis (user-to-role assignment - UA) e a
designao de permisses a papis (permission-to-role assignment PA). As funes de criao e remoo de instncias das relaes UA
so AssignUser (criao) e DeassignUser (remoo). Para as relaes PA, as funes necessrias so GrantPermission (criao) e
RevokePermission (remoo).
As funes de suporte so necessrias para a gerncia de sesses e na
tomada de decises do controle de acesso. Um papel ativo necessrio na
regulao do controle de acesso para um usurio durante uma sesso. A
funo 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 composio desse conjunto padro durante a sesso adicionando ou removendo
papis. As funes relacionadas com a adio e remoo de papis ativos e
outras funes auxiliares so as seguintes:
CreateSession: Cria um sesso de usurio e fornece ao usurio um
conjunto padro de papis;
AddActiveRole: Adiciona um papel como um papel ativo para a sesso atual;
DropActiveRole: Remove um papel do conjunto de papis ativos da
sesso atual;
CheckAccess: Determina se um processo da sesso tem permisso
para realizar a operao requerida em um objeto.
As funes de inspeo so aquelas que permitem ao administrador do
sistema verificar todos os usurios relacionados com um determinado papel
bem como os papis relacionados com um determinado usurio. Alm disso,
tambm permitem que o administrador verifique os resultados das funes
de suporte ao determinar os atributos de sesso (papis ativos e permisses). 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 um
determinado papel;
AssignedRoles (M): retorna o conjunto de papis designados a um
determinado usurio;
RolePermissions (O): retorna o conjunto de permisses dadas a um
determinado papel;
UserPermissions (O): retorna o conjunto de permisses que um determinado usurio tem a partir dos seus papis;
SessionRoles (O): retorna o conjunto de papis ativos associados
sesso;
SessionPermissions (O): retorna o conjunto de permisses disponveis na sesso (i. e., a unio de todas as permisses designadas aos
papis ativos da sesso);
RoleOperationsOnObject (O): retorna o conjunto de operaes um
dado papel pode realizar em um dado objeto;
UserOperationsOnObjects (O): retorna o conjunto de operaes um
dado usurio podem realizar em um dado objeto.
30

3.3.3

RBAC Hierrquico

Nesse componente esto presentes todas as funes administrativas que

existem no RBAC ncleo. No entanto, a funo DeassignUser deve ser redefinida porque com a presena de hierarquias de papis um usurio pode
herdar uma autorizao para um papel mesmo no estando diretamente
designado para este papel. Logo, a hierarquia permite que usurios herdem permisses de papis que esto abaixo do seu papel na hierarquia. A
questo : o usurio somente pode ser removido de uma relao com um
papel diretamente designado a ele, ou pode ser removido de uma relao
com um papel herdado? A resposta fica a cargo da implementao e no
descrita no padro.
As funes administrativas adicionais do componente hierrquico so
relativas a criao e manuteno de relaes de hierarquia entre papis. As
operaes consistem em criar ou remover uma relao de hierarquia entre
dois papis existentes em um conjunto de papis, ou adicionar um novo
papel hierarquia, posicionando-o apropriadamente. O nome e o propsito
dessas funes so descritas como se segue:
AddInheritance: estabelece uma nova relao de herana imediata
entre dois papis;
DeleteInheritance: remove uma relao de herana imediata entre dois papis;
AddAscendant: cria um novo papel e coloca-o como ascendente imediato de um papel;
AddDescendant: cria um novo papel e coloca-o como descendente
imediato de um papel.
As funes de suporte do componente hierrquico so aquelas do ncleo
do RBAC, com a mesma funcionalidade, contudo as funes CreateSession
e AddActiveRole, por causa da hierarquia de papis, precisam ser redefinidas. Da mesma forma, as funes de inspeo do ncleo do RBAC tambm so vlidas para o componente hierrquico. Em adio, algumas funes so redefinidas pelo fato de que os conjuntos de relaes entre papis e
usurios no possuem apenas elementos diretamente associados, mas tambm aqueles advindos das relaes de hierarquia de papis. As funes so
definidas abaixo:
AuthorizedUsers: retorna o conjunto de usurios diretamente associados a um papel bem como aqueles usurios que esto associados a
papis que herdam esse papel;
AuthorizedRoles: retorna o conjunto de papis diretamente associados a um usurio bem como aqueles papis herdados pelos papis
diretamente associados ao usurio.
31

Alm disso, as funes de inspeo relativas s permisses associadas

a usurios e papis devem ser igualmente redefinidas considerando-se as
relaes de hierarquia.

3.3.4

Componente de restries estticas do RBAC

Para um modelo RBAC com restries estticas que no inclui hierarquia

de papis, as funes administrativas devem conter todas aquelas que esto no ncleo do RBAC. Contudo, a funo AssignUser deve incorporar a
funcionalidade de verificao e garantia que a designao de um papel para
o 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 um
usurio a um determinado conjunto de papis simultaneamente deve ser
restringida; role_set, conjunto de papis constituintes da relao de restrio esttica; SSD_Card, que define a cardinalidade do subconjunto contido em role_set a qual a associao simultnea de papis deve ser restringida. Portanto, as funes administrativas relacionadas a criao e manuteno de uma relao de restrio esttica so operaes para:
criar e remover uma instncia de uma restrio esttica (CreateSSDSet
e 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 funes
acima produzem o mesmo resultado com uma nica exceo: restries relacionadas hierarquia de papis devem ser levadas em conta ao aplicar
uma dessas funes.

3.3.5

Componente de restries dinmicas do RBAC

A semntica para a criao de instncias de restries dinmicas idntica quela das restries estticas. Enquanto as restries estticas so
aplicadas no momento da designao de papis ao usurio (e tambm na
criao de hierarquia de papis), as restries dinmicas so aplicadas no
momento da ativao do papel por um usurio durante uma sesso.
As funes administrativas para restries dinmicas so: criao e remoo 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 cardinalidade dos papis da restrio dinmica (SetDSDCardinality).
As funes de suporte para criao de sesso (CreateSession) e ativao de papis (AddActiveRole e DropActiveRole) devem ser modificadas para aplicar as restries dinmicas no momento em que so chamadas.
32

Captulo 4
O MACA - Middleware de
Autenticao e Controle de
Acesso
Este captulo apresenta o MACA Middleware de Autorizao e Controle de
Acesso, a ferramenta que foi utilizada como servidor de controle de acesso
para o prottipo desenvolvido. O MACA uma ferramenta com cdigo
aberto e licena livre que implementa um modelo de autorizao contextual
para o controle de acesso baseado em papis. Uma autorizao contextual
usa informaes ambientais disponveis durante o momento de acesso para
decidir se um usurio tem ou no o direito de acessar um recurso, e de
que modo.
Este captulo est dividido da seguinte forma: a seo 4.1 explica o que
vem a ser um contexto do MACA; a seo 4.2 define o que so regras de
autorizao; a seo 4.3 apresenta o modelo de autorizao do MACA; a
seo 4.4 apresenta aspectos de arquitetura e de implementao do MACA;
por fim, apresentada uma viso geral do algoritmo de deciso de acesso
do MACA.

4.1

Os contextos

Um contexto qualquer informao que pode ser utilizada para distinguir

e caracterizar uma entidade (pessoa, lugar, objeto) considerada relevante
para a interao entre um usurio e uma aplicao, incluindo-se a o prprio
usurio e a prpria aplicao. O contexto denota informaes ambientais
para decidir se um acesso ser permitido ou proibido, no momento em que
o usurio tenta efetu-lo.
No MACA, h o contexto do usurio corrente (aquele que iniciou uma
sesso e que solicita uma autorizao de acesso); o contexto temporal, com
informaes sobre hora e data; o contexto de rede, com informaes de redes
e de comunicao; e outros contextos que podem ser livremente definidos e
implementados pelos formuladores e administradores da poltica de acesso.
As informaes disponveis em um contexto so recuperadas de acordo
33

com a sintaxe <nome do contexto>.<nome>, onde o primeiro termo designa o nome do contexto e o segundo termo pode designar:
uma varivel contextual, como, por exemplo, a varivel nome do contexto do usurio (usuarioCtx.nome) ou um dia da semana do contexto temporal (dtCtx.dia_semana);
um conjunto contextual, como, por exemplo, o conjunto de dias teis
da semana do contexto temporal (dtCtx.dias_teis); ou
uma funo contextual, como, por exemplo, a funo advCtx.assiste
(umCodParte, usuarioCtx.registro_profissional), que informa
se a parte identificada por umCodParte assistida pelo usurio corrente identificado pela varivel usuarioCtx.registro_profissional.
Deve-se lembrar que os contextos devem refletir, com alto nvel de abstrao, as entidades e os relacionamentos existentes entre elas no ambiente
onde o acesso realizado, a fim de facilitar a definio das polticas.

4.2

As regras de autorizao

Uma regra de autorizao relaciona informaes contextuais em expresses

lgicas que especificam uma poltica de acesso para um objeto protegido. As
regras so definidas numa linguagem de expresses lgicas capaz de recuperar os valores provenientes de variveis, conjuntos e funes contextuais
para relacion-las por meio de operadores aritmticos (+, -, *, %), relacionais (>, <, >=, <=, =, !=, in pertinncia) e booleanos (&, |, !).
Uma regra suporta os seguintes tipos de valores primitivos:
Booleano: valores do tipo true (verdadeiro) ou false (falso).
Inteiro: tipo que contm valores de nmeros inteiros;
Texto: tipo que contm valores que so cadeias de caracteres com tamanho varivel.
Vale lembrar que uma regra de autorizao, quando avaliada, sempre
deve retornar um valor do tipo booleano, caso contrrio, ocorrer um erro
pela impossibilidade de se decidir pela concesso ou negao de acesso.
H casos, ainda, em que uma regra precisa ser parametrizada para permitir a passagem de informaes contextuais do ambiente da aplicao (que
solicita a autorizao) para a regra, no momento de sua avaliao. Um
exemplo dessa situao mostrado a seguir:
umDia in dtCtx.dia_semana

34

Nesse caso, o valor do identificador umDia depende do momento em que

a aplicao solicita o acesso. Para que a regra se torne vlida, o identificador deve se subordinar a um contexto ou ser declarado explicitamente
como um parmetro de uma regra. A regra anterior torna-se uma regra
bem 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 parametrizada; 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 lista
de argumentos correspondentes aos parmetros formais seja definida. Podem ser passados como argumentos de uma regra parametrizada valores
primitivos (booleanos, inteiros, texto); variveis, conjuntos e funes contextuais; e demais expresses da linguagem, inclusive regras parametrizadas.

4.3

O modelo de autorizao contextual do MACA

Conforme j dito, o MACA estende a especificao do controle de acesso baseado em papis, com o acrscimo de autorizaes contextuais, de autorizaes positivas e negativas, de autorizaes fortes e fracas, da possibilidade
de revogar-se autorizaes e da separao de responsabilidades esttica e
dinmica 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 explicitamente o acesso. Quando o acesso proibido para a maioria dos papis
descendentes, uma autorizao negativa deve ser usada no papel ascendente. De maneira similar, quando o acesso permitido para a maioria dos
papis descendentes, uma autorizao positiva deve ser definida no papel
ascendente. Por exemplo: considere que, em uma hierarquia de papis, a
maioria dos papis tem o direito de pesquisar um processo; ento, essa autorizao deve ser definida como positiva no papel ascendente, a fim de que
os descendentes herdem essa autorizao. De forma anloga, suponha que
apenas uma minoria da descendncia tenha a capacidade de proferir uma
sentena; assim, essa autorizao pode ser definida como negativa no papel ascendente e redefinida como positiva apenas nos papis que possuem
o privilgio de execut-la.
Uma autorizao pode, ainda, ser do tipo fraca ou forte. Autorizaes
fortes estabelecem polticas absolutas, que no podem ser revogadas, enquanto as fracas so utilizadas para definir polticas mais permissivas.
35

Desta forma, autorizaes fortes e fracas podem ser utilizadas para resolver conflitos. As autorizaes fortes devem ser utilizadas para proteger
recursos considerados crticos, que envolvam conflitos de interesses. Na
presena de uma autorizao forte em um papel, esta no pode ser redefinida nos papis descendentes; quando da existncia de conflitos entre autorizaes fortes, opta-se por negar o acesso. As autorizaes fracas so
utilizadas para definir polticas que podem ser revogadas, permitindo que
autorizaes possam ser redefinidas em papis descendentes; quando da
ocorrncia de conflitos entre autorizaes fracas, prevalecer aquela que
concede 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 software e de comunicao para suportar a implementao do MACA. um
modelo cliente-servidor multicamada com os seguintes componentes principais: um servidor LDAP, encarregado de manter a base de gerncia de informaes de segurana (BIGS); um servidor de segurana, encarregado de
oferecer servios de autenticao de usurio, de deciso de acesso recursos, etc.; e finalmente, as aplicaes clientes que requisitam estes servios
de segurana. Foram adotados, na arquitetura, padres de processamento
aberto e distribudos. A seguir, detalhado cada um desses componentes.
A BIGS mantm os perfis de segurana para proteo da aplicao cliente, tais como, autorizaes de acesso, papis, representaes dos recur36

sos protegidos e dos usurios, dados para autenticao, relacionamentos

papis-usurios, papis-autorizaes, etc. Essas informaes so armazenadas em um servio de diretrio hierarquizado, cujo acesso e esquemas
de descrio de dados so padronizados atravs do protocolo LDAP. Esquemas de dados preexistentes no LDAP so utilizados no armazenamento de
informaes 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 integridade
na comunicao. As informaes persistentes do MACA foram representadas com esquemas do protocolo LDAP verso 3, sendo que o modelo de dados 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 de
diretrios interconectados que se comunicam por meio do protocolo LDAP
para atender as requisies (pesquisa, comparao, insero, remoo, etc.)
de clientes. O diretrio organiza as informaes numa estrutura hierarquizada, denominada rvore de Informaes de Diretrio (AID), numa verso
simplificada do modelo de dados X500 (fig. 4.2). Cada entrada na AID corresponde a um registro armazenado. A estrutura de dados de uma entrada
determinada pelas classes de objeto a que ela pertence; essa classe especifica os tipos de atributos de uma entrada que pertence classe. Cada
entrada identificada unicamente numa AID pelo seu Distinguished Name
37

(DN). O DN similar ao caminho completo que identifica unicamente um

arquivo num sistema de arquivos.
Cabe ao servidor de segurana oferecer servios transientes do MACA
como autenticao, autorizao e controle de acesso s aplicaes clientes,
dentre outros servios de segurana. Ele integra o servio de segurana do
CORBA (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 especifica um servio padro de deciso de acesso a recursos capaz de suportar
diferentes polticas de acesso. O servio do MACA implementa o modelo
de autorizao contextual para o controle de acesso baseado em papis que
decide o acesso aos recursos com base na poltica armazenada na BIGS e
nos contextos disponveis no momento do acesso.
A integrao entre o MACA e o SSC requer implementaes das interfaces
PrincipalAuthenticator e Credentials. PrincipalAuthenticator
realiza a autenticao (por meio do mtodo authenticate), verificando a
validade da identidade usurio no servidor LDAP. Caso seja bem sucedida,
a autenticao resulta na criao de uma instncia de Credentials, que
permite solicitar ao MACA a execuo de tarefas relacionadas a sesso do
usurio, como por exemplo, obter os papis de um usurio.
Com o usurio autenticado (e com sua credencial criada) o controle de
acesso imposto pelo ORB (Object Request Broker) s chamadas de operaes das interfaces dos objetos CORBA servidores (vide figura refmodelo).
Assim, o ORB atua como um monitor de referncia que impe, obrigatoriamente, o controle de acesso. Ele utiliza uma implementao da interface
AccessDecision do SSC para obter, do MACA, os privilgios de acesso
conferidos 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 do

objeto
AccessDecision do RAD Facility padroniza o modo como as aplicaes
clientes (objeto alvo) solicitam autorizaes para um usurio acessar um
recurso. As interaes entre o cliente, o objeto CORBA servidor e o servio
de deciso do RAD Facility d-se da seguinte maneira:
1. Um cliente solicita que o objeto servidor (objeto alvo) a execuo de
uma operao.
2. Durante a execuo da operao, o objeto servidor solicita ao objeto
AccessDecision uma autorizao para executar a operao. Podem
haver parmetros, que sero utilizados para decidir o acesso.
3. O objeto AccessDecision retorna um valor booleano indicando se a
autorizao foi concedida ou proibida.
4. Com base no retorno de AccessDecision, o objeto servidor responde
aplicao cliente, completando a execuo da operao solicitada, se
o acesso foi autorizado, ou ento, interrompendo a execuo e sinalizando para o cliente que o acesso foi proibido.

4.5

O algoritmo de deciso de acesso do MACA

O algoritmo de deciso de acesso do MACA recebe os seguintes parmetros

de 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 ser
permitido ou proibido. Os passos a seguir so executados durante o algoritmo:
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, associada a algum papel ativo ou ativvel do usurio que proba a execuo 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 de

alguma autorizao vlida, forte, associada a algum papel ativo ou
ativvel do usurio que permita executar a operao opr no objeto
obj. Caso exista, o acesso concedido (retorna verdadeiro), o eventual
papel inativo ativado na sesso session_ref e o algoritmo pra.
4. Caso o algoritmo no tenha parado, ento verifica-se a existncia de
alguma autorizao vlida, fraca, associada a algum papel ativo ou
para ativao do usurio que permita executar a operao opr no
objeto obj. Caso exista o acesso concedido (retorna verdadeiro), o
eventual papel inativo ativado na sesso session_ref e o algoritmo pra.
5. Caso o algoritmo no tenha parado, ento o acesso negado (retorna
falso) e o algoritmo pra.
Note-se, pela execuo dos passos algoritmo, que as autorizaes fortes e
negativas prevalecem sobre as demais autorizaes, inclusive as eventuais
autorizaes equivalentes, fortes e positivas. Por sua vez, autorizaes fortes prevalecem sobre as autorizaes fracas equivalentes e as autorizaes
fracas positivas prevalecem sobre as autorizaes fracas negativas equivalentes.

40

Captulo 5
Modelo de acesso
implementado como prova de
conceito
Esse captulo apresenta uma implementao de controle de acesso baseado
em papis para processos judiciais virtuais, restrita a uma rea especfica
do domnio de aplicao jurdica. O objetivo desta implementao servir
de prova de conceito da racionalidade da soluo em middleware proposta
por sua arquitetura, tendo como foco imediato sua evoluo para um prottipo piloto nesta rea. A soluo em middleware aqui proposta visa a
racionalidade em dois sentidos.
No primeiro sentido, abstrato, busca-se explorar o potencial do modelo
RBAC para alcanar maior eficincia na gerncia de polticas de segurana
demandadas, de um lado, por regulamentao complexa das regras de negcio (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-izao

T)
No segundo sentido, concreto, busca-se explorar o potencial do modelo
de desenvolvimento colaborativo, sob regime de licenciamento livre, para
alcanar maior eficincia no atendimento demanda instrumental de mecanismos de segurana prprios para integrao e/ou informatizao de sistemas processuais na esfera judiciria, atualmente reprimida, alavancando
e provendo assim a autonomia do usurio, em relao a fornecedores de
componentes, para controlar sua prpria poltica de segurana, autonomia
esta que a prpria essncia desta segurana.
Da a adaptao do projeto MACA, software sob licena GPL originalmente desenvolvido para controle de acesso a sistemas de pronturios mdicos, para atender aos requisitos de segurana especficos do domnio de
aplicao em tela.
A seo 5.1 apresenta o modelo de acesso proposto. A seo 5.2 apresenta aspectos de implementao.

41

5.1

O modelo de acesso proposto

A soluo apresentada cobre os processos judiciais autuveis em Juizados

Especiais 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 (Poder Judicirio) que servem para resolver as pequenas causas com rapidez,
de forma simples, sem despesas e sempre buscando um acordo entre as
partes. O artigo 3 da Lei 9099 exposto a seguir esclarece qual a
competncia dos Juizados Especiais Cveis.
"Art. 3 O Juizado Especial Cvel tem competncia para conciliao, processo e julgamento das causas cveis de menor complexidade, assim consideradas:
I - as causas cujo valor no exceda a quarenta vezes o salrio
mnimo;
II - as enumeradas no art. 275, inciso II, do Cdigo de Processo
Civil;
III - a ao de despejo para uso prprio;
IV - as aes possessrias sobre bens imveis de valor no excedente ao fixado no inciso I deste artigo.
(...)"
A escolha pelo Juizado Especial Cvel se justifica pela simplicidade e
pela facilidade de aplicao de um procedimento virtual para seus atos processuais. Os Juizados Especiais tm dentre seus princpios processuais a
informalidade e a celeridade, buscando obter a rpida soluo de conflitos utilizando menos recursos processuais, e com execuo efetiva e clere.
Desta forma, a virtualizao do processo objetivo desejvel nos Juizados
Especiais, pois, alm de diminuir gastos (como por exemplo, na tramitao de papelada) permite a automatizao de boa parte do caminhamento
do processo, repassando ao sistema computadorizado a execuo de certas
tarefas e a implementao do fluxo processual, o que pode resultar na acelerao de sua execuo.
Para implementar o processo jurdico virtual autuvel em Juizados Especiais Cveis, visando esta prova de conceito, foi adotado um fluxo simplificado de caminhamento do processo. Este fluxo apresentado na figura 5.1.
O fluxo, de maneira geral, mostra as etapas pelas quais um processo
caminha, 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 a
petio inicial; o Conciliador o responsvel por dirigir a Audincia de Conciliao; o Juiz quem profere a sentena, etc.
A modelagem desenvolvida baseia-se no modelo de controle de acesso
baseado em papis (RBAC). Como j foi sinalizado na introduo deste captulo, 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 predicada
por conjuntos de prerrogativas processuais e normativas, cujo carter dinmico atinge no s a vida til do sistema processual, mas muitas vezes
tambm o prprio processo.
Para aplicao do modelo de acesso proposto, foram definidos servios
forenses que podem ser acessados pelas pessoas que lidam com os processos, no desempenho de suas funes (papis, no RBAC). Estes servios so
descritos a seguir.
Servio de Cadastro: permite cadastrar: um processo, quando da autuao de uma petio inicial;cadastrar partes do processo; editar dados de partes do processo; remover partes do processo.
Servio de Pesquisa: permite a pesquisa por processos (segundo os
filtros nmero do processo, nome de partes ou advogados), a pesquisa
por partes e a pesquisa por advogados.
Servio de Movimentao Processual: permite movimentar um pro43

cesso, segundo o fluxo de processo apresentadoOu seja, desde a autuao da petio inicial at a baixa/arquivamento do processo.
Servio de Acompanhamento e Auditoria: permite acompanhar o processo em suas diversas fases e visualizar as aes realizadas no processo (e quem as realizou).
O acesso a esses servios deve atender a poltica de acesso definida atravs de regras. Essa poltica procura respeitar os requisitos do Juizado Especial Cvel, e espelhar, na medida do possvel, as funes existentes em um
Juizado e suas normas processuais. Ela apresentada, em linhas gerais, a
seguir.
Somente usurios devidamente autenticados (com o uso de certificados digitais) podem acessar o sistema.
Conforme o controle de acesso baseado em papis, cada usurio deve
estar associado a um papel, para poder executar um servio forense
permitido quele papel. A figura 5.2 apresenta a hierarquia de papis
que foi utilizada no modelo proposto, onde procurou-se representar os
cargos existentes em uma vara desse tipo de Juizado.
Nessa hierarquia, houve a tentativa de, na medida do possvel, levar-se
em conta as relaes de responsabilidade e autoridade existentes quer nos
costumes ou nas normas processuais. Com o objetivo de formar uma hierarquia inicial simples, mas passvel de evoluo, optou-se apenas por retratar
os cargos que lidam diretamente com a movimentao do processo. Houve,
ainda, a preocupao de definio de papis genricos, como os papis Usurio, Analista Judicirio e Tcnico Judicirio, que possuem autorizaes que
so herdadas pelos papis mais especializados.
Os atos praticados so pblicos, o que implica que todos os usurios
legtimos do sistema podem ver os movimentos realizados e podem
pesquisar por processos.
Somente usurios com papis que participam em um processo (parte
ou advogado) e determinados funcionrios do Juizado podem ver os
documentos que so peas de um processo.
Os advogados s podem adicionar documentos, interpor recursos, etc.
em processos nos quais representam partes. Alm disso, dentro dos
prazos processuais em que cabe parte representada manifestar-se
nos autos.
Os juzes podem estabelecer e estender prazos, como por exemplo: prazos para a Audincia de Conciliao e prazos para interposio de recursos.
Somente juzes podem determinar a baixa de um processo, desde que
no obstado por norma processual impeditiva.
44

Figura 5.2: Hierarquia de papis considerada na implementao do modelo

de acesso aos processos
A figura 5.3 ilustra a poltica de acesso definida. So mostrados os recursos 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 autorizaes
contextuais associadas a cada papel.

46

5.2

Aspectos de implementao

Esta seo trata de aspectos de implementao do prottipo desenvolvido.

O prottipo foi implementado na plataforma Java 2 SE, verso 5. Aqui
sero discutidos aspectos relativos a autenticao e aspectos relativos a autorizaes.
O MACA, na verso utilizada (3.2.2c), s fornece suporte para autenticao baseada em senha e nome de usurio. Para adequar a forma de autenticao quela que ser demandada em implementaes piloto que busquem
testar e eventualmente atender demandas de imformatizao e/ou integrao com servios existente, sob o regime normativo de uma infra-estrutura
de chaves pblicas, optou-se por estend-lo para permitir a autenticao
via certificados digitais e chaves privadas correspondentes.
Alm de buscar cobrir o potencial de demanda deste importante momento da Justia Brasileira, a utilizao de certificados para autenticao,
nesse tipo de arquitetura, abre a possibilidade para utilizao de campos
especficos (extenses X.509) na alocao de papis, na deciso de se permitir ou se negar acesso de um usurio autenticado a um determinado servio
(Seo 6.3). Ademais, implementaes-piloto de prottipos desta arquitetura podem tambm servir de base para prova de conceito ou para homologao de normas em considrao por uma ICP qual esteja subordinada
o Juizado correspondente. Desta forma, fez-se necessria a modificao no
cdigo do MACA para satisfazer essa necessidade de projeto.
Assim, foi-lhe acrescentada mais uma forma de autenticao, chamada
X509_CERTIFICATE.
Quando X509_CERTIFICATE repassado ao MACA, durante a execuo do protocolo de autenticao por uma aplicao-cliente, isso indica que
a autenticao ser realizada via certificado digital . No prottipo implementado, assume-se que o certificado, (e a respectiva chave privada) esto
armazenados em um keystore.
Para a criao do keystore, a ser utlizado nos testes do prottipo implementado, foi utilizada a ferramenta keytool do Java, que um gerenciador de keystores de chaves privadas e certificados, incluindo bibliotecas de
gerao de chaves.

5.2.1

Gerao de chaves

A seguir, apresentada o cdigo para a criao de um certificado com essa

ferramenta.
keytool -genkey -alias usuario -keyalg RSA -keystore
user_keystore
Enter keystore password:

password

What is your first and last name?

[Unknown]:

Usuario

What is the name of your organizational unit?

47

[Unknown]:

Seo XYZ

What is the name of your organization?

[Unknown]:

Tribunal de Pequenas Causas

What is the name of your City or Locality?

[Unknown]:

Braslia

What is the name of your State or Province?

[Unknown]:

DF

What is the two-letter country code for this unit?

[Unknown]:

BR

Is CN=Usuario, OU=Seo XYZ, O=Tribunal de Pequenas

Causas,
L=Braslia, ST=DF, C=BR correct?
[no]:

yes

Enter key password for <usuario>

(RETURN if same as keystore password):

<CR>

Isso cria um certificado auto-assinado com as correspondentes chaves

pblicas e privadas e os armazena no keystore user_keystore.

5.2.2

Autenticao bidirecional usurio-servidor MACA

O prottipo, durante a autenticao, pede que o usurio informe o seu keystore (veja figura 5.4).

Figura 5.4: Tela de Autenticao

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

48

Figura 5.5: Utilizao do keystore para realizar a autenticao

De posse do caminho do arquivo que representa o keystore (varivel
ksPath), 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 representa o certificado , ento, convertido para um stream de bytes; essa
converso necessria, pois, o mtodo de autenticao authenticate da
classe PrincipalAuthenticator especifica, em sua assinatura, que o valor utilizado para a autenticao seja passado como um vetor de bytes (veja
o terceiro argumento da chamada pa.authenticate()).
Aps a chamada authenticate(), deve-se verificar o retorno do mesmo.
Os retornos verificados so AuthenticationStatus._SecAuthSuccess
e AuthenticationStatus._SecAuthFailure. O primeiro valor indica
que a autenticao foi realizada com sucesso, enquanto o segundo indica a
falha na autenticao. A figura 5.6 apresenta essa verificao.
Se a autenticao falhar, lanada uma exceo indicando a falha. Se
o MACA retornar que a autenticao foi realizada com sucesso, realizado um segundo passo de autenticao, atravs da chamada ao mtodo
performTwoWaySSL(). Essa chamada estabelece uma espcie de desafio, para provar que o certificado foi apresentado por quem se encontra de
posse da chave privada correspondente (ou seja, como sempre, o protocolo
presume que a chave privada associada ao certificado de controle exclusivo do seu titular). Esse desafio realizado por meio do estabelecimento de
uma conexo SSL (Secure Socket Layer) bidirecional, isto , onde as duas
partes se autenticam entre si; assim, alm da forma comumente utilizada
na autenticao SSL, onde o servidor (neste caso o MACA) apresenta o seu
certificado, exige-se que o cliente tambm apresente um certificado, como
forma de se identificar perante o servidor, alm da usual autenticao do
49

Figura 5.6: Verificao do retorno do mtodo authenticate()

servidor perante o cliente.
O certificado utilizado neste passo pelo usurio o mesmo que foi apresentado anteriormente na chamada authenticate de
PrincipalAuthenticator. Para implementao da comunicao SSL,
foi utilizada a API JSSE Java Secure Socket Extension (http://java.
sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html).
A figura 5.7 ilustra o lado do cliente nesse desafio.
Se nenhuma exceo for lanada durante a execuo do cdigo acima,
ento a autenticao (bidirecional) foi completada com sucesso.
Do lado do MACA, conforme j dito, foi criado mais um flag de autenticao (X509_CERTIFICATE), para poder realizar a autenticao via certificados digitais. Foram, ento, realizadas modificaes nas seguintes classes
do MACA:
PrincipalAuthenticator : classe responsvel por realizar a autenticao; foi nessa classe que acrescentou o cdigo de autenticao
via certificados digitais.
User : essa classe mantm os dados de um usurio autenticado no
MACA; nela que se realiza o BIND junto ao OpenLDAP; ela foi modificada para que se utilizasse o mecanismo SASL-EXTERNAL de autenticao junto ao LDAP; o mtodo SASL-EXTERNAL, dentre outros
50

Figura 5.7: Implementao do desafio do protocolo SSL no cliente

mecanismos e funcionalidades, permite que seja utilizada a autenticao via certificado digital entre um servidor e um cliente LDAP.
Alm disso, foi adicionada a classe SSLSimpleServer, que permite a
realizao do desafio da segunda etapa da autenticao, conforme j explicado anteriormente.
A figura 5.8 apresenta o trecho de cdigo que foi acrescentado classe
PrincipalAuthenticator do MACA, onde recebido o certificado para
realizao da autenticao.

Figura 5.8: Modificaes na classe PrincipalAuthenticator

Primeiramente, obtm-se o certificado; como o certificado recebido como
um vetor de bytes (conforme j explicado anteriormente), devemos ler es isso feito nas quatro primeiras linhas
ses bytes para obter o certificado U
mostradas. A seguir, foi seguido a mesma lgica que o MACA impe quando
da autenticao via nome de usurio senha:
51

1. verifica se o usurio j possui sesses abertas;

2. se tiver, o usurio obtido (via _userHolder.getUser());
3. caso contrrio, chamado o mtodo createUser(), que criar um
novo usurio.

5.2.3

Autenticao bidirecional MACA - LDAP

A figura 5.9 mostra o cdigo da classe User que foi modificado; este trecho
realiza o BIND no OpenLDAP, faz a pesquisa pelo usurio com base no Distinguished Name (DN) do certificado e, se possvel (e necessrio) for, cria
um usurio.

Figura 5.9: Modificaes na classe User

Observe como realizada uma autenticao mtua (bidirecional) entre o servidor OpenLDAP e o MACA as cinco primeiras linhas mostram
o acesso ao certificado do OpenLDAP e ao certificado do MACA; essa autenticao realizada via SASL-EXTERNAL via TLS (ambos gerenciam
52

internamente seus prprios keystores, com suas chaves privadas correspondentes). Os comandos
StartTlsResponse tls = (StartTlsResponse)
ldapCtx.extendedOperation(new StartTlsRequest());
tls.negotiate();
so os responsveis por negociar a sesso TLS/SSL para a realizao da
autenticao. O comando
ldapCtx.addToEnviroment(Context.SECURITY_AUTHENTICATION,
EXTERNAL);
define que o mtodo de autenticao a ser utilizado o EXTERNAL. A
seguir, por meio da instruo
String subjectDN =
certificate.getSubjectX500Principal().getName();,
obtido o Distinguished Name (DN) do titular do certificado do usurio
que se autenticou no MACA, e que precisa assumir papis para sua sesso
no sistema de aplicaes; esse DN ser utilizado como filtro de pesquisa
junto ao OpenLDAP.
Se houver resultados na pesquisa realizada, existe uma entrada de usurio correspondente quele certificado de usurio apresentado; caso contrrio, lanada uma exceo do tipo NamingException, indicando que no
h usurio correspondente para aquele certificado.
Para que a autenticao mtua entre o OpenLDAP e o MACA funcionasse, foi necessria a adio de algumas diretivas no arquivo de configurao do OpenLDAP slapd.conf. Essas diretivas so:
TLSCACertificateFile /etc/openldap/certificados/trust.pem
TLSCertificateFile /etc/openldap/certificados/ldap.cert
TLSCertificateKeyFile /etc/openldap/certificados/privkey.pem
TLSVerifyClient try
A primeira diretiva especifica o caminho do arquivo que contm os certificados confiveis do OpenLDAP. A segunda especifica o caminho do certificado o OpenLDAP. A terceira o caminho do arquivo com a chave privada
do OpenLDAP (keystore). A ltima diretiva especifica se h a necessidade
ou no de requisitar o certificado do cliente (com o valor try, especificamente, o OpenLDAP requisita um certificado, mas se nenhum for apresentado a sesso prossegue normalmente; no entanto, se o certificado apresentado for invlido, a sesso imediatamente terminada). Vale ressaltar que,
por conter valores sensveis como o caminho do arquivo da chave privada,
altamente recomendvel que a mquina que hospeda o servidor OpenLDAP
esteja fisicamente protegida.
53

Aps a realizao desses passos, conforme explicado anteriormente,

realizada uma espcie de desafio. Nos passos apresentados at agora, foi
realizada a autenticao do MACA junto ao OpenLDAP e a pesquisa do DN
do usurio na base LDAP.
Esse desafio um segundo passo da autenticao, em que h a autenticao mtua entre o usurio que deseja acessar o sistema de aplicaes e
o servidor de controle de acesso o MACA. Para a realizao desse passo,
foi acrescentada, ao cdigo do MACA, a classe SSLSimpleServer, cujas
partes principais so mostradas na figura 5.10.

Figura 5.10: Modificaes no cdigo do MACA para autenticao

A implementao foi realizada utilizando-se a API JSSE. Nesse trecho,
definido qual o keystore com os certificados confiveis (duas primeiras
linhas), o certificado que o MACA ir apresentar durante a autenticao, a
criao do contexto SSL e do socket SSL.
Vale atentar para a seguinte chamada:
serverSocket.setNeedClientAuth(true).
Esta a chamada que define que a autenticao ser bidirecional, pois,
obrigando que o cliente apresente o seu certificado. Se o certificado apresentado no for validado por uma cadeia ancorada em um certificado confivel
ao LDAP, ser lanada uma exceo indicando o erro. Nesse caso, o desafio
ir falhar.

5.3

Autorizaes

Aps a realizao com sucesso da autenticao, o usurio est apto para

acessar o sistema de aplicaes. A partir desse momento, entra em ao o
mecanismo de controle de acesso baseado em papis; toda e qualquer tentativa de acesso ao sistema intermediada pelo MACA. Ao tentar realizar
uma operao, como por exemplo a pesquisa por um processo, o sistema,
54

primeiramente, verifica se o usurio pode realizar aquela ao. Isto , se

nesse momento da sesso ele desempenha algum papel que lhe autoriza a
executar tal ao. Para isso, so levados em conta o papel (ou papis) que o
usurio est desempenhando no momento, o recurso que ele deseja acessar
e o tipo de acesso desejado (escrita, leitura, execuo, etc). A figura 5.11
apresenta um exemplo tpico de acesso no sistema, onde o usurio tenta
acessar o servio de pesquisa de processos.

Figura 5.11: Exemplo de acesso no sistema

Antes de acessar o servio, necessria a verificao de acesso, para
decidir se o acesso deve ou no ser liberado; isso feito no teste da primeira
linha do cdigo mostrado, na qual chamado o mtodo autorizaAcesso()
da controladora de autorizao. Esse mtodo retorna um valor booleano que
indica a liberao ou a proibio do acesso; como parmetros so passados
ea
o recurso a ser acessado neste caso, SServio

de Pesquisa;jurisrbac T
forma de acesso execuo.
A figura 5.12 mostra o mtodo autorizaAcesso().

Figura 5.12: Cdigo do mtodo autorizaAcesso()

Para requisitar o acesso, utiliza-se um objeto AccessDecision; a seguir, recupera-se o papel atual do usurio por meio de get_attributes()
55

de Credentials. Por fim, a linha

acesso_autorizado = ado.access_allowed(resName, operacao,
attrs)
verifica se o acesso ao recurso permitido. So passados o recurso a
ser acessado resName , a operao nesse caso execuo e os atributos do usurio, dentre os quais se encontra o seu papel. Essa operao
retorna um booleano que indica a permisso ou proibio do acesso e que
retornado para o chamador de autorizaAcesso().
A figura 5.13 ilustra, de maneira geral, como realizado uma operao
dentro do sistema.

Figura 5.13: Diagrama de seqncia com as interaes entre os objetos

durante a requisio de acesso a um determinado recurso
Um cliente solicita a realizao de uma operao sobre um determinado
recurso. Para que a operao seja realizada, deve ser chamada a operao autorizaAcesso() da controladora de autorizao, que decidir se o
acesso ser permitido ou proibido.
A controladora de autorizao acessa o objeto Credentials que representa a sesso corrente do usurio para obter os atributos
get_attributes() do usurio (o principal atributo a ser considerado
para a deciso de acesso o papel do usurio).
De posse dos atributos, a controladora de autorizao chama a operao access_allowed() do objeto AccessDecision (implementado pelo
MACA) para decidir pela liberao de acesso; nesta chamada so passados
o nome do recurso a ser acessado, a operao que o cliente deseja realizar e
os atributos do usurio.
O retorno de access_allowed() , ento, repassado para o cliente,
permitindo ou negando o acesso ao recurso. Quando o cliente deseja sair
do programa, ele acessa o mtodo finalizaSessao() da controladora de
autorizao; essa, por sua vez, realiza uma chamada ao mtodo destroy()
de Credentials que, efetivamente, finalizar a sesso corrente.

56

Captulo 6
Desdobramentos
Aqui so apresentadas uma viso geral da aplicao desenvolvida e sugesto de trabalhos futuros.

6.1

JuRisBAC

Para testar o modelo sugerido, foi desenvolvida uma aplicao piloto JuRisBAC em cdigo aberto que permite a movimentao processual segundo o fluxo de caminhamento adotado (figura 5.1). A aplicao foi desenvolvida utilizando a linguagem de programao Java, verso 1.5. Foram
utilizadas, ainda, a biblioteca cliente do MACA ( http://maca.sourceforge.
net/) para a implementao do controle de acesso e a API Log4j ( http:
//logging.apache.org/log4j/docs/) para a gerao de logs de auditoria e para o acompanhamento das fases do processo judicirio. A aplicao foi desenvolvida segundo os termos da Licena Pblica Geral Gnu
(GPL).
A aplicao permite, basicamente, acompanhar todo o rito processual,
desde a entrada de petio inicial (autuao) at o arquivamento do processo (conforme o fluxo da figura 5.1 ). Permite a entrada de documentos
(petio/citao), a movimentao processual, a pesquisa por processos, o
agendamento de audincias, a visualizao de documentos, a criao de
logs de auditoria e o acompanhamento dos atos processuais.
A seguir, encontram-se algumas telas da aplicao desenvolvida.

6.2

Documentaes

Esta seo traz as referncias para a documentao, binrios e cdigos desenvolvidos em nossa aplicao.
Os fontes e os binrios do JuRisBAC encontram-se em http://jurisrbac.
codigolivre.org.br.
Os fontes e os binrios do MACA_CS, com as modificaes que realizamos (introduo da autenticao via certificado digital), encontram-se
http://jurisrbac.codigolivre.org.br/. No momento, o projeto de
57

Figura 6.1: Tela Principal da Aplicao

Figura 6.2: Tela de Cadastro de Processo

58

Figura 6.3: Tela de Cadastro de Parte

Figura 6.4: Tela de Pesquisa de Processo

59

Figura 6.5: Tela de Movimentao de Processo

60

Figura 6.6: Tela proibindo acesso ao mdulo de movimentao de processo

modificao do MACA_CS um fork do projeto original do MACA, considerado a verso 3.2.2cx do MACA_CS, necessrio para o funcionamento do
JuRisBAC. Ambos projetos so gerenciados pelos autores deste trabalho.
A verso digital desse documento tambm se encontram em http://
jurisrbac.codigolivre.org.br/.
Todos esses arquivos esto disponveis na seo Downloads do site.

6.3

Trabalhos futuros

Na pesquisa realizada com este prottipo, surgem inmeras possibilidades

para trabalhos futuros que podero ampliar as funcionalidades da arquitetura proposta, aumentar sua robustez e melhor validar os objetivos deste
projeto.
Uma primeira necessidade seria no mbito da Engenharia de Software,
buscando uma forma para que a aplicao desenvolvida sobre a camada de
controle de acesso se configure dinamicamente, evitando problemas posteriores de inconsistncia entre regras existentes no servidor de controle de
acesso e na aplicao. Uma proposta seria fazer com que o servidor de controle de acesso gerasse e atualizasse periodicamente por exemplo, sempre que inicializado ou alterado um arquivo de configuraes. Este seria
lido pela aplicao, que permitiria ao usurio autenticado acessar dinamicamente apenas aos recursos que os papis assumidos naquela sesso no
sistema lhe dariam acesso. Por exemplo, criando menus e botes em tempo
de execuo a partir das informaes obtidas do arquivo de configuraes
e das credenciais apresentadas pelo servidor de autenticao, para aquela
61

sesso daquele usurio. Essa soluo evitaria problemas de inconsistncia

entre a aplicao o e servidor de autenticao, evitando gargalos durante
a implementao e manuteno de aplicaes, bem como na gerncia de
polticas de segurana do sistema.
Ainda com relao Engenharia de Software, considerando o modelo de
desenvolvimento colaborativo para softwares abertos com licenas livres,
seria necessrio desenvolver uma metodologia para testes da aplicao,
criar um padro de codificao e documentar as interfaces de programao
existentes.
Levando-se em conta os aspectos de segurana do sistema, seria preciso ainda pesquisar a melhor forma de proteger o banco de dados, tanto de
acessos remotos como de acessos fsicos. No nos aprofundamos sobre o assunto neste prottipo pois o foco era a modelagem do controle de acesso na
aplicao, usando criptografia forte (2-way SSL entre os servidores de aplicao, de controle de acesso e de diretrios LDAP). Como primeiro passo,
propomos uma arquitetura onde a aplicao residiria em um servidor de
aplicaes, sendo possvel o acesso remoto ao banco de dados somente por
meio desse servidor, atravs de uma VPN, protegido contra vazamento e
interceptao. Os clientes teriam acesso aos dados pela aplicao, que seria
controlada pelo servidor de controle de acesso, no podendo acessar diretamente o banco de dados.
Alm disso, seria interessante, ou talvez necessria, conforme a escala
e/ou requisitos de segurana da aplicao, explorar as possibilidades de haver um mapeamento entre as permisses existentes no SGBD e as permisses criadas no servidor de controle de acesso, integrando a gerncia do
banco de dados da poltica integrada de segurana para aquela implementao. Qual a forma mais elegante e segura de faz-lo, dependeria do
legado da arquitetura e da cultura gerencial do banco de dados a ser integrado. No obstante, e talvez mais importante, essa abordagem oferece
uma oportunidade para se considerar, de forma racional, a migrao de
banco de dados legado para, por exemplo, um regime de licenciamento condizente com a autonomia proporcionada pela soluo de gerncia de poltica
de segurana atravs de middleware livre, aqui proposta.
Por fim, um trabalho futuro importante, no contexto atual da informatizao do Judicirio em curso no Brasil, seria a utilizao de campos no
certificado apresentado pelo usurio no momento da autenticao para a
filtragem dos papis e permisses provenientes do servidor de controle de
acesso. Durante a autenticao, a aplicao verificaria a existncia de campos definidos pela autoridade certificadora que permitiria ou bloquearia a
ativao de papis vindos da camada de controle de acesso. Um exemplo
seria, no caso de um usurio ser um advogado, o seu certificado conter o
nmero de registro na OAB. No momento da autenticao, seria verificada
a existncia deste campo no certificado e, caso o servidor de controle de
acesso contivesse uma ligao entre este usurio e o papel Juiz, a aplicao bloquearia a ativao deste papel. Ou vice-versa. A arquitetura aqui
proposta possibilita esta funcionalidade, que seria de grande valia. Capaz,
ao mesmo tempo, de diminuir sensivelmente o impacto dos riscos gmeos,
62

num prestador jurisdicional informatizado, da excessiva responsabilidade

na gerncia da poltica de segurana e do abuso de poder concentrado na
funo administrativa de permisses e papis, enquanto instrumenta tecnicamente esses prestadores para participarem ativamente na evoluo da
ICP a que esto subordinados, oferecendo-lhes uma plataforma adequada
para implementarem, proporem, testarem e homologarem propostas normativas que incluem o contedo de certificados digitais ao negcio da prestao jurisdicional.

63

Captulo 7
Concluso
O presente trabalho preocupou-se em modelar o controle de acesso a um
sistema de processos judiciais representados em meios digitais, baseado no
rito processual do Juizado Especial Cvel, utilizando o modelo RBAC. A adoo deste modelo em sistemas de grande porte procura facilitar e agilizar
a administrao de permisses de acesso a recursos, bem como a gerncia
de polticas de segurana do mesmo. Isto possvel atravs da racionalizao das atribuies de permisses conjugado ao mapeamento direto dos
papis reais da organizao, com suas polticas de acesso e de segurana
correspondentes, para papis da camada de controle de acesso, facilitando
seu entendimento e sua gesto.
Como a autenticao tem papel primordial na aplicao do controle de
acesso, houve a iniciativa de prover um mecanismo de autenticao com
criptografia forte. A escolha recaiu sobre a autenticao via certificados digitais, por esta prova de conceito inserir-se no contexto de uma iniciativa,
de mbito nacional , para institucionalizar e popularizar o uso de uma Infraestrutura de Chaves Pblicas a ICP-Brasil. Esta seria responsvel
por fazer a ligao entre identidades de usurios com seus pares de chave,
pblica e privada, proporcionando assim a autenticao eletrnica em sistemas governamentais, bem como a assinatura digital em documentos oficiais. Ainda, o emprego deste modelo proporcionaria o mapeamento direto de
regras no regime da ICP, relativas a prerrogativas neste domnio de aplicao, para regras de acesso a sistemas processuais por ele controlado. Como
conseqncia, o uso de meios eletrnicos para a produo, armazenamento
e disponibilizao de documentos pblicos, incluindo-se processos judiciais,
poderia ser adotado amplamente, de forma eficiente e gil em consonncia
com a evoluo da ICP-Brasil.
Com esses objetivos, foi utilizado o MACA para a modelagem do controle de acesso RBAC. Como a verso atual desse middleware no possui
um mecanismo de autenticao via certificados, e como o seu regime de licenciamento livre, foi realizado uma modificao em sua estrutura a fim
de possibilitar a autenticao bidirecional via criptografia assimtrica entre
aplicaes clientes e o MACA, e entre o MACA e o servidor LDAP (BIGS).
Uniu-se, assim, as facilidades advindas da utilizao do modelo RBAC com
a robustez da autenticao de usurios perante o sistema via respectivos
64

certificados digitais.
Este trabalho de modificao de cdigo j desenvolvido validou a versatilidade e utilidade do desenvolvimento colaborativo, possibilitado no regime
de desenvolvimento de softwares de cdigo aberto e com licenciamento livre,
a exemplo do MACA. Este regime permite a adoo de mecanismos de segurana prprios, aumentando a autonomia de seus usurios em relao a
fornecedores de componentes, qualidade essencial no mbito da segurana.
Verifica-se igualmente a tendncia para que o MACA incorpore uma ampla gama de funcionalidades de segurana e para adoo e uso em diversos
domnios de aplicao, com diferentes perfis de necessidades relativas a
funes de segurana.
Finalmente, houve a implementao de um prottipo que contemplasse
essas realidades, como prova de conceito e ponto de partida para novas
pesquisas, que teriam como objetivo alcanar uma arquitetura robusta no
domnio da segurana, j demonstrada no seu uso pelo Incor. No caso do
domnio de aplicao para o qual foi implementada a prova de conceito,
que foi objeto desse trabalho, no domnio da informatizao do judicirio.
Procuramos dar os primeiros passos para que, no futuro, esta arquitetura
possa ser adotada no processo de informatizao do Poder Judicirio no
Brasil.

65

Referncias Bibliogrficas
Bell, D. E. and LaPadula, L. (1973). Secure Computer Systems: Mathematical Foundations and Model. The Mitre Corporation, Bedford, MA.
Clark, D. D. and Wilson, D. R. (1987). A comparison of commercial and
military computer security policies. In IEEE Symposium on Computer
Security and Privacy.
Ferraiolo, D. and Kuhn, D. R. (1992). Role-based access control. In Proceedings of the NIST-NSA National (USA) Computer Security Conference.
Ferraiolo, D., Sandhu, R., Gavrila, S., Kuhn, D., and Chandramouli, R.
(2001). A proposed standard for role based access control. ACM Transactions on Information and System Security, 4(3).
Ferraiolo, D. F., Kuhn, D. R., and Chandramouli, R. (2003). Role-Based
Access Control. Artech House, Norwood, MA.
Motta, G. H. M. B. (2003). Um modelo de autorizao contextual para o controle de acesso ao pronturio eletrnico do paciente em ambientes abertos
e distribudos. Programa de Ps-graduao em Engenharia Eltrica.
Schneier, B. (1996). Applied Criptography. John Willey & Sons, Hoboken,
NJ.

66