DEPSKY: sistema de armazenamento em clouds tolerante a intrusões

(1)

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciências

Departamento de Informática

DEPSKY: SISTEMA DE ARMAZENAMENTO EM

CLOUDS TOLERANTE A INTRUSÕES

Bruno Miguel Maia Rovisco Quaresma

MESTRADO EM ENGENHARIA INFORMÁTICA

Especialização em Arquitectura, Sistemas e Redes de Computadores

(2)

(3)

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciências

Departamento de Informática

DEPSKY: SISTEMA DE ARMAZENAMENTO EM

CLOUDS TOLERANTE A INTRUSÕES

Bruno Miguel Maia Rovisco Quaresma

DISSERTAÇÃO

Projecto orientado pelo Prof. Doutor Alysson Neves Bessani e co-orientado pelo Prof. Doutor Paulo Jorge Paiva de Sousa

MESTRADO EM ENGENHARIA INFORMÁTICA

Especialização em Arquitectura, Sistemas e Redes de Computadores

(4)

(5)

Agradecimentos

Em primeiro lugar, quero agradecer aos meus orientadores do PEI, os Professores Doutores Alysson Bessani e Paulo Sousa, pela orientação dada neste último ano do MEI. Também quero agradecer aos meus colegas, tanto de investigação como de curso, pelos bons momentos passados e troca de impressões sobre temas de interesse.

Agradeço à minha família, especialmente aos meus pais e irmã por me aturarem e facilitarem a conclusão dos meus estudos.

Finalmente agradeço, a todos os meus amigos e amigas, a força e motivação para atingir os meus objectivos.

(6)

(7)

Resumo

A manutenção da disponibilidade e da integridade da informação é um requisito fun-damental em sistemas de armazenamento. Estes sistemas lidam com a perda de dados através de replicação, na qual os dados são armazenados em múltiplas unidades básicas de armazenamento. A ideia base do trabalho aqui apresentado surgiu da constatação que as clouds de armazenamento podem ser vistas como unidades desse tipo.

Com a crescente popularidade das clouds de armazenamento, empresas que lidam com dados críticos começam a pensar em usar estes serviços para armazenar bases de dados de registos médicos, históricos de infra-estruturas críticas, dados financeiros, entre outros. No entanto, muitas pessoas acreditam que informação armazenada num sistema deste tipo é vulnerável, apesar de todas as garantias dadas pelos fornecedores, o que faz da fiabilidade e da segurança as maiores preocupações sobre o armazenamento em clouds.

Este trabalho apresenta o DEPSKY, um sistema que melhora a disponibilidade,

in-tegridade e confidencialidade de informação armazenada em clouds. Para garantir

es-tas propriedades, o sistema DEPSKY disponibiliza dois protocolos, o ADS (Available

DEPSKY), focado em melhorar a disponibilidade e integridade da informação, e o CADS

(Confidential & Available DEPSKY), que adicionalmente melhora a confidencialidade da

informação. Ambos os protocolos fornecem algoritmos para leitura e escrita, à seme-lhança do que acontece com todos os sistemas de armazenamento.

Palavras-chave: Clouds de armazenamento, replicação, disponibilidade, confidencialidade, integridade

(8)

(9)

Abstract

Maintaining availability and integrity of information is a fundamental requirement in storage systems. These systems deal with the loss of data through replication, where data is stored in multiple basic units of storage. The initial idea of the work presented here resulted from the realization that storage clouds can be viewed as such units.

With the increasing popularity of cloud storaging services, companies that deal with critical data start thinking of using these services to store medical records databases, his-torical data of critical infrastructures, financial data, among others. However, many peo-ple believe that information stored that way is vulnerable, despite the guarantees given by providers, which makes reliability and security the major concerns about cloud storaging.

This work presents DEPSKY, a system that improves the availability, integrity and

confidentiality of information stored in the cloud. To ensure these properties DEPSKY

provides two protocols, ADS (Available DEPSKY), focused on improving the availability

and integrity of information, and CADS (Confidential & Available DEPSKY), which

addi-tionally enhances the confidentiality of information. Both provide algorithms for reading and writing data, as is any storage systems.

Keywords: Storage clouds, replication, availability, confidentiality, integrity

(10)

(11)

Conteúdo

Lista de Figuras xiii

Lista de Tabelas xv 1 Introdução 1 1.1 Motivação . . . 1 1.2 Objectivos . . . 3 1.3 Contribuições . . . 3 1.4 Publicações . . . 4 1.5 Planeamento . . . 4 1.6 Estrutura do Documento . . . 5 2 Trabalho Relacionado 7 2.1 Tolerância a Intrusões . . . 7 2.1.1 Introdução ao Tema . . . 7 2.1.2 Replicação . . . 8 2.1.3 Confidencialidade . . . 11 2.2 Clouds de Armazenamento . . . 13 2.2.1 Considerações Gerais . . . 13 2.2.2 Detalhes Adicionais . . . 15 2.3 Considerações Finais . . . 17 3 DEPSKY 19 3.1 Apresentação . . . 19 3.2 Modelo de Sistema . . . 20 3.3 Modelo de Dados . . . 21 3.4 ADS - Available DEPSKY . . . 22 3.4.1 Algoritmo de Escrita . . . 22 3.4.2 Algoritmo de Leitura . . . 23

3.5 CADS - Confidential & Available DEPSKY . . . 23

3.6 Trabalhos Similares . . . 27

3.7 Considerações Finais . . . 28 ix

(12)

4 Concretização do DEPSKY 29 4.1 Considerações Gerais . . . 29 4.2 Arquitectura . . . 31 4.3 Diagramas UML . . . 32 4.4 Controladores . . . 36 4.5 Considerações Finais . . . 37 5 Avaliação Experimental do DEPSKY 39 5.1 Custo do Armazenamento Replicado . . . 39

5.2 Desempenho e Disponibilidade . . . 41

5.2.1 Metodologia . . . 41

5.2.2 Latência de Leitura . . . 42

5.2.3 Latência de Escrita . . . 44

5.3 Considerações Finais . . . 45

6 Conclusões e Trabalho Futuro 47 6.1 Conclusões . . . 47

6.2 Trabalho Futuro . . . 48

Referências 51

(13)

(14)

(15)

Lista de Figuras

3.1 Visão sobre a distribuição de informação pelas clouds. . . 20

3.2 Decomposição do Data Unit X do DEPSKY, do conceito à concretização. . . 22

4.1 Visão minimalista sobre a estrutura do DepSky. . . 31

4.2 Diagrama de classes do sistema. . . 33

4.3 Diagrama de sequência simplificado de uma operação de escrita. . . 34

4.4 Diagrama de sequência simplificado de uma operação de leitura. . . 36

5.1 FDC para as latências de leitura de dados com 100K bytes observadas em quatro diferentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três versões do DEPSKYreplicando dados por essas clouds. . . 42

5.2 FDC para as latências de leitura de dados com 1M bytes observadas em quatro diferentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três versões do DEPSKYreplicando dados por essas clouds. . . 43

5.3 FDC para as latências de leitura de dados com 10M bytes observadas em quatro diferentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três versões do DEPSKYreplicando dados por essas clouds. . . 43

(16)

(17)

Lista de Tabelas

1.1 Planeamento inicial do PEI. . . 5

2.1 Custo, em USD, do armazenamento, entrada e saída de 1 Gb de dados em

serviços de armazenamento pay-per-use estudados. . . 16

2.2 Custo, em USD, de efectuar 10000 pedidos a serviços de armazenamento

pay-per-useestudados. . . 17

2.3 Alguns limites conhecidos de serviços livres de encargos estudados. . . . 17

4.1 Número de linhas de código necessárias para cada componente do sistema. 30

5.1 Custo estimado, em USD, de 10.000 operações de leitura e escrita de

dados com 100KB, 1MB e 10MB nas clouds. . . 40

5.2 Custo estimado, em USD, de 10.000 operações de leitura e escrita de

dados com 100KB, 1MB e 10MB usando os protocolos do DEPSKY. . . . 40

5.3 Número de falhas observadas durante as experiências de leitura. O “10+10hs”

para a Azure na experiência de 10M significa que para além das 10 falhas reportadas houve um período de 10 horas onde mais de 95% dos acessos

individuais a este sistema falharam. . . 44

5.4 Latência média (ms) de escrita para diferentes tamanhos de unidades de

dados, configurações do DEPSKYe clouds de armazenamento. . . 44

(18)

(19)

Capítulo 1

Introdução

Este relatório descreve o trabalho realizado no âmbito da disciplina de Projecto de Engenharia Informática (PEI) do Mestrado em Engenharia Informática da Faculdade de Ciências da Universidade de Lisboa.

