Um modelo de diagnóstico distribuído e hierárquico para tolerância a ataques de manipulação de resultados em grades

(1)

Universidade Federal do Cear´

a

Centro de Tecnologia

Departamento de Teleinform´

atica

Programa de P´

os-Gradua¸c˜

ao em Engenharia de Teleinform´

atica

UM MODELO DE DIAGN ´

OSTICO DISTRIBU´IDO E HIER´

ARQUICO

PARA TOLERˆ

ANCIA A ATAQUES DE MANIPULAC

¸ ˜

AO DE

RESULTADOS EM GRADES COMPUTACIONAIS

Felipe Sampaio Martins

DISSERTAC

¸ ˜

AO DE MESTRADO

(2)

Universidade Federal do Cear´

a

Centro de Tecnologia

Departamento de Teleinform´

atica

Felipe Sampaio Martins

UM MODELO DE DIAGN ´

OSTICO DISTRIBU´IDO E

HIER´

ARQUICO PARA TOLERˆ

ANCIA A ATAQUES DE

MANIPULAC

¸ ˜

AO DE RESULTADOS EM GRADES

COMPUTACIONAIS

Trabalho apresentado ao Programa de Programa de P´ os-Gradua¸cão em Engenharia de Teleinformática do Depar-tamento de Teleinformática da Universidade Federal do Ceará como requisito parcial para obten¸cão do grau de Mestre em Engenharia de Teleinformática.

Orientador: Prof. Jos´e Neuman de Souza, DSc

Co-orientadores: Prof. Rossana M. de C. Andrade, PhD. e Prof. Aldri Luiz dos Santos, DSc.

(3)

M343m Martins, Felipe Sampaio

Um modelo de diagnóstico distribuído e hierárquico para tolerância a ataques de manipulação de resultados em grades computacionais / Felipe Sampaio Martins

113.:il.

Dissertação (Mestrado) Universidade Federal do Ceará, Centro de Tecnologia, Departamento de Teleinformática, Fortaleza-CE, 2006.

Orientador: Prof. José Neuman de Souza

1. Teleinformática 2. Redes e sistemas distribuídos. I.Título. II Orientador.

(4)

(5)

AGRADECIMENTOS

Gostaria de agradecer primeiramente aos meus professores orientadores Prof. Neuman, pela paciência e seriedade com a qual me conduziu nessa empreitada; a Profa. Rossana, que me acolheu, me abriu as portas e tem investido em mim, uma mulher correta, per-severante e dona de suas próprias conquistas; e ao Prof. Aldri, pela sua aten¸cão nos momentos em que compartilhamos idéias e pela pronta disposi¸cão e motiva¸cão que nele encontrei durante esse per´ıodo. Com vocês, Professores, aprendi o significado da palavra Mestre. Muito obrigado mesmo a todos vocês.

Aos professores Javam, Riverson, Miguel, Mauro e Jerffeson, membros do GREaT (Grupo de Redes de Computadores, Engenharia de Softwares e Sistemas), onde tive a oportuni-dade de trocar experiências, além de cultivar amizades inesquec´ıveis. Muito obrigado a vocês todos, em especial, Lincoln, Flávio, Rute, Diana e Marcos.

Aos mais que colegas de trabalho do CENAPAD-NE (Centro Nacional de Processamento de Alto Desempenho no Nordeste): Bringel, pelo exemplo de caráter e retidão dado nesse per´ıodo de convivência, João Marcelo, pelas risadas e descontra¸cão no dia a dia, e ao Marcio Maia, cuja participa¸cão foi decisiva na reta final do trabalho e une-se agora ao grupo, trazendo sua experiência e alegria.

A Marcus Rodrigues, Moacyr Regys, Janine Costa e todos os ex-companheiros do LAR (Laborat´orio Multiinstitucional de Redes e Sistemas) do CEFET-CE, onde fui despertado para a pesquisa cient´ıfica.

Aos professores Walfredo, Fubica e todos do LSD (Laboratório de Sistemas Distribu´ıdos) na Universidade Federal de Campina Grande, sempre dispostos e receptivos nas dis-cussões. Aos professores Elias e Albini da Universidade Federal do Paraná que leram os primeiros esbo¸cos da idéia e me motivaram ainda mais para seguir em frente. Aos professores Heron e Helano da Universidade Federal do Ceará, que me ofereceram cr´ıticas positivas que só vieram para melhorar este trabalho. Agrade¸co também a professora Mi-chele Nogueira que me socorreu com aten¸cão e presteza em momentos de desespero.

A Jacinta Pereira, que, apesar do pouco contato, foi ´otima e essencial para o sucesso dos artigos aprovados.

(6)

AGRADECIMENTOS iv Aos meus amigos das noites (Adson, Alexandre, Aline, Ayla, Carla, Cotó, Daniel, Denise, Edson, Eduardo, Elo´ıse, Emanuel, George, Gorete, Joelma, Josué, Juliana, Kelly, Leo-nardo, Manu, Márcia, Marcus Fábio, Marley, Marquinhos, Saulo, Sérgio, Rafael, Renati-nha, Robério, Thais, Tião, Tici, Ticiano e Wagner), que fizeram das situa¸cões dramáticas momentos felizes.

Ao Wraculles, amigo inspirador de todas as horas, sempre disposto a levantar o astral. A Adriana, minha amiga. Você me deu for¸cas e gra¸cas a você cá estou.

A Larry Page e Sergey Brin.

A minha fam´ılia, em especial a minha querida avó Jacyara, um exemplo de vida e de-dica¸cão. Sou o que sou por sua causa, vó.

A FUNCAP (Funda¸cão Cearense de Apoio ao Desenvolvimento Cient´ıfico e Tecnológico) pelo apoio financeiro sem o qual esse trabalho não teria sido poss´ıvel.

(7)

Se n˜ao tivesse o amor

Se n˜ao tivesse essa dor

E se n˜ao tivesse o sofrer

E se n˜ao tivesse o chorar

Melhor era tudo se acabar

(8)

RESUMO

A seguran¸ca da informa¸cão em grades computacionais envolve requisitos que vão além dos estabelecidos para as redes convencionais. Tratando-se especificamente de Integridade, a maioria das solu¸cões existentes resolve essa questão apenas no escopo de transmissão, garantindo a não-viola¸cão dos dados durante a comunica¸cão entre as máquinas. Todavia, é preciso também garantir a integridade dos dados durante o seu processamento, de modo que os resultados das tarefas (jobs) processados em uma grade não sofram qualquer altera¸cão indevida. De outra forma, a manipula¸cão de resultados compromete a aplica¸cão como um todo, incidindo num alto custo em termos de desempenho.

Para evitar que usuários obtenham resultados incorretos em virtude de elementos maliciosos, esta disserta¸cão propõe um modelo de diagnóstico para tolerância a falhas de seguran¸ca em grades computacionais de larga escala, abordando a verifica¸cão de integri-dade na execu¸cão dosjobs. Desta forma, é poss´ıvel excluir as unidades de processamento (nós) de má conduta interessadas em comprometer as aplica¸cões, oferecendo, portanto, um ambiente de computa¸cão de alto desempenho formado apenas por nós confiáveis.

A utiliza¸cão de diagnóstico em n´ıvel de sistema como estratégia contra ataques de manipula¸cão de resultados de jobs mostra-se uma solu¸cão eficaz, visto que independe das plataformas de hardware utilizadas e é interoperável com solu¸cões de seguran¸ca locais, o que viabiliza seu emprego na maioria das middlewares de grades computacionais. Além disso, o modelo de diagnóstico aqui apresentado organiza os nós em clusters lógicos, estabelecendo assim uma hierarquia entre os mesmos, de acordo com o papel de cada nó (executor, testador ou ultra-confiável), atribu´ıdo segundo seu histórico comportamental no ambiente. Essa abordagem permite que o diagnóstico seja feito de forma distribu´ıda com a participa¸cão dos nós que possuem um n´ıvel m´ınimo de confiabilidade.

Para validar esta estratégia, uma nova camada de seguran¸ca foi implementada em um simulador de grades, a fim de introduzir as asser¸cões e os comportamentos descritos no modelo proposto. Os resultados obtidos atestam a sua eficácia em cenários com diferentes taxas de nós mal intencionados, oferecendo um ´ındice de deteçcão de 100% e acurácia de 99,7% dos jobs processados, com 12,3% de custo de processamento.

(9)

ABSTRACT

Information security in grid computing involves requirements that go beyond the tradi-tional networks. Concerning specifically Integrity, most of existing solutions deal with it only during data transmission, ensuring non-violation of data in the communication between machines. Nevertheless, it is also necessary to guarantee data integrity during its processing, so that jobs results must not suffering any improper handling. Otherwise, the results manipulation compromises the application as a whole, also causing a high processing overhead.

In order to avoid that grid users obtain uncorrected results due to malicious elements, this work proposes a diagnosis model for tolerating security faults in large-scale computational grids, considering the integrity verification during job processing. In this way, it is possible to exclude those misbehaving processing units (nodes) interested in damaging the execution of processes, providing thus a high performance computing environment only formed by reliable nodes.

