Marcelo Ferreira de Lima - UFPE · execução de operações sobre dados encriptados no provedor de DBaaS. Um estudo, precursor e destacado, baseia sua solução em uma arquitetura

“SOLUÇÕES PARA DBAAS COM DADOS

ENCRIPTADOS: MAPEANDO ARQUITETURAS”

Por

Marcelo Ferreira de Lima

Dissertação de Mestrado Profissional

Universidade Federal de Pernambuco [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, 2015

Universidade Federal de Pernambuco

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.

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

Dissertação de Mestrado Profissional apresentada por Marcelo Ferreira de Lima à Pós-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.

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.

Agradeço a Deus.

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-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.

Computação em Nuvem. Arquitetura. Segurança da Informação.

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

Computing. Architecture. Information Security.

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

Figura 4.22: Sugestão de arquitetura de Liu et al. (2014) .................................................... 62

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

Gráfico 4.11: Estudos que utilizam abordagem de cebola e/ou múltiplas colunas .............. 73

LISTA DE QUADROS

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

Quadro 4.1 - Categoria e ano dos estudos catalogados ...................................................... 64

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

Tabela 4.4: Quantificando vantagens e desvantagens do modelo Proxy ............................ 68

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

4.4.7 Processing Analytical Queries over Encrypted Data ............................................................. 49

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

C.1 Lista de Estudos Catalogados ...................................................................................................... 113

13

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.

14

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.

15

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

16

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,

17

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.

18

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.

19

• 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 DB aaS: 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.

20

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.

21

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;

22

• 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

23

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.

24

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

Fonte: elaborada pelo autor

25

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.

26

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

27

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.

28

Figura 2.3: Ameaças e componentes do CryptDB


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

29

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.

30

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.

31

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:

Encpubk(M) = C e Decprivk(C) = M, logo Decprivk(Encpubk(M)) = M

32

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.

33

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).

34

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

35

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.

36

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.

37

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).

38

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


39

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.

40

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


41

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


42

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.

43

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 Encr ypted 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.

44

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 Pr ocessing 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

Proxy.

45

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 Stor age


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.

46


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 Interoperab ility 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 é

mandando para o cliente, onde é desencriptado e entregue à aplicação.

47

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 pu blic 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

Layer. O tipo de cada coluna em texto claro precisa ser compatível com as

48

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.

49

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.

50

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

51

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 encrypte d 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

52

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 Acc ess to Encrypted

Cloud Databases


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

SecureDBaaS client para viabilizar leitura e escrita de dados, além de

53

criação e modificação de tabelas. O cliente gerencia dados em texto claro,

dados encriptados, metadados e metadados encriptados. Dados e

metadados são guardados encriptados no servidor da nuvem. O tratamento

de concorrência acontece de duas formas. Para SQLs que alteram a

estrutura de tabelas a solução usa o Snapshot Isolation de Berenson et al.

(1995), os demais SQLs são tratados pelo DBMS.

Metadados são usados para gerar SQLs compatíveis com a base

encriptada. O servidor entrega o resultado ao SecureDBaaS client, que

desencripta o conteúdo e entrega ao cliente. Cada tabela do modelo em

texto claro possui uma equivalente no modelo encriptado. Nomes de tabelas

e colunas são anonimizados. Cada campo precisa ser definido

considerando um tipo de dados básico, o tipo de encriptação e o nível de

confidencialidade. O modelo de segurança assume clientes confiáveis e

cloud insiders são honestos e curiosos.


A solução usa uma arquitetura cliente-servidor. A Figura 4.14 ilustra a

distribuição dos componentes sobre o modelo de segurança, os acessos

múltiplos e os metadados e dados no cliente.

Figura 4.14: Arquitetura geral do SecureDBaaS

Fonte: FERRETTI; COLAJANNI; MARCHETTI, 2014a.

54

4.4.11 TrustedDB: A Trusted Hardware-Based Database with Privacy

and Data Confidentiality


O estudo de Bajaj e Sion (2014) apresenta o TrustDB, que utiliza

hardware seguro (SCPU) para processamento criptográfico. Os autores

demonstram um custo menor com o uso de SCPU. O processamento de

consultas é dividido entre servidor e SCPU. No caso de campos privados a

desencriptação só pode ocorrer na SCPU ou no cliente.

Consultas privadas podem depender dos resultados de consultas

públicas, o inverso também é verdadeiro. Os autores dedicam um outro

estudo prévio (BAJAJ; SION, 2011) sobre a execução de consultas. O

modelo de segurança assume um servidor não confiável e curioso.


Como ilustrado na Figura 4.15, a arquitetura cliente-servidor é

adotada. Não há qualquer módulo intermediário e o acesso ao banco se dá

por um cliente, como em qualquer DBMS tradicional.

Figura 4.15: Arquitetura geral do TrustedDB

Fonte: adaptada de Bajaj e Sion (2014).

55

4.4.12 L-EncDB: A lightweight framework for privacy -preserving data

queries in cloud computing


O L-EncDB de Li et al. (2015) permite manter a estrutura original dos

dados. A solução funciona sobre format-preserving encryption (FPE), que

preserva o tipo e o comprimento do dado encriptado. A camada application

system conta com uma application program interface (API) que transforma

e devolve a aplicação comandos SQL na versão encriptada. Este comando

é enviado ao DBMS na camada database.

Algumas operações SQL usam um esquema FPE, enquanto outras,

que envolvem consultas fuzzy e intervalos, usam esquemas order-

preserving encryption (OPE) e fuzzy query encryption (FQE) e precisam de

campos adicionais no modelo. O modelo de segurança assume atacantes

com acesso apenas a base de dados e atacantes com acesso também a

aplicação. Controles para proteger a senha usada pelo L-EncDB são

assumidos como existentes.


O L-EncDB é uma API a ser usada por uma aplicação. Como ilustrado

na Figura 4.16 não estabelece comunicação direta com o servidor. A solução

baseia-se no modelo Cliente-servidor.

Figura 4.16: Arquitetura do L-EncDB

Fonte: LI et al., 2015.

56

4.4.13 Enhancing Data Privacy in the Cloud


A solução de Lu e Tsudik (2011) exige que o database owner encripte

todo o banco com um algoritmo simétrico antes de enviá-lo para o servidor.

Se autorizado por uma certificate authority, um cliente pode formular uma

consulta e solicitar ao database owner um token e uma chave de

desencriptação. O usuário envia o token da consulta para o servidor e

recebe o resultado, que será desencriptado pelo cliente.

O modelo de segurança assume um adversário malicioso e que pode

haver conluio entre usuário e o servidor na nuvem. O database owner é

completamente confiável. Há exposição da estrutura de dados criada para

representar a consulta. Também existe uma possibilidade de ataques

similares à força bruta no servidor.


A Figura 4.17 ilustra de forma geral o funcionamento do sistema. As

comunicações entre os componentes se dão sem intermediários. É utilizada

uma arquitetura Cliente-servidor descentralizada, pois várias funções estão

distribuídas sobre diferentes elementos da arquitetura.

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

Fonte: LU; TSUDIK, 2011

57

4.4.14 Supporting Complex Queries and Access Polici es for Multi-user

Encrypted Databases


A solução de Asghar et al. (2013) suporta a aplicação de políticas de

acesso para usuários. Alterações em permissões, usuários ou tabelas não

implicam em re-encriptação de dados ou re-distribuição de chaves. O

sistema baseia-se em quatro entidades: Database User (DBU), Database

Administrator (DBA), Cloud Server (CS) e Key Management Authority

(KMA). Um DBU autorizado pelo DBA terá um conjunto de chaves gerado

pelo KMA. O KMA pode revogar chaves.

O modelo de segurança assume os DBUs confiáveis para armazenar

dados e suas chaves, mas considera o conluio entre DBUs. O DBA e o KMA

são confiáveis e O CS é assumido como honesto e curioso. O esquema

proxy encryption utilizado (DONG; RUSSELLO; DULAY, 2008) baseia-se em

elementos criptográficos de posse do cliente e do proxy. Para

esclarecimentos sobre a implementação da entidade Data Files foi feito

contato com o autor, como orienta Kitchenham (2004). Foi utilizado um

DBMS MySQL e, na medida que comandos SQL são considerados, um

banco relacional poderia ser usado.


Embora a solução proposta por Asghar et al. (2013) utilize proxy

encryption, isto não a caracteriza como uma arquitetura Proxy. A Figura 4.18

descreve os elementos mencionados e suas interações. Trata-se de uma

arquitetura Cliente-servidor descentralizada.

58

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

Fonte: ASGHAR et al., 2013.

4.4.15 Blind Seer: A Scalable Private DBMS


O Blind Seer de Pappas et al. (2014) usa um DBMS construído para

bancos de dados de médio e grande porte. Até então, utilizava-se somente

buscas por palavras-chave baseadas na quebra dos termos, impactando na

segurança. O uso de busca sublinear eficiente para consultas booleanas

arbitrárias é destacado como avanço. A solução é composta pelo cliente,

servidor, servidor de índices e o query checker. O servidor fornece o banco

encriptado para o servidor de índices, que, de forma alheia, serve às

consultas do cliente. Para evitar consultas indevidas, o query checker aplica

políticas especificadas por meio de um protocolo.

Uma árvore de busca (balance factor tree) encriptada global é usada

para buscas nos dados. A árvore e os dados encriptados são mantidos no

servidor de índices. A busca na árvore é feita com pouco vazamento de

informação, apenas o suficiente para garantir a poda e o desempenho das

buscas. Os resultados de consultas só são desencriptados no cliente. Os

59

autores optaram por um modelo de segurança semi-honesto e detalham os

vazamentos aceitos por componente em determinadas situações.


A Figura 4.19 demonstra os elementos da arquitetura e como

acontece as interações já mencionadas. Toda comunicação é sem

intermediários, mas existem divisões de responsabilidades, configurando

uma arquitetura cliente-servidor descentralizada.

Figura 4.19: Arquitetura do Blind Seer

Fonte: PAPPAS et al., 2014

4.4.16 Processing Private Queries Over an Obfuscate d Database Using

Hidden Vector Encryption


O trabalho de Trombetta, Persiano e Braghin (2014) baseia-se em um

esquema attribute-based para consultar dados encriptados. Os dados são

armazenados no DBMS não confiável. Uma chave que codifica consultas é

entregue pelo data owner, em uma fase de setup, para o usuário. Um

módulo confiável do sistema processa a consulta. Usuários e consultas

podem ser adicionados ou o data owner pode alterar dados sem a

necessidade de re-encriptar tabelas ou re-gerar as chaves.

60

Para que as consultas funcionem: uma codificação usando um vetor

é feita por linha, um campo adicional guarda as posições das colunas

encriptadas, um outro vetor (Hidden Vector Encryption) guarda valores a

serem buscados e, finalmente, os usuários recebem chaves. Por meio de

contato com o autor, como orienta Kitchenham (2004), o foi esclarecido que

operações de alteração de dados não foram testadas.


A Figura 4.20 apresenta o principal componente da arquitetura, que

é um proxy. Mas o data owner comunica-se com o proxy e diretamente com

o DBMS, caracterizando o uso de Proxy e Cliente-servidor descentralizada.

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

Fonte: TROMBETTA et al., 2014

4.4.17 DBMask: Fine-Grained Access Control on Encry pted Relational

Databases


O DBMask de Sarfraz et al. (2015) trabalha sobre um DBMS não

modificado. A solução é composta por quatro entidades. O data owner faz

uso de chaves diferentes para encriptar partes dos dados, que são

encaminhados via um proxy para o data server (DBMS). Um data user

61

autorizado pelo proxy pode fazer uso do sistema. O proxy pode converte as

consultas do data user em consultas encriptadas. O data server entregará

os resultados ao proxy, que serão desencriptados e enviados ao data user.

