Structure

O problema da indexação é bastante complexo mesmo sem colocar questões de segurança e privacidade. Os mecanismos de pesquisa e indexação de dados espalhados em siste- mas distribuídos têm sido alvo de estudos complexos nas últimas duas decadas, obtendo resultados interessantes como os algoritmos peer-to-peer.

No entanto podemos analisar o seguinte exemplo: quando queremos pesquisar por uma ficha médica de um doente, que está completamente opaca ao armazenamento, em

3. UMA SOLUÇÃO SEGURA PARA ARMAZENAMENTO EMCloud 3.4. Modelo Conceptual

diversas máquinas, temos de saber qual é o ficheiro opaco que necessitamos, sem revelar ao armazenamento o que procuramos, e o que o opaco representa.

Se avaliarmos soluções de indexação para sistemas de ficheiros, grande parte des- tes baseiam-se em estruturas de índice. Se o índice for do domínio de uma base fiável de computação, e todo o armazenamento cumprir os requisitos de segurança, podemos afirmar que o índice cumpre esses requisitos.

Podemos analisar o caso base do índice ser local:

Figura 3.9: Visão middleware com módulo de índice local

Na figura3.9, o índice executa localmente no middleware, sendo este uma TCB na ar- quitectura. Sempre que é necessário para o utilizador obter um ficheiro do middleware, é pesquisado no índice os fragmentos desse ficheiro (se estiver fragmentado), cada um com o seu nome que cumpre os requisitos de segurança previamente estabelecidos. Pos- teriormente a referência desses fragmentos é passada ao módulo de armazenamento que os vai obter independentemente dos seus mecanismos, e recupera fragmentos perdidos

3. UMA SOLUÇÃO SEGURA PARA ARMAZENAMENTO EMCloud 3.4. Modelo Conceptual

de acordo com a validação do módulo de segurança, e a disponibilidade do armazena- mento dos seus conectores. Por último os fragmentos passam pelo módulo de segurança de forma a recuperar o ficheiro original e devolvê-lo ao cliente.

Neste caso, o índice é totalmente seguro de acordo com os requisitos de segurança básicos, no entanto exige armazenamento local, e pode não escalar, dependendo do seu factor de peso em relação aos dados armazenados, e do disco local da máquina. Tam- bém pode haver necessidade de garantir backups deste índice para contemplar possíveis falhas. Por último, este modelo não contempla a existência de várias instâncias de mid- dleware, que tem de partilhar a informação do índice entre si, e garantir a consistência do mesmo.

Duas alternativas de índice distribuídas foram analisadas no capítulo2.5.3com vista a permitir não só indexar os dados, como permitir pesquisa sobre os mesmos. No entanto cada uma apresenta problemas que se revelam difíceis. O índice do iDataGuard anali- sado no capítulo2.5.3.1, é muito complexo e depende de várias rondas de comunicação sobre ficheiros armazenados nas Clouds. Tem problemas de escalabilidade, podendo au- mentar largamente o número de ficheiros armazenados na Cloud. E está vulnerável a ataques de análise aos padrões de acesso a ficheiros, que apenas se conseguem resolver utilizando acessos redundantes que acrescentam demasiado overhead ao sistema. Me- canismos de searchable-encryption analisados no capítulo 2.5.3.2 podem ser utilizados com um módulo de segurança adequado, no entanto são bastante complexos, e são alvo de investigação na actualidade, o que não permite inferir a sua utilidade no contexto da arquitectura proposta. E no modelo sobre os quais foram estudados, necessitam da utili- zação de tokens que relacionam ficheiros do lado da Cloud como visto no capítulo2.5.3.2. Assim podemos concluir que utilizar o índice de forma distribuída, para poder pes- quisar dados cifrados, sem o índice estar numa base confiável de computação, é um pro- blema bastante complexo, o qual foge ao âmbito desta dissertação. No entanto existem outras formas de abordar a questão.

Se o índice executar de forma totalmente local e apenas tivermos um middleware a exe- cutar de cada vez, de que necessitamos para salvaguardar e partilhar o índice de forma segura? Tendo um módulo de armazenamento funcional, e um módulo de segurança funcional, podemos simplesmente efectuar backups periódicos do índice para a Cloud. Tendo apenas de armazenar localmente no middleware quais os ficheiros que permitem obter informação para reconstruir o índice, e efectuar actualizações ao índice sempre que este sofre alterações. Assim temos uma solução simples de backup na Cloud.

Se existir várias instâncias do middleware, aumenta a complexidade da questão. O Far- site[ABC+_{02] mostra como podemos utilizar replicação bizantina, para ter várias partes}

do índice replicadas em ambientes inseguros. No entanto, o Farsite tem como pressu- postos os computadores de uma universidade, o que implica pouca latência e alta dispo- nibilidade das máquinas, e também assume que existem muitas máquinas para replicar a informação. Tais pressupostos não se podem aplicar ao contexto da Internet com um middlewareque cumpra os requisitos enunciados no capítulo3.3.

3. UMA SOLUÇÃO SEGURA PARA ARMAZENAMENTO EMCloud 3.4. Modelo Conceptual

Se as dimensões do índice forem em proporção muito mais pequenas que os dados armazenados (por exemplo na ordem dos 20% do tamanho dos dados armazenados), podemos assumir a existência do índice em máquinas confiáveis e de domínio próprio é um tradeoff aceitável para cumprir os requisitos. No entanto é necessária uma solução para se o índice tiver que funcionar em mais que uma máquina.

