sistemas baseados em agentesasilva/page19/page7/assets/1020612_vitor hugo... · vantagens e...

Instituto Superior de Engenharia do Porto

Mestrado em Engenharia Informática

Área de Tecnologias do Conhecimento e Decisão

Sistemas Baseados em Agentes

Agentes Móveis

1020612 – Vitor Hugo Barros

Maio de 2008

ISEP – 2008 Agentes Móveis

Índice1Introdução.................................................................................................................................3

2Agentes Móveis.........................................................................................................................4

2.1Definição e História......................................................................................................................4

2.2Mobilidade....................................................................................................................................5

3Vantagens da utilização de Agentes Móveis............................................................................8

4Toolkits de Agentes Móveis.....................................................................................................12

4.1Java nos Agentes Móveis...........................................................................................................15

4.2Aglets.........................................................................................................................................17

5Segurança em Agentes Móveis..............................................................................................22

5.1Tipos de ameaças......................................................................................................................22

5.2Medidas de prevenção...............................................................................................................25

6Conclusões..............................................................................................................................29

7Bibliografia...............................................................................................................................30

2


1 Introdução

No âmbito da disciplina de Sistemas Baseados em Agentes, incluída no Mestrado

em Engenharia Informática – vertente de Tecnologias do Conhecimento e Decisão,

do Instituto Superior de Engenharia do Porto, foram lançados vários temas para

pesquisa bibliográfica, entre os quais, o assunto “Agentes Móveis” que será o

abordado neste documento.

É objectivo deste documento definir o que são Agentes Móveis, bem como

apresentar algumas formas típicas de implementação dos mesmos e enquadrá-los

na área da computação distribuída. Serão também abordadas algumas

frameworks de desenvolvimento de Agentes Móveis com um maior foco na API

Aglets da IBM e, por fim, algumas considerações de segurança fundamentais

nesta área uma vez que se tratam de movimentações em redes intra e internet.

O documento encontra-se dividido em quatro capítulos principais. No capítulo 2 –

Agentes Móveis - é definido este conceito enquadrado-o com algum background

histórico. No 3º capítulo – Vantagens na utilização de Agentes Móveis – são

apresentadas as razões pelas quais devem ser utilizadas aplicações baseadas em

Agentes Móveis. Na secção 4 – Toolkits de Agentes Móveis – são analisadas

algumas bibliotecas para o desenvolvimento de Agentes Móveis, descritas as

vantagens e desvantagens da utilização da linguagem Java no desenvolvimento

seguindo este paradigma e é efectuada uma análise mais profunda à framework

Aglets. Por último, no capítulo 5 – Segurança em Agentes Móveis – é abordada a

problemática da segurança na movimentação de agentes bem como a

apresentação de algumas contra-medidas a aplicar para evitar ameaças.

3


2 Agentes Móveis

Nos últimos anos, e principalmente com o exponencial crescimento do número de

pessoas e dispositivos com acesso à internet, que, por sua vez, tem vindo a

disponibilizar também uma crescente panóplia de serviços e de informação, tem-

se vindo a observar um desenvolvimento elevado nas tecnologias de computação

distribuída e de rede [1].

Este desenvolvimento veio despoletar a necessidade de serem criadas aplicações

com potencialidades de troca de informação entre redes heterogéneas de uma

forma eficaz. Por esta razão foram criados vários paradigmas de desenvolvimento

de software para computação distribuída entre os quais podemos destacar os

paradigmas Cliente-Servidor, Remote Procedure Calling (RPC) e Agentes Móveis.

2.1 Definição e História

Agentes Móveis são processos de software capazes de se moverem

autonomamente de uma localização de rede física para outra a qualquer altura

[1][2][3]. O estado de execução do processo é guardado e é movido para a nova

localização juntamente com o código do Agente para que a execução possa ser

retomada no novo host [3]. O Agente executa a sua acção quando e onde achar

apropriado e não necessita estar previamente instalado no cliente. Desta forma,

denota-se um senso de autonomia inerente na mobilidade e execução do agente

[2].

4


Os Agentes Móveis são uma forma específica dos paradigmas de mobile code e

software agents. Contudo, contrariamente aos paradigmas Remote Evaluation

(RE) e Code on Demand (CoD) , os Agentes Móveis são activos na forma como

decidem migrar entre computadores a qualquer momento da sua execução. Isto

faz deles uma ferramenta poderosa para implementar aplicações distribuídas

numa rede de computadores [3].

A pesquisa na área de Agentes Móveis emergiu como uma extensão do

paradigma RE, proposto por Stamos e Gillford em 1990 [4]. Em 1999, Kotz e Gray

[1] previram que os mais relevantes websites iriam aceitar Agentes Móveis em

poucos anos, enquanto que Milojicic [5] afirmou que, apesar da tecnologia

associada aos Agentes Móveis ter visto um interesse crescente nas comunidades

cientificas e na indústria, a implementação esperada da tecnologia não teria

emergido até então e poderia inclusive nunca chegar a emergir de todo. O

