Willian Ferreira Peixoto

CENTRO ESTADUAL DE EDUCAO TECNOLGICA PAULA SOUZA
MESTRADO EM TECNOLOGIA
WILLIAN FERREIRA PEIXOTO
UMA PROPOSTA PARA

CONTROLE DE ACESSO BASEADO EM PAPIS
NA ARQUITETURA DO AGENTE
COM A PROGRAMAO ORIENTADA A ASPECTOS
SO PAULO
NOVEMBRO 2009
WILLIAN FERREIRA PEIXOTO
UMA PROPOSTA PARA

CONTROLE DE ACESSO BASEADO EM PAPIS
NA ARQUITETURA DO AGENTE
COM A PROGRAMAO ORIENTADA A ASPECTOS
Dissertao apresentada como exigncia parcial para

obteno do Ttulo de Mestre em Tecnologia no Centro
Estadual de Educao Tecnolgica Paula Souza, no
Programa de Mestrado em Tecnologia: Gesto
Desenvolvimento e Formao, sob orientao da Prof.
Dr. Mrcia Ito.
SO PAULO
NOVEMBRO 2009
Peixoto, Willian Ferreira
P379u Uma proposta para controle de acesso baseado em
papis na arquitetura do agente com a programao
orientada a aspectos. So Paulo : CEETEPS, 2009.
115 f.
Dissertao (Mestrado) - Centro Estadual de

Educao Tecnolgica Paula Souza, 2009.
1. Arquitetura de software . 2. Sistemas multiagentes .

3. Controle de acesso . 4. Programao orientada a
aspectos . 5. SMA. 6. RBAC. I. Ttulo.
Dedicatria
minha famlia que sempre me apoiou.

Agradecimentos
minha orientadora Prof. Dr. Marcia Ito, pela dedicao, motivao e confiana.
Aos professores Prof. Dr. Carlos Hideo Arima e Prof. Dr. Maurcio Amaral de Almeida pela
orientao e apoio para concluso deste trabalho.
minha amiga Marie Moritani, que fez a reviso do texto da monografia.
Enfim, a todas as pessoas e entidades que direta ou indiretamente tornaram possvel a

elaborao deste trabalho.
Uma biblioteca permite que se procure Marx,
encontre-se Schopenhauer
e se requisite a Bblia.
Ernst R. Hauschka
RESUMO
PEIXOTO, W. F. Uma Proposta para Controle de Acesso Baseado em Papis na

Arquitetura do Agente com a Programao Orientada a Aspectos. 2009. 115f.
Dissertao (Mestrado), Centro Estadual de Educao Tecnolgica Paula Souza, So Paulo.
Um agente em geral, no se encontra sozinho num sistema, mas sim como integrante de um
Sistema Multiagentes que composto por um conjunto de diferentes tipos de agentes
distribudos em um ou mais ambientes. Estes agentes desempenham papis distintos e
colaboram entre si para execuo de tarefas. Os agentes distribudos por estes ambientes
podem sofrer inmeras ameaas de segurana onde o acesso no autorizado causado pela
ausncia ou pelo fraco controle de acesso pode ser a falha de segurana utilizada para uma
investida de ataque. Desse modo, o controle de acesso torna-se uma preocupao essencial no
desenvolvimento de sistemas orientados a agentes seguros. No entanto, a implementao
deste interesse no uma tarefa trivial, pois devido sua natureza transversal, quando
implementado frequentemente causa sintomas indesejveis que impactam de forma negativa
no sistema. Consequentemente, em meio ao desafio de implementar o interesse de controle de
acesso nos agentes, os desenvolvedores devem estar atentos tambm necessidade de
produzir sistemas com um nvel avanado de separao de interesses, pois a modularizao
inadequada de interesses transversais gera esforos indesejveis na compreenso, reuso e
evoluo de projetos orientados a agentes. A ideia da separao de interesses antiga e este
princpio suportado parcialmente por paradigmas de desenvolvimento como a programao
estruturada e a programao orientada a objetos. A programao orientada a aspectos
apontada como um paradigma complementar aos existentes, cujo objetivo prover suporte
separao avanada de interesses transversais em mdulos separados, chamados de aspectos.
Desta forma, atravs da utilizao dos aspectos e do modelo de controle de acesso RBAC,
este trabalho de mestrado prope uma arquitetura para o controle de acesso baseado em
papis que proporciona alm do controle de acesso, a separao avanada deste interesse.
Palavras-chave: Sistemas Multiagentes, SMA, Arquitetura de Software, Controle de Acesso,

Autorizao, RBAC, Programao Orientada a Aspectos
ABSTRACT
PEIXOTO, W. F. Uma Proposta para Controle de Acesso Baseado em Papis na

Arquitetura do Agente com a Programao Orientada a Aspectos. 2009. 115f.
Dissertao (Mestrado), Centro Estadual de Educao Tecnolgica Paula Souza, So Paulo.
An agent is not commonly found alone in a software system, usually an agent is an element of
a Multi-agent System that is composed of various different kinds of agents that run in one or
more environments. Agents play different roles and can collaborate with each other to
perform some tasks. Once agents are distributed in multiple environments, they can suffer
attacks. The unauthorized access caused by the absence or weak authorization can be the
security vulnerability used for such attacks. Thus, authorization turns out to be an essential
concern in the development of safe agent-oriented systems. However, the implementation of
this concern is not a trivial task, due to its crosscutting nature, unwanted symptoms that affect
in a negative way in the system are often seen when implemented. Consequently, amidst the
challenge of implementing the authorization concern in agents, the developers should be
aware of the need to produce systems with an advanced level of separation of concerns, since
the poor modularization of the crosscutting concerns can generate extra efforts to understand,
reuse and improve agent-oriented projects. The principle of separation of concerns isn't new
and is supported in part by some development paradigms like procedural and object-oriented
programming. The aspect-oriented programming is indicated as a paradigm that complement
the existing ones, which aims to provide better support in separating the crosscutting concerns
into modules known as aspects. Through the use of aspects and Role-Based Access Control
model, this work proposes an agent architecture that provides not only the authorization based
on roles, but the advanced separation on this crosscutting concern.
Keywords: Multi-agent Systems, MAS, Software Architecture, Access Control,

Authorization, RBAC, Aspect-Oriented Programming
LISTAS DE FIGURAS
Figura 3.1 Autenticao, controle de acesso e outros elementos de segurana.................... 30

Figura 3.2 Nveis do modelo NIST RBAC. ....................................................................... 32
Figura 3.3 RBAC Base...................................................................................................... 34
Figura 3.4 RBAC Base com suporte a sesses. .................................................................. 35
Figura 3.5 RBAC Hierrquico........................................................................................... 36
Figura 3.6 Exemplos de hierarquias de papis. .................................................................. 37
Figura 3.7 Separao esttica de responsabilidades............................................................ 39
Figura 3.8 Separao dinmica de responsabilidades. ........................................................ 39
Figura 4.1 Viso de um sistema como uma composio de mltiplos interesses. ............... 43
Figura 4.2 Analogia com um prisma para a decomposio dos interesses. ......................... 43
Figura 4.3 Decomposio de interesses numa viso multidimensional. .............................. 44
Figura 4.4 Emaranhamento de cdigo. .............................................................................. 45
Figura 4.5 Espalhamento de cdigo por blocos de cdigo duplicados. ............................... 46
Figura 4.6 Espalhamento de cdigo por blocos de cdigo complementares........................ 46
Figura 4.7 Mapeamento de um espao de N dimenses utilizando uma linguagem de uma
dimenso.............................................................................................................................. 47
Figura 4.8 Interesse transversal implementado em sistemas OO e OA. .............................. 48
Figura 4.9 Combinador de aspectos................................................................................... 50
Figura 4.10 Composio de aspectos. ................................................................................ 51
Figura 5.1 Modelo RBAC-MAS........................................................................................ 53
Figura 5.2 Agente Supervisor responsvel por autenticar os agentes de diferentes ambientes.
............................................................................................................................................ 58
Figura 5.3 Diagrama de classes dos aspectos de segurana. ............................................... 60
Figura 5.4 Ilustrao da atuao do aspecto ProactiveAuthenticationAspect. ..................... 66
Figura 5.5 Representao grfica da atuao do aspecto ReactiveAuthenticationAspect. .... 67
Figura 5.6 Representao grfica da atuao do aspecto ProactiveAccessControlAspect. .. 68
Figura 5.7 Ilustrao da atuao do aspecto ReactiveAccessControlAspect. ....................... 69
Figura 6.1 Analogia entre teste de sistema e teste de poltica de segurana. ....................... 72
Figura 6.2 Diagrama de instalao..................................................................................... 74
Figura 6.3 Diagrama de sequncia das interaes dos agentes executados no ambiente
interno. ................................................................................................................................ 74
Figura 6.4 Diagrama de sequncia das interaes dos agentes executados no ambiente
externo................................................................................................................................. 75
LISTAS DE QUADROS
Quadro 2.1 Exemplo de mensagem FIPA ACL com o ato de comunicao request. .......... 26
Quadro 5.1 Cdigo-fonte de um agente no JADE. ............................................................. 56
Quadro 5.2 Exemplo de aspecto. ....................................................................................... 65
Quadro 6.1 Resultado obtido pelo Teste 1. ........................................................................ 79
LISTAS DE TABELAS
Tabela 2.1 Propriedades do agente. ................................................................................... 20

Tabela 3.1 Variaes do RBAC organizadas pelo nvel e suas principais funcionalidades. 33
Tabela 5.1 PCDs primitivos utilizados............................................................................... 63
Tabela 6.1 Poltica de controle de acesso RBAC. .............................................................. 76
Tabela 6.2 Cenrios de teste. ............................................................................................. 77
Tabela 6.3 Descrio dos elementos utilizados para execuo do Teste 1. ......................... 78
Tabela 6.10 Descrio dos elementos utilizados para execuo do Teste 8. ....................... 86
LISTAS DE ABREVIATURAS E SIGLAS
ACL Agent Communication Language

CSI Computer Security Institute
DAC Discretionary Access Control
FIPA Foundation for Intelligent Physical Agents
INCITS International Committee for Information Technology
JADE Java Agent Development Framework
KIF Knowledge Interchange Format
KQML Knowledge and Querying Manipulation Language
MAC Mandatory Access Control
NIST National Institute of Standards and Technology
OA Orientao a Aspectos
OMG Object Management Group
OO Orientao a Objetos
PCD Pointcut Designator
POA Programao Orientada a Aspectos
RBAC Role-Based Access Control
SMA Sistemas Multiagentes
VPN Virtual Private Network
SUMRIO
1. Introduo........................................................................................................................ 14
1.1. Objetivos do Trabalho ............................................................................................... 16
1.2. Motivaes e Resultados Esperados........................................................................... 16
1.3. Mtodo e Desenvolvimento do Trabalho ................................................................... 17
1.4. Organizao do Trabalho........................................................................................... 18
2. Agentes............................................................................................................................ 19
2.1. Autonomia ................................................................................................................ 23
2.2. Interao ................................................................................................................... 24
2.3. Papis........................................................................................................................ 26
3. Autenticao e Controle de Acesso .................................................................................. 28
3.1. Modelos de Controle de Acesso................................................................................. 30
3.1.1. Modelo NIST RBAC .......................................................................................... 31
4. Separao de Interesses com a Programao Orientada a Aspectos................................... 41
4.1. Separao de Interesses ............................................................................................. 41
4.2. Modularizao........................................................................................................... 45
4.3. Programao Orientada a Aspectos............................................................................ 47
5. Controle de Acesso RBAC na Arquitetura do Agente....................................................... 52
5.1. Camada de Controle de Acesso ................................................................................. 57
5.2. Camada de Aspectos de Segurana............................................................................ 59
5.2.1. Componentes do AspectJ.................................................................................... 61
5.2.2. Aspectos de autenticao .................................................................................... 65
5.2.3. Aspectos de controle de acesso ........................................................................... 67
6. Testes para Verificao do Controle de Acesso ................................................................ 71
6.1. Implementao para o Teste ...................................................................................... 73
6.2. Testes e Simulaes................................................................................................... 77
6.3. Anlise dos Resultados.............................................................................................. 87
7. Concluso ........................................................................................................................ 89
Referncias .......................................................................................................................... 91
Glossrio.............................................................................................................................. 99
Apndice A - Cdigos-fonte dos Aspectos ......................................................................... 103
14
1. Introduo
Um agente entendido como um software capaz de resolver um problema em

particular de forma autnoma e ainda interagir com um ambiente para possibilitar a resoluo
de problemas que individualmente no conseguiria (WOOLDRIDGE, 2002).
Normalmente um agente no encontrado sozinho num sistema. Pode se comunicar
com outros agentes ou ambientes e com frequncia esta comunicao realizada atravs da
troca de mensagens padronizadas (OMG, 2000a).
Segundo o Object Management Group (OMG) (2000a), geralmente os agentes so
executados num ambiente computacional distribudo e um sistema de agentes executado nesta
condio pode sofrer inmeras ameaas de segurana como a interceptao, modificao ou
destruio de mensagens.
A possibilidade de ocorrerem problemas de segurana tende a ser maior em ambientes
abertos, como a Internet ou uma Virtual Private Network (VPN), mas podem ocorrer tambm
em qualquer ambiente onde as entidades no so totalmente conhecidas, compreendidas e
administradas por um nico grupo.
Mouratidis et al. (2005) relatam que h uma necessidade crescente de armazenamento
e gerenciamento de informaes que so consideradas confidenciais como por exemplo,
dados mdicos, financeiros e outros tantos dados privados. Portanto, desenvolver sistemas
seguros para o manuseio dessas informaes torna-se uma necessidade e no uma simples
opo, pois incidentes de segurana podem ocasionar exposio de informaes confidencias
e perdas financeiras (MOURATIDIS; GIORGINI; SCHUMACHER, 2003).
A preocupao com a segurana em sistemas de informao aumenta continuamente
devido ao crescente emprego dos computadores nos setores empresariais, governamentais e
de ensino e ao aumento da utilizao da Internet. Esta preocupao agravada pelos
contnuos registros de incidentes de segurana (WANGHAM, 2004).
Levantamentos feitos pela pesquisa Computer Crime & Security Survey publicada pelo
Computer Security Institute (CSI) em 2008 indicam que os incidentes de segurana mais
frequentes ocorrem devido: (I) a atuao de vrus, (II) abuso interno, ou seja, incidente de
segurana causado por funcionrios insatisfeitos, (III) roubo de laptops e outros dispositivos
portteis e (IV) acesso no autorizado a sistemas de informao.
De acordo com o National Institute of Standards and Technology (NIST) possvel
classificar as ameaas de segurana que um agente ou ambiente pode sofrer, em quatro
15
categorias: (I) ameaas de um agente atacando um ambiente; (II) agentes atacando outros
agentes; (III) um ambiente atacando os agentes e (IV) outras entidades atacando os agentes ou
ambientes (JANSEN; KARYGIANNIS, 2000).
Jansen e Karygiannis (2000) afirmam que em todas as categorias citadas com exceo
da (III), o acesso no autorizado causado pela ausncia ou pelo fraco controle de acesso pode
ser a falha de segurana utilizada para uma investida de ataque.
Para garantir a segurana dos recursos do sistema preciso que a autoridade dos
agentes seja verificada pelo sistema de agentes. Este sistema tambm deve conhecer qual
acesso permitido para cada autoridade. A habilidade de identificar a autoridade dos agentes
permite que o sistema de agentes realize o controle de acesso aos recursos (OMG, 2000b).
Desse modo, o controle de acesso um requisito indispensvel num sistema orientado
a agentes para proporcionar a mitigao dos riscos de segurana relacionados aos incidentes
causados pelo acesso no autorizado.
O modelo de controle de acesso baseado em papis, mais conhecido como Role-Based
Access Control (RBAC) (SANDHU; FERRAIOLO; KUHN, 2000), tem sido aplicado em
Sistemas Multiagentes (SMA) integrando a abordagem de segurana baseada em papis com
a coordenao e organizao dos agentes (MOLESINI; DENTI; OMICINI, 2008).
Apesar de necessria, a implementao do controle de acesso no uma tarefa trivial,
pois devido sua natureza transversal, quando implementado frequentemente causa sintomas
indesejveis no sistema como o emaranhamento e espalhamento de cdigo.
Consequentemente, em meio ao desafio de implementar o interesse de controle de acesso nos
agentes, os desenvolvedores devem estar atentos tambm a necessidade de produzir sistemas
com um nvel avanado de separao de interesses, pois a modularizao inadequada de
interesses transversais gera esforos indesejveis no reuso e evoluo de projetos orientados a
agentes (GARCIA; CHAVEZ; CHOREN, 2006).
Segundo Dijkstra (1976), a separao de interesses sempre foi tida como de
importncia primria no processo de desenvolvimento, pois um instrumento bsico para se
reduzir a complexidade de software. A Orientao a Aspectos (OA) (KICZALES et al., 1997),
um paradigma que promete a separao avanada de interesses atravs de uma nova
abstrao, chamada de aspecto, para modularizar os interesses transversais (SANTANNA,
2004).
16
1.1. Objetivos do Trabalho
O objetivo deste trabalho consiste em propor uma arquitetura para implementao do

modelo de controle de acesso RBAC nos agentes por meio da Programao Orientada a
Aspectos (POA) e desenvolver um mecanismo para controle de acesso RBAC aplicvel a
sistemas orientados a agentes.
1.2. Motivaes e Resultados Esperados
A segurana de informaes protege as aplicaes contra possveis ameaas a fim de

garantir a continuidade dos negcios, de minimizar prejuzos e maximizar o retorno de
investimentos (WANGHAM, 2004).
A preocupao com a segurana h muito tempo est presente no desenvolvimento de
sistemas orientados a agentes (WAGNER, 1997; MOURATIDIS; GIORGINI; WEISS, 2003),
pois frequentemente os agentes so executados num ambiente distribudo onde interagem
trocando mensagens atravs de redes abertas como a internet ou privadas como uma VPN e
nestas condies, h grande possibilidade de ocorrerem incidentes de segurana (OMG,
2000a).
O controle de acesso em agentes aplicado (CABRI; FERRARI; LEONARDI, 2004)
como uma forma de minimizar os problemas relativos a falta de segurana em sistemas
orientados a agentes e dentre os diferentes modelos de controle de acesso existentes, o RBAC
(SANDHU, 1997) apontado (NAVARRO et al., 2005; XIAO et al., 2007) como o mais
flexvel e tambm o mais adequado para sistemas orientados a agentes modelados segundo o
conceito de papel (PARTSAKOULAKIS; VOUROS, 2002).
Apesar da existncia de algumas propostas de implementao do modelo RBAC para
o controle de acesso dos agentes (YAMAZAKI; HIRAISHI; MIZOGUCHI, 2004;
MOLESINI; DENTI; OMICINI, 2008; QUILLINAN et al., 2008), nenhuma apresenta a
preocupao com a modularizao e separao deste interesse e como consequncia,
conforme constatado por Garcia et al. (2006), a falta de suporte separao de interesses
transversais gera esforos indesejveis no reuso e evoluo de projetos orientados a agentes.
17
Motivado por estas questes, este trabalho apresenta uma arquitetura para o controle
de acesso RBAC nos agentes que proporciona alm do controle de acesso, a separao
avanada desse interesse.
Todas as funes referentes ao controle de acesso RBAC so modularizadas por um
mecanismo criado para este fim. Apesar da grande importncia desse mecanismo para a
concluso deste trabalho, a discusso de sua arquitetura e outros aspectos do seu modelo no
fazem parte do escopo deste trabalho.
A utilizao do mecanismo de controle de acesso pelos agentes realizada por meio
da programao orientada a aspectos, sendo proporcionada desta forma, a separao avanada
deste interesse.
1.3. Mtodo e Desenvolvimento do Trabalho
A fase inicial da pesquisa consistiu-se no estudo da orientao a agentes e dos

principais modelos de controle de acesso existentes. Em seguida, buscou-se em artigos
cientficos, dissertaes de mestrado e teses de doutorado os modelos e abordagens j
pesquisados para a implementao do controle de acesso em agentes.
A partir dos resultados iniciais desta pesquisa, decidiu-se utilizar para o controle de
acesso, o modelo RBAC e ento, foi realizado um estudo dirigido adaptao deste modelo
ao contexto da orientao a agentes.
Para viabilizar a aplicao deste modelo nos agentes, optou-se por desenvolver um
mecanismo de controle de acesso RBAC aplicvel a sistemas orientados a agentes. Aps a
implementao deste mecanismo foi constatado que sua utilizao pelos agentes poderia
causar impactos negativos na arquitetura, devido a natureza transversal do interesse de
controle de acesso, que tende a ficar espalhado e emaranhado com os demais interesses dos
agentes. Por conta disto, paradigmas, tcnicas e ferramentas relacionadas ao conceito da
separao de interesses foram estudadas.
Aps este estudo, optou-se pela utilizao da orientao a aspectos para
implementao do controle de acesso RBAC na arquitetura dos agentes, pois atravs deste
paradigma possvel obter um grau maior na separao de interesses transversais.
Finalmente, foram definidos os cenrios das simulaes utilizadas para validar a
arquitetura proposta.
18
1.4. Organizao do Trabalho
O texto desta dissertao uma reflexo sobre as diversas etapas que foram cumpridas
durante o mestrado e est dividido em sete captulos. O restante desta dissertao est
estruturada da seguinte forma:
O Captulo 2 Agentes , define o conceito de agente e descreve as propriedades de
agncia, principalmente as propriedades de autonomia, interao e papel. Tambm abordada
em detalhes a comunicao entre agente por meio de mensagens.
Conceitos fundamentais encontrados no contexto da segurana de sistemas de
informao so apresentados no Captulo 3 Autenticao e Controle de Acesso , onde so
discutidas as abordagens de autenticao, controle de acesso e por ltimo, o modelo de
controle de acesso NIST RBAC apresentado em detalhes.
No Captulo 4 Separao de Interesses com a Programao Orientada a Aspectos ,
a questo da separao de interesses e modularizao apresentada, tambm so detalhados
os principais elementos da orientao a aspectos onde apresentado a AspectJ, uma extenso
da linguagem Java para POA.
O Captulo 5 Controle de Acesso RBAC na Arquitetura do Agente , apresenta a
arquitetura proposta nesta dissertao. As camadas, seus principais componentes e a forma de
atuao dos aspectos de autenticao e controle de acesso nos agentes so discutidos.
As simulaes realizadas para o teste da arquitetura proposta, seguida da anlise dos
resultados, so apresentadas no Captulo 6 Testes para Verificao do Controle de Acesso .
Finalmente, o Captulo 7 Concluso , exprime as consideraes gerais, contribuies e
possveis direcionamentos de pesquisas que este trabalho pode oferecer.
19
2. Agentes
Este captulo apresenta uma viso geral do conceito de agentes e das propriedades de
autonomia, interao e papel que so necessrias para o entendimento deste trabalho.
O termo agente utilizado em diversas disciplinas da cincia da computao, como a

