Soluções para DBaaS com dados encriptados: mapeando arquiteturas

(1)

“SOLUÇÕES PARA DBAAS COM DADOS

ENCRIPTADOS: MAPEANDO ARQUITETURAS”

Por

Marcelo Ferreira de Lima

Dissertação de Mestrado Profissional

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

(2)

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Marcelo Ferreira de Lima

“SOLUÇÕES PARA DBAAS COM DADOS

ENCRIPTADOS: MAPEANDO ARQUITETURAS"

ORIENTADOR(A): Prof. Ruy José Guerra Barretto de Queiroz

RECIFE, 2015

Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.

(3)

Catalogação na fonte

Bibliotecário Jefferson Luiz Alves Nazareno CRB4-1758

L732s Lima, Marcelo Ferreira de.

Soluções para DBaaS com dados encriptados: mapeando arquiteturas./ Marcelo Ferreira de Lima – Recife: O Autor, 2015.

114 f.: fig., tab.

Orientador: Ruy José Guerra Barretto de Queiroz.

Dissertação (Mestrado profissional) – Universidade Federal de Pernambuco. CIn, Ciência da computação, 2015.

Inclui referências e apêndices.

1. Computadores- Medidas de segurança. 2. Computação em nuvem. 3. Criptografia de dados (computação). 4. Banco de dados. I. Queiroz, Ruy José Guerra Barretto de. (Orientador). II. Titulo.

005.8 CDD (22. ed.) UFPE-MEI 2015-140

(4)

Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título, “Soluções para DBaaS com Dados Encriptados: Mapeando Arquiteturas”, orientada pelo Professor Ruy José Guerra Barretto de Queiroz e aprovada pela Banca Examinadora formada pelos professores:

_______________________________________________ Prof. Robson do Nascimento Fidalgo

Centro de Informática / UFPE

______________________________________________ Prof. Jairo Simião Dornelas

Centro de Ciências Sociais Aplicadas / UFPE

_______________________________________________

Prof. Ruy José Guerra Barretto de Queiroz Centro de Informática / UFPE

Visto e permitida a impressão. Recife, 11 de agosto de 2015.

___________________________________________________ Profª. EDNA NATIVIDADE DA SILVA BARROS

Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

(5)

AGRADECIMENTOS

Ao meu orientador Ruy José Guerra Barretto de Queiroz por ter me orientado na construção deste trabalho e ter oportunizado o aprofundamento em temas tão interessantes e desafiadores. Ao amigo e vizinho Gliner Dias Alencar, parceiro frequente de estudos e pesquisas, por ter me auxiliado com discussões tão construtivas sobre os estudos considerados nesta pesquisa. Ao amigo Robson Godoi de Albuquerque Maranhão pelo exemplo de dedicação e pelas profundas discussões sobre suas experiências com métodos científicos. Aos professores das disciplinas do mestrado e à Leila Oliveira, pela sua presteza e disponibilidade. À Cecília, minha filha linda, pelo simples fato de existir. Meu agradecimento especial à minha esposa, Rayanna, minha metade indivisível. À minha mãe e ao meu pai, por não medirem esforços por mim. Meu muito obrigado aos que de alguma forma me apoiaram.

(6)

RESUMO

Com a popularização crescente do modelo de computação em nuvem oferecendo serviços em cada uma das camadas de Software-as-a-Service (SaaS),

Platform-as-a-Service (PaaS) e Infrastructure-as-Platform-as-a-Service (IaaS), começaram a surgir

provedores que disponibilizam o serviço específico de Database-as-a-Service (DBaaS), cuja ideia básica é disponibilizar bancos de dados na nuvem. Entretanto, a inviabilidade de execução de operações, consultas e alterações, sobre dados encriptados em serviços DBaaS é um fator que afasta os clientes da possibilidade de levar seus dados para a nuvem. Proprietários de dados e provedores de nuvem anseiam por sistemas criptográficos completamente homomórficos como uma solução. Mas não existe qualquer perspectiva a curto ou médio prazo de que estes sistemas possam ser computacionalmente viáveis. Atualmente pesquisas buscam construir soluções que utilizam sistemas criptográficos viáveis que possibilitem a execução de operações sobre dados encriptados no provedor de DBaaS. Um estudo, precursor e destacado, baseia sua solução em uma arquitetura Proxy, modelo que não é unanimidade para este tipo de solução. Esta pesquisa, baseada em mapeamento sistemático, busca iniciar uma discussão mais profunda sobre modelos de arquitetura para DBaaS e apresenta como principais contribuições: (i) um catálogo de estudos com propostas de soluções, organizado por modelo de arquitetura, (ii) a determinação de uma tendência na escolha de arquiteturas, considerando o estado da arte, (iii) uma investigação de um direcionamento concreto, apontando vantagens e desvantagens, com base nos estudos catalogados, sobre a adoção da arquitetura Proxy em soluções encriptadas de computação em nuvem para DBaaS e (iv) apontar uma lista consistente de questões em aberto acerca das soluções para banco de dados encriptados, com base em dados extraídos dos estudos catalogados.

Palavras-Chave: Criptografia. Privacidade. Database-as-a-service. DBaaS.

(7)

ABSTRACT

With the growing popularity of cloud computing model, offering services in each of the layers of Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and

Infrastructure-as-a-Service (IaaS), began to emerge providers that provide the

specific service Database-as-a-Service (DBaaS), whose basic idea is to provide databases in the cloud. However, the impossibility of executing operations, queries and changes on encrypted data in DBaaS services is a factor that keeps customers the possibility to bring your data to the cloud. Owners of data and cloud providers crave fully homomorphic cryptosystems as a solution. But there is no prospect in the short or medium term that these systems can be computationally feasible. Currently research seek to build solutions using viable cryptographic systems that allow the execution of operations on encrypted data on DBaaS provider. One study, precursor and highlighted, bases its solution on a Proxy architecture model, that is no unanimity for this type of solution. This research, based on systematic mapping, search start a deeper discussion of architectural models for DBaaS and presents as main contributions: (i) a catalog of studies with proposed solutions, organized by architectural model, (ii) the determination of a tendency in choosing architectures, considering the state of the art and (iii) an investigation of a concrete direction, pointing advantages and disadvantages, based on cataloged studies, on the adoption of Proxy architecture over cloud computing encrypted solutions to DBaaS and (iv) point to a consistent list of open questions about the solutions for encrypted database, based on data extracted from cataloged studies.

Keywords: Encryption. Privacy. Database-as-a-service. DBaaS. Clouding

(8)

LISTA DE FIGURAS

Figura 2.1: Arquitetura de computação em nuvem ... 22

Figura 2.2: Entidades envolvidas no modelo DBaaS ... 24

Figura 2.3: Ameaças e componentes do CryptDB ... 28

Figura 4.1: Visão simplificada do mapeamento sistemático ... 38

Figura 4.4: String de busca escolhida ... 40

Figura 4.3: Fluxo de execução do protocolo do mapeamento sistemático ... 42

Figura 4.5: Arquitetura e modelo de tratamento de ameaças do CryptDB ... 44

Figura 4.6: Arquitetura de Wang, Agrawal e Abbadi (2011) ... 45

Figura 4.7: Arquitetura do MimoSecco ... 46

Figura 4.8: Arquitetura do SDB ... 47

Figura 4.9: Arquitetura proposta por Ferretti et al. (2013) ... 48

Figura 4.10: Arquitetura geral do Cipherbase ... 49

Figura 4.11: Arquitetura do Monomi ... 50

Figura 4.12: Arquitetura geral da solução de Shatilov et al. (2014) ... 51

Figura 4.13: Arquitetura do MuteDB ... 52

Figura 4.14: Arquitetura geral do SecureDBaaS ... 53

Figura 4.15: Arquitetura geral do TrustedDB ... 54

Figura 4.16: Arquitetura do L-EncDB ... 55

Figura 4.17: Arquitetura da solução de Lu e Tsudik (2011) ... 56

Figura 4.18: Arquitetura da solução de Asghar et al. (2013) ... 58

Figura 4.19: Arquitetura do Blind Seer ... 59

Figura 4.20: Arquitetura de Trombetta, Persiano e Braghin (2014) ... 60

Figura 4.21: Arquitetura do DBMask ... 61

(9)

LISTA DE GRÁFICOS