declínio no número de publicações no tópico entre 1999 e 2001 suportaram, de

facto, o ponto de vista de Milojicic. Contudo, desde o final de 2001, houve

novamente um aumento considerável do número de publicações, largamente

devido ao estabelecimento de standards abertos para as internet applications e

do desenvolvimento da web semântica [6].

2.2 Mobilidade

Posto isto surge a questão: “Como se move, afinal, um Agente Móvel?”.

Da mesma forma que um utilizador que visita uma página web não está

realmente a visualizar os seus conteúdos directamente no servidor, mas antes é

efectuado o download de uma cópia da mesma para ser visualizado no cliente, o

5


Agente concretiza o seu movimento através da duplicação de dados. Quando o

Agente decide mover-se, guarda o seu próprio estado de execução, transporta

este estado guardado para o próximo host e continua a sua execução aí [3].

Distinguem-se dois tipos fundamentais de mobilidade [7]:

1. Na mobilidade fraca, quando o agente decide transferir-se, apenas é

guardada a componente estática do seu estado de execução (valores dos

atributos dos objectos estáticos), mas não o estado dinâmico (pilha, registos

da máquina, etc.). A execução do agente no destino será reiniciada num

ponto pré-definido (sempre no mesmo ponto definido antes da

transferência, etc.).

2. Na mobilidade forte, para além da componente estática do estado de

execução do agente, também é guardada a componente dinâmica,

prosseguindo a execução do agente na máquina destino, na instrução

imediatamente a seguir à instrução de transferência.

À primeira vista, o tipo de mobilidade mais óbvio a implementar seria a

mobilidade forte uma vez que guarda a totalidade do estado do Agente Móvel

antes da sua acção de deslocamento. Contudo, a mais utilizada tem sido a

mobilidade fraca muito porque a eficiência dos programas que implementam este

tipo de mobilidade é bastante superior e também pela razão da linguagem de

programação JavaTM, muito utilizada no desenvolvimento destas aplicações, não

possuir mecanismos standard para a preservação da componente dinâmica do

estado [7].

Embora impondo ao implementador algumas restrições adicionais, a mobilidade

6


fraca permite que se tire partido do paradigma de programação baseado em

Agentes Móveis sem que, em termos práticos, constitua uma limitação muito

significativa [7].

7


3 Vantagens da utilização de Agentes Móveis

Uma das máximas defendidas pelos investigadores Danny B. Lange e Mitsuru

Oshima é “Dispatch your Agents; shut off your machine” [8]. Esta é precisamente

a alusão a uma das maiores vantagens da utilização do paradigma de Agentes

Móveis que, contrariamente ao exigido, por exemplo, nas arquitecturas cliente-

servidor, possibilitam que o computador “servidor” possa ser desligado durante o

processamento de uma aplicação.

Como tem sido referido ao longo deste documento, inversamente aos Agentes

Estacionários, que iniciam e terminam a sua execução no mesmo sistema, os

Agentes Móveis têm a liberdade de se moverem entre sistemas o que se traduz

em enormes benefícios na criação de aplicações distribuídas, entre os quais [8]:

1. Redução da carga de rede. É normal os sistemas distribuídos apoiarem-

se em protocolos de comunicação que envolvem múltiplas interacções para

atingirem um objectivo. Isto resulta num tráfego de rede elevado. Os

Agentes Móveis permitem armazenar uma determinada conversação e

enviá-la para um host destino onde as interacções continuam localmente,

reduzindo o número de ligações necessário. Ajudam também a reduzir o

volume de dados a transferir na rede ao efectuar o processamento de dados

localmente e transferindo apenas o estado actual do agente.

8


2. Ocultação de latências da rede. Tipicamente em sistemas de tempo real,

onde a resposta imediata é essencial para o correcto funcionamento dos

mesmos, um volume de comunicações elevado resulta facilmente em

notáveis latências no envio e obtenção de informação. Para sistemas

críticos de tempo real, tais latências são inaceitáveis. Os Agentes Móveis

oferecem uma solução para estes casos pois podem ser enviados por um

controlador central para posteriormente agirem localmente nos sistemas

destino executando as directivas do controlador. Assim as latências de rede

são reduzidas a quase zero.

3. Encapsulamento de protocolos. Quando são trocados dados num

sistema distribuído, em cada host é necessário que esteja disponível o

código que implementa os protocolos necessários à interpretação dos dados

recebidos e a enviar. Contudo, à medida que estes protocolos vão evoluindo

para incluirem novas funcionalidades e melhorias na sua segurança, é

necessária a sua actualização em todos os hosts o que representa um tarefa

9

Figura 1: Abordagem baseada em RPC vs Abordagem baseada em Agentes Móveis


bastante difícil para os administradores de sistemas, muitas vezes

impossível de concretizar. Os Agentes Móveis, por outro lado, podem mover-

se para qualquer host estabelecendo “canais” de comunicação baseados

num protocolo implementado nos mesmos.