inteligncia artificial, sistemas distribudos, sistemas de aprendizado adaptativo e sistemas
especialistas. De forma que difcil encontrar uma definio sucinta para agentes onde
estejam includas todas as caractersticas que os pesquisadores e desenvolvedores consideram
que eles apresentem (SUNDSTED, 1998).
Em geral, os pesquisadores concordam que a autonomia uma caracterstica
fundamental dos agentes (RIBEIRO, 2001).
Segundo Franklin e Graesser (1996), apesar das diversas definies existentes a
respeito dos agentes possvel formalizar uma definio onde os agentes so entendidos
como programas que esto num ambiente de execuo e necessitam possuir as propriedades
de reatividade, autonomia, proatividade e continuidade temporria para que realmente sejam
considerados agentes.
O OMG (2000a) define agentes autnomos como entidades de software autnomas
que interagem com seu ambiente, percebendo-o atravs de sensores e agindo nele atravs de
atuadores1. Esta definio semelhante a apresentada por Russell e Norvig (2003), que
definem o agente como qualquer coisa que pode perceber seu ambiente atravs de sensores e
atuar neste ambiente atravs de atuadores.
Para definir o termo agente, ser utilizada a definio Wooldridge (2002) que entende
o agente como um sistema computacional situado em algum ambiente e que capaz de aes
autnomas neste ambiente a fim de alcanar seus objetivos.
Um agente possui uma estrutura de dados interna que se atualiza de acordo com a
chegada de novas percepes e esta estrutura utilizada nos procedimentos de tomada de
deciso, os quais iro gerar aes (GIRARDI; FERREIRA, 2002).
A arquitetura interna de um nico agente pode incorporar muitas propriedades. A
Tabela 2.1 apresenta, segundo o OMG (2000a), algumas delas e uma breve descrio de cada
uma.
1
Traduo do termo em ingls effectors, tambm traduzido como efetores e efetuadores.
20
Tabela 2.1 Propriedades do agente.

Propriedade Descrio
Autonomia Capacidade de atuar sem interveno externa direta.
Interao Capacidade de interagir com o ambiente e outros agentes.
Adaptao Capacidade de responder em algum grau a outros agentes e ao
seu ambiente. Formas mais avanadas de adaptao permitem
ao agente modificar seu comportamento baseado nas suas
experincias anteriores.
Mobilidade Capacidade de se transportar de um ambiente para outro.
Proatividade Capacidade de agir devido a sua orientao a objetivos. O
agente no age simplesmente em resposta ao ambiente.
Continuidade temporria um processo continuamente em execuo.
Carter Capacidade de possuir personalidade e estado emocional.
Reatividade Capacidade de perceber mudanas no ambiente e atuar de
acordo com essas mudanas.
Coordenao Capacidade de desempenhar atividades num ambiente
compartilhado com outros agentes. Estas atividades so
coordenadas atravs de planos, fluxos de trabalho ou
mecanismos de gerncia de processos.
Colaborao\Cooperao Capacidade dos agentes de se coordenarem para alcanar um
objetivo comum.
Aprendizado Capacidade do agente de aprender baseado em experincias
anteriores, quando interagindo com seu ambiente.
Algumas propriedades como a interao e colaborao so vitais em agentes que

compem um SMA. Jennings et al. (1998) consideram o SMA como uma composio de
entidades autnomas que interagem entre si para solucionar problemas que esto alm de suas
capacidades e conhecimentos individuais. Um agente que no suficientemente capacitado
para realizar uma tarefa especfica pode solicitar a realizao desta tarefa para outro agente
mais capacitado.
Um SMA caracterizado pela composio de um conjunto de diferentes tipos de
agentes e objetos que so inseridos em ambientes (JENNINGS, 1999). As principais
caractersticas dos SMAs so:
Cada agente tem capacidade de solucionar parcialmente o problema;

No existe um controle global do sistema;
Os dados so descentralizados;
O processamento assncrono.
21
Segundo o OMG (2000a) algumas consideraes sobre os SMAs so importantes:

Um agente no pode ser onipotente, ou seja, construdo de forma que faa tudo
sozinho, pois dessa forma ele ser pesado e poder apresentar problemas de velocidade,
confiabilidade, manuteno etc. Pela atribuio de papis aos agentes obtido maior
modularidade, flexibilidade, manutenibilidade e extensibilidade.
O agente no pode ser onisciente, o conhecimento est espalhado em vrios agentes,
podendo ser integrado a fim de obter se uma viso geral, quando necessrio.
Aplicaes que requerem computao distribuda so melhor suportadas por SMAs.
Agentes podem ser projetados como pequenos componentes autnomos que trabalham em
paralelo. O processamento e soluo de problemas de forma concorrente trazem solues para
muitos problemas que at ento eram tratados de uma maneira mais linear.
Em geral, um SMA utiliza mais de um tipo de agente. Um sistema que utiliza agentes
de mais de um tipo conhecido como sistema de agentes heterogneos.
O tipo do agente definido por sua classificao que pode ser realizada de diferentes
maneiras, devido as propriedades e caractersticas que o diferencia dos outros (FRANKLIN;
GRAESSER, 1996). Por exemplo, um agente do tipo mvel quando possui a habilidade de
transportar-se de um ambiente para outro, no entanto, um agente sem esta habilidade
classificado como esttico ou estacionrio. Tambm possvel classificar um agente de
acordo com o domnio de servios que ele oferece ao ambiente, por exemplo, agente de
informao responsvel por obter informaes ou agente de segurana responsvel pela
segurana do sistema (KNAPIK; JOHNSON, 1997).
Para Ferber (1999), a capacidade cognitiva dos agentes uma caracterstica que
tambm pode ser utilizada para sua classificao. Este autor apresenta trs classes de agentes:
cognitivos, reativos e hbridos.
O agente cognitivo reage no ambiente usando o conhecimento com base no histrico
do agente e incorpora estratgias de adaptao ou tcnicas de aprendizagem. Possui a
capacidade de raciocnio baseada na representao interna de seu mundo. Esta representao
realizada atravs de componentes cognitivos conhecidos como estados mentais. Os estados
mentais so responsveis pela gesto de todas as atividades internas de um agente como a
percepo e execuo de aes, crenas, desejos, intenes, mtodos e planos.
J o agente reativo simplesmente reage no ambiente sem qualquer conhecimento
prvio de sua histria. Por ltimo, o agente hbrido um agente cognitivo e reativo.
22
Sob o ponto de vista de Nwana (1996), os agentes devem ser classificados de acordo
com trs dimenses: (I) mobilidade que diferencia agentes mveis de estticos , (II) o
paradigma lgico empregado que classifica o agente entre cognitivo2 ou reativo e (III) a
caracterstica fundamental: autonomia, cooperao e aprendizado.
A combinao de duas ou mais destas caractersticas classifica o agente como hbrido,
por exemplo, agente reativo colaborativo, agente esttico reativo colaborativo etc.
As classificaes de tipos de agente no so excludentes. De maneira que, um agente
cognitivo pode ser tambm de informao ou um agente de segurana pode ser reativo ou
cognitivo (GARCIA, 2004).
Os agentes, independentemente do tipo, esto inseridos em um ou mais ambientes.
Ambiente tudo que possa interagir com um agente, e que no faa parte da sua estrutura
interna.
Segundo Russel e Norvig (2003), os ambientes de agentes podem ser classificados de
acordo com as caractersticas: acessvel ou inacessvel; determinstico ou no determinstico;
esttico ou dinmico e por ltimo discreto ou contnuo.
O ambiente acessvel aquele em que o agente pode obter uma informao atual,
completa e precisa sobre o estado do ambiente.
No ambiente determinstico no h incerteza sobre o resultado proveniente das aes
do agente, ou seja, uma ao tem somente um resultado possvel.
O ambiente esttico aquele que s altera seu estado mediante as aes dos agentes e
nunca por qualquer outro fator externo.
Ambiente discreto aquele em que existe um nmero fixo e finito de aes e
percepes sobre ele.
Segundo Wooldrige (2002), os ambientes mais complexos so os inacessveis, no
determinsticos, dinmicos e contnuos. As caractersticas do ambiente so importantes para
determinar a complexidade no processo de desenvolvimento dos agentes. No entanto, no o
nico fator que deve ser levado em considerao, a interao dos agentes com o ambiente
tambm importante.
Para a compreenso da arquitetura apresentada por este trabalho faz-se necessrio
alm do entendimento do conceito de agente, SMA, tipos de agentes e ambiente, a discusso
das propriedades de autonomia, interao e papel.
2
Tambm denominado como deliberativo ou racional.
23
2.1. Autonomia
A autonomia e a interao so consideradas pela Foundation for Intelligent Physical

Agents (FIPA) (2002) e o OMG (2000a) como propriedades requeridas para os agentes. A
autonomia caracterizada pela ausncia de controle externo sobre um agente, ou seja, ele tem
controle sobre suas aes e pode agir de forma independente de outros para alcanar seus
objetivos.
De acordo com Garcia (2004), esta propriedade essencial para distinguir agentes de
objetos. Pois, os objetos so controlados pela parte externa, em oposio aos agentes que
possuem um comportamento autnomo que no pode ser controlado externamente. Desse
modo, os agentes podem decidir negar uma solicitao de servio e ainda agir conforme
desejar. Este autor apresenta a autonomia dos agentes em trs dimenses:
(I) autonomia de execuo;

(II) autonomia de deciso;
(III) autonomia proativa.
Para alcanar seus objetivos, os agentes tm suas prprias threads de controle (I),
tomam decises em relao a instanciaes de objetivos (II) e realizam aes sem uma
interveno externa direta (III) (GARCIA, 2004).
A autonomia de execuo o controle das threads de agente. Existe diferentes
estratgias para a instanciao de threads de agente. Por exemplo, uma nica thread
instanciada quando o agente criado, uma thread instanciada para cada novo objetivo do
agente, uma thread criada para cada mensagem externa recebida etc.
A autonomia de deciso consiste em tomar decises sobre a realizao de objetivos,
esta capacidade acaba deliberando num determinado momento o curso de ao que um agente
toma. A deciso implementada por aes simples ou planos, ambos associados aos
objetivos. Assim que um evento percebido por um agente estas aes ou planos so
realizados e ento decidido se a realizao de um objetivo deve ser iniciada ou no.
24
A autonomia proativa caracterizada pela proatividade, definida como a execuo de

aes ou planos sem uma solicitao explcita de outros agentes, ou seja, o agente no age
simplesmente em resposta ao ambiente, mas sim devido a sua orientao a objetivos.
2.2. Interao
Um agente no pode evocar ou simplesmente forar outro agente a realizar alguma

ao, porm atravs de atos de comunicao3 pode interagir com ele e o influenciar a realizar
esta ao (WOOLDRIDGE, 2002).
Segundo Symeonidis e Mitka (2006), a interao a propriedade que permite ao
agente interagir com outros agentes e seu ambiente. A interatividade confere o aspecto
comportamental que o agente exibe em relao a seu ambiente, este comportamento pode ser
caracterizado como de reatividade ou proatividade.
A reatividade pode ser definida como a habilidade de perceber mudanas no ambiente
e responder a elas quando necessrio. J a proatividade entendida como a habilidade de agir
por iniciativa prpria para satisfazer algum objetivo do agente.
De acordo com Garcia (2004), a interao consiste em receber e enviar mensagens
para outros agentes. Atravs dos sensores e atuadores os agentes detectam a chegada de
mensagens de outros agentes e enviam mensagens ou geram eventos no ambiente.
Para Huhns e Singh (1997), esta forma de comunicao entre agentes pode ser vista
sob uma perspectiva de trs nveis: (I) sintaxe como as mensagens so estruturadas ; (II)
semntica o contedo das mensagens e (III) pragmatics como a mensagem pode ser
interpretada . O significado da mensagem est na combinao da semntica com o
pragmatics (HUHNS; STEPHENS, 1999).
Geralmente, as mensagens so estruturadas conforme alguma das linguagens de
comunicao de agentes (Agent Communication Language, ACL) existentes e so exemplos
destas linguagens a Knowledge and Querying Manipulation Language (KQML) (FININ et al.,
1994), Knowledge Interchange Format (KIF) (GENESERETH, 1991) e por ltimo a FIPA
ACL (FIPA, 2002).
3
Traduo do termo em ingls communicative acts, tambm conhecido como speech acts e performatives.
25
As ACLs citadas no pargrafo anterior esto fundamentadas na teoria conhecida como

speech acts (SEARLE, 1969), de modo que cada mensagem representa um ato de
comunicao (BELLIFEMINE; CAIRE; GREENWOOD, 2007).
Segundo Wooldridge (2002), a FIPA ACL possui sintaxe similar a KQML, pois a
estrutura da mensagem quase a mesma e os parmetros das mensagens so muito similares.
A diferena relevante entre estas duas linguagens est na coleo de atos de comunicao que
elas oferecem.
Entre todos os atos de comunicao oferecidos pela FIPA ACL, so destacados por
Wooldridge (2002) como sendo de grande importncia o inform e o request.
O ato de comunicao inform utilizado para comunicar uma informao, usado
sempre que o agente emissor da mensagem precisa informar ao receptor sobre uma
proposio que considera verdadeira. J o request permite ao agente emissor solicitar ao
receptor que execute uma ao.
Alm do ato de comunicao, uma mensagem FIPA ACL composta tambm por um
ou mais parmetros.
A quantidade de parmetros presentes numa mensagem pode variar de acordo com a
comunicao em questo. O parmetro performative que denota o ato de comunicao ,
requerido enquanto os parmetros sender que define o agente emissor da mensagem ,
receiver que define o agente receptor da mensagem e content contedo da mensagem ,
apesar de no serem obrigatrios, esto na maioria das mensagens.
Um exemplo de mensagem FIPA ACL apresentado no Quadro 2.1. Neste exemplo
possvel verificar o ato de comunicao do tipo request na linha 01; os valores dos parmetros
sender e receiver, ou melhor, o agente emissor e o receptor da mensagem nas linhas 02 e 03;
e por ltimo, o contedo da mensagem na linha 07 em diante.
26
Quadro 2.1 Exemplo de mensagem FIPA ACL com o ato de comunicao request.
01. (request
02. :sender (agent-identifier :name alice@mydomain.com)
03. :receiver (agent-identifier :name bob@yourdomain.com)
:ontology travel-assistant
:language FIPA-SL
:protocol fipa-request
07. :content
""((action
(agent-identifier :name bob@yourdomain.com)
(book-hotel :arrival 15/10/2006
:departure 05/07/2002 ... )
))""
)
Fonte: (BELLIFEMINE; CAIRE; GREENWOOD, 2007)
2.3. Papis
Os papis de agentes4 tm sido utilizados durante as fases de concepo (SILVA et al.,

2003), anlise (ZAMBONELLI; JENNINGS; WOOLDRIDGE, 2000), projeto e
implementao (KENDALL, 1999) de SMAs.
Segundo Partsakoulakis e Vouros (2004), a autonomia dos agentes faz com que eles
possam decidir seu prprio comportamento e em consequncia desta natureza autnoma,
existe a necessidade de coordenao dos agentes ou ento, o grupo pode apresentar um
comportamento catico. Uma maneira efetiva de alcanar esta coordenao com a
imposio de uma organizao composta por papis e suas inter-relaes especfica para o
grupo.
Agentes podem fazer parte deste grupo se forem capazes de desempenhar um ou mais
papis que contribuam para o alcance dos objetivos coletivos (PARTSAKOULAKIS;
VOUROS, 2004).
De acordo com Garcia (2004), o papel inerente a propriedade de colaborao, pois o
agente exerce diferentes papis num SMA ao trabalhar junto com outros agentes na tentativa
de alcanar os objetivos.
Um papel agrupa diferentes tipos de comportamentos em uma unidade funcional que
contribui para um objetivo do grupo, ou seja, cada papel possui o conhecimento e os
4
Traduo do termo em ingls agent roles.
27
comportamentos necessrios para realizar as colaboraes com outros agentes (GARCIA,

2004).
As interaes dos agentes, ou seja, suas aes e comportamentos podem ser
modelados segundo o conceito de papel, desta maneira, determinadas aes ou
comportamentos s sero apresentados por agentes que desempenham papis especficos
(CABRI; LEONARDI; ZAMBONELLI, 2002).
Em geral, os papis podem ser classificados em dois tipos: (I) papel intrnseco que
define o conhecimento intrnseco e as funcionalidades bsicas do agente , e (II) papel
extrnseco ou colaborativo que diz respeito ao exerccio das capacidades extrnsecas do
agente em seus relacionamentos colaborativos .
A definio de um tipo de agente est relacionada ao papel intrnseco exercido por ele
no sistema, enquanto a definio de um papel captura o modo como um agente interage com
outros agentes em seus relacionamentos de colaborao.
Segundo Garcia (2004), a relao entre papel e agente regida por oito princpios: (I)
dependncia um papel no pode existir sem um tipo de agente associado a ele ; (II)
dinamicidade um papel pode ser adicionado ou removido durante o ciclo de vida de um
agente ; (III) identidade o papel e o agente possuem a mesma identidade , ou seja, o tipo
de agente e seus papis so vistos e podem ser manipulados como uma entidade; (IV) herana
o papel de um tipo de agente tambm o papel para qualquer subtipo de agente ; (V)
multiplicidade o agente pode exercer vrios papis ao mesmo tempo ; (VI) visibilidade o
acesso ao agente restringido pelo papel ; (VII) abstratividade os papis podem ser
organizados em hierarquias e (VIII) agregao os papis podem ser compostos por outros
papis .
Neste captulo foram apresentados os conceitos de agente, SMA, tipo de agente e

ambientes. As propriedades de autonomia, interao e papis e a estrutura da mensagem FIPA
ACL foram abordadas em detalhes. No prximo captulo sero apresentados dois conceitos
fundamentais da segurana de sistemas de informao: a autenticao e o controle de acesso.
28
3. Autenticao e Controle de Acesso
Segundo Sandhu e Samarati (1996), a autenticao, o controle de acesso e a auditoria

constituem a base para a segurana de sistemas de informao. Este captulo apresenta dois
conceitos fundamentais encontrados no contexto da segurana de sistemas de informao: a
autenticao e o controle de acesso. Devido ao conceito de controle de acesso e o modelo
NIST RBAC serem de grande importncia para este trabalho, ambos so apresentados em
detalhes no decorrer deste captulo.
A segurana da informao visa proteger as informaes de ameaas, com o objetivo
de preservar o valor que possuem para um indivduo ou uma organizao, de forma a
assegurar a continuidade de um negcio, minimizar danos e maximizar o retorno dos
investimentos e das oportunidades (CAMILO, 2001).
Atravs da implementao de um conjunto de controles tais como: polticas, prticas,
procedimentos, estruturas organizacionais e funes de programas, trs propriedades
essenciais de segurana da informao podem ser preservadas: confidencialidade, integridade
e a disponibilidade (ITSEC,1991).
A confidencialidade a garantia de que a informao seja acessvel somente para
queles que tm autorizao para acess-la.
A integridade a preservao da informao conforme definida por aqueles que tm a
autorizao para manipul-las.
A disponibilidade a garantia de que a informao esteja sempre disponvel para os
usurios que possuem a autorizao para acess-la.
Estas trs propriedades da segurana da informao tambm se aplicam segurana de
sistemas de informao, onde a confidencialidade pode ser alcanada atravs da
implementao do controle de acesso (MCLEAN, 1994).
De acordo com Lehtinen et al. (2006), o controle de acesso em sistemas de informao
composto pelo controle de acesso ao sistema e o controle de acesso aos dados.
Controle de acesso ao sistema a primeira forma pela qual um sistema proporciona
segurana, pois o controle de acesso a si mesmo. Este processo estabelece a identidade de
uma entidade usurio, mquina, agente de software outra; um exemplo comum um
usurio que atravs de seu nome e senha tenta identificar-se num sistema para obter acesso
aos seus recursos (GONG; ELLISON; DAGEFORDE, 2003).
29
O controle de acesso aos dados est ligado capacidade do sistema de limitar o acesso
do usurio a determinados recursos que este oferece.
Na terminologia de segurana da informao, o controle de acesso ao sistema
conhecido como identificao e autenticao enquanto o controle de acesso aos dados
simplesmente conhecido como controle de acesso ou autorizao.
Autenticao e controle de acesso so propriedades de segurana que mantm um
relacionamento estreito, sendo que comum ao implementar a propriedade de controle de
acesso implementar tambm a propriedade de autenticao.
A funo do controle de acesso garantir que apenas usurios autorizados possam
manusear informaes, acessar recursos ou funcionalidades dos sistemas. Para que isto seja
possvel necessrio identificar e autenticar o usurio que solicita o acesso (VILLAR, 2007).
A autenticao com frequncia um pr-requisito para o controle de acesso, pois
atravs dela uma entidade no poder se passar por outra, tendo assim, acesso a recursos no
autorizados a ela.
No processo de autenticao, a entidade fornece uma prova para constatar que
realmente quem diz ser. OGorman (2003) agrupa os fatores da autenticao em trs
categorias:
Baseados no que voc sabe;