Gráfico 4.1: Estudos encontrados por fonte ... 40

Gráfico 4.3: percentual total de atendimento a cada pergunta ... 63

Gráfico 4.4: percentual total de arquiteturas aplicadas ... 65

Gráfico 4.5: quantidade de arquiteturas implementadas no tempo ... 65

Gráfico 4.6: percentual de utilização de Proxy e Cliente-servidor ... 66

Gráfico 4.7: estimativa e tendência para Proxy e Cliente-servidor... 67

Gráfico 4.9: Percentual de estudos que permitem interferência na encriptação ... 72

Gráfico 4.10: Percentual de estudos que permitem dados em texto claro ... 72

(10)

LISTA DE QUADROS

Quadro 3.1 - Algoritmos parcialmente homomórficos e operações ... 34 Quadro 4.1 - Categoria e ano dos estudos catalogados ... 64

(11)

LISTA DE TABELAS

Tabela 4.1: Resultados da etapa 1 da seleção ... 41

Tabela 4.2: Resultados da etapa 2 da seleção ... 41

Tabela 4.3: Utilização de Proxy e Cliente-servidor ... 66

(12)

SUMÁRIO

1. INTRODUÇÃO ...13

1.1 APRESENTAÇÃO ... 14

1.2 MOTIVAÇÃO E JUSTIFICATIVA ... 15

1.3 PROBLEMA E QUESTÃO DE PESQUISA ... 17

1.4 OBJETIVO GERAL ... 17

1.5 OBJETIVOS ESPECÍFICOS ... 18

1.6 ESTRUTURA DA DISSERTAÇÃO ... 18

2. COMPUTAÇÃO EM NUVEM E DATABASE-AS-A-SERVICE (DBAAS) ...20

2.1 COMPUTAÇÃO EM NUVEM ... 21

2.2 DATABASE-AS-A-SERVICE (DBAAS) ... 23

2.3 APRESENTAÇÃO DO CRYPTDB ... 26

2.4 TRABALHOS CORRELATOS ... 28

3. NOÇÕES DE CRIPTOGRAFIA ...30

3.1 CRIPTOGRAFIA SIMÉTRICA E ASSIMÉTRICA ... 31

3.2 HOMOMORFISMO ... 32

3.2.1 Encriptação Parcialmente Homomórfica (PHE) ... 33

3.2.2 Encriptação Completamente Homomórfica (FHE) ... 34

4. SOLUÇÕES BASEADAS EM CRIPTOGRAFIA PARA DBAAS ...36

4.1 APRESENTAÇÃO ... 37

4.2 MÉTODO DA PESQUISA ... 37

4.3 CICLO DA PESQUISA E O MAPEAMENTO SISTEMÁTICO ... 39

4.4 ESTUDOS CATALOGADOS NA EXECUÇÃO DA PESQUISA ... 43

4.4.1 CryptDB: Protecting Confidentiality with Encrypted Query Processing ... 43

4.4.2 A Comprehensive Framework for Secure Query Processing on Relational Data in the Cloud 44 4.4.3 Mimosecco: A Middleware for Secure Cloud Storage ... 45

4.4.4 Secure Query Processing with Data Interoperability in a Cloud Database Environment ... 46

4.4.5 Security and confidentiality solutions for public cloud database services ... 47

4.4.6 Orthogonal security with Cipherbase ... 48

(13)

4.4.8 Solution for Secure Private Data Storage in a Cloud ... 50

4.4.9 Scalable architecture for multi-user encrypted SQL operations on cloud database services 51 4.4.10 Distributed, Concurrent, and Independent Access to Encrypted Cloud Databases ... 52

4.4.11 TrustedDB: A Trusted Hardware-Based Database with Privacy and Data Confidentiality .... 54

4.4.12 L-EncDB: A lightweight framework for privacy-preserving data queries in cloud computing 55 4.4.13 Enhancing Data Privacy in the Cloud ... 56

4.4.14 Supporting Complex Queries and Access Policies for Multi-user Encrypted Databases ... 57

4.4.15 Blind Seer: A Scalable Private DBMS ... 58

4.4.16 Processing Private Queries Over an Obfuscated Database Using Hidden Vector Encryption 59 4.4.17 DBMask: Fine-Grained Access Control on Encrypted Relational Databases ... 60

4.4.18 SQL-Based Fuzzy Query Mechanism Over Encrypted Database ... 62

4.5 ANÁLISE SOBRE ESTUDOS CATALOGADOS ... 63

4.5.1 Avaliação de Qualidade dos Estudos ... 63

4.5.2 Análise Sobre os Modelos de Arquitetura ... 64

4.5.3 Dados Adicionais Sobre o Estado-da-arte ... 71

5. CONSIDERAÇÕES FINAIS ...74

5.1 SÍNTESE DA ANÁLISE... 75

5.2 RESOLUÇÃO DOS OBJETIVOS PROPOSTOS ... 75

5.3 CONCLUSÕES E TRABALHOS FUTUROS ... 77

REFERÊNCIAS ...81

APÊNDICE ...96

A. PROTOCOLO DO MAPEAMENTO SISTEMÁTICO ... 96

B. ESTUDOS EXCLUÍDOS NA SEGUNDA ETAPA DA SELEÇÃO ... 109

B.1 Lista de Estudos Excluídos na Segunda Etapa da Seleção ... 110

C. RELAÇÃO DE ESTUDOS CATALOGADOS ... 112

(14)

1

1. Introdução

Nesta seção constam a apresentação do trabalho, motivação e justificativa, problema de pesquisa, objetivos e uma descrição de como está estruturado o trabalho.

(15)

1.1 Apresentação

A computação em nuvem permite que usuários usufruam da computação alheios a boa parte da complexidade e com custos menores. Ao invés de adquirir infraestrutura, tudo pode ser utilizado como serviço, acessado por comunicação via Internet. O cliente espera algumas vantagens ao usar a nuvem como, por exemplo, reduzir custos com infraestrutura e operação, fornecer um serviço escalável e reduzir seus riscos de negócio (EUA, 2011; ZHANG; CHENG; BOUTABA, 2010). Os provedores de nuvem precisam garantir certas capacidades (EUA, 2011) para garantir as vantagens esperadas por seus clientes.

No contexto de computação em nuvem os mais diversos serviços podem ser oferecidos nas camadas de Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) e Infrastructure-as-a-Service (IaaS) (ZHANG; CHENG; BOUTABA, 2010). Esta pesquisa está situada em um serviço específico, o Database-as-a-Service (DBaaS). Disponibilizar um banco de dados na nuvem para atender aos mais variados clientes é viável. Provedores da nuvem já comercializam DBaaS, como o Microsoft Azure, Oracle Cloud e Amazon RDS. Entretanto, a inviabilidade de executar operações, consultar e alterar dados encriptados em serviços DBaaS afasta os clientes.

A encriptação homomórfica pode ser promissora (MICCIANCIO, 2010). Sistemas homomórficos permitem operações sobre dados encriptados. Porém, estes sistemas não são viáveis (GENTRY, 2009a) ou estão limitados a um único tipo de operação (PAILLIER, 1999). Portanto, alguns estudos usam sistemas criptográficos viáveis para operar sobre dados encriptados no servidor. O CryptDB de Popa et al. (2011), considerado um marco, segue esta linha e obteve destaque na comunidade científica e na imprensa (FORBES, 2011). Embora o CryptDB utilize arquitetura Proxy, esta arquitetura não se mostrou unanimidade em outras soluções ao longo do tempo.

(16)

Esta pesquisa mapeia estudos de forma sistemática em busca respostas sobre arquiteturas utilizadas em banco de dados encriptados para DBaaS. O mapeamento prevê a extração de dados a partir dos estudos. Análises sobre os dados permitiram encontrar tendências em relação a escolha das arquiteturas e lacunas na área pesquisada. As contribuições desta pesquisa são: apresentação de um catálogo de estudos com soluções de banco de dados encriptados para DBaaS, determinação de tendências na escolha de arquiteturas, investigação de impactos da arquitetura Proxy em soluções encriptadas para DBaaS e uma lista de problemas em aberto sobre banco de dados encriptados para DBaaS.

1.2 Motivação e Justificativa

