ipbrick cloud: segurança e encriptação de dados · 2019-07-22 · resumo as previsões apontam...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

IPBrick Cloud: Segurança eEncriptação de Dados

Ricardo Manuel da Silva Sousa

Mestrado Integrado em Engenharia Eletrotécnica e de Computadores

Orientador Interno: Professor João Neves

Orientado Externo: Engenheiro Miguel Ramalhão

25 de Julho de 2016

c© Ricardo Manuel da Silva Sousa, 2016

Resumo

As previsões apontam para que num futuro relativamente próximo, as estratégias de negóciodas empresas tecnológicas espalhadas pelo mundo seja fortemente influenciada pela computaçãoem cloud. De facto, a flexibilidade ao nível da demanda e oferta de recursos computacionais e oparâmetro de acessibilidade intrínseco à tecnologia, tornam a cloud atrativa quer para os clientesque usufruem dos seus serviços, quer para os fornecedores que os disponibilizam. Contudo, oprincipal motivo causador de relutância em relação à migração de serviços existentes dentro deportas para um modelo em cloud, é a segurança dos dados armazenados remotamente.

Enquadrando-se cada vez mais no princípio de negócio da cloud, a IPBrick SA pretende supri-mir qualquer tipo de fundamento que possa implicar a objeção ao uso desta tecnologia, e por issopropõe com que sejam criados mecanismos de segurança baseados em princípios criptográficos eoutros que almejam a manutenção da confidencialidade, integridade e disponibilidade dos dadosdo cliente.

No seguimento das pretensões da IPBrick SA em relação à IPBrick cloud, desenvolveu-se otrabalho descrito ao longo da presente dissertação, e que engloba o estudo e implementação deuma estratégia de encriptação dos dados do cliente, e o estudo e implementação de uma estratégiade backup dos dados do cliente, ambas ao nível da IPBrick cloud.

i

Abstract

Predictions on the future business strategies of IT companies are indicating that they will begreatly influenced by cloud computing technologies. In fact, both the flexibility associated withthe deployment of computing resources and the accessibility parameter of cloud computing, makethis technology attractive to the services providers and their clients. However, the main reasonwhy a part of the global IT community is somewhat afraid to migrate their services providedunder legacy technologies to the cloud infrastructures is the safeness of their own data.

Following this business trend, IPBrick SA has already a cloud solution available at the ITcommunications market and it wants to prevent possible objections to the use of this technologydue to the lack of data security. So that IPBrick SA recommends the implementation of securitymechanisms based on cryptographic principles and other security procedures aiming to maintainthe confidentiality, integrity, and availability of the client’s data while it is outside of his computer.

Regarding the pretencions of IPBrick SA in relation to the IPBrick cloud, work has beendeveloped and it is described in this dissertation, covering researching and implementation ofan encryption strategy of the client’s data, and the researching and implementation of a backupstrategy of the client’s data, both at the IPBrick cloud level.

iii

Agradecimentos

Os agradecimentos aqui prestados englobam todas as pessoas e entidades que estiveram en-volvidas e influenciaram positivamente o trabalho desenvolvido não só ao longo do período aca-démico dedicado ao desenvolvimento da dissertação, mas também ao período associado a todoo percurso previamente realizado que fez com que, passados 5 anos, conseguisse alcançar a retafinal de um dos objetivos da minha vida.

Agradeço por isso ao Professor João Neves por ter aceite o cargo de orientador e por conse-guinte, ter disponibilizado o seu tempo para orientar e monitorizar o trabalho elaborado ao longodos últimos 6 meses.

Agradeço ao Engenheiro Miguel Ramalhão pelos desafios lançados e pelos conselhos e indi-cações determinantes, no que diz respeito às melhores estratégias a definir para concretização dosobjetivos propostos.

Agradeço ao Engenheiro António Marques pela orientação providenciada ao nível técnico,tendo ela sido crucial no que toca à meta do desenvolvimento da implementação.

Agradeço aos meus pais porque graças a eles, estiveram sempre reunidas todas as condiçõespara que pudesse alcançar este objetivo e porque foram o meu grande poço de motivação em todosos momentos deste trajeto.

Agradeço à minha irmã pelo seu apoio, pelos conselhos e pelo seu entusiasmo que contagioutodo o meu percurso até esta reta final.

Agradeço à minha namorada pois foi ela a pessoa que mais de perto acompanhou todos osmomentos decisivos do meu percurso académico, pela sua paciência e generosidade, e porquesem ela as montanhas teriam sido tremendamente mais difíceis de escalar.

Agradeço aos meus amigos de longa data e àqueles que fui conhecendo durante os últimos 5anos, pela companhia, apoio e bem estar que me proporcionaram, pelos momentos de festa e portodas as aventuras que completaram o meu currículo como pessoa e futuro engenheiro.

Agradeço à IPBrick SA por ter disponibilizado todas as condições para a realização do trabalhorelativo à dissertação.

Agradeço à Faculdade de Engenharia da Universidade do Porto por ter sido a casa que meacolheu, e porque nela adquiri todo o conhecimento, toda a capacidade de análise e de introspeçãoe toda a cultura de engenharia, requisitos necessários para o sucesso de um engenheiro no contextoatual da sociedade tecnológica.

Ricardo M. Sousa

v

“Encryption protects our data. It protects our data when it’s sitting on our computers and in datacenters, and it protects it when it’s being transmitted around the Internet. It protects our

conversations, whether video, voice, or text. It protects our privacy. It protects our anonymity.And sometimes, it protects our lives.”

Bruce Schneier

vii

Conteúdo

1 Introdução 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Revisão Bibliográfica 52.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Definição e Estrutura da Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 O Conceito de Computação em Cloud . . . . . . . . . . . . . . . . . . . 62.2.2 Modelos da Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Ótica do Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Tecnologias Relevantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.6 Interfaces de Gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.7 Contextualização da IPBrick Cloud . . . . . . . . . . . . . . . . . . . . 14

2.3 Segurança dos Dados na Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 Conceitos de Segurança Computacional . . . . . . . . . . . . . . . . . . 152.3.2 Ameaças e Vulnerabilidades nos Serviços em Cloud . . . . . . . . . . . 172.3.3 Tecnologias Criptográficas . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.4 Disponibilidade e Backups dos Dados . . . . . . . . . . . . . . . . . . . 252.3.5 Classificação dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Projeto e Estrutura da Solução 293.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Aplicações e Dados da IPBrick Cloud . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1 Tipos de Aplicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2 Dados da IPBrick Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Estratégias para Encriptação dos Dados na IPBrick Cloud . . . . . . . . . . . . . 313.3.1 Estratégia 1 - Encriptação na Extremidade do Cliente . . . . . . . . . . . 313.3.2 Estratégia 2 - Implementação do Algoritmo Full Homomorphic Encryption 323.3.3 Estratégia 3 - Encriptação na Extremidade da IPBrick Cloud . . . . . . . 33

3.4 Estratégia para Backups dos Dados da IPBrick Cloud . . . . . . . . . . . . . . . 343.4.1 Análise dos Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.2 Ferramenta a Adotar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Estudo de Ferramentas Criptográficas . . . . . . . . . . . . . . . . . . . . . . . 353.5.1 Análise Qualitativa de Ferramentas de Encriptação do Disco . . . . . . . 36

ix

x CONTEÚDO

3.5.2 Testes de Desempenho sobre Ferramentas de Encriptação do Disco . . . 373.5.3 Conclusões e Considerações . . . . . . . . . . . . . . . . . . . . . . . . 42

3.6 Modelo-Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.6.1 Decisões sobre Estratégias e Ferramentas a Adotar . . . . . . . . . . . . 433.6.2 Mecanismo de Segurança Adicional - Autenticação do Host . . . . . . . 463.6.3 Representação Gráfica do Modelo-Solução . . . . . . . . . . . . . . . . 47

3.7 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 Implementação do Modelo-Solução na IPBrick Cloud 494.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Módulo de Encriptação de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.1 Detalhes sobre o Funcionamento da Ferramenta de Encriptação Adotada . 504.2.2 Protocolo de Gestão de Chaves Criptográficas . . . . . . . . . . . . . . . 534.2.3 Desenvolvimento do Protótipo . . . . . . . . . . . . . . . . . . . . . . . 554.2.4 Implementação do Mecanismo de Autenticação do Host . . . . . . . . . 634.2.5 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3 Módulo de Backups da IPBrick Cloud . . . . . . . . . . . . . . . . . . . . . . . 674.3.1 Detalhes sobre o Funcionamento da Ferramenta Bacula . . . . . . . . . . 674.3.2 Configurações Realizadas na Ferramenta Bacula . . . . . . . . . . . . . 684.3.3 Funcionalidade de Encriptação de Backups . . . . . . . . . . . . . . . . 684.3.4 Desenvolvimento do Protótipo . . . . . . . . . . . . . . . . . . . . . . . 704.3.5 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5 Conclusões e Trabalho Futuro 795.1 Objetivos Alcançados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.2.1 Otimização do Módulo de Encriptação dos Dados . . . . . . . . . . . . . 805.2.2 Procedimentos Adicionais no Módulo de Backup dos dados . . . . . . . 815.2.3 Encriptação de Ficheiros na Rede Social Empresarial Cafe . . . . . . . . 815.2.4 Módulo de Emissão Dinâmica de Assinaturas de E-mails . . . . . . . . . 82

A Glossário 83

B Resultados dos Testes de Desempenho 87B.1 CryFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87B.2 EncFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.3 eCryptfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.4 dm-crypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90B.5 File-System ext4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

C Configurações da Ferramenta Bacula 93C.1 Director-Daemon - Servidor Bacula . . . . . . . . . . . . . . . . . . . . . . . . 93C.2 Storage-Daemon - Servidor Bacula . . . . . . . . . . . . . . . . . . . . . . . . . 96C.3 File-Daemon - Cliente Bacula . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.4 Bconsole - Cliente Bacula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

CONTEÚDO xi

D Resultados do Questionário sobre Segurança na Cloud e Outros 99D.1 Resultados do Questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99D.2 Registo do E-mail enviado por Sebastian Messmer . . . . . . . . . . . . . . . . 107

Referências 109

xii CONTEÚDO

Lista de Figuras

2.1 Características das clouds públicas e privadas. . . . . . . . . . . . . . . . . . . . 82.2 Representação de uma estrutura em pirâmide com taxonomias e exemplos. . . . 92.3 Canal de comunicação seguro em redes privadas. . . . . . . . . . . . . . . . . . 112.4 Representação da arquitetura da virtualização através de um modelo de camadas. 112.5 Ilustração da estratégia da IPBrick cloud, baseada em SaaS. . . . . . . . . . . . 152.6 Representação da tríade CID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Modelo simplificado do processo de encriptação simétrica. . . . . . . . . . . . . 192.8 Ilustração do trade-off existente nas várias cifras e adaptações descritas (ilustração

inspirada no relatório da SkyHigh Networks). . . . . . . . . . . . . . . . . . . . 202.9 Modelo simplificado do processo de encriptação assimétrica com confidenciali-

dade garantida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.10 Esquema de implementação do MAC sem confidencialidade garantida. . . . . . . 232.11 Ciclo dos dados ao longo da cloud com exemplos de dados tipicamente associados

a cada fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Encriptação dos dados na extremidade do cliente. . . . . . . . . . . . . . . . . . 323.2 Funcionamento conceptual da Full Homomorphic Encryption. . . . . . . . . . . 333.3 Encriptação do lado da IPBrick Cloud. . . . . . . . . . . . . . . . . . . . . . . . 343.4 Modelo-Solução final. Legendas elucidativas dos elementos essenciais do modelo-

solução numeradas de 1 a 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1 Arquitetura da eCryptfs no sistema operativo Linux. A representação foi inspiradana figura 1 do relatório da IBM: "eCryptfs: An Enterprise-class CryptographicFilesystem for Linux". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Protocolo para geração da chave secreta simétrica usada pela cifra AES incorpo-rada na eCryptfs. Juntamente com a chave é gerada uma assinatura respetiva. . . 52

4.3 Partição do disco virtual "/dev/sda7" montada no diretório "/home1". . . . . . . . 534.4 Diretório "/home1" montado nele próprio pela eCryptfs, encontrado-se assim pro-

tegido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.5 Protocolo para gestão de chaves do cliente utilizado na implementação do módulo

de encriptação de dados da IPBrick cloud. . . . . . . . . . . . . . . . . . . . . . 544.6 Página principal da interface web de administração da IPBrick cloud. . . . . . . . 564.7 Acesso ao módulo de encriptação do menu da interface de administração. . . . . 574.8 Resultado da implementação da página principal do módulo de encriptação de

dados. É possível visualizar o estado "Off" correspondendo ao estado inativo. . . 574.9 Implementação da página informativa que faz a distinção entre os modos "Safe" e

"Extremely Safe". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

xiii

xiv LISTA DE FIGURAS

4.10 Resultado da implementação da página de alteração do estado do módulo de en-criptação da IPBrick cloud para o modo ativo. . . . . . . . . . . . . . . . . . . . 58

4.11 Resultado da implementação da página principal do módulo de encriptação agoracom o estado do módulo ativo, "On". . . . . . . . . . . . . . . . . . . . . . . . . 58

4.12 Resultado da implementação da página de alteração do estado ativo. É transmi-tido um aviso ao cliente sobre as consequências que podem causar uma possíveldesativação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.13 Ilustração de um aviso que é lançado sempre que o módulo de encriptação seencontre em "Extremely Safe Mode" e o sistema tenha sido alvo de um reboot. . 59

4.14 Modelo entidade-associação na origem da criação da tabela de auxílio ao módulode encriptação na base de dados local da VM. . . . . . . . . . . . . . . . . . . . 60

4.15 Protocolo de autenticação do host implementado. O círculo a tracejado representauma operação de concatenação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.16 Exemplo de uma possível infraestrutura de rede de backups da IPBrick cloud. . . 674.17 Protocolo com vista à geração da estrutura PKI para encriptação dos dados dos

backups, pela ferramenta Bacula. . . . . . . . . . . . . . . . . . . . . . . . . . . 694.18 Página principal do módulo de backups da IPBrick cloud. Aparecem listadas para

exemplo, três tarefas com parametrizações distintas. . . . . . . . . . . . . . . . 704.19 Página correspondente à parametrização de um backup diário. . . . . . . . . . . 714.20 Página correspondente à parametrização de um backup singular. . . . . . . . . . 724.21 Página correspondente à parametrização da tarefa restore. . . . . . . . . . . . . . 724.22 Resultado da implementação da página individual de cada tarefa. . . . . . . . . . 734.23 Modelo entidade-associação na origem da criação da tabela de auxílio ao módulo

de backups, na base de dados local. . . . . . . . . . . . . . . . . . . . . . . . . . 73

B.1 CryFS - teste 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87B.2 CryFS - teste 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.3 CryFS - teste 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.4 EncFS - teste 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.5 EncFS - teste 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.6 EncFS - teste 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.7 eCryptfs - teste 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.8 eCryptfs - teste 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.9 eCryptfs - teste 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.10 dm-crypt - teste 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90B.11 dm-crypt - teste 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90B.12 dm-crypt - teste 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90B.13 ext4 - teste 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91B.14 ext4 - teste 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91B.15 ext4 - teste 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Lista de Tabelas

3.1 Distinção entre exemplos de aplicações da IPBrick cloud tendo como base o sin-cronismo adjacente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Classificação dos diferentes tipo de dados associados à IPBrick cloud. . . . . . . 313.3 Avaliação qualitativa das ferramentas. . . . . . . . . . . . . . . . . . . . . . . . 363.4 Resultados dos testes de escrita, leitura e reescrita. Na coluna mais à esquerda

estão representadas as ferramentas testadas. . . . . . . . . . . . . . . . . . . . . 393.5 Média aritmética dos resultados obtidos na tabela 3.4. . . . . . . . . . . . . . . . 393.6 Resultados do teste de pesquisa aleatória. . . . . . . . . . . . . . . . . . . . . . 403.7 Latências associadas aos testes de escrita, leitura, reescrita e pesquisa aleatória

(P.A.). Nos testes de escrita e leitura é reportada a latência (ms) quer por byte(Char) quer por bloco de bytes (Bloco). . . . . . . . . . . . . . . . . . . . . . . 41

3.8 Média aritmética truncada das latência associadas aos testes de escrita, leitura,reescrita e pesquisa aleatória (P.A.). Devido à variância existente nos valores databela 3.7, foi truncado para cada sequência de testes o valor correspondente àlatência mais elevada para que as conclusões pudessem ser mais objetivas. . . . 41

4.1 Testes efetuados para verificação das funcionalidades do módulo de encriptaçãodos dados da IPBrick cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2 Testes efetuados para verificação das funcionalidades do módulo de backup dosdados da IPBrick cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

xv

xvi LISTA DE TABELAS

xviii ABREVIATURAS E SÍMBOLOS

Abreviaturas e Símbolos

AES Advanced Encryption StandardAPI Application Programming InterfaceAWS Amazon Web ServicesAGPL Affero General Public LicenseCBC Cipher Block ChainingCLI Command-Line interfaceCPU Central Processing UnitCSP Cloud Service ProviderCSB Cloud Service BrokerDES Data Encryption StandardDMTF Distributed Management Task ForceFIPS Federal Information Processing StandardFPE Format Preserving EncryptionFHE Fully Homomorphic EncryptionGUI Graphical User InterfaceIaaS Infrastructure as a ServiceIP Internet ProtocolIPsec IP Security ProtocolKVM Kernel-based Virtual MachineLAN Local Area NetworkLDAP Lightweight Directory Access ProtocolLUKS Linux Unified Key SetupWAN Wide Area NetworkMPLS Multi Protocol Label SwitchingMTA Message Tranfer AgentNAS Network Attached StorageNIST National Institute of Standards and TechnologyNFS Network File SystemOPE Order-Preserving EncryptionOS Operating SystemPaaS Platform as a ServicePKI Public Key InfrastructureRAID Redudant Array of Independent DisksREST Representational State TransferRFC Request For CommentsRSA Rivest-Shamir-AdlemanR&D Research and DevelopmentSaaS Software as a ServiceSDN Software-Defined NetworkingSSH Secure ShellTLS Transport Layer SecurityUUID Universally Unique Identifier

ABREVIATURAS E SÍMBOLOS xix

VLAN Virtual Local Area NetworkVM Virtual MachineVPN Virtual Private NetworkWiFi Wireless Local Area Network

Capítulo 1

Introdução

1.1 Contexto

Na atualidade, uma grande parte das aplicações existentes na Internet é disponibilizada numa

cloud, deixando de ser necessária a instalação e configuração de um dado serviço localmente.

Existem inúmeras vantagens no uso desta tecnologia das quais se destacam: a poupança de recur-

sos do lado do utilizador e o aumento significativo do nível de acessibilidade a um serviço. No

entanto, um dos principais fatores inerentes à utilização de uma plataforma em cloud é a segu-

rança uma vez que toda a informação disponibilizada por um utilizador permanece remotamente

localizada, não existindo na grande maioria da vezes, conhecimento da topologia da rede de comu-

nicação nem qualquer tipo de controlo relevante sobre o servidor de armazenamento. A possível

ausência de mecanismos que garantam a confidencialidade, integridade e disponibilidade dos da-

dos, faz aumentar o nível de ceticismo de algumas empresas e utilizadores domésticos no que diz

respeito ao uso de um serviço em cloud.

As empresas cujo mercado se baseia em serviços disponibilizados através da rede global In-

ternet, tendem, cada vez em maior número, em migrar a implementação que possuem nas suas

infraestruturas para um modelo em cloud. A segurança é dos aspetos que mais exige atenção. Um

estudo recente da Cloud Security Alliance (CSA) indica que a segurança das clouds é um problema

que preocupa os líderes de 61% das organizações a nível mundial [1]. Num outro estudo desen-

volvido no âmbito da presente dissertação através da realização de um questionário a cerca de 30

colaboradores de diferentes empresas tecnológicas sediadas em Portugal, cujo os resultados po-

dem ser consultados no anexo D.1, em resposta à pergunta "Que importância atribui à segurança

dos dados da sua empresa na cloud tendo em conta a estratégia de negócio praticada?", 73%

dos inquiridos consideraram extremamente importante enquanto que 23% consideraram muito

importante, indicando que de fato existe a perceção da importância de, ao nível da cloud, serem

implementados mecanismos de segurança que possam garantir controlo e confiança sobre os dados

disponibilizados pela entidade que usufrui do serviço em cloud.

A IPBrick SA, acompanhando a evolução do mercado, possui já soluções em cloud e pretende

dar respostas a futuras debilidades que um sistema desta natureza pode apresentar, nomeadamente

1

2 Introdução

no que diz respeito à segurança dos dados dos seus clientes. Para isso, torna-se necessário o estudo

e desenvolvimento de soluções que garantam a eficácia e eficiência futura ao nível da segurança

do software IPBrick da IPBrick cloud. Mais concretamente, soluções implementadas através de

mecanismos criptográficos e outros que permitam assegurar a confidencialidade, integridade, e

disponibilidade dos dados.

1.2 Motivação

A razão pela qual, parte da comunidade tecnológica global, tende em resistir à migração dos

serviços que usufruem para uma plataforma em cloud, é precisamente a falta de confiança nos

mecanismos de segurança das infraestruturas dos Cloud Service Providers (CSPs). As diretivas

europeias, que dizem respeito à regulação dos mecanismos de segurança oferecidos pelos CSPs,

sugerem um princípio de harmonização entre as diferentes leis impostas sobre a segurança e pro-

teção dos dados, na constituição de cada país membro. Em Portugal, a legislação é omissa em

relação à obrigatoriedade de imposição de mecanismos de segurança por parte dos CSPs. O ar-

tigo 12o do decreto de lei 7/2004 para controlo das comunicações eletrónicas afirma que: "Os

prestadores intermediários de serviços em rede não estão sujeitos a uma obrigação geral de vi-

gilância sobre as informações que transmitem ou armazenam ou de investigação de eventuais

ilícitos praticados no seu âmbito.". Sendo assim, a prática de atos ilícitos pelo CSP está sujeita

apenas e só, à quebra do contrato acordado com o cliente [2]. Para contornar este problema é

necessário estimular os CSPs à implementação de mecanismos de segurança que envolvam custos

sustentáveis. Nesse sentido, é urgente o desenvolvimento de tecnologias atrativas para o mercado

que garantam segurança dos dados em cloud. Existem vários projetos em curso de iniciativas

públicas e privadas. A título de exemplo, o projeto "Practice", financiado pela União Europeia,

em desenvolvimento desde 2013 e com data prevista de conclusão em 2016, que envolve várias

instituições de investigação, incluído o INESC TEC, foca-se em objetivos dos quais se destacam:

a proteção dos dados de um utilizador, dos outros utilizadores que usufruem do mesmo serviço em

cloud; a proteção dos dados de um utilizador, do CSP que providencia o serviço; a computação

segura entre servidores de armazenamento de dados e a computação segura na comunicação com

entidades não credíveis [3]. A importância comprovada de projetos a nível europeu relacionados

com a segurança na cloud, tal como o projeto "Practice", representa um fator motivacional para o

desenvolvimento do trabalho.

Na vertente pessoal do autor, o enquadramento do tema atribuído permite com que possam

ser aplicados conhecimentos que foram adquiridos nas várias unidades curriculares pertencentes

ao grupo opcional de especialização de "Redes e Serviços de Comunicações". A importância do

tema é ainda outro fator motivacional e que pode ser espelhada em dois parâmetros de valorização

relacionados, quer com o ambiente empresarial, quer com a sociedade tecnológica em que se

engloba, sendo eles os seguintes:

• Valor Económico - Uma possível solução permitiria acrescentar valor económico às futuras

propostas realizadas pela IPBrick SA, na medida em que garantiria a oferta de um nível

1.3 Objetivos 3

superior de segurança dos dados do cliente.

• Valor Científico - Uma solução eficaz e inovadora poderia levar à alteração do panorama

atual no que toca aos mecanismos de segurança implementados num serviço disponibilizado

em cloud.

1.3 Objetivos

O desenvolvimento do trabalho deve seguir linhas de orientação bem definidas e contextu-

alizadas tendo em conta o tema da dissertação. Para esse efeito, é pertinente o esclarecimento

dos objetivos propostos pela IPBrick SA, em concordância com o autor e com os orientadores.

Descrevem-se neste ponto, os três objetivos principais da dissertação:

• Encriptação dos Dados - Investigação e desenvolvimento de uma estratégia que permita

encriptar os dados da IPBrick cloud, mais concretamente os dados dos clientes que possuem

software IPBrick ao nível da cloud.

• Backups dos Dados - Investigação e desenvolvimento de uma estratégia para execução de

backups dos dados armazenados na IPBrick cloud que permita salvaguardar os dados do

cliente, restaurando-os a partir de um ponto específico na escala temporal.

• Visibilidade da Solução - Desenvolvimento de um módulo de encriptação e de um outro

dedicado à execução de backups na interface web de administração do software IPBrick,

possibilitando ao cliente a interação com os mecanismos de segurança implementados na

IPBrick cloud.

Para concretização dos referidos objetivos, devem ser tidos em conta os seguintes requisitos:

• Qualquer solução a apresentar deve basear-se na estratégia de negócio da IPBrick SA no que

toca à oferta na cloud em que os produtos disponibilizados são caracteristicamente "chave-

na-mão".

• Os mecanismos de segurança a implementar devem ser independentes de terceiros (ex. em-

presas especializadas em segurança na cloud). Todas as estratégias devem ser implementa-

das no software IPBrick da IPBrick cloud e disponibilizadas a partir do mesmo.

4 Introdução

1.4 Estrutura da Dissertação

Para além do capítulo introdutório, o conteúdo da dissertação encontra-se dividido em quatro

capítulos principais:

• Revisão bibliográfica.

• Estrutura e Projeto da Solução.

• Implementação do Modelo-Solução.

• Conclusão e Trabalho Futuro.

No capítulo de revisão bibliográfica faz-se a descrição do funcionamento da cloud, do estado

da arte em termos das tecnologias que compõem a cloud e das tecnologias existentes para imple-

mentação das medidas de segurança perspetivadas. O capítulo de estrutura e projeto da solução

aborda os pontos necessários para se alcançar uma solução que dê resposta aos objetivos propos-

tos. A implementação da solução é descrita no capítulo seguinte e as conclusões sobre o trabalho

realizado bem como o trabalho a ter em consideração no futuro, serão elementos a abordar no

último capítulo da presente dissertação.

Capítulo 2

Revisão Bibliográfica

Neste capítulo é descrito o estado atual da tecnologia relacionada com o tema tendo como

referências livros, artigos científicos e relatórios técnicos provenientes de várias fontes académi-

cas e empresariais que se dedicaram ao estudo da cloud e ao desenvolvimento de estratégias de

segurança eficazes ao nível dos dados com potencial interesse de aplicabilidade na cloud.

2.1 Introdução

A construção de um plano sólido para desenvolvimento de uma solução é apenas possível após

a revisão exaustiva dos mecanismos existentes no contexto atual que providenciam segurança nos

serviços disponibilizados em cloud. Urge, de igual forma, possuir um conhecimento aprofundado

do conceito de cloud e das tecnologias associadas, nomeadamente no que diz respeito a:

• Modelos e taxonomia da cloud.

• Disponibilização dos serviços tendo em conta a abordagem ao mercado pelos CSPs.

• Infraestruturas que constituem o modelo em cloud.

Posto isto, numa primeira parte do presente capítulo faz-se a caracterização do modelo da

cloud recorrendo às tecnologias atuais que o constituem, terminando com a contextualização da

IPBrick cloud. Numa segunda parte, descrevem-se as implementações que representam o estado

da arte dos mecanismos de segurança que podem ser implementados para proteção dos dados na

cloud, com maior incidência nas tecnologias criptográficas.

5

6 Revisão Bibliográfica

2.2 Definição e Estrutura da Cloud

2.2.1 O Conceito de Computação em Cloud

A cloud por si só não representa uma tecnologia. De facto, este termo foi escolhido para dar

nome a um sistema constituído por múltiplas tecnologias já existentes que se interligam entre si

através de uma rede complexa, levando assim ao surgimento do conceito de computação em cloud.

Durante anos, as várias tentativas para definir de forma clara e consensual este conceito inovador,

fracassaram [4]. Um documento do National Institute of Standards and Technology (NIST) com a

última revisão feita no ano de 2012, define computação em cloud da seguinte forma: "Cloud com-

puting is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool

of configurable computing resources (e.g. networks, servers, storage, applications, and services)

that can be rapidly provisioned and released with minimal management effort or service provider

interaction." [5]. Esta definição é consensual entre a comunidade global interveniente neste tema.

O NIST acrescenta ainda as cinco características essenciais associadas à computação em cloud:

• Auto-Aprovisionamento de Recursos - Um utilizador pode, de forma unilateral, fazer o

aprovisionamento de recursos tais como capacidade de armazenamento e poder de proces-

samento, sem que exista a necessidade de interação direta com o CSP [5].

• Heterogeneidade no Acesso - A existência de redes capazes de estabelecer ligação entre as

infraestruturas que armazenam os dados do utilizador, através da Internet, fazem com que

o acesso aos serviços em cloud possa ser feito através de múltiplos dispositivos, sejam eles

fixos ou móveis (ex. smartphones, tablets, laptops, workstations) [5].

• Partilha de Recursos - A partilha de recursos (ex. capacidade de armazenamento, capa-

cidade de processamento), é uma das grandes vantagens do modelo da cloud. Utiliza-se a

expressão tenant para designar o espaço na cloud correspondente a um utilizador. Nas in-

fraestruturas que constituem uma cloud, o aprovisionamento de recursos virtuais de forma

individualizada perfaz a arquitetura single-tenancy. Pelo contrário, a partilha de recursos

por múltiplos utilizadores, como no caso de uma cloud pública, define a arquitetura multi-

tenancy [5].

• Elasticidade - Nos modelos tradicionais, a demanda de recursos exigia a compra e manu-

tenção de infraestruturas mesmo que o seu uso ficasse condicionado a um curto período de

tempo. Uma das características da cloud consiste no ajuste dos recursos fornecidos, perante

as necessidades do cliente [5].

• Contabilização - Um CSP implementa um esquema de taxação que pode variar exatamente

pelo tipo de serviço que disponibiliza ou pelo tipo de contrato subjacente. Assim, essa enti-

dade pode taxar ao cliente tendo em conta o número de utilizadores do serviço (metodologia

charge-per-use), ou tendo em conta os recursos utilizados durante um período estabelecido

(metodologia pay-per-use) [5].

2.2 Definição e Estrutura da Cloud 7

2.2.2 Modelos da Cloud

No contexto da definição da cloud, é importante caracterizar os diferentes modelos, intrín-

secos aos vários serviços disponibilizados pelos CSPs. Os modelos aqui descritos baseiam-se

maioritariamente na definição de computação em cloud feita pelo instituto norte-americano NIST

[5].

• Cloud Privada - Operada e gerida apenas pela entidade proprietária ou terceiros devida-

mente autorizados e é dedicada aos serviços que se pretendem ver disponibilizados pela

mesma. Pode-se equiparar a um data-center dentro dos limites físicos do proprietário ou, no

seu conceito reformulado, disponibilizado por um CSP através de uma arquitetura single-

tenancy. Os custos de manutenção tendem a ser superiores em relação a outros tipos de

clouds mas a segurança é privilegiada uma vez que existe, à partida, um perfeito conheci-

mento de toda a rede que compõe a arquitetura [5, 6].

• Cloud Pública - Toda a infraestrutura é aprovisionada para o uso do público geral sendo que

o CSP que a disponibiliza reserva-se aos direitos impostos pelas suas políticas e regras de

gestão e manutenção. Dos CSP existentes que disponibilizam esta arquitetura destacam-se

a Amazon AWS, Azure, Google GCP e IBM Cloud [5].

• Cloud Comunitária - Plataforma partilhada por comunidades específicas com interesses

similares no uso de determinados tipos de serviços. Na definição do NIST, a cloud comu-

nitária pode ser operada por uma ou mais organizações na comunidade, um terceiro ou uma

combinação deles. Um serviço de gestão de contas bancárias pode ser um exemplo de um

interesse comum entre entidades bancárias que justifica a existência deste tipo de cloud [5].

• Cloud Híbrida - A infraestrutura deste tipo de cloud envolve duas ou mais infraestruturas

das até agora mencionadas. A cloud híbrida pode ser particularmente útil em grandes orga-

nizações que pretendem controlar a sua atividade central através de uma cloud privada e ao

mesmo tempo disponibilizar serviços e funcionalidades ao público geral ou comunidades

específicas. A interoperabilidade entre clouds define uma cloud híbrida [5].

Na Figura 2.1 podem ser observadas características relativas aos dois modelos implementa-

dos com maior frequência para disponibilização de serviços por parte dos CSPs.


Cloud Pública Cloud Privada

Recursos físicos e virtuais

partilhados

Recursos físicos e virtuais

partilhados num ambiente

privado

Conectividade através da

Internet sem restrições

Conectividade através da

Internet utilizando redes

privadas ou canais seguros

(ex. VPN)

Con%dencialidade da

informação não é privilegiadaMais garantias na segurança

da informação

Con%gurada e controlada

pelo fornecedor do serviço

Controlo geral e manutenção

feita pela entidade privada

Menos custos associadosCustos de utilização superiores

mas com tendência para

diminuirem

Foco no utilizador %nal (ex.

ferramentas de colaboração)

Foco na indústria devido ao

forte requisito de privacidade

Cloud Privada

Figura 2.1: Características das clouds públicas e privadas.

2.2.3 Ótica do Negócio

2.2.3.1 Taxonomia da Cloud

Os CSPs podem disponibilizar no mercado das clouds, produtos com as seguintes taxonomias:

• Infrastructure as a Service (IaaS) - O produto disponibilizado consiste no pacote das in-

fraestruturas físicas (ex. rede e servidores), capacidade de processamento e outros recursos

computacionais. O cliente não possui privilégios de gestão sobre este pacote podendo no

entanto ter controlo sobre as camadas do sistema operativo, entrada e saída de dados e apli-

cações [7].

• Platform as a Service (PaaS) - Os PaaS providers acrescentam ao pacote de um IaaS provi-

der as camadas do sistema operativo e entrada e saída de dados. O controlo e configuração


das aplicações bem como o ajuste de alguns parâmetros do ambiente de hosting ficam ao

encargo do cliente [7].

• Software as a Service (SaaS) - Todas as camadas são oferecidas ao cliente num pacote

único em que a aplicação do CSP corre sobre o software alojado nas infraestruturas que lhe

pertencem. Os privilégios de controlo pelo cliente são restritos e não abrangem mais do que

alguns parâmetros de ajuste da aplicação fornecida [7].

IaaS

PaaS

SaaS

Armazenamento, CPU, Memória, Largura de Banda

Software framework (Java/Python/.Net)

Armazenamento (BD/Ficheiro)

Aplicações Web

Serviços Multimédia

Ferramentas Colaborativas

Hardware Data Centers

Amazon EC2

Google Apps

Linkedin

Youtube

Skype

salesforce

Azure

Google App

Engine

Figura 2.2: Representação de uma estrutura em pirâmide com taxonomias e exemplos.

2.2.3.2 Abordagem ao Mercado

Para serem compreendidas as várias fragilidades e condicionantes existentes nos serviços

disponibilizados em cloud, é importante efetuar a contextualização do mercado de venda e/ou

revenda de serviços pelos CSPs ou outros intermediários. Tendo em conta o ponto anterior que

apresentam os três tipos de taxonomias disponibilizadas pelos CSPs, pode-se inferir de forma

automática que existem três modelos de negócio distintos.

Existe ainda um outro modelo de negócio praticado por entidades intermediárias. Não pos-

suem infraestruturas associadas a um IaaS ou PaaS provider, mas alugam-nas e acrescentam valor

de mercado para posterior disponibilização ao cliente. São os designados Cloud Service Brokers

(CSBs). O modelo de negócio dos CSBs pode basear-se na agregação e integração dos vários ser-

viços existentes providenciados por diferentes fornecedores, oferecendo um serviço ao cliente sem

que o mesmo tenha que se preocupar com as infraestruturas que o implementam. Um CSB pode

também implementar as suas próprias aplicações tendo como suporte os serviços disponibilizados

por um IaaS ou PaaS provider [8]. Devido às grandes dificuldades de interoperabilidade entre


clouds, assunto a abordar no ponto 2.2.6, os CSBs servem como interface de união estabelecendo

uma linguagem comum entre as várias infraestruturas.

2.2.4 Tecnologias Relevantes

2.2.4.1 Dispositivos de Acesso

A variedade de dispositivos de acesso a serviços ou aplicações disponibilizadas através de

plataformas em cloud, aumentou consideravelmente na última década sendo que, neste momento,

basta que um dispositivo tenha a capacidade de estabelecer conectividade com a rede Internet para

que sirva como ponto de acesso a uma aplicação em cloud. Para além dos tradicionais computado-

res pessoais e empresariais, a introdução de marketplaces que fazem a proliferação de aplicações

nos diferentes sistemas operativos dos smartphones e tablets, tornam estes últimos essenciais para

o acesso móvel à grande variedade de serviços disponibilizados em cloud. De mencionar que, a

mobilidade no acesso, só é possível graças ao desenvolvimento das tecnologias de redes sem fios

(ex. WiFi, 3G, 4G, WiMAX) [4].

2.2.4.2 Data Centers

A exigência de capacidades computacionais elevadas para disponibilização de serviços em

cloud, faz com que seja necessária a existência de data centers que armazenam um número consi-

derável de servidores. O cluster estabelecido através da rede global Internet entre os diversos data

centers localizados em diferentes partes do mundo, torna possível providenciar sistemas eficazes

de computação distribuída e de entrega de serviços. A Google e a IBM são exemplos de empresas

que disponibilizam no mercado data centers focados nas plataformas em cloud [4].

2.2.4.3 Infraestruturas de Rede

Para ser assegurado um desempenho aceitável de um dado serviço, disponibilizado através de

infraestruturas de uma cloud, é necessário desenhar uma rede eficiente para garantir o controlo

sobre o possível aumento de volume de tráfego no serviço. As tradicionais arquiteturas de redes

usadas em data centers (ex. topologia em árvore), não garantem escalabilidade e mitigação das

falhas ocorridas devido à congestão dos nós e das ligações da rede. Tecnologias atuais como

Ethernet e VLANs, também não se adequam a certas características da cloud (ex. multi-tenancy,

single-tenancy). Graças às novas arquiteturas de rede implementadas nos data centers, baseadas

em software-defined networking (SDN), é possível adaptar dinamicamente as configurações e o

desenho geral da rede tendo em conta a carga dos nós e das ligações, num dado momento [9].

Outros desenhos de rede para implementação em data centers foram desenvolvidos: VL2 [10],

Portland [11], NetLord [12].

Ao nível da distribuição de serviços e tendo em conta a cloud privada, sendo o tipo de cloud

que exige mais requisitos neste capítulo, existe a necessidade do uso de tecnologias de rede que


façam aumentar o nível padrão de segurança. Essas tecnologias consistem em firewalls, imple-

mentações de redes MPLS VPN (figura 2.3), e o uso do protocolo de encriptação ao nível da

camada de rede, com recurso ao IPSec [13].

CSP

Internet

Gateway CSP

Gateway do Cliente

Cliente

Ligação VPN

Figura 2.3: Canal de comunicação seguro em redes privadas.

2.2.5 Virtualização

O termo "virtualização" é mencionado de forma recorrente pela comunidade ligada ao desen-

volvimento de serviços em cloud. De facto, este processo permite a criação de uma interface de

abstração dos utilizadores sobre os recursos computacionais físicos (ex. processamento, redes, ar-

mazenamento), pertencentes à infraestrutura da cloud [4]. A virtualização num sistema com as ca-

racterísticas da cloud, permite a partilha democratizada dos recursos físicos existentes pelos vários

utilizadores. Esta abstração do contexto físico favorece particularmente os CSPs, permitindo-lhes

garantir da fiabilidade de parâmetros essenciais e incluídos no service-level agreement (SLA) tais

como: disponibilidade, largura de banda e capacidade de armazenamento.

Hardware

Hypervisor

GuestOS 1 GuestOS 2 GuestOS 3

App1 App2 App3 App4 App5 App6

. . .

Figura 2.4: Representação da arquitetura da virtualização através de um modelo de camadas.


2.2.5.1 Componentes Virtualizados

A virtualização pode ser conseguida a partir de diferentes tecnologias dependendo do tipo de

recurso físico. Partindo desta afirmação, definem-se os seguintes subconjuntos de virtualização:

• Virtualização dos Servidores - Consiste no componente responsável pela virtualização dos

recursos computacionais (ex. processamento e memória), designado por hypervisor (Figura

2.4). São exemplos de hypervisores existentes: VMWare, QEMU, KVM e Xen [4].

• Virtualização do Armazenamento - Consiste na virtualização de uma entidade de arma-

zenamento única a partir de múltiplos equipamentos físicos de armazenamento. Este tipo

de virtualização gera duas abstrações ao nível do armazenamento: virtualização dos volu-

mes e virtualização dos objetos. A virtualização de dispositivos de armazenamento físicos

em volumes virtuais de armazenamento, facilita a atribuição de discos às Virtual Machines

(VMs) enquanto que a possibilidade de virtualização dos objetos de dados permite assegurar

características como escalabilidade e redundância. Neste último ponto, os objetos de dados

presentes na cloud passam a designar-se por contentores, em que cada objeto corresponde a

um contentor num volume virtual de armazenamento [4].

• Virtualização da Rede - As infraestruturas que suportam uma cloud são ligadas por LANs

e WANs que se baseiam na arquitetura tradicional IP. A arquitetura IP apresenta problemas

ao nível do isolamento das redes, neste caso específico, os serviços implementados sobre

plataformas em cloud podem interferir entre si resultando em problemas de desempenho,

disponibilidade e segurança. Para ultrapassar este problema recorre-se à virtualização das

redes das clouds onde múltiplas redes virtuais compartilham os dispositivos físicos que com-

põem uma rede tradicional. Podem ser criados nós virtuais ao nível dos routers, switches e

ligações virtuais entre os mesmos. Este nível de virtualização permite aumentar a segurança

e o isolamento entre tenants e assegurar os parâmetros de desempenho e disponibilidade da

rede da cloud [9] [14].

2.2.5.2 Operações Relevantes na Virtualização

Existem operações inerentes à virtualização dos vários componentes que constituem uma

cloud e que visam facilitar os processos de requisição de recursos computacionais, de armaze-

namento e de estabelecimento de ligações. Listam-se neste ponto as operações relevantes [9]:

• Operações Computacionais:

– Criar/Remover - Define uma imagem do guest OS ou a remoção da mesma.

– Deploy/Undeploy - Permite instalar e desinstalar uma VM no hypervisor, num nó da

infraestrutura de uma cloud.

– Iniciar/Interromper/Suspender/Resumir - Operações que controlam o estado do

guest OS.


– Migrar - Efetua a transferência da instalação de uma VM para outro nó da infraestru-

tura.

– Modificar - Operação para efetuar a alteração dos parâmetros definidos aquando da

criação da VM.

– Snapshot - Cria um ponto de restauro da VM.

– Restaurar - Permite a recuperação de uma VM utilizando um snapshot disponível.

– Listar - Permite listar as várias VMs instaladas num dado nó da infraestrutura de uma

cloud.

• Operações sobre o Armazenamento:

– Criar/Remover - Definição/exclusão de uma pool de armazenamento virtual que per-

mite alocar espaço para volumes virtuais.

• Operações sobre a Rede:

– Criar/Remover - Permite a criação/remoção de routers virtuais com portas virtuais

para conectar várias interfaces de rede virtualizadas. Operação que também define

ligações virtuais entre dispositivos virtualizados.

– Configurar - Operação para configuração de parâmetros relacionados com as ligações

virtuais ou rotas estabelecidas num router virtual (ex. largura de banda).

2.2.6 Interfaces de Gestão

No contexto do negócio e desenvolvimento de tecnologia em cloud, não tem existido um con-

senso geral entre os CSP sobre a plataforma comum que deve estabelecer uma interface de gestão

e suporte das infraestruturas virtualizadas, providenciadas ao cliente. A falta desse consenso faz

com que existam diferentes abordagens por parte das empresas que dominam o setor, o que torna

a interoperabilidade entre as diferentes infraestruturas e serviços inatingível . Do ponto de vista

do cliente, este fator transforma a escolha de um serviço de um dado CSP numa questão sensível,

basta ter em conta as dificuldades inerentes à resolução de potenciais problemas num serviço com

interface de gestão proprietária criando dependência total sobre recursos técnicos fornecidos pelo

CSP, ou ainda a uma futura mudança de paradigma do negócio que implicasse a escolha de um

novo serviço cloud de um CSP distinto, o que obrigaria a que a solução existente, por possuir

problemas de compatibilidade, tivesse obrigatoriamente que ser removida.

A resolução deste problema deve assentar num método que consiga estabelecer uma lingua-

gem comum interpretada pelas várias infraestruturas das clouds, existentes na atualidade. Das

várias propostas lançadas, existem duas aproximações a um princípio de solução que entram em

conformidade com os ideais de negócio estabelecidos pelas empresas, sendo elas [4]:


1. Criação de um Open Standard que defina uma interface de gestão comum, a ser imple-

mentada nas infraestruturas das clouds.

2. Adoção de APIs que sirvam como gateway para o estabelecimento de processos de comu-

nicação uniformes entre as várias clouds.

Apesar de a primeira alternativa ser a ideal para a resolução deste problema, o processo de

geração de consenso geral entre o consórcio mundial de CSPs sobre a adoção de um standard

comum não aparenta ser trivial. Posto isto, a segunda alternativa goza de uma certa vantagem,

apesar do overhead adicional em termos de latência nos processos de gestão da cloud, devido à

camada da API que se sobrepõe à camada de software [4].

2.2.7 Contextualização da IPBrick Cloud

A IPBrick SA acompanhando a rápida evolução ao nível dos serviços em cloud, disponibiliza

as várias aplicações associadas ao seu modelo de negócio num ambiente de virtualização single-

tenancy. A cada cliente é disponibilizada uma VM com todas as características de virtualização

isoladas de outras VMs alojadas num data-center, podendo este modelo ser visto como um modelo

em cloud privada. Sobre o hypervisor definido pelo CSP, corre um guest OS que poderá ser por

exemplo, a distribuição Debian baseada no sistema operativo Linux. O espaço de armazenamento

virtual, o processamento virtual e as infraestruturas de redes virtuais são elementos de virtuali-

zação mutáveis, de VM para VM, fornecidas pelo CSP tendo em conta a demanda e a exigência

dos requisitos do cliente da IPBrick SA. Por necessidade de desenvolvimento e administração

dos sistemas, as VMs são manipuladas através das operações descritas em 2.2.5.2 pela equipa de

R&D da IPBrick SA. A responsabilidade sobre a interface de gestão da cloud é assumida pelo

CSP, ou seja, assume-se a adoção, nos processos de comunicação entre os vários elementos que

constituem a infraestrutura IPBrick cloud, de uma API proprietária. No sistema operativo convi-

dado são desenvolvidas as várias aplicações que compõem o software IPBrick da IPBrick cloud,

sendo que o produto final disponibilizado no mercado enquadra-se na tipologia de modelo de ne-

gócio de um SaaS, podendo da mesma maneira, classificar-se a IPBrick SA como sendo um CSB.

São igualmente implementados os vários mecanismos de segurança necessários para assegurar a

privacidade dos dados do cliente na sua VM (ex. firewalls, tecnologias criptográficas, software

anti-vírus). Um possível cliente pode obter o produto "chave-na-mão" sem necessitar de proceder

à aquisição de servidores físicos ou efetuar qualquer tipo de instalação ou configuração na sua má-

quina. A Figura 2.5 ilustra a estratégia definida pela IPBrick SA ao nível da cloud. Na globalidade

dos casos considera-se o CSP da IPBrick SA como sendo um fornecedor PaaS.

2.3 Segurança dos Dados na Cloud 15

PaaS

VM

SaaS

INTERNET

Cliente

Figura 2.5: Ilustração da estratégia da IPBrick cloud, baseada em SaaS.

2.3 Segurança dos Dados na Cloud

2.3.1 Conceitos de Segurança Computacional

Para melhor compreensão da necessidade no que diz respeito à adoção de mecanismos de se-

gurança para a proteção dos dados na cloud, são clarificados neste ponto conceitos de segurança

computacional que irão ser abordados ao longo dos restantes capítulos. A organização norte-

americana NIST define segurança computacional na sua publicação designada por Computer Se-

curity Handbook, como sendo: "The protection afforded to an automated information system in

order to attain the applicable objectives of preserving the integrity, availability, and confidenti-