4. Execução assíncrona e autónoma. É normal os dispositivos móveis

estarem assentes em comunicações fornecidas por redes frágeis e caras.

Tarefas que necessitem de uma conexão contínua entre um dispositivo

móvel e uma rede fixa não são provavelmente económicas ou até

tecnicamente exequíveis. Para resolver este problema, as tarefas podem ser

integradas em Agentes Móveis, que podem ser distribuídos pela rede. Após

a sua distribuição, os agentes tornam-se independentes do processo que os

criou e podem operar assincronamente e autonomamente. O dispositivo

móvel pode reconectar-se numa altura posterior para recolher o agente.

10

Figura 2: Execução assíncrona e autónoma dos Agentes Móveis


5. Adaptação dinâmica. Os Agentes Móveis podem aperceber-se do

ambiente no qual se encontram a ser executados e reagem

autonomamente à mudanças. Múltiplos Agentes Móveis possuem também a

vantagem única de se poderem distribuir por vários hosts de forma a

alcançar a distribuição de rede óptima para a resolução de um determinado

problema.

6. Heterogeneidade natural. A computação em rede é naturalmente

heterogénea, tanto da perspectiva do software, como da perspectiva do

hardware. Devido ao facto dos Agentes Móveis serem geralmente

independentes no que refere a computadores e camadas de transporte

(dependentes apenas dos seus ambientes de execução), eles fornecem

condições óptimas para a integração de sistemas de redes distintas (em

que a heterogeneidade é mais provável).

7. Robustez e tolerância a falhas. A capacidade dos Agentes Móveis

reagirem dinamicamente a situações e eventos desfavoráveis torna mais

fácil a criação de aplicações distribuídas robustas e tolerantes a falhas. No

caso de um host se encontrar em processo de encerramento, todos os

agentes são avisados e será dado tempo para estes guardarem o estado da

sua execução e migrarem para novos hosts.

11


4 Toolkits de Agentes Móveis

Agentes Móveis é um assunto que tem estado presente nos tópicos das mais

recentes pesquisas na área da computação distribuída.

Contudo, não existe “a aplicação” de Agentes Móveis [7], mas antes várias

aplicações que beneficiam da utilização do paradigma de Agentes Móveis, entre

as quais aplicações ligadas às áreas do e-commerce, assistência pessoal,

obtenção de informação distribuída, serviços de telecomunicações e rede e

processamento paralelo.

Da investigação na área dos Agentes Móveis, surgiram uma série de toolkits cujo

intuito seria o de fornecerem uma API para a implementação facilitada de

software com recurso a este paradigma. Esta investigação resultou numa série de

frameworks distintas, de entre as quais se destacam [9][10]:

1. Odyssey é uma biblioteca de desenvolvimento de Agentes Móveis simples

mas semanticamente elegante desenvolvida pela General Magic. Esta

empresa já teria desenvolvido a primeira toolkit de Agentes Móveis: a

Telescript. Contudo, devido à sua natureza proprietária teve pouco sucesso

e teve de ser re-implementada com recurso a linguagens e protocolos de

rede abertos, dando origem à Odyssey.

2. Concordia é uma framework desenvolvida pela Mitsubishi Electric ITA

conhecida por ter rica em funcionalidades. O Concordia é uma combinação

de vários componentes que constituem a aplicação distribuída. Esta toolkit

12


requer apenas uma implementação padrão da máquina virtual Java e o seu

ambiente é composto por um servidor e um conjunto de agentes.

Providencia mecanismos de segurança e tolerância a falhas.

3. Voyager foi criada pela ObjectSpace e fornece uma poderosa biblioteca

para desenvolver aplicações distribuídas. Assenta numa plataforma Object

Request Broker (ORB) com suporte a agentes. Esta framework implementa

os mecanismos tradicionais de troca de mensagens e movimentação de

agentes, mas tem como grande desvantagem a de não oferecer

mecanismos de segurança contra agentes não autorizados.

4. Aglets é uma das mais populares toolkits para o desenvolvimento de

Agentes Móveis. Inicialmente desenvolvida pela IBM Tokyo Research

Laboratories e mais tarde continuada pela comunidade open source, esta

framework tem como principais vantagens o facto de ser extremamente

bem desenhada sendo, ao mesmo tempo, simples de utilizar. Contém

também um sistema de segurança robusto que impede que aglets não

autorizados acedam a determinados recursos do sistema. Esta framework

será abordada com mais pormenor na secção 4.2.

Todos estes toolkits partilham características em comum na forma como abordam

a problemática associada aos Agentes Móveis [9][10]: são implementados em

linguagem Java e utilizam a sua máquina virtual como ambiente de execução;

usam técnicas de serialização de objectos para o envio de informação; possuem

uma arquitectura baseada num agent server.

Cada uma destas frameworks possui uma classe base de onde todos os Agentes

Móveis são derivados. Na Aglets são chamados aglets e nas Odyssey, Concordia e

Voyager são denominados agents. O propósito desta classe base é a de fornecer