Em algumas situações, manter informações em sigilo é uma necessidade. Antes do surgimento dos computadores e ao longo do tempo diversas formas de garantir privacidade e sigilo foram empregadas. Porém, com a proliferação de ambientes digitais a segurança precisava ser garantida neste cenário. Foram criados algoritmos que procuram manter os dados acessíveis somente por pessoas com privilégio legítimo.

Atualmente os algoritmos criptográficos mais utilizados baseiam sua segurança na chave criptográfica. Portanto, alguém mal-intencionado poderia ter conhecimento sobre o código fonte do algoritmo. Os paradigmas mais difundidos englobam os algoritmos simétricos e os assimétricos. Em ambos os casos, convencionalmente, exige-se a desencriptação do dado antes que uma operação seja realizada sobre ele.

Existem situações concretas nas quais é preciso utilizar dados encriptados sem desencriptá-los, preservando o sigilo e privacidade. Por exemplo, um órgão precisa acessar dados das unidades de saúde de um país para criação de políticas públicas. Se simplesmente utilizar criptografia simétrica ou assimétrica este órgão

(17)

teria que ter acesso aos dados desencriptados. Isto fragiliza o sigilo e a privacidade de pacientes com suas respectivas doenças. Um cenário como este também é possível no caso de organizações que precisam consultar informações em grandes bases de dados mineráveis e que contenham dados encriptados.

Generalizando o problema, percebe-se que manter dados na nuvem impede que operações sejam realizadas eficientemente sem comprometer a segurança. A encriptação homomórfica poderia contribuir para solucionar ou minimizar problemas de algumas áreas de pesquisa. Se beneficiariam, por exemplo, estudos sobre computação delegada, Secure Multi-Party Computation (SMPC), busca sobre dados encriptados e máquinas de aprendizado sobre dados encriptados.

Existem expectativas sobre o uso da Encriptação Completamente Homomórfica, do inglês Fully Homomorphic Encryption (FHE). Com FHE seria possível realizar arbitrariamente operações sobre dados encriptados. Ou seja, a garantia de sigilo permanece, porque os dados não são acessados, apenas o resultado da operação realizada sobre eles é obtido. Certos esquemas possuem estas propriedades, mas ainda não são viáveis (GENTRY, 2009a; GENTRY, 2009b; GENTRY, 2010).

Devido às limitações da FHE, estudos vêm investindo em técnicas viáveis para alcançar segurança em soluções Database-as-a-service (DBaaS). Estas pesquisas utilizam técnicas como, por exemplo, Encriptação Parcialmente Homomórfica, do inglês Partially Homomorphic Encryption (PHE), Criptografia Assimétrica e Criptografia Simétrica. As incertezas sobre a segurança do armazenamento de dados na nuvem afastam os clientes.

Baseadas em técnicas criptográficas viáveis, soluções com as mais variadas abordagens foram propostas nos últimos anos. Porém, em 2011 um modelo proposto ganhou notoriedade (POPA et al., 2011). Alguns fundamentos deste projeto, de pesquisadores do Massachusetts Institute of Technology – MIT,

(18)

chegaram a ser utilizados pela empresa Google em seu serviço na nuvem de dados massivos (GOOGLE, 2014).

Considerando o cenário exposto, hospedar dados sob o modelo DBaaS ainda precisa evoluir nos aspectos de segurança. Estudar os esforços para alcançar este objetivo é o principal fator motivador para este trabalho.

1.3 Problema e Questão de Pesquisa

Considerando a solução de referência proposta por Popa et al. (2011), os esquemas criptográficos desenvolvidos, os modelos de arquiteturas propostos nos estudos correlatos, as ferramentas implementadas sobre tais modelos e, de forma geral, todos os esforços que vêm sendo feitos para viabilizar o armazenamento e processamento de dados em ambientes DBaaS, persiste a seguinte pergunta:

“O modelo baseado em arquitetura Proxy é promissor quanto a tornar-se uma solução para sistemas gerenciadores de banco de dados na nuvem sob o modelo DBaaS, garantindo aplicabilidade, privacidade e sigilo sobre os dados?”.

1.4 Objetivo Geral

O objetivo geral desta pesquisa é analisar a arquitetura Proxy, modelo do CryptDB, comparando-a com outras propostas e apontando tendências. Espera-se avaliar a viabilidade da arquitetura sob o modelo Database-as-a-Service (DBaaS). Espera-se também mapear lacunas nas pesquisas sobre soluções DBaaS seguras.

(19)

1.5 Objetivos Específicos

São objetivos específicos para este trabalho:

• Executar um mapeamento sistemático que apresente um catálogo de estudos, organizado por tipo de arquitetura, sobre bancos de dados encriptados para DBaaS;

• Apontar tendências na escolha de arquiteturas e situar a arquitetura Proxy nestas tendências;

• Apontar impactos da adoção da arquitetura Proxy quando aplicada em

Database-as-a-Service (DBaaS).

• Levantar problemas em aberto, direcionando trabalhos futuros, sobre banco de dados encriptados para DBaaS.

1.6 Estrutura da Dissertação

Este documento foi estruturado para viabilizar o melhor entendimento dos temas abordados, da execução da pesquisa, das análises realizadas e dos resultados obtidos. Abaixo a organização utilizada:

• Seção 1 – Introdução: apresenta o trabalho, motivação e justificativa, problema de pesquisa, objetivos e esta descrição da estruturação do documento.

• Seção 2 – Computação em Nuvem e Database-as-a-service (DBaaS): introduz os principais conceitos sobre computação em nuvem e situa o modelo de Database-as-a-Service (DBaaS) neste contexto.

(20)

• Seção 3 – Noções de Criptografia: esclarece conceitos sobre tipos de sistemas criptográficos utilizados nas propostas de soluções para DBaaS.

• Seção 4 – Soluções Baseadas em Criptografia para DBaaS: apresenta a pesquisa, o método e o ciclo da pesquisa, descreve os estudos catalogados e reporta os resultados.

• Seção 5 – Considerações Finais: revê objetivos, fornece um resumo dos pontos mais relevantes e observa questões para trabalhos futuros.

• Referências: lista as referências citadas ao longo do trabalho. • Apêndice A: descreve o Protocolo do Mapeamento Sistemático. • Apêndice B: lista de estudos excluídos na segunda etapa da seleção. • Apêndice C: reporta a lista com todos os estudos catalogados.

(21)

2

2. Computação em Nuvem e

Database-as-a-service (DBaaS)

Esta seção introduz os principais conceitos sobre computação em nuvem e situa o modelo de Database-as-a-Service (DBaaS) neste contexto.

(22)

2.1 Computação em Nuvem

A computação em nuvem começou a ficar mais conhecida em 2006 quando Eric Schmidt, então CEO da Google, usou o termo “nuvem”. Ele descrevia um modelo de negócio para fornecimento de serviços na Internet. Mas ideias fundamentais para este paradigma já ocorriam a mais tempo. O livro de Parkhill (1966) já falava de aspectos da nuvem, mas usando o termo

Utility Computing. A computação em nuvem pode ser percebida como uma

realização da Utility Computing (ZHANG; CHENG; BOUTABA, 2010). A definição do National Institute of Standards and Technology (NIST) sobre computação em nuvem atende aos objetivos desta pesquisa:

“Computação em nuvem é um modelo para permitir o acesso ubíquo, conveniente, sob demanda à rede para um

pool compartilhado de recursos computacionais configuráveis

(ex., redes, servidores, armazenamento, aplicações e serviços) que podem ser provisionados rapidamente e liberados com um esforço mínimo de gerenciamento ou interação com o provedor” (EUA, 2011, p.2).

EUA (2011) também define cinco características essenciais para o modelo de computação em nuvem:

• Autosserviço sob demanda: o consumidor pode provisionar recursos, de forma unilateral, automática e sem interação humana com o provedor da nuvem;

• Acesso à rede: os serviços estão disponíveis por rede, por meio de mecanismos padrão, para diversos tipos de dispositivos;

• Pool de recursos: o provedor deve contar com um pool de recursos usados de forma dinâmica, a depender da demanda dos clientes;

(23)

• Elasticidade rápida: capacidades devem ser providas ou liberadas acompanhando a demanda dos clientes a qualquer tempo ou quantidade;

• Serviço mensurável: o uso dos recursos precisa ser monitorado, controlado e reportado de forma transparente para o consumidor e o próprio provedor.