Baseados no que voc possui;
Baseados no que voc .
O primeiro fator baseado no conhecimento de um segredo ou algo obscuro,

exemplos disto so a senha ou a cor preferida de um usurio.
O segundo fator baseado na posse fsica de um objeto, um token ou qualquer
dispositivo que de alguma maneira armazene senhas, chaves ou certificados de identidade so
exemplos frequentes.
O ltimo fator baseado na unicidade de uma pessoa, sistemas biomtricos como o
reconhecimento da impresso digital, da voz e ainda a identificao pela ris ou retina, so
exemplos deste tipo de autenticao.
30
Conforme descrito por Sandhu e Samarati (1994), o controle de acesso ou autorizao,

responsvel por limitar as atividades de usurios j autenticados pelo sistema. Este processo
ilustrado pela Figura 3.1 onde possvel observar que o elemento principal o monitor de
referncia, que controla cada tentativa de acesso realizada por um usurio aos recursos de um
sistema. Assim que o usurio tenta acessar um recurso do sistema, o monitor de referncia
consulta um banco de dados de autorizaes para verificar se o usurio possui as devidas
permisses de acesso ao recurso desejado.
As permisses do banco de dados de autorizaes so mantidas por um administrador
de segurana que as define de acordo com a poltica de segurana da organizao.
Figura 3.1 Autenticao, controle de acesso e outros elementos de segurana.

Fonte: Adaptado de SANDHU; SAMARATI (1994)
O controle de acesso de grande importncia para este trabalho, por isto apresentado
em maiores detalhes a seguir.
3.1. Modelos de Controle de Acesso
Os mecanismos de controle de acesso so utilizados para implementar a poltica de

autorizao de um sistema e esto ligados aos modelos de controle de acesso (WANGHAM,
2004).
31
Sandhu e Samarati (1996) classificam os modelos de controle de acesso em trs

categorias: discricionrio, obrigatrio e baseado em papis.
O controle de acesso discricionrio5 baseado na ideia de que o dono da informao
determina quem tem acesso a ela. Ele permite que os dados sejam livremente copiados de
objeto para objeto, mesmo que o acesso aos dados originais seja negado, um sujeito sempre
pode obter acesso a uma cpia.
O controle de acesso obrigatrio6 baseado nos conceitos de confidencialidade
utilizados na rea militar como um meio de gerenciar informaes previamente classificadas.
Utiliza um controle centralizado de segurana onde usurios e objetos, ou melhor, recursos do
sistema, so previamente classificados de modo que um usurio s tenha acesso a
informaes a qual possui habilitao (YAO, 2003).
Por ltimo, no controle de acesso baseado em papis, os direitos de acesso so
atribudos aos papis ao invs de serem atribudos a cada usurio, como no controle de acesso
discricionrio, os usurios obtm estes direitos em virtude de terem papis atribudos a si.
A atuao do papel como intermedirio que possibilita ao usurio exercitar uma
permisso, a responsvel pela grande flexibilidade e granularidade das atribuies de
permisso, resultado que no alcanado na atribuio direta de permisses ao usurio, sem o
uso de papis (CONCEIO; SILVA, 2006).
3.1.1. Modelo NIST RBAC
Sandhu et al. (2000) relatam que muitos vendedores de sistemas de computao tm

implementado variaes do modelo RBAC em seus produtos como banco de dados, sistemas
administrativos e operacionais devido a facilidade e flexibilidade deste modelo.
Em 2000, Sandhu et al. em considerao a uma requisio do NIST desenvolveram
uma proposta de padro para o modelo RBAC, com o objetivo de auxiliar fabricantes de
sistemas que desejavam adotar um modelo RBAC padro em seus produtos.
5
Traduo do termo em ingls Discretionary Access Control (DAC).
6
Traduo do termo em ingls Mandatory Access Control (MAC).
32
Este modelo foi publicado como NIST RBAC model (SANDHU; FERRAIOLO;
KUHN, 2000) e depois adotado como um padro 359-2004 RBAC pelo o InterNational
Committee for Information Technology (INCITS) em 2004.
O NIST RBAC continua sendo aprimorado atravs do INCITS, que em 2009 solicitou
revises para o modelo INCITS 359-2004 RBAC.
Este modelo inspirado no modelo RBAC96 proposto anteriormente por Sandhu
(1997), porm conforme descrito por Sandhu et al. (2000), o modelo NIST RBAC
organizado em quatro nveis sequenciais, apresentados pela Figura 3.2, onde funcionalidades
so acrescentadas de maneira gradual. Cada nvel adiciona exatamente um requisito e os
nveis so acumulativos, de forma que cada nvel contm os requisitos do nvel anterior da
sequncia.
Figura 3.2 Nveis do modelo NIST RBAC.
Alguns nveis deste modelo apresentam subnveis e em cada um deles implementado

uma funcionalidade especfica do nvel em questo. A Tabela 3.1 mostra os nveis, subnveis
e suas principais funcionalidades.
33
Tabela 3.1 Variaes do RBAC organizadas pelo nvel e suas principais funcionalidades.
Nvel Nome Funcionalidades
usurio adquire permisses atravs de papis
deve suportar uma relao muitos para muitos de
usurios para papis (UA)
1 RBAC Base deve suportar uma relao muitos para muitos de
permisses para papis (PA)
deve suportar reviso da relao usurio para papel
(UA)
usurios podem utilizar as permisses de mltiplos
papis simultaneamente
funcionalidades do nvel anterior
2 RBAC Hierrquico deve suportar hierarquia de papel (ordem parcial)
nvel 2a, requer suporte a hierarquias arbitrrias
nvel 2b, denota suporte a hierarquias limitadas
funcionalidades dos nveis anteriores
3 RBAC Restritivo deve suportar a separao de responsabilidades
funcionalidades do nvel anterior
4 RBAC Simtrico deve suportar reviso da relao permisso para papel
(PA) com performance comparvel a reviso da
relao usurio para papel (UA)
Fonte: Adaptado de SANDHU; FERRAIOLO; KUHN (2000)
O primeiro nvel deste modelo o RBAC Base7, responsvel pela implementao das
entidades principais do modelo RBAC: usurios (U), papis (R) e permisses (P). Sandhu et
al. (2000) descrevem as estas trs entidades da seguinte maneira:
Um usurio neste modelo a representao de um ser humano, agente autnomo,
processo ou mquina.
Papel um trabalho funcional ou o ttulo de um trabalho e confere determinada
autoridade e responsabilidade ao usurio que desempenha o papel.
Permisso a aprovao de um modo particular de acesso a um ou mais objetos do
sistema. Nesse modelo, objetos representam dados ou qualquer outro recurso que o sistema
possa oferecer. Elas so sempre positivas, conferindo poder ao seu portador de executar
alguma ao no sistema.
7
Traduo do termo em ingls Flat RBAC.
34
Duas relaes fazem a ligao dessas trs entidades: a atribuio de usurios8 (UA) e a
atribuio de permisses9 (PA). Estas relaes so do tipo muitos para muitos, ou seja, um
usurio pode desempenhar vrios papis e um papel pode ser desempenhado por vrios
usurios. De forma similar, um papel pode ter vrias permisses e uma permisso pode ser
atribuda a vrios papis. A Figura 3.3 ilustra graficamente como esto relacionadas as
entidades usurios, papis e permisses neste nvel. Usurios esto ligados aos papis atravs
da relao atribuio de usurios e as permisses esto ligadas aos papis atravs da relao
atribuio de permisses.
Figura 3.3 RBAC Base.

No primeiro nvel exigido que a reviso da relao usurio para papel seja
implementada; atravs desta funcionalidade os papis atribudos a um usurio podem ser
determinados, assim como, quais usurios possuem um determinado papel.
Por exigncia deste modelo, um usurio deve exercitar, simultaneamente, as
permisses de todos papis que detm, isto impossibilita produtos que restrinjam usurios a
ativao de um nico papel por vez.
Sandhu (1997) formaliza os componentes deste nvel por meio da definio:
U, R, P, (usurios, papis e permisses respectivamente);
UA U R, relao muitos para muitos de usurio para papel;
PA P R, relao muitos para muitos de permisso para papel.
8
Traduo do termo em ingls user assignment.
9
Traduo do termo em ingls permission assignment.
35
O conceito de sesses presente de forma facultativa neste modelo, ao contrrio do

modelo RBAC96 (SANDHU, 1997) onde requerido, considerado como o mapeamento de
um usurio para um ou mais papis. O usurio estabelece uma sesso ao ativar um
subconjunto de papis os quais ele detm, criando assim uma relao um para muitos. A
Figura 3.4 ilustra o RBAC Base implementado com o suporte a sesses onde possvel notar
que por meio da sesso o usurio associado a um ou mais papis.
Com a utilizao da sesso possvel que um usurio, detentor de um papel que possui
permisses mais amplas, possa desativar temporariamente este papel e utiliz-lo somente
quando as permisses que ele oferece forem necessrias.
Assim, um usurio detentor de vrios papis, pode trabalhar apenas com um
subconjunto deles adequado execuo das atividades a serem realizadas na sesso, e este
princpio conhecido como privilgio mnimo 10.
Segundo Conceio e Silva (2006), a atuao do papel como intermedirio que
possibilita o usurio exercitar uma permisso a responsvel pela grande flexibilidade e
granularidade das atribuies de permisso, resultado que no alcanado na atribuio direta
de permisses a usurio, sem o uso de papis.
Figura 3.4 RBAC Base com suporte a sesses.

De acordo com Sandhu et al. (2000), o segundo nvel, RBAC Hierrquico11, difere do
nvel anterior pelo fato de implementar os requisitos necessrios para introduo da relao de
hierarquia de papel (RH). Este nvel representado graficamente pela Figura 3.5, a nica
10
Traduo do termo em ingls least privilege.
11
Traduo do termo em ingls Hierarchical RBAC.
36
diferena com relao ao nvel anterior a adio da relao de hierarquia de papel (RH) na
entidade Papis (R).
Sandhu (1997) formaliza os componentes deste nvel atravs da definio:
U, R, P, UA, PA (permanecem inalterados);
RH R R, um ordenamento parcial em R chamado de hierarquia de

papis, ou de relao de domnio entre papis.
Organizaes normalmente possuem uma estrutura hierrquica de comando. A

hierarquia de papis estrutura naturalmente a autoridade e responsabilidade dentro de uma
linha de uma organizao (SANDHU, 1997).
Figura 3.5 RBAC Hierrquico.

Por conveno, a posio mais alta na hierarquia, ou seja, papis com o maior nmero
de permisses so posicionados na parte superior enquanto os de menor nmero so
posicionados na parte inferior.
Atravs da Figura 3.6(a) possvel observar uma hierarquia de papis. O papel de
menor poder na hierarquia o membro do projeto que est situado na parte inferior do
desenho, logo acima est o analista, papel que herda as permisses do papel membro do
projeto.
37
O papel analista pode acrescentar novas permisses alm das herdadas pelo papel
membro do projeto. A herana de permisses cumulativa, ou seja, o papel analista
programador herda as permisses dos papis analista e membro do projeto, o mesmo vlido
para o papel analista de teste.
Um papel pode tambm herdar as permisses de dois ou mais papis. A Figura 3.6(b)
exibe um exemplo de herana mltipla onde o papel supervisor do projeto herda as
permisses dos papis analista programador e analista de teste.
Dois subnveis de hierarquias so reconhecidos neste modelo: arbitrria e limitada.
Com a hierarquia arbitrria possvel a adoo de um ordenamento parcial arbitrrio
para servir como a hierarquia de papis.
Figura 3.6 Exemplos de hierarquias de papis.

Atravs da hierarquia limitada possvel a imposio de limitaes na hierarquia de

papis, normalmente as hierarquias so limitadas a estruturas simples como rvores ou
rvores invertidas.
O terceiro nvel, RBAC Restritivo12, implementa por meio de restries13 o conceito
de separao de responsabilidades14.
12
Traduo do termo em ingls Constrained RBAC.
13
Traduo do termo em ingls constraints.
14
Traduo do termo em ingls separation of duty, tambm traduzido como separao de tarefas e separao de
deveres.
38
Sandhu (1997) considera as restries um aspecto importante do modelo RBAC,

muitas vezes apontado como a principal motivao deste modelo.
Segundo Camilo (2001), a separao de responsabilidades uma tcnica conhecida
muito antes da existncia dos computadores, que possibilita a reduo da possibilidade da
ocorrncia de fraudes ou danos acidentais.
A separao de responsabilidades realizada atravs da diviso de responsabilidade e
autoridade sobre uma ao, ou tarefa entre mltiplos usurios, diminuindo assim o risco
decorrente de uma ao fraudulenta, pois a execuo de uma tarefa requer o envolvimento de
mais de um indivduo.
Um exemplo prtico da aplicao dessa ideia a prtica comum de algumas
organizaes de no permitir ao mesmo indivduo desempenhar o papel de requisitante de
pagamento e autorizador de pagamento, esta medida evita que o mesmo indivduo possa
solicitar um pagamento e logo em seguida autoriz-lo: estes dois papis so mutuamente
exclusivos.
A separao de responsabilidades pode ser implementada atravs da aplicao das
restries nas permisses, por exemplo, as permisses para requisitar pagamento e autorizar
pagamento no poderiam ser atribudas ao mesmo papel, evitando assim que um papel seja
perigosamente poderoso.
Existe, tambm, a possibilidade de utilizar as restries para aplicar a separao de
responsabilidades por cardinalidade. Neste modo, a restrio para atribuio de um papel est
na quantidade de usurios que podem ser atribudos a um papel, por exemplo, o papel de
diretor comercial seria limitado a no mximo um usurio.
possvel realizar a separao de responsabilidades de duas formas: esttica e
dinmica.
A separao esttica de responsabilidades15 realizada pela aplicao das restries
diretamente na atribuio do usurio aos papis (UA), conforme ilustrado pela Figura 3.7;
desta forma, um usurio nunca tem papis mutuamente exclusivos e esta relao
considerada esttica, pois no alterada ao longo do tempo.
15
Traduo do termo em ingls static separation of duty.
39
Figura 3.7 Separao esttica de responsabilidades.

A separao dinmica de responsabilidades16 apresenta uma pequena diferena em

relao a tcnica anterior: a aplicao das restries realizada somente nos papis que esto
ativos numa sesso, conforme exibido pela Figura 3.8, desta forma, uma sesso nunca tem
papis mutuamente exclusivos ao mesmo tempo, porm devido ao mecanismo de sesso,
usurios podem ter diferentes nveis de permisso em diferentes momentos.
Figura 3.8 Separao dinmica de responsabilidades.

16
Traduo do termo em ingls dynamic separation of duty.
40
O ltimo nvel deste modelo, RBAC Simtrico17, incorpora todas as caractersticas j

adicionadas pelos nveis anteriores e acrescenta a reviso da relao de permisso para papel,
similar a reviso da relao de usurio para papel apresentada no primeiro nvel.
Com esta funcionalidade possvel determinar quais permisses foram atribudas a
um papel especfico, assim como, a quais papis uma determinada permisso foi atribuda.
Este captulo teve por objetivo esclarecer os dois conceitos fundamentais encontrados
no contexto da segurana de sistemas de informao: a autenticao e o controle de acesso,
alm de apresentar em detalhes o modelo de controle de acesso NIST RBAC. No prximo
captulo, a questo da separao de interesses ser abordada e os conceitos de modularizao
e orientao a aspectos sero apresentados.
17
Traduo do termo em ingls Symmetric RBAC.
41
4. Separao de Interesses com a Programao Orientada a

Aspectos
Por muitos anos, tericos da computao concordaram que a melhor maneira de criar
sistemas mais gerenciveis identificando e separando os interesses do sistema. Esta
separao um importante instrumento para se reduzir a complexidade de sistemas de
software (FIGUEIREDO, 2006). A ideia da separao de interesses18 antiga, alguns
pesquisadores afirmam que este princpio foi formalizado por Dijkstra (1976). Este princpio
suportado parcialmente por paradigmas de desenvolvimento como a programao estruturada
e a programao orientada a objetos (OO), os quais disponibilizam abstraes que, de alguma
maneira, permitem a modularizao dos interesses com variaes de graus.
Atualmente existem algumas abordagens para a separao avanada de interesses,
incluindo a programao orientada a sujeitos (HARRISON; OSSHER, 1993), filtros de
composio (AKSIT et al., 1993), programao adaptativa (LIEBERHERR, 1996;
LIEBERHERR; ORLEANS; OVLINGER, 2001) e separao multidimensional de interesses
(TARR et al., 1999).
Segundo Lobato (2005), estas abordagens contribuem para o desenvolvimento de
sistemas OO, uma vez que proporcionam a separao de interesses em outras dimenses, alm
de classes e objetos, ao introduzir novas abstraes de modularizao e mecanismos de
composio para refinar a separao de interesses transversais.
A orientao a aspectos (KICZALES et al., 1997) discutida neste captulo, uma das
abordagens para separao avanada de interesses. apontada como um paradigma
complementar aos existentes, cujo objetivo prover suporte separao de interesses
transversais em mdulos separados, chamados de aspectos (FIGUEIREDO, 2006).
4.1. Separao de Interesses
A separao de interesses o princpio que tenta resolver as limitaes da cognio

humana ao lidar com a complexidade do software (GARCIA, 2004).
18
Traduo do termo em ingls separation of concerns.
42
Um interesse uma considerao especfica que deve ser atendida para que seja
possvel satisfazer o objetivo geral do sistema.
Um sistema o resultado da realizao de um conjunto de interesses (LADDAD,
2003).
De forma geral, os interesses podem ser classificados em duas categorias: interesses
principais19 e interesses transversais20.
Interesse principal o que se tenta separar dos demais, captura a essncia, o relevante
para o domnio da aplicao. O interesse principal prov a funcionalidade desejada sem
depender de outros aspectos da computao como distribuio, persistncia, segurana etc.
Ele especifica o que realmente importante para a aplicao.
Interesse transversal qualquer forma de computao utilizada para controlar ou
otimizar os interesses principais. Neste sentido, o interesse transversal prov suporte para os
interesses principais desempenhando assim um papel secundrio.
Uma aplicao frequentemente necessita desenvolver interesses transversais como
autenticao, logging, persistncia, transaes etc. Todos estes interesses transversais citados,
naturalmente se espalham pelos subsistemas ou mdulos da aplicao. A Figura 4.1 ilustra
esta situao, na qual possvel observar o desenvolvimento de alguns mdulos do sistema
que implementam tanto interesses referentes ao sistema system level como a segurana e a
persistncia, quanto interesses de negcio business concerns representado na figura pela
lgica de negcios. A figura tambm exibe o sistema como uma composio de mltiplos
interesses que ficam emaranhados. Devido tcnica utilizada na implementao dos mdulos,
a independncia dos interesses no mantida.
19
Traduo do termo em ingls core concerns, tambm traduzido como interesse central e interesse bsico.
20
Traduo do termo em ingls crosscutting concerns, tambm traduzido como interesse perifrico, interesse
especial, interesse entrecortante e interesse ortogonal.
43
Figura 4.1 Viso de um sistema como uma composio de mltiplos interesses.

Fonte: Adaptado de LADDAD (2003)
Esta situao no favorvel, pois para que um interesse seja compreendido e

manuseado com mais facilidade, cada parte do programa dedicada a satisfazer a um
determinado interesse deve estar concentrada num nico local fsico, separada de outros
interesses (FIGUEIREDO, 2006).
Para que um desenvolvedor consiga manter o foco em cada interesse individual
separadamente, reduzindo assim a complexidade do modelo e implementao de uma
aplicao, vital a identificao meticulosa dos interesses principais e transversais de um
sistema. Para se obter este resultado o primeiro passo decompor um conjunto de requisitos
separando-os em interesses. Laddad (2003) apresenta duas tcnicas para decompor requisitos
num conjunto interesses, que so apresentadas a seguir.
A primeira tcnica utiliza a analogia de um feixe de luz passando por um prisma para
elucidar o processo da decomposio dos requisitos em interesses. A Figura 4.2 ilustra esta
analogia; primeira vista um requisito aparenta ser uma nica unidade, entretanto, aps ser
aplicado um mecanismo de identificao de interesses possvel compreender que um
requisito composto por diversos interesses.
Figura 4.2 Analogia com um prisma para a decomposio dos interesses.

44
A segunda tcnica projeta os interesses num espao, com N dimenses, na qual cada
interesse forma uma dimenso. A Figura 4.3 apresenta esta ideia ao exibir um espao de
interesses com trs dimenses onde a lgica de negcios o interesse principal e a
persistncia e o aprendizado so interesses transversais. Este tipo de viso de um sistema
demonstra que os interesses apresentados neste espao multidimensional so independentes
de modo que podem evoluir sem afetar o restante.
Figura 4.3 Decomposio de interesses numa viso multidimensional.

Segundo Hrsch e Lopes (1995), possvel distinguir dois nveis de separao de

interesses: o conceitual e de implementao. No conceitual, a separao de interesses se limita
em prover uma definio clara e uma identificao conceitual de todos os interesses que se
distinguem de outros e assegurar que cada conceito individual no sentido de que ele no
uma composio de conceitos. No de implementao, a separao de interesses precisa prover
uma organizao adequada que consiga isolar os interesses; o objetivo deste nvel separar os
blocos de cdigo que lidam com diferentes interesses e prover um acoplamento menos rgido
entre eles.
Apesar de muitos paradigmas de desenvolvimento de software reconhecerem a
importncia da abstrao conceitual e a separao de interesses, poucas linguagens de
programao permitem que estas abstraes fiquem realmente separadas quando
programadas. A separao de interesses geralmente realizada no nvel conceitual, e no nvel
de implementao pode variar seu teor de separao dependendo da linguagem de
programao e tcnica utilizada.
45
4.2. Modularizao
Segundo Parnas (1972), a melhor maneira de lidar com a separao de interesses por
meio da criao de mdulos os quais escondem suas implementaes uns dos outros. Esta
ideia correta em sua essncia, no entanto sabe-se que as linguagens disponveis at ento
no disponibilizam meios suficientes para que esta modularizao seja mantida. Como
decorrncia da m modularizao, dois sintomas que prejudicam a manuteno e
entendimento dos sistemas so causados com frequncia: o emaranhamento de cdigo21 e o
espalhamento de cdigo22.
O emaranhamento de cdigo conforme descrito por Kiczales et al. (1997), causado
quando um mdulo implementado tendo que lidar com mltiplos interesses
simultaneamente. A consequncia deste emaranhamento do cdigo o aumento significativo
da sua complexidade para o entendimento do mesmo (LOPES, 1997); a Figura 4.4 ilustra este
sintoma ao apresentar os interesses de segurana, logging, persistncia e mobilidade
implementados num nico lugar e de maneira intercalada.
Figura 4.4 Emaranhamento de cdigo.