The usage of system-level diagnosis as a strategy against jobs results manipu-lation attacks reveals itself an efficient solution, since it does not depend on the hard-ware platform and it is interoperable with security local solutions. This feature allows the employment of the proposed model at the majority of grid computing middlewares. Furthermore, the proposed diagnosis model organizes the nodes into logical clusters, esta-blishing a hierarchy among them, in accordance to the role of each node (executor, tester or ultra-reliable), assigned through its historical behavior in the environment. This ap-proach enables diagnosis to be made in a distributed way with the participation of nodes that provide an expected degree of confidence.

To validate this strategy, a new security layer was implemented in a grid simulator in order to introduce the assertions and the behaviors described in the proposed model. The results testify the effectiveness of the model at scenarios with different quotas of malicious nodes, providing a rate of detection of 100% and accuracy of 99,7% of processed jobs, with 12,3% of overhead.

(10)

SUM´

ARIO

Cap´ıtulo 1—Introdu¸c˜ao 1

1.1 Caracteriza¸c˜ao do Problema e Motiva¸c˜ao . . . 1

1.2 Objetivo e Contribui¸c˜ao . . . 3

1.3 Trabalhos Relacionados . . . 3

1.4 Estrutura da Disserta¸c˜ao . . . 7

Cap´ıtulo 2—Grades Computacionais 8 2.1 As Grades e os Servi¸cos de Alto Desempenho . . . 8

2.2 Arquiteturas de Processamento de Alto Desempenho . . . 11

2.3 Aspectos da Implementa¸c˜ao de Arquiteturas de Grade . . . 13

2.3.1 Descoberta de Servi¸cos . . . 14

2.3.2 Escalonamento de Aplica¸c˜oes . . . 15

2.3.3 Autentica¸c˜ao e Autoriza¸c˜ao . . . 17

2.3.4 Prote¸c˜ao dos Recursos e Aplica¸c˜oes . . . 18

2.4 Seguran¸ca em Grades . . . 19

2.4.1 Seguran¸ca no Globus Toolkit . . . 20

2.4.2 Seguran¸ca no OurGrid . . . 22

(11)

SUM ´ARIO ix

Cap´ıtulo 3—Diagn´ostico em N´ıvel de Sistema 25

3.1 Tipos de Falhas . . . 25

3.2 Classifica¸c˜ao de N´os com Mau Comportamento . . . 26

3.3 Confiabilidade e Seguran¸ca . . . 26

3.4 T´ecnicas para Verifica¸c˜ao de Integridade de Processamento . . . 27

3.5 Diagn´ostico . . . 29

3.5.1 Modelo PMC . . . 30

3.5.2 Algoritmo Adaptative-DSD . . . 32

3.5.3 Algoritmo Hi-ADSD . . . 33

3.5.4 Modelos Baseados em Compara¸c˜oes . . . 34

3.6 Diagn´ostico em Grades . . . 36

3.7 Conclus˜ao . . . 38

Cap´ıtulo 4—Um Modelo para Diagn´ostico em Grades 39 4.1 Caracter´ısticas do Modelo . . . 39

4.2 Especifica¸c˜ao . . . 40

4.3 Opera¸c˜ao de Diagn´ostico . . . 43

4.4 C´alculo da Reputa¸c˜ao . . . 46

4.5 Reconfigura¸c˜ao de Clusters . . . 48

4.6 Conclus˜ao . . . 49

Cap´ıtulo 5—Avalia¸cão do Modelo 51 5.1 Caracteriza¸cão da Simula¸cão . . . 51

(12)

SUM ´ARIO x

5.1.2 Parˆametros Utilizados na Simula¸c˜ao . . . 52

5.2 Cen´arios Estudados . . . 53

5.2.1 Cen´ario sem Esquema de Reputa¸c˜ao . . . 53

5.2.2 Cen´ario com Esquema de Reputa¸c˜ao . . . 61

5.3 Conclus˜ao . . . 71

Cap´ıtulo 6—Conclus˜oes 73 6.1 Contribui¸c˜oes e Resultados . . . 73

6.2 Trabalhos Futuros . . . 74

Apˆendice A—Simuladores de Grades 86 A.1 OptorSim . . . 86

A.2 GridNet . . . 86

A.3 MicroGrid . . . 87

A.4 SimGrid . . . 87

A.5 GridSim . . . 88

A.6 Compara¸c˜ao Entre Simuladores . . . 88

Apêndice B—Programa de Simula¸cão 90 B.1 Execu¸cão de uma Rodada de Testes . . . 90

B.2 Verifica¸c˜ao de uma Rodada de Testes . . . 91

B.3 Pesquisa por Padr˜ao de Comportamento do Testador . . . 92

B.4 Verifica¸cão e Eleva¸cão do Status dos Nós . . . 93

(13)

LISTA DE ABREVIATURAS

ACL - Access Control List

ADSD - Adaptative Distributed System-Level Diagnosis API - Application Program Interface

BoT - Bag-of-Tasks

CA - Certificate Authority CPU - Central Processing Unit FIFO - First In First Out

GSI - Globus Security Infrastructure GSS - Generic Security Services

Hi-ADSD - Hierarchical Adaptative Distributed System-Level Diagnosis HTC - High-Throughput Computing

HTTP - Hyper Text Transfer Protocol JVM - Java Virtual Machine

MM - Maeng, Malek

MPP - Massively Parallel Processors NoW - Network of Workstations NS - Network Simulator

P2P - Peer-to-Peer

(14)

LISTA DE ABREVIATURAS xii SOAP - Simple Object Access Protocol

SSL - Secure Socket Layer UC - Ultra-Confi´avel

UDDI - Universal Description, Discovery and Integration VO - Virtual Organizations

WQR - Workqueue with Replication

(15)

LISTA DE FIGURAS

2.1 Representa¸c˜ao da topologia de clusters . . . 8

2.2 VOs intercontinentais . . . 9

2.3 Grade de servi¸cos . . . 10

2.4 Arquitetura SMP . . . 11

2.5 Arquitetura MPP . . . 12

2.6 Arquitetura NoW . . . 12

2.7 Arquitetura de uma grade computacional de larga escala . . . 13

2.8 Descoberta dinˆamica de servi¸cos via Web Services . . . 15

2.9 Assinatura digital no GSI . . . 21

2.10 T´ecnica Sandbox . . . 23

3.1 Voto majorit´ario com 6 n´os fornecedores de recursos . . . 28

3.2 Poss´ıvel s´ındrome para um sistema baseado em testes distribu´ıdos . . . . 30

3.3 Exemplo de grafo do sistema e grafo de testes para 4 n´os . . . 31

3.4 Grafo de testes no ADSD . . . 32

3.5 Divis˜ao de clusters no Hi-ADSD . . . 33

3.6 Funcionamento do modelo MM . . . 35

3.7 Funcionamento do modelo de Compara¸c˜oes Generalizado . . . 35

(16)

LISTA DE FIGURAS _xiv

4.1 Eleva¸c˜ao de status dos n´os . . . 41

4.2 Estrat´egia de testes aplicados aos n´os da grade . . . 43

5.1 Estratégia de diagnóstico sem reputa¸cão . . . 54

5.2 Acur´acia obtida com 1/6 dos n´os maliciosos . . . 55

5.5 Quantidade de n´os inseridos na blacklist . . . 57

5.6 N´os maliciosos detectados com 1/6 da grade comprometida . . . 58

5.9 Custo introduzido com 1/6 dos n´os maliciosos . . . 60

5.12 N´os inseridos na blacklist com 1/6 de maliciosos . . . 64

5.15 N´os maliciosos detectados com rodada de testes a cada 6h . . . 66

5.18 N´os maliciosos remanescentes com rodada de testes a cada 6h . . . 67

(17)

LISTA DE FIGURAS _xv

(18)

LISTA DE TABELAS

3.1 Unidades testadoras falhas emitem resultados indeterminados . . . 30

4.1 Determina¸c˜ao de status dos n´os . . . 47

4.2 O vetor identifica o estado dos n´os em cada cluster . . . 49

5.1 N´os maliciosos detectados no pior e no melhor caso . . . 59

5.2 Valores para eleva¸c˜ao de status . . . 62

(19)

CAP´ITULO 1

INTRODUC

¸ ˜

AO

Esta disserta¸cão apresenta um modelo de diagnóstico para verifica¸cão de integridade de resultados de tarefas (jobs) submetidas a um ambiente de grade computacional. Este modelo visa prover um eficiente mecanismo de tolerância a ataques de manipula¸cão, seja em plataformas de grades fechadas (e.g., Globus Toolkit) ou abertas (e.g., OurGrid), evi-tando a presen¸ca de elementos (nós) maliciosos interessados em invalidar ou corromper o resultado dos jobs. Assim, através da deteçcão de manipula¸cão maliciosa de resulta-dos, o modelo proposto permite que nós mal intencionados sejam isolados da grade, não comprometendo o processamento das aplica¸cões como um todo.