uma interface comum de comunicação entre diferentes agentes. Em qualquer

13


destes toolkits, o agente não é acedido directamente, mas antes é feito um

pedido a um tipo de agent proxy que se encarregará de reencaminhar as

mensagens para o agente. Esta proxy é desenvolvida automaticamente pela

toolkit.

Por definição, os agentes deveriam circular entre diferentes hosts sem que os

mesmos tivessem de preencher quaisquer pré-requisitos para a sua aceitação.

Contudo, por razões de segurança, todas estas frameworks contêm um agent

server que consiste basicamente em fornecer um ambiente controlado para a

execução e aceitação de agentes. Um determinado agent server apenas pode

receber e executar agentes criados com a mesma toolkit.

Ambas as frameworks possuem também uma classe ambiente. O ambiente pode

ser acedido por agentes e cada agente deve estar associado a um ambiente.

A forma como é efectuada a migração de agentes nos diferentes toolkits é

semelhante. Cada um deles possui um método (membro da classe base do

agente) que tem como argumento o endereço do servidor destino. Também

possuem um método que é invocado imediatamente antes da migração do

agente e da chegada do agente. Estes métodos podem ser re-implementados

para executarem de limpeza ou de inicialização de estados.

A grande diferença entre estas bibliotecas de criação de aplicações distribuídas

baseadas em Agentes Móveis reside essencialmente nos mecanismos de

transporte de agentes e na sua interacção. A forma como abordam a segurança

na troca de agentes é também distinta entre frameworks.

14


4.1 Java nos Agentes Móveis

A linguagem Java tem sido aceite largamente como a linguagem para a escrita de

sistemas de Agentes Móveis [9]. A razão para isto reside no facto desta tecnologia

fornecer de base a maioria das características necessárias ao desenvolvimento de

aplicações baseadas em Agentes Móveis.

De seguida são apresentadas algumas características que fazem da linguagem

Java uma óptima escolha para o desenvolvimento de sistemas de Agentes Móveis

[11]:

1. Independência de plataforma. A linguagem Java foi desenhada para

operar em redes heterogéneas. Toda a programação efectuada nesta

linguagem é compilada para um byte code independente da arquitectura ou

do sistema operativo que será lido pela máquina virtual do Java que, por

sua vez, terá de se encontrar instalada no sistema. Não existem aspectos

dependentes de nenhuma arquitectura na linguagem Java. Desta forma, é

possível o desenvolvimento de Agentes Móveis sem a preocupação do tipo

de computadores nos quais este será executado.

2. Execução segura. Um dos objectivos da criação da tecnologia Java foi a

sua utilização em intranets e na internet. Assim, a exigência de segurança

em todas as suas acções influenciou de sobremaneira o seu desenho. Isto

faz com que o simples facto de utilizar Java torne a aceitação de agentes

não reconhecidos razoavelmente segura pois, devido à sua arquitectura,

não é possível que o mesmo mexa no código do host ou que aceda a

informação que não deve aceder.

3. Carregamento de classes dinâmico. Este mecanismo permite que a

máquina virtual carregue e defina classes em runtime. Providencia um

15


namespace que protege cada agente, permitindo que estes sejam

executados segura e independentemente uns dos outros.

4. Programação com múltiplas threads. Os agentes são por definição

autónomos. Isto é, um agente é executado independentemente de outros

agentes que estejam a correr no mesmo local. Permitindo que cada agente

seja executado no seu próprio processo, também chamado thread de

execução, é uma forma de fazer com que os agentes se comportem

autonomamente. Felizmente, o Java não permite apenas a programação

multithread, mas também suporta um conjunto de primitivas de

sincronização disponíveis de raiz na linguagem. Estas primitivas possibilitam

a interacção entre agentes.

5. “Serialização” de objectos. Uma característica chave dos agentes

móveis é o facto destes poderem ser “serializados” e “deserializados”. O

Java convenientemente disponibiliza um mecanismo de “serialização” de

raiz que permite a representação do estado de um objecto numa forma

“serializada” suficientemente detalhada de forma a possibilitar a

reconstrução do objecto numa altura posterior. A forma “serializada” do

objecto deve ser capaz de reconhecer a classe a partir da qual o estado do

objecto foi guardado, e restaurar esse estado numa nova instância. É

importante a ordem deste restauro uma vez que é possível que os vários

objectos sejam interdependentes.

6. Reflexão. O código Java pode descobrir informação acerca dos campos,

métodos e construtores de classes e pode usar campos, métodos e

construtores reflectidos para operarem a um nível mais baixo nos objectos,

sempre com as restrições de segurança aplicadas. A reflexão acomoda

então a necessidade dos agentes terem de ser inteligentes relativamente a

eles mesmos bem como a outros agentes.

16


Apesar do Java estar muito bem adaptado para o desenvolvimento de sistemas de

Agentes Móveis, existem algumas limitações que devemos ter em conta [11]:

1. Suporte inadequado para o controlo de recursos. O Java não possui