Este projecto foi desenvolvido na unidade de investigação LaSIGE (Laboratório de Sistemas Informáticos de Grande Escala) sito no Departamento de Informática da Facul-dade de Ciências da UniversiFacul-dade de Lisboa. Fui inserido no grupo de investigação Na-vigators no qual o meu orientador, Prof. Doutor Alysson Neves Bessani, e co-orientador, Prof. Doutor Paulo Jorge Paiva de Sousa, estão também inseridos.

Por este motivo de proximidade, ao longo do projecto foi possível a existência de uma boa comunicação de forma a que certas ideias ou dúvidas, que tenham surgido, fossem rapidamente discutidas.

Neste capítulo introdutório são apresentadas a motivação, os objectivos, as contribui-ções e o planeamento do trabalho descrito neste relatório. A secção final deste capítulo descreve de forma resumida a oraganização dos restantes capítulos.

1.1 Motivação

A manutenção da disponibilidade e da integridade da informação é um requisito fun-damental em sistemas de armazenamento. Os sistemas de armazenamento distribuído estão a tornar-se cada vez mais populares com o advento das tecnologias SAN (Storage Area Network) e NAS (Network Attached Storage), assim como a crescente disponibili-dade de discos de baixo custo. Estes sistemas lidam com a perda de dados através da replicação, na qual os dados são armazenados em múltiplas unidades básicas de armaze-namento (discos ou servidores), doravante denominados objectos base.

Um desafio importante deste tipo de sistemas é fornecer uma elevada disponibilidade, tal como já tinha sido referido. Isto significa que o sistema deve permanecer disponível ainda que um objecto base falhe; por vezes mais falhas são toleradas dependendo da resili-ência do sistema. A resiliresili-ência de um sistema de armazenamento distribuído está definida

(20)

Capítulo 1. Introdução 2

como o número f de um total de n objectos base que podem falhar sem este sistema deixar de oferecer disponibilidade e consistência. O nível de resiliência dita a disponibilidade do serviço pois ao replicar-se a informação em vários objectos base (discos, servidores), a disponibilidade da informação aumenta.

Um sistema de armazenamento distribuído emula um objecto partilhado robusto atra-vés da manutenção de cópias deste em locais diferentes, para que a informação sobreviva. Isto pode ser conseguido sem muito esforço financeiro usando vários discos de baixo custo ou PC’s de capacidade moderada, em vez de servidores poderosos, para armazenar a informação. É típico focar na abstracção de objecto de armazenamento, que apenas suporta as operações básicas de leitura e escrita pelos clientes. O estudo destes objectos é fundamental, pois estes são os alicerces para a construção de sistemas de armazenamento mais complexos.

Os algoritmos de armazenamento distribuído enfrentam o desafio de superar a as-sincronia e uma variedade de faltas, sem se desviar significativamente das garantias de consistência e desempenho do armazenamento tradicional (centralizado). Tais algoritmos variam em função de várias dimensões: na semântica de consistência que fornecem; na sua resiliência (número e tipos de faltas toleradas); na sua arquitectura (se os objectos base são simples discos ou servidores mais complexos); e na sua complexidade (e.g., la-tência). Claramente, existem muitos tradeoffs: por exemplo, oferecer maior consistência ou resiliência adicional tem impacto na complexidade.

Nos últimos tempos tem-se observado uma crescente oferta de serviços na Internet que disponibilizam espaço nos seus servidores para um cliente armazenar e partilhar informa-ção, normalmente ficheiros. No contexto deste trabalho tais serviços podem ser vistos como objectos base para a construção de um sistema de armazenamento. Contudo, terão de ser asseguradas características fundamentais como integridade, disponiblidade e con-fidencialidade, que são características básicas da segurança da informação, não estando esta segurança restrita somente a sistemas computacionais, informação digital ou sistemas de armazenamento. A segurança da informação está relacionada com a protecção de um conjunto de dados, no sentido de preservar o valor que possuem para uma entidade, indi-víduo ou organização. O conceito de segurança informática está directamente relacionado com o de segurança da informação, incluindo não apenas este mas também a segurança dos próprios sistemas.

Actualmente, muitas organizações começam a optar de forma progressiva pelo uso de clouds de armazenamento. Exemplos recentes são serviços como o Twitter e o Facebook que até há bem pouco tempo tinham os seus próprios data centers de armazenamento e hoje tercerizam parte deste serviço para a Amazon e o seu Simple Storage Service (Ama-zon S3) [1]. Esta tendência pode ser definida como o armazenamento de informação num sistema de armazenamento remoto mantido por terceiros. A Internet fornece a ligação entre o computador e esse sistema.

(21)

O armazenamento em clouds tem algumas vantagens sobre o armazenamento tradici-onal. Por exemplo, se se armazenar informação numa cloud, esta estará acessível a partir de qualquer local com acesso à Internet e evita a necessidade da manutenção de uma infra-estrutura de armazenamento na organização.

À medida que as clouds de armazenamento se tornam mais populares, empresas que lidam com dados critícos começam a pensar em usar estes serviços para armazenar bases de dados de registos médicos, históricos de infra-estruturas críticas, dados financeiros, entre outros. No entanto, um perigo muitas vezes ignorado está no facto dos sistemas de armazenamento remoto estarem fora do controlo dos donos dos dados, apesar das garantias dadas pelos fornecedores (e.g., SLA - Service Level Agreement), o que faz da fiabilidade e da segurança as maiores preocupações sobre o armazenamento em clouds.

1.2 Objectivos

O principal objectivo deste trabalho era a concretização de um sistema de

armazena-mento em clouds tolerante a intrusões, o DEPSKY, assegurando a integridade,

disponibi-lidade e confidenciadisponibi-lidade da informação. Outro dos objectivos deste trabalho era realizar diversos tipos de testes ao sistema, analisando o seu desempenho.

1.3 Contribuições

No inicio desta dissertação, foi necessário realizar um estudo acerca do tema tolerân-cia a intrusões, de forma a aprofundar conhecimentos nesta área de investigação, inci-dindo na replicação e confidencialidade de informação. Durante este estudo inicial foi dada uma pequena contribuição a um projecto paralelo, que consistiu na actualização de uma biblioteca baseada em sistemas de quóruns activos 2.1.2.

Também foi necessária investigação sobre clouds de armazenamento (2.2), incluindo o estudo de API’s de variados serviços do género.

Após este processo foi iniciado o desenho e concretização do DEPSKY. Estas tarefas

foram realizadas de forma incremental tendo sido efectuadas várias revisões de modo a melhorar o sistema. À medida que se efectuava uma nova versão, eram realizados testes ao desempenho de modo a se perceber o que poderia ser melhorado.

A principal contribuição desta tese é o DEPSKY, um sistema que garante

disponibi-lidade, integridade e confidencialidade de informação armazenada em clouds. A ideia fundamental deste sistema é replicar a informação por várias clouds de armazenamento, utilizando algoritmos para armazenamento fiável e partilha de segredos.

O DEPSKY fornece uma abstracção de um sistema de armazenamento tolerante a

intrusões, possuindo algoritmos que permitem a leitura e escrita de dados em clouds. Du-rante o seu desenvolvimento tomaram-se opções tendo em conta a disponibilidade e o

(22)

custo do armazenamento em clouds. Outra contribuição importante é a análise das medi-das efectuamedi-das ao sistema e a esses serviços de armazenamento em clouds. Os resultados

obtidos permitiram efectuar a avaliação aos protocolos do DEPSKY.

É também de referir que a parte considerável do tempo dispendido em termos de desenvolvimento do sistema foi para estudo das API’s dos serviços usados e subjacente concretização do controlador (responsável pela comunicação) para cada serviço.

1.4 Publicações

O trabalho descrito neste relatório deu origem à seguinte publicação:

Título: Melhorando a Disponibilidade e Confidencialidade dos Dados Armazenados em Clouds [30]

Autores: Bruno Quaresma, Alysson Bessani e Paulo Sousa

Em: INForum 2010 [6] - Segurança de Sistemas de Computadores e Comunicações

1.5 Planeamento

O planeamento inicial deste trabalho consistia nas seguintes tarefas: • T1 - Estudo da replicação e de técnicas de replicação

• T2 - Estudo de técnicas que garantem confidencialidade em informação replicada, nomeadamente esquemas de partilha de segredos e códigos de apagamento

• T3 - Estudo das clouds de armazenamento existentes na web e suas API’s • T4 - Desenho do sistema

• T5 - Concretização do sistema • T6 - Testes ao sistema

