Cen´ario com Esquema de Reputa¸c˜ao

Com o surgimento de novos n´os testadores, o modelo adquire caracter´ısticas de hierarquia, `a medida que novas responsabilidades s˜ao delegadas a estes n´os. O uso de um esquema de reputa¸c˜ao permite inferir o qu˜ao honesto um n´o tem se comportado no ambiente ao oferecer os resultados dos jobs processados. Assim, a estrat´egia de diagn´ostico neste segundo cen´ario ´e uma evolu¸c˜ao da apresentada na Figura 5.1 relativa ao primeiro cen´ario. A diferen¸ca ´e que agora s˜ao considerados os aspectos de reputa¸c˜ao, eleva¸c˜ao de status e

5.2. Cen´arios Estudados 62

reconfigura¸c˜ao dos clusters, como especificado no Cap´ıtulo 4.

Nesse caso, ´e importante verificar o impacto do uso do esquema de reputa¸c˜ao em- pregado, avaliando o comportamento do ambiente diante dos novos n´os que obt´em status de testador e UC em fun¸c˜ao dos parˆametros T CTmin (Tempo m´ınimo de Conex˜ao Total)

e T ENmax (Taxa m´axima de Erros Naturais), ambos estipulados pelo administrador da

grade. Assim, as simula¸c˜oes neste cen´ario foram realizadas tomando como base o tempo. Diferente das simula¸c˜oes no primeiro cen´ario, aqui as simula¸c˜oes n˜ao finalizam mais ao final de 10 mil jobs processados. Cada simula¸c˜ao ´e conclu´ıda agora ao final de sete dias de opera¸c˜ao da grade e o n´umero de jobs n˜ao ´e mais limitado. Vale ressaltar que o tempo no simulador ´e diferente do tempo real. Como estes novos comportamentos elevaram bas- tante o tempo das simula¸c˜oes, em vez de 100 simula¸c˜oes para cada experimento, foram realizadas apenas 25, cada uma representando 7 dias de funcionamento da grade.

A quantidade de n´os maliciosos no ambiente s˜ao as mesmas: 1/6, 1/3 e 2/3 do total de 200 n´os. Os experimentos tamb´em consideram as simula¸c˜oes com 3, 5, 8, 10, 15 e 20 rodadas de teste, realizadas com diferentes periodicidades (a cada 6h, 12h e 24h de opera¸c˜ao da grade). Como foi observado que quase todos os n´os maliciosos eram detectados nas primeiras rodadas de teste, ou seja, nas primeiras horas de opera¸c˜ao da grade, os experimentos aqui simulados assumem a entrada dinˆamica de n´os no ambiente ao t´ermino de cada conjunto de rodada de teste. Assim, cada vez que um novo n´o entra na grade, ´e definido aleatoriamente se aquele n´o poder´a ou n˜ao se comportar maliciosamente. As chances de um novo n´o da grade entrar como malicioso s˜ao de 50%. O n´umero m´aximo de n´os no ambiente permanece em 200.

Para as simula¸c˜oes, foi assumido que todos os n´os est˜ao permanentemente conec- tados `a grade e, portanto, o parˆametro T CImin(Tempo m´ınimo de Conex˜ao Ininterrupta)

´e desconsiderado. Os valores de T ENmax e T CTmin para eleva¸c˜ao de status s˜ao listados

na Tabela 5.2.

Testador UC

T ENmax 3% 0%

T CTmin 1 dia 3 dias

Tabela 5.2 Valores para eleva¸c˜ao de status

A partir desses parˆametros foi poss´ıvel investigar a quantidade e a freq¨uˆencia de rodadas de testes necess´arias para a detec¸c˜ao dos n´os de mau comportamento, o impacto

5.2. Cen´arios Estudados 63

do uso da blacklist associada ao esquema de reputa¸c˜ao, o custo introduzido, o ´ındice de confiabilidade e a taxa de erros naturais de cada n´o. Para c´alculo do ICmin e ICi, foram