nenhuma forma do implementador poder controlar os recursos que um

objecto Java consome. Isto expõe o sistema a ataques do tipo Denial of

Service (DoS), no qual um agente pode consumir memória ilimitadamente,

por exemplo, através da execução de um ciclo infinito “roubando” desta

forma todos os recursos disponíveis e necessários ao normal funcionamento

do sistema.

2. Não existe protecção de referências. Os métodos públicos de um

objecto Java estão disponíveis a qualquer outro objecto que faça referência

a si. Isto é importante para os agentes uma vez que estes não têm noção de

quantos nem de quais agentes se encontram a aceder aos seus objectos. A

solução encontrada para este problema foi a utilização de agent proxies

responsáveis pelo filtro de acessos aos objectos do agente.

3. Não existe suporte para guardar e carregar um estado de execução.

Actualmente é impossível em Java obter o estado de execução completo de

um objecto. Informação como o estado do contador do programa e da

frame stack são permanentemente território proibido para programas em

Java. É então impossível para um Agente Móvel retomar a sua exacta

computação num novo host (mobilidade forte). O agente deve basear-se em

atributos internos e no registo de eventos externos que informem o novo

host do ponto de execução a partir do qual deve retomar (mobilidade fraca).

4.2 Aglets

17


Aglets é uma biblioteca de desenvolvimento de aplicações com recurso a Agentes

Móveis [12].

Originalmente desenvolvida por Mitsuro Oshima e Danny Lange no IBM Tokio

Research Laboratory em 1995 [12][13], foi entretanto disponibilizada à

comunidade open source que se encarregou de lançar as versões 2.x desta toolkit

[12]. O nome Aglets surge da junção das palavras agent + applets devido ao

facto de ter sido criado como uma reflexão do modelo aplicado às applets [13].

Os aglets diferem das applets na medida em que são programas Java que se

movem entre hosts, guardando o seu estado ao longo do caminho e podendo

inclusivé voltar ao host inicial. Enquanto que as applets são sempre executadas

num browser, os aglets correm num aglet server.

O SDK Aglets inclui a Aglets API, documentação, aglets exemplo e o aglet server

denominado Tahiti.

Tahiti é uma aplicação executada como um agent server. Possui um GUI muito

fácil de utilizar que permite ao utilizador criar, enviar e eliminar agentes assim

como definir os acessos dos agentes aos agent servers.

18


O modelo definido pela Aglets API compreende uma série de abstracções que tem

como objectivo tomar partido das vantagens que a linguagem Java oferece no que

refere a agentes, assim como ultrapassar as desvantagens identificadas

anteriormente. Assim, são apresentados de seguida os elementos base da

framework [11]:

1. Aglet. Um aglet é um objecto Java móvel que visita hosts que executam

aglet servers. É autónomo, pois inicia a sua execução numa thread

independente assim que chega a um novo host, e reactivo, devido à sua

capacidade de responder a mensagens recebidas.

2. Proxy. Um proxy representa um aglet. Funciona com um escudo protector

que controla o acesso exterior aos métodos públicos do agente. O proxy

19

Figura 3: GUI do aglet server Tahiti


pode também servir para esconder a localização real do aglet.

3. Context. Um contexto (context) constitui a área de trabalho do aglet. É um

objecto estacionário que fornece os meios para manter e gerir aglets num

ambiente uniforme onde o host se encontra seguro contra agentes

maliciosos. Cada aglet server pode conter vários contexts.

4. Message. Uma mensagem (message) é um objecto trocado entre aglets.

Permite a troca síncrona e assíncrona de mensagens entre aglets para

colaboração e troca de informação sem necessidade de uma ligação

contínua entre os mesmos.

5. Future reply. Uma resposta futura (future reply) é usada no envio

assíncrono de mensagens como um handler para receber um resultado

numa altura futura assincronamente.

6. Identifier. A cada aglet está associado um identificador (identifier). Este

identificador é globalmente único e imutável ao longo do clclo de vido do

aglet.

De seguida são sumarizadas as operações fundamentais dos aglets,

nomeadamente criação, clonagem, envio, retracção, eliminação e envio de

mensagens, bem como a sua contextualização no ciclo de vida do aglet [11]:

1. Creation. A criação (creation) de um aglet ocorre num contexto. É atribuído

um identificador ao aglet, este é inserido no contexto e é inicializado. O

aglet começa a sua execução assim que seja inicializado.

2. Cloning. A clonagem (cloning) de um aglet produz uma cópia quase

perfeita do aglet original dentro do mesmo contexto. As únicas diferenças

residem no identificador atribuído e no facto do novo aglet reiniciar a sua

execução. De notar que as threads de execução não são clonadas.

20


3. Dispatching. O envio (dispatching) de um contexto para outro irá

despoletar a remoção do aglet do seu contexto para o inserir no contexto

destino, onde reiniciará a sua execução.

4. Retraction. A retracção (retraccion) de um aglet é a acção contrária ao