• T7 - Escrita da Tese de Mestrado

A calendarização destas tarefas é apresentada na figura 1.5. Este planeamento foi seguido na perfeição até à fase de testes ao sistema (T6). Teve que ser investido mais um mês nesta tarefa devido à necessidade de se efectuarem melhoramentos ao sistema, o que levou ao adiamento da escrita desta tese para o mês de Junho de 2010.

(23)

Capítulo 1. Introdução 5 Tarefas Mês/Ano T1 Setembro e Outubro de 2009 T2 Novembro de 2009 T3 Dezembro de 2009 e Janeiro de 2010 T4 Fevereiro de 2010 T5 Março de 2010 T6 Abril de 2010 T7 Maio de 2010

Tabela 1.1: Planeamento inicial do PEI.

1.6 Estrutura do Documento

Este documento encontra-se organizado da seguinte forma:

• Capítulo 2 - Este capítulo descreve o trabalho relacionado com o sistema desenvol-vido. É introduzido o conceito tolerância a intrusões e como a replicação é impor-tante para este tipo de sistemas. Também são introduzidas técnicas de distribuição de informação por réplicas de maneira a garantir confidencialidade. Mais especi-ficamente são abordadas as seguintes técnicas: partilha de segredos e códigos de apagamento com criptografia simétrica. Neste capítulo também são apresentadas as clouds de armazenamento, assim como são analisadas propriedades e caracterís-ticas que estas devem assegurar.

• Capítulo 3 - Apresentação do sistema de armazenamento tolerante a intrusões DEPSKY,

modelo de sistema, modelo de dados e protocolos concretizados. Para concluir são

analisados trabalhos recentes que tentam fazer algo similar ao DEPSKY, sendo

efec-tuadas algumas comparações entre os sistemas estudados.

• Capítulo 4 - Neste capítulo são analisados os detalhes da concretização do sistema descrito no capítulo anterior.

• Capítulo 5 - Este capítulo contém uma avaliação experimental ao DEPSKY,

efectu-ada durante o mês de Junho de 2010. São analisados os desempenhos dos protoco-los e das clouds individualmente.

• Capítulo 6 - Neste último capítulo são apresentadas as conclusões deste trabalho assim como algum trabalho a desenvolver no futuro.

(24)

(25)

Capítulo 2

Trabalho Relacionado

Neste capítulo é resumido o estudo inicial efectuado sobre a área de tolerância a in-trusões e sobre clouds de armazenamento.

2.1 Tolerância a Intrusões

2.1.1 Introdução ao Tema

Com a utilização crescente dos sistemas distribuídos, em variadas áreas de actividade, aumentou a preocupação com a confiabilidade dos diversos componentes de um sistema [33, 17]. A tolerância a faltas é um dos aspectos mais importantes nos modelos de sis-temas distribuídos clássicos e o seu objectivo é aumentar a disponibilidade e fiabilidade dos sistemas. Um sistema tolerante a faltas deve continuar a prestar o seu serviço correc-tamente mesmo na eventualidade de existir um problema com algum dos componentes. Esta visão levou à adopção de uma atitude pessimista em relação ao funcionamento dos sistemas distribuídos, na qual se assume que nenhum sistema é totalmente correcto (e.g., foram cometidos erros na fase de especificação, desenho ou concretização do sistema) e poderá estar susceptível a faltas.

Os sistemas distribuídos em geral assentam no modelo: Falta ⇒ Erro ⇒ Falha. A tolerância a faltas não trata de impedir ou prevenir que faltas aconteçam mas antes evitar que estas levem a erros e consequente falha do sistema. Opta-se por esta abordagem porque pode ser impossível prever todas as faltas possíveis num sistema, já que estas podem ser causadas por diversos motivos assim como ter uma origem interna ou externa. A replicação foi a técnica encontrada para construir sistemas tolerantes a faltas pois contribui para um aumento da resiliência do sistema. A resiliência de um sistema distri-buído está definida como o número f de um total de n máquinas que podem falhar sem este sistema renunciar à disponibilidade e à consistência. Esta distribuição também au-menta a resistência a faltas na medida em que, ao contrário de um sistema centralizado, não existe um ponto único de falha. Contudo, no paradigma da tolerância a faltas, as técnicas usadas assumem que componentes do sistema podem falhar por paragem ou por

(26)

Capítulo 2. Trabalho Relacionado 8

omissão de passos do algoritmo que executa. Isto significa que o sistema pode não estar preparado para lidar com falhas causadas com intencionalidade por um atacante malici-oso, e consequentemente pode ser comprometido.

O número de ataques efectuados com sucesso a sistemas distribuídos tem vindo a aumentar o que levou organizações a preocuparem-se com a segurança e confiabilidade dos seus serviços. Isto fez com que surgisse o conceito tolerância a intrusões [33, 20]. A tolerância a intrusões é uma extensão da tolerância a faltas tradicional que considera intru-sões como faltas. Com esta abordagem tornou-se possível desenvolver sistemas tolerantes a faltas que, ao mesmo tempo, respeitam as propriedades de segurança definidas.

Existe ainda outro conceito relacionado com tolerância a intrusões, denominado tole-rância a faltas bizantinas. Faltas bizantinas [27], ou arbitrárias, são o tipo de faltas mais genérico que existe e englobam todos os tipos de faltas que podem ocorrer num sistema, incluindo as intrusões. Quando ocorre uma falta bizantina, o sistema pode responder de forma imprevisível a menos que tenha sido construído para tolerar este tipo de faltas.

A maioria dos trabalhos relacionados com a tolerância a intrusões assume que o sis-tema está envolvido num ambiente bizantino, ou seja, que o sissis-tema é susceptível a faltas arbitrárias, seja uma intrusão, acidental ou maliciosa, uma falha do software ou por moti-vos externos ao sistema.

Tal como na tolerância a faltas clássica, recorre-se a replicação para conceber sistemas tolerantes a faltas bizantinas. Nas próximas secções são discutidas alguns modelos de replicação tolerantes a faltas bizantinas estudados. Também são discutidas técnicas para garantir a confidencialidade de dados replicados.

2.1.2 Replicação

A ideia básica da replicação consiste em distribuir cópias de informação por um con-junto de servidores e tem sido amplamente usada em tolerância a faltas para garantir a disponibilidade e a fiabilidade de sistemas distribuídos. Muitos dos trabalhos em sistemas distribuídos tolerantes a intrusões são também baseados em replicação. Este tipo de so-lução permite garantir a disponibilidade e a integridade do sistema se existirem intrusões num número limitado de réplicas.

Existem dois modelos de replicação tolerantes a faltas bizantinas, a Replicação de Máquina de Estados [25] e Sistemas de Quóruns Bizantinos [28]. Existe ainda uma outra abordagem que foi estudada e que pode ser vista como um híbrido entre os dois modelos referidos antes, denominada Sistemas de Quóruns Activos [12].

Seguidamente, todas estas abordagens são analisadas com mais detalhe. Replicação de Máquina de Estados

A replicação de máquina de estados é a abordagem generalista para a concretização de serviços tolerantes a faltas em que cada servidor é uma máquina de estados definida

(27)

por variáveis de estado e comandos atómicos, que são operações sobre as variáveis de estado. Os clientes enviam pedidos para a execução de comandos para todas as réplicas do sistema. Nesta abordagem as réplicas começam todas com o mesmo estado e no tempo de actividade das réplicas existe acordo e ordem total o que significa que todas as réplicas executam os mesmos comandos pela mesma ordem. Obter estas propriedades, acordo e ordem total, requer o uso de algoritmos distribuídos que ofereçam certas garantias sobre a entrega das mensagens ao conjunto de réplicas. Para além disso, as operações executadas pelas réplicas têm de ser deterministas pois o estado resultante, após a operação, em todas as réplicas do sistema tem de ser o mesmo. Como é impossível resolver o problema do consenso, também conhecido como o problema da difusão atómica, em ambientes assíncronos de forma determinista os sistemas usualmente requerem a existência de certos limites temporais [19].

Sistemas de Quóruns Bizantinos

Um sistema de quóruns bizantinos [28] pode ser definido como um conjunto de sub-conjuntos de servidores, em que cada sub-conjunto é um quórum. A intersecção e a disponibilidade são duas características fundamentais dos quóruns. A primeira assegura que as operações efectuadas nos diferentes quóruns mantêm-se consistentes enquanto que a segunda está implícita pois cada quórum actua em prol do sistema.

Um sistema de quóruns pode ser usado para prover uma abstracção de memória par-tilhada fiável bastando para isso definir objectos distribuídos e operações a realizar sobre estes. Através de um sistema de quóruns é possível definir objectos distribuídos e sobre eles realizar operações de tal forma que simulam a existência de uma memória partilhada fiável.