utilizadas, respectivamente, Equa¸c˜oes 1 e 2 da Se¸c˜ao 4.4. J´a o T ENi´e dado pela Equa¸c˜ao

3 da referida se¸c˜ao.

Como observado nas simula¸c˜oes, todos os n´os executores com bom comporta- mento tendem a obter status de testador e, posteriormente, UC. Para evitar que o ambi- ente fique povoado de UCs, foi avaliado o comportamento do sistema diante da cria¸c˜ao de at´e 10 novos clusters l´ogicos operando de forma independente, sendo que o n´umero de n´os testadores foi limitado a 6 por cluster.

Na situa¸c˜ao em que o modelo possui v´arios clusters l´ogicos, fica evidente a sua distribui¸c˜ao e hierarquiza¸c˜ao, visto que cada cluster, gerenciado por um UC, opera de forma independente dos demais. Nas simula¸c˜oes, a reconfigura¸c˜ao de clusters acontece no surgimento de um novo n´o UC.

Desta forma, h´a uma elei¸c˜ao entre os UCs para determinar quem ser´a o l´ıder no processo de reconfigura¸c˜ao. Os demais UCs fornecem a este novo l´ıder as informa¸c˜oes sobre os n´os de seu clusters, para que o mesmo possa calcular o novo tamanho dos clusters (raz˜ao entre o total de n´os do sistema e total de n´os UCs, como descrito na Equa¸c˜ao 4 da Se¸c˜ao 4.5) e redistribuir todos os n´os executores e testadores equitativamente entre os n´os UCs.

Detec¸c˜ao de N´os Maliciosos

Os gr´aficos das Figuras 5.12, 5.13 e 5.14 mostram a quantidade de n´os maliciosos de- tectados em fun¸c˜ao do n´umero de rodadas de teste com, respectivamente, 1/6, 1/3 e 2/3 da grade comprometida. Os gr´aficos revelam que o comportamento observado no primeiro cen´ario (quanto maior a quantidade de rodadas de testes, maior o n´umero de maliciosos detectados) tamb´em se repete aqui.

Nota-se tamb´em que a partir de um certo momento, n˜ao importa a quantidade de testes realizados, o n´umero de n´os maliciosos detectados tende a ser o mesmo. Por exemplo: com a realiza¸c˜ao de testes a cada 6h, o n´umero de n´os maliciosos detectados ´e praticamente o mesmo a partir de 5 rodadas. Vale ressaltar que 5 rodadas de testes a cada 6 horas equivalem a 20 rodadas ao dia (140 ao final de uma semana de opera¸c˜ao).

5.2. Cen´arios Estudados 64

Como esperado, o pior caso ´e justamente quando h´a uma maior quantidade de n´os maliciosos e uma quantidade de testes reduzida. Conforme a Figura 5.14, com apenas 3 rodadas ao dia s˜ao detectados aproximadamente 170 n´os maliciosos. No entanto, isso n˜ao significa que sobraram 100 n´os com mau comportamento livres para comprometer as aplica¸c˜oes em execu¸c˜ao.

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

Figura 5.13 N´os inseridos na blacklist com 1/3 de maliciosos

Como nesse cen´ario ´e considerada a entrada de novos n´os ap´os cada rodada de testes, o n´umero de maliciosos presentes no ambiente pode variar. Quanto mais roda- das, mais n´os maliciosos s˜ao detectados e, por conseg¨uinte, mais novos n´os igualmente

5.2. Cen´arios Estudados 65

Figura 5.14 N´os inseridos na blacklist com 2/3 de maliciosos

maliciosos s˜ao gerados. O que ´e observado ´e que h´a um limite para a quantidade de n´os maliciosos que comp˜oem a grade durante seu per´ıodo de execu¸c˜ao. O que se observa ´e que, em m´edia, o n´umero m´aximo de n´os maliciosos na grade ´e aproximadamente o dobro da quantidade inicial.

Assim sendo, para avaliar o grau de eficiˆencia do sistema, conhecer somente a totalidade dos n´os maliciosos detectados n˜ao ´e suficiente. ´E preciso tamb´em observar como o ambiente reage em cada um dos dias de opera¸c˜ao. Essa informa¸c˜ao ´e dada pelos gr´aficos seguintes.