Neste cap´ıtulo, são apresentadas a justificativa e a motiva¸cão para o desenvol-vimento desta disserta¸cão, bem como os objetivos e as contribui¸cões que se pretende alcan¸car. Em seguida, são discutidos os trabalhos relacionados nas áreas de seguran¸ca em grades, sistemas de reputa¸cão, diagnóstico em n´ıvel de sistema e tolerância a falhas em grades. Por fim, é dada uma descri¸cão de como está organizado o restante desta disserta¸cão.

1.1 CARACTERIZAÇ ÃO DO PROBLEMA E MOTIVAÇ ÃO

(20)

1.1. Caracteriza¸c˜ao do Problema e Motiva¸c˜ao 2

O provimento de seguran¸ca nas redes tradicionais envolve a utiliza¸cão de meca-nismos que, em geral, impedem o acesso não autorizado de usuários e provêem sigilo e integridade dos dados transmitidos [2, 3]. No contexto da computa¸cão em grade, a ado¸cão de tais mecanismos é mais complexa, em virtude da intr´ınseca natureza heterogênea do ambiente, que incorpora requisitos de seguran¸ca diversos.

Além disso, deve-se considerar que as grades podem ser formadas por diferentes redes, com diferentes dom´ınios administrativos e, por consegüinte, diferentes pol´ıticas de seguran¸ca. Desta maneira, garantir a seguran¸ca da informa¸cão em ambientes deste tipo envolve novos requisitos, sendo assim uma tarefa complexa.

Tais requisitos têm sido atendidos e tratados de diferentes formas na literatura. Algumas solu¸cões propostas visam, por exemplo, garantir confidencialidade e integridade na comunica¸cão entre os elementos de rede que compõem a grade [4, 5]. O controle de acesso aos recursos também tem sido bastante estudado [6, 7]. No que diz respeito à integridade da informa¸cão, a maioria dos trabalhos têm tratado essa questão apenas no âmbito da transmissão, garantindo a não-viola¸cão dos dados durante a comunica¸cão entre as máquinas [8, 9].

Todavia, para oferecer seguran¸ca em grades é necessário também garantir a in-tegridade dos dados durante o seu processamento, de forma que os resultados dos jobs

processados em uma grade não devem sofrer qualquer altera¸cão indevida. Logo, uma infra-estrutura deste porte precisa certificar-se de que as máquinas que compõem a grade não são constitu´ıdas porhosts maliciosos interessados em invalidar ou corromper o resul-tado de umjob. Do contrário, a manipula¸cão de resultados pode comprometer o processo como um todo, além de incidir num alto custo em termos de desempenho.

(21)

1.2. Objetivo e Contribui¸c˜ao 3

1.2 OBJETIVO E CONTRIBUIC¸ ˜AO

Este trabalho propõe um modelo de diagnóstico para tolerância a falhas de seguran¸ca em grades computacionais de larga escala, abordando a verifica¸cão de integridade na execu¸cão dosjobs processados. O objetivo do modelo consiste em garantir a validade dos resultados dos jobs procesados e excluir os nós de má conduta que estejam interessados em prejudicar a execu¸cão dos processos e, desta forma, comprometer o desempenho das aplica¸cões em grade.

A solu¸cão aplica o paradigma de tolerância a falhas no dom´ınio da seguran¸ca, à medida que propõe um modelo de diagnóstico em n´ıvel de sistema, mediante uma abordagem distribu´ıda e hierárquica para verifica¸cão de integridade na execu¸cão dos

jobs. Distribu´ıda porque o diagnóstico é realizado por todos os nós do sistema com o n´ıvel m´ınimo de confiabilidade requerido para tal, e hierárquico porque os papéis dos nós são atribu´ıdos de acordo com a reputa¸cão adquirida através dos seus comportamentos dentro do ambiente.

A principal contribui¸cão do modelo apresentado é a aplica¸cão de técnicas de to-lerância a falhas de seguran¸ca para deteçcão de ataques de manipula¸cão dos resultados dos jobs em grades computacionais. Este modelo pode ser integrado às principais plata-formas de grades, tais como Globus [10] e OurGrid [11].

Para sua valida¸cão, o modelo é submetido a uma ferramenta de simula¸cão de ambientes de grades chamada GridSim, onde cenários representativos são avaliados a fim de determinar sua eficiência e robustez. Assim, uma contribui¸cão secundária é a extensão do simulador de grades utilizado, visto que novos métodos foram incorporados, a fim de suportar os mecanismos empregados no modelo proposto.

1.3 TRABALHOS RELACIONADOS

(22)

sobre-1.3. Trabalhos Relacionados 4

carga, bugs de firmware, interrup¸c˜ao da comunica¸c˜ao e bad blocks de discos, excluindo, portanto, falhas de natureza intencionalmente maliciosas.

Já em Duarte et al [13], os autores propõem um mecanismo para identifica¸cão das causas das falhas em ummiddleware de grade. Assim, através de uma abordagem baseada em diagnóstico, pode-se conhecer os motivos que levaram determinados componentes de

software ao mau funcionamento e ent˜ao descobrir se as falhas sinalizadas por aquele componente foram originadas realmente por ele ou por um outro componente que lhe oferece algum servi¸co.

Um algoritmo para verifica¸cão de integridade em grades é apresentada em Santos et al [14]. O Anti-Doping, como os seus autores o chamam, consiste em uma série de testes executados por cada unidade de processamento provedora de recurso. O diagnóstico ob-tido pelos testes pode ser utilizado para gerenciar informa¸cões sobre os recursos dossites. O resultado dos testes é disponibilizado no formato XML para que cada administrador desite conhe¸ca o grau de confiabilidade de suas máquinas. Esta abordagem, no entanto, foi idealizada especificamente para a grade OurGrid e não chegou a ser implementada nem simulada.

Ainda tratando-se de tolerância a falhas, um algoritmo de diagnóstico também é apresentado em Caruso et al [15] para conhecer quais as unidades de processamento que estão falhas em um sistema em grade. Entretanto, este trabalho considera como grade uma plataforma de hardware com diversos processadores interligados em malha, ou seja, não há heterogeneidade nem alta dispersão geográfica e, portanto, os resultados dosjobs

não estão sujeitos a ataques de manipula¸cão.

Albini [16] propõe um algoritmo para diagnóstico de eventos baseado em com-para¸cões, chamado Hi-Comp. Nessa proposta, um nó envia uma tarefa para dois de seus filhos (nós que possuem liga¸cão direta) e após receber os resultados, repete o processo para outros dois filhos, até que tenha passado por todos os nós filhos. Ao diagnosticar um filho, o nó testador também obtém informa¸cões de diagnóstico do cluster ao qual o filho pertence. Embora o Hi-Comp seja capaz de diagnosticar outros tipos de falhas além decrash, ele assume que os nós testadores sem-falhas informam resultados confiáveis.

(23)

1.3. Trabalhos Relacionados 5

ambos podem qualificar um ao outro de maneira positiva, negativa ou neutra, de tal forma que a soma das qualifica¸cões recebidas determina a reputa¸cão do usuário. Neste sistema, o armazenamento e gerenciamento das qualifica¸cões são comumente centraliza-dos, acarretando em problemas t´ıpicos desta arquitetura, como por exemplo, ponto único de falha e gargalo no desempenho.

Em ambientes distribu´ıdos, como os sistemas Peer-to-Peer (P2P) para comparti-lhamento de arquivos, mecanismos de atribui¸cão e verifica¸cão de reputa¸cão têm sido cada vez mais empregados, com o intuito de minimizar a presen¸ca de peers (pares) maliciosos interessados em difundir arquivos falsos ou incompletos, ou mesmo v´ırus e worms. As-sim, o esquema de reputa¸cão permite que os pares participantes possam obter informa¸cão confiável para o download de arquivos (recursos) de qualidade.

Nesse sentido, protocolos têm sido propostos para identificar pares maliciosos em ambientes P2P, tais como [18, 19, 20, 21]. Em geral, estas abordagens baseiam-se em certos critérios para estabelecer n´ıveis de confian¸ca às entidades envolvidas, provendo assim uma informa¸cão adicional que poderá ser útil ao usuário antes de realizar odownload

desejado. A informa¸cão de reputa¸cão de um par é dada a partir das suas intera¸cões com a rede.

Em Kamvar et al [18], o algoritmo EigenTrust computa um valor de confian¸ca de um par com base nas opiniões dos demais pares que interagiram com ele, assumindo transitividade nas opiniões. Em Aberer et al [19], o protocolo proposto mantém apenas informa¸cões de feedbacks negativos que condenam a participa¸cão do par, onde ele é sim-plesmente classificado em dois n´ıveis (confiável ou não-confiável). A proposta de Cornelli et al [20], chamada P2PRep, visa estimar a confian¸ca de um dado par na rede Gnutella, a partir de vota¸cão entre os participantes. No entanto, além de necessitar de uma estrutura criptográfica para verificar as identidades dos pares, o trabalho não evidencia claramente as métricas utilizadas para o cálculo da reputa¸cão. O XRep, apresentado por Damiani et al [21], é uma extensão do P2PRep que associa um valor de reputa¸cão tanto para os pares quanto para os recursos. O XRep também utiliza vota¸cão, mas tanto os votos dos pares confiáveis quanto os dos não-confiáveis têm o mesmo peso. Além disso, assim como as demais propostas, o XRep não leva em conta o tempo de vida dos pares no ambiente de rede.