ality of information system resources (includes hardware, software, firmware, information/ data,


and telecommunications". Da definição é possível retirar três requisitos essenciais no que toca à

segurança dos dados na cloud [15]:

• Confidencialidade dos Dados - Assegura que os dados sensíveis não estejam no formato

original ou destapados a possíveis indivíduos que não possuam autorização para acesso aos

mesmos.

• Integridade dos Dados - Requisito que indica que os dados só devem ser alterados por

indivíduos devidamente autorizados.

• Disponibilidade dos Dados - Assegura o correto funcionamento do sistema em causa, soft-

ware e aplicações, aos indivíduos devidamente autorizados, garantindo a correta disposição

dos dados.

Os requisitos de segurança anteriores completam a tríade CID (Figura 2.6), base fundamen-

tal e que deve ser tida sempre em consideração aquando da implementação de mecanismos de

segurança dos dados.

Con�denci

alid

ade Integridade

Disponibilidade

Dados e Serviços

Figura 2.6: Representação da tríade CID.

Existem outros requisitos de segurança computacional de relevância considerável no que toca

à implementação de estratégias de segurança nos diversos sistemas de informação existentes na

atualidade e que podem ter importância no desenvolvimento das soluções a apresentar para reso-

lução dos objetivos da dissertação. Esses requisitos outsiders são aqui descritos [15]:

• Autenticidade - Assegura a genuinidade dos dados em que o autor dos mesmos deve ser

sempre reconhecido como tal. Toma em conta o procedimento de verificação em que se

avalia se de facto os dados são proprietários do autor que o diz ser. A violação da integridade

dos dados é garantia da perda da autenticidade dos mesmos.


• Não Repúdio - Assegura a existência de dados forenses que permitam seguir atividades

executadas no passado pelos autores dos dados em causa. É um requisito implementando

através de contadores e pode servir como prova, por exemplo, para a tomada de ações legais

em relação a determinada entidade.

2.3.2 Ameaças e Vulnerabilidades nos Serviços em Cloud

No que toca à segurança dos dados de um utilizador num serviço em cloud, existem vários

tipos de ameaças, sendo que as que apresentam maior impacto nas tecnologias de computação em

cloud segundo a CSA, são:

1. Abuso e Uso Descontrolado das Capacidades da Cloud - IaaS e PaaS providers por mo-

tivos ligados ao próprio marketing empresarial, criam a ilusão da oferta de recursos compu-

tacionais ilimitados, ao cliente. A falta de segurança no processo de registo de utilizadores

oferece uma oportunidade aos spammers e outro tipo de adversários de efetuar o arma-

zenamento, em grandes quantidades, de conteúdo inapropriado, sem que o anonimato do

adversário seja posto em causa [16].

2. Adversários Internos - Falta de políticas de vigilância e controlo no serviço em cloud de

uma empresa pode levar a que colaboradores mal intencionados consigam perpetrar ataques

através do acesso às respetivas contas com as credenciais correspondentes, sem que exista

qualquer tipo de barreira de segurança [16].

3. Interfaces de Gestão e APIs Inseguras - As interfaces de gestão e comunicação com a

cloud que podem ser oferecidas pelos CSPs ou consistir em bibliotecas open-source, são

alvo de ataques às credenciais de autenticação e aos dados do cliente na cloud, em caso de

falha nos mecanismos de segurança implementados nessa interface [16].

4. Partilha de Tecnologias - A partilha de infraestruturas e recursos computacionais em ar-

quiteturas multi-tenant pode permitir o acesso não autorizado ao conteúdo pertencente a um

dado cliente, por parte de outros clientes. É uma consequência da falta de propriedades de

isolamento dos hypervisores utilizados na virtualização, das partições de discos, de caches

e da própria rede do data-center [16].

5. Perda ou Fuga de Dados - Existem várias potenciais vulnerabilidades para o comprometi-

mento dos dados. Operações como eliminação ou alteração de dados armazenados na cloud

sem que exista um mecanismo de backup ou então, a falta de métodos criptográficos que

assegurem a confidencialidade, integridade e autenticidade dos dados, fazem com que esta

ameaça possa ter, em caso de concretização, um impacto irreversível no serviço [16].

6. Hijacking de Contas e Serviço - O roubo de credenciais através de ataques como phishing,

exploração de vulnerabilidades do software e outros tipos de fraude, continuam a sortir

efeito nos serviços disponibilizados em cloud. Na concretização da ameaça, um adversário


poderia, por exemplo, assumir a identidade do utilizador proprietário da conta associada ao

serviço e executar vários tipos de ataques em nome do mesmo [16].

7. Falhas de Hardware - Falhas nas tecnologias físicas (ex. routers, servidores), podem colo-

car em causa a disponibilidade dos dados em cloud [17].

8. Desastres Naturais - Causas naturais (ex. furacões, cheias, descargas elétricas), podem pôr

em risco a segurança das infraestruturas físicas das clouds [17].

9. Desenho e Planeamento das Infraestruturas Inadequados - Situações de overload devido

à deficiência na disponibilização de recursos computacionais ou falhas no desenho da rede

do serviço cloud [17].

2.3.3 Tecnologias Criptográficas

Faz-se neste ponto, o levantamento das tecnologias criptográficas que permitem colmatar pos-

síveis vulnerabilidades relacionadas com a confidencialidade, integridade e autenticidade dos da-

dos, e outras que procuram manter otimizado, o nível de disponibilidade dos dados. São descritas

técnicas clássicas de criptografia que continuam em uso e técnicas recentes, estas últimas com

maior fator de adaptabilidade à computação em cloud.

2.3.3.1 Algoritmos para Encriptação dos Dados

São dois os algoritmos de encriptação mais comuns. Por cada algoritmo são dados exemplos

de cifras e outros mecanismos criptográficos considerados seguros na atualidade:

• Encriptação Simétrica - O algoritmo de encriptação simétrica é um tipo de cripto-sistema

em que a encriptação e a desencriptação são feitas usando a mesma chave. A encriptação de

um texto em claro é realizada recorrendo a uma chave secreta com tamanho em número de

bits suficientemente grande para serem evitados ataques de força bruta, onde são testadas re-

cursivamente várias chaves até ser encontrada a chave correta. A chave secreta é distribuída

por um canal seguro, diretamente de forma física entre as entidades comunicantes ou recor-

rendo a uma terceira entidade de confiança com a responsabilidade de fazer a distribuição.

Nas cifras simétricas distinguem-se algoritmos apropriados para comunicações síncronas

que fazem a encriptação byte-a-byte ou bit-a-bit (ex. RC4), e algoritmos apropriados para

comunicações assíncronas e envio de ficheiros ou segmentos de dados de tamanho conside-

rável (ex. AES/CBC). As cifras simétricas assíncronas consideradas seguras pelo NIST e

recomendadas para o uso na encriptação de dados, são as seguintes:

– Triple DES - A cifra consiste em três implementações do algoritmo DES de forma se-

quencial, usando três chaves distintas, cada uma com o tamanho de 56 bits, perfazendo

uma chave efetiva de 168 bits de tamanho [15].

– AES/CBC/256 - A cifra faz uso de uma chave de 256 bits e atua no modo de operação

cipher block chaining (CBC) onde o segmento de dados em questão é repartido por


blocos de 128 bits, esses blocos são encriptados recorrendo à chave secreta e a um

vetor de inicialização [15].

Texto

claro

AES/CBC/256

K

Chave partilhada

entre remetente

e destinatário

Chave partilhada

entre remetente

e destinatário

Encriptação

AES/CBC/256

Desencriptação

Texto

claro

X Y = E ( K , X ) X = D ( K , Y )

Transmissão do texto encriptado

K

Figura 2.7: Modelo simplificado do processo de encriptação simétrica.

O nível de segurança elevado das cifras anteriores é um fator que pode, nem sempre, ser

favorável. De facto, a encriptação segura pode ter impacto na cloud ao nível das funciona-

lidades (ex. pesquisa de informação encriptada). Portanto, deve existir sempre um trade-off

entre o nível de segurança e funcionalidades que se pretendem ver implementadas. Na prá-

tica, são feitas alterações e adaptações às cifras seguras, tornando-se mais flexíveis, mas

também, mais vulneráveis a ataques com base em métodos estatísticos. Recorrendo a um

relatório da Skyhigh Networks, empresa de segurança na cloud sediada nos EUA, são lis-

tadas adaptações a cifras seguras e outras recomendações de algoritmos, que permitem a

existência das funcionalidades essenciais da cloud. Na Figura 2.8 é apresentado um gráfico

trade-off entre as várias implementações sugeridas.

– Encriptação Seletiva - Num conjunto de dados faz-se a encriptação de um segmento

mais sensível em relação aos restantes segmentos (ex. número de identificação bancá-

ria). É uma adaptação usada na cifra AES [18].

– Format Preserving Encryption (FPE) - É um método de encriptação que preserva o

tamanho e o formato do texto original. Pode ser útil em funcionalidades de serviços

em cloud que requerem o mesmo formato do texto em claro, no texto encriptado. É

um standard adotado pelo NIST como modo de operação de cifras simétricas (modo

FFX)[18].

– Searchable Encryption - Sacrifica-se o nível de segurança imposto pelas cifras men-

cionadas para se conseguir efetuar pesquisa eficiente sobre os dados encriptados. São

utilizadas várias aproximações que se distinguem pela maior ou menor redução do

nível de segurança do algoritmo de encriptação [18]:

1. Uso de keywords.


2. Pesquisa palavra a palavra.

3. Indíces locais ou tokenization.

4. Pesquisa por prefixo.

– Order-Preserving Encryption (OPE) - Adaptação à cifra AES que permite a existên-

cia de pesquisa eficiente, isto porque, no caso de existência de uma ordem na orga-

nização dos dados, nos textos em claro, essa ordem é preservada nos textos encripta-

dos [18].

– Fully Homomorphic Encryption (FHE) - Método de encriptação que recorre a uma

função específica para pesquisa dos dados encriptados. Este é o formato idealizado

pela comunidade global ligada à investigação de algoritmos criptográficos uma vez

que não seria necessária uma redução drástica da segurança das cifras para a realiza-

ção de pesquisas eficientes sobre os dados encriptados. Contudo este método ainda

está longe de ser adotado pelas empresas devido à fraca performance que apresenta

tendo em conta os recursos computacionais atualmente existentes [18]. Ainda assim,

a FHE continua a ser alvo de investigação. Um exemplo do uso da FHE pode ser

estudado numa publicação com origem no projeto "Practice" com o nome de "Secure

Deduplication of Encrypted Data without Additional Independent Servers" [19].

Se

gu

ran

ça (

ap

roxi

ma

da

me

nte

)

Funcionalidades (aproximadamente)

Standard

(ex. AES/CBC/256)Encriptação seletiva

FHE

OPE

Searchable Encryption

FPE

Figura 2.8: Ilustração do trade-off existente nas várias cifras e adaptações descritas (ilustraçãoinspirada no relatório da SkyHigh Networks).

• Encriptação Assimétrica - Neste tipo de algoritmo, cada entidade comunicante deve pos-

suir duas chaves: uma chave pública e uma chave privada. Para garantir confidencialidade

dos dados, os mesmos são encriptados no remetente recorrendo à chave pública do des-

tinatário. A entidade de destino usa o seu par privado para efetuar a desencriptação dos

dados. O processo contrário, ou seja, a encriptação feita no remetente recorrendo à chave


privada do remetente, não garantiria confidencialidade (qualquer entidade poderia desen-

criptar o texto recorrendo à chave pública do remetente porque a mesma é pública), mas

garantiria autenticidade dos dados uma vez que a chave privada corresponde apenas à en-

tidade remetente. Este tipo de cifra obriga à existência de estratégias de gestão de chaves

públicas que normalmente recorrem a certificados x509 atribuídos por uma autoridade de

certificação. O uso deste sistema para encriptação de grandes quantidades de dados não é

sugerido devido à latência introduzida pelo mecanismo de troca de chaves. Deve ser usado

por exemplo, como canal seguro para troca de uma chave simétrica que possibilitaria a reali-

zação de encriptação simétrica. Um exemplo de um cripto-sistema assimétrico é o algoritmo

Rivest-Shamir-Adleman (RSA) [15].

Texto

claro

RSA

Chaveiro

da entidade

A

Chave privada

da entidade

B

Encriptação

RSA

Desencriptação

Texto

claro

X Y = E ( PUB , X ) X = D ( PRB , Y )

Transmissão do texto encriptado

Chaveiro

da entidade

A

PUB PRB

Figura 2.9: Modelo simplificado do processo de encriptação assimétrica com confidencialidadegarantida.

2.3.3.2 Ferramentas para Encriptação do Disco

Existem ferramentas específicas de encriptação dos dados num disco de armazenamento. A

encriptação do disco assegura que todos os ficheiros depositados num determinado diretório pro-

tegido da file system presente no sistema, são guardados no disco num formato encriptado através

da execução de algoritmos de encriptação simétrica. Os dados ficam disponíveis em formato de

texto claro após um processo de autenticação por um utilizador creditado que normalmente passa

pela disponibilização de uma password responsável por encriptar e desencriptar as chaves crip-

tográficas simétricas. No contexto das ferramentas de encriptação do disco, existem dois tipo de

soluções que se diferenciam pela granularidade da encriptação:


• Encriptação ao Nível da File System - Consiste na implementação de uma camada de en-

criptação sobre uma file system existente (ex. file system ext4), que faz com que todos os

ficheiros escritos num diretório com encriptação ativa, sejam encriptados antes de ser re-

alizada a escrita propriamente dita, no disco. A encriptação é feita on-the-fly partindo da

disponibilidade permanente de chaves criptográficas armazenadas, normalmente de forma

encriptada, no próprio sistema, e que são geridas a partir de uma funcionalidade associada

a um determinado sistema operativo (ex. keyctl do Linux Kernel). A interação do utili-

zador com a ferramenta é feita apenas no momento em que é efetuado o mounting sobre

um diretório pertencence à estrutura da file system existente, em que o mesmo deve inserir

uma password secreta. O processo de mounting consiste na montagem de uma determinada

partição de um disco de armazenamento, num diretório organizado pela estrutura da file

system presente no sistema, de modo a que os dados armazenados no disco possam ficar

disponíveis num formato manipulável ao utilizador. Os dados dos ficheiros introduzidos no

diretório após ser efetuado o mounting da ferramenta de encriptação, são armazenados na

partição do disco correspondente, num formato encriptado. A partir do diretório protegido

continuar-se-á a visualizar os ficheiros num formato em texto claro, porém, qualquer tenta-

tiva de mounting da partição do disco correspondente aos dados protegidos, noutro diretório,

sem que seja utilizada a mesma ferramenta ou caso seja utilizada a mesma ferramenta mas

sem inserção correta da senha do utilizador, resulta na exposição dos dados dos ficheiros

num formato encriptado. Duas das ferramentas open-source disponíveis no mercado são:

eCryptfs e EncFS [20].

• Encriptação ao Nível do Dispositivo de Armazenamento - A encriptação ocorre na ca-

mada inferior em relação à camada da file system presente e garante que todos os dados

escritos num dispositivo de armazenamento são encriptados. O processo que leva à im-

posição de uma camada de proteção dos dados de ficheiros no sistema é em tudo idêntico

ao descrito nas ferramentas de encriptação de file system, apenas o diretório protegido não

pertence à estrutura organizada da file system existente. Esta solução possui um nível de

granularidade mais fino, sendo impossível distinguir sequer quais as características em ter-

mos de configurações do software, ou seja, a meta-data em vigor no sistema devido ao

facto de a encriptação ser realizada numa camada inferior à da file system. Das ferramentas

open-source de livre uso comercial, destacam-se: dm-crypt e TrueCrypt [20].

2.3.3.3 Integridade e Autenticidade dos Dados

A violação da integridade dos dados implica também que o remetente deixe de ser o original

pelo que, a verificação da integridade pode ser vista também como a verificação da autenticidade

dos dados. Existem dois métodos que são amplamente usados:

• Função de Hash - Uma função que aceita como parâmetros de entrada segmentos de dados

de tamanho variável, produzindo à saída um código de tamanho fixo chamado código de

hash. Uma boa função de hash produz outputs distribuídos uniformemente e de natureza


aleatória. A alteração de bits num segmento de dados implica que o código de hash gerado

seja diferente do gerado aquando do segmento original, o que permite a criação de um meca-

nismo criptográfico de verificação da integridade. Um dos algoritmos de hash mais usados

na atualidade é o SHA-3 ou SHA256, que produz um código aleatório de 256 bits [15].

• Message Authentication Code (MAC) - É um algoritmo que recebe um segmento de dados

de tamanho variável e uma chave secreta como inputs e gera um código de autenticação.

Combina o uso de uma função de hash criptográfica com o algoritmo de encriptação si-

métrica. Um dado segmento de dados pode ser autenticado no destinatária fazendo o uso

da chave simétrica destinada ao MAC. Existem várias funções que podem gerar o código

de autenticação sendo que a mais usada é uma função de hash adaptada ao contexto de

autenticação de mensagens, HMAC [15].

Texto claro

K

MAC

| |X

X

MAC( K , X )MAC( K , X )

X

MAC

K

Comparar

X

Figura 2.10: Esquema de implementação do MAC sem confidencialidade garantida.

2.3.3.4 Autenticação e Controlo de Acesso

Para estabelecer o acesso controlado às aplicações em cloud exige-se a imposição de regras

aos utilizadores. A RFC 2828 define autenticação do utilizador em dois passos: identificação

e verificação. A identificação consiste no fornecimento de dados que identifiquem o utilizador,

normalmente um username do utilizador e uma forma de autenticação do mesmo que pode con-

sistir por exemplo, em passwords, elementos biométricos ou ainda cartões eletrónicos. O passo de

verificação consiste na confirmação da validade dos identificadores do utilizador fazendo a com-

paração com os dados guardados num servidor. Em sistemas implementados sobre infraestruturas

de redes, os métodos de autenticação do utilizador envolvem algoritmos criptográficos (ex. cifra

simétrica), para que a troca de dados entre utilizador e o sistema ocorra de forma confidencial.


O Kerberos é um exemplo de um protocolo para autenticação dos utilizadores na rede e con-

siste numa sequência de operações entre clientes e um dispositivo central (ex. servidor LDAP),

baseados em algoritmos criptográficos [15]. Torna-se importante de igual forma a utilização de

estratégias para recuperação das credenciais de um utilizador, em caso de perda ou comprometi-

mento das mesmas. A tendência atual é o uso de procedimentos self-service password recovery,

que permitem por exemplo, efetuar o reset das credenciais comprometidas através do envio de um

desafio para o e-mail associado ao utilizador. O LDAP Tool Box project possui uma aplicação em

PHP que permite ao utilizador alterar a sua password num diretório LDAP [21].

Para além da autenticação de utilizadores é necessário de igual forma ter em conta mecanismos

de autenticação de alvos distintos, principalmente quando a maioria dos elementos que compõem

a infraestrutura da cloud são parte integrante de um serviço fornecido por um dado CSP, ou seja,

localizam-se num espaço remoto. Um exemplo de um elemento que deve ser autenticado sempre

que haja um boot do sistema é o próprio host do ambiente de virtualização. A perspetiva de

autenticação doutros elementos que não apenas o utilizador é defendida pela CSA que recomenda,

por exemplo, o uso de dispositivos com procedimentos de autenticação implementados como o

exemplo do hardware security module (HSM), dispositivo com o intuito de proteger e gerir chaves

criptográficas [22].

2.3.3.5 Gestão de Chaves Criptográficas

O processo de gestão de chaves é a parte mais crítica da implementação de técnicas criptográ-

ficas para a segurança dos dados na cloud. O acesso de um intruso ao sistema de armazenamento

de chaves, comprometeria todos os dados armazenados num serviço disponibilizado em cloud. A

CSA define um conjunto de regras que devem ser seguidas para o estabelecimento de uma boa

política de gestão de chaves criptográficas [22]:

1. Uma organização deve definir políticas de gestão de chaves escolhendo algoritmos apropri-

ados para o envio seguro de chaves e o ciclo de vida associado a cada uma.

2. A geração de chaves criptográficas deve recorrer a geradores "pseudo-aleatórios" adequa-

dos, que cumpram os critérios de colisão e imagem única.

3. As chaves criptográficas nunca devem ser armazenadas e enviadas em claro.

4. As chaves criptográficas devem ser armazenadas num HSM, um dispositivo físico adaptado

às funcionalidades de gestão chaves criptográficas, com possibilidade de ligação à rede.

5. O acesso ao espaço de armazenamento de chaves deve ser concedido apenas a utilizadores

devidamente autorizados recomendando-se no mínimo, dois utilizadores autorizados, para

diminuírem as possibilidades de conspirações individuais internas, numa dada organização.

6. As chaves criptográficas devem ser guardadas no local de armazenamento de chaves dedi-

cado à técnica criptográfica em que se enquadram.


7. O serviço de gestão de chaves deve estar acordo com os standards correntes definidos pelo

NIST e pelo conjunto de normas definidas no Federal Information Processing Standard

(FIPS).

2.3.4 Disponibilidade e Backups dos Dados

Para ser assegurado o requisito de disponibilidade dos dados, é também necessário recorrer a

procedimentos que não envolvam diretamente o uso de técnicas criptográficas. O conhecimento

de algoritmos que geram redundância no armazenamento e permitem o backup dos dados, é um

fator a ter em conta para compreensão dos mecanismos de segurança que devem ser adotados para

manutenção de um nível ideal de disponibilidade dos dados.

2.3.4.1 Operações nos Discos

A estratégia básica para o aumento da redundância e desempenho nas operações efetuadas

sobre o armazenamento num disco consiste na aproximação a um modelo linear onde o número

de cópias N, considerando um custo C por cópia, teria um custo de armazenamento total de N×C.

Atualmente, as estratégias postas em prática para redundância de dados nos discos envolvem um

custo inferior ao modelo linear e consistem essencialmente, em duas abordagens:

• Redudant Array of Independent Disks (RAID) - Para além de replicar os dados por dois ou

mais discos, permitindo com que possam ser recuperados em caso de falha de um ou mais

discos, o RAID privilegia o aumento da performance no acesso aos dados armazenado. A

estratégia consiste na substituição de um disco de grande capacidade por vários discos de

capacidade inferior (striping). O armazenamento é feito contiguamente pelos vários dis-

cos de capacidade de armazenamento inferior (mirroring). Existem vários níveis de RAID

que se distinguem pelo desempenho em termos de leitura, escrita, reconstrução de falhas,

disponibilidade de dados e número mínimo de unidades de disco necessárias [23].

• Técnicas de Codificação - São técnicas que providenciam redundância sem que seja neces-

sário replicação completa dos dados, eliminando-se algum overhead, tornando-se as opera-

ções mais eficientes. Nestas técnicas, um segmento de dados é dividido em m fragmentos

que são codificados em n novos fragmentos redundantes onde n > m. Define-se o rácio de

codificação como sendo:

r =mn< 1,

e o custo total da redundância passa a ser:

1r.

Os dados originais podem ser recuperados recorrendo a m fragmentos de um total de n. Os

algoritmos Reed-Solomon e Cauchy Reed-Solomon são exemplos de técnicas de codifica-

ção [24].


Na escolha da estratégia para estabelecimento de um mecanismo de backup de dados é preciso

ter em conta dois fatores determinantes:

1. Resistência a Falhas - Os diferentes algoritmos apresentam graus de resistência a falhas

distintos [24].

2. Performance - A rapidez do algoritmo nos processos de leitura, escrita e recuperação de

falhas é determinante, porém, deverá existir um trade-off entre o nível da performance e o

número de unidades de armazenamento necessárias para atingir essa performance, para que

sejam evitados custos desnecessários, aquando da escolha do algoritmo [24].

2.3.4.2 Ferramentas para Backups dos Dados

Um dos objetivos da dissertação é fornecer mecanismos que sirvam de suporte a à realização

de backups dos dados na cloud do cliente da IPBrick SA. Estes mecanismos são particularmente

úteis quando se pretende efetuar o restauro dos dados a partir de um ponto específico no tempo.

No mercado das clouds já existem CSPs que cobram serviços de backups dos dados ao nível

empresarial. A estratégia é simples e consiste em múltiplas cópias de dados espalhadas por in-

fraestruturas de vários IaaS ou PaaS providers. Para contornar os potenciais custos associados a

um CSP, utilizam-se ferramentas com licença open-source, que se baseiam na grande maioria, no

algoritmo rsync criado por Andrew Tridgell and Paul Mackerras e anunciado no dia 19 de Junho

de 1996. Este algoritmo permite realizar backups incrementais de dados remotamente localizados,

sincronizando o espaço de armazenamento do backup, apenas copiando os segmentos de dados

mais recentes armazenados na cloud. Existem várias ferramentas que se baseiam especificamente

neste algoritmo ou em variações do mesmo. Das variações existentes destacam-se a implementa-

ção de técnicas de criptografia simétrica sobre os dados armazenados em backup. São exemplos

de ferramentas [25]:

• Rsync - É uma ferramenta open-source de transferência de ficheiros que segue o algoritmo

original rsync e mantém um diretório sincronizado funcionando como um espelho em rela-

ção à fonte dos dados. Não existem mecanismos de encriptação associados ao backup [26].

• Bacula - Uma solução open-source implementada em C++ para backups incrementais. Pos-

sui funcionalidades de encriptação dos dados quer em transferência, quer em armazena-

mento [27].

• BackupPC - Ferramenta open-source para backup de ficheiros implementada em Perl. Per-

mite a transferência de ficheiros através do protocolo SSH e disponibiliza uma interface

gráfica para gestão dos backups [28].

• Obnam - Um programa para execução de backups que providencia um snapshot dos da-

dos num determinado ponto temporal. A transferência dos dados do espaço remoto é

feita via protocolo SSH e são armazenados encriptados com uso do protocolo Gnu Privacy

Guard [29].


Uma lista mais extensa das ferramentas disponíveis pode ser obtida no website da organiza-

ção associada à distribuição do sistema operativo Linux, designada por Arch Linux. Listaram-se

previamente as que foram alvo de testes de integração no software IPBrick da IPBrick cloud [25].

2.3.5 Classificação dos Dados

A computação em cloud é um fenómeno que surgiu graças à conjugação de várias tecnologias

(ex. redes de comunicação, servidores de armazenamento, servidores de virtualização). A inter-

ligação dessas tecnologias forma um sistema complexo que torna exigente a tarefa de controlo

sobre os dados que o constituem. Para diminuir a dificuldade de implementação de mecanismos

criptográficos que mantenham os dados seguros, deu-se uma importância individualizada aos es-

tados ou fases que os mesmos podem assumir durante o seu ciclo de computação na cloud. Sendo

assim, para um melhor tratamento dos dados ao nível segurança, mais concretamente, ao nível da

encriptação, a CSA sugere a diferenciação dos dados na cloud em três fases [30]:

• Dados em Repouso - São os dados que se encontram armazenados de uma forma persistente

através de métodos de armazenamento estruturados (ex. base de dados) ou não estruturadas

(ex. file systems), fazendo-se uso de discos físicos ou virtuais para armazenamento. O

uso ou processamento dos dados acontece esporadicamente e num período alargado após

efetuado o armazenamento. A CSA recomenda a existência de mecanismos que garantam

a confidencialidade dos dados em repouso na cloud quando a sensibilidade dos mesmos

assim o exige, o estabelecimento de uma política de controlo de acesso aos dados utilizando

protocolos de autenticação seguros e a verificação da integridade imediatamente antes do

período de processamento [30].

• Dados em Trânsito - Dados que se encontram sobre um processo de transferência de um re-

positório de dados para outro. Os repositórios podem consistir em: servidores de back-end,

aplicações, e bases de dados, todos interligados por redes comuns ou por redes distintas.

Os dados sensíveis em trânsito devem ser protegidos, especialmente quando a transferência

de dados ocorre sobre infraestruturas de redes públicas ou partilhadas. A proteção deve ser

implementada recorrendo aos protocolos de comunicação seguros (ex. IPSec, SSL/TLS),

que formam túneis de comunicação impenetráveis, ou recorrendo a algoritmos de encripta-

ção de dados (ex. encriptação simétrica). Do ponto de vista da encriptação, a integridade

e autenticidade dos dados são requisitos particularmente críticos nesta fase pelo que devem

ser asseguradas estratégias de verificação dos mesmos (ex. MAC, encriptação assimétrica).

Segundo a CSA, um CSP deve ser capaz de proteger os dados em trânsito nas várias comu-

nicações realizadas pelo cliente no serviço disponibilizado em cloud [30].

• Dados em Uso - Consistem nos dados que se encontram na fase de processamento pelo

software ou aplicações do serviço em cloud disponibilizado pelo CSP. A CSA recomenda

a encriptação dos dados sensíveis em uso, no entanto, deve ser tido em conta o forte re-

quisito da disponibilidade dos mesmos para que não exista interrupções no funcionamento


do serviço fornecido ao cliente. No que toca à exigência em termos de disponibilidade

destes dados, técnicas de encriptação simétrica que procuram aumentar o desempenho dos

processos criptográficos (ex. encriptação seletiva, format preserving encryption, searchable

encryption), devem ser colocadas em prática [30].

Dados em

Repouso

Dados em

Trânsito

Dados em

Uso

Arquivos

Backups

e-mailsDados em

tempo Real

Con!gurações

de sistema

Con!gurações

de Aplicações

Figura 2.11: Ciclo dos dados ao longo da cloud com exemplos de dados tipicamente associados acada fase.

2.4 Conclusão

Tendo em conta o âmbito da dissertação, o presente capítulo fornece uma contextualização

pormenorizada daquilo que é a cloud, o seu funcionamento, as tecnologias que a constituem, e as

possíveis medidas de segurança que podem ser implementadas nas suas infraestruturas.

A sequência imposta na abordagem dos vários tópicos do presente capítulo serve para estabe-

lecer uma reconstituição exata da cloud e dos mecanismos de segurança que podem ser englobados

de forma a proteger os dados independentemente do local ou fase do ciclo de vida em que possam

estar.

A importância desta etapa é inquestionável sendo que, a partir do conhecimento adquirido

sobre o tema, das ferramentas e tecnologias descritas ao longo deste capítulo, e da contextualização

da IPBrick cloud no que toca à estratégia da IPBrick SA, torna-se possível idealizar uma proposta

de solução que vá de encontro aos objetivos pré-estabelecidos para a presente dissertação.

Capítulo 3

Projeto e Estrutura da Solução

O presente capítulo expõe o conjunto de etapas necessárias para o desenvolvimento e con-

cretização de um modelo-solução teórico baseado no conjunto de tecnologias revistas no capítulo

anterior, e que servirá como resposta aos objetivos definidos na presente dissertação e base de

suporte ao desenvolvimento de protótipos de prova conceptual, no software IPBrick da IPBrick

cloud.

3.1 Introdução

Após o capítulo de revisão da tecnologia atual relacionada com o tema da dissertação, reúnem-

se as condições para a execução de todo um conjunto de processos que visam garantir a solidez

de um modelo-solução teórico, tendo em conta os objetivos pré-delineados. Posto isto, o presente

capítulo possui a seguinte organização em termos de conteúdo:

1. Estudo e contextualização das aplicações e dos dados na IPBrick cloud.

2. Abordagem de possíveis estratégias de segurança a implementar na IPBrick cloud, nomea-

damente no que diz respeito à encriptação dos dados, backups dos dados, e mecanismos de

autenticação na cloud.

3. Avaliação de ferramentas de encriptação de dados.

4. Definição das estratégias e ferramentas a adotar no modelo-solução e representação gráfica

do modelo.

Procura-se através de uma análise ao tipo de aplicações e de dados existentes no modelo em

cloud do software IPBrick, optar pela estratégia de encriptação que melhor se adequa, fazendo uso

de uma ou mais ferramentas que serão escolhidas tendo como pesos, a apreciação global das suas

funcionalidades e os resultados de testes de desempenho efetuados sobre as mesmas. Pretende-se

igualmente definir a estratégia para realização de backups dos dados da IPBrick cloud que deverá

fazer o incremento do fator disponibilidade associado aos dados do cliente na cloud. O capítulo

29

30 Projeto e Estrutura da Solução

termina com a representação e descrição do modelo-solução teórico que servirá como suporte ao

desenvolvimento de protótipos de demonstração, na IPBrick cloud.

3.2 Aplicações e Dados da IPBrick Cloud

Para determinar a estratégia ou as múltiplas estratégias de encriptação a seguir, deve efetuar-

se o estudo aprofundado do tipo de aplicações disponibilizadas ao cliente e do tipo de dados

armazenados, enviados e processados pelas mesmas, que constituem o software IPBrick no seu

modelo em cloud. O software IPBrick baseia-se na distribuição Debian do sistema operativo

Linux. A organização de ficheiros do software IPBrick é estabelecida a partir da file system ext4

para sistemas operativos Linux.

3.2.1 Tipos de Aplicações

As aplicações disponibilizadas através do software podem distinguir-se quanto ao tipo de sin-

cronismo que lhes estão associadas. Na Tabela 3.1 faz-se a distinção entre as exemplos de aplica-

ções em tempo real e exemplos de aplicações assíncronas que são disponibilizadas ao cliente na

IPBrick cloud.

Tempo Real AssíncronasVoIP E-mail

Videoconferência FaxGestor de FicheirosGestor de Backups

Websites

Tabela 3.1: Distinção entre exemplos de aplicações da IPBrick cloud tendo como base o sincro-nismo adjacente.

3.2.2 Dados da IPBrick Cloud

Os dados produzidos a partir do uso das aplicações pelo cliente, ou seja, os dados que per-

tencem ao cliente, são armazenados quer nos diretórios dedicados ao armazenamento de dados de

contas de utilizadores nos sistemas operativos Linux, no caso do software IPBrick, "/home1" e

"/home2", quer na base de dados que interage com as aplicações, estando a mesma alojada num

sub-diretório localizado no diretório principal "/var". Na Tabela 3.2 faz-se a distinção de da-

dos existentes na IPBrick cloud segundo os critérios de classificação de dados descritos no ponto

2.3.5. Os dados são classificados tendo em conta as características intrínsecas ao serviço em que

se enquadram. Por exemplo, os e-mails pelas características que possuem associadas ao serviço

de E-mail são dados particularmente sensíveis e com grande grau de exposição quando estão em

trânsito sendo classificados como dados em trânsito, no entanto, este fator não impede com que

3.3 Estratégias para Encriptação dos Dados na IPBrick Cloud 31

possam ficar arquivados durante um largo período de tempo ou processados de forma esporádica

aquando, por exemplo, de uma leitura pelo destinatário do e-mail. Por outro lado, os dados de

ficheiros em arquivo (ex. faturas, inventários, relatórios de contas), passam grande parte do seu

tempo em armazenamento sem que sejam processados ou enviados, por este motivo são classifi-

cados como dados em repouso.

Dados em Repouso Dados em Trânsito Dados em UsoArquivos E-Mails Configurações de Sistema

Logs Antigos do Sistema Faxes Configurações de AplicaçõesBackups Dados em Tempo Real Logs de Aplicações

Tabela 3.2: Classificação dos diferentes tipo de dados associados à IPBrick cloud.

Os dados em uso e parte dos dados em trânsito estão particularmente associados às aplicações

em tempo real que possuem fortes requisitos de disponibilidade e atraso reduzido. Por este motivo,

esses mesmos dados devem estar também eles operáveis num fator percentual de disponibilidade

equivalente ao das aplicações. A possível escolha de uma estratégia de encriptação dos dados

processados pelas aplicações em tempo real deve ter em conta esta análise.

3.3 Estratégias para Encriptação dos Dados na IPBrick Cloud

Tendo em conta o modelo em cloud do software IPBrick, podem ser adotadas diferentes es-

tratégias que divergem quer no algoritmo de encriptação em que se baseiam quer no local da

infraestrutura da cloud onde são implementadas. Assim, apresentam-se três estratégias que sur-

gem do conhecimento adquirido a partir do estudo efetuado sobre o estado da arte das tecnologias

relacionadas com o tema da dissertação.

3.3.1 Estratégia 1 - Encriptação na Extremidade do Cliente

Esta estratégia consiste na implementação de algoritmos de encriptação num dos extremos

de comunicação da cloud, neste caso, no dispositivo de acesso do cliente. Tendo em conta uma

perspetiva de alto-nível, os dados seriam encriptados imediatamente antes de transitarem para o

espaço remoto da cloud recorrendo a uma ferramenta que conseguisse implementar por exemplo, o

algoritmo de encriptação simétrica sobre os dados do cliente. Um exemplo prático desta estratégia

pode ser visto na referência associada ao presente excerto escrito, onde é feito o uso de uma

ferramenta de encriptação de file system, já abordada na secção 2.3.3.2 e que irá ser analisada ao

pormenor juntamente com outras ferramentas equivalentes no ponto 2.3.3.2 [31]. Um fator a ter

em conta nesta estratégia é o tipo de gestão de chaves criptográficas a adotar. Para ser mantida

uma das características essenciais da computação em cloud, a heterogeneidade no acesso referida

em 2.2.1, é necessário que o cliente disponibilize nos dispositivos que pretende ver com acesso

garantido, as chaves criptográficas juntamente com o algoritmo de encriptação implementado. Só


assim é possível garantir a correta encriptação e desencriptação dos dados em cada dispositivo

de acesso do cliente. Um outro mecanismo com grau de escalabilidade superior em termos de

garantias de acesso consistiria na disponibilização das chaves criptográficas juntamente com os

dados encriptados, na cloud. Para o correto funcionamento das aplicações disponibilizadas pela

IPBrick cloud num modelo SaaS, seria necessário que o cliente disponibilizasse as suas chaves

criptográficas num formato desencriptado, caso contrário a disponibilidade das aplicações estaria

comprometida.

Cliente

Mecanismos de encriptação e

desencriptação iguais aos

implementados nos dispositivos

do cliente, utilizando as chaves

criptográ$cas fornecidas pelo mesmo.

Gestão de chaves criptográ$cas

e mecanismos de encriptação e

desencriptação em todos os

dispositivos do cliente.

1

Sincronização dos dados

encriptados do cliente com

a IPBrick Cloud.

2

PaaS

VM

SaaS

Cliente

3

Figura 3.1: Encriptação dos dados na extremidade do cliente.

3.3.2 Estratégia 2 - Implementação do Algoritmo Full Homomorphic Encryption

Esta estratégia consiste num algoritmo criptográfico teoricamente adaptado ao contexto da

cloud, já referido em 2.3.3.1, que faz uso de uma ou mais cifras simétricas e garante a confidenci-

alidade, integridade e disponibilidade permanente (tríade CID), dos dados armazenados em cloud.

O grande argumento da FHE baseia-se no facto de os dados estarem sempre encriptados quando

localizados num ambiente remoto sem que exista a necessidade de desencriptação para o proces-

samento de informação, processamento de pedidos do cliente e de configurações essenciais ao

funcionamento de aplicações na cloud. O homomorfismo presente num algoritmo de encriptação

garante que seja possível, tendo Enc(x) e Enc(y), computar Enc(f(x,y)) em que f pode consistir

numa função de adição, multiplicação ou disjunção exclusiva. Esta condição de homomorfismo

3.3 Estratégias para Encriptação dos Dados na IPBrick Cloud 33

permite com que seja possível processar dados sem que seja necessário efetuar a desencriptação,

ou seja, no caso da cloud, o fornecimento de chaves criptográficas a terceiros por parte do cliente

(ex. IPBrick SA, CSP), deixa de ser estritamente necessário. A figura 3.2 ilustra uma possível im-

plementação da FHE. Apesar do idealismo subjacente a esta estratégia em que os dados só estão

em claro na máquina do cliente, esta abordagem não passa, pelo menos para já, de uma aproxima-

ção teórica àquilo que seria uma implementação dotada de um nível de segurança máximo, isto

devido às exigências de um forte poder de processamento para que as operações sobre o texto

encriptado sejam viáveis ao nível da cloud.

Gestão de chaves criptográ�cas


desencriptação em todos os

dispositivos do cliente.

Cliente

1

Dados processados pelas

aplicações no formato encriptado.

Não existe necessidadade de

armazenamento das chaves do cliente.

3


encriptados do cliente com

a IPBrick Cloud.

2

Não existe necessidadade de

armazenamento das chaves do client

PaaS

VM

SaaS

SaaS

Figura 3.2: Funcionamento conceptual da Full Homomorphic Encryption.

3.3.3 Estratégia 3 - Encriptação na Extremidade da IPBrick Cloud

Tendo em conta o modelo de negócio da IPBrick cloud já descrito em 2.2.7, uma das es-

tratégias possíveis consiste no desenvolvimento de processos criptográficos no próprio ambiente

de virtualização cloud. Recorrendo a ferramentas tais como, ferramentas de encriptação do disco

adaptadas ao contexto da virtualização do armazenamento, ou outras que consistem em algoritmos

de encriptação simétrica e assimétrica, a protocolos de gestão de chaves e a protocolos de auten-

ticação, seria possível garantir ao cliente a segurança ao nível da confidencialidade, integridade e

disponibilidade dos dados no seu espaço virtual da cloud, contra terceiros (ex. fornecedor PaaS

da IPBrick SA). A IPBrick SA seria responsável tanto pela gestão da encriptação na cloud como


das chaves criptográficas, no entanto, só o cliente, dono da sua VM na cloud, teria a capacidade

de desencriptar os seus dados através da introdução de uma senha secreta única e que só o mesmo

a possuiria. O cliente teria acesso a partir de qualquer dispositivo não sendo necessária a insta-

lação de ferramentas de auxílio aos processos criptográficos na sua máquina, nem tendo sequer a

responsabilidade da gestão de chaves criptográficas .

Cliente não necessita

de ferramentas de encriptação

nem de proceder à gestão das

chaves criptográ�cas nos seus

dispositivos de acesso.

Existência de chaves criptográ�cas


desencriptação na IPBrick Cloud.

Proteção dos dados é sempre feita

aquando e durante o armazenamento

na Cloud.

1 3

Cliente


em claro do cliente com

a IPBrick Cloud.

2

PaaS

VM

SaaS

Cliente

Figura 3.3: Encriptação do lado da IPBrick Cloud.

3.4 Estratégia para Backups dos Dados da IPBrick Cloud

3.4.1 Análise dos Requisitos

O estudo e implementação de uma estratégia de backup dos dados da IPBrick cloud foi um

dos objetivos definidos para a presente dissertação. De fato, os backups dizem muito a respeito

da segurança que se pretende na IPBrick cloud no que toca por exemplo ao requisito de dispo-

nibilidade dos dados. Isto porque, uma estratégia eficaz para execução de backups dos dados do

cliente na IPBrick cloud permitiria salvaguardar possíveis infortúnios, que pudessem colocar em

causa a disponibilidade dos dados e aplicações. Para a implementação adequada de uma solução

de backups devem ser definidos dois requisitos essenciais:

• Segurança dos Dados dos Backups - Os dados dos backups são tipicamente dados em

repouso pelo que deve ser disponibilizada uma funcionalidade que permita a imposição de

algoritmos criptográficos sobre os mesmos que garantam confidencialidade, integridade e

disponibilidade dos backups.

3.5 Estudo de Ferramentas Criptográficas 35

• Destino dos Backups - Importa também definir qual o destino dos dados dos backups reali-

zados por cada cliente na IPBrick cloud. Podem ser consideradas três arquiteturas distintas

de suporte à estratégia de backup dos dados tendo em conta o destino dos dados dos backups:

1. Cliente possui servidor individual de armazenamento de backups nas suas instalações

(ex. servidor NAS ).

2. IPBrick possui servidor dedicado ao armazenamento de backups de clientes nas suas

instalações (ex. servidor NAS).

3. O armazenamento dos backups é feito em espaço remoto na IPBrick cloud recorrendo

para isso a uma VM dedicada, fornecida pelo PaaS provider.

3.4.2 Ferramenta a Adotar

No ponto 2.3.4 referente ao capítulo da revisão bibliográfica, foram descritas tecnologias de

execução e gestão de backups. Num período inicial do desenvolvimento do trabalho, foram re-

alizados testes de integração no software IPBrick da IPBrick cloud, de várias ferramentas para

backups de dados, de livre uso comercial, destacando-se as seguintes já mencionadas em 2.3.4.2:

Obnam, BackupPC, Bacula, sendo que todas suportam como funcionalidades, a encriptação e

desencriptação dos dados dos backups e verificação da integridade dos mesmos aquando dos res-

tauros efetuados. Porém, na sequência de uma decisão interna decorrente de uma reunião de

atualização do trabalho desenvolvido, em que, perspetivando-se o futuro do software IPBrick no

que diz respeito à integração de uma tecnologia de gestão de backups, foi escolhida a ferramenta

para backups Bacula como sendo o agente principal da estratégia a delinear para a realização de

backups de dados na IPbrick cloud.

3.5 Estudo de Ferramentas Criptográficas

Existem várias tecnologias e diferentes modos de abordagem no que diz respeito à implemen-

tação de algoritmos criptográficos ao nível do software. Recorrendo por exemplo, a uma biblioteca

da linguagem de programação Java de nome Java Cryptography Extension, seria possível o desen-

volvimento de raiz de um protótipo de encriptação de dados. No entanto, partindo da filosofia ou

estratégia de negócio posta em prática pela IPBrick SA, a prioridade no que diz respeito ao desen-

volvimento do modelo-solução no software IPBrick deve ser dada às tecnologias ou ferramentas

com licença open-source para uso comercial existentes no mercado, efetuando-se posteriormente

uma moldagem dessas mesmas ferramentas ao software IPBrick na IPBrick cloud. Durante o capí-

tulo correspondente à revisão bibliográfica fez-se referência a ferramentas que podem ser úteis na

encriptação de vários tipos de dados da IPBrick cloud, mais concretamente em 2.3.3.2 e 2.3.4.2.

Neste ponto descreve-se o estudo feito sobre essas ferramentas e outras adicionais, que consiste

em análises fundamentadas em documentação existente e execuções de testes de desempenho. O

estudo permitirá definir qual ou quais as ferramentas que poderão integrar o modelo-solução a

propor no final deste capítulo.


3.5.1 Análise Qualitativa de Ferramentas de Encriptação do Disco

3.5.1.1 Descrição da Análise

Em 3.5 fez-se referência a ferramentas de encriptação do disco que podem assegurar um ou

vários dos seguintes requisitos relacionados com a segurança computacional: confidencialidade,

integridade e disponibilidade dos dados armazenados num disco de armazenamento. As seguintes

ferramentas são analisadas de forma qualitativa, neste ponto:

1. CryFs [32].

2. eCryptfs [33].

3. EncFS [34].

4. dm-Crypt [35].

5. TrueCrypt [36].

Na Tabela 3.3 recorre-se a indicadores comuns para avaliação das características e funcionali-

dades de cada ferramenta e comparação de cada uma com as restantes. A escolha dos indicadores

tal como as avaliações efetuadas a cada ferramenta segundo esses mesmos indicadores tiveram

como base a documentação disponibilizada pelos autores e um artigo sobre desempenho de fer-

ramentas de encriptação do disco disponibilizada pela página web da organização associada à

distribuição de software Linux, Arch Linux [37]. A "Performance Local" é um indicador de de-

sempenho da ferramenta no que diz respeito à encriptação dos dados num disco físico sem ligação

à rede. A "Performance na Rede" reporta a interoperabilidade de cada ferramenta com elementos

sistema ligados à rede (ex. NFS, samba shares, protocolo LDAP). Os restantes quatro indicado-

res avaliam o desempenho de cada ferramenta no que diz respeito ao nível segurança em termos

de confidencialidade e integridade, tanto dos dados em armazenamento no disco como da meta-

dados. Entende-se por meta-dados o conjunto de dados relacionados com o sistema que reportam

entre outros, o tipo de estrutura organizada dos diretórios, o tamanho dos ficheiros, as permissões

de ficheiros e o número de ficheiros em cada diretório. A avaliação de cada ferramenta a partir

dos indicadores de desempenho descritos é feita de forma qualitativa, considerando-se dois níveis:

"Boa" e "Fraca".

CryFS eCryptfs EncFS dm-crypt TrueCryptPerformance Local Boa Boa Boa Boa BoaPerformance na Rede Boa Boa Boa Fraca FracaConfidencialidade dos Dados Boa Boa Boa Boa BoaIntegridade dos Dados Fraca Fraca Fraca Fraca FracaConfidencialidade dosMeta-Dados Boa Fraca Fraca Boa Boa

Integridade dos Meta-Dados Boa Fraca Fraca Fraca FracaTabela 3.3: Avaliação qualitativa das ferramentas.


3.5.2 Testes de Desempenho sobre Ferramentas de Encriptação do Disco

3.5.2.1 Descrição dos Testes

Os testes de desempenho baseiam-se numa ferramenta de file system benchmarking que se

designa por Bonnie++. Entre outros, esta ferramenta permite a execução de testes de escrita,

leitura, reescrita e pesquisa sobre um dado diretório. São retornados valores de velocidade em

kB/s, médias ponderadas do uso do processador em valores percentuais e latências adjacentes

aos testes em questão representados na unidade de medida de tempo do sistema internacional de

unidades, o segundo. Nos testes de escrita e leitura são retornados valores de velocidade e uso

médio do processador quer por byte, quer por blocos de bytes.

Foram realizados testes nas seguintes ferramentas de encriptação do disco: eCryptfs, EncFS,

CryFS e dm-crypt, todos elas montadas previamente num diretório específico com estrutura orga-

nizacional estabelecida pela file system ext4, file system utilizada no software IPbrick da IPBrick

cloud. Para obtenção de um elemento de comparação base, foi realizado um teste isolado sobre a

file system ext4. A ferramenta TrueCrypt, analisada de forma qualitativa no ponto anterior, baseia-

se em estratégias de encriptação que assentam nos princípios de funcionamento do Linux Unified

Key Setup (LUKS), tal como a dm-crypt. Pelo facto de serem ferramentas muito semelhantes,

divergindo apenas em alguns parâmetros de segurança, só foram realizados testes de desempe-

nho sobre a dm-crypt. Os testes foram executados numa VM com as seguintes características de

virtualização:

• Guest OS - Debian Jessie Linux-3.16.0-4-amd64.

• Memória RAM Virtual - 1 GB.

• Memória Disco Rígido Virtual - 30 GB.

Um teste de escrita consiste na geração de forma recursiva de cerca de 16384 ficheiros, com

tamanho que pode variar entre 0 bytes e 10024 bytes, num diretório especificado através de um dos

parâmetros de entrada do comando definido para execução dos testes. O teste de leitura consiste

na leitura recursiva dos ficheiros gerados e o teste de reescrita consiste num teste de escrita em que

os ficheiros são eliminados de forma imediata e gerados novamente. O teste de pesquisa aleatória

faz uso de processos SeekProcCount em paralelo completanto um total de 8000 lseek()’s em locais

dos ficheiros especificados por Random(). Outros detalhes dos algoritmos que perfazem os tes-

tes de benchmarking suportados pela ferramenta Bonnie++, podem ser consultados na referência

associada ao presente parágrafo [38].

A credibilidade dos resultados depende de possíveis alterações do ambiente de testes para

cada ferramenta de encriptação do disco bem como dos elementos parametrizáveis. Em cada

ferramenta de encriptação do disco definiu-se a cifra de encriptação simétrica como sendo a AES

atuando em modo CBC com chaves criptográficas de tamanho equivalente a 256 bits. Os restantes

parâmetros bem como o ambiente de realização dos testes mantiveram-se idênticos para todos os

testes efetuados sobre as ferramentas de encriptação do disco em causa.


Admitindo que as ferramentas de encriptação do disco e a ferramenta Bonnie++ já se encon-

tram instaladas no sistema operativo, fica apenas a ser necessária a execução de dois comandos

na interface CLI para se proceder à execução dos testes. Tomando como exemplo a ferramenta

eCryptfs, os dois comandos necessários ao procedimento são os seguintes:

1.1 $ mount − t e c r y p t f s / home / home −o e c r y p t f s _ c i p h e r = a e s / cbc ,e c r y p t f s _ k e y _ b y t e s =32

2

Comando que faz a instalação ou a montagem da ferramenta de encriptação no diretório

do utilizador ,"/home". Os inputs do comando definem a cifra simétrica a utilizar AES

bem como o modo de atuação CBC e o número de bytes da chave simétrica, 32 bytes

correspondentes a 256 bits.

2.1 $ b on n i e ++ −d / home −u 0 −n 1 6 : 1 0 : 0 : 1 −m TesteX2

Comando para execução dos vários testes sobre o diretório "/home". Em " -n" define-se o

número de ficheiros em que 16 corresponde a 16384 ficheiros gerados, o tamanho máximo

de cada ficheiro em que 10 corresponde a 10024 bytes e o tamanho mínimo de cada ficheiro,

0 bytes. Em " -m" define-se o nome do teste a executar, neste caso, "TesteX".

3.5.2.2 Resultados

Os resultados dos testes bem como médias aritméticas associadas aos valores obtidos são, de

seguida, expostos em tabelas. Foram executadas três sequências de testes por cada ferramenta para

demonstração da consistência dos valores obtidos. Os valores presentes nas tabelas encontram-se

arredondados às unidades. Nos testes de escrita e leitura são reportados a velocidade (kB/s) e o uso

do processador (CPU) quer por byte (Char) quer por bloco de bytes (Bloco). Por cada ferramenta

representada indicam-se os resultados de três testes a que foi sujeita. Os ficheiros output obtidos a

partir dos testes podem ser observados nos anexos em B.


Teste de Escrita Teste de Leitura Teste de ReescritaChar Bloco Char Bloco

KB/s CPU kB/s CPU kB/s CPU kB/s CPU kB/s CPU45 16% 6648 1% 2609 55% 16989 2% 6891 2%

CryFS 45 16% 5654 1% 3663 77% 18299 2% 7437 2%43 16% 7534 1% 2811 58% 28749 1% 8934 1%19 13% 20959 5% 4007 87% 94691 4% 13370 3%

EncFS 18 13% 21462 6% 4200 84% 94158 4% 13836 3%18 13% 22217 6% 4272 90% 94280 4% 14184 3%23 99% 22865 43% 3012 78% 95653 96% 15120 37%

eCryptfs 23 97% 21590 41% 3549 91% 95959 96% 13656 34%23 99% 20203 37% 3561 96% 96566 96% 13478 33%

565 89% 13026 2% 3069 77% 117972 5% 14048 1%dm-crypt 593 94% 18641 3% 3071 78% 121005 5% 16637 1%

601 93% 9024 1% 3140 84% 120801 5% 16426 1%714 85% 24129 4% 4402 95% 349402 68% 19199 6%

ext4 782 94% 22019 4% 3932 89% 345922 68% 16841 5%688 83% 19963 3% 3877 87% 326984 62% 16499 5%

Tabela 3.4: Resultados dos testes de escrita, leitura e reescrita. Na coluna mais à esquerda estãorepresentadas as ferramentas testadas.

Teste de Escrita Teste de Leitura Teste de ReescritaChar Bloco Char Bloco

kB/s CPU kB/s CPU kB/s CPU kB/s CPU kB/s CPUCryFS 44 16% 6612 1% 3028 63% 21346 3% 7754 3%EncFs 18 13% 21586 6% 4160 87% 94376 4% 13797 3%

eCryptfs 23 92% 21552 41% 3374 88% 96059 96% 14085 35%dm-crypt 586 92% 13564 3% 3093 80% 119926 5% 15704 1%

ext4 728 87% 22037 4% 4070 90% 340769 66% 17513 5%Tabela 3.5: Média aritmética dos resultados obtidos na tabela 3.4.

A partir das tabelas 3.4 e 3.5 é possível retirar as seguintes conclusões:

• Na escrita de um byte, a dm-crypt apresentou os melhores desempenhos em relação às

restantes ferramentas enquanto que a CryFS conseguiu superar a EncFS e a eCryptfs. Na

escrita de blocos de bytes, tanto a EncFS como eCryptfs apresentaram desempenhos superi-

ores às restantes ferramentas. Em termos globais, a eCryptfs apresentou valores superiores

para o uso médio percentual das capacidades de processamento, a este nível a CryFS obteve

bons resultados.

• Na leitura de um byte, os resultados foram idênticos enquanto que na leitura de blocos

de bytes, a dm-crypt destaca-se novamente obtendo uma velocidade de leitura na ordem

da centena de MB/s, por outro lado, a CryFS apresenta o pior desempenho. Novamente a

eCryptfs apresenta valores do uso médio do CPU muito elevados.


• No teste de reescrita, a CryFS que apresenta desempenhos inferiores às restantes ferra-

mentas. A eCryptfs demonstra novamente um uso do CPU muito superior às restantes

ferramentas.

• Os testes sobre a file system ext4 de forma isolada, na sua maioria, apresentam melhores

resultados que a ext4 em conjugação com as restantes ferramentas.

Teste de Pesquisa AleatóriakB/s CPU kB/s CPU439 6%

CryFs 595 8% 617 8%817 9%436 9%

EncFs 447 9 419 8%373 7%653 144

eCryptfs 684 150% 623 136%532 115%648 12%

dm-crypt 526 11% 569 11%532 11%752 55%

ext4 821 68% 731 62%619 62%

Tabela 3.6: Resultados do teste de pesquisa aleatória.

A partir da tabela 3.6 é possível retirar as seguintes conclusões:

• A semelhança entre os valores médios da velocidade da pesquisa não permitem fazer

uma distinção clara entre as várias ferramentas testadas.

• Relativamente ao uso médio do CPU, destaque para a CryFS e EncFS sendo estas as que

apresentam melhor desempenho no que diz respeito ao uso percentual médio da capacidade

do processador, ao contrário da eCryptfs, apresentando novamente o desempenho mais fraco

a este nível.


Teste de Escrita Teste de Leitura Teste de Reescrita Teste P.A.Char Bloco Char Blocoms ms ms ms ms ms193 7145 63 517 5111 2271

CryFs 203 7696 34 278 2658 232196 6398 78 358 5075 197578 2659 38 57 1591 8794

EncFs 1103 794 61 76 971 7623716 1029 75 48 911 11865369 631 174 55 1470 502

eCryptfs 698 1692 5 44 1792 364402 913 7 39 1693 67229 54735 62 73 5704 37

dm-crypt 22,2 4106,0 15 64 4552 3423 11904 14 96 4275 6060 3149 46 40 902 639

ext4 17,0 941 53 50 1642 7047 3621 68 256,0 1494 79

Tabela 3.7: Latências associadas aos testes de escrita, leitura, reescrita e pesquisa aleatória (P.A.).Nos testes de escrita e leitura é reportada a latência (ms) quer por byte (Char) quer por bloco debytes (Bloco).

Teste de Escrita Teste de Leitura Teste de Reescrita Teste P.A.Char Bloco Char Blocoms ms ms ms ms ms

CryFS 195 6772 49 318 3866 215EncFS 647 912 49 53 941 8209

eCryptfs 386 772 6 41 1582 433dm-crypt 23 47916 14 68 4413 35

ext4 32 2045 49 45 1198 75Tabela 3.8: Média aritmética truncada das latência associadas aos testes de escrita, leitura, reescritae pesquisa aleatória (P.A.). Devido à variância existente nos valores da tabela 3.7, foi truncado paracada sequência de testes o valor correspondente à latência mais elevada para que as conclusõespudessem ser mais objetivas.

A partir da tabela 3.8 é possível retirar as seguintes conclusões:

• Na escrita de um byte, a dm-crypt apresentou um tempo médio de resposta inferior seguindo-

se a CryFS. Na escrita de blocos de bytes, a EncFS e eCryptfs obtiveram o melhor desem-

penho a este nível.

• Na leitura de um byte e de blocos de bytes a eCryptfs apresentou os valores médios mínimos

de latência.

• Na reescrita a EncFS apresentou melhor desempenho em relação às restantes ferramentas.


• Na pesquisa aleatória, a dm-crypt tem o melhor desempenho.

3.5.3 Conclusões e Considerações

Para além da análise qualitativa apresentada na Tabela 3.3, existem outros fatores teóricos que

podem ser determinantes na possível escolha de uma das ferramentas analisadas e que são aqui

enunciados:

• De momento, a EncFS é considerada insegura e a própria equipa de suporte recomenda que

seja evitada a sua utilização.

• A CryFS é recente (ano de 2015), e a sua versão atual não é considerada totalmente estável.

• Apenas a CryFS possui mecanismos de verificação da integridade da meta-dados do soft-

ware.

• A eCryptfs é utilizada para encriptação dos dados no disco do diretório "/home" do utiliza-

dor, na distribuição Ubuntu do sistema operativo Linux.

• TrueCrypt e dm-Crypt têm implementações ligeiramente diferentes das restantes. Estas

ferramentas não possuem a funcionalidade de sincronização de ficheiros o que implica que

aquando de uma nova encriptação, todos os ficheiros em armazenamento terão que passar

novamente pelo mesmo processo criptográfico.

Da análise dos resultados provenientes dos testes efetuados sobre as ferramentas de en-criptação do disco, retiram-se as seguintes conclusões:

• Dos valores de velocidade obtidos nos testes de escrita, leitura e reescrita executados, organizam-

se as ferramentas de forma sucessiva sendo que o primeiro lugar é atribuído à ferramenta

que apresentou os melhores resultados na globalidade:

1. dm-crypt.

2. EncFS.

3. eCryptfs.

4. CryFS.

3.6 Modelo-Solução 43

• No que diz respeito ao uso médio do processador na globalidade dos casos, organizam-se

as ferramentas de forma sucessiva sendo que o primeiro lugar é atribuído à ferramenta que

apresentou melhores resultados:

1. EncFS.

2. CryFS.

3. dm-crypt.

4. eCryptFs.

• Tendo em conta as latências obtidas nos testes de escrita, leitura, reescrita e pesquisa alea-

tória efetuados, as ferramentas organizam-se da seguinte forma em que o primeiro lugar é

atribuído à ferramenta que apresentou melhores resultados:

1. eCryptfs.

2. EncFS.

3. dm-crypt.

4. CryFS.

3.6 Modelo-Solução

3.6.1 Decisões sobre Estratégias e Ferramentas a Adotar

Das análises e descrições elaboradas nos pontos anteriores do presente capítulo surgem con-

clusões que influenciam de forma significativa os elementos integrantes do modelo-solução teórico

final:

• Da análise exposta em 3.2 ao tipo de aplicações e dados existentes no software IPBrick da

IPBrick cloud, conclui-se que os dados classificados como dados em uso devem permanecer

disponíveis em texto claro, de forma permanente caso contrário, as aplicações em tempo real

deixariam de estar funcionais. Esta ilação é relevante no que toca à escolha da estratégia de

encriptação a seguir.

• A "Estratégia 1", correspondente à encriptação do lado do cliente, é uma solução viável

para encriptação de dados em repouso, no entanto, esta vai contra os princípios de negócio

na cloud postos em prática pela IPBrick SA em que o software IPBrick da IPBrick cloud

deve integrar o modelo SaaS e como a solução de encriptação do lado do cliente exigiria

a dado ponto, a instalação de aplicações na sua máquina que permitissem a encriptação e

desencriptação dos dados fora da IPBrick cloud, o modelo de negócio deixaria de consistir

num full SaaS.


• Apenas a "Estratégia 2" que consiste no algoritmo FHE poderia ser adotada para encriptação

dos dados em uso sem que existisse perda de disponibilidade nas aplicações uma vez que

o algoritmo permite com que os dados, mesmo que encriptados, consigam ser processados

sem que se executem operações de encriptação ou desencriptação. O número de operações

de encriptação e desencriptação a ser efetuado caso fosse adotada uma das duas outras es-

tratégias de encriptação seria suficiente para provocar atrasos no processamento de dados

em uso que poriam em causa a disponibilidade de aplicações em tempo real. Tendo como

exemplo as configurações do serviço VoIP, uma pesquisa na lista de contactos exigiria uma

operação de desencriptação sobre o ficheiro ou base de dados correspondente imediatamente

antes de ser realizada a pesquisa sendo que depois de realizada a pesquisa, o ficheiro ou base

de dados sofreria uma nova encriptação, cenário que introduziria atrasos significativos nas

funcionalidades da aplicação existindo também possibilidade de atrasos e interrupções du-

rante uma chamada de voz pelo tempo necessário à desencriptação de ficheiros relacionados

com parâmetros de ajustes da chamada. O grande problema da "Estratégia 2" reside no facto

de esta ser apenas uma abordagem teórica tendo em conta o poder de processamento atual

dos computadores. Na atualidade existem apenas protótipos académicos de sistemas que

seguem de forma parcial o algoritmo FHE. Segundo o perito em segurança e criptógrafo

Bruce Schneier, seguindo a Lei de Moore, serão precisos 40 anos para que esta estratégia

seja realmente viável [39]. Num contacto por e-mail estabelecido com o autor da ferramenta

CryFS, Sebastien Messmer, abordando-se o tema sobre o futuro da encriptação da cloud em

que foi pedida a sua opinião acerca do algoritmo FHE, obteve-se uma resposta, passando-se

a citar o seguinte excerto: "(...) There is much more happening in the cloud where CryFS

can’t help. It can’t help protect your non-file user data, and it can’t help if your cloud pro-

vider needs to run computations on your data. There, you would need fully homomorphic

encryption. As far as I know, there aren’t any fully homomorphic systems that are secure

and have a good performance yet. Homomorphic encryption is a very interesting research

topic and probably will come up with some solutions here given some time.". Um registo do

e-mail resposta enviado pelo criptógrafo Sebastien Messmer, pode ser visto no anexo D.2.

• A "Estratégia 3" é uma solução viável para encriptação de dados em repouso e enquadra-se

no modelo de negócio da IPBrick SA em que a adição de funcionalidades de encriptação ao

pacote de aplicações oferecido pela IPBrick cloud não requer nenhuma interação ao nível da

instalação de ferramentas de encriptação ou gestão de chaves criptográficas no dispositivo

de acesso do cliente. É uma estratégia independente de terceiros (ex. CSP), podendo ser

implementada partindo da integração de ferramentas de encriptação de livre uso comercial,

como as estudadas em 3.5.

• Em relação à estratégia de backups dos dados da IPBrick cloud, ficou claro a integração no

modelo-solução da ferramenta Bacula como agente de backups ficando por definir o destino

dos dados dos backups. Numa perspetiva de poupança de recursos físicos e admitindo que


será feito o uso do módulo de encriptação da ferramenta Bacula, opta-se por definir uma

VM dedicada, funcionando como servidor de backups, na IPBrick cloud.

• Do estudo efetuado sobre as ferramentas de encriptação em 3.5 resultam várias conclusões:

– Da análise qualitativa, a CryFS demonstrou ser a ferramenta que cumpre o maior nú-

mero de indicadores em estudo. É a única ferramenta que possui mecanismos de

verificação de integridade da meta-dados do sistema, podendo ser este o fator respon-

sável pelos resultados menos conseguidos nos testes de desempenho, em comparação

com as restantes ferramentas. O estudo feito sobre a CryFS prova que existem condi-

ções para que seja candidata a integrar o modelo-solução a propor, porém, o facto de

ser uma ferramenta desenvolvida recentemente e a sua versão atual não ser conside-

rada estável pelo próprio autor, são condicionantes que impedem a sua integração no

software IPBrick pelo menos, no período presente.

– Os resultados dos testes de desempenho comprovam que a EncFS foi a ferramenta

que apresentou melhor desempenho na globalidade, porém e da mesma forma que a

CryFS, a recomendação da equipa de desenvolvimento para que seja evitada a sua

utilização devido a falhas na imlementação das funcionalidades criptográficas (ex. uso

de cifras inseguras), faz com que esta ferramenta também não possa ser integrada no

software IPBrick.

– As ferramentas eCryptfs e dm-crypt são potenciais candidatas a integrarem o modelo-

solução, não apresetando as condicionantes das restantes ferramentas. Na avaliação

qualitativa a eCryptfs cumpre apenas mais um indicador em comparação com a dm-

crypt. Nos testes de desempenho a dm-crypt conseguiu bons resultados como de-

monstram os valores de velocidade obtidos nos diversos testes efetuados enquanto que

a eCryptfs apesar de apresentar percentagens do uso médio do CPU elevadas, obteve

bons resultados no que diz respeito aos valores de latência dos testes executados. As

diferenças ao nível da encriptação do disco entre as duas ferramentas foram analisa-

das no ponto 2.3.3.2 do capítulo de revisão bibliográfica. Pelo motivo de a eCryptfs

ser uma ferramenta de encriptação ao nível file system, tornando-se mais flexível nos

processos de mounting sobre os diretórios que se desejam seguros, é a ferramenta es-

colhida em detrimento da dm-crypt.

O modelo-solução final ficará assim composto:

• Tipo de Dados a Encriptar - Dados em repouso.

• Estratégia de Encriptação - "Estratégia 3 - Encriptação do Lado da IPBrick Cloud".

• Ferramenta de Encriptação - eCryptfs.

• Ferramenta para Backups - Bacula.

• Destino dos Backups - VM dedicada na IPBrick cloud.


3.6.2 Mecanismo de Segurança Adicional - Autenticação do Host

Do desenvolvimento do trabalho e da execução de testes de integração das várias ferramentas

de encriptação no software IPBrick da IPBrick cloud, surgiu a ideia de implementação de um pro-

cedimento de segurança extra em relação aos objetivos pré-definidos para a presente dissertação.

3.6.2.1 Análise do Problema

No software IPBrick da IPBrick cloud existem estratégias ou mecanismos para autenticação

de utilizadores na cloud que se encontram de acordo com a norma RFC 2828 mencionada no

ponto 2.3.3.4 do capítulo de revisão bibliográfica. Contudo e tendo em conta o contexto e a

arquitetura da IPBrick cloud abordada em 2.2.7, pode existir a necessidade de autenticação do

próprio ambiente do host (figura 2.4), do ambiente virtual onde se encontram os dados do cliente

na cloud. Esta ideia surgiu de uma reunião de trabalho em que se considerou a possibilidade de

ocorrência de ataques recorrendo à duplicação de VMs ou cópias de discos virtuais, através de

operações relacionadas com a virtualização descritas em 2.2.5.2, no ambiente remoto da cloud.

Um algoritmo de autenticação a este nível deve tomar em conta parâmetros únicos do host como

elementos autenticadores. Em caso de falha na autenticação, os dados da IPBrick cloud devem

manter-se inacessíveis, inclusive ao cliente.

3.6.2.2 Estratégia a Adotar

A estratégia deve seguir um modelo protocolar que engloba a concatenação de vários elemen-

tos na sua maioria relacionados com as características do host da VM. Da concatenação desses

elementos surge uma senha que deve ser utilizada em comparações recursivas aquando do arran-

que do software IPBrick da IPBrick cloud na VM. Um método semelhante que se designa por Fin-

gerprinting in Single Host VM Environments foi implementado por uma companhia de proteção

de dados chamada SafeNet [40]. No método referido foram utilizados dois elementos distintos:

endereço MAC da placa de rede e a informação do CPU. A utilização de apenas um elemento

relacionado com o ambiente do host não garantiria a fiabilidade da estratégia de autenticação visto

que esse mesmo elemento pode estar replicado noutros hosts, assim:

• Caso um ataque de duplicação da VM ou cópia do disco virtual aconteça dentro da mesma

rede, existe grande probabilidade de os endereços MAC das placas de rede virtuais serem

distintos, no entanto as informações sobre o CPU seriam provavelmente idênticas.

• Caso um ataque de duplicação da VM ou cópia do disco virtual seja desencadeado a partir

de uma rede distinta da VM atacada, existe grande probabilidade das informações do CPU

dos hosts serem distintas, no entanto é possível que os endereços MAC das placas de rede

sejam iguais.

Apesar do método implementado pela SafeNet não ser infalível, pode ser determinante na

prevenção, com grande probabilidade de sucesso, de ataques em ambientes virtuais como o caso

da IPBrick cloud.


3.6.3 Representação Gráfica do Modelo-Solução

No esquema da figura 3.4 é possível ver definidas duas VMs nas infraestruturas do PaaS pro-

vider da IPBrick SA. A VM1 deve albergar o protótipo do módulo de encriptação com princípios

criptográficos assentes nas funcionalidades da ferramenta de encriptação do disco eCryptfs, bem

como o mecanismo de segurança adicional de autenticação do host da VM.

VM1

SaaS

VM2

SaaS

PaaS

VM1 suporta a estratégia

de encriptação dos dados

de$nida (Encriptação do lado da

IPBrick Cloud), através da

integração da ferramenta

eCryptfs com o software

IPBrick .

1

Backup

Restore

VM2 suporta a estratégia

de backup dos dados

a implementar através

da ferramenta Bacula. Deve

ser possível encriptar e os dados

aquando do backup e

desencriptar aquando do

Restore.

2

INTERNET

Cliente

4 Módulos de encriptação

e de backups dos dados

na interface web de

administração da

IPBrick cloud da VM1.

VM1 incorpora mecanismo

de autenticação do

host da VM.

3

Figura 3.4: Modelo-Solução final. Legendas elucidativas dos elementos essenciais do modelo-solução numeradas de 1 a 4.


A VM2 deve alojar um servidor central de gestão de backups implementado a partir da ferra-

menta Bacula. Deve existir a funcionalidade de encriptação dos dados dos backups. O utilizador

terá acesso na interface web de administração da IPBrick cloud, neste caso na interface correspon-

dente à VM1, a dois módulos: módulo de encriptação e módulo de backups dos dados. Através

da interface de administração deverá ser possível controlar as funcionalidades das ferramentas a

integrar no software IPBrick da IPBrick cloud. Apesar de no esquema estarem representadas ape-

nas duas VMs, os módulos de encriptação e de backups podem ser aplicados a qualquer VM na

IPBrick cloud. Para efeitos de implementação dos protótipos e testes futuros serão igualmente

apenas tidas em conta as duas máquinas do esquema.

3.7 Conclusão

Após os vários passos descritos ao longo do presente capítulo com vista a encontrar a solução

que melhor cumpre os objetivos do trabalho e os requisitos de integração do software IPBrick da

IPBrick cloud, estão reunidas as condições para o desenvolvimento dos protótipos de demonstra-

ção.

Do estudo e análises efetuadas no presente capítulo é possível concluir que o modelo-solução

final apresentado não é perfeito ao nível criptográfico. À falta de tecnologia atual que permita

manter os dados encriptados em todas as fases do seu ciclo de vida, opta-se por encriptar certos

tipos de dados através do uso de ferramentas adequadas, de forma a que não seja posto em causa a

disponibilidade dos vários serviços e aplicações da IPBrick cloud. De referir o elemento inovador

aliado à ferramenta de encriptação sendo que a mesma irá atuar ao nível das partições de discos

num contexto de virtualização.

A importância deste capítulo é evidenciada com a descrição do modelo-solução final, mo-

delo esse que serve de justificação a todo o trabalho desenvolvido a partir do presente ponto da

dissertação.

Capítulo 4

Implementação do Modelo-Solução naIPBrick Cloud

O capítulo 4 distingue-se dos anteriores pelo facto do conteúdo que apresenta, assentar maiori-

tariamente na componente prática do trabalho. Neste capítulo são descritas todas as etapas levadas

a cabo para construção e posterior verificação da eficácia, de protótipos para prova conceptual da

solução apresentada no capítulo anterior.

4.1 Introdução

Após todo o projeto envolvido na definição de um modelo-solução capaz de fornecer garan-

tias no cumprimento dos objetivos propostos para a presente dissertação, procura-se comprovar ao

longo deste capítulo a eficácia do funcionamento do mesmo na IPBrick cloud. Para isso é neces-

sário a integração das ferramentas criteriosamente escolhidas no capítulo anterior com o software

IPBrick e o desenvolvimento das páginas correspondentes, na interface web de administração da

IPBrick cloud, para que o cliente possa interagir com as diversas funcionalidades a disponibilizar.

Em concordância com o modelo-solução e com os objetivos propostos, o conteúdo do presente

capítulo está organizado em duas partes principais, correspondentes à descrição das várias etapas

envolvidas no desenvolvimento dos dois módulos seguintes:

• Módulo de Encriptação dos Dados - Módulo que engloba todos os elementos do modelo-

solução com vista à encriptação dos dados da IPBrick cloud. Na primeira parte deste capí-

tulo serão descritos os passos necessários para a implementação deste módulo, mais especi-

ficamente: funcionalidades relevantes da ferramenta de encriptação selecionada, protocolos

de gestão de chaves criptográficas, pormenores cruciais no desenvolvimento do protótipo

do módulo de encriptação na IPBrick cloud e testes funcionais para verificação do correto

funcionamento da implementação.

• Módulo de Backups dos Dados - Engloba os elementos essenciais para a implementa-

ção da estratégia de backup dos dados da IPBrick cloud. De forma idêntica ao módulo de

49

50 Implementação do Modelo-Solução na IPBrick Cloud

encriptação, serão descritos na segunda parte deste capítulo, todos os passos para implemen-

tação deste módulo, nomeadamente os seguintes: funcionalidades relevantes da ferramenta

Bacula, protocolos de gestão de chaves para a funcionalidade de encriptação da ferramenta,

descrição de configurações essenciais para execução de backups e restores, pormenores cru-

ciais do desenvolvimento do protótipo do módulo de backups de dados da IPBrick cloud e

testes funcionais para verificação do correto funcionamento da implementação.

A descrição da pilha de software desenvolvido para construção do protótipo, encontra-se em

cada uma das partes principais do presente capítulo, organizada através de um modelo multi-

camadas, considerando-se as três camadas seguintes:

• Front-End - Corresponde ao software desenvolvido para estabelecimento de uma interface

com o utilizador.

• Middle-End - Camada que aqui se define para expor o desenvolvimento do canal de comu-

nicação implementado entre o front-end e o back-end, fazendo uso de sistemas de base de

dados através do gestor PostgreSQL. .

• Back-End - Camada que diz respeito ao software desenvolvido com o intuito de integrar

corretamente as funcionalidades das ferramentas na IPBrick cloud.

Na descrição ao nível do front-end, serão expostos screen-shots das páginas desenvolvidas

na interface web de administração para que exista elucidação do leitor relativamente à user-

experience do cliente. Na camada middle-end demonstram-se os processos levados a cabo para

a geração de tabelas nas base de dados com vista ao auxílio na comunicação entre o front-end

e o back-end. Por último, na camada back-end, são explicados os pormenores essenciais para

integração das ferramentas do modelo-solução, recorrendo à exposição de excertos de código.

O mecanismo de segurança adicional descrito no ponto 3.6.2 do capítulo anterior, foi im-

plementado na camada back-end do módulo de encriptação de dados, pelo que a referência ao

desenvolvimento do mecanismo é feita nessa ponto do capítulo.

4.2 Módulo de Encriptação de Dados

4.2.1 Detalhes sobre o Funcionamento da Ferramenta de Encriptação Adotada

No capítulo anterior definiu-se, através de estudos e testes de desempenho, que a ferra-

menta de encriptação a integrar o modelo-solução e que melhor se adequa à estratégia de encripta-

ção escolhida e aos tipos de dados da IPBrick cloud que devem ser encriptados, seria a ferramenta

de encriptação do disco eCryptfs.

4.2 Módulo de Encriptação de Dados 51

Gestor de Chaves

UtilizadorKernel

Gestor de ChaveseCryptfs

Daemon

TPM

OpenSSL

PAMGnuPG

Camada eCryptfs

Kernel

Crypto

API

File System ext4

Estrutura do Ficheiro

Meta-Dados Criptográ"cos

Frameworks

Figura 4.1: Arquitetura da eCryptfs no sistema operativo Linux. A representação foi inspirada nafigura 1 do relatório da IBM: "eCryptfs: An Enterprise-class Cryptographic Filesystem for Linux".

Apesar de ser classificada como ferramenta de encriptação do disco, a designação mais cor-

reta é a de file system criptográfica ou de encriptação, atuando no topo da pilha sobre a qual está

definida a organização dos ficheiros no sistema (Figura 4.1), por outras palavras, sobre uma file

system existente, dando-se o exemplo da file system ext4 no caso do software IPBrick. A arqui-

tetura da eCryptfs é composta por diversas frameworks do sistema operativo Linux das quais se

destacam as seguintes: Linux kernel keyring service, kernel cryptographic API, Linux Pluggable

Authentication Modules, OpenSSL, Trusted Platform Module, GnuPG keyring; pertencentes quer

ao espaço dedicado ao utilizador, quer ao Linux kernel, com o objetivo de tornar a importante

tarefa de gestão de chaves criptográficas simples e transparente. As operações de encriptação e

desencriptação dos dados são executadas ao nível do kernel do sistema operativo tirando proveito

da kernel cryptographic API, evitando-se, segundo os autores da ferramenta, overheads associa-

dos às operações no contexto de trocas de elementos criptográficos entre o espaço do utilizador e

o espaço do kernel [41].


Passphrase || Salt da eCryptfs

i < 65536

SHA-512

SHA-512

Chave Secreta Simétrica

Assinatura

Chaveiro do Kernel

Figura 4.2: Protocolo para geração da chave secreta simétrica usada pela cifra AES incorporadana eCryptfs. Juntamente com a chave é gerada uma assinatura respetiva.

A eCryptfs suporta os algoritmos baseados , quer em chave simétrica, quer em chave pública,

referenciados em 2.3.3.1. Devido ao elevado número de operações associado ao algoritmo de en-

criptação recorrendo a chave pública, este último não é tão comummente usado para encriptação

dos dados com a ferramenta eCryptfs. Todas as cifras simétricas suportadas pelo Linux kernel são

candidatas a incorporar os mecanismos de encriptação de dados da eCryptfs. Das cifras supor-

tadas destaca-se a AES no modo de atuação por blocos, CBC. A eCryptfs possui um protocolo

próprio para geração e gestão da chave secreta simétrica a utilizar para encriptação dos dados de

cada ficheiro. Esse protocolo tem como elementos fundamentais, a passphrase definida como pa-

râmetro de entrada pelo utilizador do sistema, um salt pré-definido, e um conjunto de operações

de hash recursivas recorrendo à função de hash SHA-512. A figura 4.2 ilustra o protocolo interno

da eCryptfs para geração da chave secreta simétrica em que a passphrase do utilizador é conca-

tenada com o salt específico da ferramenta, o resultado da concatenação serve como input inicial

a um conjunto de 65536 iterações da função de hash SHA-512. Os 32 primeiros bytes ou 256

bits, resultantes das sucessivas iterações, formam a chave secreta simétrica. A assinatura da chave

secreta simétrica deriva da execução de mais uma iteração em que são selecionados os 8 primeiros

bytes do resultado obtido [41].

Aquando do mounting da eCryptfs num diretório que se pretende protegido (ex. "/home1" na


Figura 4.3: Partição do disco virtual "/dev/sda7" montada no diretório "/home1".

Figura 4.4), todos os ficheiros nele gerados a partir de então, são escritos na partição do disco pre-

viamente montada nesse mesmo diretório (Figura 4.3), num formato encriptado após intervenção

da cifra AES no modo CBC utilizando como chave de encriptação a gerada a partir do protocolo

da Figura 4.2 que manter-se-á juntamente com a sua assinatura, em cache no chaveiro do kernel

até que a eCryptfs seja desativada. Recorrendo ao uso de uma gíria descontextualizada, a eCryptfs

define um caixote em que todos os dados nele depositados sofrem um processo de encriptação

imediatamente antes de serem armazenados no disco. Contudo, o caixote permanece aberto, e

os dados disponíveis (após sofrerem uma operação de desencriptação), enquanto que a eCryptfs

estiver montada, isto depois da realização de um processo de autenticação bem sucedido utili-

zando, por exemplo, a passphrase do cliente. Juntamente com o conteúdo encriptado de um dado

ficheiro são também guardados meta-dados que incluem, entre vários parâmetros criptográficos, a

assinatura da chave correspondente à usada para encriptar o referido ficheiro. Como foi visto no

ponto correspondente ao estudo das ferramentas criptográficas em 3.5, a eCryptfs não possui, na

atualidade, mecanismos de verificação da integridade dos dados embora exista a previsão para a in-

tegração dessa funcionalidade através do uso do procedimento MAC, já abordado no ponto 2.3.3.3

do capítulo da revisão bibliográfica [41].

4.2.2 Protocolo de Gestão de Chaves Criptográficas

O fator sensível e determinante tendo em conta a tríade confidencialidade, integridade e dis-

ponibilidade dos dados (Figura 2.6), na IPBrick cloud, é a gestão dos diferentes tipos de chaves

necessárias para a implementação de um sistema criptográfico seguro. Na Figura 4.2 do ponto

anterior observa-se o protocolo interno para gestão de chaves criptográficas da eCryptfs partindo

do fornecimento de uma passphrase por parte do utilizador. O criptógrafo Sylvain Pelissier no

artigo "How to crack Ubuntu encryption and passwords", sobre a eCryptfs, descreve um bug no

protocolo interno de gestão de chaves criptográficas da ferramenta, que consiste no uso de um salt

estático e conhecido, aquando da concatenação inicial com a passphrase introduzida pelo utiliza-

dor, o que torna possível os ataques criptográficos conhecidos por: ataque do dicionário e ataque

do arco-íris [42]. O mesmo criptógrafo conseguiu decifrar a sua passphrase através da ferramenta

john the ripper, perpetrando os ataques referidos anteriormente, no período de tempo equivalente

a um mês. Para serem evitados possíveis ataques como os referidos, para que exista independência

em relação aos protocolos internos da eCryptfs e também para que o próprio cliente da IPBrick SA

possua as suas próprias chaves únicas e distintas de todos os outros clientes, decidiu-se construir

um protocolo de gestão de chaves totalmente independente da ferramenta de encriptação e cujo

o objetivo é gerar uma passphrase de entrada na eCryptfs suficientemente robusta para prevenir

ataques de força bruta, ataques do dicionário e ataques do arco-íris.


Figura 4.4: Diretório "/home1" montado nele próprio pela eCryptfs, encontrado-se assim prote-gido.

IPBrick SaltPassword do Cliente

| |

SHA-256

Passphrase a introduzir na eCryptfs

1

2

3

Figura 4.5: Protocolo para gestão de chaves do cliente utilizado na implementação do módulo deencriptação de dados da IPBrick cloud.

A Figura 4.5 ilustra o protocolo a implementar para a geração da passphrase que serve como

parâmetro de entrada ao protocolo interno da eCryptfs que por sua vez, gera a chave secreta si-

métrica. Na interface de administração da IPBrick cloud o cliente deverá introduzir a password

que pretende para ativação do módulo de encriptação. Essa password é concatenada com um salt

que só a IPBrick SA tem conhecimento. O resultado da concatenação serve ainda como parâ-

metro de entrada à função de hash SHA-256. Do output da função de hash resulta a passphrase

robusta e única a introduzir na eCryptfs. Caso o cliente selecione o caminho 1, a sua password

é imediatamente eliminada do sistema após geração da passphrase a introduzir na eCryptfs, esta

última é igualmente eliminada do sistema após o mounting dos diretórios que se querem seguros,

tal como indica o caminho 3, garantindo-se assim a eficácia do sistema criptográfico, salvaguar-

dando o direito de acesso aos dados apenas ao cliente da IPBrick SA, extinguindo-se qualquer tipo

de backdoors que pudessem vir a existir. Apenas a chave simétrica criptográfica permanece em

cache no espaço do kernel durante o período de atividade do módulo de encriptação mas possí-


veis ataques a essa chave exigiriam privilégios de root no sistema ou um ataque por força bruta

a uma chave de 256 bits que designa o tamanho da chave secreta simétrica, tendo ainda que ser

encontrado o vetor de inicialização da cifra AES em modo CBC, o que na prática, devido à ine-

xistência de poder de processamento suficiente na atualidade, é considerado extremamente difícil.

O caminho 2 representado na Figura 4.5, foi criado para disponibilizar uma opção ao cliente que

permita efetuar um backup da sua password que seria útil, por exemplo, no caso de esquecimento.

Seria também útil para salvaguardar a autonomia da IPBrick cloud aquando de um reboot ines-

perado (ex. falha nos servidores do CSP). Sempre que existe um reboot do sistema, a eCryptfs é

desmontada e todos os dados do diretório protegido ficam disponibilizados ao cliente no formato

encriptado. Para que o cliente consiga visualizar os dados em claro quando o sistema se encontra

novamente ativo, é necessário que insira novamente a sua password para que a eCryptfs possa ser

montada uma vez mais. O caminho 2 preveniria esta situação tornando a IPBrick cloud totalmente

automática a este nível. No entanto, seguindo este caminho, existe uma redução considerável

da segurança imposta uma vez que a password do cliente fica armazenada no espaço remoto da

IPBrick cloud, podendo permanecer num formato ofuscado, mas ainda assim representa um me-

canismo que vai contra princípios criptográficos definidos pela CSA, criando possivelmente uma

backdoor indesejável. Ainda assim, essa funcionalidade está prevista no protocolo para deixar ao

critério do cliente a escolha da opção que lhe seja mais conveniente.

4.2.3 Desenvolvimento do Protótipo

4.2.3.1 Tecnologias Utilizadas

Para implementação de um protótipo do módulo de encriptação da IPBrick cloud foram utili-

zadas as seguintes tecnologias:

• Ambiente de Desenvolvimento - VM com guest OS IPBrick v6.1 (Debian GNU/Linux 7.5

wheezy).

• Pacote de Instalação - ecryptfs-utils (99-1+deb7u1).

• Linguagens Front-End - JavaScript, HTML, CSS.

• Gerenciador de Base de Dados - PostgreSQL.

• Linguagens Back-End - PHP, Linux Shell Scripting.

4.2.3.2 Desenvolvimento do Front-End

Considera-se como fazendo parte deste nível de desenvolvimento, todos os procedimentos

necessários à implementação das interfaces gráficas, sendo estas o meio de interação único entre o

cliente e o módulo de encriptação da IPBrick cloud. No estudo do design das páginas, teve-se em

conta a integração do front-end a desenvolver com a interface web de administração da IPBrick


cloud já existente, e que engloba um vasto número de módulos relacionados com configurações

necessárias aos vários tipos de aplicações existentes na IPBrick cloud. Por esse motivo, o design

de todas as páginas correspondentes ao módulo de encriptação dos dados deve ser idêntico ao da

Figura 4.6 que representa a página principal da interface web de administração da IPBrick cloud.

Figura 4.6: Página principal da interface web de administração da IPBrick cloud.

O módulo de encriptação deve estar acessível num dos menus disponíveis do lado esquerdo

da interface de administração da IPBrick cloud (Figura 4.7). A página inicial indica o estado em

que se encontra a encriptação dos dados (Figura 4.8). A partir da página inicial do módulo de

encriptação é possível modificar o estado atual, ativando ou desativando a encriptação dos dados.


Figura 4.7: Acesso ao módulo de encriptação do menu da interface de administração.

Figura 4.8: Resultado da implementação da página principal do módulo de encriptação de dados.É possível visualizar o estado "Off" correspondendo ao estado inativo.

Na página de alteração do estado atual do módulo de encriptação da IPBrick cloud para o

modo ativo (Figura 4.10), é estabelecida a interação necessária com utilizador para execução do

protocolo de gestão de chaves do cliente, através de um formulário em que é pedido a inserção de

uma password segura e a seleção do modo de encriptação. Existem dois modos de encriptação que

diferem no destino da password do cliente após ativação da encriptação como foi possível observar

no protocolo de gestão de chaves criptográficas (Figura 4.5). Selecionando o modo "Safe", será

feito um backup da password do cliente e o sistema permanecerá completamente automático. O

modo "Extremely Safe" garante ao utilizador que a sua password não é guardada no sistema (me-

canismo recomendado pela CSA), pelo que o mesmo terá que a inserir sempre que ocorra algum

reboot inesperado da VM na cloud. Na Figura 4.9 é possível observar um texto informativo que

surge imediatamente antes do formulário de alteração do estado inativo do módulo de encriptação,

com o intuito de dar conhecimento ao cliente dos diferentes modos de encriptação disponíveis.

Para incremento da segurança, não existem estratégias de recuperação da password. O protótipo

também não suporta a funcionalidade de alteração da password do cliente, assunto que é abordado

no capítulo 6 como trabalho futuro.


Figura 4.9: Implementação da página informativa que faz a distinção entre os modos "Safe" e"Extremely Safe".

Figura 4.10: Resultado da implementação da página de alteração do estado do módulo de encrip-tação da IPBrick cloud para o modo ativo.

Após alteração do estado inativo, a página principal apresentará o estado "On" (Figura 4.11),

indicando que o módulo de encriptação da IPBrick cloud se encontra ativo. Durante esse estado,

todo os dados do cliente gerados são armazenados no disco virtual no formato encriptando sendo

que o cliente tem acesso permanente aos dados em texto claro até que exista alteração do estado

ativo do módulo de encriptação.

Figura 4.11: Resultado da implementação da página principal do módulo de encriptação agoracom o estado do módulo ativo, "On".


A partir do estado ativo é possível desativar manualmente o módulo de encriptação ou o pró-

prio pode ser desativado caso o modo escolhido tenha sido o "Extremely Safe" e o sistema sofra

um reboot inesperado. A desativação manual (Figura 4.12), é desaconselhada ao utilizador, uma

vez que o mesmo deixa de conseguir aceder em texto claro, aos dados encriptados no disco virtual

armazenados até então, podendo colocar em causa a disponibilidade das aplicações da IPBrick

cloud, e os novos dados produzidos não ficarão armazenados na partição do disco virtual, no for-

mato encriptado. Em caso de reboot, o sistema reconhece o acontecimento e avisa o cliente da

necessidade de introduzir novamente a sua password (Figura 4.13), através do envio de um e-mail

executando um comando Linux próprio na CLI, e de um aviso exposto na página de alteração do

estado atual do módulo de encriptação.

Figura 4.12: Resultado da implementação da página de alteração do estado ativo. É transmitidoum aviso ao cliente sobre as consequências que podem causar uma possível desativação.

Figura 4.13: Ilustração de um aviso que é lançado sempre que o módulo de encriptação se encontreem "Extremely Safe Mode" e o sistema tenha sido alvo de um reboot.


As ativações e desativações do módulo de encriptação bem como as configurações adjacentes,

não são procedimentos realizados em run-time. De facto, só existem alterações no funcionamento

das aplicações da IPBrick cloud quando se executa uma funcionalidade presente numa das páginas

da interface de administração cujo nome é Apply Configurations e que permite aplicar todas as

configurações feitas até então.

4.2.3.3 Desenvolvimento do Middle-End

No âmbito da clarificação do sistema de comunicação da implementação do módulo de en-

criptação, é importante fazer uma referência às base de dados. Para auxílio na aplicação das

configurações no back-end do módulo de encriptação, é utilizada uma base de dados, por outras

palavras, a ligação entre o front-end e o back-end é feita a partir de uma tabela própria para o

módulo de encriptação, criada na base de dados local da VM.

AdministradorAltera_

estado

Módulo

Encriptação

Ativo

Modo

Force_Disable

Nome

ID Morada

1 1 Password

Figura 4.14: Modelo entidade-associação na origem da criação da tabela de auxílio ao módulo deencriptação na base de dados local da VM.


A entidade "Administrador" corresponde ao cliente da IPBrick SA. Essa entidade já foi pre-

viamente definida nas base de dados locais da IPBrick cloud, pelo que as atenções recaem apenas

na entidade "Módulo de Encriptação". Esta última possui um tuplo "Ativo" que deverá consistir

numa variável booleana na tabela criada para o propósito. O "Modo" é o tuplo que designa o modo

de encriptação escolhido pelo cliente e deverá consistir numa variável binária em que "0" define

o modo de encriptação "Safe" e "1" define o modo de encriptação "Extremely Safe". O tuplo

"Force_Disable" indica se o módulo de encriptação foi ou não manualmente desativado pelo que

deverá também ele consistir numa variável booleana na tabela da base de dados. O tuplo "Pas-

sword" guarda temporariamente a password do cliente se o mesmo escolher o modo "Extremely

Safe" e guarda permanentemente a password do cliente de forma ofuscada se o mesmo escolher o

modo "Safe".

Refira-se que as variáveis relativas aos tuplos descritos anteriormente são consideradas como

sendo variáveis de estado ou flags e por isso, a tabela criada requer só uma entrada para leitura e

atualização dos valores.

4.2.3.4 Desenvolvimento do Back-End

A partir da parametrização feita pelo cliente nas páginas do módulo de encriptação dos dados

da IPBrick cloud implementada na interface web de administração, e da incorporação dos valores

dos parâmetros na tabela da base de dados criada para esse efeito, torna-se possível executar

todos os procedimentos ao nível do back-end para ativação propriamente dita da encriptação.

Considera-se como fazendo parte deste nível de desenvolvimento, todos os procedimentos que

levam à implementação dos dois mecanismos seguintes:

• Automatização do protocolo de gestão de chaves do cliente.

• Automatização do mounting da eCryptfs no sistema.

Os mecanismos foram implementados recorrendo a scripts System V para início, interrupção

e reinício de aplicações nos sistemas operativos Linux. Apresenta-se um exemplo da estrutura de

um script System V usado nos ficheiros desenvolvidos para o desenvolvimento efetuado no back-

end:

1 ### BEGIN INIT INFO2 # P r o v i d e s : e C r y p t f s3 # Requi red−S t a r t : $ne twork $ r e m o t e _ f s $ s y s l o g4 # Requi red−Stop : $ne twork $ r e m o t e _ f s $ s y s l o g5 # Should−S t a r t : f i r s t b o o t6 # Should−Stop : f i r s t b o o t7 # D e f a u l t−S t a r t : 2 3 4 58 # D e f a u l t−Stop : 0 1 69 # Shor t−D e s c r i p t i o n : f i l e f o r e C r y p t f s mount

10 ### END INIT INFO


11 # ! / u s r / l o c a l / b i n / sh12

13 s t a r t ( ) {14

15 # Mecanismos a u t o m a t i z a d o s16

17 }18

19 s t o p ( ) {20

21 # D e s a t i v a c a o do modulo de e n c r i p t a c a o22

23 }24

25 ### main l o g i c ###26 c a s e " $1 " i n27 s t a r t )28 s t a r t29 ; ;30 s t o p )31 s t o p32 ; ;33 r e s t a r t | r e l o a d | c o n d r e s t a r t )34 s t o p35 s t a r t36 ; ;37 ∗ )38

39

40 echo " Usage : / e t c / i n i t . d / ${NAME} { s t a r t | s t o p | r e s t a r t | f o r c e−r e l o a d } " >&241 e x i t 142 ; ;43 e s a c44 e x i t 0

Lista de Código 4.1: Esqueleto do script System V usado para a implementação do back-end.

O código apresentado em 4.1 começa com um cabeçalho (linhas 1-10). Esse cabeçalho per-

mite definir qual a ordem de início e de paragem de cada serviço instalado no sistema operativo

IPBrick aquando de um arranque e de um cessar da VM, respetivamente. Esta funcionalidade é

relevante caso o cliente faça a seleção do modo de encriptação "Safe" no módulo de encriptação

da interface web de administração da IPBrick cloud, em que o sistema deve permanecer comple-

tamente automático e sendo assim, os dados do cliente devem ficar imediatamente disponíveis

aquando de um arranque e indisponíveis apenas quando todos os serviços estiverem encerrados,

aquando de um cessamento da atividade da VM.

Em "start()" é implementado o protocolo de gestão de chaves do cliente partindo como pa-

râmetro de entrada, o valor correspondente à password do cliente guardado na tabela da base de

dados associada ao módulo de encriptação. Após ser gerado o output que define a passphrase da


eCryptfs, a password do cliente é eliminada da base de dados caso o mesmo tenha selecionado

o modo "Extremely Safe". Com a passphrase gerada, é possível montar a eCryptfs nos diretó-

rios que se pretendem seguros. Esses diretórios correspondem aos repositórios típicos dos dados

produzidos pelo cliente do uso das várias aplicações da IPBrick cloud, sendo eles: os diretórios

"/home" e o diretório "/var/lib/postgres" correspondente à base de dados local. A cifra de encrip-

tação a selecionar é a AES no modo CBC e o tamanho da chave secreta simétrica é de 256 bits. O

seguinte comando traduz um exemplo de como foi implementado o código para o acionamento da

proteção num dos diretórios através da eCryptfs, na função "start()":

1 $ mount − t e c r y p t f s / home / / home / −o key= p a s s p h r a s e : $ p a s s p h r a s e ,e c r y p t f s _ c i p h e r =aes , e c r y p t f s _ k e y _ b y t e s =32 , e c r y p t f s _ p a s s t h r o u g h =y ,e c r y p t f s _ e n a b l e _ f i l e n a m e _ c r y p t o =y

Lista de Código 4.2: Excerto do código utilizado na função "start()".

Na lista de código 4.2, a variável bash "$passphrase" contém o valor que provém do resultado

da execução do protocolo de gestão de chaves do cliente. Nos restantes parâmetros indica-se a

cifra e o tamanho da chave secreta simétrica. Indica-se também em "ecryptfs_passtrough" que os

ficheiros que já se encontrarem no diretório, não devem ser encriptados. A definição do último

parâmetro de entrada do comando, faz com que exista encriptação dos nomes dos ficheiros. Como

foi dito anteriormente, a passphrase da eCryptfs não fica armazenada no sistema. No sistema per-

manece apenas a chave secreta simétrica gerada pelo protocolo interno da eCryptfs, isto, enquanto

o módulo de encriptação se mantiver ativo. Em "stop()" (lista de código 4.1), procede-se à de-

sativação da encriptação que por outras palavras consiste em desmontar a eCryptfs dos diretórios

protegidos. Um excerto de código para desmontar a eCryptfs de um dado diretório pode ser ob-

servado na lista de código 4.3.

1 $ umount − t / home

Lista de Código 4.3: Excerto do código utilizado na função "stop()".

4.2.4 Implementação do Mecanismo de Autenticação do Host

A implementação do mecanismo de autenticação do host teve em conta, de forma idêntica ao

protocolo da SafeNet, dois parâmetros característicos do ambiente de host da VM: endereço MAC

da placa de rede, e informação relativa ao CPU. A esses parâmetros foram ainda adicionados

os UUIDs das partições do disco virtual e um salt específico da IPBrick SA. A implementação

baseou-se no protocolo representado pela Figura 4.15:


Endereço MAC UUID’s do Disco Virtual

Informação do CPU

IPBrick Salt

| |

SHA-256

Código para Autenticação do Host

Figura 4.15: Protocolo de autenticação do host implementado. O círculo a tracejado representauma operação de concatenação.

Aquando da ativação do módulo de encriptação, é gerado o código de autenticação e guardado

num ficheiro que ficará permanentemente armazenado em texto claro num diretório secreto do

sistema. A partir desse momento, por cada boot da VM, existe uma processo autenticação execu-

tado na função "start()" (lista de código 4.1), que consiste novamente na execução do protocolo da

Figura 4.15 e na comparação do resultado obtido com o código previamente armazenado. Caso a

autenticação seja bem sucedida, a VM arranca normalmente. Caso contrário, é enviado um alerta

via e-mail, através de um comando Linux executado na CLI, ao departamento de R&D da IPBrick

SA, informando sobre um possível contexto de ataque sobre os dados de um dado cliente. Se

o modo de encriptação selecionado consistir no modo "Safe", os dados do cliente permanecerão

encriptados ou seja, não existe mount automático da eCryptfs recorrendo à password do cliente

guardada na tabela da base de dados associada ao módulo de encriptação.

4.2.5 Testes Funcionais

Para comprovar a eficácia de toda a implementação feita na IPBrick cloud relativa ao módulo

de encriptação de dados, foi realizada uma bateria de testes. Na tabela a baixo é possível observar

o processo de validação levado a cabo por cada teste realizado.


ID Descrição por Passos Progonóstico Resultado

1 Teste de verificação da confidencialidade:

1. Ativação do módulo de encriptação.

2. Criação de um ficheiro num dos diretó-rios de dados do cliente, protegido pelaeCryptfs.

3. Desativação do módulo de encriptação.

Prevê-se a visualização do con-teúdo do ficheiro no formato en-criptado.

Bem Sucedido

2 Teste de verificação da confidencialidade numdiretório distinto do protegido:


2. Criação de um ficheiro num dos diretó-rios de dados do cliente protegido pelaeCryptfs.

3. Mounting do diretório protegido noutrodiretório sem utilizar a eCryptfs.

No diretório montado pelo dire-tório protegido deve visualizar-se o conteúdo do ficheiro no for-mato encriptado.

Bem Sucedido

3 Teste de verificação da integridade:


2. Criação de um ficheiro num dos dire-tórios dos dados do cliente protegidospela eCryptfs.

3. Desativação do módulo de encriptação.

4. Violação da integridade do ficheiro en-criptado através da escrita de caracte-res aleatórios no ficheiro e nova ativa-ção do módulo de encriptação.

Espera-se que o conteúdo do fi-cheiro seja de alguma forma afe-tado, isto porque como já foivisto, a eCryptfs não possui me-canismos de verificação da inte-gridade dos dados.

Bem Sucedido

4 Simulação de um ataque de cópia do discovirtual na cloud:


2. Criação de um ficheiro num dos diretó-rios dos dados do cliente protegido pelaeCryptfs.

3. Cópia do disco virtual a partir de umaVM distinta.

Após a montagem da partição dodisco virtual copiado onde estãolocalizados os dados do ficheiroreferido, na nova VM, deve-seobservar o conteúdo do ficheirono formato encriptado.

Bem Sucedido


5 Verificação do funcionamento automático domodo de encriptação "Safe Mode":


2. Criação de um ficheiro num dos diretó-rios dos dados do cliente protegido pelaeCryptfs.

3. Execução de um reboot do sistema.

Após o reboot, a eCryptfs deveestar montada nos diretórios pré-definidos sendo possível obser-var o conteúdo do ficheiro criadoem texto claro.

Bem Sucedido

6 Verificação do funcionamento correto do pro-cedimento adicional de autenticação do host:

1. Ativação do módulo de encriptação nomodo "Safe".

2. Cessação do estado ativo da VM.

3. Remoção da placa de rede virtual esubstituição por uma nova no gestor deVMs.

4. Ativação da VM.

O endereço MAC da nova placade rede é diferente e por isso aautenticação do host deve falharsendo que no modo "Safe" os da-dos do cliente deverão continuarindisponíveis.

Bem Sucedido

Tabela 4.1: Testes efetuados para verificação das funcionalidades do módulo de encriptação dosdados da IPBrick cloud.

Os testes apresentados na Tabela 4.1 são uma descrição do trabalho de verificação feito após

o desenvolvimento de um protótipo módulo de encriptação dos dados da IPBrick cloud. Os resul-

tados dos testes demonstram a integração adequada dos protocolos estruturados e da ferramenta

eCryptfs no software IPBrick da IPBrick cloud. Os testes 1 e 2 comprovaram a eficácia por parte

da eCryptfs na garantia da confidencialidade dos dados. O teste 3 representa um teste de confir-

mação de um conhecimento adquirido, de que a eCryptfs não possui mecanismos de verificação

da integridade dos dados, no entanto, a violação da integridade dos dados por parte de um intruso

com vista à deturpação da informação e ao engano do cliente é impraticável devido ao modo de

atuação CBC da cifra AES que estabelece uma ligação de dependência entre os blocos de dados

encriptados de tal ponto que basta o corrompimento de um dos blocos para que os dados fiquem,

após desencriptação, num formato ilegível sendo que a este nível pode-se afirmar que o próprio

modo de atuação da cifra AES oferece proteção da integridade dos dados. O teste 4 foi realizado

com ajuda de engenheiros de administração de sistemas da equipa de R&D da IPBrick SA, em que

foi simulado um ataque típico em ambiente de virtualização que consiste na cópia de um disco vir-

tual de uma máquina com potencial interesse, por parte de um intruso. O teste foi concluido com

sucesso uma vez que os dados do ficheiro em estudo encontravam-se encriptados após a cópia do

disco virtual. Os testes 5 e 6 validaram funcionalidades dos protocolos criados sendo que no teste

4.3 Módulo de Backups da IPBrick Cloud 67

6 fez-se uso de um dos parâmetros presentes no protocolo de autenticação do host, o endereço

MAC da placa de rede virtual.

4.3 Módulo de Backups da IPBrick Cloud

4.3.1 Detalhes sobre o Funcionamento da Ferramenta Bacula

A ferramenta Bacula foi selecionada de forma perentória para integrar o modelo-solução final,

dando resposta a um dos objetivos principais propostos que consiste na implementação de uma

estratégia de backups dos dados da IPBrick cloud. Esta ferramenta possui licença open-source

AGPL version 3, e está escalada para o uso eficiente ao nível empresarial. O seu modo de atuação

foca-se numa arquitetura centralizada com a existência de um servidor de backups principal de-

signado, no vocabulário associado à ferramenta, por diretor. Usufruem das capacidades de gestão

e armazenamento de backups, do diretor, os elementos da arquitetura que na sintaxe se designam

por clientes.

VM1

director-daemon

VM2

le-daemon

Cliente 1

VM3

le-daemon

Cliente 2

le-daemon

Cliente 3

Backup

Restore

Backup

Restore

BackupRestore

storage-daemon

VM4

Servidor Bacula

Cliente 1Cliente 1

Cliente 2Cliente 2Cliente 2

Cliente 3Cliente 3Cliente 3

Figura 4.16: Exemplo de uma possível infraestrutura de rede de backups da IPBrick cloud.

A configuração dos diretores e dos clientes pode ser feita manipulando um conjunto de da-

emons: storage-daemon, file-daemon, e director-daemon. Na mesma máquina podem coexistir

diretor e cliente mas na prática comum, o diretor define o elemento central da rede de backups

ou o servidor de backups como demonstra a figura 4.16. Vários clientes podem estar ligados ao

mesmo diretor. A comunicação entre cliente e diretor é feita recorrendo à porta TCP 9101, que é


aberta após a realização de um processo de autenticação entre os mesmos. Os vários pedidos do

cliente são enviados a partir de uma interface CLI específica da ferramenta Bacula que se designa

por bconsole. Esses pedidos resultam na programação de uma tarefa, termo associado à sintaxe

da ferramenta Bacula que designa um backup ou um restore, definindo-se parâmetros necessários

à sua execução, destacando-se entre eles: o tipo de tarefa, a periodicidade da tarefa, a hora e data

para ser iniciada a sua execução e se se pretende que ocorra encriptação dos dados ou não.

4.3.2 Configurações Realizadas na Ferramenta Bacula

O protótipo do módulo de backups da IPBrick cloud é constituído por duas VMs tal como

representa o modelo-solução na Figura 3.4. No mesmo modelo considerou-se a VM2 como sendo

o agente principal da gestão de backups tendo sido necessário manipular os ficheiros associados

à director-daemon e à storage-daemon (Figura 4.16), para definir essa mesma VM como servidor

Bacula do protótipo. No ficheiro de configuração correspondente à director-daemon foram aplica-

das configurações para definição das tarefas que deveriam ser disponibilizadas, ao cliente Bacula,

atribuindo o endereçamento na rede VLAN da VM respetiva ao cliente, e definindo uma pool de

armazenamento dos dados dos backups. No ficheiro de configuração da storage-daemon fez-se o

endereçamento do servidor de armazenamento que consiste no próprio endereço na rede da VM2.

As configurações realizadas no servidor Bacula podem ser consultadas em C.1 e C.2 .

Da mesma forma e para completar a arquitetura do protótipo, configurou-se a VM1 como

sendo cliente Bacula havendo necessidade de proceder à manipulação do ficheiro de configuração

da file-daemon. Das configurações realizadas, destacam-se os procedimentos de autenticação efe-

tuados, utilizando-se a mesma password definida no ficheiro de configuração da director-daemon

no servidor Bacula. Destaca-se também a definição dos diretórios "/home1" e "/home2" como

os diretórios a partir dos quais devem ser feitos os backups dos dados, sendo estes os diretórios

correspondentes aos dados produzidos e armazenados pelo cliente da IPBrick SA. No anexo C.3

podem ser consultadas as configurações levadas a cabo para definição do cliente Bacula.

Como foi referido no ponto anterior, a comunicação entre cliente e servidor Bacula é feita a

partir de um canal próprio aberto na porta TCP 9101. Através da bconsole, é possível enviar pedi-

dos a partir do cliente ao servidor Bacula. Foi necessário proceder de igual forma, à configuração

da bconsole estando a mesma descrita no anexo C.4, sendo que também inclui um mecanismo de

autenticação fazendo uso da password do servidor Bacula.

4.3.3 Funcionalidade de Encriptação de Backups

Os backups são dados tipicamente em repouso, por esse motivo e pelo facto de o local de ar-

mazenamento dos dados dos backups no modelo-solução consistir numa VM apropriada para tal

na IPBrick cloud, ou seja, em espaço remoto, os dados devem permanecer encriptados até que seja

feito um restore do backup. A ferramenta Bacula possui uma funcionalidade própria de encrip-

tação de backups que permite garantir os requisitos de segurança pertencentes ao triângulo CID:

confidencialidade, integridade e disponibilidade. Essa funcionalidade recorre a diversas técnicas


criptográficas, destacando-se as seguintes: cifra assimétrica RSA, cifra simétrica AES e certifica-

dos x509. Os dados dos backups são encriptados na máquina correspondente ao cliente Bacula

e armazenados na máquina do diretor. As chaves criptográficas devem ficar permanentemente

armazenadas na máquina do cliente.

Chave privada RSA

Certi!cado x509

| |

client.key client.cert

Estrutura PKI

client.cert

/etc/bacula/

Figura 4.17: Protocolo com vista à geração da estrutura PKI para encriptação dos dados dosbackups, pela ferramenta Bacula.

A chave secreta simétrica para encriptação dos dados é gerada automaticamente a partir da

file-daemon do cliente, no entanto, o par de chaves público-privado RSA bem como o certificado

x509 devem ser fornecidos pelo utilizador. Para geração automática das chaves RSA e do certifi-

cado x509 auto-assinado pela IPBrick SA, foi criado o protocolo representado pela Figura 4.17.

Da geração da chave privada e acrescentado a chave pública correspondente, resulta o certificado

x509. A concatenação entre certificado x509 e chave privada forma uma public key infrastruc-

ture (PKI). O ficheiro correspondente à PKI é exportado para o diretório onde está localizada a

file-daemon do cliente Bacula. Os ficheiros correspondentes à chave privada e ao certificado x509

devem ser guardados num diretório seguro e distinto do "/etc/bacula". As recomendações da CSA

em relação às boas práticas para gestão de chaves criptográficas, enunciadas no ponto 2.3.3.5, são

seguidas, uma vez que as chaves mantém-se armazenadas num local diferente dos dados encrip-

tados. No caso de perda das chaves e do certificado, para que se mantenha a disponibilidade dos

dados dos backups, a ferramenta Bacula permite a criação de uma PKI suplente que é gerada, de

igual forma, a partir do protocolo representado pela Figura 4.17, e que deve ser armazenada num

local diferente da VM1. Os mecanismos criptográficos da ferramenta Bacula asseguram também

a verificação da integridade dos dados através do uso da função de hash, SHA-256.


4.3.4 Desenvolvimento do Protótipo

4.3.4.1 Tecnologias Utilizadas

Para implementação de um protótipo do módulo de backups da IPBrick cloud foram utilizadas

as seguintes tecnologias:

• Ambiente de Desenvolvimento - Duas VMs com o guest OS IPBrick v6.1 (Debian GNU/-

Linux 7.5 wheezy).

• Pacote de Instalação - Bacula-7.2.0.

• Linguagens Front-End - JavaScript, HTML, CSS.

• Gerenciador de Base de Dados - Gerenciador de base de dados PostgreSQL.

• Linguagens Back-End - PHP, Linux Shell Scripting.

4.3.4.2 Desenvolvimento do Front-End

A implementação do front-end foi desenvolvida na máquina do cliente Bacula, representando

essa máquina um possível cliente da IPBrick SA. Na interface web de gestão da IPBrick cloud

foi criado um sub-menu designado por "Backups Bacula" que aponta para a página principal do

módulo de backups dos dados da IPBrick cloud. A página principal (Figura 4.18), foi desenvolvida

de modo a apresentar uma lista de diferentes tarefas em estados distintos.

Figura 4.18: Página principal do módulo de backups da IPBrick cloud. Aparecem listadas paraexemplo, três tarefas com parametrizações distintas.

Na Figura 4.18 são apresentadas duas tarefas de backup que se distinguem pela parâmetro

periodicidade. Periodicidade "single" associada ao "Single Backup", indica que a tarefa de backup

programada deve ser realizada apenas uma única vez, definindo-se uma data e hora específicas

para a sua execução. Para as tarefas de periodicidade "daily" é necessário apenas definir a hora

que se pretende que iniciem. O IP do servidor de backups Bacula é exibido no parâmetro "Backup


Location". A encriptação é parametrizada apenas nas tarefas de backup. A tarefa restore acontece

no exato instante em que é programada, sendo necessário indicar apenas o ponto de restauro no

tempo, mantendo-se os restantes parâmetros associados ao backup selecionado para o efeito. Na

lista de tarefas da página principal é também possível visualizar o estado das mesmas. Existem

quatro estados distintos: "Programmed", "Running", "Finished" e "Error". A tarefa restore pelo

facto de ser executada no mesmo instante em que é programada, poderá passar por todos os estados

com exceção do "Programmed".

A partir da página principal, é possível criar uma nova tarefa acedendo à página correspondente

através da ligação "Insert". Os formulários diferem no tipo de tarefa a programar e no caso dos

backups, na periodicidade que se pretende atribuir. As Figuras 4.19, 4.20 e 4.21 representam os

três formulários criados para programação das diferentes tarefas.

Figura 4.19: Página correspondente à parametrização de um backup diário.


Figura 4.20: Página correspondente à parametrização de um backup singular.

Figura 4.21: Página correspondente à parametrização da tarefa restore.

A partir da lista de tarefas exposta na página principal, é também possível selecionar individu-

almente cada tarefa e alterar os parâmetros que lhe estão associados, bem como elimina-la da lista

de tarefas.


Figura 4.22: Resultado da implementação da página individual de cada tarefa.

4.3.4.3 Desenvolvimento do Middle-End

Para exportar a parametrização feita pelo cliente aquando da inserção, alteração ou eliminação

de uma tarefa, recorre-se ao auxílio de uma tabela criada para o propósito na base de dados local

da VM correspondente ao cliente Bacula, através do gestor PostgreSQL.

AdministradorAlterar_

Tarefa Tarefas

ID

Tarefa

Tipo

Nome

ID Morada

1 1

Endereço_IP

Inserir_

Tarefa

Eliminar_

Tarefa

Período

Data

Hora

Estado

Encriptação

Figura 4.23: Modelo entidade-associação na origem da criação da tabela de auxílio ao módulo debackups, na base de dados local.

As três relações distintas entre a entidade "Administrador" e a entidade "Tarefas Bacula" são

representadas na Figura 4.23. Foi criada uma tabela na base de dados local associada à entidade

"Tarefas Bacula" em que os tuplos da entidade representam as a maior parte das colunas integran-

tes da tabela. A chave primária "ID" da entidade "Tarefas Bacula" foi configurada, aquando da

geração da tabela, como sendo foreign-key de outra chave primária de uma tabela pertencente ao

schema associado à ferramenta Bacula, identificadora de cada tarefa programada na ferramenta.

Refira-se novamente que a ferramenta Bacula tem uma base de dados própria para auxílio na ges-


tão de backups localizada na VM correspondente ao diretor ou servidor Bacula. Essa interação

entre tabelas de diferentes schemas, possuindo ambas o mesmo elemento identificador de tarefas,

permite com que seja obtida informação relevante diretamente da base de dados da ferramenta

Bacula através da interface fornecida pela bconsole que suporta a realização de SQL queries do

lado do cliente. Para eliminar e alterar tarefas, adicionaram-se duas colunas à tabela associada à

entidade "Tarefas Bacula", que funcionam como flags indicando se a tarefa sofreu alteração ou

ordem de remoção.

4.3.4.4 Desenvolvimento do Back-End

O desenvolvimento propriamente dito do software relativo à camada back-end teve como base

a leitura dos valores inseridos pelo cliente na interface web de administração da IPBrick cloud,

a partir tabela criada para o efeito na base de dados local. Fazendo uso dos valores lidos, foram

executados pedidos ao servidor Bacula através da bconsole. Um exemplo de um pedido executado

a partir de um dos ficheiros desenvolvidos, pode ser observado na lista de código 4.4.

1 $ ( echo " run Backup " && echo "mod" && echo " 6 " && echo \ " " . $ho raDa ta . " \ " &&echo "mod" && echo " 1 " && echo \ " " . $ t i p o . " \ " && echo " yes " ) | b c o n s o l e

Lista de Código 4.4: Comando para execução de um pedido ao servidor Bacula para realização da

tarefa de backup.

O código da lista 4.4 é constituído maioritariamente por comandos estáticos da própria bibli-

oteca de comandos da bconsole. O comandos estáticos traçam o trajeto necessário para serem

aplicadas as configurações do cliente através dos comandos dinâmicos fazendo uso das variáveis

"$horaData" e "$tipo". A variável "$horaData" possui o valor correspondente à concatenação da

hora e da data definidas para execução da tarefa, e a variável "$tipo" possui o valor correspon-

dente ao tipo de backup a executar: incremental ou completo; sendo que o primeiro backup a

executar é por defeito um backup completo. Ambas as variáveis possuem os valores resultantes da

parametrização da tarefa de backup realizada pelo cliente da IPBrick SA.

A tarefa de backup com periodicidade diária requer ainda que seja programado de forma dinâ-

mica, um cronjob no sistema. Um exemplo de um cronjob relativo ao backup diário programado

para as 00:00h de cada dia pode ser visto na lista de código 4.5.

1 00 00 ∗ ∗ ∗ ( echo " run " && echo " 1 " && echo "mod" && echo " 1 " && echo " 1 " &&echo " yes " ) | b c o n s o l e

Lista de Código 4.5: Exemplo da definição de um cronjob para agendamento dos backups diários.

Para encriptar os dados dos backups na VM do cliente, é executado um script baseado no

protocolo da figura 4.17, aquando do primeiro pedido do cliente para realização de um backup en-

criptado, sendo que a partir daí as chaves criptográficas pertencentes ao cliente ficam armazenadas

nos diretórios secretos criados para o efeito, de forma permanente. É necessário também ajustar


dinamicamente as configurações da file-daemon do cliente Bacula (lista de código 4.6), de forma

a ativar a funcionalidade de encriptação do Bacula.

1

2 FileDaemon {3 Name = s r v r s −fd4 FDport = 91025 W o r k i n g D i r e c t o r y = / v a r / run / b a c u l a6 Pid D i r e c t o r y = / v a r / run / b a c u l a7 Maximum C o n c u r r e n t Jobs = 208 FDAddress = 1 7 2 . 3 1 . 3 . 5 89

10 # Dynamic c o n f i g u r a t i o n s t o e n a b l e e n c r y p t i o n11 PKI S i g n a t u r e s = Yes12 PKI E n c r y p t i o n = Yes13 PKI Keypa i r = " / e t c / b a c u l a / c l i e n t . pem"14 PKI Mas te r Keypa i r = " / e t c / b a c u l a / m a s t e r . pem"15 }

Lista de Código 4.6: Configurações geradas dinamicamente para ativação da encriptação dos

backups, linhas (10-14).

Na lista de código 4.6 gerada dinamicamente são ativadas as "PKI Signatures" para verifi-

cação da integridade dos dados, a funcionalidade de encriptação através da "PKI Encryption", e

indicados os caminhos da PKI gerada para encriptação dos dados no atributo "PKI Keypair", e da

PKI suplente no atributo "PKI Master Keypair". Caso não se deseje encriptar os dados para uma

dada tarefa, as configurações da file-daemon são novamente ajustadas ficando os atributos "PKI

Signatures" e "PKI Encryptions" ajustados com o parâmetro "No".

No que toca à implementação da tarefa de restore, esta requer a execução de um conjunto de

comandos fornecendo-se o ponto exato no tempo para a recuperação do backup que mais se apro-

xima desse ponto. A lista de código 4.7 mostra um exemplo do conjunto de comandos utilizados:

1 $ echo " r e s t o r e " && echo " 6 " && echo \ " " . $ho raDa ta . " \ " && echo " 2 " && echo " 2" && echo " mark ∗ " && echo " done " && echo " yes " ) | b c o n s o l e

Lista de Código 4.7: Comando para execução de um pedido ao servidor Bacula para realização da

tarefa de restore.

4.3.5 Testes Funcionais

Para comprovar a eficácia de toda a implementação feita na IPBrick cloud relativa ao módulo

de backup dos dados da ferramenta Bacula, foram realizados três testes conclusivos, sobre as

funcionalidades implementadas. Na tabela a baixo é possível observar o processo de validação

levado a cabo por cada teste realizado.


ID Descrição por Passos Progonóstico Resultado

1 Teste de verificação da execução de tarefaspela ferramenta Bacula:

1. Programação de uma tarefa backup arealizar no instante imediato.

2. Programação de uma tarefa restore a re-alizar a partir de um ponto anterior aoinstante atual.

3. Observação dos dados das tarefas nosdiretórios correspondentes.

Prevê-se a visualização dos da-dos relativos ao backup numapool de armazenamento em for-mato hexadecimal, no diretóriocorrespondente do servidor Ba-cula bem como a visualizaçãodos dados relativos ao restoreem claro no diretório correspon-dente no cliente Bacula.

Bem Sucedido

2 Teste de verificação da encriptação dos dadosdos backups:

1. Programação de uma tarefa backup arealizar no instante imediato, ativandoa funcionalidade de encriptação.

2. Observação dos dados no servidor Ba-cula efetuando um dump dos dados dapool, armazenados no formato hexade-cimal.


Após a realização de um dumpdos dados hexadecimais arma-zenados no servidor Bacula,espera-se que os mesmos se en-contrem no formato encriptado.Do resultado do restore devemser observados os dados correta-mente desencriptados.

Bem Sucedido

3 Teste do mecanismo de verificação da integri-dade dos dados:

1. Programação de uma tarefa backup arealizar no instante imediato, ativandoa funcionalidade de encriptação.

2. Manipulação dos dados do backup ar-mazenados no formato hexadecimal napool de armazenamento no servidorBacula.


Durante o restore aguarda-se adeteção da violação da integri-dade dos dados efetuada e algumprocedimento de ação relativa-mente ao dados em causa.

Bem Sucedido

Tabela 4.2: Testes efetuados para verificação das funcionalidades do módulo de backup dos dadosda IPBrick cloud.

4.4 Conclusão 77

De referir que os dados são comprimidos antes de serem armazenados na pool de armazena-

mento criada para o efeito no servidor Bacula e por isso ficam expostos num formato hexadecimal.

Para visualização dos dados em texto claro é necessário converte-los para o formato binário fa-

zendo um dump dos mesmos, utilizando para isso um comando Linux específico. Relativamente

ao teste sobre o mecanismo de integridade, após a deteção de irregularidades na integridade dos

dados, o restore é anulado e o backup correspondente aos dados manipulados é dado como incon-

sistente.

4.4 Conclusão

Todo o trabalho desenvolvido e descrito no presente capítulo teve como objetivo a implemen-

tação do modelo-solução definido no capítulo anterior, na IPBrick cloud.

A integração da eCryptfs decorreu sem causar perturbações no restante conjunto de servi-

ços pertencentes à IPBrick cloud e validou a estratégia de encriptação definida no capítulo 3,

conseguindo-se garantir essencialmente, os parâmetros de confidencialidade e disponibilidade

dos dados tipicamente em repouso, associados às aplicações assíncronas. Ao nível do utilizador

definiram-se dois modos de encriptação em que um deles procede ao armazenamento da password

do cliente na VM com o objetivo de aumentar o nível de disponibilidade do sistema. Mas ainda

que a password seja armazenada de forma ofuscada e a sua desencriptação requerer algum estudo

dos protocolos implementados por parte de um possível adversário, existirá sempre pelo menos

uma backdoor explorável. Contudo, pretende-se com estes dois modos, dar a opção de escolha ao

cliente entre um nível de segurança máximo ou a autonomia e com isso, a disponibilidade total

da IPBrick cloud isto porque, no caso de um reboot da VM do cliente seria necessário uma nova

introdução da password na interface de administração e até ao acontecimento do referido proce-

dimento, os dados permaneceriam encriptados. A implementação do mecanismo de autenticação

do host revelou-se uma alternativa consistente em relação aos restantes métodos criptográficos

aplicados. De fato, este mecanismo pode até prevenir eventuais backdoors existentes por exem-

plo, no modo de encriptação "Safe", já referido, alertando para possíveis invasões e impedindo a

exposição imediata dos dados em texto claro.

A implementação do módulo de backups dos dados trouxe um serviço eficaz à IPBrick cloud

permitindo um aumento da disponibilidade dos dados do cliente, existindo possíveis pontos de re-

cuperação úteis sobretudo em procedimentos de distaster recovery. Os dados dos backups podem

ainda ser encriptados, garantindo-se sempre a tríade CID no que a este módulo diz respeito.

A partir dos testes funcionais realizados, conclui-se que o modelo-solução foi corretamente

implementado sendo evidente a eficácia das estratégias e ferramentas adotadas.

Capítulo 5

Conclusões e Trabalho Futuro

O último capítulo da dissertação pretende expor ao leitor o ponto de vista do autor em relação

às metas concretizadas, tendo em conta os objetivos iniciais propostos pela IPBrick SA. Pretende

igualmente explorar o trabalho futuro no que diz respeito ao aperfeiçoamento das estratégias im-

plementadas para o cumprimento dos objetivos e possíveis procedimentos adicionais de segurança

a acrescentar aos já integrados na IPBrick cloud.

5.1 Objetivos Alcançados

Os três objetivos definidos inicialmente relacionados com a segurança da IPBrick cloud: im-

plementação de uma estratégia encriptação dos dados, implementação de uma estratégia de bac-

kup dos dados, e a criação de interfaces de gestão das estratégias para interação com o cliente

da IPBrick SA, foram satisfeitos. No entanto, as expetativas no que se refere essencialmente à

encriptação dos dados do cliente na IPBrick cloud eram porventura, demasiado otimistas. O autor

considerou inicialmente a abordagem de estratégias que possibilitassem a encriptação da totali-

dade dos dados do cliente, de forma permanente, independentemente da fase do ciclo de vida em

que se pudessem encontrar ou do tipo de aplicações a que estivessem associados sendo que, e tal

como foi descrito no capítulo 3, a estratégia baseada na aplicação do algoritmo FHE permitiria

hipoteticamente atingir esse nível de segurança criptográfica. Contudo, no contexto tecnológico

atual, não existe capacidade de processamento computacional suficiente para implementação prá-

tica da estratégia FHE. À falta de outras alternativas idênticas, optou-se por encurtar a gama de

dados da IPBrick cloud visada pelos processos de encriptação, integrando-se uma ferramenta crip-

tográfica no próprio ambiente de virtualização da cloud, permitindo-se garantir a segurança dos

dados armazenados no disco virtual sendo esses dados tipicamente dados em repouso. Posto isto,

o objetivo de encriptação dos dados foi reformulado e passou a ter-se em conta apenas a proteção

criptográfica exercida sobre os discos virtuais sendo o mesmo concretizado com sucesso, tal como

já referido anteriormente. Uma outra estratégia de autenticação do host do guest OS, não direta-

mente relacionadas com os objetivos da encriptação dos dados, mas que contribui ativamente para

a eficácia do mesmo, foi igualmente implementada e testada com sucesso.

79

80 Conclusões e Trabalho Futuro

Tendo em conta a estratégia de backup dos dados, o objetivo inicial em relação à mesma

passava pelo incremento do requisito de disponibilidade dos dados do cliente. Adicionalmente foi

também possível integrar uma funcionalidade específica de encriptação dos dados dos backups. O

objetivo foi assim concluído com êxito.

Das ameaças e vulnerabilidades nos serviços em cloud descritas em 2.3.2, os protótipos im-

plementados visam principalmente, colmatar as ameaças e vulnerabilidades que possam advir do

ponto 3 relativo à partilha de tecnologias, e do ponto 4 relativo à perda ou fuga de dados.

Considerando o próprio trabalho desenvolvido na IPBrick SA, os protótipos implementados

demonstraram o correto funcionamento das estratégias e ferramentas adotadas, para darem res-

posta aos objetivos propostos. Posto isto, os objetivos quer ao nível académico e científico, quer

ao nível da estratégia empresarial, foram alcançados de forma satisfatória.

5.2 Trabalho Futuro

5.2.1 Otimização do Módulo de Encriptação dos Dados

O módulo de encriptação dos dados da IPBrick cloud encontra-se estável relativamente aos

requisitos de segurança de confidencialidade e de disponibilidade dos dados. No entanto é de notar

a ausência de mecanismos de verificação da integridade dos dados, funcionalidade não incorporada

na ferramenta de encriptação eCryptfs. De fato, só o próprio modo de atuação de blocos CBC da

cifra AES pode criar de forma involuntária, um mecanismo de proteção da integridade dos dados.

Posto isto, uma das possíveis tarefas a ter em conta como trabalho futuro seria a implementação

de uma funcionalidade consistente, de verificação da integridade dos dados.

Ao nível da interação do cliente com o módulo de encriptação dos dados na interface web de

administração da IPBrick cloud, existe uma funcionalidade que não é suportada mas que deve ser

tida em conta no futuro, caso se proceda à maturação do protótipo já existente. Essa funcionalidade

consiste no mecanismo de alteração ou reset da password do cliente. Na implementação atual, de-

vido ao protocolo estruturado para gestão de chaves do cliente, a encriptação dos dados depende

da password introduzida pelo cliente aquando da primeira ativação do módulo. Uma alteração

dessa password com o sistema em produção, poderia fazer com que os dados ficassem permanen-

temente inacessíveis. Um mecanismo ao nível do back-end já foi preconcebido, tornando possível

ao cliente proceder à alteração da sua password sem que perca os dados protegidos até então. Esse

mecanismo deve ser executado quando o módulo de encriptação dos dados se encontra ativo, e

consiste na realização de um backup temporário dos dados, seguindo-se a alteração da password

do cliente e por último, o restore dos dados nos diretórios correspondentes sendo que a partir deste

último passo, tanto os dados antigos como os novos dados produzidos são encriptados no disco

virtual com uma chave secreta simétrica atualizada.

5.2 Trabalho Futuro 81

5.2.2 Procedimentos Adicionais no Módulo de Backup dos dados

O módulo de backup dos dados na interface web de administração da IPBrick cloud foi desen-

volvido tendo como princípio base o envio de pedidos a partir de um cliente Bacula, a um servidor

ou diretor Bacula, sendo ambos configurados maioritariamente de forma estática, tal como foi

descrito no ponto 4.3.2, para estabelecerem o canal de comunicação necessário para o envio de

pedidos pelo cliente Bacula e programação das tarefas no servidor Bacula. Tal como foi referido

no ponto 4.3.1 correspondente à descrição da ferramenta Bacula, esta pode ser configurada numa

VM para atuar como cliente, como servidor ou até para suportar os dois papéis simultaneamente

se tivermos em conta a existência de redes de backups diferentes. Como trabalho futuro sugere-

se, a adição de funcionalidades ao módulo de backup dos dados da interface de administração,

que permitam efetuar parametrizações de forma a configurar dinamicamente cada VM, para o pa-

pel que o cliente pretende que desempenhe sendo que de momento, o protótipo na interface de

administração está orientado apenas para a parametrização e programação das tarefas no cliente

Bacula.

Em relação à segurança criptográfica dos dados dos backups da ferramenta Bacula, recomenda-

se como trabalho futuro, o incremento da segurança ao nível do protocolo para geração da infra-

estrutura PKI da Figura 4.17 em que devem existir cópias quer do certificado x509 original, quer

do certificado x509 suplente, armazenadas por exemplo, numa base de dados segura, para que se

previnam possíveis infortúnios ligados à perda ou destruição dos certificados na VM onde estão

armazenados, e até para que se consiga garantir flexibilidade no acesso aos backups encriptados,

caso o cliente pretenda fazer um restore numa outra VM em sua posse, que não a originalmente

usada para fazer os backups.

5.2.3 Encriptação de Ficheiros na Rede Social Empresarial Cafe

Esta proposta para trabalho futuro não está diretamente relacionada com os objetivos pré-

estabelecidos para a presente dissertação, mas representa uma ideia consolidada do autor para

aumentar a oferta no que toca à disponibilização de mecanismos de segurança pela IPBrick cloud,

ao cliente da IPBrick SA. Num questionário realizado no âmbito da presente dissertação a 30 co-

laboradores de diversas empresas tecnológicas, em resposta à pergunta 11 do questionário: "Nos

seguintes serviços de armazenamento de ficheiros em Cloud: Dropbox, Google Docs, Box; consi-

deraria o uso de uma funcionalidade que permitisse encriptar os ficheiros que desejasse com uma

chave de encriptação fornecida por si?", cujo resultados podem ser observados no anexo D.1,

cerca de 90% dos colaborados inquiridos responderam afirmativamente. Este resultado prova a

existência de uma certa apreensão da comunidade tecnológica em relação à segurança dos da-

dos em espaço remoto, estando recetivos à criação de funcionalidades que permitam dar-lhes um

controlo muito superior sobre o estado e o formato dos seus próprios dados na cloud. A rede

social "cafe", é uma rede social empresarial desenvolvida e disponibilizada pela IPBrick SA atra-

vés da IPBrick cloud [43]. Esta rede social possui um módulo de armazenamento e gestão de

ficheiros tal como os serviços mencionados na questão acima transcrita. A proposta para trabalho

82 Conclusões e Trabalho Futuro

futuro consistiria na disponibilização de uma funcionalidade no referido módulo, que permitisse

de forma opcional e por cada ficheiro, a realização da encriptação on-the-fly através da introdução

de uma password pelo cliente. A desencriptação do ficheiro seria feita pelo cliente, introduzindo

a mesma password. A implementação back-end basear-se-ia num algoritmo de encriptação si-

métrica em que o ficheiro em texto claro seria parâmetro de entrada, juntamente com uma chave

secreta simétrica gerada a partir da password inserida pelo cliente, originando-se um ficheiro de

saída encriptado que substituiria o ficheiro em texto claro até então disponibilizado.

5.2.4 Módulo de Emissão Dinâmica de Assinaturas de E-mails

Outra proposta que não está diretamente relacionada com os objetivos definidos na presente

dissertação mas que se enquadra com a perspetiva de acréscimo do nível de segurança imposto na

IPBrick cloud, tem a ver com a proteção de e-mails, caracterizados como sendo dados tipicamente

em trânsito. Isto porque, tendo em conta a arquitetura do serviço de E-mail, existe grande propen-

são para ataques de espionagem sobre os conteúdos dos e-mails no ciclo de vida compreendido

entre o envio no remetente e a receção no destinatário. Apesar de, a maior parte dos message

transfer agents (MTAs), suportarem o protocolo criptográfico TLS para o envio seguro de e-mails,

continuam a existir servidores legacy que atuam como relays, espalhados pela rede global da Inter-

net, que não suportam o protocolo TLS. Para prevenir possíveis ataques no contexto descrito, uma

estratégia de emissão dinâmica de certificados para assinatura de e-mails pode ser incorporada na

IPBrick cloud. Assim por exemplo, caso um cliente da IPBrick SA pretendesse enviar e rece-

ber e-mails de forma totalmente segura, na comunicação entre o próprio e uma terceira entidade,

poderia através da interface web de administração da IPBrick cloud, preencher um conjunto de pa-

râmetros necessários à emissão automática de dois certificados, um para si próprio e outro para a

entidade com quem pretende comunicar. Os certificados seriam emitidos através de um protocolo

automático para geração de certificados da IPBrick SA. Seriam produzidos dois ficheiros, cada um

correspondente a cada certificado, e deveriam consistir em executáveis para instalação automática

nos clientes de e-mail (ex. Thunderbird). Um dos obstáculos adjacentes a esta estratégia poderia

consistir na forma de envio do certificado à entidade em questão, necessário para que a mesma

possa descodificar os e-mails assinados pelo cliente da IPBrick SA. Para tornar o sistema total-

mente autónomo, a transmissão do certificado à entidade em questão seria feita através do envio de

um e-mail ainda não protegido, é claro, correndo-se o risco de esse preciso e-mail ser submetido a

um ataque. Empresas de segurança dispõem no mercado serviços de emissão dinâmica de certifi-

cados para assinatura de e-mails seguindo uma estratégia similar mas que pode acarretar custos ao

comprador equivalentes por exemplo, a 12 euros por um certificado com período de validade de

um ano, tal como pode ser visto na página web da companhia de segurança Comodo [44]. Posto

isto, com a adoção de uma estratégia de emissão dinâmica de assinaturas digitais de e-mails na

IPBrick cloud, disponibilizava-se ao cliente, sem custos adicionais, um mecanismo de segurança

opcional que poderia proteger a confidencialidade, integridade, autenticidade e contabilidade ou

não-repúdio, dos e-mails.

Anexo A

Glossário

Adversário No contexto criptográfico designa uma entidade maliciosa.

Ataque do Dicionário Ataque típico a sistemas criptográficos por um adversário,

e que envolve a uso recursivo de um conjunto de palavras

previamente listadas.

Ataque do Arco-íris Ataque em que um adversário tenta reverter uma função de

hash a partir de tabelas pré-computadas.

Cronjob Tarefa que executa de forma automática, em data, hora e

periodicidade especificadas.

Estrutura PKI É um conjunto de entidades, procedimentos e regras neces-

sárias para a gestão de certificados digitais.

GnuPG Keyring Ferramenta para comunicações seguras, e que permite exe-

cutar várias operações criptográficas, inclusive a geração

de chaves de encriptação.

Informação do CPU Engloba os detalhes do processador acessíveis a partir do

comando Linux "cat /proc/cpuinfo".

John the Ripper É uma ferramenta para extorsão de senhas que se baseia

em ataques de força bruta.

Kernel Cryptographic API Framework própria para a gestão de operações criptográfi-

cas no Linux kernel.

83

84 Glossário

Linux Kernel Keyring Service Ferramenta que procede ao armazenamento e gestão de

chaves criptográficas no Linux kernel.

Linux Pluggable Módulo de autenticação dos utilizadores do sistema opera-

tivo Linux.

LUKS Especificação standard nos sistemas operativos Linux para

encriptação dos discos rígidos.

Lseek() Chamada ao sistema para especificar a leitura ou escrita

numa determinada posição de um dado ficheiro.

Modo de Operação Na criptografia designa um algoritmo a usar nas cifras de

bloco como a DES ou AES.

MPLS VPN Protocolo para implementação de uma rede virtual privada

através da técnica de transporte MPLS.

MTA Servidor ou software responsável pela transferência de e-

mails desde o remetente até ao destinatário ou a um ponto

intermédio.

OpenSSL Biblioteca open-source para implementação de algoritmos

ou protocolos criptográficos.

SDN Arquitetura que envolve um conjunto de tecnologias de re-

des e cujo objetivo é proporcionar ao administrador uma

fácil gestão do tráfego na rede num determinado momento.

System V Script Utilizado para configuração dos run-levels que definem o

momento de início e paragem das aplicações nos sistemas

operativos Linux.

Schema Termo utilizado na linguagem das base de dados relaci-

onais que designa um agrupamento de tabelas ou outros

procedimentos.

Trusted Platform Module Consiste num micro-controlador próprio para execução de

tarefas criptográficas, como a autenticação.

Tenancy No domínio da cloud, define se uma dada instância de soft-

ware serve múltiplos utilizadores (multi-tenancy), ou ape-

nas um utilizador (single-tenancy).

Glossário 85

User-Experience Termo que especifica a perceção da qualidade da interação

do utilizador com um dado produto.

x509 Standard que especifica o formato de certificados digitais

x509, de chaves públicas.

86 Glossário

Anexo B

Resultados dos Testes de Desempenho

Neste anexo são apresentados os ficheiros output dos testes de desempenho realizados com a

ferramenta bonnie++.

B.1 CryFS

Figura B.1: CryFS - teste 1.

87

88 Resultados dos Testes de Desempenho



B.2 EncFS

Figura B.4: EncFS - teste 1.


B.3 eCryptfs 89


B.3 eCryptfs

Figura B.7: eCryptfs - teste 1.




B.4 dm-crypt

Figura B.10: dm-crypt - teste 1.



B.5 File-System ext4 91

B.5 File-System ext4

Figura B.13: ext4 - teste 1.



Anexo C

Configurações da Ferramenta Bacula

Neste anexo são apresentadas configurações estáticas realizadas para definição da arquitetura

e das funcionalidades do modelo-solução relativamente à estratégia de backups da IPBrick cloud.

C.1 Director-Daemon - Servidor Bacula

1

2 D i r e c t o r { # d e f i n e mys e l f3 Name = bacu l a−d i r4 DIRpor t = 9101 # where we l i s t e n f o r UA c o n n e c t i o n s5 Q u e r y F i l e = " / e t c / b a c u l a / s c r i p t s / que ry . s q l "6 W o r k i n g D i r e c t o r y = " / v a r / run / b a c u l a "7 P i d D i r e c t o r y = " / v a r / run / b a c u l a "8 Maximum C o n c u r r e n t Jobs = 209 Password = " 0mzDIgN0wh1sHIepQh9kZ19NAbDYSnkA " # Conso le password

10 Messages = Daemon11 }12

13 JobDefs {14 Name = " D e f a u l t J o b "15 Type = Backup16 Leve l = I n c r e m e n t a l17 C l i e n t = s r v r s −fd18 F i l e S e t = " F u l l S e t "19 S c h e d u l e = " WeeklyCycle "20 S t o r a g e = F i l e 121 Messages = S t a n d a r d22 Pool = F i l e23 S p o o l A t t r i b u t e s = yes24 P r i o r i t y = 1025 Wri te B o o t s t r a p = " / v a r / run / b a c u l a /%c . b s r "26 }27

28

93

94 Configurações da Ferramenta Bacula

29 Job {30 Name = " RemoteBackup "31 JobDefs = " D e f a u l t J o b "32 C l i e n t = s r v r s −fd33 Pool = RemoteF i l e34 }35

36

37 Job {38 Name = " Res to reRemote "39 Type = R e s t o r e40 C l i e n t = s r v r s −fd41 F i l e S e t =" F u l l S e t "42 S t o r a g e = F i l e 143 Pool = F i l e44 Messages = S t a n d a r d45 Where = / v a r / l i b / b a c u l a / bacu l a−r e s t o r e s46 }47

48

49 # L i s t o f f i l e s t o be backed up50 F i l e S e t {51 Name = " F u l l S e t "52 I n c l u d e {53 O p t i o n s {54 s i g n a t u r e = MD555 }56

57 F i l e = / home158 F i l e = / home259 }60