Zhang, Cheng e Boutaba (2010) apontam como vantagens do uso de computação em nuvem: sem investimento inicial em infraestrutura, baixo custo de operação, alta escalabilidade, acesso fácil e redução de riscos de negócio e despesas com manutenção. A Figura 2.1 ilustra a arquitetura em camadas da computação em nuvem descrita por Rimal et al. (2009). O estudo de Zhang, Cheng e Boutaba (2010) usa uma divisão similar. Entretanto, inclui o hardware, juntamente com ferramentas de virtualização e armazenamento em bloco, na camada de Infrastructure-as-a-Service (IaaS). Reduzindo a visão para três camadas.

Figura 2.1: Arquitetura de computação em nuvem

Fonte: RIMAL et al., 2009

Quanto ao modelo de negócio, a ideia é que cada camada atue como provedora de serviço para uma outra camada e para o usuário final. Segundo Zhang, Cheng e Boutaba (2010) e EUA (2011), as nuvens podem ser classificadas quanto ao tipo de acordo com as seguintes características.

Nuvens públicas são mantidas por provedores que oferecem os serviços para o público em geral. Dados armazenados neste tipo de nuvem

(24)

podem sofrer com problemas de privacidade e sigilo. Nuvens privadas são de uso exclusivo da organização. Embora este tipo alcance maior segurança, tem custo alto por não compartilhar recursos. Um modelo de nuvem comunitária é considerado por Subashini e Kavitha (2011). Difere da nuvem privada por os recursos e custos divididos entre duas ou mais organizações.

As nuvens híbridas combinam nuvens privadas e nuvens públicas. Requerem um projeto muito cauteloso sobre a divisão do que será mantido na infraestrutura privada ou pública. Herda características dos tipos de nuvem privadas e públicas. As nuvens virtualmente privadas rodam em uma infraestrutura pública, mas permitem ao contratante usar Virtual Private Network (VPN) para projetar configurações. Neste tipo a comunicação subjacente também é virtualizada.

2.2 Database-as-a-Service (DBaaS)

Antes da popularização do termo computação em nuvem, o estudo de Hacigumus, Iyer e Mehrotra (2002) trouxe a ideia de

Database-as-a-Service (DBaaS). Foram inspirados pela ideia de software-as-a-service,

baseada em Applications Services Providers (ASP), mas propunham o banco de dados como objeto central da iniciativa de outsourcing. A proposta de solução dos autores explora o fato de que bancos de dados tendem a crescer, e administrá-los pode se tornar complexo e custoso.

O trabalho de Hacigumus, Iyer e Mehrotra (2002) já considerava privacidade dos dados como um desafio na implementação de DBaaS. A implementação proposta já considerava uma forma de encriptar os dados no DBMS. Entretanto, usava uma abordagem incipiente que não fornecia garantias robustas de privacidade e sigilo.

(25)

A ideia principal do DBaaS é que toda a administração do banco de dados seja feita pelo provedor de serviços. O contratante pode se ocupar com suas necessidades específicas de dados e com o core business.

Estudos (WONG et al., 2014; LU; TSUDIK, 2011; PAPPAS et al., 2014; TROMBETTA; PERSIANO; BRAGHIN, 2014; SARFRAZ et al., 2015; POPA et al., 2011; TU et al., 2013; FERRETTI et al., 2014b) que propõem soluções em DBaaS consideram as seguintes entidades envolvidas no funcionamento da solução:

• Proprietário dos dados (data owner): responsável pela integridade, privacidade e por especificar controles de acesso sobre os dados; • Usuário: pessoa que utiliza os dados do sistema;

• Servidor: ambiente que armazena os dados e, preferencialmente, realiza todo o processamento para disponibilizá-los;

• Cliente: porção do sistema que permite a interação com os dados hospedados no servidor.

A Figura 2.2 ilustra estas entidades e a relação entre elas. No cenário DBaaS a característica imutável é que os dados devem estar armazenados no provedor de serviços em nuvem.

Figura 2.2: Entidades envolvidas no modelo DBaaS

(26)

Em uma situação real a distribuição das entidades e as suas funções pode variar. Entretanto, os dados sempre ficam sob a guarda do provedor de DBaaS. Em se tratando de um serviço de nuvem pública, este ambiente não é assumido como confiável.

Manter dados sob a guarda do proprietário exige cuidados com segurança, mas passar esta guarda para um terceiro pode exigir muito mais cuidados. O terceiro, no caso o provedor de DBaaS, pode se enquadrar em um perfil de ameaça. Honesto e curioso (curious-but-honest) e malicioso são perfis frequentes (GOLDREICH, 2004; KATZ; LINDELL, 2015).

Honesto e curioso é restrito, pois o provedor atua de forma passiva, apenas observando. Isto é possível com seus privilégios. O tipo malicioso é irrestrito, agindo ativamente, subvertendo protocolos e interferindo no processamento. O tipo honesto e curioso é considerado factível (VIMERCATI et al., 2007), pois atuar ativamente pode deixar rastros detectáveis. Descobrir uma prática como esta poderia abalar a confiança dos clientes sobre o provedor.

Perfis de ameaça podem estar associados à outras entidades do modelo. O usuário pode ser considerado completamente confiável, mas em determinadas situações ele poderia participar de um conluio com insiders do provedor (FERRETTI et al., 2014b; ASGHAR et al., 2013). As soluções para DBaaS devem contar com um modelo de segurança. Este modelo contempla a descrição do perfil de ameaça para as entidades envolvidas.

As variadas propostas de solução para DBaaS apontam o uso da criptografia para tentar garantir um nível de segurança satisfatório. As primeiras propostas guardavam na nuvem o banco de dados encriptado. No momento da consulta o todo o banco poderia ser trazido para o cliente e desencriptado. Evidentemente esta não é uma boa escolha em termos de flexibilidade, desempenho e escalabilidade.

(27)

A solução de Hacigumus, Iyer e Mehrotra (2002) encripta e desencripta os dados no próprio servidor, por meio de User Defined

Functions (UDF). Mas o usuário precisa passar a chave para o servidor que

é, no mínimo, honesto e curioso. Portanto, a segurança é fortemente comprometida.

Processar consultas no servidor sem desencriptar dados pode ser observada pode combinar eficiência e mais segurança. Esta abordagem precisa que operações tradicionais sejam convertidas em operações que manipulem dados encriptados no servidor. Algumas soluções nesta linha funcionam com um DBMS de mercado não modificado (LI et al., 2015; FERRETTI et al., 2013; POPA et al., 2012), mas outras exigem modificações e uso de hardware específico (BAJAJ; SION, 2014; ARASU et al., 2013).

A criptografia se mostra essencial na garantia da segurança dos dados em servidor na nuvem. Mas as pesquisas se deparam com muitos desafios. Na busca por superá-los a proposta de Popa et al. (2011) resultou em destaque na comunidade científica, sendo referenciada em diversos outros estudos, servindo de base para novas propostas e sendo até citada na imprensa (FORBES, 2011; GENTRY et al., 2014; TOPLE et al., 2013; STEPHEN et al., 2014).

2.3 Apresentação do CryptDB

O CryptDB (POPA et al., 2011) destaca-se pelo pioneirismo em implementar soluções para vários problemas sobre banco de dados encriptados na nuvem. Os autores identificam a proposta como um caminho para o modelo de Database-as-Service (DBaaS).

O CryptDB é um proxy confiável e usa abordagens de ajuste de SQLs e esquemas criptográficos. Assim o DBMS não confiável executa consultas sobre dados encriptados de forma transparente. A solução cobre duas

(28)

ameaças: (I) atacantes com privilégios de acesso aos dados, como funcionários bisbilhoteiros do provedor e (II) ataques arbitrários que comprometam qualquer componente.

Para tratar a ameaça (I), são utilizadas camadas de encriptação, como em uma cebola. O CryptDB decide sobre qual camada requisitará os dados a depender da consulta executada. As camadas utilizam esquemas criptográficos com níveis de segurança diferentes.

As camadas RND e DET utilizam os sistemas criptográficos AES e

Blowfish de forma não determinística e determinística, respectivamente. A