As Figuras 5.15, 5.16 e 5.17 ilustram a evolu¸c˜ao da blacklist com o passar dos dias, considerando as diferentes periodicidades de rodadas de testes, com 2/3 da grade comprometida. Os gr´aficos referentes a 1/6 e 1/3 dos n´os agindo maliciosamente n˜ao acrescentam novas informa¸c˜oes, visto que o comportamento apresentado ´e proporcional- mente an´alogo.

Os gr´aficos evidenciam que com o passar do tempo, a curva de n´os maliciosos detectados tende a zero, de forma que a grande maioria destes n´os ´e isolada logo no primeiro dia. Com rodadas de testes acontecendo a cada 6h, o sistema praticamente deixa de detectar n´os maliciosos j´a no terceiro dia de opera¸c˜ao. ´E importante notar que nessa situa¸c˜ao, o desempenho na detec¸c˜ao de n´os maliciosos ´e a mesma para 8, 10, 15 e 20 rodadas de teste. Isso significa que, com rodadas acontecendo a cada 6h, pode-se utilizar uma quantidade de testes reduzida sem prejudicar a eficiˆencia do diagn´ostico.

5.2. Cen´arios Estudados 66

Contudo, `a medida que os testes s˜ao realizados menos frequentemente, essa equi- dade no desempenho para 8, 10, 15 e 20 rodadas tende a diminuir, como observado, por exemplo, nas Figuras 5.16 e 5.17. Al´em disso, com uma menor freq¨uˆencia na realiza¸c˜ao dos testes, o sistema leva mais tempo para deixar de detectar novos n´os maliciosos.

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

Figura 5.16 N´os maliciosos detectados com rodada de testes a cada 12h

Por outro lado, deixar de detectar n´os maliciosos a partir de um dado momento n˜ao significa que todos foram encontrados e j´a n˜ao existem maliciosos na grade. Este comportamento ´e atribu´ıdo `a natureza dinˆamica do ambiente modelado que permite a entrada de novos n´os, que podem ou n˜ao agir maliciosamente. Assim, para conhecer o

5.2. Cen´arios Estudados 67

Figura 5.17 N´os maliciosos detectados com rodada de testes a cada 24h

quanto o sistema de detec¸c˜ao ´e realmente robusto, ´e preciso observar a quantidade de n´os maliciosos remanescentes ao final dos sete dias de opera¸c˜ao. As Figuras 5.18, 5.19 e 5.20 ilustram como o ambiente de grade ´e “higienizado” durante esse per´ıodo, utilizando o esquema de diagn´ostico proposto em uma ambiente com 2/3 da grade inicialmente “contaminado”.

Segundo os gr´aficos obtidos, em qualquer situa¸c˜ao com apenas 3 rodadas de teste, sempre haver´a n´os maliciosos que passam desapercebidos no ambiente. No entanto, para as outras quantidades de rodadas, a grade pode ser devidamente limpa com rodadas acontecendo a cada 6h j´a no segundo dia de opera¸c˜ao do sistema.

5.2. Cen´arios Estudados 68