Antes de analisar uma alternativa para este problema, é necessário identificar clara- mente a informação a indexar. Um ficheiro armazenado no middleware é composto pelo seguinte:

• Identificador único. Por exemplo um URI6, ou um caminho absoluto para um fi- cheiro num filesystem.

• Informação sobre os dados criptográficos utilizados. Nomeadamente o salt,o IV, e o tamanho do objecto cifrado.

• Informação sobre o tamanho do ficheiro.

• Informação sobre os fragmentos, nomeadamente tendo para cada fragmento: Identificador único do fragmento

Informação de armazenamento do fragmento (por exemplo disco e stripe no caso do RAID)

• Metadados genéricos. Se pretendemos efectuar pesquisas mais complexas sobre os ficheiros para utilizar com diversas aplicações, podemos associar atributos nome:valor aos ficheiros. Para efeito de limitação do tamanho do índice, podemos assumir um valor máximo de metadata aos ficheiros, suficientemente pequeno para não criar demasiado overhead ao índice.

Atribuindo limites a todos os atributos indicados, podemos calcular o tamanho de uma entrada de índice desta natureza, por exemplo:

• Identificador único. 200 Caracteres a 2 bytes cada.

• Informação criptográfica. Salt 8 bytes, IV 8 bytes, tamanho do ficheiro inteiro de 4 bytes.

• Tamanho do ficheiro, um inteiro de 4 bytes. • Fragmentos:

Identificador do fragmento, 50 caracteres a 2 bytes cada. Informação de armazenamento, 20 caracteres a 2 bytes cada.

• Metadata genérica, tanto o nome como o valor 50 caracteres a 2 bytes cada.

3. UMA SOLUÇÃO SEGURA PARA ARMAZENAMENTO EMCloud 3.4. Modelo Conceptual

Assumindo que temos um ficheiro de 500KB com 4 entradas de metadata, e cifrado em blocos de 100KB, teriamos uma entrada com: 400 + 8 + 8 + 4 + 4 + 5(100 + 40) + 4(100 + 100) = 1924bytes, o que podemos arredondar para 2KB. Para comparação se o mesmo ficheiro estiver em blocos de 10KB, teriamos 8224 bytes, ou aproximadamente 8KB. Dependendo do tamanho médio do ficheiro a armazenar no middleware, e do ta- manho dos blocos, o índice crescerá mais ou menos num factor constante do armazena- mento total. Utilizando o primeiro exemplo, a existência 1 milhão de ficheiros de 500KB armazenados, representaria um tamanho total de 476 GB aproximadamente, e para as entradas "básicas"de índice destes dados, teríamos 1,9 GB. Contabilizando mil milhões de ficheiros de 500KB a blocos de 100KB com 4 metadados cada, teríamos 476 Terabytes aproximadamente de dados, e entradas de índice de 1,9 Terabytes. Estes valores de ín- dice são geríveis com alguma facilidade numa máquina ou servidor local, tendo os dados armazenados externamente.

Se apenas existir informação local sobre os ficheiros, seria fácil indexar os mesmos recorrendo a uma Btree ou Hashtable. Sendo sempre necessário utilizar estruturas que permitam a pesquisa por metadados. Mesmo assumindo que se utilizaria uma Hashtable para a pesquisa de metadados, o mapeamento inverso no pior caso (todos os ficheiros tem metadados diferentes), seria um simples tuplo com um dos campos da metadata e o nome do ficheiro. Para cada ficheiros com 4 metadados cada, isto seria (100 + 400) ∗ 8∗ = 4000bytes. Se tivessemos 1 milhão de ficheiros como no primeiro exemplo, teriamos para pesquisa de metadados no pior caso, um índice com 3,72 GB. O que faria um total acumulado de índice de 5,62 GB para 476 GB de dados. Dependendo do caso, é possível argumentar que é um valor aceitável de proporção entre os dados e o índice. E mesmo para o caso de mil milhões de ficheiros, o armazenamento necessário para um índice é um valor baixo o suficiente para armazenar num computador Desktop actual comum.

Assumindo que este compromisso é interessante, é necessário analisar o problema quando existe mais que um middleware, e necessitamos de sincronismo entre diferentes índices. Torna-se necessário garantir requisitos como escalabilidade, descentralização, elasticidade, durabilidade e tolerância a falhas do índice, para o caso de este estar dis- tribuído em diferentes bases confiáveis de computação, existem actualmente modelos de base de dados não relacionais que oferecem essas características out-of-the-box. No capítulo2.2.3estudou-se a base de dados Cassandra, que oferece as garantias todas enu- meradas anteriormente. Assume-se sempre que as instâncias de Cassandra executam sobre bases confiáveis de computação, pois este sistema não é desenhado para lidar com os problemas que poderiam existir se tal não fosse. Tendo em conta que os ficheiros de um índice só são acedidos quando este é procurado pelo identificador único, ou quando é efectuado uma pesquisa sobre os metadados, basta um esquema BigTable, em conjunto com um índice sobre os metadados, para obtermos um índice funcional sobre Cassandra. A alternativa seria o desenvolvimento de um modelo de índice bizantino como es- tudado no capítulo2.3.1, sobre o qual os Middlewares funcionassem com os seus índices