Na maioria das implementações de sistemas de quóruns bizantinos são usados n ≥ 3f + 1 servidores com quóruns de tamanho 2f + 1, sendo f o número de faltas toleradas. Assim é assegurado que, mesmo na eventualidade de acontecerem f faltas, existem pelo menos dois quóruns que se intersectam numa réplica correcta, ou seja, cada um dos dois quóruns mantém um número de servidores correctos de maneira a que pelo menos um quórum é formado apenas por servidores correctos.

Tipicamente, em sistemas de quóruns, o estado de um registo em cada servidor é representado pelo seu valor e por uma estampilha temporal, ou número de versão. Uma operação de escrita sobre este registo é processada da seguinte maneira: a estampilha temporal é lida dos quóruns, incrementada, indicando a próxima versão do registo, e logo a seguir é escrito o novo valor para o sistema juntamente com a nova estampilha. Numa operação de leitura sobre este registo o sistema retorna o valor e estampilha correntes do registo. Em alguns sistemas de quóruns bizantinos em que existe concorrência entre operações, é usado um mecanismo denominado de writeback no qual o valor lido é escrito de volta no sistema obrigando a que todas as leituras realizadas posteriormente retornem

(28)

o mesmo par (valor, e estampilha temporal) ou uma versão mais recente desse par. Sistemas de Quóruns Activos

Enquanto que a replicação de máquina de estados é uma solução genérica para con-cretizar sistemas tolerantes a faltas bizantinas, os quóruns são geralmente usados para construir repositórios de dados tolerantes a faltas bizantinas. Ao servirem para concre-tizar algo de mais simples do que replicação de máquina de estados, muitas vezes os trabalhos com quóruns evitam a necessidade de realizar consenso não ficando limitados pelo resultado FLP [19], podendo os algoritmos ser totalmente assíncronos. No entanto, a principal diferença entre a replicação de máquina de estados e os sistemas de quoruns é que as operações na replicação de máquina de estados envolvem sempre todos os ser-vidores, enquanto que nos sistemas de quóruns as operações são geralmente feitas sobre um quórum, o que torna os algoritmos mais escaláveis.

Segundo a proposta [12], os Sistemas de Quóruns Activos (SQA) surgiram da consta-tação de que os sistemas de quóruns apresentam uma escalabilidade e simplicidade maior que os protocolos baseados em máquinas de estados, mas apenas podem ser utilizados na concretização de sistemas simples como por exemplo sistemas de armazenamento.

Sistemas mais complexos que necessitam que exista acordo entre servidores têm de ser concretizados recorrendo a replicação de máquinas de estado. Um sistema de quóruns activos pode ser visto como um híbrido entre sistemas de quóruns e máquinas de estado, que junta as duas abordagens num único sistema. Um sistema deste tipo usa diferentes protocolos para diferentes operações, ou seja, protocolos de sistemas de quóruns para as operações de leitura e escrita, e, protocolos de máquina de estados para outras mais complexas, como uma actualização.

Através de SQA é assegurado que um sistema construído sobre esta abordagem per-manece correcto na presença de n ≥ 3f + 1 réplicas, sendo f o número máximo de réplicas que podem falhar de forma bizantina. Se este pressuposto for satisfeito um ob-jecto implementado usando o SQA satisfaz as seguintes propriedades:

• Linearizability: O sistema executa operações numa determinada ordem de modo a que aparente ser acedido sequencialmente [21];

• Wait-freedom: Operações requesitadas por clientes correctos terminam, indepen-dentemente do comportamento de outros clientes, correctos ou maliciosos, do sis-tema [23].

A primeira é uma propriedade de safety que garante que as réplicas se comportam si-mulando um sistema centralizado, executando uma mensagem de cada vez. A segunda propriedade é uma propriedade de liveness importante para garantir a correcta terminação de todas as operações.

(29)

Um SQA permite replicar objectos sendo que, sobre estes, é possível realizar três tipos de operações distintas:

• Escrita: O estado do objecto é alterado para o valor recebido como entrada. • Leitura: O estado do objecto é retornado.

• Actualização (Read-Modify-Write): O estado do objecto é modificado de acordo com os parâmetros recebidos e o estado do objecto.

As operações de leitura e escrita são implementadas através de sistemas de quóruns bizantinos e por isso são operações assíncronas, não dependentes de condições optimistas ou pressupostos sobre tempo para garantir a terminação ao contrário da operação de actu-alização que recorre a replicação de máquina de estados, necessitando de sincronia parcial para resolver o consenso. Os protocolos de leitura e escrita são baseados nos sistemas de quóruns e o de actualização é baseado no CL-BFT, apresentado em [15].

2.1.3 Confidencialidade

Confidencialidade é a propriedade da informação que garante que esta não será di-vulgada a entidades sem autorização, por outras palavras, garantir que a informação está apenas acessível para os que têm autorização de acesso a esta.

A confidencialidade é compreendida no domínio da segurança informática, como a protecção de informação trocada entre um remetente e um ou mais destinatários contra terceiros. Isto deve ser feito independentemente da segurança do sistema de comunicação utilizado. De facto, uma questão de grande interesse é o problema de garantir o sigilo de comunicação utilizado quando o sistema é inerentemente inseguro, como a Internet.

Num sistema que garante a confidencialidade, um terceiro que obtenha informação trocada entre rementente e destinatário não será capaz de extrair qualquer informação inteligível. Isto é garantido através de mecanismos de criptografia.

A replicação é normalmente vista como sendo má para a confidencialidade, porque se informação privada se encontra replicada apenas se torna mais fácil para um atacante a conseguir, não mais difícil. Apesar disso, existem algumas técnicas para garantir confi-dencialidade em dados replicados, como as que são explicadas de seguida.

Partilha de Segredos

Um esquema de partilha de segredos [32] é o método para dividir um segredo entre um grupo de participantes, em que a cada um deles é atribuída um parte do segredo. O segredo pode ser reconstruído apenas quando um determinado número de partes são recombinadas, pois partes individuais não têm utilidade por si só.

Mais formalmente, num esquema de de partilha de segredos existe um distribuidor e n participantes. O distribuidor gera o segredo a partir da informação original, divide-o por

(30)

n partes e entrega uma parte a cada participante. As partes poderão mais tarde ser usadas para a reconstrução da informação original mas individualmente não fornecem nenhuma informação sobre seu conteúdo, ou seja, é inexequível extrair de uma parte alguma da informação original.

O distribuidor usa um algoritmo de maneira a que grupos de t ou mais participantes, possam reconstruir a informação original, com as suas partes. Se por exemplo n = 5 e t = 3, a informação original é distribuída por 5 partes, uma para cada participante, e um grupo de 3 ou mais partes participantes pode desvendar o segredo.

Códigos de Apagamento

Os códigos de apagamento são semelhantes aos códigos de correcção de erros (FEC - Forward Error Correction) usados em telecomunicações, mas enquanto nos primeiros a informação pode apenas ser apagada, nos últimos pode também ser modificada. A ideia base consiste na divisão de um ficheiro em n fragmentos de forma a que seja suficiente ter k fragmentos para reconstruí-lo, mas k − 1 fragmentos não cheguem para o fazer. Para este efeito usa-se um código de apagamento-(k,n).

No contexto da confiabilidade apenas foram estudadas algumas propostas, nomeada-mente o mecanismo denominado AVID (Asynchronous Verifiable Information Dispersal) e o mesmo mecanismo mas com confidencialidade, o cAVID. Ambos propostos em [14]. Um cliente que quer armazenar um ficheiro F começa por o codificar como um vec-tor [F 1; ...; F n] usando um código de apagamento-(k,n). Além disso obtém um conjunto de fingerprints [24] calculando um vector com sínteses criptográficas de cada F i : D = [D1; ...; Dn]. Depois, toda essa informação é enviada para os servidores usando um pro-tocolo de difusão fiável.

Se o cliente for malicioso e alguns dos fragmentos estiverem corrompidos, há duas possibilidades: o número de fragmentos disponíveis permite reconstruir o ficheiro, o que é feito; ou não é possível reconstruir esses fragmentos e o ficheiro não é armazenado. Quando a operação termina os servidores apagam todos os fragmentos que não lhes per-tencem.