61 Exclude {62 F i l e = / v a r / run / b a c u l a63 F i l e = / v a r / l i b / b a c u l a64 F i l e = / p roc65 F i l e = / tmp66 F i l e = / s y s67 F i l e = / . j o u r n a l68 F i l e = / . f s c k69 }70 }71

72 C l i e n t {73 Name = s r v r s −fd74 Address = 1 7 2 . 3 1 . 3 . 5 875 FDPort = 910276 C a t a l o g = MyCatalog

C.1 Director-Daemon - Servidor Bacula 95

77 Password = " 1wqRG04MfHTh8SowA1xR9f1MSk6rGa8E" # password f o rFileDaemon

78 F i l e R e t e n t i o n = 60 days # 60 days79 Job R e t e n t i o n = 6 months # s i x months80 AutoPrune = yes # Prune e x p i r e d Jobs / F i l e s81 }82

83 # D e f i n i t i o n o f f i l e V i r t u a l Au tochange r d e v i c e84 S t o r a g e {85 Name = F i l e 186 # Do n o t use " l o c a l h o s t " h e r e87 Address = 1 7 2 . 3 1 . 3 . 6 3 # N. B . Use a f u l l y q u a l i f i e d name h e r e88 SDPort = 910389 Password = " RBOtv0UjEoNA5iVJNFr1OSSOQlKGxLRt "90 Device = F i l e C h g r 191 Media Type = F i l e 192 Maximum C o n c u r r e n t Jobs = 10 # run up t o 10 j o b s a t h e same t ime93 }94

95 # G e n e r i c c a t a l o g s e r v i c e96 C a t a l o g {97 Name = MyCatalog98 dbname = " b a c u l a " ; d b a d d r e s s = " l o c a l h o s t " ; d b p o r t = " 5433 " ; d b u s e r = " b a c u l a

" ; dbpassword = " 32787 dcd2b49f0844a36e4ea24e967b8 "99 }

100

101 # F i l e Pool d e f i n i t i o n102 Pool {103 Name = F i l e104 Pool Type = Backup105 Recyc le = yes # Bacu la can a u t o m a t i c a l l y r e c y c l e

Volumes106 AutoPrune = yes # Prune e x p i r e d volumes107 Volume R e t e n t i o n = 365 days # one y e a r108 Maximum Volume Bytes = 50G # L i m i t Volume s i z e t o some th ing

r e a s o n a b l e109 Maximum Volumes = 100 # L i m i t number o f Volumes i n Pool110 Labe l Format = " Vol−" # Auto l a b e l111 }

Lista de Código C.1: Configurações realizadas no ficheiro de configuração relativo à director-

daemon.


C.2 Storage-Daemon - Servidor Bacula

1

2 S t o r a g e { # d e f i n i t i o n o f m ys e l f3 Name = bacu l a−sd4 SDPort = 9103 # D i r e c t o r ’ s p o r t5 W o r k i n g D i r e c t o r y = " / v a r / run / b a c u l a "6 Pid D i r e c t o r y = " / v a r / run / b a c u l a "7 Maximum C o n c u r r e n t Jobs = 208 SDAddress = 1 7 2 . 3 1 . 3 . 6 39 }

Lista de Código C.2: Configurações realizadas no ficheiro de configuração relativo à storage-

daemon.

C.3 File-Daemon - Cliente Bacula

1

2 D i r e c t o r {3 Name = bacu l a−d i r4 Password = " 1wqRG04MfHTh8SowA1xR9f1MSk6rGa8E"5 }6

7 FileDaemon { # t h i s i s me8 Name = s r v r s −fd9 FDport = 9102 # where we l i s t e n f o r t h e d i r e c t o r

10 W o r k i n g D i r e c t o r y = / v a r / run / b a c u l a11 Pid D i r e c t o r y = / v a r / run / b a c u l a12 Maximum C o n c u r r e n t Jobs = 2013

14 FDAddress = 1 7 2 . 3 1 . 3 . 5 815

16 PKI S i g n a t u r e s = Yes17 PKI E n c r y p t i o n = Yes18

19 PKI Keypa i r = " / e t c / b a c u l a / c l i e n t . pem"20 PKI Mas te r Key = " / e t c / b a c u l a / m a s t e r . c e r t "21 }22

23 # Send a l l messages e x c e p t s k i p p e d f i l e s back t o D i r e c t o r24 Messages {25 Name = S t a n d a r d26 d i r e c t o r = bacu l a−d i r = a l l , ! sk ipped , ! r e s t o r e d27

28 }

Lista de Código C.3: Configurações realizadas no ficheiro de configuração relativo à file-daemon.

C.4 Bconsole - Cliente Bacula 97

C.4 Bconsole - Cliente Bacula

1

2 D i r e c t o r {3 Name = bacu l a−d i r4 DIRpor t = 91015 a d d r e s s = " 1 7 2 . 3 1 . 3 . 6 3 "6 Password = " 0mzDIgN0wh1sHIepQh9kZ19NAbDYSnkA "7 }

Lista de Código C.4: Configurações realizadas no ficheiro de configuração da bconsole no cliente

Bacula.

Anexo D

Resultados do Questionário sobreSegurança na Cloud e Outros

D.1 Resultados do Questionário

Este questionário foi realizado durante os meses de maio e junho e envolveu cerca de 30

colaboradores de diferentes empresas tecnológicas portuguesas, recorrendo à plataforma de gestão

de questionários online que se designa por "qualtrics". No presente anexo divulga-se o conteúdo

do questionário bem como os resultados estatísticos correspondentes às respostas dadas pelos

colaborados consultados.

D.1.0.1 Cabeçalho 1

«Este questionário surge no âmbito de uma investigação decorrente da dissertação em desen-

volvimento pelo estudante Ricardo Manuel da Silva Sousa do Mestrado Integrado em Engenharia

Eletrotécnica e Computadores da Faculdade de Engenharia da Universidade do Porto, cujo tema

é: Segurança e Encriptação na Cloud. Pretende-se analisar a postura das empresas e dos seus co-

laboradores em relação a mecanismos de segurança na Cloud, mais concretamente, o mecanismo

de encriptação de informação importante e sensível para a empresa e para o colaborador. Todos

os dados resultantes do questionário serão tratados de forma a ser mantido o total anonimato dos

indivíduos consultados.»

99

100 Resultados do Questionário sobre Segurança na Cloud e Outros

D.1.0.2 Pergunta 1

Indique uma estimativa do número de colaboradores da empresa onde trabalha.1. Indique uma estimativa do número de colaboradores da empresa ondetrabalha.

Relatório inicialÚltima modificação: 06/17/2016

1 7 23%

2 10-49 3 10%

3 50-249 5 17%

4 >250 15 50%

Total 30

Valor mín. 1

Valor máx. 4

Média 2.93

Variação 1.58

Desvio padrão 1.26

Total de respostas 30

# Resposta Barra Resposta %

Estatística Valor

D.1.0.3 Pergunta 2

Em qual das seguintes áreas melhor enquadra a posição que assume na sua empresa?2. Em qual das seguintes áreas melhor enquadra a posição que assume na suaempresa?

1 Produção e/ou Desenvolvimento e Investigação 17 57%

2 Recursos Humanos e Suporte 1 3%

3 Marketing 4 13%

4 Administração e/ou Finanças 1 3%

5 Outra 3 10%

6 Vendas 1 3%

8 Apoio Técnico IT/Redes 3 10%

Total 30

Estagiário

Desenvolvimento de SW à medida do Cliente

Energia

Valor mín. 1

Valor máx. 8

Média 2.67

Variação 5.61

Desvio padrão 2.37



Outra

Estatística Valor

D.1 Resultados do Questionário 101


«Uma grande parte das aplicações existentes na Internet é disponibilizada numa cloud, dei-

xando de ser necessária a instalação e configuração de um dado serviço localmente. Várias

empresas procuram cada vez mais migrar os softwares que possuem, instalados localmente, para

um modelo em cloud. Existem inúmeras vantagens no uso desta tecnologia das quais se destacam:

a poupança de recursos do lado do utilizador e o aumento significativo do nível de acessibilidade

a um serviço. No entanto, um dos principais fatores inerentes à utilização de uma plataforma em

cloud é a segurança dos dados (...)", Ricardo Sousa em "Relatório final - Preparação da Disser-

tação 2015/2016".»

D.1.0.5 Pergunta 3

A sua empresa providencia-lhe algum tipo de serviço ou aplicação em cloud para auxílio no

desenvolvimento das tarefas que lhe são propostas ? Exemplos de serviços: gestão documental,

serviço de e-mail, VoIP.3. A sua empresa providencia-lhe algum tipo de serviço ou aplicação em Cloudpara auxílio no desenvolvimento das tarefas que lhe são propostas ? Exemplos deserviços: gestão documental, serviço de e-mail, VoIP.

1 Sim 26 87%

2 Não 4 13%

3 Não sei responder 0 0%

Total 30

Valor mín. 1

Valor máx. 2

Média 1.13

Variação 0.12

Desvio padrão 0.35



Estatística Valor

Caso a resposta à pergunta 3 seja negativa, é realizado um "salto" para a pergunta 5.


D.1.0.6 Pergunta 4

Confia na segurança dos dados da empresa armazenados e processados pelo serviço ou aplica-

ção em cloud que lhe é disponibilizado?4. Confia na segurança dos dados da empresa armazenados e processadospelo serviço ou aplicação em Cloud que lhe é disponibilizado?

1 Sim 24 92%

2 Não 2 8%

Total 26

Valor mín. 1

Valor máx. 2

Média 1.08

Variação 0.07

Desvio padrão 0.27



Estatística Valor

D.1.0.7 Pergunta 5

Faz uso de ferramentas de colaboração e partilha de ficheiros tais como (Box, Dropbox, Goo-

gle Docs, Office 365), e/ou de serviços de comunicação e social media tais como (Skype, Slack,

Facebook, LinkedIn, Twitter), por iniciativa própria, para apoio no desenvolvimento das suas ta-

refas na empresa?

5. Faz uso de ferramentas de colaboração e partilha de ficheiros tais como (Box,Dropbox, Google Docs, Office 365), e/ou de serviços de comunicação e socialmedia tais como (Skype, Slack, Facebook, LinkedIn, Twitter), por iniciativa própria,para apoio no desenvolvimento das suas tarefas na empresa?

1 Sim 29 97%

2 Não 1 3%

Total 30

Valor mín. 1

Valor máx. 2

Média 1.03

Variação 0.03

Desvio padrão 0.18



Estatística Valor


Caso a resposta à pergunta 5 seja negativa, é realizado um "salto" para a pergunta 7.

D.1.0.8 Pergunta 6

Confia na segurança dos dados armazenados e processados pelas ferramentas de colaboração

e partilha de ficheiros e/ou, serviços de comunicação e social media, que utiliza por iniciativa

própria no apoio ao desenvolvimento das suas tarefas na empresa?a apoio no desenvolvimento das

suas tarefas na empresa?

6. Confia na segurança dos dados armazenados e processados pelasferramentas de colaboração e partilha de ficheiros e/ou, serviços de comunicaçãoe social media, que utiliza por iniciativa própria no apoio ao desenvolvimento dassuas tarefas na empresa?

1 Sim 22 76%

2 Não 7 24%

Total 29

Valor mín. 1

Valor máx. 2

Média 1.24

Variação 0.19

Desvio padrão 0.44



Estatística Valor

D.1.0.9 Pergunta 7

Que importância atribui à segurança dos dados da sua empresa na cloud tendo em conta a

estratégia de negócio praticada?7. Que importância atribui à segurança dos dados da sua empresa na Cloudtendo em conta a estratégia de negócio praticada?

1 Extremamente importante 21 70%

2 Muito importante 7 23%

3 Moderadamente importante 2 7%

4 Pouco importante 0 0%

5 Nada importante 0 0%

Total 30

Valor mín. 1

Valor máx. 3

Média 1.37

Variação 0.38

Desvio padrão 0.61



Estatística Valor


D.1.0.10 Pergunta 8

A sua empresa utiliza algum tipo de técnica de encriptação para proteção de dados confiden-

ciais?8. A sua empresa utiliza algum tipo de técnica de encriptação para protecção dedados confidenciais?

1 Sim 12 40%

2 Não 5 17%

3 Não tenho conhecimento 13 43%

Total 30

Valor mín. 1

Valor máx. 3

Média 2.03

Variação 0.86

Desvio padrão 0.93



Estatística Valor


«"Fully Homomorphic Encryption (FHE) é um sistema criptográfico teoricamente funcional

em que todos os dados do utilizador de um dado serviço em cloud estão permanentemente encrip-

tados. Só o próprio utilizador tem acesso à informação em claro no seu computador. Todas as

operações necessárias para o funcionamento da cloud são processadas sobre os dados em formato

encriptado.". Mais sobre FHE em (http://www.wired.com/2014/11/hacker-lexicon-homomorphic-

encryption/).»