`

A medida que a freq¨uˆencia de realiza¸c˜ao de testes diminui, essa limpeza do am- biente ´e adiada e, algumas vezes n˜ao ´e nem completada, como no caso de 8 rodadas a cada 24h, onde, ap´os sete dias, restam aproximadamente 10% da quantidade inicial de n´os maliciosos. Esta quantidade de maliciosos remanescente tende a diminuir com mais testes sendo aplicados na mesma periodicidade; tanto que a partir de 15 rodadas a cada 24h, j´a n˜ao h´a mais maliciosos na grade ao final de uma semana.

Figura 5.19 N´os maliciosos remanescentes com rodada de testes a cada 12h

Figura 5.20 N´os maliciosos remanescentes com rodada de testes a cada 24h

De acordo com os gr´aficos avaliados nesta se¸c˜ao, para qualquer quantidade de n´os maliciosos iniciais compondo o ambiente, o sistema mostra-se robusto a partir de

5.2. Cen´arios Estudados 69

5 rodadas de testes ocorrendo a cada 6h, ou 8 rodadas a cada 12h. Entretanto, para conhecer o n´umero ideal de rodadas e de periodicidade, ´e necess´ario observar o custo e a acur´acia obtida com estes valores, visto que tais m´etricas podem impactar nos resultados obtidos.

Custo

A Figura 5.21 apresenta o custo introduzido no sistema neste segundo cen´ario. Como este cen´ario foi modelado de forma a permitir novos n´os entrando na grade (dentro do limite m´aximo de 200 n´os no ambiente), o overhead ´e praticamente o mesmo para qualquer quantidade inicial de n´os maliciosos, diferentemente do primeiro cen´ario, onde, com mais n´os maliciosos no ambiente, menor o custo introduzido.

Figura 5.21 Custo introduzido

Como discutido anteriormente, o esquema de diagn´ostico proposto mostra-se sufi- cientemente robusto com 5 rodadas de testes a cada 6h, ou 8 a cada 12h. Por´em, conforme o gr´afico da Figura 5.21, 8 rodadas a cada 12h apresentam-se como melhor alternativa, tendo em vista o trade-off alcan¸cado. Enquanto com 5 rodadas obt´em-se um overhead de 17%, com 8 esse overhead cai para cerca de 12,3%.

Comparado com o primeiro cen´ario, os resultados obtidos com a mesma quanti- dade de rodadas s˜ao ainda mais satisfat´orios, j´a que o overhead alcan¸cado no presente cen´ario ´e menor do que o observado no melhor caso do cen´ario simulado sem reputa¸c˜ao,

5.2. Cen´arios Estudados 70

que apresenta 15% de overhead com 1/6 dos n´os maliciosos, mostrado na Figura 5.9. Em outras palavras, o modelo de diagn´ostico associado ao esquema de reputa¸c˜ao proposto com blacklist ´e perfeitamente capaz de sanar um ambiente de grades infectado com mais da metade dos n´os agindo maliciosamente em um curto prazo e com um baixo custo adicional.

Acur´acia

Os gr´aficos da Figuras 5.22, 5.23 e 5.24 apresentam o grau de acur´acia obtido com o diagn´ostico da grade, mediante 1/6, 1/3 e 2/3 dos n´os corrompendo os resultados dos jobs processados. Como constatado, a acur´acia sofre com um n´umero maior de n´os maliciosos no sistema, especialmente se os testes s˜ao aplicados com menos freq¨uˆencia. Enquanto, por exemplo, com 1/6 de maliciosos na grade obt´em-se uma acur´acia de 99,7% com 5 rodadas a cada 6h, esse valor decresce vertiginosamente para 86,7% com a mesma quantidade de rodadas, acontecendo a cada 24h em uma grade com 2/3 dos n´os comprometidos.

Figura 5.22 Acur´acia com 1/6 de maliciosos

Novamente, comparando estes resultados com aqueles obtidos no primeiro cen´ario, nota-se um significativo ganho na quantidade de jobs processados corretamente. Por exemplo: com 2/3 dos n´os maliciosos na grade, no primeiro cen´ario foi observado uma acur´acia de 83,2% sem blacklist e 89,2% com blacklist, ambos com 8 rodadas de teste. Neste segundo cen´ario, para a mesma quantidade de rodadas usando blacklist com re- puta¸c˜ao, a acur´acia salta, no pior caso, para 94%, o que leva `a conclus˜ao que o modelo

5.3. Conclus˜ao 71

proposto n˜ao s´o ´e escal´avel, mas tamb´em eficiente, pois ele ´e capaz de elevar a acur´acia dos jobs processados, ao passo que reduz o overhead introduzido.

Figura 5.23 Acur´acia com 1/3 de maliciosos

Figura 5.24 Acur´acia com 2/3 de maliciosos

5.3 CONCLUS˜AO