A operação de leitura consiste simplesmente em pedir fragmentos aos servidores até se obterem os k necessários para reconstruir F . O parâmetro k tem de verificar a condição: f + 1 ≤ k ≤ n − 2f . A melhor resistência é obtida quando n = 3f + 1, logo k = f + 1. O mesmo artigo apresenta o esquema cAVID que garante também a confidencialidade dos dados armazenados. Para garantir a confidencialidade é necessário haver controlo de acesso ao ficheiro. Para o efeito junto do ficheiro é guardada uma lista de controlo de acesso L com os identificadores dos clientes que a eles podem aceder. A forma como é conseguida a confidencialidade é simples: o ficheiro é cifrado usando criptografia simé-trica antes de ser armazenado usando o esquema AVID. Uma desvantagem é a necessidade de partilha de uma chave secreta O problema é o que se faz da chave secreta. Se o cliente

(31)

ficasse com a chave para si, só ele poderia recuperar o ficheiro, o que em geral não é o objectivo.

2.2 Clouds de Armazenamento

2.2.1 Considerações Gerais

Uma cloud de armazenamento pode ser descrita como um serviço online que fornece espaço nos seus servidores para um cliente armazenar informação. A comunicação entre o cliente e o serviço, como o acesso ou actualização de dados, é efectuada sobre a Internet. Existem variados sistemas de armazenamento em clouds, uns possuem um foco muito específico, como armazenar apenas mensagens de e-mail ou imagens digitais, outros po-dem armazenar todo o tipo de informação digital.

As instalações que abrigam sistemas de armazenamento em clouds são chamados de data centers. Uma cloud de armazenamento pode ser concretizada com um ou mais data centers.

O seu funcionamento pode ser descrito da seguinte forma: um cliente envia ficheiros através da Internet para os servidores que guardam a informação. O acesso aos servidores pelo cliente é efectuado através de interfaces web ou serviços web, que permitem o acesso e manipulação dos dados armazenados. Tais serviços são usualmente baseados no modelo REST (REpresentational State Transfer) ou na arquitectura SOAP (Simple Object Access Protocol).

Os sistemas de armazenamento em clouds geralmente usam centenas de servido-res porque ocasionalmente os computadoservido-res precisam de manutenção ou reparação logo torna-se importante armazenar a mesma informação em várias máquinas, para introduzir redundância no sistema. Sem redundância, um sistema de armazenamento em clouds não poderia garantir a um cliente que a sua informação estará sempre disponível. Por exem-plo, a maioria dos sistemas replica a informação por servidores que usam diferentes fontes

de electricidade (normalmente também geograficamente afastados) ou usam UPS1_,

per-mitindo aos clientes o acesso à sua informação mesmo em caso de falha no fornecimento de electricidade.

Nem todos os clientes estão preocupados apenas com a falta de espaço, alguns usam sistemas de armazenamento em clouds para backup de informação, o que garante que, caso haja algum problema na infra-estrutura computacional do cliente, a informação es-tará intacta na cloud de armazenamento.

Actualmente estão disponíveis na web algumas centenas de fornecedores de armaze-namento em clouds e o número tem vindo a aumentar. Além disso, também o espaço de armazenamento oferecido aos clientes parece crescer regularmente.

1_{UPS (Uninterruptible Power Supply) - é um sistema de alimentação elétrico que entra em}

(32)

Existem fornecedores de armazenamento em clouds que cobram uma quantia fixa por uma quota de espaço e largura de banda de entrada e saída de dados, enquanto outros usam um modelo pay-per-use e cobram quantias variáveis consoante o espaço ocupado e a largura de banda utilizada pelo cliente. Além disso, o modelo de cobrança das clouds

pay-per-useincorpora o conceito de elasticidade de recursos: paga-se apenas pelo uso e

o serviço pode crescer arbitrariamente para acomodar altas demandas esporádicas. De seguida exemplificam-se alguns dos serviços que fornecem armazenamento em clouds (Cloud Storaging):

• Clouds Pay-per-use

– Amazon Simple Storage Service (Amazon S3) [1] – Microsoft Windows Azure Platform [8]

– Nirvanix Storage Delivery Network (Nirvanix SDN) [9] – RackSpace [10];

• Clouds de custo fixo – DivShare [3] – DocStoc [4] – Box.net [2]

– FilesAnywhere [5]

Em geral, o preço do armazenamento online tem vindo baixar devido à entrada de cada vez mais empresas neste negócio. Isto levou muitas empresas que cobram pelos seus serviços a optarem por fornecer uma alternativa gratuita que oferece algum espaço para armazenamento, mas com limitações quando comparados aos serviços pagos.

As duas maiores preocupações acerca do armazenamento em clouds são a fiabilidade e a segurança. É improvável que uma organização confie a seus dados critícos a outra entidade sem a garantia que terá acesso a estes dados sempre que quiser (disponibilidade), que estes não serão corrompidos (integridade) e que mais ninguém terá acesso a eles sem a sua autorização (confidencialidade). Para garantir a segurança da informação, a maioria dos sistemas usa uma combinação de técnicas, incluindo:

• Criptografia: algoritmos criptográficos são usados para codificar a informação tornando-a ininteligível e qutornando-ase impossível de decifrtornando-ar sem tornando-a chtornando-ave ustornando-adtornando-a ptornando-artornando-a cifrtornando-ar tornando-a infor-mação, normalmente uma chave secreta partilhada entre cliente e o serviço;

• Autenticação: é necessário o registo do cliente através da criação de credenciais de acesso (e.g., username e password);

(33)

• Autorização: o cliente define quem pode aceder à sua informação.

Mesmo com estas medidas de protecção, muitas pessoas acreditam que informação armazenada num sistema de armazenamento remoto é vulnerável. Existe sempre a pos-sibilidade de um hacker malicioso, de alguma maneira, ganhar acesso à informação do sistema, por exemplo, devido a vulnerabilidades existentes neste. Existe também a pos-sibilidade de funcionários da empresa com acesso aos servidores poderem roubar, alterar ou destruir informação. As empresas no negócio de armazenamento em clouds investem muito dinheiro em medidas de segurança para limitar a possibilidade de roubo ou corrup-ção da informacorrup-ção. Além disso, há sempre a preocupacorrup-ção de colocar os dados critícos (e muitas vezes confidenciais) nas mãos de terceiros, que terão acesso às informações neles contidos.

Finalmente, há também a questão da fiabilidade e disponibilidade dos serviços de ar-mazenamento. Armazenar informação num sistema remoto acedido via Internet coloca a organização vulnerável a todos os problemas de conectividade e indisponibilidade tem-porária da Internet. Além disso, praticamente todos os grandes fornecedores de serviços de armazenamento já sofreram problemas de disponibilidade e/ou corromperam dados de clientes, mesmo com a redundância interna de seus sistemas (os dados são tipicamente armazenados em diferentes data centers do provedor).

2.2.2 Detalhes Adicionais

Nesta secção são descritos detalhes adicionais de alguns serviços de armazenamento estudados.

Distribuição geográfica de Data Centers

A distribuição geográfica é importante na medida em que cria redundância no serviço, não existindo um ponto único de falha, e principalmente porque também aproxima os dados dos clientes.

A lista seguinte relata esta distribuição global de data centers das clouds pay-per-use estudadas:

• Amazon S3 - 3 nos Estados Unidos mais um na Irlanda e outro em Singapura. • Azure - Pelo menos um nos Estados Unidos (Chicago) e outro na Irlanda (Dublin). • Nirvanix - 3 nos Estados Unidos (California, Texas e New Jersey) mais um na

Alemanha e outro no Japão.

• RackSpace - 6 nos Estados Unidos (3 no Texas, 2 na Virginia e 1 em Chicago) mais 2 no Reino Unido e outro em Hong Kong.

(34)

Acordo de nível de serviço

Um SLA (Service Level Agreement) é a parte de um contrato de serviços entre duas ou mais entidades no qual o nível de prestação do serviço é definido formalmente. Na prática, o termo é usado no contexto de tempo de entrega de um serviço ou de um desempenho específico. Por exemplo, se a empresa A contratar um nível de serviço de entregas de 95% em menos de 24 horas à Empresa B, esta já sabe que de todas as entregas que lhe forem dadas para fazer, no mínimo 95% tem que ser feitas em menos de 24 horas.

No contexto do armazenamento em clouds este acordo concentra-se principalmente no nível de disponibilidade dos dados armazenados.

Todas as clouds de armazenamento pay-per-use estudadas (i.e., Amazon S3, Azure, Nirvanix e RackSpace) garantem uma disponibilidade de 99,9% existindo compensações para o cliente caso esta percentagem não se verifique. Estas compensações são, em geral, aplicadas como descontos na facturação do cliente. Os descontos podem variar entre os

10% e os 100% dependendo do nível de disponibilidade efectivamente verificado.2