envio, isto é, consiste na acção de remover um aglet do seu actual contexto

para o inserir no contexto onde a retracção foi requerida.

5. Disposal. A eliminação (disposal) de um aglet irá parar a sua execução e

removê-lo do contexto no qual está incluído.

6. Messaging. O envio de mensagens (messaging) entre aglets envolve o

envio, recepção e manuseamento de mensagens síncrona e

assincronamente.

21

Figura 4: Ciclo de vida de um aglet e respectivas operações


5 Segurança em Agentes Móveis

Devido à sua natureza móvel e à sua utilização em redes de grande dimensão, o

uso de Agentes Móveis implica o surgimento de uma série preocupações de

segurança. Os agentes necessitam de protecção de outros agentes e dos hosts

nos quais são executados. Da mesma forma, os hosts precisam de ser protegidos

dos agentes e de outros aplicativos que possam comunicar com a plataforma

[14].

5.1 Tipos de ameaças

É possível classificar as ameaças de segurança em quatro grandes categorias

[15]:

1. Agente para Plataforma. Este grupo representa o conjunto de ameaças

nos quais os agentes exploram falhas de segurança ou lançam ataques a

uma plataforma. Este conjunto de ameaças inclui técnicas de

masquerading, DoS e acesso não autorizado.

2. Agente para Agente. Esta categoria representa o conjunto de ameaças

nos quais os agentes exploram falhas de segurança ou lançam ataques a

outros agentes. Este conjunto de ameaças inclui masquerading, acesso

não autorizado, DoS e repudiação.

3. Plataforma para Agente. Este grupo representa o conjunto de ameaças

nos quais as plataformas comprometem a segurança dos agentes. Este

conjunto de ameaças inclui masquerading, DoS, eavesdropping e

22


alteração.

4. Outros para Plataforma de Agentes. Esta categoria representa o

conjunto de ameaças nos quais entidades externas, incluindo agentes e

plataformas de agentes, ameaçam a segurança duma plataforma de

agentes. Este conjunto de ameaças inclui masquerading, DoS, acesso não

autorizado, e cópia e replicação.

Os problemas associados com a protecção dos hosts no que refere à execução de

código malicioso é já bem conhecida [14] e, como tal, não serão abordados em

detalhe neste documento (embora muitos deles sejam descritos no ponto de vista

do host).

Já o problema posto pelos hosts maliciosos que pretendem atacar os seus agentes

é de resolução bem mais complexa. Isto porque, uma vez que um agente se

encontra sob o controlo de um host que o executa, o host pode em princípio fazer

o que quiser ao agente e ao seu código [14].

Os ataques que um host malicioso pode provocar podem ser sumarizados da

seguinte forma [14][15]:

1. Masquerade. Uma plataforma pode-se “mascarar” de outra plataforma de

forma a conseguir que o agente pense que está a ser executado num host

confiável. Desta forma, o masquerade host pode danificar tanto o host ao

qual tomou a identidade, como aos agentes que o interpretam como sendo

confiável e que, por essa razão, se movimentam para ele.

2. Denial of Service. Quando um agente chega a determinada plataforma,

esta espera que o agente execute os seus pedidos honestamente,

23


efectuando uma alocação de recursos justa, de acordo com os acordos

relacionados com a qualidade de serviço. Contudo, uma plataforma

maliciosa pode ignorar os requisitos do agente e introduzir atrasos

inaceitáveis para tarefas críticas ou até terminar a sua execução sem

notificação.

3. Eavesdropping. A ameaça clássica eavesdropping envolve a intercepção e

monitorização de comunicações secretas. Esta ameaça ganha, contudo,

contornos exacerbados nos sistemas de Agentes Móveis pois a plataforma

pode observar tanto as comunicações do agente, como as suas instruções

de execução.

4. Alteração. Uma vez que o agente pode visitar várias plataformas sob

vários domínios de segurança, expondo o seu código, dados e estado a

estas plataformas, devem ser implementados mecanismos capazes de

garantir a integridade do agente. Caso esta situação não se verifique, uma

plataforma maliciosa pode alterar o código, dados ou estado do agente e

“infectar” as plataformas para as quais este migrará.

Além destes ataques, relacionados directamente com os hosts, são também

frequentes os apresentados de seguida [15]:

1. Acesso não autorizado. Utilizadores remotos, processos e agentes podem

requerer recursos para os quais não são autorizados. Este tipo de ameaça

pode ser despoletada a partir de scripts que exploram falhas de segurança

nos sistemas operativos para ganhar acesso a recursos para os quais não

possuem autorização.

2. Repudiação. A repudiação ocorre quando um agente, que se encontre a

participar numa transacção ou comunicação, afirme que essa comunicação

nunca existiu. Independentemente da repudiação se deliberada ou

24


acidental, esta pode levar a sérias disputas que podem não ser facilmente

resolvidas.

3. Cópia e Replicação. De cada vez que um agente se move de um host para

outro aumenta a sua exposição a ameaças de segurança. Uma entidade que