O espalhamento de cdigo causado quando um procedimento implementado em

mltiplos mdulos. Como os interesses transversais, por definio ficam espalhados por
muitos mdulos, as implementaes relacionadas a eles tambm se dispersam por todos estes
21
Traduo do termo em ingls code tangling, tambm traduzido como entrelaamento de cdigo.
22
Traduo do termo em ingls code scatteing.
46
mdulos (LADDAD, 2003). O espalhamento de cdigo pode ser classificado em duas

categorias: blocos de cdigo duplicados e blocos de cdigo complementares.
Blocos de cdigo duplicados so caracterizados pela repetio de cdigos que
apresentam uma natureza aproximadamente idntica, a Figura 4.5 elucida esta situao ao
exibir o espalhamento de cdigo causado pela necessidade de implementar a funcionalidade
de checar autorizao de acesso nos mdulos: contas, ATM, cliente e atendente.
Figura 4.5 Espalhamento de cdigo por blocos de cdigo duplicados.

Blocos de cdigo complementares so caracterizados quando alguns mdulos

implementam partes complementares de um interesse, a Figura 4.6 exibe o espalhamento de
cdigo causado pela necessidade de se colocar blocos de cdigo complementares em
mltiplos mdulos para produzir uma funcionalidade.
Figura 4.6 Espalhamento de cdigo por blocos de cdigo complementares.

47
O emaranhamento de cdigo e o espalhamento de cdigo juntos, impactam

negativamente no projeto e desenvolvimento de software de muitas maneiras. possvel notar
como consequncia destes sintomas, a reduo do entendimento, o aumento da dificuldade de
evoluo e a reduo da reusabilidade dos artefatos de software (SANTANNA, 2004).
De acordo com Orleans (2005), as linguagens OO suportam parcialmente a separao
de interesses atravs da utilizao da herana e do polimorfismo, entretanto muitas vezes um
interesse no pode ser separado apenas em classes.
Da mesma forma, Garcia (2004) afirma que a orientao a objetos possui limitaes
claras no tratamento de interesses que cuidam dos requisitos naturalmente envolvidos em
diversas operaes e componentes do sistema. Esta limitao ilustrada pela Figura 4.7:
esquerda mostrado um espao tridimensional de interesses e direita est o cdigo
unidimensional que implementa estes interesses, representado nesta figura por um fluxo
contnuo de chamadas. A ortogonalidade dos interesses no espao de interesses perdida
quando eles so mapeados para um espao de implementao unidimensional onde seu foco
a implementao dos interesses principais, e ento a implementao dos interesses
transversais fica misturada com a implementao dos interesses principais.
Figura 4.7 Mapeamento de um espao de N dimenses utilizando uma linguagem de uma dimenso.
4.3. Programao Orientada a Aspectos
Segundo Kiczales et al. (1997), existem propriedades que um sistema deve

implementar e que no so modularizveis segundo os paradigmas atualmente dominantes;
estas propriedades so classificadas em componentes e aspectos. Componentes podem ser
facilmente modularizados segundo o processo de decomposio funcional. Os aspectos, no
entanto, so difceis de modularizar por este processo; os aspectos so propriedades que
precisam ser satisfeitas em vrios componentes de um sistema, como sincronizao,
48
persistncia, caching etc. ou que no fazem parte das responsabilidades primrias dos
componentes. Assim, o objetivo da orientao a aspectos possibilitar ao desenvolvedor
separar componentes e aspectos de forma clara, e ainda comp-los entre si da maneira
apropriada de forma a constituir o sistema desejado.
A POA favorece a modularizao dos interesses transversais por meio de uma
abstrao chamada aspecto que possibilita a sua separao e composio para produzir o
sistema (SANTANNA, 2004). Esta abordagem contribui para a melhoria no
desenvolvimento de software OO, pela separao avanada de interesses que proporciona
atravs da utilizao de aspectos. A Figura 4.8 ilustra esta forma de separao dos interesses
transversais exibindo graficamente como a implementao de um interesse transversal pelos
mdulos de um sistema OO acaba espalhada e emaranhada, enquanto a implementao com a
OA consegue modularizar este interesse transversal num nico aspecto. possvel notar que
na implementao OO, cada classe representada pelo retngulo precisa lidar diretamente
com o interesse transversal em questo, enquanto na implementao OA, somente o aspecto
representado pelo losango lida diretamente com este interesse.
Figura 4.8 Interesse transversal implementado em sistemas OO e OA.

Fonte: Adaptado de FIGUEIREDO (2006)
Figueiredo (2006) constata que a orientao a aspectos introduz uma terceira dimenso
de decomposio quando utilizada em conjunto com a OO, ao decompor o sistema em dados
e funes e, tambm, de acordo com os interesses transversais em abstraes denominadas
aspectos.
49
Um sistema baseado em aspectos composto por cinco elementos: uma linguagem de

componentes, uma (ou mais) linguagem(ns) de aspectos, um (ou mais) programa(s) de
componentes, um ou mais programas de aspectos e um combinador de aspectos.
A linguagem de componentes normalmente uma linguagem de programao que se
baseia teoricamente em um dos paradigmas de desenvolvimento de software23, como Java,
C++, Pascal, C, Lisp etc.
A linguagem de aspectos normalmente uma extenso das linguagens de
componentes. Alguns exemplos de linguagens de aspectos so a AspectJ (ASPECTJ, 2009),
AspectC++ (ASPECTCPP, 2009), Aspect.NET (ASPECTNET, 2009) e a AspectLua
(ASPECTLUA, 2009).
Dentre as linguagens de aspectos citadas, a AspectJ foi utilizada para implementao
da arquitetura proposta neste trabalho.
O AspectJ uma linguagem para programao orientada a aspectos de uso geral,
criada pelo laboratrio Palo Alto Research Center, da Xerox, e hoje um projeto de cdigo
aberto mantido pela fundao Eclipse (ECLIPSE, 2009).
Ela funciona como uma extenso da linguagem Java (JAVA, 2009), sendo um
superconjunto desta linguagem. Desse modo, todo programa em AspectJ, ao ser compilado,
passvel de execuo em qualquer mquina virtual Java (Kiczales et al., 2001).
Portanto, em uma aplicao orientada a aspectos em AspectJ, os componentes so
implementados usando a sintaxe padro de Java, e os aspectos so implementados usando a
sintaxe de AspectJ.
O cdigo do aspecto torna explcito o comportamento que integrado ao cdigo dos
componentes, e os contextos onde a integrao ocorre, os chamados pontos de juno24.
Pontos de juno so elementos semnticos da linguagem de componentes com as
quais os programas de aspectos se coordenam. Exemplos de pontos de juno comuns so:
invocaes de mtodos chamadas ou recebimentos , lanamento de excees, instanciao
de objetos, entre outros.
O combinador de aspectos25 combina os programas de componentes e de aspectos de
forma a gerar o programa final (PIVETA, 2001). Ele identifica nos componentes, pontos de
23
Orientado a Objetos, Procedural, Declarativa.
24
Traduo do termo em ingls join point.
25
Traduo do termo em ingls weaver.
50
juno onde os aspectos se aplicam produzindo o cdigo final da aplicao, que implementa
tanto as propriedades definidas pelos componentes como aquelas definidas pelos aspectos.
Pode, ainda, atuar em tempo de compilao ou de execuo, implementaes de
combinadores de aspectos em tempo de execuo tm a possibilidade de permitir a adio ou
excluso de aspectos na aplicao em tempo de execuo.
A Figura 4.9 ilustra o funcionamento do combinador de aspectos que atua em tempo
de compilao. Para combinar classes e aspectos, primeiramente realizada a compilao das
classes utilizando o compilador da linguagem e em seguida elas so combinadas com os
aspectos pela ao do combinador de aspectos. O produto um programa executvel,
resultado da combinao das classes com os aspectos.
Figura 4.9 Combinador de aspectos.

Segundo Laddad (2003), desenvolver um sistema utilizando POA similar a

desenvolver um sistema utilizando outros paradigmas: preciso identificar os interesses,
implement-los e por ltimo formar um sistema final combinando-os.
Geralmente, a comunidade de pesquisa de POA define este processo em trs passos:
(I) decomposio dos aspectos, (II) implementao dos interesses e (III) recomposio dos
aspectos.
No primeiro passo, os requisitos so decompostos com a finalidade de identificar quais
so interesses principais e transversais. No segundo passo, cada interesse implementado de
maneira independente. Por ltimo, so especificadas as regras para a recomposio dos
aspectos criados e ento, o combinador de aspectos utiliza estas informaes para combin-los
e formar o sistema final.
51
Figura 4.10 Composio de aspectos.

A Figura 4.10 ilustra graficamente os trs passos deste processo descritos

anteriormente. Ao utilizar novamente a analogia de um feixe de luz passando por um prisma,
possvel observar a decomposio dos aspectos representada pelo feixe de luz passando
por um prisma que a decompe em espectros ; estes espectros representam os interesses
que so implementados pelos aspectos . Por ltimo, a recomposio dos aspectos realizada
pelo combinador de aspectos representado pelo prisma invertido que junta todos os
espectros num nico feixe de luz que representa o sistema.
Neste captulo foram abordadas a questo da separao de interesses, os sintomas da

m modularizao e foi apresentada a programao orientada a aspectos, um paradigma
complementar aos existentes, cujo objetivo prover a separao de interesses transversais em
mdulos fisicamente separados chamados aspectos. A arquitetura de controle de acesso
RBAC em agentes, proposta por este trabalho, ser apresentada no prximo captulo.
52
5. Controle de Acesso RBAC na Arquitetura do Agente
Este captulo relata as principais decises tomadas tendo em vista a implementao do

controle de acesso RBAC na arquitetura do agente com um vis para a separao de
interesses.
A aplicao do conceito de papis em agentes apontada como um padro de projeto

para modelagem das interaes dos agentes que permite a separao de responsabilidades e o
reuso de cdigo (WOOLDRIDGE; JENNINGS; KINNY, 1999; CABRI; FERRARI;
ZAMBONELLI, 2003).
Uma aplicao dos papis em agentes trabalhada por Viroli et al. (2007) onde
apresentado o modelo RBAC-MAS. Este modelo prope a modelagem e organizao de um
SMA seguindo os conceitos do modelo RBAC. Os autores tambm observam que trs
adaptaes conceituais no modelo RBAC so necessrias para que este fique adequado ao
contexto dos SMAs.
A primeira adaptao o entendimento de que neste modelo a entidade Usurio (U)
o prprio agente do sistema. A segunda uma consequncia da primeira caracterizada pela
relao Atribuio de Agentes (UA), onde os Papis (R) so atribudos diretamente a um
agente, de acordo com os papis que este desempenha. Por ltimo, as Permisses (P) so
concedidas sobre as aes e percepes dos agentes e no acerca dos recursos que o sistema
possa oferecer. O conceito de sesso e a relao Atribuio de Permisses (PA) permanecem
inalterados.
Os principais componentes deste modelo podem ser formalizados atravs da definio:
U, R, P, (agentes, papis e permisses respectivamente);
UA U R, relao muitos para muitos de agentes para papel;
PA P R, relao muitos para muitos de permisso para papel.
A Figura 5.1 apresenta graficamente as entidades do modelo RBAC-MAS, esquerda

exibida a entidade Agentes (U), a relao Atribuio de Agentes (UA) e a entidade
53
Sesses(S), que tambm est presente neste modelo de forma facultativa. Ao centro
ilustrada a entidade Papis (R) que est ligada entidade Permisses (P) por meio da relao
Atribuio de Permisses (PA).
Figura 5.1 Modelo RBAC-MAS.

Fonte: Adaptado de VIROLI; OMICINI; RICCI (2007)
Do mesmo modo que o conceito de papel empregado na modelagem e organizao

dos agentes, tambm aplicado no controle de acesso dos agentes (CABRI; FERRARI;
LEONARDI, 2005), especialmente no controle de acesso segundo o modelo RBAC, onde o
papel a entidade central (NAVARRO et al., 2005; XIAO et al., 2007; QUILLINAN et al.,
2008).
Ao observar os sistemas orientados a agentes modelados com o conceito de papel e o
modelo de controle de acesso RBAC, nota-se que ambos possuem o papel como elemento
central e comum. Em virtude disto, este trabalho considera que o modelo RBAC adequado
para o controle de acesso em sistemas orientados a agentes modelados segundo o conceito de
papis, pois neste contexto, conforme j elaborado por Viroli et al. (2007) o agente
entendido como o usurio que desempenha papis.
No entanto, a implementao do interesse de controle de acesso, que tipicamente um
interesse transversal, causa paralelamente sintomas indesejveis no sistema como o
espalhamento e entrelaamento de cdigo quando realizada segundo as formas tradicionais de
modularizao (BODKIN, 2004; SHAH; HILL, 2004), de modo que a separao avanada de
interesses se faz desejvel.
Tendo como fundamento a abordagem em que a separao de interesses inerente ao
controle de acesso, esta arquitetura estrutura estes dois conceitos separao de interesses e
54
controle de acesso em camadas, seguindo as diretrizes estabelecidas pelo padro arquitetural

Layer (BUSCHMAN et al., 1996), onde cada camada representa um nvel de abstrao.
A estruturao da arquitetura do agente em camadas no uma ideia nova; Kendall et
al. (1999) propem o padro arquitetural Agente em camadas que fundamentado no padro
Layer, para separar os diferentes interesses que um agente deve tratar como por exemplo a
autonomia, a mobilidade, a interao etc.
No contexto deste trabalho, a arquitetura dos agentes est composta por trs camadas:
A primeira camada trata das propriedades intrnsecas dos agentes como: a autonomia,
a interao e os papis. nesta camada que os sensores e atuadores dos agentes esto
desenvolvidos. Sua discusso no faz parte do escopo deste trabalho.
O controle de acesso RBAC de responsabilidade da segunda camada. Sua funo
apenas prover o mecanismo para a autenticao dos agentes e o manuseio de seu usurio,
papis e permisses.
A terceira camada responsvel pela separao do interesse de controle de acesso por
meio dos aspectos. Ela atua como um intermedirio que utiliza as funcionalidades de controle
de acesso que esto na segunda camada e realiza a ligao com as propriedades essenciais dos
agentes que esto na primeira camada.
Desta forma, o interesse de controle de acesso incorporado aos agentes sem a
necessidade deles implement-lo diretamente, o que causaria os sintomas da m
modularizao discutidos no captulo anterior. Os detalhes de construo da camada de
controle de acesso e a de separao do interesse, chamada de camada de aspectos de
segurana, so discutidos em sees distintas no decorrer deste captulo.
Para auxiliar no desenvolvimento dos agentes foi utilizado o arcabouo26 Java Agent
Development Framework (JADE) (BELLIFEMINE et al., 2003). Este arcabouo OO
destinado ao desenvolvimento de SMAs em conformidade com o padro FIPA (FIPA, 2002).
Sob o ponto de vista de Caire (2003), o JADE pode ser entendido tambm como um
middleware, pois alm das bibliotecas de classes que oferece para criao de agentes,
disponibiliza um ambiente de execuo para os agentes e ferramentas grficas para a
administrao e monitoramento das atividades dos agentes que so executados na plataforma.
Trs propriedades foram decisivas para a escolha deste arcabouo. A primeira o fato
de um agente no JADE ser representado por um nico componente Java um exemplo est
26
Traduo do termo em ingls framework.
55
apresentado no Quadro 5.1 , caracterstica que viabiliza a realizao do processo de

combinao dos aspectos que permite a atuao dos aspectos nos agentes. A segunda o
mecanismo conhecido como pginas amarelas27, que permite a localizao de um agente que
fornece um determinado servio. E por ltimo, a comunicao entre agentes por mensagens
FIPA ACL (FIPA, 2002), que permite aos aspectos examinarem seu contedo. O emprego
destas propriedades na arquitetura proposta demonstrado nas prximas sees, cujo objetivo
explicar as camadas da arquitetura e seus principais componentes.
27
Traduo do termo em ingls yellow pages, tambm conhecido como Directory Facilitator (DF).
56
Quadro 5.1 Cdigo-fonte de um agente no JADE.

package br.mestrado.hosp.agents;
import jade.core.Agent;
import jade.core.behaviours.CyclicBehaviour;
import jade.lang.acl.ACLMessage;
/**
* Exemplo de agente no JADE
* */
public class Supervisor extends Agent {
protected void setup() {
// Set this agent main behaviour

addBehaviour(new ReceiveMessagesBehaviour(this));
}
// Behaviour
private class ReceiveMessagesBehaviour extends CyclicBehaviour {
public ReceiveMessagesBehaviour(Agent a) {
super(a);
}
public void action() {

ACLMessage msg = receive();
if (msg == null) {
block();
return;
}
try {
// responde pelo tipo de msg
switch (msg.getPerformative()) {
case (ACLMessage.INFORM): {
break;
}
case (ACLMessage.REQUEST): {
break;
}
case (ACLMessage.QUERY_REF): {
break;
}
default:
break; //replyNotUnderstood
}
} catch (Exception ex) {

ex.printStackTrace();
}
}
}
}
57
5.1. Camada de Controle de Acesso
Esta camada cuja funo prover a autenticao e controle de acesso aos agentes,
constituda por dois elementos: um mecanismo de controle de acesso RBAC chamado
Heimdall e um agente chamado Supervisor.
At o momento da finalizao desta pesquisa no foi encontrado nenhum mecanismo
ou arcabouo para controle de acesso NIST RBAC que pudesse ser aplicado aos agentes
desenvolvidos com o JADE, por conta disto o Heimdall foi construdo.
O Heimdall um mecanismo de autenticao e controle de acesso que implementa o
modelo NIST RBAC, apresentado no captulo trs. Portanto, a principal funo deste
mecanismo atuar como um monitor de referncia de forma a realizar o controle de acesso
dos agentes.
Para construo deste mecanismo foi utilizado como base, o Java Authentication and
Authorization Service (JAAS) (2009), uma biblioteca do Java para autenticao e controle de
acesso. Desta forma, as funes bsicas de autenticao e controle de permisses dos usurios
puderam ser aproveitadas pelo Heimdall podendo-se assim, concentrar os esforos para sua
construo na tarefa de adaptao das funes j existentes de maneira a trabalhar conforme o
modelo RBAC.
O segundo elemento integrante desta camada o agente Supervisor. Sua funo
realizar a autenticao dos agentes que atravs do envio de mensagens FIPA ACL (FIPA,
2002) solicitam autenticao e comunicar a possvel falta de permisso de algum agente
quando este tenta executar uma ao a qual no possui a devida permisso.
A ideia de estabelecer um nico agente responsvel por atender ao pedido de
autenticao de todos os agentes que interagem num determinado ambiente trabalhada por
Cabri et al. (2004), que apresentam o agente Supervisor. Neste trabalho o agente Supervisor
utilizado com mesmo conceito, porm ao contrrio da ideia original onde este agente assumia
um papel para cada ambiente em que era capaz de realizar a autenticao, nesta arquitetura
este agente assume um nico papel: o de supervisor. Ao desempenhar este papel ele capaz
de autenticar tanto os agentes que esto no mesmo ambiente em que ele se encontra quanto os
agentes que esto em outros ambientes.
O agente Supervisor, assim que criado, registra-se no servio de pginas amarelas
como provedor do servio de autenticao. Desta forma, todos os agentes que desejam
58
participar da sociedade podem procurar por um agente capaz de realizar sua autenticao e
solicitar esta operao antes de comear a interagir com os demais agentes.
Para que um agente seja autenticado deve enviar uma mensagem do tipo
SolicitarAutenticacaoAction para o agente Supervisor contendo o usurio e senha que so
utilizados pelo Heimdall no processo de autenticao. Caso a autenticao seja bem sucedida,
o agente registrado pelo Heimdall numa lista de agentes autenticados onde armazenado o
identificador nico do agente e o usurio que ele utilizou. Desta forma, possvel controlar os
agentes autenticados e os usurios utilizados. De modo que a partir do usurio utilizado por
um agente possvel conhecer os papis e permisses aos quais ele tem direito.
Uma vez autenticado, o agente est submetido de forma direta ou indireta , ao
controle de acesso atravs da atuao dos aspectos de controle de acesso. As formas de
atuao destes aspectos so discutidas na prxima seo.
A Figura 5.2 ilustra graficamente a disposio dos elementos envolvidos no processo
de autenticao. possvel identificar o agente Supervisor e os demais agentes que enviam
mensagens do tipo SolicitarAutenticacaoAction para o Supervisor a fim de serem
autenticados. Tambm demonstrado que os agentes podem estar em dois ambientes
distintos: interno e externo.
O ambiente interno definido neste trabalho como o ambiente onde o agente
Supervisor se encontra e por isto, tambm o ambiente onde o controle de acesso est
implementado. J o externo definido como qualquer ambiente que interage com o interno
embora o controle de acesso no esteja presente.
Figura 5.2 Agente Supervisor responsvel por autenticar os agentes de diferentes ambientes.
Fonte: Adaptado de CABRI; FERRARI; LEONARDI (2004)
59
Embora todos os agentes devam ser autenticados, o procedimento explicado