A única desvantagem para o cliente é ter de monitorizar a disponibilidade e depois ter de relatar ao fornecedor se o nível contratualizado não se verificar para ter direito aos descontos. Existe também um tempo limite para reclamação dos descontos (e.g., 15 dias no caso da Nirvanix e 30 dias nos restantes).

Custo do armazenamento em clouds

O preço praticado pelos serviços de armazenamento em clouds é um dos factores que torna este tipo de armazenamento tão atractivo e que leva muitas organizações a migrarem os seus dados para estes serviços. A tabela 2.1 apresenta o preço praticado por 4 dos servi-ços mais utilizados actualmente. É de salientar que alguns dos serviservi-ços fazem a distinção de armazenamento em diferentes localizações (e.g., o custo de armazenamento num data

center na Europa e num na Ásia é diferente). Por isso, apenas estão representados os

custos para armazenamento em data centers europeus (i.e., Azure e Amazon S3).

Nirvanix Azure - EU Amazon S3 - EU RackSpace

Armazenamento 0,25 0,15 0,15 0,15

Entrada 0,18 0,10 0,10 0,08

Saída 0,18 0,15 0,10 0,22

Tabela 2.1: Custo, em USD, do armazenamento, entrada e saída de 1 Gb de dados em serviços de armazenamento pay-per-use estudados.

A tabela 2.2 complementa a informação apresentada na tabela 2.1 com o custo de pedidos efectuados aos serviços mencionados.

2_{e.g., No SLA do Amazon S3 está contratualizado um desconto de 10%, se a disponibilidade verificada}

(35)

Tipo de Pedido Nirvanix Azure - EU Amazon S3 - EU RackSpace

GET * 0 0,01 0,01 0

PUT ** 0 0,01 0,10 0 ***

Tabela 2.2: Custo, em USD, de efectuar 10000 pedidos a serviços de armazenamento

pay-per-useestudados.

Legenda da tabela 2.2

* também inclui pedidos do tipo HEAD e DELETE. ** também inclui pedidos do tipo POST, LIST ou COPY.

*** cobra 0,20 se forem pedidos para ficheiros com menos de 250K bytes.

Para finalizar esta análise a tabela 2.3 apresenta as limitações conhecidas de alternati-vas gratuitas fornecidas por algumas clouds de custo fixo estudadas.

Serviço(conta gratuita) Limitações conhecidas

DivShare 5 Gb de armazenamento; 10 Gb downloads/mês; Um

down-loadapenas pode ser efectuado dez segundos após o pedido;

Docstoc 1000 pedidos por minuto; Número de uploads diário limitado

a 50000; 50 Mb é o tamanho máximo permitido de um fi-cheiro; Apenas são permitidos 200 downloads diariamente;

FilesAnywhere 1 Gb de armazenamento; 25 Mb é o tamanho máximo

per-mitido de um ficheiro; Apenas são perper-mitidos 25 downloads diariamente;

Box.net 1 Gb de armazenamento; 25Mb é o tamanho máximo

permi-tido de um ficheiro;

Tabela 2.3: Alguns limites conhecidos de serviços livres de encargos estudados. É de salientar que com estas alternativas gratuitas, a maior parte destes serviços não permite transferências de dados concorrentes. No entanto estes limites são removidos ou alterados quando se adquire um dos serviços pagos (e.g., contas Premium ou Professio-nal).

2.3 Considerações Finais

Neste capítulo foram discutidos os paradigmas da tolerância a faltas e tolerância a intrusões, convergindo estas para um modelo mais generalista de tolerância a faltas bi-zantinas, e a razão da necessidade de adoptar este tipo de abordagens na concepção de sistemas seguros e confiáveis.

Foram estudadas algumas técnicas para a concretização de sistemas tolerantes a fal-tas bizantinas, a replicação máquina de estados, os sistemas de quóruns bizantinos e os sistemas de quóruns activos. Também foram abordadas técnicas para garantir a confiden-cialidade em dados replicados, a partilha de segredos e os códigos de apagamento.

(36)

Finalmente houve também uma análise das características e a oferta existente de ser-viços para armazenamento de informação na cloud.

Este estudo sobre o estado da arte foi importante na medida em que serviu de base para o desenho do sistema proposto nesta tese, que irá ser apresentado no próximo capítulo.

(37)

Capítulo 3

D

EP

S

KY

3.1 Apresentação

Este capítulo apresenta o DEPSKY, um sistema para replicação de dados em várias

clouds que melhora a disponibilidade, integridade e confidencialidade da informação

ar-mazenada. O DEPSKYé a contribuição mais importante desta tese.

Os blocos atómicos de dados no DEPSKYdesignam-se por unidades de dados (data

units), que podem ser actualizadas pelos seus donos e acedidas por um conjunto arbitrário de leitores. A disponbilidade destas unidades é garantida mesmo em caso de falhas devido ao uso de algoritmos de replicação para sistemas de quóruns bizantinos de disseminação [28], onde os dados armazenados em cada servidor (i.e., que neste caso são clouds de armazenamento) são auto-verificáveis devido ao uso de assinaturas digitais e resumos criptográficos (i.e., se um servidor alterar o conteúdo dos dados, o leitor descobre e ignora os dados corrompidos).

O DEPSKYoferece também a possibilidade da informação mais sensível ser protegida

através de um esquema de partilha de segredos [32, 31], introduzindo garantias de con-fidencialidade. Desta maneira, nenhuma cloud individualmente tem acesso à informação contida nos dados.

A figura 3.1 ilustra como o DEPSKY distribui a informação (e.g., um ficheiro)

pe-las várias clouds. Estão representados dois clientes do sistema, um a usar o protocolo

ADS (Available DEPSKY) e outro a usar o protocolo CADS (Confidential & Available

DEPSKY). A diferença entre estes protocolos é a informação enviada para as clouds. No

caso de um cliente usar o protocolo ADS , é enviada uma cópia da informação para todas as clouds. Com o protocolo CADS a informação é dividida em partes, tantas quanto o nú-mero de clouds, e depois cada parte é enviada para sua cloud. A informação é dividida de maneira a que apenas seja necessário um determinado número de partes para reconstruir a informação original, e não a totalidade das partes.

Nas secções seguintes são apresentados o modelo de sistema, o modelo de dados, os

dois protocolos já mencionados, ADS e CADS, e trabalhos similares ao DEPSKY.

(38)

Capítulo 3. DEPSKY 20 RackSpace Amazon S3 Windows Azure Nirvanix SDN

Cliente [ADS] _{O valor é} Cliente [CADS]

replicado pelas clouds. O valor é dividido em partes que serão enviadas uma para cada cloud Valor JSS Valor Parte #1 Parte #2 Parte #3 Parte #4

Figura 3.1: Visão sobre a distribuição de informação pelas clouds.

3.2 Modelo de Sistema

O modelo de sistema utilizado no DEPSKYsegue uma série de hipóteses pragmáticas

tidas em conta no desenho dos protocolos de replicação em clouds de armazenamento. Cada cloud é representada por um servidor passivo (não executa nenhum código dos protocolos) que oferece operações de leitura e escrita de dados com semântica de consistência regular [26]: uma operação de leitura executada concorrentemente com uma operação de escrita retorna o valor da unidade de dados antes da escrita ou o valor que está a ser escrito.

Em primeiro lugar, assume-se que para cada unidade de dados há apenas um escritor, e este escritor só sofre falhas por paragem. Isto significa que cada bloco de dados é

escrito por uma única entidade1 , o que simplifica os protocolos já que não têm de lidar

com escritas concorrentes. Além disso, escritores maliciosos não são considerados pois estes poderiam escrever dados sem sentido do ponto de vista da aplicação de qualquer forma. Finalmente, estas duas hipóteses permitem a concretização de protocolos de leitura e escrita em sistemas onde os servidores são apenas discos passivos, como as clouds de

1_{Na prática pode existir mais de um escritor para uma unidade de dados desde que os acessos para}

(39)

Capítulo 3. DEPSKY 21

armazenamento.

Os servidores (clouds) e leitores estão sujeitos a faltas arbitrárias ou bizantinas [27]. Esta decisão vai de encontro à hipótese pessimista de que não conhecemos o que há dentro de uma cloud e portanto é seguro assumir que os dados lá armazenados podem ser corrompidos arbitrariamente. Da mesma forma, como são suportados múltiplos leitores para cada unidade de dados, é conveniente também assumir que estes podem ter qualquer comportamento. Devido ao uso de sistemas de quóruns bizantinos de disseminação [28], o sistema requer n ≥ 3f + 1 servidores para tolerar até f servidores um número ilimitado de clientes faltosos.