(24)

1.3. Trabalhos Relacionados 6

ou usu´ario, ou seja, qual o n´ıvel de qualidade e confiabilidade no processamento de um resultado oferecido.

Em Sarmenta [22], o autor propõe um esquema baseado na credibilidade para, através de cálculos probabil´ısticos e combina¸cão de técnicas de tolerância a falhas, ofe-recer prote¸cão contra usuários maliciosos em um ambiente de computa¸cão voluntária. Nesta abordagem, o cliente envia cada job a ser executado para diferentes unidades de processamento até que pelo menos um determinado número m de resultados devolvidos sejam coincidentes. Através da compara¸cão entre eles, a validade do resultado é atestada. Assim, as unidades de processamento provedoras de recursos ganham mais confian¸ca à medida que agem corretamente no ambiente. Uma outra possibilidade de aplica¸cão de testes, é o envio periódico de tarefas cujos resultados são previamente conhecidos para provar o comportamento das unidades de processamento.

Essa técnica, também conhecida como verifica¸cão focalizada, assemelha-se às abordagens encontradas em trabalhos como Casale et al [23] e Zhao et al [24]. No entanto, todas estas solu¸cões são essencialmente centralizadas, o que ocasiona um custo para o

host gerente responsável pelos testes, tendo em vista que todo job de teste também é processado pelo gerente. No caso da verifica¸cão baseada em replica¸cão, é observado um alto overhead e desperd´ıcio de recursos, à medida que os mesmos jobs são entregues a, no m´ınimo, m unidades de processamento.

A grade OurGrid também utiliza o conceito de reputa¸cão, mas em outro contexto. Nesse caso, a verifica¸cão de reputa¸cão é empregada para incentivar a doa¸cão de recursos computacionais ociosos e minimizar a presen¸ca de usuários que apenas consomem recur-sos, sem colaborar com a comunidade. Desta forma, o OurGrid monta o que é chamado de Rede de Favores [25], onde cada par calcula uma reputa¸cão local para cada outro par, a partir do total de favores que ele fez e recebeu no passado. Este cálculo permite que os pares doadores dêem maior prioridade de execu¸cão às entidades que mais contribuem com os outros participantes. No OurGrid este sistema autônomo permite que os pares utilizem somente informa¸cão local para priorizar seus consumidores, eliminando a necessidade de obter um valor global de reputa¸cão, diferentemente dos sistemas de gerenciamento de reputa¸cão anteriormente discutidos. Reputa¸cão autônoma tem se mostrado, portanto, um mecanismo eficiente em grades computacionais.

(25)

partici-1.4. Estrutura da Disserta¸c˜ao 7

pantes. Em vez disso, cada par analisa a credibilidade dos demais integrantes da grade conforme suas intera¸cões passadas com os mesmos, eliminando a necessidade de um pro-tocolo de obten¸cão da informa¸cão de reputa¸cão de um par e a preocupa¸cão com a validade da informa¸cão obtida, já que a mesma encontra-se à disposi¸cão localmente.

Com a introdu¸cão desse conceito de reputa¸cão é poss´ıvel ainda tornar o modelo hierárquico, dificultando a possibilidade de um nó com boa reputa¸cão não ser apanhado ao fornecer resultados corrompidos. Além disso, o modelo proposto permite uma sens´ıvel economia de recursos já que não há replica¸cão de jobs entre os nós.

1.4 ESTRUTURA DA DISSERTAC¸ ˜AO

Este trabalho está organizado da seguinte forma: no Cap´ıtulo 2, são abordados os prin-cipais conceitos envolvidos em grades computacionais, evidenciando aspectos e funciona-lidades como descoberta de servi¸cos, autentica¸cão e autoriza¸cão dos usuários, escalona-mento e prote¸cão das aplica¸cões e máquinas. Além disso, são investigados os requisitos e mecanismos de seguran¸ca oferecidos por diferentes plataformas, em especial o Globus e o OurGrid.

O Cap´ıtulo 3 trata dos conceitos envolvidos em tolerância a falhas e modelos de diagnóstico em n´ıvel de sistema, discutindo as vantagens e desvantagens de cada modelo apresentado. Também são apresentados os tipos de falhas encontradas em grades, as técnicas para verifica¸cão de integridade de processamento que podem ser aplicadas nestes ambientes e uma breve taxonomia de nós com mau comportamento.

No Cap´ıtulo 4 são explanadas as caracter´ısticas e funcionalidades do modelo de diagnóstico proposto, apresentando sua especifica¸cão, a estratégia utilizada para a aplica¸cão de testes no processo de diagnóstico e o cálculo do ´ındice de confiabilidade dos nós.

A valida¸cão do modelo realizada através de simula¸cão, bem como os resultados obtidos, são apresentados no Cap´ıtulo 5.

(26)

CAP´ITULO 2

GRADES COMPUTACIONAIS

Neste cap´ıtulo são discutidas as caracter´ısticas pertinentes a um ambiente de grade com-putacional, destacando funcionalidades como descoberta e acesso aos servi¸cos, auten-tica¸cão/autoriza¸cão dos usuários, e prote¸cão dos dados. Também são abordadas as tec-nologias que permitem a cria¸cão de uma infra-estrutura de grade e as especifica¸cões para sua padroniza¸cão, bem como os requisitos e mecanismos de seguran¸ca oferecidos por duas das principais plataformas de grades, Globus Toolkit e OurGrid.

2.1 AS GRADES E OS SERVIC¸ OS DE ALTO DESEMPENHO

Até meados da década passada, a computa¸cão de alto desempenho era realizada somente através do uso de supercomputadores. Por tratar-se de uma arquitetura robusta, com diversos processadores e grande quantidade de memória, a aquisi¸cão destas máquinas possui custo elevado e muitas vezes inviável.

Como alternativa, surgiu a proposta de dispor um conjunto de processadores interconectados por uma rede de alta velocidade, formando o que se chamacluster. Desta forma, os processos são divididos em tarefas (jobs) que são distribu´ıdas entre as unidades de processamento fornecedoras de recursos (nós). Uma arquitetura baseada em clusters

é normalmente constitu´ıda por ambientes locais, onde as unidades encontram-se em um mesmo dom´ınio administrativo. Esta abordagem é ilustrada pela Figura 2.1, onde os nós, controladas pelo mesmofront-end, são responsáveis pela execu¸cão dos jobs.

(27)

2.1. As Grades e os Servi¸cos de Alto Desempenho 9

A necessidade de uma distribui¸cão mais ampla da computa¸cão de alto desem-penho, utilizando inclusive recursos ociosos de máquinas independentes e remotas em vários dom´ınios, motivou a cria¸cão de uma tecnologia que fornecesse uma infra-estrutura descentralizada e flex´ıvel para execu¸cão de aplica¸cões paralelas.

Esta nova modalidade de computa¸cão distribu´ıda, conhecida como computa¸cão em grade (grid computing), requer a agrega¸cão, sele¸cão e coordena¸cão dos recursos com-putacionais envolvidos nos diversos dom´ınios, visando a solu¸cão de problemas de uma dada institui¸cão de forma colaborativa. Logo, a principal diferen¸ca entre a computa¸cão em grades e os sistemas distribu´ıdos convencionais é que a primeira preocupa-se com o compartilhamento de recursos em larga escala orientado ao alto desempenho [1]. Não importa que tais recursos estejam geograficamente separados; mas sim que estes mes-mos recursos possam ser acessados de maneira transparente, possibilitando a cria¸cão de verdadeiras “Organiza¸cões Virtuais”.

Sabendo que a computa¸cão em grades aproveita-se dos diversos recursos pulveri-zados entre os diversos dom´ınios, o usuário membro de uma Organiza¸cão Virtual (VO) constitu´ıda, por exemplo, de centros de computa¸cão espalhados em universidades dos cinco continentes, pode submeter o seu problema computacional para a comunidade e, assim, utilizar os diferentes recursos de cada centro, permitindo, inclusive, o trabalho co-operativo entre os pesquisadores, como ilustrado na Figura 2.2, onde f´ısicos de diferentes institui¸cões compartilham softwares, ciclos de CPU, espa¸co em disco e schemas.

(28)

2.1. As Grades e os Servi¸cos de Alto Desempenho 10

Em um n´ıvel mais alto de abstra¸cão, as grades computacionais podem ser vistas como uma rede na qual o usuário se conecta a fim de obter servi¸cos computacionais que exigem recursos sob demanda para executar, de forma transparente, aplica¸cões que tra-balham, por exemplo, com processamento de v´ıdeo, renderiza¸cão de imagens e simula¸cões f´ısico-qu´ımicas, como ilustrado a Figura 2.3.

Figura 2.3 Grade de servi¸cos

