Professional Documents
Culture Documents
Orientador
Prof. Pedro A. D. Rezende
Braslia
2006
Universidade de Braslia
Instituto de Cincias Exatas
Departamento de Cincia da Computao
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.
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
23
23
25
25
27
27
28
28
29
31
32
32
33
33
34
35
36
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
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
12
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
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
2.1.4
Monitor de referncia
2.2
2.2.1
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
2.2.2
Modelo Clark-Wilson
2.3
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
2.4
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
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
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
26
3.1.3
Ativao de papis
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 :
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 :
sujeito, t :
importante notar que est ltima regra condicional permite que outras restries possam ser colocadas na execuo de transaes.
3.3
3.3.1
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
3.3.2
O ncleo do RBAC
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
3.3.4
3.3.5
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
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
34
4.3
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
4.5
39
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
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
45
46
5.2
Aspectos de implementao
5.2.1
Gerao de chaves
password
Usuario
[Unknown]:
Seo XYZ
Braslia
DF
BR
yes
<CR>
5.2.2
O prottipo, durante a autenticao, pede que o usurio informe o seu keystore (veja figura 5.4).
48
5.2.3
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.
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
5.3
Autorizaes
de Pesquisa;jurisrbac T
forma de acesso execuo.
A figura 5.12 mostra o mtodo autorizaAcesso().
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
58
59
60
6.3
Trabalhos futuros
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