O modelo de segurança assume que o data owner e o proxy são

confiáveis. O data server é honesto e curioso. Os data users não são

confiáveis e precisam ter seus atributos de identidade emitidos por um

provedor confiável e certificados pelo data owner. Chaves não são

armazenadas no usuário. O comprometimento do proxy permite que os

usuários autenticados tenham os dados acessados. Data users podem ser

revogados sem a necessidade de redistribuição de chaves ou re-

encriptação de dados.


A Figura 4.21 ilustra a arquitetura que suporta o DBMask. Identifica-

se a presença de um Proxy. Entretanto, verifica-se que o data owner toma

para si funções principais, como a concessão de acesso ao sistema e a

encriptação dos dados. Portanto, é uma arquitetura mista do modelo

Cliente-servidor descentralizado e do modelo Proxy.

Figura 4.21: Arquitetura do DBMask

Fonte: SARFRAZ et al., 2015.

62

4.4.18 SQL-Based Fuzzy Query Mechanism Over Encrypt ed Database


A proposta de (LIU et al., 2014) utiliza um DBMS não modificado,

format-preserving encryption (FPE) e propõe um novo mecanismo fuzzy

query encryption (FQE). O módulo criptográfico armazena dados no DBMS

e responde consultas de aplicações. O módulo de interpretação gera

consultas sobre dados encriptados.

Para cada campo do banco um outro será adicionado para o suporte

a consultas fuzzy. O campo adicional vai comportar a string da palavras-

chave encriptadas. Os relacionamentos não são alterados. O modelo de

segurança assume que os módulos precisam estar em um ambiente

confiável.


O sistema pode ser implementado em um proxy ou no cliente, pois a

solução é um software development kit (SDK). A Figura 4.22 ilustra o caso

do uso em Proxy, descrevendo as interações entre as entidades e o uso do

campo adicional (Additional Field).

Figura 4.22: Sugestão de arquitetura de Liu et al. (2014)

Fonte: LIU et al., 2014

63

4.5 Análise Sobre Estudos Catalogados

A análise foi organizada em três partes. A Análise 1 busca tendências

sobre os modelos de arquitetura. A Análise 2 aponta vantagens e

desvantagens da arquitetura Proxy para DBaaS. A Análise 3 confronta as

desvantagens do modelo Proxy e as capacidades exigidas dos provedores

(EUA, 2011). Os estudos catalogados também foram avaliados quanto a

qualidade e dados adicionais sobre o estado-da-arte foram levantados.

4.5.1 Avaliação de Qualidade dos Estudos

Embora Kitchenham, Budgen e Brereton (2011) não apontem como

essencial em mapeamentos, a avaliação de qualidade demonstra a

importância dos estudos e pode basear futuras pesquisas. O Gráfico 4.3

mostra que 100% dos trabalhos contam com contribuições e objetivos bem

definidos. 88,89% apresentam informações detalhadas e apontam trabalhos

futuros. A arquitetura é definida com clareza por 77,78% dos trabalhos. O

atendimento total médio às perguntas foi de 92,22%.

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


A pergunta AQ05 obteve o menor percentual. A ausência de detalhes

sobre a arquitetura em alguns trabalhos, mesmo quando outros aspectos

são detalhados, pode indicar um espaço para trabalhos futuros.

64

4.5.2 Análise Sobre os Modelos de Arquitetura

Análise 01 : o Quadro 4.1 demonstra a categorização dos estudos

nas seguintes arquiteturas: (i) Proxy, (ii) Cliente-servidor, (iii) Cliente-

servidor Descentralizada, (iv) Proxy e Cliente-servidor Descentralizada e (v)

software development kit (SDK).

Estudos categorizados como (i) utilizam arquitetura puramente Proxy,

enquanto os definidos com (ii) utilizam puramente Cliente-servidor. A

categoria (iii) indica o uso da arquitetura Cliente-servidor com funções

distribuídas em mais de um servidor, portanto descentralizada. A categoria

(iv) indica o uso dos modelos de arquitetura Proxy e Cliente-servidor

Descentralizada na mesma solução. Estudos categorizados como (v)

indicam a apresentação da solução em forma de SDK. Neste último caso,

segundo os autores, podendo ser usada em uma arquitetura Proxy ou

Cliente-servidor.

Arquitetura Solução Ano (i) CryptDB (Popa et al., 2011) 2011

(Wang et al., 2011) 2011 MimoSecco (Achenbach et al., 2011) 2011 SDB (Wong et al. 2014) 2014

(ii) (Ferretti et al., 2013) 2013 Cipherbase (Arasu et al., 2013) 2013 Monomi (Tu et al., 2013) 2013 (Shatilov et al., 2014) 2014 MuteDB (Ferretti et al., 2014b) 2014 SecureDBaaS (Ferretti et al., 2014a) 2014 TrustedDB (Bajaj; Sion, 2014) 2014 L-EncDB (Li et al., 2015) 2015

(iii) (Lu, Tsudik, 2011) 2011 (Asghar et al., 2013) 2013 Blind Seer (Pappas et al., 2014) 2014

(iv) (Trombetta et al., 2014) 2014 DBMask (Sarfraz et al., 2015) 2015

(v) (Liu et al., 2014) 2014

Quadro 4.1 - Categoria e ano dos estudos catalogado s Fonte: elaborado pelo autor

65

Com o Gráfico 4.4 é possível obter uma visão sobre o percentual total

dos modelos de arquitetura aplicados nos estudos. O maior percentual fica

para o modelo Cliente-servidor, com 44,44%, seguido pelo modelo Proxy,

com 22,22%. Os demais modelos apresentam 16,67%, 11,11% e 5,56%

para, respectivamente, arquiteturas Cliente-servidor Descentralizada, Proxy

e Cliente-servidor Descentralizada e software development kit (SDK).

Gráfico 4.4: percentual total de arquiteturas aplicadas

Fonte: elaborado pelo autor.

A visão de distribuição ao longo do tempo da aplicação das

arquiteturas é dada pelo Gráfico 4.5. É percebida a maior utilização da

arquitetura Proxy em 2011, seguida de um declínio. A arquitetura Cliente-

servidor é aplicada em 2013 e é seguida por um crescimento. As demais

arquiteturas não contabilizam mais que uma aplicação por ano.

Gráfico 4.5: quantidade de arquiteturas implementadas no tempo


66

Todos os estudos catalogados apresentam, em diferentes

combinações, utilizações das arquiteturas Proxy e Cliente-servidor.

Portanto, é importante aferir a utilização destas duas arquiteturas. A Tabela

4.3 consolida a utilização destas duas arquiteturas, independentemente se

elas estão sendo usadas isoladamente ou de forma combinada. Foi

contabilizado um total de 21 utilizações de arquitetura.

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

Ano Proxy Cliente -servidor Total 2011 3 1 4 2012 0 0 0 2013 0 4 4 2014 3 7 10 2015 1 2 3 Total 7 14 21


Baseado na Tabela 4.3, o Gráfico 4.6 mostra o percentual de

utilizações dos dois modelos. O Proxy fica com 33,33% e o modelo Cliente-

servidor com 66,67%.

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


Pode-se assumir que o total de trabalhos publicados em um ano

tenha relação com a quantidade de trabalhos que usam Proxy ou Cliente-

servidor. Assim é possível estimar uma tendência. Assumida a média de 4

estudos por ano para calcular a tendência, a estimativa é que em 2016 uma

(1,34) publicação utilize o modelo Proxy e duas (2,65) o modelo Cliente-

67

servidor. O Gráfico 4.7 ilustra a dispersão de pontos e as retas de tendência

para Proxy e Cliente-servidor em azul e vermelho, respectivamente.

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


Devido às limitações da série histórica não é viável aplicar modelos

estatísticos que contemplem sazonalidade. Pelo demonstrado, a utilização

da arquitetura Proxy demonstra tendência de queda e o modelo Cliente-

servidor tende ao crescimento.

Análise 02 : foram extraídas dos estudos as observações feitas

explicitamente pelos autores sobre a arquitetura Proxy. A extração dividiu as

observações em vantagens e desvantagens.

A Tabela 4.4 quantifica todas as observações. O campo Citações

informa quantos estudos citaram a observação. Foram extraídas 15

citações. Verifica-se que a quantidade de desvantagens explicitamente

citadas é consideravelmente maior que a de vantagens, a primeira com

quase o triplo das citações da segunda.

O percentual de desvantagens é de 73%. A observação mais

frequente é sobre comprometer características do modelo de DBaaS, com

3 citações. As duas próximas observações mais frequentes foram citadas

em 2 estudos e dizem respeito ao modelo centralizador do Proxy.

68

A lista de desvantagens mencionadas explicitamente nos estudos é

maior que a das vantagens. Algumas desvantagens são reiteradas em dois

ou três estudos. As vantagens apontadas dizem respeito a aspectos de

transparência de acesso dos clientes e maior segurança.

Tabela 4.4: Quantificando vantagens e desvantagens do modelo Proxy

Tipo Observação Citações

Van

tage

ns

Não exige modificação na conexão com o DBMS e nos SQLs das aplicações 1

Permite elevar a segurança ao processar resultado intermediários no proxy, vazando menos informações (ex.: no uso do OPE)

1

Clientes acessam o DBMS de forma transparente 1

Pode dificultar a obtenção de informações sobre o usuário pelo o provedor de DBaaS, facilitando correlações com as consultas que são executadas

1

Total de vantagens 4

Des

vant

agen

s

Compromete características de disponibilidade, confiabilidade e elasticidade, que são essenciais no modelo DBaaS

3

O proxy é um ponto único de falha na segurança 2

Em um ataque, todas as chaves, que no momento estiverem sob o domínio do proxy, serão comprometidas 2

Proxies não suportam apropriadamente cenários com clientes geograficamente dispersos 1

O proxy, assumido como confiável, não pode ser colocado em um ambiente de nuvem não confiável 1

O proxy pode tornar-se um gargalo no sistema 1

Manter um proxy pode ser inviável para clientes que optam pela nuvem para simplificar operações e reduzir custos

1

Total de desvantagens 11

Total geral 15


Análise 3 : primeiramente foi verificado o estado da arte em relação

à distribuição do elemento proxy no modelo de segurança. Entre as 7

soluções catalogadas que utilizam um proxy, 6 delas assumem que ele seja

confiável (SARFRAZ et al., 2015; LIU et al., 2014; WONG et al., 2014;

TROMBETTA; PERSIANO; BRAGHIN, 2014; POPA et al., 2011; WANG;

69

AGRAWAL; ABBADI, 2011) e 1 delas assume um ambiente parcialmente

confiável (ACHENBACH; GABEL; HUBER, 2011).

Mas, como o descrito no site comercial da solução (MIMOSECCO,

2015) e no estudo de Lehner, Oberweis e Schiefer (2014), o proxy desta

solução exige um provedor de nuvem certificado, um parceiro confiável de

negócio, locações em países com jurisdição favorável ou uma nuvem

privada. Também utiliza hardware na guarda de chaves usadas no proxy.

A utilização de proxy confiável representa praticamente o total dos

estudos e não assume uma confiança relativa em terceiros. Portanto, para

as análises desta pesquisa considera-se o modelo de segurança com o

proxy confiável e o tipo de nuvem pública. A desvantagem “o proxy,

assumido como confiável, não pode ser colocado em um ambiente de

nuvem não confiável”, na Análise 02, corrobora com este contexto.

Definido o modelo de segurança, esta análise investiga impactos

sobre as cinco capacidades exigidas (EUA, 2011) dos provedores de nuvem:

Autosserviço sob demanda : com exceção da proposta de Wang,

Agrawal e Abbadi (2011), as soluções que utilizam um proxy armazenam os

dados em um DBMS não modificado. Isto evita alterações nas plataformas

dos provedores da nuvem. Entretanto, comumente o provedor DBaaS