É assumida também a ausência de um sistema de distribuição de chaves entre os clien-tes. Os leitores apenas sabem como aceder ao sistema para ler dados e também possuem a chave pública do escritor para verificação e validação de dados.

3.3 Modelo de Dados

A figura 3.2 apresenta o modelo de dados do DEPSKYem três níveis:

Conceptual Data Unit Num nível conceptual temos os blocos representados por

unida-des de dados(data units) que contêm, além do seu valor (data), um número de versão

(version number) e informações de verificação que tornam os dados auto-verificáveis (ve-rification data). Além disso são identificadas por um nome único (e.g.,X).

Generic Data Unit Genericamente, uma unidade de dados do DEPSKYé representada

em cada cloud por dois ficheiros: um contendo os metadados e o outro com o valor mais recente armazenando na unidade. Estes dois ficheiros estão sempre dentro de um contai-ner. O container de uma unidade de dados, para além de conter os metadados e o valor actual, pode conter também versões anteriores do valor desta unidade. O identificador é usado para obter referências para container e metadados dessas unidades nos proto-colos definidos, ou seja, o nome dos containers e dos ficheiros advém do identificador da unidade de dados (e.g., numa unidade de dados com o identificador X, o container denomina-se Xcontainer e o ficheiro de metadados denomina-se Xmetadata). Os fichei-ros de metadados são os mais importantes pois é sempre necessário um quórum destes nos protocolos definidos. Os metadados consistem na seguinte informação: um número de versão (Version Number), o nome do ficheiro com o valor desta versão (Data Pointer) e informação de verificação (Verification Data), que inclui um resumo criptográfico do valor para verificação de integridade deste e, no caso de ser uma unidade de dados com confidencialidade, dados públicos necessários para a leitura do valor. Para escrever ou ler uma unidade de dados é sempre necessário obter o ficheiro de metadados deste em primeiro lugar.

(40)

Data Unit Implementation Ao nível de implementação, cada cloud possui uma

repre-sentação da unidade de dados de acordo com a definição da sua estrutura interna (e.g., um

containeré mapeado para um bucket na Amazon S3 ou para um blobcontainer na Azure).

X _{Amazon S3}

Bucket X

Container X

Metadata

Generic Data Unit Data Unit Implementation

Data

Version Number Verification Data

Data

Data Pointer

Conceptual Data Unit

Verification Data Version Number Data Nirvanix SDN Folder X Metadata Data Windows Azure BlobContainer X Metadata Data DivShare Folder X Metadata Data

Figura 3.2: Decomposição do Data Unit X do DEPSKY, do conceito à concretização.

3.4 ADS - Available D

EP

S

KY

Esta secção apresenta o algoritmo ADS que promove uma melhoria da disponibili-dade de dados na cloud através da replicação das unidisponibili-dades de dados por várias clouds de armazenamento.

3.4.1 Algoritmo de Escrita

1. Um cliente escritor começa por enviar um pedido de leitura dos metadados a todas as clouds. O escritor espera n − f ficheiros de metadados correctamente assinados por ele e lidos de diferentes clouds para então obter o número de versão máximo dentre os contidos nestes ficheiros. O algoritmo 1 ilustra como são lidos os meta-dados.

2. O número de versão lido no passo anterior é incrementado em uma unidade, dando origem ao número de versão dos dados a serem escritos nesta operação (linhas 4-8 do algoritmo 3). Um ficheiro, a conter os dados a serem escritos e cujo nome corres-ponde ao nome da unidade de dados concatenado com o número de versão, é criado em todas as clouds (linhas 9-10 do algoritmo 3). O escritor espera confirmação da escrita deste ficheiro de n − f clouds.

(41)

3. Após conclusão da escrita da nova versão, são actualizados os metadados para a nova versão sendo enviados pedidos de escrita para este efeito. Antes de serem enviados, os metadados são assinados pelo escritor (linhas 11-17 do algoritmo 3). Neste passo o ficheiro de metadados é actualizado (ficheiro com metadados anterior é sobrescrito), ao contrário do passo 2 em que é escrita uma nova versão dos dados num ficheiro diferente do da versão anterior. A operação de escrita termina quando se recebe confirmação da actualização de metadados de n − f clouds (linha 18 do algoritmo 3).

Note que o algoritmo de escrita preserva as versões anteriores da unidade de dados. Estas versões podem ser apagadas quando o escritor achar conveniente através de um procedimento de garbage collection que envia pedidos de remoção a todas as clouds.

3.4.2 Algoritmo de Leitura

1. Um cliente leitor começa por efectuar pedidos de metadados a todas as clouds e esperar por n − f ficheiros de metadados correctamente assinados pelo escritor, como está descrito no algoritmo 1. O leitor obtém o número de versão máximo reportado nestes ficheiros.

2. Após obter o número de versão mais actual da unidade de dados, o cliente envia pedidos de leitura para esta versão a todas as clouds e aguarda. A operação termina quando é recebido um valor cujo resumo criptográfico é igual ao resumo cripto-gráfico contido nos metadados. Só depois desta verificação de integridade é que o valor é retornado (linhas 8-11 do algoritmo 4).

Optimização de leitura. Uma optimização importante para diminuir os custos

mone-tários do protocolo de leitura (ver secção 5.1) é enviar o pedido de leitura da versão mais actual do valor da unidade de dados apenas à cloud que responder mais rapidamente à requisição de metadados e reportar a versão mais actual dos dados. Desta forma, em casos sem falhas, apenas uma das clouds será lida. Caso esta cloud não responda atempa-damente (timeout) ou retorne uma versão anterior, outras clouds são acedidas até que se obtenha a versão mais recente.

3.5 CADS - Confidential & Available D

EP

S

KY

O ADS garante a integridade e disponibilidade dos dados em clouds de armazena-mento. No entanto, um dos problemas fundamentais neste tipo de solução é evitar que entidades não autorizadas tenham acesso aos dados armazenados na cloud.

(42)

Esta secção apresenta o protocolo CADS, que integra um algoritmo criptográfico de

partilha de segredo de tal forma que os dados armazenados em cada cloud

individual-mente sejam de pouca utilidade.

Um esquema de partilha de segredos [32, 31], conforme já explicado na secção 2.1.3, é o método para dividir um segredo entre um grupo de n participantes, em que a cada um deles é atribuída um parte do segredo (que tem o mesmo tamanho do segredo original). O segredo pode ser reconstruído apenas quando f + 1 dessas partes são recombinadas e qualquer combinação de até f partes individuais não revelam nenhuma informação sobre o segredo.

A única diferença entre os protocolos de escrita do ADS e do CADS é que neste último introduziu-se um algoritmo de partilha de segredos no passo 2 do ADS de tal forma a produzir tantas partes do segredo (valor a ser escrito na unidade de dados) quanto o número de clouds. Cada uma destas partes é depois enviada para sua respectiva cloud (linhas 8-10 do algoritmo 5).

O algoritmo de leitura do CADS funciona de forma bastante similar ao ADS, porém, ao invés de aguardar apenas uma resposta com a versão mais actual dos dados (ADS -passo 2), esperam-se f + 1 partes de diferentes clouds para combiná-las usando o al-goritmo de partilha de segredos, obtendo o valor originalmente escrito (linhas 9-13 do algoritmo 6).

Para garantir a confidencialidade ponto-a-ponto na Internet, o CADS depende da uti-lização de HTTP sobre SSL (HTTPS) para que a informação que circula na rede seja imperceptível para terceiros. Com a utilização de HTTP sem SSL um atacante que con-seguisse interceptar f + 1 partes poderia reconstruir o segredo.

Algoritmo 1: query_metadata(dataUnit)

Entrada: unidade de dados do DEPSKY

Saída: vector com n − f metadados assinados lidos de diferentes clouds início

1

m[0 .. n − 1] ←− ⊥

2

para 0 ≤ i ≤ n − 1 faça em paralelo

3

tmi ←− cloudi.get(dataU nit, ”metadata”)

4

se verif y(tmi, Pukw) então

5 m[i] ←− tmi 6 fim 7 fim 8

enquanto |{i | m[i] 6=⊥}| < n − f faça

9

sleep(50ms); /* aguarda 50ms antes de continuar */

10 fim 11 retorna m 12 fim 13

(43)

Algoritmo 2: write_value(dataUnit, n[0 .. n − 1], v[0 .. n − 1])

Entrada: unidade de dados do DEPSKY, identificadores (nomes) e valores a

escrever Saída: nada início 1 ok[0 .. n − 1] ←− false 2

3

oki ←− cloudi.put(dataU nit, n[i], v[i])