Pesquisas e implementa¸cões têm sido realizadas e diversas grades, tais como Fu-sionGrid [26], GridPP [27] e GriPhyN [28], já estão em produ¸cão. Em paralelo ao seu desenvolvimento, as redes em grades têm despertado o interesse da comunidade cient´ıfica e da indústria, posicionando-se como forte estratégia para a computa¸cão em geral e não apenas para alto desempenho. Nos últimos anos, grandes projetos como Globus Alliance [10] e TeraGrid [29] foram iniciados e aplica¸cões vêm sendo desenvolvidas para materia-lizar a visão das grades computacionais. Nesse sentido, a comunidade cient´ıfica tem se empenhado em estudos que visam a implementa¸cão de sistemas complexos,frameworks e aplica¸cões a partir da tecnologia em grades, tais como portaisweb [30, 31, 32], simula¸cão de colisão de buracos negros [33, 34], sistemas de tele-imersão para visualiza¸cão da qua-lidade da água em ecossistemas [35], video-games interativos para múltiplos jogadores simultâneos [36], análise de conteúdo multim´ıdia [37], previsão de cataclismos [38], entre outros.

(29)

2.2. Arquiteturas de Processamento de Alto Desempenho 11

Do ponto de vista de servi¸cos de seguran¸ca, falhas na especifica¸cão das confi-gura¸cões e pol´ıticas de acesso ao ambiente podem ser exploradas por usuários externos ou internos, a fim de obter acesso não autorizado aos recursos computacionais. Tais falhas nos sistemas em grade podem causar impacto em diferentes n´ıveis [39].

A seguir são discutidas a evolu¸cão e as principais caracter´ısticas das arquiteturas existentes para o processamento de aplica¸cões de alto desempenho.

2.2 ARQUITETURAS DE PROCESSAMENTO DE ALTO DESEMPENHO

No contexto de processamento de alto desempenho, as arquiteturas de execu¸cão para aplica¸cões paralelas podem diferir em diversos aspectos, tais como conectividade (atri-butos do canal de comunica¸cão que interliga os processadores), heterogeneidade (dife-ren¸cas entre os processadores), escalabilidade (quantidade de processadores), entre ou-tros. Sendo assim, as arquiteturas de processamento paralelo podem ser classificadas em quatros grupos de acordo com essas caracter´ısticas [40].

O primeiro grupo é o SMP (Symmetric Multiprocessor), formado por máquinas multiprocessadas, cujas CPUs compartilham a mesma área de memória e barramento, como ilustrado na Figura 2.4. Tal arquitetura é considerada fortemente acoplada, tendo em vista que se trata de processadores fisicamente próximos e que interagem por meio de redes de comunica¸cão de alta velocidade [41]. Embora esta forma de disposi¸cão dos processadores apresente boa conectividade, ela possui limita¸cões de escalabilidade, já que em geral é constitu´ıda por, no máximo, algumas poucas dezenas de processadores.

Figura 2.4 Arquitetura SMP

(30)

2.2. Arquiteturas de Processamento de Alto Desempenho 12

proprietária de alta velocidade e controladas por um escalonador de tarefas [42]. Tais máquinas são, portanto, altamente escaláveis com suporte a inúmeros processadores, po-dendo chegar à ordem de milhares, como no caso dos supercomputadores MPP de terceira gera¸cão Cray XT3 [43].

Figura 2.5 Arquitetura MPP

No terceiro grupo, a arquitetura NoW (Network of Workstations), por sua vez, também agrega um conjunto de processadores independentes. No entanto, diferente-mente do MPP, em uma NoW cada unidade possui seu próprio escalonador. Na verdade, uma arquitetura NoW é constitu´ıda por várias esta¸cões de trabalho interligadas por uma rede tradicional (comumente Ethernet), como mostrado na Figura 2.6. Por esse motivo, as NoWs são consideradas arquiteturas fracamente acopladas. Essa disposi¸cão “clusterizada” permite o uso de esta¸cões de trabalho de propósito geral voltadas para a computa¸cão de alto desempenho a um custo comparativamente baixo em rela¸cão ao uso de supercomputadores.

Figura 2.6 Arquitetura NoW

(31)

2.3. Aspectos da Implementa¸c˜ao de Arquiteturas de Grade 13

Figura 2.7 Arquitetura de uma grade computacional de larga escala

Vale ressaltar que as caracter´ısticas arquiteturais de cada um dos grupos podem impactar no desempenho das aplica¸cões. Por exemplo, uma aplica¸cão paralela de alta granularidade (diversosjobs no mesmo contexto de uma tarefa, cooperando entre si) pode consumir maior tempo de execu¸cão se submetida a uma arquitetura fortemente acoplada [41]. Além disso, é poss´ıvel afirmar que a evolu¸cão das arquiteturas de processamento paralelo com vistas ao alto desempenho tem caminhado para uma maior distribui¸cão dos componentes, agregando não só uma maior escalabilidade como também maior heteroge-neidade.

A se¸cão seguinte aborda os aspectos fundamentais para implementa¸cão de ar-quiteturas de grades, tais como descoberta de servi¸cos, escalonamento de aplica¸cões e autentica¸cão e autoriza¸cão dos usuários.

2.3 ASPECTOS DA IMPLEMENTAC¸ ˜AO DE ARQUITETURAS DE GRADE

(32)

e coordena¸c˜ao do uso desses recursos compartilhados, a fim de solucionar problemas computacionais de determinadas Organiza¸c˜oes Virtuais.

Tendo em mente que as grades computacionais são plataformas de execu¸cão para aplica¸cões paralelas que congregam recursos dispersos geográfica e administrativamente [40], algumas arquiteturas têm sido criadas para a implementa¸cão de grades, tais como Globus [10], Condor [44], Legion [45] e OurGrid [11]. Qualquer que seja a arquitetura de grade empregada, os servi¸cos computacionais oferecidos apresentam as seguintes carac-ter´ısticas [46]:

❼ heterogeneidade;

❼ alta dispersão geográfica; ❼ compartilhamento de recursos; ❼ múltiplos dom´ınios administrativos; ❼ controle distribu´ıdo.

No entanto, o não-atendimento a algum desses aspectos não descaracteriza neces-sariamente uma determinada arquitetura como grade. Da mesma forma, cada arquitetura possui suas próprias peculiaridades na maneira como implementa (ou não implementa) servi¸cos como escalonamento, contabiliza¸cão e seguran¸ca. Assim, ao considerar as gra-des como arquiteturas orientadas a servi¸cos, certas funcionalidagra-des importantes para a implementa¸cão dessas infra-estruturas devem ser abordadas, como explicado a seguir.

2.3.1 Descoberta de Servi¸cos

Uma grade pode se estender por diversos dom´ınios. Desta forma, a grade é fundamen-talmente uma grande inter-rede de dimensão global, com caracter´ısticas dinâmicas, onde os servi¸cos e recursos não só são heterogêneos como também extremamente voláteis, em vista do grande número de entidades (e.g., usuários, esta¸cões, recursos) que entram e saem do ambiente constantemente.

(33)

os usuários devem ser capazes de criar novos servi¸cos que possam interagir com outros servi¸cos, sem interven¸cão do administrador [1]. A descoberta dinâmica de servi¸cos pode então ser vista como um meta-servi¸co, na medida em que permite que uma dada aplica¸cão encontre os recursos e servi¸cos que atendam a sua demanda.

Nesse contexto, a tecnologia de Web Services tem sido cada vez mais empre-gada na cria¸cão de arquiteturas de grades baseadas em servi¸cos [46], pois ela aproveita vários padrões já estabelecidos, como o HTTP, e incorpora novos, como oUniversal Des-cription, Discovery and Integration (UDDI), o qual destina-se justamente à descoberta dinâmica de servi¸cos através da cria¸cão de um catálogo global de todos os Web Services

compartilhados na Internet [46], como ilustrado na Figura 2.8.

Figura 2.8 Descoberta dinˆamica de servi¸cos via Web Services [47]

Inicialmente, o cliente utiliza o registro UDDI para conhecer quem é o servidor capaz de lhe prover um dado servi¸co X (passos 1 e 2). De posse da referência para o servi¸co, o cliente comunica-se diretamente com o servidor responsável que disponibiliza um documento Web Services Description Language (WSDL), descrevendo os servi¸cos oferecidos e determinando como invocá-los (passos 3 a 6), através do protocolo Simple Object Access Protocol (SOAP).

2.3.2 Escalonamento de Aplica¸c˜oes

(34)

recursos, de tal forma que o escalonador precisa conhecer informa¸cões sobre a grade e as aplica¸cões em execu¸cão. Em suma, é preciso conhecer as informa¸cões de monitora¸cão usa-das em previsões de desempenho (quanto tempo cada tarefa consumirá aquele recurso), o que não é fácil, já que, segundo Santos Neto em [48], tais informa¸cões são dinâmicas e normalmente não se encontram dispon´ıveis no momento do escalonamento. O XSuffe-rage e Workqueue with Replication, discutidos a seguir, são exemplos de heur´ısticas de escalonamento aplicadas em grades.

