sistemas baseados em agentesasilva/page19/page7/assets/1020612_vitor hugo... · vantagens e...
Post on 11-Nov-2018
214 Views
Preview:
TRANSCRIPT
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 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
ISEP – 2008 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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
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
ISEP – 2008 Agentes Móveis
[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
top related