camada OPE trata ordenação de dados, mas vaza para o DBMS a ordem de itens de consultas. Antes do CryptDB o esquema OPE proposto por Boldyreva et al. (2009) não tinha implementação e aferições conhecidas. A camada HOM utiliza o sistema PHE aditivo de Paillier (PAILLIER, 1999). A camada JOIN e OPE-JOIN trata equi-joins e range-joins sem vazamentos para o DBMS. A camada SEARCH permite o operador LIKE.

Para tratar a ameaça (II) cabe ao desenvolvedor da aplicação aplicar políticas de usuários usando anotações que são armazenadas no CryptDB. Por meio de principals o mecanismo permite definir quem pode acessar cada item de dado. Com base nas anotações o CryptDB realiza o gerenciamento de chaves. O CryptDB tem acesso às chaves criptográficas por meio da senha do usuário autenticado.

Com esta estratégia a solução limita o vazamento de informações aos usuários que estão autenticados no momento do comprometimento do ambiente. Os usuários que não estão ativos no sistema neste momento terão a privacidade e o sigilo dos dados garantidos. A Figura 2.3 ilustra a distribuição da solução dentro do modelo de segurança assumido, um exemplo de acesso aos dados por um tipo de cliente e a cobertura sobre os dois tipos de ameaças.

(29)

Figura 2.3: Ameaças e componentes do CryptDB

Fonte: elaborada pelo autor

2.4 Trabalhos Correlatos

Uma revisão bibliográfica levantou estudos correlatos que cobrem desafios e soluções envolvendo bancos de dados na nuvem. Todos guardam algumas similaridades com esta pesquisa, mas diferem em outros aspectos.

O estudo de Shankarwar e Pawar (2014) seguem a mesma linha, mas enfatizam soluções e oferecem uma cronologia sobre elas. Destacam pontos de pesquisa em aberto. Dinadayalan, Jegadeeswari e Gnanambigai (2014) destacam nove princípios de segurança nuvem, além de descrever algumas ações e ferramentas. Shahzad (2014) revisita as capacidades definidas por EUA (2011) e levanta a possibilidade de um economic

Distributed Denial of Service (eDDoS). Keshavarzi, Haghighat e Bohlouli

(2013) trazem a perspectiva de impacto sobre os negócios das empresas.

Esta pesquisa difere bastante dos trabalhos citados até aqui por não endereçar problemas genéricos de segurança na nuvem e suas possíveis soluções. Mas tem em comum o fato de se basear nos conceitos e no modelo de competências aceito por estes estudos para suas avaliações.

No estudo de Dara (2013) é possível verificar uma extensa lista de técnicas que podem ser aplicadas para garantir a privacidade dos dados na nuvem. O estudo de Aljafera et al. (2014) segue a mesma linha, enfatiza

(30)

detalhes dos esquemas criptográficos e fornece um experimento comparativo entre eles. Diferentemente destes dois últimos estudos, esta pesquisa não se propõe a estudar esquemas criptográficos. Mas deve passar por eles para elucidar o funcionamento das soluções avaliadas.

O estudo de Mehak et al. (2014) guarda mais proximidade com esta pesquisa. Considera as capacidades de computação em nuvem e características de arquiteturas DBaaS para uma avaliação de segurança. Levanta problemas serem enfrentados por DBaaS e mecanismos para enfrentá-los. Entretanto, tem conclusões pautadas em bases conceituais e não apresenta um levantamento sistemático sobre estudos.

Outro estudo que se aproxima mais desta pesquisa é o de Basharat, Azam e Muzaffar (2012). Mas avalia apenas cinco estudos sob aspectos de segurança. Os estudos avaliados são de uma época anterior às propostas atuais. Também não indica a aplicação de um levantamento sistemático.

A pesquisa atual, embora se assemelhe a outros estudos em alguns aspectos, tem características próprias e busca por meio delas atingir seus objetivos.

(31)

3

3. Noções de Criptografia

Esta seção busca esclarecer alguns conceitos sobre técnicas criptográficas que atualmente são usadas nas propostas de soluções para DBaaS, bem como outras que, embora não sejam viáveis, são tidas como uma possível solução para muitos desafios.

(32)

3.1 Criptografia Simétrica e Assimétrica

Atualmente existem dois tipos de algoritmos criptográficos bastante difundidos. Os mais antigos são os simétricos. Levam este nome porque uma chave igual é utilizada. Consequentemente, o remetente de uma mensagem precisa compartilhar a chave com o destinatário. Seu funcionamento geral pode ser representado da seguinte forma:

Enck(M) = C e Deck(C) = M, logo Deck(Enck(M)) = M

Ao receber um texto claro M e uma chave K, a função Enc entregará C, que é o texto encriptado. A função Dec executa a operação inversa, retornando o texto original M a partir de C e da chave K. A opção por algoritmos simétricos recai sempre no problema da distribuição de chaves de forma segura. O AES (EUA, 2001) é um exemplo de algoritmo simétrico. O fato de ser um padrão estimula a sua adoção. Ele foi pensado para ser flexível, por isso admite três tamanhos de chave e de quantidades de rodadas.

Diante da inquietude gerada pelo problema de compartilhamento de chaves, Diffie e Hellman anunciaram em um estudo: “nós estamos à beira de uma revolução na criptografia” (DIFFIE; HELLMAN, 1976). O algoritmo de Diffie e Hellman iniciou a popularização da criptografia assimétrica. Em seguida um estudo de Rivest, Shamir e Adleman (1978) apresentou o RSA, um sistema criptográfico assimétrico completo. As chaves usadas estão relacionadas e são geradas pelo RSA. Sua segurança baseia-se na dificuldade de fatorar o produto de dois números primos grandes. O funcionamento de algoritmos assimétricos pode ser representado como:

(33)

Juma diferença essencial entre o funcionamento dos algoritmos simétricos e assimétricos é que não é preciso compartilhar uma chave secreta. A chave utilizada pelo remetente é pública e não é necessário sigilo na sua distribuição. Existem outras opções de algoritmos assimétricos, como os que baseiam sua segurança no problema de curvas elípticas.

3.2 Homomorfismo

Depois da publicação do RSA um importante trabalho de Rivest, Adleman e Dertouzos (1978) apresentou possibilidades até então pouco consideradas. O estudo tratava de situações reais que exigiriam a execução de operações sobre valores encriptados, preservando a privacidade. O estudo indicava que isso seria possível com o RSA, mas levantava limitações. Denomina-se esta propriedade de homomorfismo. De maneira geral, um algoritmo assim tem seu homomorfismo descrito como:

Enc(M1 M2) = Enc(M1) Enc(M2)

Sendo uma operação, seria possível realizar, por exemplo, uma adição sobre dados ainda encriptados. Quanto as propriedades homomórficas, é importante destacar que se enquadram em dois tipos: parcialmente homomórficos, do inglês Partially Homomorphic Encryption (PHE), e completamente homomórficos, do inglês Fully Homomorphic

Encryption (FHE).

Os esquemas FHE suportariam qualquer tipo de operação, mas ainda residem no campo teórico. Entretanto, já existem implementações de esquemas PHE aplicáveis na prática, mas limitadas a um tipo de operação. Alcançar a construção de um FHE viável poderia ser representativo para o modelo DBaaS.

(34)

Um esquema FHE poderia ser usado em funções agregadas. Por exemplo, Agrega poderia representar uma função agregada qualquer. Seria possível dividir ou multiplicar dados encriptados em uma coluna com um

comando SELECT Agrega(CampoValor) FROM TabelaDados. Bastaria

substituir Agrega pela função correspondente a soma ou multiplicação. O

mesmo campo CampoValor poderia ser dividido pelo campo

CampoDivisor, também encriptado. Os resultados seriam entregues encriptados ao usuário do serviço DBaaS e seriam desencriptados.

A grande expectativa em relação ao desenvolvimento de um algoritmo com essas possibilidades gira em torno de cenários como os mencionados. Os dados poderiam ser armazenados na nuvem já encriptados, ser processados ainda encriptados na própria nuvem e o resultado seria devolvido encriptado para o usuário desencriptar. Esquemas FHE permitiriam aos clientes dos provedores de DBaaS aproveitarem as vantagens da nuvem com garantias de sigilo.

3.2.1 Encriptação Parcialmente Homomórfica (PHE)