anteriormente recomendado somente para agentes que so executados num ambiente
externo, pois conforme discutido na prxima seo, a autenticao dos agentes que esto no
ambiente interno pode ser realizada pela atuao do aspecto ProactiveAuthenticationAspect,
de maneira que o fluxo de mensagens desnecessrias evitado.
5.2. Camada de Aspectos de Segurana
A funo desta camada implementar o interesse de controle de acesso nos agentes de

forma que esteja presente sem que estes tenham que lidar diretamente com ele. Para alcanar
este nvel de independncia a POA utilizada.
Esta camada composta por sete aspectos de segurana:
SecurityAspect;
AuthenticationAspect;
ProactiveAuthenticationAspect;
ReactiveAuthenticationAspect;
AccessControlAspect;
ProactiveAccessControlAspect;
ReactiveAccessControlAspect.
Os aspectos foram agrupados de acordo com sua funo, autenticao ou controle de

acesso e modelados de acordo com o diagrama de classes exibido na Figura 5.3. No topo do
diagrama est o aspecto SecurityAspect; ele o ancestral de todos os aspectos de segurana.
Este aspecto possui como propriedade uma referncia ao agente Supervisor e esta referncia
herdada e utilizada pelos seus aspectos descendentes.
Dois aspectos estendem diretamente o SecurityAspect: AuthenticationAspect e
AccessControlAspect. Estes dois, assim como o ancestral comum, so abstratos e apenas
60
fornecem funcionalidades bsicas para os quatro aspectos que atuam diretamente nos agentes
do ambiente interno: ProactiveAuthenticationAspect, ReactiveAuthenticationAspect,
ProactiveAccessControlAspect e ReactiveAccessControlAspect. Estes quatro so os principais
desta arquitetura, por isto so apresentados individualmente e em detalhes no decorrer desta
seo.
Figura 5.3 Diagrama de classes dos aspectos de segurana.
Os aspectos de autenticao e controle de acesso atuam de duas maneiras distintas, por

isto so classificados como proativos ou reativos.
Os aspectos proativos atuam nos agentes que esto no ambiente interno, de forma a
evitar a troca de mensagens desnecessrias entre os agentes.
Aspectos reativos tambm atuam nos agentes que esto no ambiente interno, mas
somente quando estes recebem mensagens de agentes que esto em ambiente externo e por
isso no possvel exercer o controle de acesso proativo.
Numa viso geral, os aspectos atuam nos sensores e atuadores dos agentes,
responsveis respectivamente por receber e enviar mensagens FIPA ACL. Independentemente
da forma de atuao do aspecto proativo ou reativo na maioria dos casos, sua atividade se
61
resume interceptao e anlise do contedo das mensagens seguida da legitimao ou no,

da troca de mensagem.
Para a anlise do contedo da mensagem os parmetros sender, receiver e content da
mensagem FIPA ACL so utilizados pelo aspecto, pois a partir deles possvel obter o agente
emissor, receptor e o contedo, ou melhor, a ao que a mensagem representa. E, com estas
informaes, o aspecto averigua atravs do Heimdall se os agentes emissor e receptor
possuem as permisses necessrias para lidarem com aquela ao. Caso possuam, a troca de
mensagem legitimada, seno esta operao abortada.
Com esta estratgia o aspecto evita o processamento desnecessrio de mensagens
pelos sensores e receptores dos agentes, pois somente mensagens vlidas so trocadas, alm
de promover a separao do interesse de controle de acesso que est presente nos agentes sem
que estes lidem de forma direta com ele.
A linguagem AspectJ (ASPECTJ, 2009) foi utilizada para a programao dos aspectos
de segurana e, por conta disto, alguns conceitos essenciais para a compreenso do
funcionamento destes aspectos so apresentados a seguir.
5.2.1. Componentes do AspectJ
Os principais componentes do AspectJ utilizados neste trabalho foram os pontos de

juno, pontos de atuao28, atuadores29 e aspectos.
Ponto de juno qualquer ponto de execuo identificvel de um sistema, um dos
conceitos fundamentais da POA e consequentemente, do AspectJ. Como exemplos de pontos
de juno em uma linguagem OO podem ser citados:
chamada de mtodo;
atribuio de um valor a uma varivel;
sentena de retorno de um mtodo;
instanciao de um objeto;
28
Traduo do termo em ingls pointcut.
29
Traduo do termo em ingls advice, tambm traduzido como adendo e comportamento ortogonal.
62
checagem de uma condio;

uma comparao;
o manuseio de uma exceo30;
laos interativos como for, while, do/while.
Apesar desta grande variedade de pontos de juno, o AspectJ, com a finalidade de

evitar dependncia de implementao ou ortogonalidade instvel, disponibiliza somente
alguns deles para a utilizao, os quais so conhecidos como pontos de juno expostos. Em
geral, este tipo de ponto de juno so os lugares no cdigo fonte do sistema onde possvel
alterar a execuo principal do programa. Entres os pontos de juno expostos esto:
chamada e execuo de mtodos;

instanciao de objetos;
acesso a atributos;
manuseio de excees.
Os aspectos de controle de acesso deste trabalho utilizam pontos de juno referente

execuo dos mtodos dos agentes responsveis pelo envio e/ou recebimento de mensagens.
Todos os pontos de juno possuem um contexto associado a eles, por exemplo, uma
chamada a um ponto de juno de um mtodo tem o objeto que realizou a chamada, o objeto
alvo e os argumentos do mtodo disponveis para o contexto.
Pontos de atuao definem, ou melhor, capturam pontos de juno em um fluxo de um
programa (LADDAD, 2003); so estruturas utilizadas para sinalizar o local e o momento de
atuao dos aspectos no programa (FIGUEIREDO, 2006).
Uma vez identificado um ponto de juno, o ponto de atuao utilizado para
especificar regras de combinao envolvendo pontos de juno e estas regras sero utilizadas
pelos aspectos para realizar um bloco de cdigo antes ou depois da execuo de um ou mais
pontos de juno (LADDAD, 2003).
Um ponto de atuao definido atravs de um ou mais designador de ponto de
atuao (Pointcut Designator, PCD). Existem diversos PCDs predefinidos na linguagem, que
30
Traduo do termo em ingls exception.
63
so conhecidos como PCDs primitivos. A Tabela 5.1 exibe apenas os que foram utilizados
neste trabalho.
Tabela 5.1 PCDs primitivos utilizados.

Designadores Descrio
args Expem ou limitam os argumentos de um ponto de juno para
o ponto de atuao
call Chamada de um mtodo ou construtor
execution Execuo de um mtodo ou construtor
within Captura um ponto de juno de um determinado tipo
A palavra-chave pointcut usada para definir que um ou mais PCDs constituem um

ponto de atuao e de maneira semelhante declarao de mtodos no Java, possvel utilizar
modificadores de acesso como o public e o private.
Um ponto de atuao pode ser classificado como: nomeado ou annimo. O ponto de
atuao nomeado um elemento que pode ser referenciado em muitos lugares fazendo dele
um elemento reutilizvel. J o annimo semelhante classe annima da OO, ou seja,
definido no lugar em que utilizado, como uma parte de um atuador ou para definio de
outro ponto de atuao.
Pelo fato do ponto de atuao annimo ser definido somente no momento de sua
utilizao seu reuso fica inviabilizado e consequentemente, na prtica, seu uso no
recomendado quando o cdigo da declarao do ponto de atuao complexo.
O atuador uma estrutura parecida com um mtodo da OO; atravs dele definido em
que momento e como o aspecto ir atuar no ponto de juno. Ele auxilia na questo do o que
fazer ao definir o comportamento a ser executado pelo aspecto nos pontos de juno
associados. A estrutura do atuador designa a semntica comportamental do aspecto
(FIGUEIREDO, 2006).
Existem trs tipos de atuadores no AspectJ: atuador do tipo anterior, posterior e de
contorno.
O atuador do tipo anterior, utilizado atravs da palavra-chave before, define que o
bloco de cdigo do atuador deve ser executado antes da execuo do ponto de atuao.
O atuador do tipo posterior, usado atravs da palavra-chave after, define que o bloco
de cdigo do atuador deve ser executado depois da execuo do ponto de atuao. Existem
64
trs variaes deste atuador que esto relacionadas execuo do ponto de atuao, que pode
ter terminado normalmente, gerado uma exceo ou terminado normalmente ou no.
O atuador do tipo de contorno, utilizado atravs da palavra-chave around, utilizado
para substituir ou no a execuo do bloco de cdigo do ponto de atuao pelo bloco de
cdigo do atuador, portando ele pode ser utilizado para desviar o fluxo de execuo de um
programa.
Os aspectos no AspectJ so construes similares a classes, que encapsulam, alm dos
atributos e mtodos convencionais, atuadores e PCDs. SantAnna (2004) define o aspecto
como a unidade de modularidade para interesses transversais onde cada aspecto encapsula
uma funcionalidade que atravessa outras classes do programa.
possvel verificar a aplicao desta ideia pela anlise dos aspectos desta arquitetura
que encapsulam a funcionalidade de controle de acesso que atravessa as classes que
representam os agentes.
As vrias maneiras de escrever um aspecto e associ-lo ao cdigo principal da
aplicao esto diretamente relacionadas ao interesse ao qual ser implementado atravs do
aspecto. Um aspecto pode estar escrito em seu prprio arquivo, semelhante s classes Java
que so escritas em arquivos com seu nome ou podem estar escritos no mesmo arquivo de
uma classe.
O Quadro 5.2 apresenta o SecurityAspect como um exemplo de aspecto. Atravs dele
possvel observar a semelhana da estrutura de um aspecto com uma classe Java e as
utilizaes dos elementos discutidos nesta seo como o ponto de juno, ponto de atuao e
atuadores.
65
Quadro 5.2 Exemplo de aspecto.
5.2.2. Aspectos de autenticao
O interesse de autenticao modularizado por trs aspectos: AuthenticationAspect,

ProactiveAuthenticationAspect e ReactiveAuthenticationAspect.
O aspecto AuthenticationAspect o aspecto ancestral da hierarquia de aspectos de
autenticao; ele implementa atravs da utilizao do Heimdall, a funcionalidade de
autenticao de agentes que utilizada pelos seus descendentes.
O aspecto ProactiveAuthenticationAspect promove a autenticao dos agentes do
ambiente interno assim que estes so configurados e desta forma, no preciso que estes
agentes tenham que realizar o esforo desnecessrio de enviar uma mensagem ao agente
Supervisor solicitando sua autenticao, pois ela ocorre automaticamente. Para que esta
66
estratgia seja vivel preciso que os agentes sejam modelados de forma a possurem como
propriedades as informaes necessrias para sua autenticao: o usurio e a senha. Desta
forma este aspecto pode capturar estas informaes para serem utilizadas no processo de
autenticao. A Figura 5.4 ilustra a atuao proativa deste aspecto representado pelo
losango nos agentes do ambiente interno. possvel notar tambm que somente o aspecto
lida diretamente com o interesse de autenticao atravs do Heimdall ilustrado pelo circulo
hachurado contido no aspecto .
Figura 5.4 Ilustrao da atuao do aspecto ProactiveAuthenticationAspect.
O aspecto ReactiveAuthenticationAspect atua no agente Supervisor interceptando as

mensagens que este recebe dos agentes que esto num ambiente externo. Esta forma de
autenticao entendida como reativa, pois decorrente de uma solicitao de autenticao
ao contrrio da proativa onde realizada automaticamente.
O agente Supervisor serve apenas como uma referncia para os agentes, pois todo
processo de autenticao realizado pelo aspecto. Desta forma, a autenticao realizada sem
a necessidade do agente Supervisor lidar com este interesse.
A Figura 5.5 representa graficamente a atuao deste aspecto no agente Supervisor.
Antes que qualquer mensagem seja percebida pelo sensor deste agente, interceptada por este
aspecto (Figura 5.5, a). Se a mensagem for um pedido de autenticao enviada por outro
67
agente, ou seja, se a mensagem uma ao do tipo SolicitarAutenticacaoAction, este aspecto

realiza o processo de autenticao do agente emissor (Figura 5.5, b), caso contrrio o fluxo de
processamento da mensagem devolvido para o Supervisor. Caso a autenticao tenha sido
mal sucedida, este aspecto faz com que um atuador do agente Supervisor emita uma
mensagem do tipo InformarAcessoNegadoAction ao agente solicitante da autenticao (Figura
5.5, c), onde especificado que ocorreu um erro na autenticao do agente.
Figura 5.5 Representao grfica da atuao do aspecto ReactiveAuthenticationAspect.
5.2.3. Aspectos de controle de acesso
O interesse de controle de acesso modularizado por trs aspectos:

AccessControlAspect, ProactiveAccessControlAspect e ReactiveAccessControlAspect.
O aspecto AccessControlAspect o aspecto ancestral da hierarquia de aspectos de
controle de acesso, ele implementa atravs da utilizao do Heimdall a funcionalidade de
controle de acesso de agentes que utilizada pelos seus descendentes.
Numa viso geral, os aspectos ProactiveAccessControlAspect e
ReactiveAccessControlAspect, promovem o controle de acesso dos agentes ao interceptar as
mensagens FIPA ACL e analisar as permisses de acesso dos envolvidos na troca de
mensagens.
68
Para que esta estratgia seja vivel preciso que para cada ao passvel de execuo
pelos agentes, existam as permisses associadas. Pois estes aspectos analisam os parmetros
sender, receiver e content da mensagem para verificar se o agente emissor contido no
parmetro sender e receptor contido no parmetro receiver , possuem permisso para
trabalharem com a ao contida no parmetro content .
O aspecto ProactiveAccessControlAspect intercepta e analisa as mensagens que os
atuadores dos agentes situados no ambiente interno enviam para outros agentes. A Figura 5.6
representa graficamente esta ao.
Assim que um atuador do agente emissor acionado para enviar uma mensagem, o
aspecto a intercepta (Figura 5.6, a) e atravs dos valores dos parmetros sender, receiver e
content verifica se os agentes emissor e receptor possuem permisso para trabalharem com a
ao desejada (Figura 5.6, b). Se ambos possuem as devidas permisses, ento o processo de
envio continuado e a mensagem entregue (Figura 5.6, c). Caso contrrio, este processo
abortado e o tratamento deste erro por falta de permisso executado (Figura 5.6, d).
Figura 5.6 Representao grfica da atuao do aspecto ProactiveAccessControlAspect.

69
Devido a atuao proativa deste aspecto, no efetivado no sistema a situao de um

agente solicitar uma ao a outro sendo que um dos envolvidos na troca de mensagem no
possui permisso para trabalhar com esta ao. Desta forma, alm da separao do interesse
alcanada pela utilizao do aspecto evitado o esforo desnecessrio do envio e recebimento
de mensagem por parte dos agentes, pois somente ocorre a troca de mensagens vlidas.
O aspecto ReactiveAccessControlAspect trabalha de forma semelhante ao anterior, no
entanto, ao contrrio do ProactiveAccessControlAspect ele atua nos sensores ao invs de agir
sobre os atuadores do agente. Ele intercepta e analisa as mensagens que os sensores dos
agentes situados no ambiente interno recebem dos agentes localizados num ambiente externo.
Este processo ilustrado pela Figura 5.7 e explicado a seguir.
Figura 5.7 Ilustrao da atuao do aspecto ReactiveAccessControlAspect.

70
Como no possvel realizar o controle de acesso de forma proativa, ou seja, logo no

envio de uma mensagem de um agente externo, esta mensagem interceptada (Figura 5.7, a)
e analisada (Figura 5.7, b) por este aspecto antes que seja percebida pelo sensor do agente
receptor. Se tanto o agente emissor quanto o receptor possurem a permisso necessria para a
ao, a mensagem recebida normalmente pelo receptor (Figura 5.7, c). Caso contrrio, este
aspecto far com que o sensor do agente receptor no perceba a mensagem e em seguida
acionar um atuador do agente Supervisor de modo que envie uma mensagem do tipo
InformarAcessoNegadoAction para o emissor, onde informada a falta de permisso (Figura
5.7, d).
Este captulo apresentou as principais decises que foram tomadas para a

implementao do controle de acesso RBAC na arquitetura do agente. Foi abordada a
aplicao do conceito de papis em agentes e sua relao com o controle de acesso baseado
em papis, o arcabouo JADE e sua importncia para esta arquitetura e, por fim, as camadas
da arquitetura do agente e seus principais componentes e aspectos responsveis pela aplicao
e separao do controle de acesso RBAC nos agentes.
71
6. Testes para Verificao do Controle de Acesso
Qualquer falha na implementao do controle de acesso pode colocar em risco a

efetividade de uma poltica de controle de acesso. Por isso, vital assegurar atravs de testes
que sua implementao est em conformidade com a poltica de segurana especificada
(HUANG et al., 2009).
Myers (2004) define o teste de software como um processo, ou uma srie de
processos, definidos para garantir que o cdigo do sistema faz aquilo que foi construdo para
fazer e nada, alm disto. Ele tambm afirma que este processo deve ser executado com a
inteno de encontrar erros no programa.
De forma semelhante, Pressman (2006) declara que o teste de software um elemento
frequentemente citado como verificao e validao. A verificao se refere ao conjunto de
atividades que garantem que o software tenha implementado corretamente uma funo
especfica. E a validao se refere a um conjunto de atividades diferentes que do garantia de
que o sistema construdo atende aos requisitos do cliente. Todavia, o autor observa que existe
uma forte divergncia de opinio sobre quais tipos de teste constituem a validao, pois
alguns autores consideram que todo teste verificao e que a validao ocorre quando
requisitos so revisados e aprovados.
Para a verificao da implementao proposta neste trabalho, o teste baseado em
poltica de segurana (HWANG et al., 2008) o indicado pois, conforme descrito pelos
autores, existem duas motivaes para a conduo deste teste: (I) assegurar que a
especificao da poltica de segurana est correta e (II) assegurar a conformidade entre a
poltica especificada e sua implementao.
Segundo Martin (2006), o teste da poltica de segurana funciona de forma anloga ao
teste de sistema. A Figura 6.1 ilustra esta analogia: as entradas para o teste so as requisies
de acessos e as sadas so as respostas de acesso. A execuo do teste ocorre quando uma
requisio de acesso avaliada pelo mecanismo de controle de acesso de acordo com a
poltica de segurana implementada pelo mesmo. Desta forma, possvel verificar a
conformidade entre a poltica de segurana e o mecanismo que a implementa atravs da
inspeo das requisies, respostas e respostas esperadas.
72
Figura 6.1 Analogia entre teste de sistema e teste de poltica de segurana.

Fonte: Adaptado de Martin (2006)
Com esta abordagem possvel aumentar a certeza de que a poltica de segurana e

sua implementao por um mecanismo esto corretas. Ao assumir que a poltica de segurana
est especificada de forma correta, o elemento a ser testado passa a ser a sua implementao,
que no caso deste trabalho a arquitetura para controle de acesso proposta.
Hwang et al. (2008) classificam os testes baseados em poltica de segurana em dois
tipos. No primeiro, o artefato a ser testado a poltica de controle de acesso e seu principal
objetivo assegurar que ela foi especificada corretamente. No segundo tipo, o artefato a ser
testado a implementao da poltica, ou melhor, do controle de acesso, e o objetivo principal
assegurar a conformidade entre a poltica especificada e sua implementao.
Similarmente, Huang et al. (2009) definem este segundo tipo de teste como teste de
controle de acesso e o classificam em dois tipos: funcional e adversrio.
A responsabilidade do teste funcional de controle de acesso31 determinar se a
implementao do controle de acesso est funcionando em conformidade com a poltica de
segurana especificada. J o teste adversrio de controle de acesso32 realizado para
determinar se esta implementao contm alguma vulnerabilidade para a realizao deste
teste, acessos ilegais so simulados .
Em virtude de possurem como objetivo o teste da implementao do controle de
acesso, os testes funcional e adversrio citados no pargrafo anterior, tornam-se adequados
31
Traduo do termo em ingls functional access control test.
32
Traduo do termo em ingls adversarial access control test.
73
para realizar a verificao do controle de acesso RBAC implementado na arquitetura dos

agentes.
6.1. Implementao para o Teste
Para validar a arquitetura de controle de acesso proposta por este trabalho, definida no
captulo anterior, elaborou-se um SMA desenvolvido com o intuito de viabilizar as
simulaes necessrias para efetuar os testes de controle de acesso.
Este sistema est distribudo em dois ambientes: o interno e o externo. Conforme j
definido no captulo anterior, como ambiente interno entende-se o local onde o controle de
acesso est implementado e por consequncia o agente Supervisor tambm est presente j, o
externo, um ambiente que interage com o interno, embora sem a presena do controle de
acesso.
A distribuio dos agentes em dois ambientes distintos necessria para a realizao
das simulaes, pois a arquitetura proposta utiliza aspectos diferentes para tratar as
requisies de cada ambiente. Aspectos proativos tratam de requisies de agentes que esto
num ambiente interno enquanto os reativos daqueles que esto no externo. O diagrama de
instalao33 apresentado pela Figura 6.2 exibe estes ambientes e seus respectivos agentes
criados para a realizao das simulaes dos cenrios que so apresentados no decorrer deste
captulo.
A esquerda da Figura 6.2, est representado graficamente o ambiente interno
apelidado de hospital01-platform , ele abriga o agente Supervisor e os demais agentes
prprios deste sistema: Arquivista, Atendente, Enfermeiro, Diabetologista e Paciente. A
direita est o ambiente externo apelidado de hospital02-platform , o qual uma reproduo
parcial do ambiente interno e contm apenas dois agentes: o Paciente e o Atendente.
33
Traduo do termo em ingls deployment diagram.
74
Figura 6.2 Diagrama de instalao.
O funcionamento deste sistema, ou melhor, a interao entre os agentes que esto no