O XSufferage é uma abordagem para escalonamento que apóia-se no conhecimento sobre o desempenho dos recursos [49]. Esta heur´ıstica de escalonamento dá prioridade às tarefas que seriam mais prejudicadas caso não fossem escalonadas, com base na diferen¸ca entre o melhor e o segundo melhor tempo de execu¸cão previsto para cada tarefa em cada site. Desta maneira, a tarefa que apresentar maior diferen¸ca terá prioridade para ser escalonada no site que a executaria mais rapidamente [48]. Além disso, os dados de entrada utilizados para o cálculo da diferen¸ca são reaproveitados no momento da aloca¸cão de recursos, reduzindo o impacto de transferências desnecessárias. Porém, para calcular a diferen¸ca o XSufferage precisa de informa¸cões, como a carga da CPU, a largura de banda e os tempos de execu¸cão de cada tarefa e, como mencionado anteriormente, essas informa¸cões são de dif´ıcil obten¸cão, tendo em vista a natureza dinâmica das grades.

(35)

2.3.3 Autentica¸c˜ao e Autoriza¸c˜ao

Ao tornar os seus recursos dispon´ıveis, o administrador daquele dom´ınio pode impor res-tri¸cões na maneira como e quando seus recursos serão utilizados por outrem. Da mesma forma, um consumidor de recursos pode querer, por exemplo, utilizar somente recur-sos certificados como seguros. Faz-se necessário, portanto, mecanismos que garantam a identidade de um consumidor ou recursos (autentica¸cão) e que determinem se uma dada opera¸cão solicitada é ou não válida (autoriza¸cão).

Por tratar-se de um ambiente bastante disperso e heterogêneo, as grades possuem certos requisitos de seguran¸ca mais complexos se comparados às redes tradicionais. No que diz respeito à autentica¸cão e autoriza¸cão, as grades devem oferecer mecanismos que permitam [1]:

❼ Assinatura única (Single sign-on): para ter acessos aos recursos da grade, os usuários devem realizar o login, isto é, autenticar-se somente uma vez;

❼ Delega¸cão: um determinado programa executado pelo usuário deve poder acessar recursos os quais são autorizados para aquele usuário;

❼ Integra¸cão com solu¸cões locais: as solu¸cões de seguran¸ca da grade devem interoperar com as solu¸cões de seguran¸ca dos provedores cujos recursos estão sendo utilizados; ❼ Relacionamentos de confian¸ca baseado no usuário: se um usuário tem direito a utilizar os recursos de dois provedores distintos, ele pode desejar fazê-lo simulta-neamente, sem necessidade de intera¸cão entre os administradores de seguran¸ca dos provedores.

Para que cada dom´ınio mantenha sua própria pol´ıtica local de autentica¸cão e autoriza¸cão, e ao mesmo tempo exporte um servi¸co para autentica¸cão e autoriza¸cão de usuários externos, as atuais iniciativas de grades têm utilizado certificados digitais e esquemas baseados em chaves públicas e privadas [46].

(36)

2.3.4 Prote¸c˜ao dos Recursos e Aplica¸c˜oes

Para encorajar uma maior participa¸cão e disponibiliza¸cão dos recursos, é preciso dar ga-rantias aos fornecedores de que seus recursos computacionais não serão comprometidos, já que suas máquinas estão expostas a uma aplica¸cão desconhecida que poderia muito bem, por exemplo, destruir o sistema de arquivos ou mesmo congestionar a rede. Nesse sentido, mecanismos de prote¸cão dos recursos têm sido desenvolvidos para garantir que uma dada aplica¸cão não contenha código malicioso que venha a prejudicar o pleno funcionamento das máquinas.

Embora não haja uma padroniza¸cão, a tendência observada na literatura é criar uma área com sistema de arquivos, processos e recursos de rede isolados, sem poder acessar outros processos. Em outras palavras, um determinado processo confinado nessa área só poderá acessar os outros processos, o sistema de arquivos e os recursos de rede que se encontram em sua própria área. Essa abordagem, conhecida como virtualiza¸cão [51], é adotada em técnicas como o Sandbox [52], que além de limitar as poss´ıveis a¸cões do código de um processo, impedindo que o mesmo cause danos a outros programas e aos arquivos do usuário, também evita o consumo exagerado dos recursos dispon´ıveis. De outro modo, a execu¸cão dos processos locais da máquina fornecedora de recursos estaria comprometida. Como mencionado anteriormente, não há padroniza¸cão para prote¸cão dos recursos, mas diversas iniciativas vêm adotando solu¸cões semelhantes, como no caso do Projeto OurGrid, que possui uma solu¸cão baseada no Sandbox, intitulada Swan [46].

A respeito das aplica¸cões, para algumas é primordial que os dados trafegando na grade sejam mantidos sob sigilo, pois o acesso não autorizado a informa¸cões confidenciais pode comprometer os resultados. Contudo, atender esse requisito de confidencialidade é uma tarefa bastante complexa, ainda mais tratando-se de um ambiente amplamente dinâmico e distribu´ıdo como as grades.

Além disso, a possibilidade de manipula¸cão indevida dos resultados obtidos com o processamento é outro aspecto a ser considerado, visto que se os processos e seus resultados forem corrompidos, a aplica¸cão irá incorrer em um alto custo em termos de desempenho. Nesse caso, é necessário um esquema que garanta não só a privacidade dos dados que trafegam na grade, mas também a integridade dos processos e resultados obtidos, certificando-se que as máquinas que compõem a grade não são constitu´ıdas por

(37)

2.4. Seguran¸ca em Grades 19

apesar de também não existir qualquer padroniza¸cão nesse sentido.

2.4 SEGURANC¸ A EM GRADES

Seguran¸ca em redes de computadores requer, tradicionalmente, princ´ıpios de auten-tica¸cão, controle de acesso, integridade, privacidade e não-repúdio [3]. Contudo, as grades computacionais, por serem de natureza dinâmica e heterogênea, possuem requisitos de seguran¸ca adicionais, tais como [54, 55]:

❼ Assinatura única: o usuário deve se autenticar uma vez, a fim de obter, utilizar e liberar os recursos dispon´ıveis, sem que o mesmo tenha que se autenticar novamente; ❼ Uniformidade e prote¸cão de credenciais: informa¸cões como senhas e chaves privadas

devem estar protegidas e codificadas de maneira padr˜ao;

❼ Interoperabilidade com solu¸cões de seguran¸ca locais: as solu¸cões de seguran¸ca de-vem fornecer mecanismos de acesso entre dom´ınios, sendo que o acesso a recursos de um dom´ınio local é determinado pelas suas próprias pol´ıticas de seguran¸ca; ❼ Exportabilidade: o código deve ser exportável de modo que possa ser executado em

qualquer site da grade, sem um esquema “pesado” de criptografia;

❼ Cria¸cão dinâmica de servi¸cos: os usuários devem ser capazes de criar novos servi¸cos que possam interagir com outros servi¸cos, sem interven¸cão do administrador; ❼ Estabelecimento dinâmico de dom´ınios confiáveis: os diferentes dom´ınios precisam

estabelecer uma rela¸cão de confian¸ca entre os seus usuários e recursos para garantir a coordena¸cão de recursos.

Além dos requisitos acima citados, a dinamicidade do ambiente também deve ser levada em considera¸cão, tendo em vista o grande número de jobs e participantes que interagem com a grade constantemente. Existem, portanto, vários desafios para qualquer infra-estrutura de seguran¸ca em grade.

(38)

Além disso, o Legion permite implementar pol´ıticas de seguran¸ca de acordo com a ne-cessidade, onde cada objeto possui um método chamado “MayI” que indica ao usuário os métodos do objeto aos quais ele tem acesso [7]. Em outras palavras, todo objeto é responsável por sua própria pol´ıtica de controle de acesso. Pordefault, o método MayI im-plementa uma pol´ıtica baseada em checagem de credenciais e listas ACL (Access Control List).

Já na plataforma Condor, cujo foco é voltado para a computa¸cão de alta vazão (High-Throughput Computing - HTC) [56], é utilizado Secure Socket Layer (SSL) em conjunto com certificados X.509 para a autentica¸cão, tal como na plataforma Globus (na verdade, parte da implementa¸cão dos aspectos de seguran¸ca usados no Condor é originada do Globus [57]). Para a autoriza¸cão, o Condor oferece um mecanismo que controla quais máquinas podem se unir à grade, quais máquinas podem obter informa¸cões sobre osite e quais máquinas do ambiente possuem privilégios administrativos. No in´ıcio do projeto Condor, a autoriza¸cão era baseada em informa¸cões dohost (como endere¸co IP, por exemplo). Em sua versão estável mais recente, o Condor 6.6 trabalha com autoriza¸cão baseada no usuário.

A seguir, ser˜ao discutidos em maiores detalhes os mecanismos e aspectos de se-guran¸ca observados nas plataformas Globus Toolkit e OurGrid.

2.4.1 Seguran¸ca no Globus Toolkit

A infra-estrutura oferecida pela plataforma Globus é atualmente a mais utilizada para constru¸cão de Organiza¸cões Virtuais montadas sobre grades computacionais. O projeto Globus é direcionado para a defini¸cão e implementa¸cão das camadas de mais baixo n´ıvel no desenvolvimento de grades computacionais, permitindo criar abstra¸cões e diversas funcionalidades básicas [48]. A ferramenta desenvolvida no contexto do projeto Globus é conhecida como Globus Toolkit e hoje encontra-se em sua versão 4 (GT4).