consiga interceptar o agente em movimento pode copiá-lo e retransmiti-lo

quantas vezes pretender simulando varios envio do agente quando só

deveria ter ocorrido um.

5.2 Medidas de prevenção

Os problemas de segurança que surgem com os Agentes Móveis são bastante

conhecidos e compreendidos pela comunidade de pesquisa da área de segurança

e, como tal, é dado grande ênfase a este assunto [14].

Têm havido várias tentativas de resolução dos problemas postos pelos Agentes

Móveis, a maior parte das quais endereçando uma parte específica do problema.

Como foi referido anterirmente, uma vez chegado a um host, o agente puco ou

nada pode fazer para evitar que o host o trate como desejar. Este problema é

normalmente conhecido como “o problema do host malicioso” [14].

Não existe uma solução universal para este problema, mas algumas soluções

parciais foram já propostas, conforme resumido nos pontos seguintes [14]:

1. Acordos contratuais. A solução mais simples (pelo menos do ponto de

vista técnico) é a de usar meios contratuais para resolver o problema dos

hosts maliciosos. Os operadores das plataformas de agentes garantem, via

25


contratos, que irão operar as suas plataformas de forma segura, não

violando a privacidade ou a integridade do agente. Contudo, provar que um

contrato foi quebrado pode não ser uma tarefa trivial.

2. Hardware confiável. Se não é possível confiar nos ambientes de execução

disponíveis uma solução óbvia é a de confiar o fornecimento de hardware a

uma entidade certificada, na forma de dispositivos (ex. Smartcards)

instalados nos hosts destino, cuja função será a de bloquear alterações que

o host possa fazer aos agentes. De notar que esta medida pode ser

ultrapassada, mas requer um esforço muito maior por parte do atacante.

3. Nós confiáveis. Ao introduzir nós confiáveis na infraestrutura onde os

Agentes Móveis podem migrar quando requerido, é possível prevenir que

seja enviada informação sensível para hosts não confiáveis, assim como se

torna possível auditar possíveis comportamentos suspeitos de hosts

maliciosos.

4. Agentes confiáveis. Ao utilizar agentes cooperantes, é obtido um

resultado semelhante ao dos nós confiáveis. A informação e a

funcionalidade pode ser dividida por vários agentes de forma a que se a

segurança um agente for comprometida não seja comprometida toda a

tarefa.

5. Auditoria de execuções. A auditoria de execuções foi proposta para

detectar modificações não autorizadas aos agentes através dos registos de

execução em cada plataforma de agentes. Cada plataforma terá de registar

um log de operações desempenhadas pelos agentes que por si passam. A

desvantagem desta abordagem é o espaço gasto e o esforço necessário

para gerir esses logs.

6. Encriptação. A criptografia assimétrica está bem adaptada para Agentes

Móveis que necessitem de enviar resultados para o seu owner ou que vá

recolhendo informação ao longo do seu percurso antes de enviar o conteúdo

26


encriptado para o seu owner. Os resultados enviados pelo agente vão sob a

forma encriptada e apenas hosts confiáveis que possuam a respectiva

chave a podem desencriptar.

7. Código ofuscado. Também conhecido como a segurança blackbox, mistura

o código de forma a que ninguém consiga perceber a sua funcionalidade.

Contudo, eventualmente após algum tempo e investindo bastante esforço é

possível que este código seja “decifrado”. Assim esta medida é proposta

como medida de protecção temporária.

8. Certificados digitais. Os certificados digitais são utilizados para permitir a

uma entidade reguladora a validação das assinaturas digitais. Os

certificados normalmente incluem um período de validade no qual podem

ser emitidas assinaturas digitais e podem ser estendidos de forma a validar

restrições relacionadas com o contexto do agente (ex. Máximo valor de uma

compra; host onde se encontra a executar).

A problemática da protecção da plataforma do agente contra agentes maliciosos

beneficia já de uma tecnologia mais madura. Isto devido ao facto de existirem

técnicas semelhantes aplicadas em questões associadas com os downloads a

partir da internet que podem ser aplicadas ao cenário dos Agentes Móveis [14]:

1. “Enclausuramento” e interpretação segura do código. O

“enclausuramento” isola as aplicações (no nosso caso os agentes) em

domínios distintos forçados pelo software. Esta técnica permite que

programas não confiáveis sejam executados no seu espaço virtual

prevenindo a sua interferência com outras aplicações. A ideia por trás da

interpretação segura do código é a de bloquear ou tornar seguros comandos

do agente considerados inseguros. O Java utiliza “enclausuramento” e

interpretação segura do código.

27


2. Código com prova de segurança. O código com prova de segurança

requere que o autor de um agente prove formalmente que o agente se

encontra em conformidade com uma determinada política de segurança. A

plataforma de execução pode verificar essa prova antes de executar o

agente sem quaisquer restrições. A desvantagem desta abordagem é a

dificuldade em gerar tais provas formais de forma automatizada e eficiente.