ambiente interno demonstrada pelo diagrama de sequncia exibido pela Figura 6.3 e
explicado a seguir.
Figura 6.3 Diagrama de sequncia das interaes dos agentes executados no ambiente interno.
Aps o agente Paciente ser criado, ele solicita seu registro ao agente Atendente e este,
por sua vez, solicita que o agente Arquivista efetive este registro persistindo os dados deste
paciente numa base de dados. O agente Enfermeiro pode ento solicitar ao Arquivista, um
75
agente Paciente registrado no sistema para que possa realizar a medio de glicemia. Aps a
glicemia ser medida, ou seja, ser comunicada pelo agente Paciente ao Enfermeiro o qual
solicita ao Arquivista a atualizao desta informao na base dados e tambm, de acordo com
um critrio de valores de glicemia, pode solicitar ao Diabetologista que analise o valor
coletado. Dependendo do valor coletado o agente Diabetologista libera o Paciente, ou seja,
solicita ao agente Arquivista que o remova da base de dados e avisa o fato ao Paciente
fazendo com que este no faa mais parte da comunidade de agentes.
De forma similar a apresentada anteriormente, as interaes entre os agentes
executados no ambiente externo com aqueles do interno so demonstradas pelo diagrama de
sequncia exibido pela Figura 6.4. Conforme pode ser observado pela anlise deste diagrama,
a interaes so as mesmas expostas pelo diagrama de sequncia anterior, mostrado pela
Figura 6.3 com exceo das duas primeiras .
Figura 6.4 Diagrama de sequncia das interaes dos agentes executados no ambiente externo.
Isto ocorre porque o ambiente externo uma reproduo parcial do interno. Neste
ambiente somente dois agentes so executados, o Paciente e o Atendente e estes dois
interagem com os demais do ambiente interno para realizarem suas tarefas e por isto preciso
76
que sejam autenticados. Consequentemente, a primeira ao que executam um pedido de

autorizao para o agente Supervisor representada no diagrama pelo envio da mensagem
SolicitarAutenticacaoAction . O restante das interaes so as mesmas explicadas
anteriormente.
Alm dos agentes distribudos em dois ambientes, para realizao dos testes
necessrio definir a poltica de controle de acesso a qual estes agentes esto submetidos. Por
isso, uma poltica de controle de acesso especificada de forma a definir os usurios, papis e
permisses atribudos aos agentes do sistema em questo.
A Tabela 6.1 exibe os elementos desta poltica de controle de acesso RBAC. A
primeira coluna contm os usurios que so vinculados aos agentes, na coluna do meio esto
os papis que cada usurio desempenha e na ltima coluna esto as permisses atribudas aos
papis. Conforme discutido no captulo quatro, no contexto dos SMAs as permisses so
concedidas sobre as aes dos agentes e no acerca dos recursos que o sistema possa oferecer.
Tabela 6.1 Poltica de controle de acesso RBAC.

Usurio Papel Permisso
AtualizarGlicemia
InformarPaciente
arquivista Arquivista LiberarPaciente
RegistrarPaciente
SolicitarPaciente
atendente Atendente RegistrarPaciente
InfomarAcessoNegado
diabetologista Diabetologista AvisarDiabetologista
LiberarPaciente
AtualizarGlicemia
AvisarDiabetologista
enfermeiro Enfermeiro InformarGlicemia
InformarPaciente
SolicitarGlicemia
SolicitarPaciente
InformarGlicemia
paciente Paciente LiberarPaciente
RegistrarPaciente
SolicitarGlicemia
InfomarAcessoNegado
supervisor Supervisor InfomarAcessoNegado
SolicitarAutenticacao
77
6.2. Testes e Simulaes
Para a validao da implementao de controle de acesso proposta por este trabalho

foram realizados os testes funcional e adversrio propostos por Huang et al. (2009). Para
simular as situaes possveis de requisio de acesso por um agente, quatro cenrios foram
definidos conforme exibido pela Tabela 6.2.
Tabela 6.2 Cenrios de teste.

Cenrio Descrio
C1 Execuo de uma ao por um agente que no est autenticado
C2 Execuo de uma ao por um agente cuja autenticao foi mal sucedida
C3 Execuo de uma ao por um agente autenticado e que possui a permisso
necessria
C4 Execuo de uma ao por um agente autenticado e que no possui a permisso
necessria
Os testes adversrios so realizados pelas simulaes dos cenrios C1 e C2. O

primeiro cenrio C1 visa verificar se o controle de acesso implementado capaz de
impedir que um agente no autenticado execute uma ao. O segundo, testa a mesma situao,
porm aps o agente ter fracassado na tentativa de autenticao.
J os testes funcionais so executados atravs das simulaes dos cenrios C3 e C4. O
cenrio C3 verifica se um agente autenticado consegue executar uma ao a qual possui a
permisso necessria e por ltimo, o cenrio C4 testa se controle de acesso capaz de impedir
que um agente j autenticado execute uma ao a qual no possui permisso.
O mecanismo de controle de acesso, avalia atravs da atuao dos aspectos, tanto as
requisies de agentes que esto num ambiente interno quanto as que chegam de agentes
situados num ambiente externo. Portanto, necessrio que os quatro cenrios definidos
anteriormente sejam simulados a partir destes dois ambientes, pois desta maneira, alm de
erros no mecanismo de controle de acesso, eventuais falhas na implementao dos aspectos
tambm podem ser detectadas.
Desse modo, um total de oito testes foram definidos. Quatro, para testar as requisies
dos agentes situados no ambiente interno um para cada cenrio, identificados como Teste 1
at Teste 4 onde simulado a execuo da ao RegistrarPacienteAction pelo agente
Paciente. E, de maneira similar, quatro, para testar as requisies que chegam de agentes
78
localizados num ambiente externo identificados como Teste 5 at Teste 8 onde simulado
a execuo da ao RegistrarPacienteAction pelo agente Atendente.
A seguir esto descritos os testes, as simulaes executadas e os resultados obtidos.
Teste 1
O primeiro teste visa verificar se o controle de acesso implementado capaz de
impedir a execuo de uma ao por um agente localizado no ambiente interno cuja
autenticao no foi realizada. Ele realizado atravs de uma simulao onde o agente
Paciente, ainda no autenticado, executa a ao RegistrarPacienteAction. A Tabela 6.3
apresenta de forma sintetizada o cenrio, ambiente, agente, ao executada, elementos do
modelo RBAC utilizados e o resultado esperado deste teste.
Tabela 6.3 Descrio dos elementos utilizados para execuo do Teste 1.

Teste Teste 1
Cenrio C1
Tipo Adversrio
Ambiente Interno (hospital01-platform)
Agente
Requisio
Agente Paciente (paciente01)

Ao RegistrarPacienteAction
Usurio paciente
RBAC
Papel Paciente
Permisso RegistrarPaciente
Resultado esperado Acesso negado (Usurio no autenticado)
Para a realizao deste teste executada uma simulao onde o agente Paciente ainda
no autenticado executa a ao RegistrarPacienteAction. Para isto ocorrer, o ponto de atuao
do aspecto ProactiveAuthenticationAspect, responsvel por autenticar os agentes do ambiente
interno assim que so configurados, alterado de forma a no realizar a autenticao do
agente Paciente. Como consequncia, o aspecto ProactiveAccessControlAspect aborta o envio
da mensagem RegistrarPacienteAction do agente Paciente para o Atendente, pois o emissor
no est autenticado e por isto no pode executar qualquer ao no sistema. O Quadro 6.1
apresenta a sada para o console referente execuo desta simulao, onde possvel notar
que o aspecto ProactiveAccessControlAspect no permitiu ao agente Paciente enviar a
mensagem RegistrarPacienteAction ao Atendente.
79
Quadro 6.1 Resultado obtido pelo Teste 1.

...
ProactiveAccessControlAspect - (paciente01@hospital01-platform =>
atendente01@hospital01-platform):RegistrarPacienteAction
***** AGENTE NAO AUTENTICADO *****
***** agente: [paciente01@hospital01-platform] ou
[atendente01@hospital01-platform]
***** HeimdallException: User is not authenticated
...
Teste 2
O segundo teste verifica se o controle de acesso implementado capaz de impedir a
execuo de uma ao por um agente localizado no ambiente interno cuja autenticao foi
mal sucedida devido a informaes incorretas. Ele realizado atravs de uma simulao onde
o agente Paciente, no autenticado, executa a ao RegistrarPacienteAction. A Tabela 6.4
exibe de forma resumida os elementos utilizados na simulao para realizao deste teste.

Teste Teste 2
Cenrio C2
Tipo Adversrio
Agente
Requisio

Usurio paciente
RBAC
Papel Paciente
Resultado esperado Acesso negado (usurio no autenticado)
Nesta simulao, o agente Paciente alterado de forma a portar uma senha invlida
assim, no momento em que o aspecto ProactiveAuthenticationAspect realiza o procedimento
para autenticao deste agente, um erro gerado e este agente no autenticado. Em
decorrncia, o aspecto ProactiveAccessControlAspect aborta o envio da mensagem
RegistrarPacienteAction do agente Paciente para o Atendente, pois o emissor no est
autenticado e portanto no pode executar qualquer ao no sistema. O Quadro 6.2 apresenta a
sada para o console referente a execuo desta simulao. possvel notar que o aspecto
ProactiveAuthenticationAspect no realiza a autenticao do agente Paciente e em
80
decorrncia, o aspecto ProactiveAccessControlAspect impede que este agente envie a

mensagem ao Atendente.

...
ProactiveAuthenticationAspect - o agente [paciente01@hospital01-
platform] nao foi autenticado com o usuario: paciente
***** agente: [paciente01@hospital01-platform]
...
...
...
Teste 3
Neste teste verificado se o controle de acesso opera em conformidade com a poltica
de segurana, ou seja, se consegue conceder a execuo de uma ao a um agente localizado
no ambiente interno autenticado e que possui a permisso necessria. Ele realizado atravs
de uma simulao onde o agente Paciente, devidamente autenticado, executa a ao
RegistrarPacienteAction. A Tabela 6.5 apresenta de forma sucinta os elementos utilizados na
simulao para realizao deste teste.

Teste Teste 3
Cenrio C3
Tipo Funcional
Agente
Requisio

Usurio paciente
RBAC
Papel Paciente
Resultado esperado Acesso permitido
81
Nenhuma alterao no sistema foi necessria para realizar esta simulao, pois ela o
fluxo normal do sistema. O Quadro 6.3 apresenta a sada para o console referente sua
execuo. possvel notar que o aspecto ProactiveAuthenticationAspect autentica o agente
Paciente e a atuao do aspecto ProactiveAccessControlAspect no gera nenhum erro ao
avaliar as permisses dos agentes envolvidos na troca de mensagem.

...
platform] foi autenticado com o usuario: paciente
...
...
...
Teste 4
O quarto teste visa verificar se o controle de acesso implementado capaz de impedir
a execuo de uma ao por um agente localizado no ambiente interno autenticado e que
no possui a permisso necessria. realizado atravs de uma simulao onde o agente
Paciente, depois de autenticado, executa a ao RegistrarPacienteAction. A Tabela 6.6 exibe
de forma condensada o cenrio, ambiente, agente, ao executada, elementos do modelo
RBAC utilizados na simulao para realizao deste teste.

Teste Teste 4
Cenrio C4
Tipo Funcional
Agente
Requisio

Usurio paciente
RBAC
Papel Paciente
Resultado esperado Acesso negado (falta de permisso)
82
Nesta simulao, a poltica de controle de acesso foi alterada de forma a no permitir

que o agente Paciente possa executar a ao RegistrarPacienteAction, ou seja, a permisso
RegistrarPaciente do papel Paciente foi removida. Como resultado, aspecto
ProactiveAccessControlAspect aborta o envio da mensagem RegistrarPacienteAction do
agente Paciente para o Atendente. O Quadro 6.4 apresenta a sada para o console referente a
execuo desta simulao. possvel notar que apesar de autenticado pelo aspecto
ProactiveAuthenticationAspect, o agente Paciente impedido pelo aspecto
ProactiveAccessControlAspect de executar a ao RegistrarPacienteAction.
...
platform] foi autenticado com o usuario: paciente
...
...
***** ACESSO NEGADO *****
***** sem permissao para acao: (RegistrarPacienteAction)
...
Teste 5
O quinto teste possui como objetivo verificar se o controle de acesso implementado
capaz de impedir que uma ao executada por um agente localizado num ambiente externo e
no autenticado seja concluda, ou seja, a mensagem que representa esta ao no seja
percebida pelos sensores do agente receptor da mensagem. Neste teste verificada a atuao
do controle de acesso, ou melhor, dos aspectos de controle de acesso em relao aos agentes
situados no ambiente externo. realizado atravs de uma simulao onde o agente Atendente
localizado no ambiente externo , ainda no autenticado, executa a ao
RegistrarPacienteAction. A Tabela 6.7 apresenta de forma sintetizada o cenrio, ambiente,
agente, ao executada, elementos do modelo RBAC utilizados e o resultado esperado deste
teste.
83

Teste Teste 5
Cenrio C1
Tipo Adversrio
Ambiente Externo (hospital02-platform)
Agente Agente Atendente (atendenteExterno01)

Requisio
Usurio atendente
RBAC
Papel Atendente
Para esta simulao, o agente Atendente foi alterado de forma a no solicitar sua
autenticao ao agente Supervisor localizado no ambiente interno . Por isso, o aspecto
ReactiveAccessControlAspect impede que a mensagem RegistrarPacienteAction enviada pelo
Atendente seja percebida pelos sensores do agente Arquivista, pois o emissor da mensagem
no est autenticado e como decorrncia, ele no pode executar nenhuma ao no sistema. O
Quadro 6.5 apresenta a sada para o console referente execuo desta simulao.
...
ReactiveAccessControlAspect - (atendenteExterno1@hospital02-platform =>
arquivista01@hospital01-platform):RegistrarPacienteAction
***** agente: [atendenteExterno1@hospital02-platform] ou
[arquivista01@hospital01-platform]
...
...
ProactiveAccessControlAspect - (supervisor01@hospital01-platform =>
atendenteExterno1@hospital02-platform):InformarAcessoNegadoAction
...
Teste 6
Teste 6
Este teste verifica se o controle de acesso implementado capaz de impedir a
concluso de uma ao executada por um agente localizado no ambiente externo, cuja
autenticao foi mal sucedida devido a informaes incorretas . realizado atravs de uma
simulao onde o agente Atendente, no autenticado, executa a ao RegistrarPacienteAction.
84
A Tabela 6.8 exibe de forma resumida os elementos utilizados na simulao para realizao
deste teste.

Teste Teste 6
Cenrio C2
Tipo Adversrio
Agente
Requisio
Agente Atendente (atendenteExterno01)

Usurio atendente
RBAC
Papel Atendente
Nesta simulao, o agente Atendente foi alterado de forma a portar uma senha
invlida. Assim, no momento que o aspecto ReactiveAuthenticationAspect realiza o
procedimento para autenticao deste agente, um erro gerado e o agente no autenticado.
Como resultado, o aspecto ReactiveAccessControlAspect impede que a mensagem
RegistrarPacienteAction enviada pelo agente Atendente seja processada pelo Arquivista. O
Quadro 6.6 apresenta a sada para o console referente a execuo desta simulao onde
possvel verificar a atuao dos aspectos ReactiveAuthenticationAspect e
ReactiveAccessControlAspect.

...
ReactiveAuthenticationAspect - o agente [atendenteExterno1@hospital02-
platform] nao foi autenticado com o usuario: atendente
***** agente: [atendenteExterno1@hospital02-platform]
...
...
...
...
...
85
Teste 7
Neste teste verificado se o controle de acesso opera em conformidade com a poltica
de segurana, ou seja, se permite que uma ao executada por um agente localizado no
ambiente externo, autenticado e que possui a permisso necessria seja concluda. Ele
realizado atravs de uma simulao onde o agente Atendente, devidamente autenticado,
executa a ao RegistrarPacienteAction. A Tabela 6.9 apresenta de forma sucinta os
elementos utilizados na simulao para realizao deste teste.

Teste Teste 7
Cenrio C3
Tipo Funcional
Agente

Requisio
Usurio atendente
RBAC
Papel Atendente
Resultado esperado Acesso permitido
Nenhuma alterao foi realizada no sistema para esta simulao, pois ela o fluxo
normal do sistema. O Quadro 6.7 apresenta a sada para o console referente execuo desta
simulao. possvel notar que o aspecto ReactiveAuthenticationAspect autentica o agente
Atendente e em seguida o aspecto ReactiveAccessControlAspect atua sobre o agente receptor
da mensagem agente Arquivista e no gera nenhum erro, fato que indica o sucesso na
execuo da ao.

...
platform] foi autenticado com o usuario: atendente
...
...
...
86
Teste 8
O ltimo teste visa verificar se o controle de acesso implementado capaz de impedir
a concluso de uma ao executada por um agente localizado no ambiente externo,
autenticado e que no possui a permisso necessria . realizado atravs de uma simulao
onde o agente Atendente depois de autenticado, executa a ao RegistrarPacienteAction. A
Tabela 6.10 exibe de forma condensada o cenrio, ambiente, agente, ao executada,
elementos do modelo RBAC utilizados na simulao para realizao deste teste.

Teste Teste 8
Cenrio C4
Tipo Funcional
Agente
Requisio

Usurio atendente
RBAC
Papel Atendente
Resultado esperado Acesso negado (falta de permisso)
Para realizar esta simulao, a poltica de controle de acesso foi alterada de forma a
no permitir que o Atendente possa executar a ao RegistrarPacienteAction, ou seja, a
permisso RegistrarPaciente do papel Atendente foi removida. Em decorrncia, o aspecto
ReactiveAccessControlAspect impede que a mensagem RegistrarPacienteAction enviada pelo
agente Atendente seja processada pelo Arquivista. O Quadro 6.8 apresenta a sada para o
console referente execuo dessa simulao. possvel verificar que apesar do aspecto
ReactiveAuthenticationAspect autenticar o agente Atendente, o aspecto
ReactiveAccessControlAspect impede que a ao seja concluda ou melhor, impede que a
mensagem seja percebida pelo agente Arquivista devido a falta de permisso do emissor.
87

...
platform] foi autenticado com o usuario: atendente
...
...
ReactiveAccessControlAspect - (atendenteExterno1@hospital02-platform
=> arquivista01@hospital01-platform):RegistrarPacienteAction
***** ACESSO NEGADO *****
***** sem permissao para acao: (RegistrarPacienteAction)
...
...
6.3. Anlise dos Resultados
Atravs da anlise dos resultados obtidos por cada simulao, observou-se que as
respostas produzidas pelo controle de acesso implementado foram condizentes com os
resultados esperados. Isto evidencia que, dentro do conjunto de cenrios testados, a
implementao do controle de acesso na arquitetura dos agentes est operando de forma
correta.
Nota-se tambm, devido a utilizao dos aspectos, dois benefcios agregados a
implementao proposta: a separao do interesse de controle de acesso e uma provvel
economia do esforo computacional realizado pelos agentes que destinado ao
processamento de mensagens invlidas34.
A separao do interesse de controle de acesso explcita pelos prprios aspectos que
atravs da atuao nos sensores e atuadores dos agentes faz com que o controle de acesso
esteja presente sem que eles lidem diretamente com este interesse. Conforme pode ser
inspecionado nos cdigos-fonte dos aspectos Apndice A .
A economia do esforo computacional que destinado ao processamento de
mensagens invlidas possui evidncia de ser alcanada devido a atuao dos aspectos de
controle de acesso. O ProactiveAccessControlAspect atravs de sua influncia nos atuadores
34
Entende-se por mensagem invlida qualquer mensagem onde um dos envolvidos agente emissor ou
receptor no possua permisso para lidar com a ao em questo.
88
dos agentes aborta o envio de mensagens invlidas. J o ReactiveAccessControlAspect faz

com que uma mensagem invlida enviada por um agente situado num ambiente externo no
seja percebida pelo sensor do agente receptor. Desse modo poupado o esforo
computacional do agente receptor para processar uma mensagem cuja permisso de um dos
envolvidos inexistente; fato que torna a troca de mensagem ilegtima.
89
7. Concluso
A implementao do controle de acesso na arquitetura do agente uma maneira de

mitigar os riscos de segurana relativos a incidentes causados pelo acesso no autorizado.
Dentre os modelos de controle de acesso existentes, o RBAC tem sido aplicado em
SMA de forma a integrar harmonicamente o controle de acesso baseado em papis com a
coordenao e organizao dos agentes modelados segundo o conceito de papis.
Para utilizao deste modelo num SMA trs adaptaes so necessrias: a primeira
que neste contexto, a entidade Usurio deve ser o prprio agente do sistema, a segunda a
atribuio dos papis diretamente a um agente, de acordo com os papis que este desempenha
e, por ltimo, a concesso de permisses deve ser feita sobre as aes e percepes dos
agentes e no sobre dos recursos do sistema (VIROLI et al., 2007).
Apesar dessas adaptaes no serem complexas, a implementao do controle de
acesso RBAC na arquitetura do agente pode gerar devido a sua natureza transversal
sintomas indesejveis no sistema como o emaranhamento e espalhamento de cdigo que
juntos, impactam negativamente na compreenso, reuso e evoluo de projetos orientados a
agentes. Estes dois sintomas decorrentes da m modularizao so evitados com a utilizao
da POA, pois este paradigma promove a separao de interesses transversais em mdulos
separados, chamados aspectos.
Neste contexto, este trabalho contribui com uma proposta para controle de acesso
RBAC na arquitetura do agente que promove alm do controle de acesso dos agentes, a
separao avanada desse interesse. Tendo como fundamento esta abordagem em que a
separao de interesses inerente ao controle de acesso, a arquitetura estrutura estes dois
conceitos separao de interesses e controle de acesso em camadas, onde cada uma
representa um nvel de abstrao.
Na camada de controle de acesso a autenticao e controle de acesso RBAC so
modularizados por um mecanismo intitulado Heimdall criado para este fim, enquanto a
utilizao destas funcionalidades pelos agentes realizada por meio de aspectos elementos
da camada de aspectos de segurana que viabilizam a separao avanada deste interesse.
atravs da utilizao dos aspectos que as funcionalidades de autenticao e controle de acesso
so implementadas e depois integradas com os agentes.
Provavelmente a maior contribuio deste trabalho est na exposio da forma de
como os aspectos podem promover o controle de acesso nos agentes. A atuao dos aspectos
90
diretamente nos sensores e atuadores dos agentes mostrou-se eficiente, pois possibilitou alm
do controle de acesso, a evidncia de economia do esforo computacional que seria destinado
ao processamento de mensagens invlidas.
Grande parte desta economia resultado da atuao proativa dos aspectos
ProactiveAuthenticationAspect e ProactiveAccessControlAspect que devido a forma de
atuao acabam reduzindo o fluxo de mensagem entre agentes.
O trabalho apresentado nesta dissertao pode ser continuado atravs de um estudo
quantitativo para avaliar o quanto a estratgia de utilizar aspectos nos sensores e atuadores
dos agentes para o controle de acesso influencia no fluxo de mensagens entre agentes de
maneira a impactar no desempenho geral da comunidade de agentes.
Como trabalhos futuros a presente dissertao sugere um estudo da utilizao da POA
para garantir a integridade de mensagens trocadas entre os agentes. Esta integridade pode ser
implementada atravs de aspectos responsveis por encriptar uma mensagem assim que ela
enviada por um atuador do agente emissor e outros que a desencriptam antes que seja
percebida pelo sensor do receptor.
Outra proposta visa realizar uma comparao de desempenho entre a implementao
do controle de acesso RBAC em agentes com a POA em paridade com outras implementaes
que no utilizam esta abordagem.
Finalmente, a ltima proposta de trabalho uma anlise aprofundada do desempenho