D.1.0.12 Pergunta 9

A implementação deste sistema garantiria um nível de segurança muito próximo do ideal para

toda a comunidade cibernética. Recorreria a uma framework baseada no FHE para proteção dos

seus dados pessoais na cloud?9. A implementação deste sistema garantiria um nível de segurança muitopróximo do ideal para toda a comunidade cibernética. Recorreria a umaframework baseada no FHE para proteção dos seus dados pessoais na Cloud?

1 Sim 27 90%

2 Não 2 7%

3 Não quero responder 1 3%

Total 30

Valor mín. 1

Valor máx. 3

Média 1.13

Variação 0.19

Desvio padrão 0.43



Estatística Valor


D.1.0.13 Pergunta 10

Os polémicos casos baseados em estratégias de pirataria informática com vista à divulgação de

conteúdo de elevado interesse para toda a população, exemplos: Wikileaks, Snowden, Panama Pa-

pers; deixariam de acontecer frequentemente com o uso do sistema FHE. As agências de segurança

poderiam perder a capacidade de espionagem sobre indivíduos e organizações potencialmente no-

civas à sociedade.

Posto isto, confiaria a disponibilização de backdoors (pontos de penetração num sistema de

segurança) a certas autoridades governamentais ou não governamentais para facilitar o processo