São denominados algoritmos parcialmente homomórficos aqueles que preservam o homomorfismo para uma única operação, não para todas. Por exemplo, um algoritmo que permita a execução somente da operação de adição sobre dados encriptados é considerado parcialmente homomórfico.

Uma outra restrição a ser considerada é o limite de vezes que as operações suportadas podem ser executadas sobre os dados antes que a desencriptação falhe. Um dos focos de esforço no trabalho de construção de algoritmos homomórficos é permitir a execução das operações por uma quantidade de vezes indefinida ou máximo que for possível (SMART; VERCAUTEREN, 2010).

(35)

Embora existam trabalhos, como o de Naehrig, Lauter e Vaikuntanathan (2011), que indiquem a aplicabilidade prática da PHE, a busca pela possiblidade de execução de operações de forma ilimitada ainda parece ser o caminho mais cobiçado.

Um exemplo de algoritmo PHE aplicado em estudos (POPA et al., 2011; FERRETTI et al., 2014b; TU et al., 2013) de soluções de banco de dados encriptados é o de sistema proposto por Paillier (1999). Trata-se de um algoritmo para criptografia de chave pública aditivo. Utilizando Paillier é possível encriptar, com a chave pública, dois valores X1 e X2, operar uma adição sobre eles e obter o resultado da soma que poderá ser desencriptado com a chave privada.

Outros algoritmos de criptografia com chave pública possuidores de propriedades homomórficas funcionam essencialmente da mesma forma, mas permitem computação sobre outros tipos de operação. O Quadro 3.1 lista mais exemplos (RIVEST; ADLEMAN; DERTOUZOS, 1978; ELGAMAL, 1985; GOLDWASSER; MICALI, 1984; BENALOH, 1994) de algoritmos PHE e qual operação é suportada por cada um deles:

Algoritmo Operação suportada

RSA Homomorfismo multiplicativo El Gamal Homomorfismo multiplicativo

Goldwasser-Micali Homomorfismo sobre XOR (ou exclusivo) Benaloh Homomorfismo aditivo

Paillier Homomorfismo aditivo

Quadro 3.1 - Algoritmos parcialmente homomórficos e operações

Fonte: elaborado pelo autor

3.2.2 Encriptação Completamente Homomórfica (FHE)

Quase trinta anos depois do estudo de Rivest, Adleman e Dertouzos (1978) abrir um horizonte, o trabalho de Boneh, Goh e Nissim (2005) renova

(36)

expectativas em relação a criação de um esquema FHE. Não encerrou a busca por um esquema de FHE praticável, mas indicou a factibilidade. O esquema suportava adições arbitrárias e uma multiplicação (seguida por adições arbitrárias) sobre dados encriptados. Não se tratava ainda de homomorfismo completo, mas era uma contribuição considerável.

Passados cinco anos o trabalho de Gentry (2009a) revelou, finalmente, um esquema FHE. O esquema proposto utiliza reticulados ideais para prover o homomorfismo. Operações sobre dados encriptados incluem ruídos nestes dados. A partir de uma certa quantidade de ruído a desencriptação ficará comprometida. A grande contribuição de Grant foi desencriptar e reduzir o ruído inconveniente de maneira homomórfica. Entretanto, a solução proposta por Gentry para o ruído também acarreta um aumento demasiado no tamanho de parâmetros necessários. Portanto, a solução não viabiliza o uso de FHE em aplicações práticas.

Depois deste marco outros trabalhos surgiram propondo formas mais práticas e eficientes de lidar com o problema em questão. O trabalho de Gentry e Halevi (2011) propõe um novo esquema esperando abrir caminho para a eliminação dos gargalos da proposta de Gentry (2009a).

Brakerski e Vaikuntanathan (2011) basearam sua proposta de FHE em aprendizagem com os erros (LWE), do inglês learning with errors. A proposta baseia-se em reticulados arbitrários e não utilização de pressupostos assumidos em outros trabalhos que resultavam em gargalos.

Os esforços continuam para propor novas soluções ou otimizações de soluções que marcaram a evolução das pesquisas. Isto indica que esta área ainda está em estágio de amadurecimento. Portanto, provavelmente precisará percorrer um longo caminho até que alcance aplicabilidade prática.

(37)

4

4. Soluções Baseadas em

Criptografia para DBaaS

Esta seção apresenta a pesquisa, o método utilizado, o ciclo da pesquisa, os estudos catalogados e os resultados encontrados.

(38)

4.1 Apresentação

Esta seção apresenta a fundamentação para o método de pesquisa escolhido, descreve o ciclo da pesquisa, sintetiza os estudos primários catalogados com cada arquitetura identificada e relata análises e resultados.

4.2 Método da pesquisa

Segundo Marconi e Lakatos (2010) não há ciência sem o emprego de métodos científicos. Tomando como base os objetivos da pesquisa e a forma de condução da mesma, o método utilizado é dedutivo. Este tipo de método caracteriza-se como aquele que a partir de duas proposições gera inevitavelmente uma conclusão (FACHIN, 2006). Pode-se dizer que um método dedutivo tem como objetivo explicar o conteúdo das premissas por meio de um raciocínio descendente e logicamente encadeado que finda em uma conclusão (SILVA; MENEZES, 2005).

Ainda sobre as bases metodológicas do método, a pesquisa também se baseia em um método comparativo, pois segundo Fachin (2006) este é um tipo de método que busca investigar e explicar fatos segundo as suas semelhanças e diferenças. Comumente um método comparativo aborda duas séries ou fatos de natureza análoga a fim de detectar intersecções.

Segundo Gil (2010) e Marconi e Lakatos (2010), quanto a abordagem, esta pesquisa pode ser definida como quantitativa e, quanto aos objetivos, como descritiva. Pois, respectivamente, usa técnicas para coleta de dados usados em análises estatísticas e descreve uma situação sem a interferência do pesquisador.

O método utilizado na pesquisa é o mapeamento sistemático e baseia-se na proposta de revisão sistemática de Kitchenham (2004).

(39)

Kitchenham, Budgen e Brereton (2011) diferenciam revisões e mapeamentos. Ambos permitem categorizar estudos, mas na revisão o detalhamento de estudos é relevante. A revisão busca contradições ou consistências entre estudos, o mapeamento busca a catalogação e caracterização. O mapeamento pode desconsiderar os resultados dos estudos catalogados e a avaliação de qualidade.

A presente pesquisa se acomoda bem sobre um mapeamento sistemático. Pois estuda uma população abrangente de outros trabalhos, investigando desdobramentos de uma proposta de arquitetura (POPA et al., 2012) em estudos posteriores. Outros fatores foram ponderados na escolha do método. A revisão bibliográfica identificou nos estudos uma ausência de estruturação e diferenças de escopo e na aferição de resultados. Segundo Kitchenham (2004), um estudo que usa mapeamento é secundário, pois mapeia estudos primários. Um mapeamento pode ser usado para sumarizar evidências, identificar lacunas e prover subsídios novas investigações.

Como ilustra a Figura 4.1, o método proposto por Kitchenham (2004) conta com as fases de planejamento, condução e reporte de resultados. Cada fase é dividida em estágios. As setas descendentes sugerem um processo sequencial, as setas pontilhadas ascendentes indicam a possibilidade de iteração entre as fases. Isto permite adequações em atividades realizadas em fases anteriores.

Figura 4.1: Visão simplificada do mapeamento sistemático

(40)

Segundo Kitchenham (2004), na fase de planejamento é levantada a necessidade do estudo e definido o protocolo de mapeamento. O protocolo reforça a imparcialidade, evitando vieses. A fase de condução é a execução do protocolo criado na fase de planejamento. A fase de reporte de resultados trata da comunicação dos resultados com atenção as restrições de formato.

4.3 Ciclo da Pesquisa e o Mapeamento Sistemático

A pesquisa foi dividida em duas fases. A primeira fase, de objetivo exploratório, tratou-se de uma revisão bibliográfica tradicional e a segunda envolveu um mapeamento sistemático. Na primeira fase um total de 55 artigos foram estudados. Alguns trabalhos contribuíram definir parâmetros para a fase seguinte.

A segunda fase consistiu na execução do mapeamento sistemático. Esta seção resume as principais atividades realizadas nas fases de planejamento, execução do protocolo, síntese dos estudos e análises sobre os dados.