geral do sistema obtido pela utilizao do agente Supervisor em contraposio a outras
estratgias para autenticao dos agentes.
91
Referncias
AKSIT, Mehmet; WAKITA, Ken; BOSCH, Jan; BERGMANS, Lodewijk; YONEZAWA,

Akinori. Abstracting Object Interactions Using Composition Filters. In: Proceedings of
the Workshop on Object-Based Distributed Programming, ECOOP'93, 1993
ASPECTCPP. Pgina oficial do projeto AspectC++. Disponvel em:

<http://www.aspectc.org>. Acessado em: 21/06/2009.
ASPECTJ. Pgina oficial do projeto AspectJ. Disponvel em:

<http://www.eclipse.org/aspect>. Acessado em: 22/06/2009.
ASPECTLUA. Pgina oficial do projeto AspectLua. Disponvel em:

<http://luaforge.net/projects/aspectlua>. Acessado em: 21/06/2009.
ASPECTNET. Pgina oficial do projeto Aspect.NET. Disponvel em:

<http://www.facultyresourcecenter.com/curriculum/pfv.aspx?ID=6801>. Acessado em:
21/06/2009.
BELLIFEMINE, Fabio; CAIRE, Giovanni; TRUCCO, Tiziana; RIMASSA, Giovanni. JADE

Programmers Guide, 2003.
BELLIFEMINE, Fabio; CAIRE, Giovanni; GREENWOOD, Dominie. Developing Multi-

Agent Systems with JADE, 2007.
BODKIN, Ron. Enterprise Security Aspects. In: International Conference on Aspect-

Oriented Software Development (AOSD), 2004.
BUSCHMAN, Frank; MEUNIER, Regine; ROHNERT, Hans; SOMMERLAD, Peter; STAL,

Michael. Pattern-Oriented Software Architecture Volume 1: A System of Patterns. John
Wiley & Sons, 1996.
CABRI, Giacomo; LEONARDI, Letizia; ZAMBONELLI, Franco. Modeling Role-based

Interactions for Agents. In: Proceedings of the OOPSLA 2002 Workshop on Agent-Oriented
Methodologies, 2002.
CABRI, Giacomo; FERRARI, Luca; ZAMBONELLI, Franco. Role-based Approaches for

Engineering Interactions in Large-scale Multi-Agent Systems. Software engineering for
multi-agent systems II: research issues and practical applications, vol. 2940, 2003.
CABRI, Giacomo; FERRARI, Luca; LEONARDI, Letizia. Embedding JAAS in Agent

Roles to Apply Local Security Policies. Third International Conference on Principles and
Practice of Programming Java (PPPJ), 2004.
CABRI, Giacomo; FERRARI, Luca; LEONARDI, Letizia. Applying Security Policies

Through Agent Roles: a JAAS Based Approach. Science of Computer Programming,
Elsevier, Amsterdam-NL, 2005.
CAIRE, Giovanni. JADE Tutorial: JADE Programming for Beginners. 2003

92
CAMILO, Jos Augusto Peanha. FTQL: Um Modelo Para o Estudo de Organizaes, do

Ponto de Vista de Controle de Acesso, Baseado em Funes, Tarefas e Qualificaes. So
Jos dos Campos, 2001. Dissertao (Mestrado) - Instituto Tecnolgico de Aeronutica.
Diviso de ps-graduao.
CONCEIO, Heraldo Vieira D.; SILVA, Roberto de Oliveira. Aplicabilidade do Modelo

RBAC no Controle de Acesso para a Rede Sem Fio do Senado Federal, Distrito Federal,
2006. Monografia de Especializao Universidade de Braslia, Faculdade de Tecnologia.
Departamento de Engenharia Eltrica.
CSI. Computer Crime & Security Survey, The latest results from the longest-running
project of its kind, 2008. Disponvel em:
<http://i.cmpnet.com/v2.gocsi.com/pdf/CSIsurvey2008.pdf>. Acessado em: 17/07/2009.
DIJKSTRA, E. A Discipline of Programming. Prentice-Hall, Englewood Cliffs, New Jersey,

1976.
ECLIPSE. Pgina oficial da fundao eclipse. Disponvel em: <http://www.eclipse.org>.

Acessado em: 22/06/2009.
FERBER, Jacques. Multi-agent Systems: An Introduction to Distributed Artificial

Intelligence, Addison-Wesley, 1999.
FIGUEIREDO, Eduardo Magno Lages. Uma abordagem quantitativa para