O Globus Toolkit oferece uma API (Application Program Interface) que dispo-nibiliza um conjunto de mecanismos de seguran¸ca. Essa API, conhecida como Globus Security Infrastructure (GSI) foi implementada sobre o GSS (Generic Security Servi-ces)[58] e provê servi¸cos de seguran¸ca, tais como autentica¸cão, autoriza¸cão, não-repúdio, confidencialidade e privacidade dos dados [4].

(39)

usuários, esta¸cões e recursos), o GSI utiliza o esquema de certificado digital de acordo com o padrão X.509. Esses certificados são assinados por uma autoridade certificadora (Certificate Authority - CA), que exerce as fun¸cões de administra¸cão e armazenamento dos certificados. Dessa forma, o GSI atende o requisito de autentica¸cão única (single sign-on) através do uso de usuários proxies na estrutura interna da grade. Esse tipo de autentica¸cão funciona da seguinte forma: no momento em que um usuário cadastrado se autentica na grade e envia algum processo para ser executado, um usuárioproxy utiliza a identidade deste usuário autenticado e fica responsável por realizar todas as autentica¸cões subseqüentes no ambiente interno, de forma independente da localiza¸cão do dom´ınio des-tas entidades na grade. Além disso, o GSI provê autentica¸cão mútua através da troca de chaves entre as entidades envolvidas da grade, utilizando SSL. Logo após a execu¸cão do processo de autentica¸cão e da comprova¸cão da identidade das entidades, é criado um túnel SSL responsável pela provisão de integridade e confidencialidade na comunica¸cão entre as entidades da grade.

O GSI também disponibiliza um servi¸co de não-repúdio através da utiliza¸cão de assinaturas digitais, como ilustrado na Figura 2.9. No processo de cria¸cão da assinatura, uma fun¸cão hash (H) é utilizada para gerar um resumo da mensagem a ser assinada. Após a gera¸cão e assinatura do resumo com a chave K privada da entidade da grade, este é enviado juntamente com a própria mensagem para a outra entidade participante da comunica¸cão que realizará o processo de verifica¸cão de assinatura, que acontece através da compara¸cão entre o resumo gerado da mensagem e o resultado da decodifica¸cão da assinatura via chave K pública do emissor [4].

Figura 2.9 Assinatura digital no GSI

(40)

tenha sido apropriadamente executado [59]. Assim, dentre as caracter´ısticas de seguran¸ca inerente ao GSI, observa-se a ausˆencia de um esquema que verifique a integridade dos

jobs em processamento, o que evidencia a necessidade de constru¸c˜ao de mecanismos de seguran¸ca no Globus que solucionem este problema de forma integrada ao GSI.

O Global Grid Forum [60], entidade padronizadora de tecnologias para grades formada por centros de pesquisa, institui¸cões acadêmicas e o setor corporativo, define que dentre os requisitos de seguran¸ca estabelecidos, há a necessidade de mecanismos que detectem intrusão, identifiquem o mau uso da grade por parte de usuários maliciosos, protegendo o ambiente, inclusive, contra v´ırus e worms [61], e que também garantam a integridade das informa¸cões, provendo confian¸ca nos resultados obtidos com o processa-mento.

2.4.2 Seguran¸ca no OurGrid

A plataforma OurGrid é uma solu¸cão para a cria¸cão de grades computacionais, com foco em aplica¸cões chamadas Bag-of-Tasks (BoT), ou seja, aplica¸cões cujas tarefas são independentes umas das outras [62]. Dessa forma, o OurGrid viabiliza uma rede P2P de troca de favores, onde, caso sejam solicitados, os recursos ociosos de um determinadosite

são fornecidos para outro, mediante uma pol´ıtica de quanto mais se doa recursos, maior a prioridade junto à comunidade para obtê-los quando necessário [46].

O OurGrid oferece mecanismos para autentica¸cão em n´ıvel desite local e remoto. No primeiro caso, a autentica¸cão segue os procedimentos tradicionais (login e senha), já que trata-se de máquinas que encontram-se no mesmo dom´ınio ao qual o usuário pertence. Contudo, o acesso a recursos de outrossites passa pelofront-end de seu dom´ınio, ou seja, o OurGrid Peer local. Nesse caso, é utilizado o esquema de certificados X.509 [40].

(41)

2.5. Conclus˜ao 23

programas e aos arquivos do usuário dono da máquina fornecedora, já que estes mesmos

jobs estão confinados em uma área onde só poderão acessar outros processos, o sistema de arquivos e os recursos de rede que nela se encontram. Esta técnica é ilustrada pela Figura 2.10.

Figura 2.10 T´ecnica Sandbox

Embora o OurGrid possua um mecanismo para a prote¸cão dos recursos, não existe de fato um mecanismo que proteja também as aplica¸cões. Portanto, essa plataforma não oferece garantias que os jobs executados pelas Gums sejam processados corretamente, sem a manipula¸cão indevida dos seus resultados.

Assim como no Legion, no Condor e no Globus, nota-se a necessidade de uma solu¸cão que garanta não só o bom uso dos recursos oferecidos, mas também a integri-dade dos processos e dos resultados obtidos, certificando-se assim que as máquinas que compõem a grade não sejam constitu´ıdas por nós maliciosos interessados em invalidar os dados.

2.5 CONCLUS˜AO

Este cap´ıtulo apresentou as principais caracter´ısticas das arquiteturas de sistemas dis-tribu´ıdos, com destaque para grades computacionais, discutindo aspectos como desco-berta de servi¸cos e escalonamento das aplica¸cões. Além disso, também foram investiga-dos requisitos de seguran¸ca existentes para qualquer plataforma de grades, destacando os principais mecanismos de seguran¸ca oferecidos pelas plataformas Globus e OurGrid.

(42)

2.5. Conclus˜ao 24

(43)

CAP´ITULO 3

DIAGN ´

OSTICO EM N´IVEL DE SISTEMA

Neste cap´ıtulo são discutidos os principais modelos de falhas encontradas em grades, apresentando duas estratégias de tolerância a falhas que podem ser aplicadas nesse am-biente com o intuito de detectar a manipula¸cão dos resultados processados. Em seguida, são abordados modelos de diagnóstico em n´ıvel de sistema, apontando seus conceitos, caracter´ısticas, vantagens e desvantagens.

3.1 TIPOS DE FALHAS

Ambientes distribu´ıdos e heterogêneos como os de grades são bastante suscet´ıveis a erros devido a sua complexidade. Quanto maior a grade, maior a possibilidade de falhas, já que um número maior de componentes e elementos precisam estar continuamente interagindo. Assim, inúmeros tipos de falhas podem ocorrer nesse tipo de ambiente, como as falhas do tipo crash, por omissão, temporiza¸cão e as falhas bizantinas [63].

(44)

3.2. Classifica¸c˜ao de N´os com Mau Comportamento 26

3.2 CLASSIFICAÇ ÃO DE N ÓS COM MAU COMPORTAMENTO

Conforme mencionado, as falhas ocasionadas por n´os maliciosos constituem apenas uma subclasse das falhas bizantinas decorrentes por mau comportamento. De acordo com Hollick et al em [65], as falhas originadas pelo mau comportamento envolvem componentes (n´os) que passam a agir de maneira inativa, ego´ısta ou maliciosa.

Os nós inativos não cooperam com a rede, deixando de encaminhar pacotes, recusando-se a processar os jobs que lhe são entregues ou omitindo informa¸cões sobre seus recursos dispon´ıveis. Os nós considerados ego´ıstas negligenciam ajuda aos demais nós, favorecendo apenas seus próprios interesses. No contexto OurGrid, por exemplo, um nó ego´ısta (chamado free-rider) é aquele que apenas consome recursos da comunidade, sem oferecer seus próprios recursos quando solicitado. Embora ele não doe seus recursos, o nó ego´ısta pode manter-se respondendo às requisi¸cões de descoberta de recursos a fim de permanecer ativo na grade. Quanto aos nós maliciosos, estes possuem, por exemplo, interesse em subverter os recursos da grade, oferecer um resultado inválido ou mesmo em difundir worms ou v´ırus entre as máquinas do ambiente.

A classe de n´os maliciosos pode ainda ser subdividida em trˆes categorias [24]:

❼ N´os maliciosos tolos: sempre retornam resultados corrompidos;

❼ N´os maliciosos comuns: retornam resultados corrompidos com uma certa probabi-lidade;

❼ Nós maliciosos inteligentes: agem normalmente durante um certo per´ıodo para obter boa reputa¸cão, até que passam deliberadamente a retornar resultados corrompidos com uma certa probabilidade.

Dentre as classifica¸cões de mau comportamento apresentadas, as falhas de natu-reza maliciosa que geram resultados corrompidos, em especial os nós maliciosos tolos e comuns, constituem o escopo desta disserta¸cão.

3.3 CONFIABILIDADE E SEGURANC¸ A

(45)

3.4. T´ecnicas para Verifica¸c˜ao de Integridade de Processamento 27