fornece uma ferramenta Web para gerenciamento do banco de dados pelo

próprio cliente (autosserviço). Isto acontece nas soluções DBaaS da

Microsoft, Oracle e Amazon (MICROSOFT, 2015; ORACLE, 2015;

AMAZON, 2015).

A administração de memória, armazenamento e processamento

poderia ocorrer normalmente. Contudo, qualquer acesso ao esquema,

estruturas e dados das tabelas, resultaria na visualização da versão

encriptada do banco de dados. Em algumas soluções (FERRETTI;

70

COLAJANNI; MARCHETTI, 2014a; POPA et al., 2011; SHATILOV et al.,

2014) nomes de tabelas e campos são anonimizados. Para visualizar os

dados e as estruturas em texto claro, só atravessando o proxy.

Considerando a necessidade de o proxy ser confiável, ele ficaria no

ambiente do cliente, dificultando o fornecimento de uma interface web pelo

provedor de DBaaS.

Acesso à rede : o proxy provê transparência da comunicação do

cliente com o DBMS. Também não é necessário distribuir software adicional

para cada cliente, que podem ser heterogêneos. Entretanto, o fato do proxy

precisar ser confiável torna-se uma dificuldade, interferindo na comunicação

para acesso aos dados.

Um cenário comum de clientes dispersos geograficamente, como na

proposta de Wang, Agrawal e Abbadi (2011), exigiria arranjos para

direcionar clientes para os proxies intermediarem os acessos. A Análise 02

aponta duas desvantagens relacionadas: “o proxy pode tornar-se um

gargalo no sistema” e “proxies não suportam apropriadamente cenários com

clientes geograficamente dispersos”.

Pool de recursos e elasticidade rápida : nas soluções catalogadas

que usam proxy o crescimento de clientes poderia implicar em problemas

de disponibilidade do proxy. Se um proxy passa a funcionar fora do provedor

da nuvem, ele não faz parte do pool de recursos. Este proxy não seria

administrado pelo provedor da nuvem, mas provavelmente pelo próprio data

owner. Isto corrobora com a desvantagem previamente mencionada,

“compromete características de disponibilidade, confiabilidade e

elasticidade, que são essenciais no modelo DBaaS”.

Um proxy administrado pelo cliente se opõe as vantagens de

ausência de investimento inicial com infraestrutura e de despesas com

manutenção apontadas por Zhang, Cheng e Boutaba (2010). A

71

desvantagem “manter um proxy pode ser inviável para clientes que optam

pela nuvem para simplificar operações e reduzir custos”, apontada na

Análise 02, resume bem esta questão.

Serviço mensurável : com exceção da proposta de Wang, Agrawal e

Abbadi (2011), que não utiliza um DBMS sem modificações, o proxy não se

mostra um impeditivo para mensuração do serviço. Entretanto, por conta da

anonimização de nomes de tabelas e campos, as informações mensuradas

precisariam de algum tratamento para serem legíveis e úteis para o cliente.

As anonimizações são implementadas para evitar que informações

sobre os dados vazem no servidor. Fornecer um monitoramento demandará

um mapeamento para a estrutura do banco em texto claro. Este

mapeamento poderia ser feito pelo próprio proxy, que é confiável e tem a

função de realizar os mapeamentos para os SQLs. Entretanto, nenhum dos

estudos menciona esforços neste sentido.

As Análises 1, 2 e 3 evidenciam os motivos pelos quais não é trivial

utilizar um proxy para atender todas as capacidades exigidas do provedor.

Por precisar estar em um ambiente confiável, os proxies utilizados nas

soluções que representam o estado-da-arte impactam diretamente nas

vantagens esperadas pelos usuários de soluções DBaaS.

4.5.3 Dados Adicionais Sobre o Estado-da-arte

Esta seção expõe dados adicionais extraídos dos estudos

catalogados. Estes dados apoiam uma melhor compreensão de pontos

relevantes sobre bancos de dados encriptados e levantam possibilidades de

estudos futuros.

72

Foram identificados 16 estudos, do total de 18, que citam o CryptDB

de Popa et al. (2011). Indicando a relevância desta solução para a área. O

CryptDB, de alguma forma, influenciou boa parte dos trabalhos publicados

posteriormente.

Algumas soluções permitem a interferência, pelo data owner ou DBA,

no nível de encriptação. Esta flexibilidade impacta sobre o trade-off entre

funcionalidade e segurança. Como ilustra o Gráfico 4.9, um total de 10 (56%)

estudos permitem interferência e 8 (44%) não permitem.

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


Um total de 6 (33,33%) soluções permitem valores também em texto

claro, como ilustra o Gráfico 4.10. Permitir texto claro pode otimizar o

desempenho e o uso de espaço. Entretanto, pode facilitar a inferência sobre

dados encriptados.

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


73

Foram identificados 2 (11%) estudos, de Tu et al. (2013) e de Wang

et al. (2011), que processam alguma parte da consulta no cliente. É uma

abordagem destoante do modelo de computação em nuvem. Mas contorna

limitações de técnicas de consultas sobre dados encriptados.

Um total de 7 (38,88%) estudos utilizam abordagens de cebola de

encriptação e/ou múltiplas colunas para representar um campo em texto

claro, como aplicado por Popa et al. (2011). Estas abordagens causam

impacto no volume armazenado e no processamento. O Gráfico 4.11 ilustra

o uso destas abordagens ao longo do tempo.

Gráfico 4.11: Estudos que utilizam abordagem de cebola e/ou múltiplas colunas


O mapeamento identificou 3 (16%) estudos que baseiam sua

segurança em hardware. Apenas o estudo de Bajaj e Sion (2014) analisa os

custos reais de processamento utilizando e não utilizando hardware seguro.

Achenbach et al (2011) e Arasu et al. (2013) não apresentam análises.

Foram identificados 2 (11,11%) estudos que utilizam dados e/ou

índices distribuídos em dois ou mais provedores (ACHENBACH et al., 2011;

WANG et al., 2011). Esta distribuição pode incrementar a segurança, desde

que não haja conluio entre provedores.

A pesquisa identificou 7 estudos (38,88%) que utilizam esquemas

PHE aditivos. Apenas Shatilov et al. (2014) implementam uma solução

candidata a FHE, proposta por Zhirov, Zhirova e Krendelev (2013). O

esquema suporta multiplicação e adição e está submetido severas

limitações.

74

5

5. Considerações Finais

Revê os objetivos propostos desta pesquisa, fornecendo um resumo dos

pontos mais relevantes e observando questões para trabalhos futuros.

75

5.1 Síntese da Análise

Foram catalogados 18 trabalhos, categorizados em cinco tipos de

arquiteturas. Verificou-se que houve 92,22% de atendimento às perguntas

da avaliação de qualidade e que trabalhos futuros podem aprofundar as

discussões sobre as arquiteturas de soluções DBaaS seguras. Encontrou-

se uma menor proporção de aplicações com arquitetura puramente em

Proxy em relação à Cliente-servidor e outras apresentações.

Foi identificado na pesquisa que as soluções, independentemente da

combinação, baseavam-se em Proxy ou Cliente-servidor. Portanto, também

se avaliou a utilização do modelo Proxy ou Cliente-servidor nas soluções.

Foram identificadas um total de 21 utilizações. A proporção da utilização de

Proxy também foi menor, inclusive quando foi analisada a tendência da série

histórica. Portanto, o estado da arte de estudos sobre soluções de banco de

dados encriptados para DBaaS aponta para o modelo Cliente-servidor.

Foram extraídas dos estudos todas as vantagens e desvantagens do

modelo Proxy. O número de desvantagens foi maior que o de vantagens. A

desvantagem mais citada é sobre o comprometimento de capacidades

exigidas do modelo de computação em nuvem (EUA, 2011). De acordo com

a análise feita sobre os dados extraídos dos estudos, a necessidade de o

proxy ficar em um ambiente confiável provoca diferentes impactos nas

capacidades esperadas no modelo DBaaS. Dados adicionais sobre o

estado-da-arte foram extraídos para subsidiar trabalhos futuros.

5.2 Resolução dos Objetivos Propostos

Os objetivos específicos, descritos na seção 1.5, são revisitados a

seguir. Adicionalmente é feita uma avaliação que corrobora com o

atendimento de cada um deles.

76

1. Executar um mapeamento sistemático que apresente um

catálogo de estudos, organizado por tipo de arquitetura, sobre

bancos de dados encriptados para DBaaS;

2. Apontar tendências na escolha de arquiteturas e situar a

arquitetura Proxy nestas tendências;

3. Apontar impactos da adoção da arquitetura Proxy quando

aplicada em Database-as-a-Service (DBaaS).

4. Levantar problemas em aberto, direcionando trabalhos

futuros, sobre banco de dados encriptados para DBaaS

O método de mapeamento sistemático baseado na proposta de

Kitchenham (2014) foi planejado e aplicado, identificando e avaliando 1.535

estudos. Foram selecionados para catalogação, organizada por arquitetura,

18 estudos com soluções de bancos de dados encriptados para DBaaS.

Os estudos forneceram evidências para a realização de uma análise

quantitativa sobre as abordagens arquiteturais adotadas. Os dados foram

utilizados para identificar e confrontar a adoção das diferentes arquiteturas.

Foram realizadas análises que identificaram tendências de utilização de

arquiteturas em uma série temporal. A arquitetura Proxy foi situada nestas

tendências, observada a opção por outros modelos arquiteturais.

Análises sobre os dados obtidos apontaram impactos sobre a adoção

da arquitetura Proxy em soluções encriptadas para DBaaS. Vantagens e

desvantagens foram evidenciadas. Um levantamento de dados também foi

realizado sobre os estudos para apontar problemas em aberto. Vários

pontos passiveis de aprofundamento em trabalhos futuros foram

evidenciados nesta pesquisa.

77

5.3 Conclusões e Trabalhos Futuros

A adoção da computação em nuvem é um paradigma atual muito

atrativo para pessoas e empresas. Para garantir as vantagens para os

clientes certas capacidades (EUA, 2011) devem ser atendidas pelo provedor

de serviços na nuvem. Entretanto, garantias de privacidade sobre os dados

processados e mantidos pelos provedores são essenciais. De outro modo

clientes preocupados com sigilo e privacidade buscam outras soluções mais

complexas e caras em detrimento das vantagens da nuvem pública.

No contexto do Database-as-a-Service, estas garantias de

privacidade ainda figuram como desafios (DARA, 2013; ALJAFERA et al.,

2014). Algoritmos completamente homomórficos não indicam uma solução

computacionalmente viável em curto ou médio prazo. Pesquisas atuais

buscam utilizar sistemas criptográficos viáveis para processar e proteger os

dados na nuvem. O uso de soluções como FPE, OPE, técnicas de busca de

palavras-chave, proxy-encryption, PHE, MAC e algoritmos simétricos,

aparecem nas propostas de solução catalogadas por esta pesquisa.

Dentre outras características, a utilização de um determinado

esquema criptográfico guarda relação com a arquitetura escolhida para a

solução, que é de suma relevância dos pontos de vista da segurança,

aplicabilidade e aderência ao modelo de computação em nuvem.

Esta pesquisa mostra, em uma série histórica, como e porque se deu

a escolha das arquiteturas nos estudos que propõem soluções direcionadas

para DBaaS. O método empregado na pesquisa se mostrou apropriado,

levando ao atendimento dos objetivos estabelecidos previamente. O

planejamento cuidadoso de um protocolo e a execução criteriosa do ciclo da

pesquisa foram cumpridos sob as recomendações de Kitchenham (2004). A

78

partir de um universo de 1.535 estudos foi possível chegar a um catálogo de

18 estudos primários para responder à pergunta de pesquisa.

Dos 18 estudos catalogados 22,22% utilizam arquitetura puramente

Proxy e 44,44% puramente Cliente-servidor. Consolidando a utilização de