Para validar o modelo proposto, as simula¸c˜oes foram realizadas com diferentes quotas de n´os maliciosos em dois cen´arios: o primeiro n˜ao considera os aspectos de reputa¸c˜ao e o segundo inclui a reputa¸c˜ao e, portanto, eleva¸c˜ao de status e reconfigura¸c˜ao de clusters.

5.3. Conclus˜ao 72

Em ambos os cen´arios estudados, 8 rodadas de teste mostram-se como uma quantidade ideal para a estrat´egia de diagn´ostico proposta. Enquanto no melhor caso do primeiro cen´ario pode-se obter um grau de detec¸c˜ao acima de 90%, com uma acur´acia de apro- ximadamente 98% e custo de 15%, no segundo cen´ario foi observado uma detec¸c˜ao de 100% dos n´os maliciosos, com uma acur´acia de 99,7% e um custo de 12,3%.

Estes n´umeros obtidos com as simula¸c˜oes atestam a eficiˆencia do modelo ao detec- tar e isolar diferentes quantidades de n´os maliciosos de uma grade, comprovando tamb´em que o uso de diagn´ostico aplicado no contexto de seguran¸ca permite minimizar ou mesmo extinguir a presen¸ca de n´os interessados em corromper os resultados das aplica¸c˜oes em grade. As t´ecnicas de verifica¸c˜ao focalizada e blacklist, associadas a um esquema de re- puta¸c˜ao que leva em conta o tempo de vida dos n´os no ambiente, viabilizam o isolamento de n´os com mau comportamento, obtendo assim um alto ´ındice de acur´acia dos processos, sem aumento do overhead.

CAP´ITULO 6

CONCLUS ˜OES

Este cap´ıtulo traz as conclus˜oes e considera¸c˜oes finais a respeito do modelo de diagn´ostico proposto para tolerar ataques de manipula¸c˜ao de resultados em grades computacionais. As principais contribui¸c˜oes e resultados oferecidos pela pesquisa realizada e os direciona- mentos para trabalhos futuros tamb´em s˜ao destacados neste cap´ıtulo.

6.1 CONTRIBUIC¸ ˜OES E RESULTADOS

Por tratar-se de uma tecnologia recente, certos aspectos de seguran¸ca na computa¸c˜ao em grade ainda n˜ao foram suficientemente explorados. Em um passado recente, a seguran¸ca em grades tratava apenas do gerenciamento de identidades e controle de acesso, atrav´es de uma abordagem baseada em infra-estrutura de chave p´ublica. Pesquisas realizadas nessa ´area tˆem dirigido esfor¸cos para proteger n˜ao s´o a comunica¸c˜ao, mas tamb´em as aplica¸c˜oes em execu¸c˜ao e os usu´arios. No entanto, atualmente nenhuma das plataformas de grades estudadas oferece um mecanismo para garantia de integridade do processamento.

Esta disserta¸c˜ao apresentou um modelo de diagn´ostico de falhas de seguran¸ca para ser utilizado como estrat´egia de detec¸c˜ao de ataques de manipula¸c˜ao de resultados dos jobs em um ambiente de grade. A partir de uma abordagem hier´arquica, distribu´ıda e baseada em reputa¸c˜ao, o modelo permite que a grade isole os n´os indesejados, de tal forma que ao final ´e poss´ıvel oferecer um ambiente de computa¸c˜ao de alto de desempenho livre de n´os maliciosos e resultados manipulados arbitrariamente.

Diagn´ostico em n´ıvel de sistema mostra-se ent˜ao como uma solu¸c˜ao eficaz para o problema aqui discutido, visto que independe das plataformas de hardware utilizadas, considerando a natureza heterogˆenea e dinˆamica das grades. Al´em disso, um modelo de diagn´ostico em n´ıvel de sistema permite que o algoritmo nele baseado possa ser aplicado tanto em grades fechadas (formadas entre corpora¸c˜oes) quanto em grades abertas (cons- titu´ıdas por hosts comuns conectados a Internet dispostos a doarem seus recursos ociosos num esquema de computa¸c˜ao volunt´aria).