Estudos obtidos na revisão bibliográfica tradicional foram revisitados para definição de parâmetros. Buscou-se uma ferramenta de suporte ao método, considerando o ranking de Marshall, Brereton e Kitchenham (2014). Verificou-se que o software escolhido, o StArt (LAPES, 2015), é aderente ao método de Kitchenham (2004), como afirmam Fabbri et al. (2012). Os estudos não tratavam o assunto pesquisado de forma estruturada. Portanto, o formulário de extração de dados sofreu vários de ajustes. Foram definidas estratégias iniciais de análises.

Para identificação dos estudos foram realizados experimentos em cada fonte para entender o funcionamento e a sintaxe para strings de busca. Foram criadas formas automatizadas de resgatar os resultados das fontes.

(41)

Também foi preciso aplicar ferramentas para converter formatos de resultados (RIS, BibTeX, Medline, etc.) suportados pelas fontes.

Para identificar os estudos foi criada uma string de busca geral. A

string deveria trazer o universo de estudos que respondessem à pergunta

de pesquisa. O desafio era não excluir qualquer estudo e não trazer um número elevado de estudos dissociados. A string de busca utilizada obteve 1.534 estudos e está ilustrada na Figura 4.4:

Figura 4.4: String de busca escolhida

Fonte: elaborada pelo autor.

Os artigos identificados foram indexados na ferramenta StArt. O Gráfico 4.1 ilustra a quantidade de estudos encontrada por fonte.

Gráfico 4.1: Estudos encontrados por fonte Fonte: elaborado pelo autor

(42)

Como orientado por Kitchenham (2004), o estágio de seleção foi dividido em duas etapas. Na primeira os critérios de inclusão e exclusão foram aplicados sobre o título, abstract e palavras-chave de cada estudo. Foram rejeitados 1.477 e 57 estudos passaram para a segunda etapa. A Tabela 4.1 mostra estes números detalhados por fonte.

Tabela 4.1: Resultados da etapa 1 da seleção

Fonte Ident.

Exclusão

Pre-seleção

Repetidos Em alemão Outros

motivos ACM 114 5 0 96 13 CiteSeerX 248 60 0 182 6 Eng. Village 19 18 0 1 0 IEEE 376 7 0 359 10 Sc. Direct 110 0 0 108 2 Scopus 375 137 0 223 15 Springer 292 65 1 215 11 Totais 1.534 292 1 1.184 57

A segunda etapa, realizada pelo pesquisador e um auxiliar previamente orientado, consistiu na leitura adicional da introdução e conclusão dos 57 artigos resultantes. Um artigo adicional foi identificado nas referências com base em snowball (GREENHALGH; PEACOCK, 2005). A lista de pré-selecionados passou para 58 itens. Foram rejeitados 40 artigos e 18 estudos primários foram selecionados. A Tabela 4.2 detalha os números.

Tabela 4.2: Resultados da etapa 2 da seleção

Fonte Pré-seleção Rejeitados Duplicados Selecionados

ACM 13 8 0 5 CiteSeerX 6 4 1 1 IEEE 10 8 0 2 Sc. Direct 2 1 0 1 Scopus 15 8 0 7 Springer 11 9 1 1 Snow ball 1 0 0 1 Totais 58 38 2 18

(43)

A extração dos dados ocorreu sobre os 18 estudos selecionados e foi baseada no formulário de extração. Autores de 6 artigos foram contatados para esclarecimentos, como recomendado por Kitchenham (2004). Cópias do e-mail foram enviadas para até o terceiro autor de cada estudo. O formulário elaborado em uma planilha eletrônica. A execução do protocolo do mapeamento sistemático está detalhada na Figura 4.3.

Figura 4.3: Fluxo de execução do protocolo do mapeamento sistemático

A síntese dos dados extraídos foi baseada no formulário de extração e cotas destacadas. Basicamente consistiu na geração da síntese textual de cada trabalho selecionado com a finalidade de catalogação. Neste estágio houve a identificação da arquitetura usada em cada estudo.

As estratégias de análise criadas no planejamento foram revisitadas. Com os dados obtidos na extração foi possível definir como seria a análise, dispersão e completude dos dados puderam ser considerados. As análises foram executadas e os resultados obtidos.

(44)

4.4 Estudos Catalogados na Execução da Pesquisa

A seguir são apresentadas as sínteses dos 18 estudos catalogados. Na descrição de cada estudo é destacada a análise e identificação da arquitetura usada na solução.

4.4.1 CryptDB: Protecting Confidentiality with Encrypted Query Processing

4.4.1.1 Proposta do estudo

A proposta de Popa et al. (2011), o CryptDB, cobre dois tipos de ameaças: (I) alguém com privilégios administrativos legítimos e (II) um ataque que possa comprometer qualquer um dos componentes do sistema. Para conter a ameaça (I), o CryptDB utiliza uma ideia de camadas de encriptação, como em uma cebola. O sistema decide sobre qual camada requisitará os dados dependendo da consulta executada. As camadas utilizam esquemas criptográficos com níveis de segurança diferentes.

Para tratar a ameaça (II) a solução armazena anotações no CryptDB que descrevem políticas de controle de acesso para usuários. Com base nestas anotações ocorre o gerenciamento de chaves de encriptação. O próprio CryptDB só poderá ter acesso às chaves por meio das senhas de usuários autenticados.

4.4.1.2 Arquitetura Identificada

Como definido em Popa et al. (2011) o CryptDB funciona sobre uma arquitetura Proxy. A Figura 4.5 ilustra a arquitetura, bem como todos os componentes, seus principais subcomponentes e ainda o modelo de tratamento de ameaças. O proxy precisa estar em ambiente seguro.

(45)

Figura 4.5: Arquitetura e modelo de tratamento de ameaças do CryptDB

Fonte: POPA et al., 2011.

4.4.2 A Comprehensive Framework for Secure Query Processing on Relational Data in the Cloud

4.4.2.1 Proposta da pesquisa

O trabalho de Wang, Agrawal e Abbadi (2011) baseia-se em “salted”

Informational Dispersal Algorithm (IDA) e em column-access-via-proxy. O salted IDA, que conta com fatores aleatórios denominados de salt, melhora

a confidencialidade do IDA original. O IDA dispersa dados matriciais em partes não interpretáveis. O modelo de segurança prevê servidores não confiáveis, mas clientes e proxies confiáveis.

A utilização de proxies dificulta a identificação de usuários, evitando inferências sobre os dados. O uso de vários proxies pode balancear carga e garantir maior tolerância a falhas. Para as consultas é usado um índice em árvore B+. Os clientes recuperam da nuvem uma parte do índice para localizar tuplas candidatas. Como recomendado por Kitchenham (2004), o autor esclareceu que a solução funcionaria sobre um DBMS de mercado, mas seriam necessárias modificações para suportar a árvore B+.

A Figura 4.6 ilustra a arquitetura da proposta de Wang, Agrawal e Abbadi (2011). Estão presentes na solução os clientes (c1, c2, c3 e c4), os

proxies e os servidores na nuvem. Portanto, trata-se de uma arquitetura

(46)

Figura 4.6: Arquitetura de Wang, Agrawal e Abbadi (2011)

Fonte: adaptado de WANG; AGRAWAL; ABBADI, 2011

4.4.3 Mimosecco: A Middleware for Secure Cloud Storage

No artigo de Achenbach, Gabel e Huber (2011) é proposto o MimoSecco. A solução distribui um serviço particionado entre servidores. Para isso transforma o modelo em texto claro escondendo relações entre os dados. Por exemplo, a tabela A, em texto claro, é transformada em três tabelas. Uma tabela de dados e mais duas tabelas de índice. A encriptação dos dados é parcial. Tabelas de dados e índices são alocadas em servidores separados. Na execução de consultas um módulo adapter consulta as tabelas de índices e, após desencriptar os resultados, consulta a tabela de dados. O resultado é desencriptado pelo adapter. Algumas consultas geram resultados parciais que precisam de um pós-processamento no adapter.

O sistema funciona sobre um adapter que intermedia as interações entre cliente e servidor. O MimoSecco utiliza hardware criptográfico no servidor. Um outro trabalho de Huber e Hartung (2014), define um modelo de segurança para o MimoSecco. O adapter é assumido como parcialmente confiável, considerando que não haverá vazamento da chave. A solução aponta o uso de hardware criptográfico. O cliente é considerado confiável e o DBMS não é confiável.