como por exemplo, falta de energia elétrica, bugs de software, degrada¸cão do hardware, má configura¸cão dos componentes, falhas na comunica¸cão, entre outros [66]. Já o con-ceito de seguran¸ca (security) está intimamente ligado a uma inten¸cão maliciosa, como distribui¸cão de v´ırus, invasão de redes, quebra de chaves secretas, entre outros. Assim, a finalidade da seguran¸ca é evitar ou tolerar ataques desse tipo, protegendo as informa¸cões e os servi¸cos oferecidos por um sistema.

Embora possuam ênfases diferenciadas, ambas as áreas preocupam-se com o cor-reto funcionamento dos sistemas computacionais, geralmente denominado como dependa-bility. Na realidade, seguran¸ca e confiabilidade interseccionam-se à medida que seguran¸ca também pode tratar problemas de origem acidental, enquanto confiabilidade pode incluir problemas de origem maliciosa. Mecanismos clássicos, como controle de acesso e auten-tica¸cão, t´ıpicos da área de seguran¸ca, podem ser utilizados para preven¸cão de falhas, assim como ferramentas de tolerância a intrusões podem lan¸car mão de conceitos comuns à tolerância a falhas [67].

Nesse contexto, o termo confiabilidade utilizado no restante deste trabalho refere-se justamente ao grau de integridade do comportamento de um determinado nó (unidade de processamento) ao fornecer um resultado de umjob que é processado por ele na grade. Para isso, são utilizadas técnicas de tolerância a falhas.

3.4 TÉCNICAS PARA VERIFICAÇ ÃO DE INTEGRIDADE DE PROCESSAMENTO

Em sistemas distribu´ıdos, mais especificamente em grades computacionais, tolerância a falhas também tem sido utilizada no dom´ınio da seguran¸ca. Assim, técnicas de verifica¸cão de integridade de processamento podem ser aplicadas utilizandojobs para testar periodi-camente os nós da grade. Dependendo do sistema, osjobs de teste podem ser constitu´ıdos pelos próprios jobs da aplica¸cão. Por exemplo, o projeto Seti@home [68] (computa¸cão voluntária para pesquisa de vida extra-terrena) adota o esquema de vota¸cão majoritária (majority voting), onde osjobs da aplica¸cão são replicados e distribu´ıdos entre os diversos

hosts volunt´arios do ambiente.

(46)

3.4. T´ecnicas para Verifica¸c˜ao de Integridade de Processamento 28

um resultado diferente da maioria. Assim, o nó gerente assume x como resultado final válido e o nó D como malicioso.

Embora seja relativamente simples de implementar, essa estratégia baseada em replica¸cão é indicada somente em casos onde a taxa de erros é necessariamente baixa. Caso contrário, a replica¸cão crescerá excessivamente em fun¸cão do número m, e quanto maior o número de réplicas, maior o desperd´ıcio de recursos e menor o desempenho.

Figura 3.1 Voto majorit´ario com 6 n´os fornecedores de recursos

Uma alternativa ao esquema de vota¸cão majoritária é a técnica baseada em veri-fica¸cão focalizada (spot-checking), utilizado em trabalhos como o de Sarmenta [22]. Nesse caso, os nós são testados aleatoriamente através da solicita¸cão de execu¸cão de umjob cujo resultado é previamente conhecido. Se o resultado divergir do esperado, os resultados an-teriores retornados por este nó são descartados. A utiliza¸cão de um mecanismo do tipo lista negra (blacklist) permite indicar quais nós não são mais desejados na grade.

O trabalho de Casale et al [23] também emprega uma filosofia semelhante para tolerar ataques de manipula¸cão em grades. Os nós podem receber tantojobs de teste com resultados já conhecidos pelo nó gerente, comojobsreplicados entre os diversos nós do am-biente. Tais problemas são submetidos aos nós em intervalos regulares pré-determinados. Segundo Casale et al, uma forma de diminuir o custo (overhead) introduzido por essas técnicas seria a ado¸cão de um esquema de reputa¸cão que determine o grau de confiabili-dade de um dado nó de acordo com o seu comportamento.

(47)

3.5. Diagn´ostico 29

comportamento dos nós. Além disso, para grades é necessário obviamente aplicar testes mais sofisticados. Uma possibilidade é combinar diagnóstico com verifica¸cão focalizada, utilizando também uma lista negra e um esquema eficiente de reputa¸cão.

3.5 DIAGN ´OSTICO

Algoritmos de diagnóstico em n´ıvel de sistema são comumente utilizados como uma es-tratégia de tolerância a falhas, onde, a partir de uma série de testes, determina-se quais unidades estão falhas e quais estão em pleno funcionamento, obtendo ao final um conjunto de respostas, chamado s´ındrome [69].

Os primeiros modelos de diagnóstico que surgiram são do tipo centralizado, onde há a presen¸ca de uma unidade central responsável por testar os enlaces e estados das demais unidades do sistema. Esse modelo, embora pare¸ca de mais fácil implementa¸cão, possui a limita¸cão de disponibilidade, pois caso ocorra uma falha na unidade central, todo o sistema ficará comprometido.

Como alternativa, surgiram os modelos distribu´ıdos, onde a responsabilidade de aplica¸cão dos testes é passada para várias ou todas as unidades do sistema. Uma es-tratégia simplificada para execu¸cão de testes em modelos distribu´ıdos consiste no envio de est´ımulos das unidades testadoras para as unidades testadas [70]. Se as respostas das unidades testadas chegarem dentro de um intervalo de tempo limitado, a unidade testa-dora a considera como uma unidade sem-falha. Por outro lado, se a resposta não vier a tempo, a unidade testadora conclui que a unidade testada é falha.

Um algoritmo de diagnóstico pode declarar todas as N unidades de um sistema como falhas, não falhas ou suspeitas. Em um modelo distribu´ıdo, é assumido que as unidades testadoras não falhas relatam resultados confiáveis. Com rela¸cão aos resultados das unidades falhas nada pode ser afirmado, como ilustra a Figura 3.2, com os resultados detalhados na Tabela 3.1.

(48)

Figura 3.2 Poss´ıvel s´ındrome para um sistema baseado em testes distribu´ıdos

Testador Testado Resultado

Não-Falho Não-Falho 0 Não-Falho Falho 1

Falho N˜ao-Falho X (0 ou 1) Falho Falho X (0 ou 1)

Tabela 3.1 Unidades testadoras falhas emitem resultados indeterminados

Na se¸cão seguinte são discutidos os principais modelos de diagnóstico em n´ıvel de sistema encontrados na literatura. Deste ponto em diante, as unidades do sistema são chamadas nós. No escopo deste trabalho, cada nó representa um recurso de processa-mento computacional.

3.5.1 Modelo PMC

Um dos modelos clássicos de diagnóstico propostos é o modelo PMC [71], cujo nome deriva das iniciais dos seus autores (Preparata, Metze e Chien). Nesse modelo, os nós testam uns aos outros e tais testes são realizados em intervalos pré-definidos. Os nós sem-falhas que aplicam os testes são considerados confiáveis e relatam resultados corretos. Já os nós testadores falhos são imprevis´ıveis, podendo dar um parecer arbitrário para o resultado do nó testado. Os resultados dos testes possuem representa¸cão binária (0 para sem-falha, 1 para falha). Embora os testes sejam realizados de forma distribu´ıda, o diagnóstico no modelo PMC é centralizado, visto que é assumida a existência de uma entidade conhecida comoobservador central (ou oráculo) com a atribui¸cão de receber todos os resultados dos testes (s´ındrome), para em seguida determinar o diagnóstico do sistema como um todo.

(49)

status de falha de um nó não muda durante o teste e o diagnóstico. Embora este modelo não considere falhas transitórias ou intermitentes, estas são as mais comuns e as mais dif´ıceis de diagnosticar [72]. Esse modelo foi adotado em trabalhos como [73, 74, 75].

Para seu formalismo, o modelo utiliza a teoria de grafos, onde os vértices repre-sentam os nós e as arestas indicam os enlaces com a dire¸cão dos testes. Assim sendo, um sistema S, composto por N nós totalmente conectados, é representado através de um grafo completo G=(V, E), onde V representa os vértices e E os enlaces. Um grafo completo para o modelo PMC com 4 nós é ilustrado pela Figura 3.3 (a).

Figura 3.3 Exemplo de grafo do sistema e grafo de testes para 4 n´os

Na Figura 3.3 (b), o grafo direcionado de testes representa um sistema de 4 nós, onde a aresta partindo do vértice A para o vértice B, por exemplo, representa um teste aplicado pelo nó A sobre o nó B (A → B), cujo resultado é X, isto é, indeterminado, podendo ser 0 ou 1, já que o nó testador A está falho. O teste (B → C) identifica que o nó C não possui falha (resultado 0). O mesmo para o teste (C → D). Já o teste (D→A) indica que o A está falho (resultado 1). Assim, a s´ındrome do sistema pode ser representada pelo vetor de 4 bits X, 0, 0, 1, lembrando que no modelo PMC os nós testa-dores sem-falhas são totalmente confiáveis e sempre reportam resultados corretos. Esse conjunto de resultados é passado para o observador central, que tem a responsabilidade de oferecer o diagnóstico do estado do sistema, o que nem sempre é trivial, já que nós testadores podem dar resultados divergentes sobre um determinado nó testado.