arquiteturas em dois tipos chega-se ao total de 21 utilizações, sendo 66,67%

de Cliente-servidor e 33,33% de Proxy. Estes mesmos dados analisados ao

longo do tempo demonstram a preferência pela arquitetura Cliente-servidor

em detrimento da arquitetura modelo Proxy. Em uma avaliação de tendência

também foi possível verificar a opção pela arquitetura Cliente-servidor.

As vantagens e desvantagens do uso de um proxy foram extraídas

para consolidar os motivos da não opção pela arquitetura Proxy. O número

de citações de desvantagens foi maior que a de vantagens. Uma

investigação foi realizada para esclarecer os eventuais impactos da

utilização de um proxy no contexto de DBaaS seguro. Esta investigação fez

emergir alguns pontos que remeteram as desvantagens apontadas nos

estudos.

Considerando a adoção de um proxy, também foram incluídas na

investigação duas outras características não enfatizadas nos demais

estudos: a dificuldade em prover autosserviço sob demanda por meio de

uma interface web fornecida pelo provedor de DBaaS e os arranjos que

precisam ser feitos para garantir a característica de serviço mensurável.

As análises demonstraram que o modelo de arquitetura Proxy, por

hora, não é promissor para soluções de banco de dados encriptados para

DBaaS. Os estudos e as análises realizadas mostram desvantagens que

dificultam sua adoção no modelo DBaaS. O fato do proxy precisar estar em

um ambiente confiável é fator determinante. A garantia da privacidade e

sigilo dos dados armazenados e processados na nuvem fica condicionada

ao posicionamento do proxy em um local confiável.

79

O estudo de banco de dados encriptados para DBaaS ainda é um

campo com muitos desafios em aberto. O mapeamento sistemático

realizado nesta pesquisa, além das contribuições já citadas, também

resultou na indicação de uma lista com pontos que podem ser aprofundados

em trabalhos futuros. São eles:

• Aprofundamento da discussão sobre a escolha de arquiteturas

para soluções DBaaS com bancos de dados encriptados;

• Aplicar novamente o mapeamento sistemático, dentro de

alguns anos, para comparação com resultados desta

pesquisa;

• Verificar dentre os trabalhos catalogados quais estão

causando maior impacto em outras pesquisas, usando como

referência, por exemplo, a quantidade de citações que cada

um apresenta em mecanismos de busca;

• Mapear todas as indicações de trabalhos futuros constantes

nos artigos catalogados por esta pesquisa;

• Investigar os impactos da arquitetura Cliente-servidor, que de

acordo com esta pesquisa vem sendo a mais amplamente

adotada, considerando as propostas catalogadas neste

estudo;

• Investigar o impacto das soluções propostas quando aplicadas

em modelos de segurança mais extremos, que prevejam, por

exemplo, a formação de conluio entre o usuário e o provedor

de nuvem;

• Avaliar se a arquitetura Proxy também não seria apropriada se

utilizada com um esquema proxy-encryption, como o utilizado

por Asghar et al. (2013).

• Levantar discussões sobre a capacidade serviços

mensuráveis, entregando informações legíveis e úteis a

negócio, considerando que os serviços de DBaaS

80

funcionariam sobre estruturas anonimizadas e dados

encriptados.

• Dentre os trabalhos catalogados, analisar os que permitem a

definição de níveis de encriptação pelo data owner com intuito

de traçar impactos de segurança e ganhos de funcionalidade.

• Analisar os estudos catalogados que suportam o modo misto,

campos em texto claro e campos encriptados, e investigar os

reais ganhos reais e os impactos na privacidade dos dados.

• Utilizar os estudos catalogados para investigar impactos do

uso de técnicas de processamento parcial de consultas sobre

dados encriptados no modelo DBaaS.

• Aprofundar as avaliações de possibilidades de utilização de

hardware para processamento criptográfico em soluções de

DBaaS. Buscar mais comparações entre abordagens que não

usam hardware e as que usam, além de investigar

possibilidades de aplicação de hardware menos custoso.

• Avaliar algoritmos candidatos a FHE que, mesmo com

limitações, possam ser empregados em domínios específicos

de banco de dados, garantida a viabilidade computacional e a

segurança.

81

Referências

ACHENBACH, D.; GABEL, M.; HUBER, M.. Mimosecco: A Middleware for

Secure Cloud Storage . In: ISPE INTERNATIONAL CONFERENCE ON

CONCURRENT ENGINEERING, 18., 2011, Boston, EUA.

ALJAFERA, Hussain et al. A brief overview and an experimental evaluation of

data confidentiality measures on the cloud. Journal Of Innovation In Digital

Ecosystems . EUA, vol.1, p. 1-11. dez. 2014.

AMAZON (EUA). Amazon RDS. 2015. Disponível em:

<http://aws.amazon.com/rds/>. Acesso em: 16 jul. 2015.

ARASU, A. et al. Orthogonal security with Cipherbase. In: BIENNIAL

CONFERENCE ON INNOVATIVE DATA SYSTEMS RESEARCH (CIDR), 6.,

2013, Asilomar, CA, EUA. Proceedings of the 6th Biennial Conference on