de desencriptação da informação dos utilizadores de um serviço em cloud?

10. Os polémicos casos baseados em estratégias de pirataria informática comvista à divulgação de conteúdo de elevado interesse para toda a população,exemplos: Wikileaks, Snowden, Panama Papers; deixariam de acontecerfrequentemente com o uso do sistema FHE. As agências de segurança poderiamperder a capacidade de espionagem sobre indivíduos e organizaçõespotencialmente nocivas à sociedade. Posto isto, confiaria a disponibilização debackdoors (pontos de penetração num sistema de segurança) a certasautoridades governamentais ou não governamentais para facilitar o processo dedesencriptação da informação dos utilizadores de um serviço em cloud?

1 Sim 9 30%

2 Não 17 57%

3 Não quero responder 4 13%

Total 30

Valor mín. 1

Valor máx. 3

Média 1.83

Variação 0.42

Desvio padrão 0.65



Estatística Valor


Nos seguintes serviços de armazenamento de ficheiros em cloud: Dropbox, Google Docs,

Box; consideraria o uso de uma funcionalidade que permitisse encriptar os ficheiros que desejasse

com uma chave de encriptação fornecida por si?11. Nos seguintes serviços de armazenamento de ficheiros em Cloud:Dropbox, Google Docs, Box; consideraria o uso de uma funcionalidade quepermitisse encriptar os ficheiros que desejasse com uma chave de encriptaçãofornecida por si?