4

fim

5

enquanto |{i | m[i] = true}| < n − f faça

6

7 fim 8 fim 9 Algoritmo 3: ADS_write(dataUnit,v)

Entrada: unidade de dados do DEPSKYe valor a escrever

Saída: nada início 1 n[0 .. n − 1] ←− ⊥ 2 v[0 .. n − 1] ←− ⊥ 3 se max_ver = −1 então 4 m ←− query_metadata(dataU nit) 5

max_ver ←− max ({m[i].version|0 ≤ i ≤ n − 1})

6

fim

7

new_ver ←− max_ver + 1

8

∀i ∈ {0 , ..., n − 1} : n[i] ←− ”value” + new_ver, v[i] ←− v

9

write_value(dataU nit, n, v)

10

∀i ∈ {0 .. n − 1} : n[i] ←− ”metadata”

11

para 0 ≤ i ≤ n − 1 faça

12

new_meta ←− hnew_ver, H(v), n[i]i

13 sign(new_meta, Prkw) 14 v[i] ←− new_meta 15 fim 16 write_value(dataU nit, n, v) 17 max_ver ←− new_ver 18 fim 19

(44)

Algoritmo 4: ADS_read(dataUnit)

Saída: valor da unidade de dados do DEPSKY

início

1

m ←− query_metadata(dataU nit)

2

max_id ←− i | m[i].version = max ({m[i].version|0 ≤ i ≤ n − 1})

3

v[0 .. n − 1] ←−⊥

4

para 0 ≤ i < n − 1 faça em paralelo

5

v[i] ←− cloudi.get(dataU nit, ”value” + m[max_id].version)

6

fim

7

enquanto ¬∃i : v[i] 6=⊥ ∧H(v[i]) = m[max_id].verif ication faça

8

9 fim 10 retorna v[i] 11 fim 12 Algoritmo 5: CADS_write(dataUnit,v)

Entrada: unidade de dados do DEPSKYe valor a escrever

Saída: nada início 1 n[0 .. n − 1] ←−⊥ 2 se max_ver = −1 então 3 m ←− query_metadata(dataU nit) 4

max_ver ←− max ({m[i].version|0 ≤ i ≤ n − 1})

5 fim 6 new_ver ←− max_ver + 1 7 v[0 .. n − 1] ←− get_shares(v) 8

∀i ∈ {0 .. n − 1} : n[i] ←− ”value” + new_ver

9

write_value(dataU nit, n, v)

10

para 0 ≤ i < n − 1 faça

11

new_meta ←− hnew_ver, H(v[i]), n[i]i

12 sign(new_meta, Prkw) 13 v[i] ←− new_meta 14 fim 15

∀i ∈ {0 .. n − 1} : n[i] ←− ”metadata”

16 write_value(dataU nit, n, v) 17 max_ver ←− new_ver 18 fim 19

(45)

Algoritmo 6: CADS_read(dataUnit)

Saída: valor da unidade de dados do DEPSKY

início

1

m ←− query_metadata(dataU nit)

2

max_id ←− i | m[i].version = max ({m[i].version|0 ≤ i ≤ n − 1})

3

v[0 .. n − 1] ←−⊥

4

5

v[i] ←− cloudi.get(dataU nit, ”value” + m[max_id].version)

6

fim

7

valueHash ←− m[max_idx].verif ication

8

enquanto |{i | v[i] 6=⊥}| < n − f

9

faça

10

11 fim 12 retorna combine_shares(v) 13 fim 14

3.6 Trabalhos Similares

De acordo com a pesquisa efectuada e até onde se sabe, existem apenas dois trabalhos

bastante recentes que tentam fazer algo similar ao DEPSKY para melhorar a

confiabili-dade e segurança dos dados armazenados em clouds de armazenamento, e ambos foram desenvolvidos em paralelo com o trabalho aqui apresentado.

O HAIL (High-Availability Integrity Layer) [13] consiste num conjunto de protocolos criptográficos que juntam códigos de apagamento com provas de recuperação que permi-tem a concretização de uma camada de software para proteger a integridade dos dados armazenados em clouds, mesmo que estas sejam invadidas e corrompidas por um adver-sário móvel.

Quando comparado ao DEPSKY, o HAIL apresenta pelo menos três limitações: só

lida com dados estáticos (i.e., os algoritmos não suportam actualizações e multiplas

ver-sões dos dados), requer que os servidores executem código (ao contrário do DEPSKY, que

considera as clouds de armazenamento como discos passivos) e não usa nenhum meca-nismo para protecção da confidencialidade dos dados armazenados.

O sistema RACS (Redundant Array of Cloud Storage) [22] utiliza técnicas similares às empregues nos sistemas RAID nível 5 [29] para concretizar replicação de dados em diversas clouds.

Diferentemente do DEPSKY, o RACS não se preocupa com problemas de segurança,

(46)

forma que torna inviável o acesso aos dados.

Além de não proteger contra corrupção de dados e violações de confidencialidade, o RACS também não suporta actualizações dos dados armazenados. Todas estas limitações

tornam o RACS muito menos poderoso que o DEPSKY.

Além das diferenças entre os sistemas, os trabalhos sobre o HAIL e RACS não apre-sentam nenhum tipo de medida que utilize a diversidade de clouds.

O protocolo CADS e a sua concretização são baseados nas ferramentas desenvolvidas para a concretização da camada de confidencialidade do DepSpace [11].

Este sistema utiliza um esquema de partilha de segredos publicamente verificável para adicionar uma camada genérica de confidencialidade sobre sistemas replicados que se-guem a abordagem de replicação por máquina de estados.

Apesar de utilizar a mesma biblioteca de partilha de segredos escrita em Java (JSS [7]), os mecanismos e protocolos desenhados para o DepSpace não podem ser directamente aplicados ao armazenamento em clouds uma vez que requerem execução de código nos servidores na verificação dos dados, e assumem que as actualizações de unidades de dados são sempre processadas na mesma ordem global no sistema.

3.7 Considerações Finais

Neste capítulo foi apresentado o DEPSKY, um novo sistema de armazenamento

to-lerante a intrusões, que promove uma melhoria da disponibilidade, integridade e confi-dencialidade dos dados armazenados em clouds. Tal como a maioria dos sistemas de

armazenamento, o DEPSKYsuporta duas operações básicas, leitura e escrita, mas oferece

a possibilidade dos dados serem armazenados de acordo com um esquema de partilha de segredos, garantindo a confidencialidade destes. No próximo capítulo são apresentados os detalhes da concretização do sistema.

(47)

Capítulo 4

Concretização do D

EP

S

KY

4.1 Considerações Gerais

O DepSky e todos os seus componentes foram concretizados na linguagem de pro-gramação Java. Em primeiro lugar foram concretizados alguns controladores, que são responsáveis pela comunicação com os diferentes sistemas de armazenamento em clouds. Cada controlador comunica com a respectiva cloud através dos seus serviços web disponibilizados, utilizando uma interface ReSTful ou através de envelopes SOAP. Toda a comunicação é efectuada sobre HTTPS (HyperText Tranfer Protocol secure).

Os controladores foram os componentes que mais tempo consumiram em termos de desenvolvimento dada a variedade no funcionamento dos diferentes serviços web de cada cloud. Foram concretizados controladores para os seguintes serviços: Amazon Simple Storage Service, Microsoft Windows Azure Platform, Nirvanix Storage Delivery Network, DivShare, DocStoc e Box.net.

Os controladores do Amazon S3 e do Windows Azure foram concretizados sobre bi-bliotecas Java, que contêm uma implementação completa dos serviços web, disponibiliza-das pelos fornecedores. Estas bibliotecas foram usadisponibiliza-das mas tiveram que ser ligeiramente modificadas para suportarem proxies sem autenticação, porque a rede do DI-FCUL está dependente de uma proxy deste tipo para acesso ao exterior (Internet).

Os restantes controladores foram concretizados recorrendo a classes da API do Java como a URLConnection para as ligações, os parsers de XML para processar respostas dos serviços web e uma variedade de módulos Java vocacionados para segurança, como o JSSE (Java Secure Socket Extension) e o JCA (Java Cryptography Architecture), que inclui o JCE (Java Cryptographic Extension).

Após a conclusão de um número suficiente de controladores, iniciou-se o desenvolvi-mento do componente responsável pelos protocolos (DepSky), e de outro responsável pela verificação, validação e criação de metadados do sistema (DepSkyManager). Foi também concretizado um wrapper para controladores que efectua a gestão dos retries e timeouts dos pedidos HTTP, para garantir fiabilidade ponto-a-ponto (DepSkyCloudManager).