Innovative Data Systems Research (CIDR'13) . Asilomar: 2011.

ASGHAR, M. R. et al. Supporting Complex Queries and Access Policies for Multi-

user Encrypted Databases. In: ACM WORKSHOP ON CLOUD COMPUTING

SECURITY, 2013, Berlin, Germany. Proceedings of the 2013 ACM workshop

on Cloud computing security workshop . 2013. p. 77 - 88.

ATALLAH, Mikhail J. et al. Dynamic and Efficient Key Management for Access

Hierarchies. ACM Transactions On Information And System Security

(TISSEC). Nova York, NY, EUA, vol. 12, p. 1-43. jan. 2009.

82

MICROSOFT (EUA). Microsoft Azure - Banco de dados SQL . 2015. Disponível

em: <http://azure.microsoft.com/pt-br/services/sql-database/>. Acesso em: 16

jul. 2015.

BAJAJ, S.; SION, R.. TrustedDB: A Trusted Hardware-Based Database with

Privacy and Data Confidentiality. IEEE Transactions On Knowledge And Data

Engineering . EUA, vol. 26, p. 752-765. mar. 2014.

BAJAJ, S.; SION, R.. TrustedDB: A Trusted Hardware-Based Database with

Privacy and Data Confidentiality. In: ACM SIGMOD INTERNATIONAL

CONFERENCE ON MANAGEMENT OF DATA, 2011, Athens, Greece.

Proceedings of the 2011 ACM SIGMOD International Co nference on

Management of Data . Nova York, NY, EUA: ACM, 2011. p. 205 - 216.

BASHARAT, Iqra; AZAM, Farooque; MUZAFFAR, Abdul Wahab. Database

Security and Encryption: A Survey Study. International Journal Of Computer

Applications . Nova York, NY, EUA, vol. 47, p. 28-34. jun. 2012.

BENALOH, J.. Dense Probabilistic Encryption. In: WORKSHOP ON SELECTED

AREAS OF CRYPTOGRAPHY, 1994, Ontario, Canada. Proceedings of the

Workshop on Selected Areas of Cryptography . Ontario, Canada, 1994. p. 120

- 128.

BERENSON, Hal et al. A Critique of ANSI SQL Isolation Levels. In: ACM

SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA,

1995, San Jose, Califórnia, EUA. Proceedings of the 1995 ACM SIGMOD

International Conference on Management of Data . EUA: ACM, 1995. p. 1 - 10.

BOLDYREVA, A. et al. Orderpreserving Symmetric Encryption. In: ANNUAL

INTERNATIONAL CONFERENCE ON THE THEORY AND APPLICATIONS OF

83

CRYPTOGRAPHIC TECHNIQUES (EUROCRYPT), 28., 2009, Cologne,

Germany. Proceedings of the 28th Annual International Confer ence on the

Theory and Applications of Cryptographic Techniques (EUROCRYPT).

2009.

BONEH, D.; GOH, E.; NISSIM, K. Evaluating 2-DNF Formulas on Ciphertexts.

In: INTERNATIONAL CONFERENCE ON THEORY OF CRYPTOGRAPHY

(TCC'05), 2., 2005. Proceedings of the Second International Conference on

Theory of Cryptography . 2005. p. 325 - 341.

BRAKERSKI, Z.; VAIKUNTANATHAN, V.. Efficient Fully Homomorphic

Encryption from (Standard) LWE. In: ANNUAL SYMPOSIUM ON

FOUNDATIONS OF COMPUTER SCIENCE, 52., 2011, Palm Springs, CA, EUA.

Proceedings of the 52nd Annual Symposium on Foundat ions of Computer

Science . EUA: IEEE, 2011. p. 97 - 106.

CAO, N. et al. Privacy-preserving multi-keyword ranked search over encrypted

cloud data. IEEE Transactions On Parallel And Distributed Syste ms . EUA, p.

222-233. jan. 2014.

CHEN, Y.; SION, R.. To cloud or Not to Cloud?: Musings on Costs and Viability.

In: ACM SYMP. CLOUD COMPUTING (SOCC ’11), 2., 2011, Cascais, Portugal.

Proceedings of the Second ACM Symp. Cloud Computing (SOCC ’11). Nova

York, NY, EUA: ACM, 2011. p. 1 - 7.

CRAMPTON, J.; MARTIN, K.; WILD, P.. On key assignment for hierarchical

access control. In: IEEE WORKSHOP COMPUTER SECURITY FOUNDATIONS,

19., 2006. Proceedings of the 19th IEEE Workshop Computer Secu rity

Foundations . 2006, p. 98 - 111.

DARA, S.. Cryptography Challenges for Computational Privacy in Public Clouds.

In: IEEE INTERNATIONAL CONFERENCE ON CLOUD COMPUTING IN

84

EMERGING MARKETS (CCEM), 2., 2013, Bangalore, India. Proceedings of the

Conference on Cloud Computing in Emerging Markets ( CCEM). 2013. p.1-5.

DIFFIE, W.; HELLMAN, M. E.. New Directions in Cryptography. IEEE

Transactions On Information Theory . nov. 1976.

DINADAYALAN, P.; JEGADEESWARI, S.; GNANAMBIGAI, D.. Data Security

Issues in Cloud Environment and Solutions. In: WORLD CONGRESS ON

COMPUTING AND COMMUNICATION TECHNOLOGIES, 2014, Tiruchirappalli,

India. Proceedings of the 2014 World Congress on Computing and

Communication Technologies . CA, EUA: IEEE, 2014. p. 88 - 91.

DONG, Changyu; RUSSELLO, Giovanni; DULAY, Naranker. Shared and

Searchable Encrypted Data for Untrusted Servers. In: ANNUAL IFIP WG 11.3

WORKING CONFERENCE ON DATA AND APPLICATIONS SECURITY, 22.,

2008, London, Uk. Proceeedings of the 22Nd Annual IFIP WG 11.3 Workin g

Conference on Data and Applications Security . Berlin, Heidelberg: Springer-

verlag, 2008. p. 127 - 143.

EGOROVA, V.; CHECHULINA, D.; KRENDELEV, S. F. (2013) New View on

Block Encryption (Unpublished).

ELGAMAL, Taher. A Public Key Cryptosystem and a Signature Scheme Based

on Discrete Logarithms. Advances In Cryptology: Proceedings of CRYPTO 84 .

Berlin, p. 10-18. jan. 1985.

EUA. National Institute Of Standards And Technology (NIST). U.S Department of

Commerce. FIPS-197 - Advanced Encryption Standard (AES) . 2001.

Disponível em: <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

Acesso em: 12 jun. 2015.

85

EUA. NIST. U.S Department Of Commerce. NIST Cloud Computing Program .

EUA: NIST, 2011. 7 p. Disponível em: < http://csrc.nist.gov/publications/

nistpubs/800-145/SP800-145.pdf >. Acesso em: 17 jul. 2015.

FABBRI, S. et al. Managing literature reviews information through visualization.

In: INTERNATIONAL CONFERENCE ON ENTERPRISE INFORMATION

SYSTEMS, 14., 2012, Wroclaw, Poland. Proceedings of 14th the International

Conference on Enterprise Information Systems . Lisboa: Scitepress, 2012.

FACHIN, O.. Fundamentos de Metodologia. 5. ed. São Paulo: Saraiva, 2006.

209 p.

FERRETTI, L. et al. Security and Confidentiality Solutions for Public Cloud

Database Services. In: INTERNATIONAL CONFERENCE ON EMERGING

SECURITY INFORMATION, SYSTEMS AND TECHNOLOGIES

(SECURWARE), 7., 2013, Barcelona, Spain. Proceedings of the 7th

International Conference on Emerging Security Infor mation, Systems and

Technologies . 2013.

FERRETTI, L.; COLAJANNI, M.; MARCHETTI, M.. Distributed, Concurrent, and

Independent Access to Encrypted Cloud Databases. Parallel And Distributed

Systems: IEEE Transactions on Parallel and Distribu ted Systems . Alamitos,

CA, EUA, vol. 25, p. 437-446. fev. 2014a.

FERRETTI, L. et al. Scalable Architecture for Multi-User Encrypted SQL

Operations on Cloud Database Services. IEEE Transactions On Cloud

Computing . jun. 2014b.

FORBES (EUA). An MIT Magic Trick: Computing On Encrypted Database s

Without Ever Decrypting Them . 2011. Disponível em:

<http://www.forbes.com/sites/ andygreenberg/2011/12/19/an-mit-magic-trick-

86

computing-on-encrypted-datab ases-without-ever-decrypting-them/>. Acesso

em: 10 maio 2015.

GENTRY, C.. Fully Homomorphic Encryption Using Ideal Lattices. In: ANNUAL

ACM AYMPOSIUM ON THEORY OF COMPUTING, 41., 2009, Nova York, NY,

EUA. Proceedings of the 41st Annual ACM Aymposium on The ory of

Computing . ACM, 2009a. p. 169 - 178.

GENTRY, C.. A Fully Homomorphic Encryption Scheme. 2009. 209 f. Tese

(Doutorado) - Doutorado, Stanford, CA, EUA, 2009b. Disponível em:

<http://crypto.stanford.edu/craig/craig-thesis.pdf>. Acesso em: 17 jul. 2015.

GENTRY, Craig. Computing arbitrary functions of encrypted data.

Communications of The ACM , Nova York, NY, EUA, v. 53, n. 3, p.97-105, mar.

2010.

GENTRY, C. et al. Private Database Access With HE-over-ORAM

Architecture . 2014. Repositório não revisado - Cryptology ePrint Archive, Report

2014/345.. Disponível em: <https://eprint.iacr.org/2014/345.pdf>. Acesso em: 16

jul. 2015.

GENTRY, C.; HALEVI, S.. Fully Homomorphic Encryption Without Squashing

Using Depth-3 Arithmetic Circuits. In: IEEE SYMPOSIUM ON FOUNDATIONS

OF COMPUTER SCIENCE, 52., 2011, Palm Springs, California. Proceedings of

the 2011 IEEE 52Nd Annual Symposium on Foundations of Computer

Science . Washington, DC, EUA: IEEE Computer Society, 2011. p. 107 - 109.

GIL, Antônio Carlos. Como Elaborar Projetos de Pesquisa . 5. ed. São Paulo:

Editora Atlas, 2010. 200 p.

GOLDREICH, O.. Fundations of Cryptography . Cambridge: Cambridge

University Press, 2004. 798 p.

87

GOLDWASSER, S.; MICALI, S.. Probabilistic Encryption. Journal Of Computer

And System Sciences. v.28, p. 270-299. abr. 1984.

GOODRICH, Michael T.. Data-oblivious External-memory Algorithms for the

Compaction, Selection, and Sorting of Outsourced Data. In: ANNUAL ACM

SYMPOSIUM ON PARALLELISM IN ALGORITHMS AND ARCHITECTURES,

23., 2011, San Jose, Califórnia, EUA. Proceedings of the Twenty-third Annual

ACM Symposium on Parallelism in Algorithms and Arch itectures . Nova

York, NY, EUA: ACM, 2011. p. 379 - 388.

GOOGLE (EUA). A command line encrypting client that accesses BigQuery

service. 2014. Disponível em: <https://code.google.com/p/encrypted-bigquery-

client/>. Acesso em: 01 jul. 2015.

GREENHALGH, Trisha; PEACOCK, Richard. Effectiveness and efficiency of

search methods in systematic reviews of complex evidence: audit of primary

sources. BMJ . Londres, nov. 2005.

HACIGUMUS, H.; IYER, B.; MEHROTRA, S.. Providing Database as a Service.

In: INTERNATIONAL CONFERENCE ON DATA ENGINEERING, 18., 2002, San

Jose, CA, EUA. Proceedings of the 18th International Conference on Data

Engineering . 2002. p. 29 - 38.

HUBER, M.; HARTUNG, G.. Side Channels in Secure Database Outsourcing on

the Example of the MimoSecco Scheme. Trusted Cloud Computing . p. 35-48.

nov. 2014.

KATZ, J.; LINDELL, Y.. Introduction to Modern Cryptography . 2. ed. Chapman

e Hall, 2015. 598 p.

KESHAVARZI, A.; HAGHIGHAT, A. T.; BOHLOULI, M.. Research Challenges and

Prospective Business Impacts of Cloud Computing: A Survey. In: IEEE

88

INTERNATIONAL CONFERENCE ON INTELLIGENT DATA ACQUISITION AND

ADVANCED COMPUTING SYSTEMS: TECHNOLOGY AND APPLICATIONS,

7., 2013, Berlin, Germany. Proceedings of the 7th IEEE International

Conference on Intelligent Data Acquisition and Adva nced Computing

Systems: Technology and Applications . 2013. p. 731 - 736.

KITCHENHAM, Barbara. Procedures for Performing Systematic Reviews. Keele

University Technical Report TR/SE-0401 . Keele University, Keele, UK, p. 1-33.

jul. 2004.

KITCHENHAM, Barbara A.; BUDGEN, David; BRERETON, O. Pearl. Using

mapping studies as the basis for further research - A participant-observer case

study. Information And Software Technology . Newton, MA, EUA, p. 638-651.

jun. 2011.

Lapes. StArt - State of the Art through Systematic Review . 2015. Disponível

em: <http://lapes.dc.ufscar.br/tools/start_tool>. Acesso em: 16 jul. 2015.

LEHNER, J.; OBERWEIS, A.; SCHIEFER, G.. Data protection in the Cloud - The

MimoSecco Approach. Trusted Cloud Computing . p. 177-186. nov. 2014.

LI, Jiangtao; LI, Ninghui. OACerts: Oblivious Attribute Certificates. IEEE

Transactions On Dependable And Secure Computing . p. 340-352. dez. 2006.

LI, Jin et al. L-EncDB: A lightweight framework for privacy-preserving data queries

in cloud computing. Knowledge-based Systems . v. 79, p. 18-26. maio 2015.

LIU, Zheli et al. SQL-Based Fuzzy Query Mechanism Over Encrypted Database.

International Journal Of Data Warehousing And Minin g (IJDWM) . p. 71-87.

dez. 2014.

89

LIU, Zheli et al. Secure Storage and Fuzzy Query over Encrypted Databases. In:

INTERNATIONAL CONFERENCE (NSS), 7., 2013, Madrid, Spain. Proceedings

of the 7th International Conference . Berlin: Springer-verlag Berlin Heidelberg,

2013. p. 439 - 450.

LU, Yanbin; TSUDIK, Gene. Enhancing Data Privacy in the Cloud. In: 5TH IFIP

WG 11.11 INTERNATIONAL CONFERENCE, IFIPTM 2011, 5., 2011,

Copenhagen, Denmark. Proceedings of the 5th IFIP WG 11.11 International

Conference, IFIPTM 2011 . IFIP International Federation For Information

Processing, 07. 2011, p. 117 - 132.

MARSHALL, Christopher; BRERETON, Pearl; KITCHENHAM, Barbara. Tools to

Support Systematic Reviews in Software Engineering: A Feature Analysis. In:

INTERNATIONAL CONFERENCE ON EVALUATION AND ASSESSMENT IN

SOFTWARE ENGINEERING (EASE), 18., 2014, Londres, UK. Proceedings of

the 18th International Conference on Evaluation and Assessment in

Software Engineering . Nova York, Ny, Eua: Acm, 2014. p. 1 - 10.

MARCONI, Maria de Andrade; LAKATOS, Eva Maria. Fundamentos de

Metodologia Científica. 7. ed. São Paulo: Atlas, 2010. 320 p.

MEHAK, Faria et al. Security Aspects of Database-as-a-Service (DBaaS) in

Cloud Computing. Cloud Computing - Challenges, Limitations And R&d

Solutions . Switzerland, p. 297-324. out. 2014.

MICCIANCIO, Daniele. A First Glimpse of Cryptography's Holy Grail.

Communications Of The Acm, Nova York, NY, EUA, v. 53, n. 3, p.96-96, mar.

2010.

MIMOSECCO (Alemanha). MimoSecco - Middleware for Mobile and Secure

Cloud Computing . 2015. Disponível em: <www.mimosecco.de>. Acesso em: 12

jul. 2015.

90

NAEHRIG, Michael; LAUTER, Kristin; VAIKUNTANATHAN, Vinod. Can

homomorphic encryption be practical? In: ACM WORKSHOP ON CLOUD

COMPUTING SECURITY WORKSHOP, 3., 2011, Chicago, EUA. Proceedings

of the 3rd ACM workshop on Cloud computing security workshop . Nova

York, NY, EUA: ACM, 2011. p. 113 - 124.

ORACLE (EUA). Oracle Cloud Database . 2015. Disponível em:

<https://cloud.oracle.com/database>. Acesso em: 17 jul. 2015.

PAILLIER, Pascal. Public-key cryptosystems based on composite degree

residuosity classes. In: INTERNATIONAL CONFERENCE ON THEORY AND

APPLICATION OF CRYPTOGRAPHIC TECHNIQUES, 17., 1999, Prague,

República Checa. Proceedings of the 17th International Conference on

Theory and Application of Cryptographic Techniques . Berlin, Heidelberg:

Springer-verlag, 1999. p. 223 - 238.

PAPPAS, Vasilis et al. Blind Seer: A Scalable Private DBMS. In: IEEE

SYMPOSIUM ON SECURITY AND PRIVACY, 14., 2014, Fairmont, San Jose,

Ca. Proceedings of the 2014 IEEE Symposium on Security and Privacy .

Washington, DC, EUA: IEEE Computer Society, 2014. p. 359 - 374.

PARKHILL, Douglas F.. The Challenge of The Computer Utility. Reino Unido:

Addison-wesley Publishing Company, 1966.

POPA, Raluca Ada et al. CryptDB : MIT CSAIL Computer Systems Security

Group. 2014. Disponível em: <https://css.csail.mit.edu/cryptdb/>. Acesso em: 16

jul. 2015.

POPA, Raluca Ada et al. CryptDB: Processing Queries on an Encrypted

Database. Communications of the ACM . Nova York, NY, EUA, set. 2012. p.

103-111.

91

POPA, Raluca Ada et al. CryptDB: Protecting Confidentiality with Encrypted

Query Processing. In: TWENTY-THIRD ACM SYMPOSIUM ON OPERATING

SYSTEMS PRINCIPLES, 23, 2011, Cascais. Proceedings of the Twenty-Third

ACM Symposium on Operating Systems Principles . Cascais, Portugal: Acm,

2011. p. 85 - 100.

POPA, Raluca Ada et al. Building web applications on top of encrypted data using

Mylar. In: CONFERENCE ON NETWORKED SYSTEMS DESIGN AND

IMPLEMENTATION (USENIX), 11., 2014, Seattle, WA, EUA. Proceedings of the

11th USENIX Conference on Networked Systems Design and

Implementation . 2014. p. 157 - 172.

RABIN, Michel O.. Digitalized Signatures and Public-Key Functions as

Intractable as Factorization . MIT-LCS-TR-212. ed. Massachusetts Institute Of

Technology, 1979. 20 p. Disponível em: <http://publications.csail.mit.edu/lcs

/pubs/pdf/MIT-LCS-TR-212.pdf>. Acesso em: 17 jul. 2015.

RIMAL, B.p.; CHOI, Eunmi; LUMB, I.. A Taxonomy and Survey of Cloud

Computing Systems. In: INC, IMS AND IDC, 2009. NCM '09. INTERNATIONAL

CONFERENCE ON JOINT, 5., 2009, Seul, Coreia do Sul. Proceedings of the

INC, IMS and IDC, 2009. NCM '09 . International Conference on Joint. EUA:

IEEE, 2009. p. 44 - 51.

RIVEST, R.l.; SHAMIR, A.; ADLEMAN, L.. A method for obtaining digital

signatures and public-key cryptosystems. Communications of the ACM , Nova

York, NY, EUA, v. 21, n. 2, p.120-126, fev. 1978. Disponível em: <

http://people.csail. mit.edu/rivest/publications.html>. Acesso em: 17 jul. 2015.

RIVEST, R.; ADLEMAN, L.; DERTOUZOS, M.. On Data Banks and Privacy

Homomorphism. In: FOUNDATIONS OF SECURE COMPUTATION, 1978, Nova

York. Proceedings of the Foundations of Secure Computatio n. Nova York,

92

NY, EUA: Academic Press, 1978. p. 169 - 180. Disponível em: <

http://people.csail. mit.edu/rivest/publications.html>. Acesso em: 17 jul. 2015.

SALSOFT PAWEL SALAWA. SQLite Studio. 2015. Disponível em:

<http://sqlitestudio.pl/>. Acesso em: 17 jul. 2015.

SARFRAZ, M. I. et al. DBMask: Fine-Grained Access Control on Encrypted

Relational Databases. In: ACM CONFERENCE ON DATA AND APPLICATION

SECURITY AND PRIVACY (CODASPY), 5., 2015, San Antonio, TX, EUA.

Proceedings of the 5th ACM Conference on Data and A pplication Security

and Privacy - CODASPY’15 . 2015. p. 1 - 11.

SHAHZAD, Farrukh. State-of-the-art Survey on Cloud Computing Security

Challenges, Approaches and Solutions. In: INTERNATIONAL CONFERENCE

ON EMERGING UBIQUITOUS SYSTEMS AND PERVASIVE NETWORKS

(EUSPN), 5., 2014, Halifax, Nova Scotia, Canada. Proceedings of the The 5th

International Conference on Emerging Ubiquitous Sys tems and Pervasive

Networks (EUSPN-2014) . Amesterdã: Elsevier B.v., 2014. p. 357 - 362.

SCHNEIER, Bruce. Description of a New Variable-Length Key, 64-Bit Block

Cipher (Blowfish). In: FAST SOFTWARE ENCRYPTION: CAMBRIDGE

SECURITY WORKSHOP, 1993, Cambridge, U.k.. Proceedings of the Fast

Software Encryption: Cambridge Security Workshop . Berlin: Springer-verlag,

1994. p. 191 - 204. Disponível em < https://www.schneier.com/paper-blowfish-

fse.html>. Acesso em: 10 de junho de 2015.

SHANKARWAR, Mahesh U.; PAWAR, Ambika V.. Security and Privacy in Cloud

Computing: A Survey. In: INTERNATIONAL CONFERENCE ON FRONTIERS OF

INTELLIGENT COMPUTING, 3., 2014, Bhubaneswar, Odisha, India.

Proceedings of the 3rd International Conference on Frontiers of Intelligent

Computing: Theory and Applications (FICTA) 2014 . v. 2, Springer, 2014.

93

SHATILOV, K. et al. Solution for Secure Private Data Storage in a Cloud. In:

FEDERATED CONFERENCE ON COMPUTER SCIENCE AND INFORMATION

SYSTEMS (FEDCSIS), 2014. Proceedings of the Federated Conference on

Computer Science and Information Systems (FedCSIS) . IEEE, 2014. p. 885 -

889.

SILVA, Edna Lucia da; MENEZES, Estera Muszkat. Metodologia da Pesquisa

e Elaboração de Dissertação . 4. ed. Florianópolis: UFSC, 2005. 139 p.

Disponível em: <https://projetos.inf.ufsc.br/arquivos/Metodologia_de_pesquisa

_e_elaboracao_de_teses_e_dissertacoes_4ed.pdf>. Acesso em: 12 jul. 2015.

SMART, N. P.; VERCAUTEREN, F.. Fully Homomorphic Encryption with

Relatively Small Key and Ciphertext Sizes. In: INTERNATIONAL CONFERENCE

ON PRACTICE AND THEORY IN PUBLIC KEY CRYPTOGRAPHY (PKC), 13.,

2010, Paris, France. Proceedings of the 13th International Conference on

Practice and Theory in Public Key Cryptography . Berlin: Springer-verlag,

2010. p. 420 - 443.

SONG, Dawn Xiaoding; WAGNER, D.; PERRIG, A.. Practical techniques for

searches on encrypted data. In: IEEE SYMPOSIUM ON SECURITY AND

PRIVACY, 21., 2000, Oakland, Ca. IEEE Symposium on Security and Privacy,

2000. S&P 2000. Proceedings .IEEE, 2000. p. 44 - 55.

STEPHEN, J. J. et al. Program Analysis for Secure Big Data Processing. In:

IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE

ENGINEERING, 29., 2014, Vasteras, Suécia. Proceedings of the IEEE/ACM

International Conference on Automated Software Engi neering, 2014 . Nova

York, NY, EUA: Acm, 2014. p. 277 - 288.

SUBASHINI, S.; KAVITHA, V.. A survey on Security Issues in Service Delivery

Models of Cloudcomputing. Journal Of Network And Computer Applications. p.

1-11. jan. 2011.

94

TOPLE, Shruti et al. AutoCrypt - Enabling Homomorphic Computation on Servers

to Protect Sensitive Web Content. In: ACM SIGSAC CONFERENCE ON

COMPUTER & COMMUNICATIONS SECURITY, 2013, Berlin, Germany.

Proceedings of the 2013 ACM SIGSAC conference on Co mputer &

communications security . Nova York, NY, EUA: Acm, 2013. p. 1297 - 1310.

TROMBETTA, Alberto; PERSIANO, Giuseppe; BRAGHIN, Stefano. Processing

Private Queries over an Obfuscated Database Using Hidden Vector Encryption.

In: NORDIC CONFERENCE (NORDSEC), 19., 2014, Tromso, Noruega.

Proceedings of the 19th Nordic Conference, NordSec 2014. Suíça: Springer

International Publishing, 2014. p. 94 - 109.

TU, Stephen et al. Processing analytical queries over encrypted data. In:

INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 39., 2013,

Trento, Italy. Proceedings of the 39th international conference on Very Large

Data Bases . VLDB Endowment, 2013. p. 289 - 300.

VIMERCATI, Sabrina de Capitani di et al. Over-encryption: Management of

Access Control Evolution on Outsourced Data. In: INTERNATIONAL

CONFERENCE ON VERY LARGE DATA BASES, 33., 2007, Vienna, Austria.

Proceedings of the 33rd International Conference on Very Large Data

Bases . VLDB Endowment, 2007. p. 123 - 134.

WANG, Shiyuan; AGRAWAL, Divyakant; ABBADI, Amr El. A Comprehensive

Framework for Secure Query Processing on Relational Data in the Cloud. In:

VLDB INTERNATIONAL CONFERENCE ON SECURE DATA MANAGEMENT,

8., 2011, Seattle, Wa, Eua. Proceedings of the 8th VLDB International

Conference on Secure Data Management . Berlin, Heidelberg: Springer-verlag,

2011. p. 52 - 69.

WAZLAWICK, R. S.. Metodologia de Pesquisa para Ciência da Computação .

Rio de Janeiro: Elsevier, 2009. 159 p. (6).

95

WONG, Wai Kit et al. Secure Query Processing with Data Interoperability in a

Cloud Database Environment. In: ACM SIGMOD INTERNATIONAL

CONFERENCE ON MANAGEMENT OF DATA, 2014, Snowbird, Utah, EUA.

Proceedings of the 2014 ACM SIGMOD International Co nference on

Management of Data . Nova York, NY, EUA: ACM, 2014. p. 1395 - 1406.

ZHANG, Qi; CHENG, Lu; BOUTABA, Raouf. Cloud Computing: State-of-the-art

and Research Challenges. Journal Of Internet Services And Applications .

Berlin, Heidelberg, v. 1, p. 7-18. maio 2010.

ZHIROV, Alexander; ZHIROVA, Olga; KRENDELEV, Sergey F.. Practical Fully

Homomorphic Encryption over Polynomial Quotient Rings. In: WORLD

CONGRESS ON INTERNET SECURITY, 2013, London, United Kingdom.

Proceedings of the World Con gress on Internet Secu rity (WorldCIS-2013) .

IEEE, 2013. p. 70 - 75.

96

APÊNDICE

A

A. Protocolo do Mapeamento

Sistemático

Esta seção descreve os detalhes do protocolo definido na fase de

planejamento do mapeamento sistemático.

97

Protocolo de Mapeamento Sistemático

A.1 – Descrição do Problema

O armazenamento de dados em sistemas gerenciadores de banco de

dados para Database-as-a-service garantindo privacidade e sigilo (DBaaS)

desafia pesquisadores. É esperado que a arquitetura utilizada não permita que

os dados em texto claro não sejam acessados indevidamente, mesmo por quem

os administra.

A.2 - Objetivo

Este protocolo deve nortear a execução de um mapeamento sistemático.

Ao final do mapeamento deve ser apresentado um catálogo de estudos sobre

bancos de dados encriptados para DBaaS.

A.3 - Pergunta de Pesquisa

A pergunta de pesquisa deve guiar a execução do mapeamento

sistemático, cujo resultado é a base para atendimer aos objetivos do trabalho.

A.3.1 - Foco da pergunta de pesquisa

Identificar estudos que apresentem abordagens de modelos de soluções

baseadas em criptografia que utilizem sistemas gerenciadores de banco de

dados, de forma a permitir sua caracterização e comparação com o modelo

baseado em Proxy implementado no CryptDB.

A.3.2 - Qualidade e Amplitude da pergunta

Com intuito de garantir a qualidade e delimitar a amplitude da pergunta de

pesquisa, os estudos com os modelos propostos devem (i) ter uma arquitetura

98

bem definida para o modelo, (ii) contar com experimentos que permitam a sua

avaliação e (iii) descrever as abordagens de avaliação do modelo.

A.3.3 - Pergunta de Pesquisa

A pergunta de pesquisa utilizada neste protocolo coincide, por uma

consequência natural, com a questão de pesquisa principal da dissertação, em

seguida replicada:

Q.1) 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?

A.3.3.1- Intervenção

Haverá intervenção sobre as propostas de modelos de armazenamento

de dados em sistemas gerenciadores de banco de dados baseados em

criptografia.

A.3.3.2 - População

A população de estudos que este mapeamento busca abranger são

aqueles que tratem de armazenamento de dados com garantias de privacidade.

A.3.3.3 - Estudos de controle (base inicial)

Inexiste base inicial ou de controle de posse do pesquisador.

A.4 - Palavras-chave

As palavras-chave foram selecionadas por estarem ligadas a pergunta de

99

pesquisa e espera-se que com elas os resultados das fontes de pesquisa

possam cobrir a população desejada para o mapeamento sistemático.

As palavras-chave, além da ligação com a pergunta de pesquisa, seguem

critérios de relação e classificação entre elas. O grupo das doze primeiras

palavras-chave tratam de esquemas criptográficos podem ser utilizados para

implementação das soluções buscadas. As três seguintes descrevem

tecnologias e conceitos. Enquanto as últimas descrevem princípios que devem

ser seguidos por qualquer solução proposta. Palavras-chave consideradas:

“public key encryption”, “public key cryptographic”,

“symmetric homomorphic encryption”, “symmetric

homomorphic cryptographic”, “somewhat homomorphic

encryption”, “somewhat homomorphic cryptographic”,

“partially homomorphic encryption”, “partially

homomorphic cryptographic”, “fully homomorphic

encryption”, “fully homomorphic cryptographic”, “cryptdb”,

“cloud storage”, “encrypted storage”, “privacy-preserving”,

“privacy”, “confidentiality”, “encrypted”.

A.5 - Critérios para Seleção de Fontes

As fontes de pesquisa para execução do protocolo de levantamento

sistemático devem atender aos critérios de: (i) possuir opção de consulta por

palavras chave, (ii) disponibilidade de download de artigos por meio de página

na Internet e (iii) importância e relevância da fonte (Kitchenham 2007).

A.5.1 - Fontes Escolhidas

As seguintes fontes foram selecionadas para este mapeamento, de

acordo com os critérios definidos na seção anterior: ACM Digital Library,

100

SpringerLink, IEEE Xplore Digital Library, Science Direct, Scopus, CiteSeerX e

Engineering Village.

A.6 - Seleção de estudos primários: inclusão/exclus ão dos artigos e

procedimentos

Todos os resultados encontrados devem se submeter aos seguintes

critérios de inclusão e exclusão. Estes critérios devem ser revistos em cada fase,

em qualquer estágio que o estudo é avaliado:

A.6.1 - Critérios de exclusão

Os artigos não devem se enquadrar nos critérios abaixo:

• E01: O estudo não está em formato eletrônico;

• E02: O estudo não está livremente disponível na web;

• E03: O idioma do estudo não é o inglês;

• E04: O estudo não responde à pergunta de pesquisa;

• E05: O estudo é repetido: se o artigo está disponível em duas fontes,

apenas a primeira incidência será considerada;

• E06: O estudo é duplicado: se dois estudos apresentam conteúdo similar,

apenas o último e/ou o mais completo será considerado;

• E07: O estudo não foi revisado ou não é completo: relatório técnico,

sumário estendido, apresentação ou livro;

• E08: O resultado não é um estudo, mas conteúdo irrelevante (índice,

folder, chamadas para eventos, etc.).

A.6.2 - Critérios de inclusão

Os artigos devem se enquadrar nos seguintes critérios:

101

• I01: O artigo deve propor um modelo de arquitetura que envolva um

sistema gerenciador de banco de dados baseado em criptografia sob o

modelo DBaaS;

• I02: O artigo deve indicar que o modelo já foi implementado em uma

ferramenta que permitiu a experimentação, execução e avaliação do

modelo proposto;

• I03: O artigo deve descrever o modelo de ferramenta proposto trazendo

avaliações sobre sua aplicabilidade e capacidade de assegurar a

privacidade dos dados.

A.6.3 - Procedimentos

Como definido por Kitchenham (2004), baseia-se em um processo multi-

estágio, com duas etapas. Na primeira etapa os critérios de inclusão e exclusão

devem ser aplicados na leitura e análise do título, abstract e palavras-chave de

cada um dos artigos. A lista dos artigos não excluídos na primeira etapa seguem

para a segunda etapa da seleção. Um artigo só pode ser analisado na segunda

etapa se contar com seu texto completo disponível para leitura.

A segunda etapa, que precede o estágio de extração, contempla

obrigatoriamente a leitura da introdução e conclusão de cada um dos artigos

remanescentes da primeira etapa pelo pesquisador e por um auxiliar, que deve

ser previamente orientado pelo pesquisador sobre os objetivos da pesquisa e os

critérios de exclusão e inclusão de artigos. As impressões de cada um são

discutidas em conjunto e os critérios de inclusão e exclusão são novamente

aplicados. Em caso de dúvidas, o texto completo pode ser usado.

Ainda na segunda etapa, ao final da decisão sobre a inclusão ou exclusão

de cada artigo, a lista de referências deve ser verificada pelo pesquisador e o

auxiliar. Se um artigo claramente interessante for encontrado, ele será

adicionado ao final da lista de artigos que estão sendo avaliados. Esta técnica,

baseada em snowball, só será aplicada até este nível, portanto as referências

102

deste último artigo não serão analisadas. O resultado desta segunda etapa de

seleção são os estudos primários selecionados.

Todas as decisões sobre inclusão e exclusão de arquivos devem ter o

registro de seus motivos, de forma que permita uma posterior conferência.

A.7 - Estratégia de Busca de Informação

A estratégia de busca precisa ser bem definida, pois depende dela o

alcance a uma população satisfatória de estudos, tanto em quantidade, mas

também em consonância com as repostas que se busca para a pergunta de

pesquisa.

É o rigor que difere um mapeamento sistemático de uma revisão

bibliográfica tradicional (KITCHENHAM, 2004). Para este protocolo, depois de

testes e ajustes, foram definidas as seguintes estratégias de buscas, já

atualizadas com os dados da execução:

A.7.1 – Fonte ACM Digital Library

String de Busca

Fonte: ACM Digital Library

Data da busca: 15/05/2015

Limitação de período: Sem limitação

URL: http://dl.acm.org/advsearch.cfm?coll=DL&dl=ACM&query=&qrycnt=391109&since_month=&since_year=&before_month=&before_year=

Pesquisador: Marcelo Ferreira de Lima Observações: Nenhuma. String para busca: ( ("public key" OR "symmetric homomorphic" OR "somewhat

homomorphic" OR "partially homomorphic" OR "fully homomorphic")AND("encryption" OR "cryptographic")) AND ("cryptdb" OR "cloud storage" OR "encrypted storage") AND ("privacy-preserving" OR "privacy" OR "confidentiality") AND ((("Abstract":"privacy") OR ("Abstract":"encrypted")) OR (("Title":"privacy") OR ("Title":"encrypted")) OR (("Keywords":"privacy") OR ("Keywords":"encrypted")))

Resultados: 114 itens retornados.

103

A.7.2 – Fonte SpringerLink

String de Busca Fonte: SpringerLink



URL: http://link.springer.com Pesquisador: Marcelo Ferreira de Lima Observações: • O mecanismo não distingue campos específicos para a

busca (ex.: abstract, title, keywords, etc.). String para busca: (("public key" OR "symmetric homomorphic" OR "somewhat

homomorphic" OR "partially homomorphic" OR "fully homomorphic") AND ("encryption" OR "cryptographic")) AND ("cryptdb" OR "cloud storage" OR "encrypted storage") AND ("privacy-preserving" OR "confidentiality") AND ("privacy" OR "encrypted")


A.7.3 – Fonte IEEE Xplore Digital Library

String de Busca Fonte: IEEE Xplore Digital Library



URL: http://ieeexplore.ieee.org/search/advsearch.jsp?expression-builder

Pesquisador: Marcelo Ferreira de Lima Observações: • Visando amplitude, a opção “Full Text & Metadata” foi

marcada. • O mecanismo de busca é limitado em 40 palavras.

Portanto, é necessária a execução da string por 3 vezes (alternando apenas as expressões em destaque ao final) e a eliminação de resultados repetidos dentro desta mesma fonte.

String para busca: (("public key" OR "symmetric homomorphic" OR "somewhat homomorphic" OR "partially homomorphic" OR "fully homomorphic") AND ("encryption" OR "cryptographic")) AND ("cryptdb" OR "cloud storage" OR "encrypted storage") AND ("privacy-preserving" OR "privacy" OR "confidentiality") AND -------------------------------------------------------------------------(("Abstract":"privacy") OR ("Abstract":"encrypted")) ------------------------------------------------------------------------(("Title":"privacy") OR ("Title":"encrypted")) -------------------------------------------------------------------------(("Keywords":"privacy") OR ("Keywords":"encrypted"))

Resultados: 257 itens retornados, 15 itens retornados e 277 itens retornados por cada consulta. 376 depois de eliminadas as repetições entre as consultas.

104

A.7.4 – Fonte Science Direct

String de Busca Fonte: Science Direct



URL: http://www.sciencedirect.com/science?_ob=MiamiSearchURL&_method=requestForm&_temp=all_boolSearch.tmpl&md5=052b06d957a9d8c82e07acf1d7eef1b7

Pesquisador: Marcelo Ferreira de Lima Observações: Nenhuma. String para busca: (("public key" OR "symmetric homomorphic" OR "somewhat

homomorphic" OR "partially homomorphic" OR "fully homomorphic") AND ("encryption" OR "cryptographic")) AND ("cryptdb" OR "cloud storage" OR "encrypted storage") AND ("privacy-preserving" OR "privacy" OR "confidentiality") AND ((("Abstract":"privacy") OR ("Abstract":"encrypted")) OR (("Title":"privacy") OR ("Title":"encrypted")) OR (("Keywords":"privacy") OR ("Keywords":"encrypted")))


A.7.5 – Fonte Scopus

String de Busca Fonte: Scopus



URL: http://www.scopus.com/search/form.url?display=advanced&clear=t&origin=searchbasic&txGid=44037053C4BDA6B7885329D1FEA2852F.mw4ft95QGjz1tIFG9A1uw%3a2

Pesquisador: Marcelo Ferreira de Lima Observações: Nenhuma. String para busca: (("public key" OR "symmetric homomorphic" OR "somewhat

homomorphic" OR "partially homomorphic" OR "fully homomorphic") AND ("encryption" OR "cryptographic")) AND ("cryptdb" OR "cloud storage" OR "encrypted storage") AND ("privacy-preserving" OR "privacy" OR "confidentiality") AND (TITLE-ABS-KEY("privacy") OR TITLE-ABS-KEY("encrypted"))


A.7.6 – Fonte CiteSeerX

String de Busca Fonte: CiteSeerX



URL: http://citeseerx.ist.psu.edu/index Pesquisador: Marcelo Ferreira de Lima Observações: Nenhuma. String para busca: (("public key" OR "symmetric homomorphic" OR "somewhat

homomorphic" OR "partially homomorphic" OR "fully homomorphic") AND ("encryption" OR "cryptographic")) AND ("cryptdb" OR "cloud storage" OR "encrypted storage") AND ("privacy-preserving" OR "privacy" OR "confidentiality") AND ((abstract:("privacy") OR abstract:("encrypted")) OR (title:("privacy") OR title:("encrypted")) OR (keyword:("privacy") OR keyword:("encrypted")))


105

A.7.7 – Engineering Village

String de Busca

Fonte: Engineering Village



URL: http://www.engineeringvillage.com/search/expert.url? CID=expertsearch

Pesquisador: Marcelo Ferreira de Lima Observações: Nenhuma. String para busca: ((("public key" OR "symmetric homomorphic" OR "somewhat

homomorphic" OR "partially homomorphic" OR "fully homomorphic")AND("encryption" OR "cryptographic")) wn ALL) AND (("cryptdb" OR "cloud storage" OR "encrypted storage") wn ALL) AND (("privacy-preserving" OR "privacy" OR "confidentiality") wn ALL) AND ((("privacy") wn KY) OR (("encrypted") wn KY))


A.8 – Extração de Dados

Para a execução do estágio de extração de dados sobre os estudos primários selecionados é preciso projetar previamente o formulário de extração. Isto é uma estratégia para evitar os vieses, mais prováveis se o formulário é criado ao longo da execução da extração (KITCHENHAM; BUDGEN; BRERETON, 2011). A criação e alterações e neste formulário devem ser discutidos entre o pesquisador e o auxiliar. Os seguintes tópicos constam no formulário desta pesquisa:

SQ Item do formulário Descrição/Interesse

1 Nome da Solução Nome dado a solução pelos autores ou citação, no caso de não haver um nome.

2 Ano Ano da publicação do estudo.

3 Quantidade de autores? Número de autores.

4 Instituição de vínculo dos autores? Lista de instituições às quais os autores aparecem vinculados.

5 Referencia o CryptDB no trabalho? O estudo cita o trabalho que publicou o CryptDB. (S/N)

6 Permite interferência no nível de criptografia?

Permite que o usuário ou DBA defina a criptografia a ser utilizada em cada campo, não fazendo apenas de forma automática. (S/N)

106


7 Apresenta suporte ao armazenamento de valores em texto claro?

Permite que campos em texto claro sejam armazenados em conjunto com campos encriptados. Não encripta necessariamente todos os campos. (S/N)

8 Existe processamento de consulta a dados encriptados no cliente?

Processa consultas completas ou resultados pré-processados no cliente. (S/N)

9 Usa encriptação em camadas ("cebola" ou com múltiplos campos)?

Usa uma das duas ou as duas estratégias: encripta múltiplas vezes valores no mesmo campo e/ou armazena em mais de um campo encriptado um campo em texto claro. (S/N)

10 É composto de um DBMS não modificado? Baseia-se em um DBMS de uso difundido, sem alterações no código fonte, podendo simplesmente ser usado como é. (S/N)

11 É baseado em hardware? Precisa de um hardware para funcionar com todo o seu potencial. (S/N)

12 Prevê repartição dos dados e/ou índices em locais diferentes?

É adotada alguma estratégia que utiliza: dados e/ou índices de alguma forma distribuída. (S/N)

13 Síntese do modelo de segurança previsto Descrição textual do modelo de segurança previsto (entidades confiáveis, não confiáveis, conluios, situações específicas, uso de dispositivos, etc.)

14 Proxy em ambiente confiável? Campo derivado do anterior.

15 Esquemas, sistemas ou algoritmos criptográficos que se baseia?

Lista de esquemas, sistemas ou algoritmos criptográficos (ex.: OPE, FPE, proxy-encryption, etc.)

16 Utiliza PHE? Utiliza encriptação parcialmente homomórfica. (S/N)

17 Utiliza FHE? Utiliza encriptação completamente homomórfica. (S/N)

18 Arquitetura Identificada Descrição da arquitetura identificada.

107


19 Apenas data onwer/DBA carrega e altera dados encriptados no DBMS?

Alterações na base só podem ser realizadas pelo data owner ou DBA. Usuários ficam restritos às consultas. (S/N)

20 Quais vantagens explicitamente apontadas do modelo Proxy?

Descrição textual das vantagens sobre o modelo de arquitetura Proxy explicitamente apontadas no estudo.

21 Quais desvantagens explicitamente apontadas do modelo Proxy?

Descrição textual das desvantagens sobre o modelo de arquitetura Proxy explicitamente apontadas no estudo.

A.9 – Avaliação de Qualidade

Embora não seja considerado essencial ou relevante, para um

mapeamento sistemático (KITCHENHAM; BUDGEN; BRERETON, 2011), o

protocolo definido para este trabalho utiliza um conjunto de perguntas de

avaliação de qualidade, que devem ser aplicadas a cada um dos estudos

selecionados. A motivação para inclusão de critérios de avaliação de qualidade

na presente pesquisa se limita a um subconjunto de objetivos simplificados

definidos por Kitchenham, Budgen e Brereton (2011) para revisões sistemáticas.

Portanto, os objetivos dos critérios de avaliação de qualidade para esta pesquisa

são:

• Como um meio de ponderar a importância de cada estudo;

• Para basear orientações em futuras pesquisas.

A.9.1 – Perguntas Gerais de Avaliação de Qualidade

Estas perguntas gerais não têm relação direta e específica com a

pergunta de pesquisa. Poderiam, em boa medida, balizar qualidade para

diferentes tipos de pesquisa, pois verificam características esperadas na maioria

dos trabalhos:

108

• AQ01 - O estudo indica claramente sua relevância/contribuição?

• AQ02 - Os objetivos do estudo são claramente definidos?

• AQ03 - O estudo apresenta detalhes, profundidade e riqueza de

informações?

• AQ04 - O estudo levanta questões para trabalhos futuros?

A.9.2 – Perguntas Específicas de Avaliação de Quali dade

Esta pergunta tem relação direta e específica com a pergunta de pesquisa:

• AQ05 - O estudo define claramente qual a arquitetura utilizada em sua

solução?

Referências do Protocolo de Mapeamento Sistemático

Kitchenham, B. (2004) Procedures for performing systematic reviews . Keele,

UK, Keele University, v. 33.

Kitchenham, B.; Budgen, D. (2007) Using mapping studies as the basis for

further research - A participant-observer case stud y. Information & Software

Tecnology 53(6): 638-651.

POPA, Raluca Ada et al. CryptDB: Protecting Confidentiality with Encrypted

Query Processing. In: TWENTY-THIRD ACM SYMPOSIUM ON OPERATING

SYSTEMS PRINCIPLES, 23, 2011, Cascais. Proceedings of the Twenty-Third

ACM Symposium on Operating Systems Principles. Cascais, Portugal: Acm,

2011. p. 85 - 100.

109

APÊNDICE

B

B. Estudos excluídos na segunda

etapa da seleção

Reporta uma lista que identifica todos os estudos excluídos na segunda

etapa do estágio de seleção.

110

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

SQ ID Ano Fonte Título

1 97 2012 ACM A Security Aware Stream Data Processing Scheme on the Cloud and Its Efficient Execution Methods

2 37 2014 ACM Building Web Applications on Top of Encrypted Data Using Mylar

3 40 2013 ACM DEMO: Adjustably encrypted in-memory column-store

4 28 2012 ACM DJoin: Differentially Private Join Queries over Distributed Databases

5 7 2014 ACM Improved Anonymous Proxy Re-encryption with CCA Security

6 1 2014 ACM Optimized and Controlled Provisioning of Encrypted Outsourced Data

7 39 2012 ACM Protecting Data Confidentiality in Cloud Systems

8 29 2013 ACM Searching over Encrypted Data in Cloud Systems

9 18449 2009 CiteSeerX Mixed Encryption over Semi-Trusted Database

10 18503 2013 CiteSeerX Multi Tenant Data Storage Security In Cloud Using Data Partition Encryption Technique

11 18435 2007 CiteSeerX Providing Data Sharing As a Service

12 18533 2009 CiteSeerX The Blind Stone Tablet: Outsourcing Durability to Untrusted Parties

13 18473 2008 CiteSeerX Towards Secure Data Outsourcing

14 259 2009 IEEE A Novel Framework for Database Security Based on Mixed Cryptography

15 163 2013 IEEE A novel framework to prevent privacy breach in cloud data storage area service

16 305 2012 IEEE A searchable encryption scheme for outsourcing cloud storage

17 366 2012 IEEE Efficient Query Processing on Outsourced Encrypted Data in Cloud with Privacy Preservation

18 205 2014 IEEE Performance and Cost Evaluation of an Adaptive Encryption Architecture for Cloud Databases

19 122 2013 IEEE Secure and privacy-preserving database services in the cloud

20 145 2013 IEEE Symmetrically-Private Database Search in Cloud Computing

111

SQ ID Ano Fonte Título

21 372 2012 IEEE Usable, Secure, Private Search

22 545 2015 Science Direct

A novel policy-driven reversible anonymisation scheme for XML-based services

23 4507 2012 Scopus DEMO: Query encrypted databases practically

24 4271 2014 Scopus Model of an encrypted cloud relational database supporting complex predicates in WHERE clause

25 4209 2015 Scopus New construction of secure range query on encrypted data in cloud computing

26 4463 2013 Scopus Nonlinear order preserving index for encrypted database query in service cloud environments

27 4242 2014 Scopus Privacy-preserving complex query evaluation over semantically secure encrypted data

28 4334 2014 Scopus Randomly partitioned encryption for cloud databases

29 4474 2013 Scopus Secure cloud transactions

30 4421 2013 Scopus Secure storage and fuzzy query over encrypted databases

31 10562 2013 Springer Cloud-Specific Services for Data Management

32 10598 2009 Springer Encryption over Semi-trusted Database

33 10620 2014 Springer Framework for Efficient Search and Statistics Computation on Encrypted Cloud Data

34 10565 2004 Springer Performance-Conscious Key Management in Encrypted Databases

35 10546 2011 Springer PKIS: practical keyword index search on cloud datacenter

36 10446 2014 Springer Practical and Privacy-Preserving Policy Compliance for Outsourced Data

37 10634 2013 Springer Practical Immutable Signature Bouquets (PISB) for Authentication and Integrity in Outsourced Databases

38 10474 2014 Springer Preserving Database Privacy in Cloud Computing

39 10606 2014 Springer Side Channels in Secure Database Outsourcing on the Example of the MimoSecco Scheme

40 10499 2010 Springer Structured Encryption and Controlled Disclosure

112

APÊNDICE

C

C. Relação de estudos catalogados

Reporta a lista com dados de todos os estudos catalogados ao final da

pesquisa.

113

C.1 Lista de Estudos Catalogados

Os estudos primários do catálogo estão categorizados na lista por

modelo de arquitetura utilizado e ordenados por ano e título do estudo.

SQ ID Ano Arquitetura Título

1 04553 2011 Proxy A Comprehensive Framework for Secure Query Processing on Relational Data in the Cloud

2 00009 2011 Proxy CryptDB: Protecting Confidentiality with Encrypted Query Processing

3 381974 2011 Proxy MimoSecco: A Middleware for Secure Cloud Storage

4 00005 2014 Proxy Secure Query Processing with Data Interoperability in a Cloud Database Environment

5 18558 2013 Cliente-servidor Orthogonal Security with Cipherbase

6 00081 2013 Cliente-servidor Processing Analytical Queries over Encrypted Data

7 04398 2013 Cliente-servidor Security and Confidentiality Solutions for Public Cloud Database Services

8 00204 2014 Cliente-servidor Distributed, Concurrent, and Independent Access to Encrypted Cloud Databases

9 04307 2014 Cliente-servidor Scalable Architecture for Multi-User Encrypted SQL Operations on Cloud Database Services

10 04352 2014 Cliente-servidor Solution for Secure Private Data Storage in a Cloud

11 00142 2014 Cliente-servidor TrustedDB: A Trusted Hardware-Based Database with Privacy and Data Confidentiality

12 00501 2015 Cliente-servidor L-EncDB: A Lightweight Framework for Privacy-preserving data Queries in Cloud Computing

13 10506 2011 Cliente-servidor descentralizada

Enhancing Data Privacy in the Cloud

14 00057 2013 Cliente-servidor descentralizada

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

15 04346 2014 Cliente-servidor descentralizada Blind Seer: A scalable private DBMS

114

SQ ID Ano Arquitetura Título

16 04311 2014 Proxy e Cliente-servidor descent.

Processing private queries over an obfuscated database using hidden vector encryption

17 00088 2015 Proxy e Cliente-servidor descent.

DBMask: Fine-Grained Access Control on Encrypted Relational Databases

18 04291 2014 Software

Development Kit SQL-Based Fuzzy Query Mechanism Over Encrypted Database

Documents

Marcelo Ferreira de Lima - UFPE · execução de operações sobre dados encriptados no provedor de DBaaS. Um estudo, precursor e destacado, baseia sua solução em uma arquitetura