desenvolvimento de software orientado a aspectos. Rio de Janeiro, 2006. Dissertao
(Mestrado) - Pontifcia Universidade Catlica do Rio de Janeiro. Departamento de
Informtica.
FININ, Tim; FRITZSON, Richard; MCKAY, Don; MCENTIRE, Robin. KQML as an agent
communication language. In: Proceedings of the third international conference on
Information and knowledge management (CIKM '94), New York, NY, USA, 1994.
FIPA. Pgina oficial da organizao FIPA. Disponvel em: <http://www.fipa.org>.

FIPA. FIPA ACL Message Structure Specification, 2002. Disponvel em:

<http://www.fipa.org/specs/fipa00061>. Acessado em: 22/06/2009.
FRANKLIN, Stan; GRAESSER, Art. Is it an agent, or just a program?: A taxonomy for

autonomous agents. Proceedings of Third International Workshop on Agent Theories,
Architectures, and Languages (ATAL'96), 1996.
GARCIA, Alessandro Fabrcio. Objetos e agentes: uma abordagem orientada a aspectos.

Rio de Janeiro, 2004. Tese (doutorado) - Pontifcia Universidade Catlica do Rio de Janeiro,
Departamento de Informtica.
GARCIA, Alessandro; CHAVEZ, Christina; CHOREN, Ricardo. Enhancing Agent-

Oriented Models with Aspects. In: Proceedings of the 5th International Conference on
Autonomous Agents and Multi-Agent Systems (AAMAS06), 2006.
93
GENESERETH, Michael. R. Knowledge Interchange Format. Proceedings of the Second

International Conference on the Principles of Knowledge Representation and Reasoning,
1991.
GIRARDI, Rosario; FERREIRA, Steferson Lima Costa. Arquiteturas de software baseadas

em agentes. Universidade Federal do Maranho, Departamento de Informtica, 2002.
GONG, Li; ELLISON, Gary; DAGEFORDE, Mary. Inside Java 2 Platform Security.
Second Edition, Prentice Hall, 2003.
HARRISON, William; OSSHER, Harold. Subject-Oriented Programming - A Critique of

Pure Objects. In: Proceedings of the ACM Conference on Object-Oriented Programming
Systems, Languages, and Applications (OOPSLA'93), 1993.
HUANG, Chao; SUN, Jianling; WANG, Xinyu; SI, Yuanjie. Selective Regression Test for
Access Control System Employing RBAC. In: Proceedings of the 3rd International
Conference and Workshops on Advances in Information Security and Assurance (ISA '09),
2009.
HUHNS, Michael N.; SINGH, Munindar P. Readings in Agents. Morgan Kaufmann, CA,
EUA, 1 edio, 1997.
HUHNS, Michael N.; STEPHENS, Larry M. Multiagent systems and societies of agents.
Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. MIT
Press, Cambridge, MA, USA, 1999.
HRSCH, Walter; LOPES, Cristina Videira. Separation of Concerns. College of Computer

Science, Northeastern University, Boston, 1995.
HWANG, JeeHyun; MARTIN, Evan; XIE, Tao; HU, Vincent C. Policy-Based Testing.
Department of Computer Science, North Carolina State University, Raleigh, 2008.
ITSEC. Information Technology Security Evaluation Criteria (ITSEC). Luxembourg:

Office for Official Publications of the European Communities, 1991.
INCITS. InterNational Committee for Information Technology. Pgina oficial do comit.

Disponvel em: <http://www.incits.org>. Acessado em: 22/06/2009.
JAAS. Java Authentication and Authorization Service. Disponvel em:

<http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html>.
JANSEN, Wayne; KARYGIANNIS, Tom. Mobile agent security. NIST Special Publication
800-19, National Institute of Standards and Technology, Computer Security Division, 2000.
JAVA. Pgina oficial da linguagem de programao Java. Disponvel em:

<http://java.sun.com>. Acessado em: 22/06/2009.
94
JENNINGS, Nicholas R.; SYCARA Katia.; WOOLDRIDGE Michael. A Roadmap of

Agent Research and Development. In: Autonomous Agents and Multi-Agent Systems
Journal. Kluwer Academic Publishers, Boston, Volume 1, Issue 1, p. 7-38, 1998.
JENNINGS, Nicholas R. Agent-Oriented Software Engineering. In: Proceedings of the

12th International Conference on Industrial and Engineering Applications of Artificial
Intelligence, 1999.
KENDALL, E.; KRISHNA, P.; PATHAK, C.; SURESH, C. A Framework for Agent
Systems. Implementing Application Frameworks Object-Oriented Frameworks at Work,
John Wiley & Sons, 1999.
KENDALL, Elizabeth A. Role model designs and implementations with aspect-oriented

programming. In: Proceedings of the 14th ACM SIGPLAN conference on Object-oriented
programming, systems, languages, and applications. Denver, Colorado, United States, 1999.
KICZALES, Gregor; IRWIN, John; LAMPING, John; LOINGTIER, Jean-Marc; LOPES,

Cristina Videira; MAEDA, Chris; MENDHEKAR, Anurag. Aspect-Oriented Programming.
In: ECOOP 97, 1997.
KICZALES, Gregor; HILSDALE, Eric; HUGUNIN, Jim; KERSTEN, Mik; PALM, Jeffrey;
GRISWOLD, William G. An Overview of AspectJ. In: 15th European Conference on
Object-Oriented Programming (ECOOP 01), 2001.
KNAPIK, Michael; JOHNSON, Jay. Developing Intelligent Agents for Distributed

Systems: Exploring Architectures, Techniques, and Applications, Osborne/McGraw-Hill,
1997.
LADDAD, Ramnivas. AspectJ in Action, Pratical Aspect-Oriented Programming. 1. ed.,

Greenwich: Manning, 2003.
LEHTINEN, Rick; RUSSEL, Deborah; GANGEMI, G.T. Computer Security Basics.

Second Edition, O'Reilly Media, 2006.
LIEBERHERR, Karl J. Adaptive Object-Oriented Software: The Demeter Method with

Propagation Patterns. PWS Publishing Company, 1996.
LIEBERHERR, Karl J.; ORLEANS, Doug; OVLINGER, Johan. Aspect-oriented

programming with adaptive methods. Communications of the ACM, Volume 44, Issue 10,
2001.
LOBATO, Cidiane Aracaty. Um Framework Orientado a Aspectos para Mobilidade de

Agentes de Software. Rio de Janeiro, 2005. Dissertao (Mestrado) - Pontifcia Universidade
Catlica do Rio de Janeiro. Departamento de Informtica.
LOPES, Cristina Isabel Videira. D: A Language Framework For Distributed

Programming. Boston, 1997. Tese (Doutorado) - Northeastern University, College of
Computer Science.
95
MARTIN, Evan. Automated test generation for access control policies. In: Companion to
the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages,
and applications (OOPSLA '06), 2006.
MCLEAN, John. Security models. In: Encyclopedia of Software Engineering (ed. John
Marciniak), Wiley Press, 1994.
MOLESINI, Ambra; DENTI, Enrico; OMICINI, Andrea. RBAC-MAS & SODA:

Experimenting RBAC in AOSE. In: 9th International Workshop Engineering Societies in
the Agents World (ESAW'08), 2008.
MOURATIDIS, Haralambos; GIORGINI, Paolo; SCHUMACHER, Markus. Security

Patterns for Agent Systems. Proceedings of the Eight European Conference on Pattern
Languages of Programs (EuroPLoP), Irsee, 2003.
MOURATIDIS, Haralambos; GIORGINI, Paolo; WEISS, Michael. Integrating Patterns

and Agent-Oriented Methodologies to Provide Better Solutions for the Development of
Secure Agent-Based Systems. In: Proceedings of the Workshop on Expressiveness of Pattern
Languages, 2003
MOURATIDIS, Haralambos et al. A secure architectural description language for agent

systems, In: Proceedings of the fourth international joint conference on Autonomous agents
and multiagent systems (AAMAS '05), 2005.
MYERS, Glenford J. The art of software testing. 6 Edio, Hoboken, New Jersey, John
Wiley & Sons, Inc., 2004.
NAVARRO, G.; ORTEGA-RUIZ, J. A.; AMETLLER, J.; ROBLES, S. Distributed

Authorization Framework for Mobile Agents. Lecture Notes in Computer Science,
Mobility Aware Technologies and Applications, Vol. 3744, 2005.
NWANA, Hyacinth S. Software agents: An overview, Knowledge Engineering Review.

Cambridge University Press, Vol. 11, No. 3, 1996.
OGORMAN, Lawrence. Comparing Passwords, Tokens, and Biometrics for User

Authentication. Proceedings of the IEEE, Vol. 91, No. 12, 2003.
OMG, Object Management Group. Agent Technology Green Paper, 2000. Disponvel em:
<http://www.objs.com/agent/agents_Green_Paper_v100.doc>. Acessado em: 15/09/2009.
OMG, Object Management Group. Mobile Agent Facility Specification, 2000. Disponvel
em: <http://www.omg.org/cgi-bin/doc?formal/00-01-02.pdf>. Acessado em: 15/09/2009.
ORLEANS, Doug. Programming language support for separation of concerns. 2005. Tese
(doutorado) - Northeastern University, Faculty of the Graduate School. College of Computer
Science.
PARNAS, David Longe. On the Criteria to Be Used in Decomposing Systems into

Modules. Carnegie-Mellon University, Department of Computer Science. Communications of
the ACM, Vol. 15, No. 12, 1972.
96
PARTSAKOULAKIS, Ioannis; VOUROS, George. Importance and Properties of Roles in

MAS Organization: A review of methodologies and systems. In: First International Joint
Conference on Autonomous Agents & Multiagent Systems (AAMAS 02), 2002.
PARTSAKOULAKIS, Ioannis; VOUROS, George. ROLES IN MAS: Managing the

Complexity of Tasks and Environments. An Application Science for Multi-Agent Systems:
Multiagent Systems, Artificial Societies, And Simulated Organizations, Volume 10, Spring
US, 2004.
PIVETA, Eduardo. Um Modelo de Suporte a Programao Orientada a Aspectos. Santa

Catarina, 2001. Dissertao (Mestrado) - Universidade Federal de Santa Catarina.
PRESSMAN, Roger S. Engenharia de software. Traduo de Rosngela Delloso Penteado,

reviso tcnica de Ferno Stella R. Germano, Jos Carlos Maldonado, Paulo Csar Masiero.
6 Edio, So Paulo, Editora McGraw Hill, 2006.
QUILLINAN, Thomas B.; WARNIER, Martijn; OEY, Michel; TIMMER, Reinier;

BRAZIER, Frances. Enforcing Security in the AgentScape Middleware. In: Proceedings of
the 1st International Workshop on Middleware Security (MidSec), 2008.
RIBEIRO, Paula Clark. Modelagem e Implementao OO de Sistemas Multi-Agentes. Rio

de Janeiro, 2001. Dissertao (Mestrado) - Pontifcia Universidade Catlica do Rio de
Janeiro. Departamento de Informtica.
RUSSELL, Stuart J.; NORVIG, Peter. Artificial Intelligence: A Modern Approach.

Prentice Hall, 2003.
SANDHU, Ravi; SAMARATI, Pierangela. Access control: Principles and practice. IEEE
Communications Magazine, p. 40, 1994.
SANDHU, Ravi; SAMARATI, Pierangela. Authentication, Access Control, and Audit.

ACM Computing Surveys, Vol. 28, No. 1, 1996.
SANDHU, Ravi S. Role-Based Access Control. George Manson University, Laboratory for
Information Security Technology, ISSE Department, 1997.
SANDHU, Ravi; FERRAIOLO, David; KUHN, Richard. The NIST Model for Role-Based
Access Control: Towards A Unified Standard. Information Technology Laboratory,
National Institute of Standards and Technology (NIST), 2000.
SANTANNA, Cludio Nogueira. Manutenibilidade e reusabilidade de software

orientado a aspectos: um framework de avaliao. Rio de Janeiro, 2004. Dissertao
(Mestrado) - Pontifcia Universidade Catlica do Rio de Janeiro, Departamento de
Informtica.
SEARLE, John R. Speech Acts: An essay in the philosophy of language. Cambridge, MA,
Cambridge University Press, 1969.
97
SHAH, Viren; HILL, Frank. An Aspect-Oriented Security Framework: Lessons Learned.

In: Proceedings of AOSDSEC'04 (AOSD Technology for Application-Level Security).
Workshop of the Aspect Oriented Software Development Conference, Lancaster, UK, 2004.
SILVA, Viviane; GARCIA, Alessandro; BRANDO, Anarosa; CHAVEZ, Christina,

LUCENA, Carlos; ALENCAR, Paulo. Taming Agents and Objects in Software
Engineering. In: Software Engineering for Large-Scale Multi-Agent Systems
(SELMAS2003), 2003.
SUNDSTED, Todd. An introduction to agents. Java World. 1998. Disponvel em:

<http://www.javaworld.com/jw-06-1998/jw-06-howto.html>. Acessado em: 15/09/2009
SYMEONIDIS, Andreas; MITKA, Pericles. Agent Intelligence Through Data Mining. An

Application Science for Multi-Agent Systems: Multiagent Systems, Artificial Societies, And
Simulated Organizations, Volume 14, Spring US, 2006.
TARR, Peri; OSSHER, Harold; HARRISON, William; SUTTON, Stanley M. Jr. N Degrees
of Separation: Multi-Dimensional Separation of Concerns. In: Proceedings of the 21st
International Conference on Software Engineering, 1999.
VILLAR, Melissa Vieira Fernandes. Modelo de autenticao e autorizao baseado em

certificados de atributos para controle de acesso de aplicaes em ambiente distribudo
utilizando redes de Petri coloridas. Fortaleza, 2007. Dissertao (Mestrado) Universidade
Federal do Cear, Programa de Ps-graduao em Engenharia de Teleinformtica.
VIROLI, Mirko; OMICINI, Andrea; RICCI, Alessandro. Infrastructure for RBAC-MAS:

An Approach Based on Agent Coordination Contexts. Applied Artificial Intelligence, Vol.
21, 2007.
WAGNER, Gerd. Multi-Level Security in Multiagent Systems. Cooperative Information

Agents, LNAI 1202, 1997.
WANGHAM, Michelle Silva. Esquema de segurana para agentes mveis em sistemas

abertos. Florianpolis, 2004. Tese (Doutorado) - Universidade Federal de Santa Catarina,
Programa de Ps-graduao em Engenharia eltrica.
WOOLDRIDGE, Michael; JENNINGS, Nicholas R.; KINNY, David. A Methodology for

Agent-Oriented Analysis and Design. In: Proceedings of the third annual conference on
Autonomous Agents, 1999.
WOOLDRIDGE, Michael. An introduction to multiagent systems. John Wiley & Sons,

2002.
YAMAZAKI, Wataru; HIRAISHI, Hironori; MIZOGUCHI, Fumio. Designing an Agent-

Based RBAC System for Dynamic Security Policy. In: Proceedings of the 13th IEEE
International Workshops on Enabling Technologies: Infrastructure for Collaborative
Enterprises (WETICE '04), 2004.
YAO, Walt Teh-Ming. Trust Management for Widely Distributed Systems. 2003. Teste
(Doutorado) - University of Cambridge, Jesus College.
98
XIAO, Liang et al. An Adaptive Security Model for Multi-agent Systems and Application
to a Clinical Trials Environment. In: 31st Annual International Computer Software and
Applications Conference (COMPSAC), 2007.
ZAMBONELLI, Franco; JENNINGS, Nicholas R.; WOOLDRIDGE, Michael.

Organisational Abstractions for the Analysis and Design of Multi-Agent Systems.
Workshop on Agent-Oriented Software Engineering, 2000.
99
Glossrio
Agente: sistema computacional situado em algum ambiente e que capaz de aes autnomas
neste ambiente a fim de alcanas seus objetivos.
Ambiente: tudo que possa interagir com um agente, e que no faa parte da sua estrutura
interna.
Ambiente Externo: ambiente cujo controle de acesso no est implementado.
Ambiente Interno: ambiente cujo controle de acesso est implementado.
AspectJ: linguagem de programao pertencente ao paradigma de orientao aspectos.
Aspecto: abstrao utilizada na orientao a aspectos para modularizao de interesses

transversais.
Atuador: estrutura que define o momento de atuao de um aspecto num determinado ponto
de juno.
Autenticao: processo onde uma entidade fornece uma prova onde constatado se ela
realmente quem diz ser.
Autorizao: ato de limitar as atividades de usurios j autenticados pelo sistema.
Biblioteca: conjunto de funes especficas para a utilizao por programas que no querem
envolver-se em detalhes de implementao destas funes, mas apenas querem utilizar seus
servios.
Camada: abstrao que representa uma diviso lgica de componentes ou aspectos.
Cenrio: meio natural para escrever especificaes parciais, os cenrios capturam uma
sequncia de interaes que representam uma transio no sistema, ou uma funo no sistema.
100
Combinador de Aspectos: elemento responsvel pelo cruzamento de um ou mais aspectos

com os componentes descritos na linguagem de componentes de forma a gerar o programa
final.
Controle de Acesso: ato de limitar as atividades de usurios j autenticados pelo sistema.
Decomposio Funcional: diviso e modularizao de um processo ou sistema, de acordo com

suas funcionalidades, em partes mais compreensveis e menores.
Emaranhamento de Cdigo: sintoma causando quando um mdulo implementado tendo que

lidar com mltiplos interesses.
Espalhamento de Cdigo: sintoma causado quando um procedimento implementado em

mltiplos mdulos.
Interesse: considerao especfica que deve ser atendida para que seja possvel satisfazer o
objetivo geral do sistema.
Interesse Principal: especifica o que realmente importante para a aplicao, captura a

essncia, o relevante para o domnio da aplicao.
Interesse Transversal: qualquer forma computacional utilizada para controlar ou otimizar os

interesses principais.
Middleware: programa que faz mediao entre outros programas.
Modularizao: processo de criar mdulos os quais escondem suas implementaes uns dos
outros.
Monitor de Referncia: elemento que controla as tentativas de acesso realizadas por um

usurio aos recursos de um sistema.
Orientao a Aspectos: paradigma de programao de sistemas que permite a separao de

interesses transversais por meio de abstraes chamadas aspecto.
101
Orientao a Objetos: paradigma de anlise, projeto e programao de sistemas baseado na

composio e interao entre diversos componentes de software chamados de objetos.
Orientao a Agentes: paradigma que tem como elemento central o agente.
Pginas Amarelas: mecanismo que permite a localizao de um agente que oferece um

determinado servio.
Papel: trabalho funcional ou ttulo de um trabalho que confere determinada autoridade e

responsabilidade ao usurio que o desempenha.
Permisso: aprovao de um modo particular de acesso a um ou mais objetos do sistema.
Plataforma: local de instalao e execuo de um agente.
Poltica de Controle de Acesso: conjunto de papis e permisses atribudos a um usurio.
Ponto de Atuao: estrutura utilizada para sinalizar o local e momento de atuao do aspecto.
Ponto de Juno: pontos definidos na execuo de um programa, por exemplo: chamadas a

mtodos, acessos a membros e instanciao de objetos.
Requisito: objetivos ou restries estabelecidas por clientes e usurios que definem as

caractersticas, atributos, habilidades ou qualidade que um sistema (ou qualquer um de seus
mdulos e sub-rotinas), deve prover para ser til a seus usurios.
Role-Based Access Control: modelo de controle de acesso onde os direitos de acesso so

atribudos aos papis ao invs de serem atribudos a cada usurio.
Separao de Interesses: princpio que guia a diviso em partes do sistema onde a situao
ideal seria que a parte do programa dedicada a satisfazer a um determinado interesse estivesse
concentrada em uma nica localidade fsica, separada de outros interesses, para que o
interesse possa ser estudado e compreendido com facilidade.
102
Separao de Responsabilidade: diviso de tarefas e de permisses associadas entre diferentes

papis de forma a prevenir que um nico usurio acumule muita autoridade.
Sistema Multiagente: composio de um conjunto de diferentes tipos de agentes e objetos que

so inseridos em um ou mais ambientes.
Teste Adversrio de Controle de Acesso: simulaes de acessos ilegais realizadas com a

finalidade de determinar se o controle de acesso implementado contm alguma
vulnerabilidade.
Teste de Controle de Acesso: conjunto de atividades realizadas para assegurar a conformidade

entre a poltica de segurana e sua implementao.
Teste Funcional de Controle de Acesso: simulaes de acessos realizadas com a finalidade de

determinar se a implementao do controle de acesso est funcionando em conformidade com
a poltica de segurana especificada.
Teste de Verificao: conjunto de atividades realizadas para garantir que o sistema testado
implementa corretamente uma funo especfica.
Thread: diviso de um processo em duas ou mais tarefas que podem ser executadas em
paralelo.
Usurio: representao de um ser humano, agente autnomo, processo ou mquina.
Vulnerabilidade: brecha em um sistema computacional, tambm conhecida como bug.
Virtual Private Network: rede de comunicaes privada normalmente utilizada por uma
empresa ou um conjunto de empresas ou instituies. Utiliza como infraestrutura uma rede de
comunicao pblica, como por exemplo, a Internet.
103
Apndice A -
Cdigos-fonte dos Aspectos
104
SecurityAspect
package br.mestrado.hosp.aspects.security;
import org.heimdall.Heimdall;
import br.mestrado.hosp.agents.Supervisor;
/**
* Aspecto responsvel pela segurana (base)
* */
public abstract aspect SecurityAspect {
//
// Pega o agente supervisor da aplicao
//
protected Supervisor supervisor = null;
//pointcut
pointcut supervisorSetup() :
execution(void
br.mestrado.hosp.agents.Supervisor.setup());//PCD
//advice
after(): supervisorSetup(){
this.supervisor = (Supervisor) thisJoinPoint.getTarget();
}
//
// Inicializa o Heimdall
//
public SecurityAspect() {
Heimdall.authenticationManager.setApplicationName("hosp");
}
}
105
AuthenticationAspect
import jade.core.AID;
import javax.security.auth.login.LoginException;
/**
* Aspecto responsvel pela autenticacao (base)
* @author Willian
*/
public abstract aspect AuthenticationAspect extends SecurityAspect {
/**
* Login do agente
*
* @param agente O agente a ser autenticado
* @param userName usuario
* @param password senha
*/
protected boolean agentLogIn(AID agent, String userName,
String password) {
try {
if (Heimdall.authenticationManager.logIn(agent,
userName, password)) {
//System.out.println(Utils.getTime() + " - agente

[" + agent.toString() +
"] foi autenticado com o usuario: " + userName);
System.out.println(this.getClass().getSimpleName()+
" - o agente [" + agent.getName()+ "] foi
autenticado com o usuario: "
+ userName);
return true;
}
else {
//System.err.println(Utils.getTime() + " - o agente
[" + agent.getName() + "] nao foi autenticado com o
usuario: " + userName);
System.err.println(this.getClass().getSimpleName()+
" - o agente [" + agent.getName() + "] nao foi
autenticado com o usuario: " + userName);
return false;
}
}
catch (LoginException e) {
System.err.println("***** AGENTE NAO AUTENTICADO

*****");
106
System.err.println("***** agente: [" + agent.getName());
System.err.println("***** " + e.getMessage());
return false;
}
}
}
107
ProactiveAuthenticationAspect
import br.mestrado.hosp.agents.BaseAgent;
/**
* Aspecto responsvel pela autenticacao (agentes no ambiente)
* @author Willian
*/
public aspect ProactiveAuthenticationAspect extends AuthenticationAspect {
//
// Authentication (Proactive), agente deste ambiente
//
pointcut proActiveAuthentication() :
within(br.mestrado.hosp.agents.*) &&
!within(br.mestrado.hosp.agents.BaseAgent) &&
//para fazer o teste T1

//!within(br.mestrado.hosp.agents.Paciente) &&
//para fazer o teste T1
execution(protected void setup());
after(): proActiveAuthentication(){
//pega o agente
BaseAgent agente = (BaseAgent) thisJoinPoint.getTarget();
//pega o usuario e senha do agente;

String userName = agente.getUser();
String password = agente.getPassword();
if(agentLogIn(agente.getAID(), userName, password))

{
System.out.println("*** Proactive Authentication: " +
agente.getAID().toString() + "user: " + userName);
}
else
{
*****");
System.err.println("***** agente: [" + agente.getName() +
"]");
}
}
108
ReactiveAuthenticationAspect
import jade.content.Concept;
import jade.content.ContentElement;
import jade.content.onto.basic.Action;
import br.mestrado.hosp.agents.ontology.InformarAcessoNegadoAction;
import br.mestrado.hosp.agents.ontology.SolicitarAutenticacaoAction;
/**
* Aspecto responsvel pela autenticacao (agentes fora do ambiente)
* @author Willian
*/
public aspect ReactiveAuthenticationAspect extends AuthenticationAspect {
//
// Authentication (Reactive), agente de outro ambiente
//
pointcut reActiveAuthentication() :
call(void
br.mestrado.hosp.agents.Supervisor.ReceiveMessagesBehaviour.processAction(A
CLMessage, ContentElement));
//advice
void around() : reActiveAuthentication(){
Object[] params = thisJoinPoint.getArgs();

ACLMessage msg = (ACLMessage) params[0];
ContentElement content = (ContentElement) params[1];
// pega a acao
Concept action = ((Action) content).getAction();
if (action instanceof SolicitarAutenticacaoAction) {
SolicitarAutenticacaoAction solicitarAutenticacaoAction =
(SolicitarAutenticacaoAction) action;
//AID agent = msg.getSender();
String[] values =
solicitarAutenticacaoAction.getEntidade().toString()
.split(",#@,");
if (agentLogIn(msg.getSender(), values[0], values[1])) {

System.out.println("*** Reactive Authentication: "+
msg.getSender().toString() + " user: " +values[0]);
}
else {

*****");
System.err.println("***** agente: [" + m
sg.getSender().getName() + "]");
109
InformarAcessoNegadoAction informarAcessoNegado =
new InformarAcessoNegadoAction();
informarAcessoNegado.setAgentAction(solicitarAutenticacaoAction);
informarAcessoNegado.setAccessDeniedMessage("USUARIO ou SENHA
INVALIDA");
supervisor.replyAcessoNegado(msg.getSender(),
informarAcessoNegado);
} else
proceed();
}
}
110
AccessControlAspect
import jade.content.AgentAction;
import org.heimdall.security.authorization.rbac.Permission;
import br.mestrado.hosp.agents.ontology.AtualizarGlicemiaAction;
import br.mestrado.hosp.agents.ontology.AvisarDiabetologistaAction;
import br.mestrado.hosp.agents.ontology.InformarGlicemiaAction;
import br.mestrado.hosp.agents.ontology.InformarPacienteAction;
import br.mestrado.hosp.agents.ontology.LiberarPacienteAction;
import br.mestrado.hosp.agents.ontology.RegistrarPacienteAction;
import br.mestrado.hosp.agents.ontology.SolicitarAutenticacaoAction;
import br.mestrado.hosp.agents.ontology.SolicitarGlicemiaAction;
import br.mestrado.hosp.agents.ontology.SolicitarPacienteAction;
/**
* Aspecto responsvel pelo controle de acesso (base)
* */
public abstract aspect AccessControlAspect extends SecurityAspect {
//
// Controle de acesso
//
/**
*
* Verifica se um agente possui permissao para uma ao.
*
* @param agent Um agente j autenticado
* @param action A ao que o agente est tentando
executar/solicitando execuo
*/
protected boolean agentHasPermission(AID agent, AgentAction action)
throws LoginException {
//
// Mapeamento (action <-> permission)
//
org.heimdall.security.authorization.rbac.Permission p = null;
if (action instanceof AtualizarGlicemiaAction) {

p = new
Permission(SecurityConstants.Permissions.AtualizarGlicemia.toString(),
null);
}
else if (action instanceof AvisarDiabetologistaAction) {
111
p = new
Permission(SecurityConstants.Permissions.AvisarDiabetologista.toString(),
null);
}
else if (action instanceof InformarAcessoNegadoAction) {
p = new
Permission(SecurityConstants.Permissions.InformarAcessoNegado.toString(),
null);
}
else if (action instanceof InformarGlicemiaAction) {
p = new
Permission(SecurityConstants.Permissions.InformarGlicemia.toString(),
null);
}
else if (action instanceof InformarPacienteAction) {
p = new
Permission(SecurityConstants.Permissions.InformarPaciente.toString(),
null);
}
else if (action instanceof LiberarPacienteAction) {
p = new
Permission(SecurityConstants.Permissions.LiberarPaciente.toString(), null);
}
else if (action instanceof RegistrarPacienteAction) {
p = new
Permission(SecurityConstants.Permissions.RegistrarPaciente.toString(),
null);
}
else if (action instanceof SolicitarAutenticacaoAction) {
p = new
Permission(SecurityConstants.Permissions.SolicitarAutenticacao.toString(),
null);
}
else if (action instanceof SolicitarGlicemiaAction) {
p = new
Permission(SecurityConstants.Permissions.SolicitarGlicemia.toString(),
null);
}
else if (action instanceof SolicitarPacienteAction) {
p = new
Permission(SecurityConstants.Permissions.SolicitarPaciente.toString(),
null);
}
else {
return false;
}
//
//Verifica se o agente (usuario do agente) possui a permissao
//
if (Heimdall.rbacManager.hasPermission(agent, p)) {
return true;
} else {
return false;
}
}
112
ProactiveAccessControlAspect
import br.mestrado.hosp.agents.BaseAgent;
/**
* Aspecto responsvel pelo controle de acesso proativo (no envio da
mensagem)
* @author Willian
*/
public aspect ProactiveAccessControlAspect extends AccessControlAspect {
pointcut agentSendMessage(int performative, AID receiver, AgentAction

action) :
args( performative, receiver, action) &&
execution(void br.mestrado.hosp.agents.*.sendMessage(int,
AID , AgentAction )) ;
//advice
void around(int performative, AID receiver, AgentAction action):
agentSendMessage(performative, receiver, action){
BaseAgent sender = (BaseAgent) thisJoinPoint.getTarget();
//System.out.println("PAC[" + performative + "]:\t(" +

sender.getName() + " => " + receiver.getName() + "):\t" +
action.getClass().getSimpleName());
System.out.println("ProactiveAccessControlAspect - (" +
sender.getName() + " => " + receiver.getName() + "):" +
//
//Analisa se o agente tem permissao
//
try {
if((!(sender.getAID().getAddressesArray()[0]).
equals(receiver.getAddressesArray()[0]))
&&
!Heimdall.authenticationManager.isAuthenticated(receiver))
//agente externo, nao autenticado que precisa ser avisado
{
proceed(performative, receiver, action);
//se tem permissao envia a mensagem
}
else if (agentHasPermission(sender.getAID(), action) &&
113
agentHasPermission(receiver, action)) {
proceed(performative, receiver, action);
//se tem permissao envia a mensagem
} else {
//
// Exibe a mensagem que o agente sender ou o
receiver nao esta autorizado a executar a acao
//
System.err.println("***** ACESSO NEGADO *****");
System.err.println("***** agente: [" +
sender.getName() + "] ou [" + receiver.getName() +
"]");
System.err.println("***** sem permissao para acao:
("+action.getClass().getSimpleName()+")");
}
} catch (LoginException e) {
//
// Exibe a mensagem que o agente sender nao esta
autenticado
//
*****");
System.err.println("***** agente: [" + sender.getName() +
"] ou [" + receiver.getName() + "]");
System.err.println("***** HeimdallException: "
+e.getMessage());
}
}
114
ReactiveAccessControlAspect
import jade.content.ContentElement;
import jade.content.onto.basic.Action;
/**
* Aspecto responsvel pelo controle de acesso reativo (no recebimento da
mensagem)
* @author Willian
*/
public aspect ReactiveAccessControlAspect extends AccessControlAspect {
//recebimento de mensagens pelo agente

pointcut agentReceiveMessage(ACLMessage message, ContentElement
content) :
args( message, content) &&
execution(void
br.mestrado.hosp.agents.*.ReceiveMessagesBehaviour.processAction(ACLMessage
, ContentElement));
//advice
void around(ACLMessage message, ContentElement content) :
agentReceiveMessage(message, content){
AID sender = message.getSender();

AID receiver = ((AID) message.getAllReceiver().next());
if (!(sender.getAddressesArray()[0]).
equals(receiver.getAddressesArray()[0])) {
AgentAction action = (AgentAction)

(((Action)content).getAction());
//System.err.println("RAC[" + message.getPerformative() +
"]:\t(" + sender.getName() + " => "
+ receiver.getName() + "):\t"
// + action.getClass().getSimpleName());
System.out.println("ReactiveAccessControlAspect - (" +
sender.getName() + " => " + receiver.getName() + "):" +
//
//Analisa se o agente tem permissao e avisa ele caso no
tenha
115
//
InformarAcessoNegadoAction informarAcessoNegado =
new InformarAcessoNegadoAction();
informarAcessoNegado.setAgentAction((AgentAction)
action);
try {
if (agentHasPermission(sender, (AgentAction)
action))
//e o receiver tb
{
proceed(message, content);
//se tem permissao recebe a mensagem
} else {
System.err.println("***** ACESSO NEGADO

*****");
sender.getName() + "] ou [" + receiver.getName() + "]");
System.err.println("***** sem permissao para
acao: ("+action.getClass().getSimpleName()+")");
//aborta o envio da mensagem e envia uma msg

para ele dizendo que nao tem direito.
informarAcessoNegado.setAccessDeniedMessage("ACESSO NEGADO");
supervisor.replyAcessoNegado(sender,
}
} catch (LoginException e) {

*****");
sender.getName() + "] ou [" + receiver.getName() + "]");
System.err.println("***** HeimdallException: "
+e.getMessage());
informarAcessoNegado.setAccessDeniedMessage("AGENTE
NAO ESTA AUTENTICADO");
supervisor.replyAcessoNegado(sender,
}
} else
proceed(message, content); //local
}
}

Willian Ferreira Peixoto

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Willian Ferreira Peixoto

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO ESTADUAL DE EDUCAO TECNOLGICA PAULA SOUZA

WILLIAN FERREIRA PEIXOTO

UMA PROPOSTA PARA

UMA PROPOSTA PARA

Dissertao apresentada como exigncia parcial para

Dissertao (Mestrado) - Centro Estadual de

1. Arquitetura de software . 2. Sistemas multiagentes .

minha famlia que sempre me apoiou.

minha amiga Marie Moritani, que fez a reviso do texto da monografia.

Enfim, a todas as pessoas e entidades que direta ou indiretamente tornaram possvel a

PEIXOTO, W. F. Uma Proposta para Controle de Acesso Baseado em Papis na

Palavras-chave: Sistemas Multiagentes, SMA, Arquitetura de Software, Controle de Acesso,

PEIXOTO, W. F. Uma Proposta para Controle de Acesso Baseado em Papis na

Keywords: Multi-agent Systems, MAS, Software Architecture, Access Control,

Figura 3.1 Autenticao, controle de acesso e outros elementos de segurana.................... 30

Tabela 2.1 Propriedades do agente. ................................................................................... 20

ACL Agent Communication Language

Um agente entendido como um software capaz de resolver um problema em

1.1. Objetivos do Trabalho

O objetivo deste trabalho consiste em propor uma arquitetura para implementao do

1.2. Motivaes e Resultados Esperados

A segurana de informaes protege as aplicaes contra possveis ameaas a fim de

1.3. Mtodo e Desenvolvimento do Trabalho

A fase inicial da pesquisa consistiu-se no estudo da orientao a agentes e dos

1.4. Organizao do Trabalho

O termo agente utilizado em diversas disciplinas da cincia da computao, como a

Tabela 2.1 Propriedades do agente.

Algumas propriedades como a interao e colaborao so vitais em agentes que

Cada agente tem capacidade de solucionar parcialmente o problema;

Segundo o OMG (2000a) algumas consideraes sobre os SMAs so importantes:

A autonomia e a interao so consideradas pela Foundation for Intelligent Physical

(I) autonomia de execuo;

A autonomia proativa caracterizada pela proatividade, definida como a execuo de

Um agente no pode evocar ou simplesmente forar outro agente a realizar alguma

As ACLs citadas no pargrafo anterior esto fundamentadas na teoria conhecida como

Fonte: (BELLIFEMINE; CAIRE; GREENWOOD, 2007)

Os papis de agentes4 tm sido utilizados durante as fases de concepo (SILVA et al.,

comportamentos necessrios para realizar as colaboraes com outros agentes (GARCIA,

Neste captulo foram apresentados os conceitos de agente, SMA, tipo de agente e

3. Autenticao e Controle de Acesso

Segundo Sandhu e Samarati (1996), a autenticao, o controle de acesso e a auditoria

Baseados no que voc sabe;

O primeiro fator baseado no conhecimento de um segredo ou algo obscuro,

Conforme descrito por Sandhu e Samarati (1994), o controle de acesso ou autorizao,

Figura 3.1 Autenticao, controle de acesso e outros elementos de segurana.

3.1. Modelos de Controle de Acesso

Os mecanismos de controle de acesso so utilizados para implementar a poltica de

Sandhu e Samarati (1996) classificam os modelos de controle de acesso em trs

3.1.1. Modelo NIST RBAC

Sandhu et al. (2000) relatam que muitos vendedores de sistemas de computao tm

Figura 3.2 Nveis do modelo NIST RBAC.

Alguns nveis deste modelo apresentam subnveis e em cada um deles implementado

Figura 3.3 RBAC Base.

Sandhu (1997) formaliza os componentes deste nvel por meio da definio:

U, R, P, (usurios, papis e permisses respectivamente);

UA U R, relao muitos para muitos de usurio para papel;

PA P R, relao muitos para muitos de permisso para papel.

O conceito de sesses presente de forma facultativa neste modelo, ao contrrio do

Figura 3.4 RBAC Base com suporte a sesses.

Sandhu (1997) formaliza os componentes deste nvel atravs da definio:

U, R, P, UA, PA (permanecem inalterados);

RH R R, um ordenamento parcial em R chamado de hierarquia de

Organizaes normalmente possuem uma estrutura hierrquica de comando. A

Figura 3.5 RBAC Hierrquico.