1 Sim 27 90%

2 Não 3 10%

Total 30

Valor mín. 1

Valor máx. 2

Média 1.10

Variação 0.09

Desvio padrão 0.31



Estatística Valor



Conhece alguma das seguintes ferramentas de encriptação? 1.LUKS; 2.EncFS; 3.eCryptfs;

4.dm-crypt; 5.CryFS.12. Conhece alguma das seguintes ferramentas de encriptação? 1.LUKS;2.EncFS; 3.eCryptfs; 4.dm-crypt; 5.CryFS.

1 Não 23 77%

2 Sim 7 23%

Total 30

Valor mín. 1

Valor máx. 2

Média 1.23

Variação 0.19

Desvio padrão 0.43



Estatística Valor

D.2 Registo do E-mail enviado por Sebastian Messmer 107

D.2 Registo do E-mail enviado por Sebastian Messmer

20/06/2016 Gmail - Re: CryFS Contact Form (from [email protected])

https://mail.google.com/mail/u/0/?ui=2&ik=529ceb9ff1&view=pt&search=inbox&msg=153e0fc7faaa0328&siml=153e0fc7faaa… 1/2

Ricardo Sousa <[email protected]>

Re: CryFS Contact Form (from [email protected])Sebastian Messmer <[email protected]> Mon, Apr 4, 2016 at 12:15 PMTo: [email protected]