(47)

A distribuição de componentes é ilustrada na Figura 4.7. O adapter do MimoSecco é um Proxy, como bem foi observado por Lehner, Oberweis e Schiefer (2014). Não há processamento de consultas no cliente, que delega ao adapter a consulta aos dados e apenas espera os resultados.

Figura 4.7: Arquitetura do MimoSecco

Fonte: (HUBER; HARTUNG, 2014)

4.4.4 Secure Query Processing with Data Interoperability in a Cloud Database Environment

O trabalho de Wong et al. (2014) propõe o SDB, um sistema baseado na ideia de que cada valor em texto claro é decomposto em segredos guardados por partes diferentes. Um protocolo entre as partes executa uma função determinística do valor. O SDB evita esquemas criptográficos incompatíveis e processamento no cliente por meio de interoperabilidade dos dados. Suporta apenas valores inteiros, pois é baseado em aritmética modular. Campos em texto claro são suportados.

A arquitetura do SDB é composta por um DBMS não modificado, o

SDB Server, o SDB Client e as aplicações. O SDB minimiza a quantidade

de elementos de segredo no cliente, diminuindo o espaço usado. O SDB

Client gera planos de execução. Em seguida o protocolo de

compartilhamento de segredo é executado. Ao receber a mensagem o

server protocol identifica no DBMS os dados buscados. O resultado é

(48)

Quanto ao modelo de segurança a camada cliente é confiável. O SDB

Server e o DBMS não são confiáveis. Como orienta Kitchenham (2004), o

autor foi contatado para esclarecimentos. O cliente enxerga SDB Client como se fosse o DBMS.

Como ilustrado na Figura 4.8, a arquitetura do SDB é composta pela aplicação, SDB Client, SDB Server e DBMS. O módulo SDB Client atua como um proxy entre as aplicações e o DBMS. Entretanto, observa-se que este proxy está dividido em dois módulos, o SDB Client e o SDB Server.

Figura 4.8: Arquitetura do SDB

Fonte: WONG et al., 2014

4.4.5 Security and confidentiality solutions for public cloud database services

A proposta de Ferretti et al. (2013) suporta clientes distribuídos. O cliente busca os metadados na nuvem, desencripta-os e os mantém localmente. O modelo de segurança prevê uma WAN não confiável, um cliente confiável e um administrador de nuvem semi-honesto.

O estudo utiliza encriptação em camadas de cebolas por campo. Em cada cebola a camada mais externa de encriptação denomina-se Actual

(49)

cebolas que está associada. Na criação do esquema ocorre a associação automática de cebolas aos campos, mas é permita customização pelo DBA. Em uma consulta as camadas da cebola são desencriptadas até chegar em uma compatível com os operadores utilizados.

A arquitetura proposta por Ferretti et al. (2013) é ilustrada na Figura 4.9 e aplica-se naturalmente aos ambientes cliente-servidor.

Figura 4.9: Arquitetura proposta por Ferretti et al. (2013)

Fonte: FERRETTI et al., 2013.

4.4.6 Orthogonal security with Cipherbase

O Cipherbase (ARASU et al., 2013) estende o Microsoft SQL Server. Na proposta a execução das consultas é dividida entre hardware tradicional e coprocessador baseado em Field-Programmable Gate Array (FPGA) assumido como seguro. Campos níveis de encriptação mais fortes implicam em pior desempenho. Campos não encriptados são suportados. Quanto ao modelo de segurança, o hardware seguro e o cliente são assumidos como confiáveis.

O hardware seguro só é usado nos casos indispensáveis. Cada cliente possui uma chave usada para encriptar dados e comandos SQL.

(50)

Resultados vindos do servidor também são desencriptados com esta chave. A porção da consulta que executará no hardware seguro contém a assinatura do cliente. O hardware confiável contém uma chave secreta, pois as tuplas encriptadas devem ser desencriptadas para processamento. O resultado é encriptado e mandado para fora do hardware. A mesma chave é usada para encriptar as chaves das aplicações no cliente.

A arquitetura do Cipherbase, ilustrada na Figura 4.10, é restrita ao modelo cliente-servidor. As áreas azuis são confiáveis (Client Machine e

TM) e as áreas brancas não confiáveis (UM e Blocks). As áreas em

vermelho indicam os componentes modificados para a solução.

Figura 4.10: Arquitetura geral do Cipherbase

Fonte: ARASU et al., 2013.

4.4.7 Processing Analytical Queries over Encrypted Data

A solução Monomi (Tu et al., 2013) foi construída sobre um DBMS não modificado. A ideia é lidar com o I/O de consultas analíticas sobre conjuntos muito grandes de dados encriptados, dividir consultas para execução no servidor ou no cliente e refinar planos de execução.

(51)

Consultas são divididas pelo componente planner entre cliente e servidor. O processamento no servidor é priorizado. A solução utiliza uma árvore de operadores para dividir a consulta em partes e não suporta armazenamento de texto claro. Um módulo designer otimiza o projeto físico do modelo. Já o Monomi ODBC library é o único elemento com acesso às chaves de desencriptação. O modelo de segurança assume o cliente confiável e o servidor não confiável.

A Figura 4.11 ilustra o modelo segurança e a arquitetura Cliente-servidor do Monomi. Os componentes concentram-se na zona confiável, descrita como Trusted client. A ideia é que cada cliente se comunique diretamente com o DBMS.

Figura 4.11: Arquitetura do Monomi

Fonte: TU et al., 2013.

4.4.8 Solution for Secure Private Data Storage in a Cloud

O estudo de Shatilov et al. (2014) propõe uma solução que usa FHE, não passa chaves para o servidor de forma insegura e combina várias encriptações em uma tabela. O DBMS utilizado não precisa de modificações. O módulo cliente é composto por quatro componentes, sendo o SQL queries processor o componente principal. Ele transforma as

(52)

consultas antes de enviá-las para o DBMS e processa as respostas do DBMS. O modelo de segurança assume o cliente como confiável.

A solução utiliza metadados em arquivos. Nomes de colunas e tabelas são anonimizados. Os campos encriptados são definidos na criação das tabelas. Em contato com o autor, como orienta Kitchenham (2004), verificou-se que o algoritmo candidato a FHE (ZHIROV; ZHIRIVA; KRENDELEV, 2013) utilizado gera um vetor de valores encriptados cujos itens são armazenados em campos na tabela.

A proposta de Shatilov et al. (2014) é uma solução baseada no modelo de arquitetura cliente-servidor, como ilustrado na Figura 4.12. A solução é um cliente instalado na máquina do usuário.

Figura 4.12: Arquitetura geral da solução de Shatilov et al. (2014)

Fonte: SHATILOV et al., 2014

4.4.9 Scalable architecture for multi-user encrypted SQL operations on cloud database services

Ferretti et al. (2014b) propõem o MuteDB que conta com o MuteDB

DBA client e os MuteDB clients. Os MuteDB clients podem executar

consultas de forma concorrente. Os dados e os metadados são armazenados encriptados. O DBA é o único que pode modificar metadados, pois cabe a ele a administração do controle de acesso. O modelo de segurança prevê: um DBA do cliente confiável, cloud insiders honestos e

(53)

curiosos, ataques arbitrários e conluio entre usuários legítimos do cliente e

cloud insiders.

Regras de autorização de banco de dados em texto claro são transformados em regras aplicadas em um banco de dados encriptado. O controle de acesso ocorre no nível de tabelas. Uma chave secreta é fornecida com as credenciais, permitindo calcular, por algoritmos de derivação (ATALLAH et al. 2009; CRAMPTON; MARTIN; WILD, 2006), as chaves criptográficas do banco de dados. O DBA distribui chaves secretas únicas para os usuários, de acordo com uma matriz de controle de acesso.

A proposta usa o modelo de arquitetura cliente-servidor, como ilustrado na Figura 4.13 e conta um cliente voltado para atividades do DBA.

Figura 4.13: Arquitetura do MuteDB

Fonte: FERRETTI et al., 2014b.

4.4.10 Distributed, Concurrent, and Independent Access to Encrypted Cloud Databases

O SecureDBaaS de Ferretti, Colajanni e Marchetti (2014a) utiliza um