3. Código assinado. Ao assinar digitalmente um agente é garantida a sua

autenticidade, origem e integridade. Tipicamente a entidade que assina o

código é o autor do agente ou uma entidade reguladora. A política de

segurança na plataforma, provavelmente em conjunção com certificados

fornecidos com o código assinado, decidirá então de uma assinatura

particular significa que o código possa executado.

4. Histórico de caminhos. A ideia por trás dos históricos de caminhos é a de

possibilitar a um host saber por onde andou um determinado agente. Caso

o agente tenha andado por hosts não confiáveis, a plataforma pode decidir

não executar o agente ou simplesmente retirar-lhe privilégios.

5. Avaliação de estados. A avaliação de estados tenta assegurar que o

estado de um agente não foge dos parâmetros definidos pelo seu autor

original. Este desenvolve uma função assinada que se torna parte do código

do agente e que é responsável por efectuar uma avaliação do estado do

agente em determinado momento. A plataforma pode invocar essa função

para determinar qual o estado do agente, garantindo-lhe privilégios de

acordo com o resultado obtido.

28


6 Conclusões

Após a elaboração do presente documento de pesquisa bibliográfica, o

conhecimento do autor no que respeita à temática dos Agentes Móveis foi

adquirido com elevado grau de sucesso.

Ficaram por abordar alguns temas interessantes acerca desta área como a

controvérsia existente entre os defensores da abordagem AI de agentes vs os

cientistas da área da computação distribuída, análises comparativas entre o

ganho da utilização do paradigma de Agentes Móveis vs o conhecido modelo

cliente-servidor, a análise de frameworks de Agentes Móveis criadas mais

recentemente para aplicações específicas, estender a análise à problemática da

segurança, entre outros, para não tornar o documento demasiado extenso.

No final foram seleccionados os temas que permitem ao leitor perceber o que são

os Agentes Móveis, quais as suas funções e aplicações, quais as ferramentas com

que podem ser desenvolvidos, quais os seus riscos e quais as medidas para

precaver esses riscos.

Foi bastante gratificante para o autor conhecer e dar a conhecer esta área sendo

que, caso haja nova oportunidade, será uma área em que o mesmo investirá mais

algum tempo.

29


7 Bibliografia

[1] KOTZ, DAVID e GRAY, ROBERT S. (1999), Mobile Agents and the Future of the Internet. Hannover, New Hamsphire.

[2] PATEL R. B., MASTORAKIS, NIKOS e GARG, K. (2005), Mobile Agent Location Management in Global Networks. India e Grécia.

[3] WIKIPEDIA, THE FREE ENCYLOPEDIA (2007). Mobile Agent. http://en.wikipedia.org/wiki/Mobile_agent

[4] PAGE, JOHN (2005). Mobile Agent Security, http://www.csse.monash.edu.au/~jpage/mobile_agents.htm, Australia

[5] MILOJICIC, D. (1999). Trend Wars Mobile Agent Applications. IEEE Concurrency. Vol. 7. No. 3. 80 - 90.

[6] SCHOEMAN, MARTIN e CLOETE, ELSABÉ (2003). Architectural Components for the Efficient Design of Mobile Agent Systems. University of South Africa.

[7] VIERA, VALTER e CAMARINHA-MATOS, L. M. (1999), Agentes Móveis na Operação Remota. ISEL e UNL, Lisboa, Portugal.

[8] LANGE, DANNY B. e OSHIMA, MITSURU (1999). Seven Good Reasons for Mobile Agents. Communications of the ACM. Vol. 42, No. 3.

[9] VERSTEEG, STEVEN (1998). Comparison of Mobile Agent Toolkits for Java. Australia.

[10] OYAMADA, MÁRCIO SEIJI e ITO, SÉRGIO AKIRA (1998). Aglets: Agentes Móveis em Java. Universidade Federal do Rio Grande do Sul, Brasil.

[11] LANGE, DANNY B. e OSHIMA, MITSURU (1998). Mobile Agents with Java: The Aglet API. EUA / Japão.

30

http://en.wikipedia.org/wiki/Mobile_agent

http://en.wikipedia.org/wiki/Mobile_agent

http://www.csse.monash.edu.au/~jpage/mobile_agents.htm


[12] WIKIPEDIA, THE FREE ENCYLOPEDIA (2008). Aglets. http://en.wikipedia.org/wiki/Aglets

[13] HORVAT, D., CVETKOVIĆ, D., MILUTINOVIĆ, V., KOČOVIĆ, P. e KOVAČEVIĆ, V. (2000). Mobile Agents and Java Mobile Agents Toolkits. Jugoslávia.

[14] BORSELIUS, NIKLAS (2002). Mobile agent security. University of London.

[15] JANSEN, WAYNE e KARYGIANIS, TOM (2000). Mobile agent security. Gaithersburg, EUA.

31

http://en.wikipedia.org/wiki/Aglets

sistemas baseados em agentesasilva/page19/page7/assets/1020612_vitor hugo... · vantagens e...

Documents