Hi Ricardo,

thanks for your interest. I've actually written my master's thesis about CryFS. If you want to take a look, youcan find it here: https://www.cryfs.org/cryfs_mathesis.pdf

I believe that cloud encryption will play a very important role in the future. Leaks of private data (e.g. pictures)are happening more and more often, and government mass surveillance doesn't seem to know anyboundaries. Many companies could gain a lot in terms of efficiency and productivity if they used the cloudmore, but they don't trust it for fear of their data being leaked to competitors. There have been tools beforeCryFS that could be used with cloud storage (EncFS for example), but they haven't been designed for thecloud and all have their disadvantages. That is why I think CryFS will play a very important part in future.

To make that happen, it has to be simple. We're not there yet, CryFS is much too hard to use for peoplewithout deep computer knowledge. To be widely adapted, it has to be as simple to use as the Dropbox clientitself. That's where I want to go with CryFS in the future. In an ideal world, encrypting your cloud storagewouldn't be an optin, but an optout if you don't want to encrypt it.

However, as you said, this solves only one very specific use case, namely storing your files in the cloud.There is much more happening in the cloud where CryFS can't help. It can't help protect your nonfile userdata, and it can't help if your cloud provider needs to run computations on your data. There, you would needfully homomorphic encryption. As far as I know, there aren't any fully homomorphic systems that are secureand have a good performance yet. Homomorphic encryption is a very interesting research topic and probablywill come up with some solutions here given some time.

Once there is a good homomorphic encryption scheme, there are two possibilities. If it doesn't have anydisadvantages for storing files (e.g. fulfills only lesser security definitions or is slower), CryFS could simplyswitch to using it. If it does have disadvantages, CryFS could either stay in its niche for storing files in thecloud, or it could offer homomorphic encryption scheme as a choice for the user.

I'm glad you like CryFS and I'd be very happy to get further feedback from you. Tell me what you think shouldbe improved, test it and report bugs, and let me know if there is anything I can help you with.

All the best,Sebastian

On 04.04.2016 12:20, CryFS Contact Form wrote:

CryFS Contact Form (from [email protected])

Email: [email protected]

Message:

Hi Sebastien,

I'm a student of Computing Engineering at University of Porto currently doing my master thesisrelated to cloud security and encryption. I found both the functionalities and security features ofCryFS to be really impressive and a good alternative for traditional tools as eCryptfs or Encfs. Iwould like to know if possible, your opinion about the future of cloud encryption. Do you thinkthese file level encryption tools in synchronization with public or private cloud services will bethe future of personal cloud security? What about "datainuse" (for certain cloud applications)that need to be in the clear format, don't you think that's also important to find a way of encryptall of that data without prejudice of applications functionalities (e.g fully homomorphicencryption)? Thanks in advance. I'm recommending CryFS to my colleagues and some Startups

Referências

[1] Cloud Security Alliance. Cloud Adoption Practices & Priorities Survey Report. Dispo-nível em https://downloads.cloudsecurityalliance.org/initiatives/surveys/capp/Cloud_Adoption_Practices_Priorities_Survey_Final.pdf, acedido a última vez em 28 de Janeiro de 2016.

[2] Assembleia da República. Decreto de lei 7/2004. Disponível em https://dre.pt/application/dir/pdf1sdip/2004/01/005A00/00700078.pdf acedido a últimavez em 20 de Janeiro de 2016.

[3] União Europeia. Project Practice. Disponível em https://practice-project.eu/home/mission-motivation acedido a última vez em 20 de Janeiro de 2016.

[4] Latif Shahed Mather Tim, Kumaraswamy Subra. Cloud Security and Privacy An EnterprisePerspective on Risks and Compliance. O’REILLY, 1a edição, 2009.

[5] Peter Mell e Timothy Grance. The NIST Definition of Cloud Computing. Relatório técnico,National Institute of Standards and Technology, Setembro 2011.

[6] Tharam Dillon. Cloud Computing: Issues and Challenges, Maio 2010. Disponível em http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5474674, acedidoa última vez em 13 de Janeiro de 2016.

[7] Qi Zhang, Lu Cheng, e Raouf Boutaba. Journal of internet services and applications. Cloudcomputing: state-of-the-art and research challenges, páginas 7–18, Abril 2010.

[8] ComputeNext. What is Cloud Service Brokerage?, 2015. Disponível em https://www.computenext.com/cloud-service-brokerage, acedido a última vez em 19 de Ja-neiro de 2016.

[9] Raouf Boutaba Nelson L.S. da Fonseca. Cloud Services, Networking, and Management.Wiley-IEE Press, 1a edição, 2015.

[10] Navendu Jain Srikanth Kandula Changhoon Kim Parantap Lahiri David A. Maltz ParveenPatel Sudipta Sengupta Albert Greenberg, James R. Hamilton. VL2: A Scalable and Flexi-ble Data Center Network. Disponível em http://www.cs.princeton.edu/~chkim/papers/vl2-cacm11.pdf, acedido a última vez em 19 de Janeiro de 2016.

[11] Nathan Farrington Nelson Huang Pardis Miri Sivasankar Radhakrishnan Vikram Subra-manya Amin Vahdat Radhika Niranjan Mysore, Andreas Pamboris. Portland: A ScalableFault-Tolerant Layer 2 Data Center Network Fabric. Disponível em http://cseweb.ucsd.edu/~vahdat/papers/portland-sigcomm09.pdf, acedido a última vez em19 de Janeiro de 2016.

109

https://downloads.cloudsecurityalliance.org/initiatives/surveys/capp/Cloud_Adoption_Practices_Priorities_Survey_Final.pdf



https://dre.pt/application/dir/pdf1sdip/2004/01/005A00/00700078.pdf

https://dre.pt/application/dir/pdf1sdip/2004/01/005A00/00700078.pdf

https://practice-project.eu/home/mission-motivation

https://practice-project.eu/home/mission-motivation

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5474674

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5474674

https://www.computenext.com/cloud-service-brokerage

https://www.computenext.com/cloud-service-brokerage

http://www.cs.princeton.edu/~chkim/papers/vl2-cacm11.pdf

http://www.cs.princeton.edu/~chkim/papers/vl2-cacm11.pdf

http://cseweb.ucsd.edu/~vahdat/papers/portland-sigcomm09.pdf

http://cseweb.ucsd.edu/~vahdat/papers/portland-sigcomm09.pdf

110 REFERÊNCIAS

[12] Nathan Farrington Nelson Huang Pardis Miri Sivasankar Radhakrishnan Vikram Su-bramanya Amin Vahdat Radhika Niranjan Mysore, Andreas Pamboris. Netlord: AScalable Multi-Tenant Network Architecture for Virtualized Datacenters. Disponí-vel em http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p62.pdf, acedido a última vez em 19 de Janeiro de 2016.

[13] Prominic. Which private cloud is right for my organization? Disponível em http://www.prominic.com/web.nsf/pages/datacenter-private-cloud, acedido aúltima vez em 19 de Janeiro de 2016.

[14] Prashant Shenoy Timothy Wood. The Case for Enterprise-Ready Virtual Private Clouds,2009. Disponível em https://www.cs.utah.edu/~kobus/docs/cloudnet.pdf,acedido a última vez em 13 de Janeiro de 2016.

[15] William Stallings. Cryptography and Network Security: Principles and Practice.O’REILLY, 5a edição, 2009.

[16] Cloud Security Alliance. Cloud Computing Vulnerability Incidents: A StatisticalOverview. Disponível em https://cloudsecurityalliance.org/download/cloud-computing-vulnerability-incidents-a-statistical-overview/,acedido a última vez em 20 de Janeiro de 2016.

[17] Cloud Security Alliance. Top Threats to Cloud Computing V1.0. Disponível em https://cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf, acedidoa última vez em 20 de Janeiro de 2016.

[18] Inc. SkyHigh. The Cloud Encryption Handbook: Encryption Schemes and Their Rela-tive Strengths and Weaknesses. Disponível em https://www.skyhighnetworks.com/offers/wp-encryption-handbook/, acedido a última vez em 23 de Janeiro de 2016.

[19] Project Practice. Secure Deduplication of Encrypted Data without Additional IndependentServers. Disponível em http://eprint.iacr.org/2015/455.pdf, acedido a últimavez em 31 de Janeiro de 2016.

[20] Arch Linux. Disk Encryption. Disponível em https://wiki.archlinux.org/index.php/Disk_encryption, acedido a última vez em 23 de Janeiro de 2016.

[21] LDAP Tool Box Project. Self-service password. Disponível em http://ltb-project.org/wiki/documentation/self-service-password, acedido a última vez em 28de Janeiro de 2016.

[22] Cloud Security Alliance. SecaaS Implementation Guidance. Disponível emhttps://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf, acedido a últimavez em 31 de Janeiro de 2016.

[23] Inc. Cisco Systems. Cisco UCS Servers Raid Guide. Disponível em http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c/sw/raid/configuration/guide/RAID_GUIDE.pdf, acedido a última vez em 23 de Janeiro de2016.

http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p62.pdf

http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p62.pdf

http://www.prominic.com/web.nsf/pages/datacenter-private-cloud

http://www.prominic.com/web.nsf/pages/datacenter-private-cloud

https://www.cs.utah.edu/~kobus/docs/cloudnet.pdf

https://cloudsecurityalliance.org/download/cloud-computing-vulnerability-incidents-a-statistical-overview/

https://cloudsecurityalliance.org/download/cloud-computing-vulnerability-incidents-a-statistical-overview/

https://cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf

https://cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf

https://www.skyhighnetworks.com/offers/wp-encryption-handbook/

https://www.skyhighnetworks.com/offers/wp-encryption-handbook/

http://eprint.iacr.org/2015/455.pdf

https://wiki.archlinux.org/index.php/Disk_encryption

https://wiki.archlinux.org/index.php/Disk_encryption

http://ltb-project.org/wiki/documentation/self-service-password

http://ltb-project.org/wiki/documentation/self-service-password

https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf


http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c/sw/raid/configuration/guide/RAID_GUIDE.pdf



REFERÊNCIAS 111

[24] John D. Kubiatowicz Hakim Weatherspoon. Erasure Coding vs. Replication: A Quan-titative Comparison. Disponível em https://oceanstore.cs.berkeley.edu/publications/papers/pdf/erasure_iptps.pdf, acedido a última vez em 23 deJaneiro de 2016.

[25] Arch Linux. Backup Programs. Disponível em https://wiki.archlinux.org/index.php/Backup_programs#Rsync-type_backups, acedido a última vez em 28de Janeiro de 2016.

[26] Wayne Davison. Rsync. Disponível em https://rsync.samba.org/, acedido a últimavez em 31 de Janeiro de 2016.

[27] Bacula.org. Bacula. Disponível em http://www.bacula.org/, acedido a última vez em31 de Janeiro de 2016.

[28] Craig Barratt. BackupPC. Disponível em http://backuppc.sourceforge.net/index.html, acedido a última vez em 31 de Janeiro de 2016.

[29] Obnam.org. Obnam - backup program. Disponível em http://obnam.org/, acedido aúltima vez em 31 de Janeiro de 2016.

[30] Cloud Security Alliance. Secaas Implementation Guidance Category 8 - En-cryption. https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf, acedidoa última vez em 23 de Janeiro de 2016.

[31] Haridas N. How to put Encrypted Contents on Cloud Storages. Disponível em http://haridas.in/how-to-put-encrypted-contents-on-cloud-storages.html,acedido a última vez em 26 de Maio de 2016.

[32] Sebastien Messmer. Cryfs. Disponível em https://www.cryfs.org/, acedido a últimavez em 27 de Maio de 2016.

[33] Michael Halcrow Tyler Hicks, Dustin Kirkland. ecryptfs. Disponível em http://ecryptfs.org/, acedido a última vez em 27 de Maio de 2016.

[34] Valient Gough. Encfs. Disponível em https://wiki.archlinux.org/index.php/EncFS, acedido a última vez em 27 de Maio de 2016.

[35] dm crypt. dm-crypt. Disponível em https://wiki.archlinux.org/index.php/Dm-crypt, acedido a última vez em 27 de Maio de 2016.

[36] TrueCrypt. Truecrypt. Disponível em http://truecrypt.sourceforge.net/, ace-dido a última vez em 27 de Maio de 2016.

[37] Haridas N. Disk encryption - Performance Features. Disponível em https://wiki.archlinux.org/index.php/Disk_encryption#Performance_features, ace-dido a última vez em 26 de Maio de 2016.

[38] Russel Coker. bonnie++. Disponível em http://www.coker.com.au/bonnie++/readme.html, acedido a última vez em 26 de Maio de 2016.

[39] Bruce Schneier. Homomorphic Encryption Breakthrough. Disponível em https://www.schneier.com/blog/archives/2009/07/homomorphic_enc.html, acedido aúltima vez em 20 de Junho de 2016.

https://oceanstore.cs.berkeley.edu/publications/papers/pdf/erasure_iptps.pdf

https://oceanstore.cs.berkeley.edu/publications/papers/pdf/erasure_iptps.pdf

https://wiki.archlinux.org/index.php/Backup_programs#Rsync-type_backups

https://wiki.archlinux.org/index.php/Backup_programs#Rsync-type_backups

https://rsync.samba.org/

http://www.bacula.org/

http://backuppc.sourceforge.net/index.html

http://backuppc.sourceforge.net/index.html

http://obnam.org/



http://haridas.in/how-to-put-encrypted-contents-on-cloud-storages.html

http://haridas.in/how-to-put-encrypted-contents-on-cloud-storages.html

https://www.cryfs.org/

http://ecryptfs.org/

http://ecryptfs.org/

https://wiki.archlinux.org/index.php/EncFS

https://wiki.archlinux.org/index.php/EncFS

https://wiki.archlinux.org/index.php/Dm-crypt

https://wiki.archlinux.org/index.php/Dm-crypt

http://truecrypt.sourceforge.net/

https://wiki.archlinux.org/index.php/Disk_encryption#Performance_features

https://wiki.archlinux.org/index.php/Disk_encryption#Performance_features

http://www.coker.com.au/bonnie++/readme.html

http://www.coker.com.au/bonnie++/readme.html

https://www.schneier.com/blog/archives/2009/07/homomorphic_enc.html

https://www.schneier.com/blog/archives/2009/07/homomorphic_enc.html

112 REFERÊNCIAS

[40] Safenet Inc. Fingerprinting in Single Host VM Environments. Disponível emhttp://sentinelrms.safenet-inc.com/RMSDocumentation/Vendor/Content/DevGuide/Chapter%2015_VMs/Fingerprinting%20in%20Single%20Host%20VM%20Environments.htm, acedido a última vez em 27 de Maio de 2016.

[41] Michael Austin Halcrow. ecryptfs: An Enterprise-class Cryptographic Filesystemfor Linux. Disponível em https://www.ibm.com/support/knowledgecenter/linuxonibm/liaax/halcrow-05.pdf, acedido a última vez em 27 de Maio de 2016.

[42] Sylvain Pelissier. How to crack Ubuntu encryption and pas-swords. Disponível em https://cybermashup.com/2015/08/25/how-to-crack-ubuntu-disk-encryption-and-passwords/, acedido a úl-tima vez em 27 de Maio de 2016.

[43] IPBrick SA. Redes Sociais Empresariais. Disponível em http://www.ipbrick.com/ipbrick-cafe-enterprise-social-network/, acedido a última vez em 6 de Junhode 2016.

[44] Comodo. Purchase Corporate Secure Email Digital Certificate. Disponívelem https://www.enterprisessl.com/ssl-certificate-products/addsupport/secure-email-certificates.html?s_track=7639&key5sk1=5e8828a29b7f4a16fb36faf6884327ae10ff1109, acedido a última vez em 6 deJunho de 2016.

http://sentinelrms.safenet-inc.com/RMSDocumentation/Vendor/Content/DevGuide/Chapter%2015_VMs/Fingerprinting%20in%20Single%20Host%20VM%20Environments.htm



https://www.ibm.com/support/knowledgecenter/linuxonibm/liaax/halcrow-05.pdf

https://www.ibm.com/support/knowledgecenter/linuxonibm/liaax/halcrow-05.pdf

https://cybermashup.com/2015/08/25/how-to-crack-ubuntu-disk-encryption-and-passwords/

https://cybermashup.com/2015/08/25/how-to-crack-ubuntu-disk-encryption-and-passwords/

http://www.ipbrick.com/ipbrick-cafe-enterprise-social-network/

http://www.ipbrick.com/ipbrick-cafe-enterprise-social-network/

https://www.enterprisessl.com/ssl-certificate-products/addsupport/secure-email-certificates.html?s_track=7639&key5sk1=5e8828a29b7f4a16fb36faf6884327ae10ff1109



ipbrick cloud: segurança e encriptação de dados · 2019-07-22 · resumo as previsões apontam...

Documents