IPBrick Cloud: Segurança e Encriptação de Dados · 2019-07-22 · Resumo As previsões apontam...
Transcript of 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
ii
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
iv
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
vi
“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
viii
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
xvii
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.
8 Revisão Bibliográfica
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
2.2 Definição e Estrutura da Cloud 9
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
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
10 Revisão Bibliográfica
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
2.2 Definição e Estrutura da Cloud 11
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.
12 Revisão Bibliográfica
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.
2.2 Definição e Estrutura da Cloud 13
– 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]:
14 Revisão Bibliográfica
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,
16 Revisão Bibliográfica
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.
2.3 Segurança dos Dados na Cloud 17
• 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
18 Revisão Bibliográfica
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
2.3 Segurança dos Dados na Cloud 19
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.
20 Revisão Bibliográfica
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
2.3 Segurança dos Dados na Cloud 21
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:
22 Revisão Bibliográfica
• 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
2.3 Segurança dos Dados na Cloud 23
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.
24 Revisão Bibliográfica
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.
2.3 Segurança dos Dados na Cloud 25
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].
26 Revisão Bibliográfica
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].
2.3 Segurança dos Dados na Cloud 27
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
28 Revisão Bibliográfica
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ó
32 Projeto e Estrutura da Solução
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
e mecanismos de encriptação e
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
Sincronização dos dados
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
34 Projeto e Estrutura da Solução
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
e mecanismos de encriptação e
desencriptação na IPBrick Cloud.
Proteção dos dados é sempre feita
aquando e durante o armazenamento
na Cloud.
1 3
Cliente
Sincronização dos dados
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.
36 Projeto e Estrutura da Solução
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 Estudo de Ferramentas Criptográficas 37
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.
38 Projeto e Estrutura da Solução
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.
3.5 Estudo de Ferramentas Criptográficas 39
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.
40 Projeto e Estrutura da Solução
• 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.
3.5 Estudo de Ferramentas Criptográficas 41
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.
42 Projeto e Estrutura da Solução
• 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.
44 Projeto e Estrutura da Solução
• 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
3.6 Modelo-Solução 45
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.
46 Projeto e Estrutura da Solução
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 Modelo-Solução 47
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.
48 Projeto e Estrutura da Solução
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].
52 Implementação do Modelo-Solução na IPBrick Cloud
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
4.2 Módulo de Encriptação de Dados 53
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.
54 Implementação do Modelo-Solução na IPBrick Cloud
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í-
4.2 Módulo de Encriptação de Dados 55
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
56 Implementação do Modelo-Solução na IPBrick Cloud
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.
4.2 Módulo de Encriptação de Dados 57
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.
58 Implementação do Modelo-Solução na IPBrick Cloud
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".
4.2 Módulo de Encriptação de Dados 59
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.
60 Implementação do Modelo-Solução na IPBrick Cloud
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.
4.2 Módulo de Encriptação de Dados 61
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
62 Implementação do Modelo-Solução na IPBrick Cloud
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
4.2 Módulo de Encriptação de Dados 63
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:
64 Implementação do Modelo-Solução na IPBrick Cloud
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.
4.2 Módulo de Encriptação de Dados 65
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:
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. 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:
1. Ativação do módulo de encriptação.
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:
1. Ativação do módulo de encriptação.
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
66 Implementação do Modelo-Solução na IPBrick Cloud
5 Verificação do funcionamento automático domodo de encriptação "Safe Mode":
1. Ativação do módulo de encriptação.
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 é
68 Implementação do Modelo-Solução na IPBrick Cloud
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
4.3 Módulo de Backups da IPBrick Cloud 69
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.
70 Implementação do Modelo-Solução na IPBrick Cloud
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
4.3 Módulo de Backups da IPBrick Cloud 71
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.
72 Implementação do Modelo-Solução na IPBrick Cloud
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.
4.3 Módulo de Backups da IPBrick Cloud 73
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-
74 Implementação do Modelo-Solução na IPBrick Cloud
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
4.3 Módulo de Backups da IPBrick Cloud 75
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.
76 Implementação do Modelo-Solução na IPBrick Cloud
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.
3. Programação de uma tarefa restore a re-alizar a partir de um ponto anterior aoinstante atual.
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.
3. Programação de uma tarefa restore a re-alizar a partir de um ponto anterior aoinstante atual.
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.
78 Implementação do Modelo-Solução na IPBrick Cloud
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
Figura B.2: CryFS - teste 2.
Figura B.3: CryFS - teste 3.
B.2 EncFS
Figura B.4: EncFS - teste 1.
Figura B.5: EncFS - teste 2.
B.3 eCryptfs 89
Figura B.6: EncFS - teste 3.
B.3 eCryptfs
Figura B.7: eCryptfs - teste 1.
Figura B.8: eCryptfs - teste 2.
Figura B.9: eCryptfs - teste 3.
90 Resultados dos Testes de Desempenho
B.4 dm-crypt
Figura B.10: dm-crypt - teste 1.
Figura B.11: dm-crypt - teste 2.
Figura B.12: dm-crypt - teste 3.
B.5 File-System ext4 91
B.5 File-System ext4
Figura B.13: ext4 - teste 1.
Figura B.14: ext4 - teste 2.
Figura B.15: ext4 - teste 3.
92 Resultados dos Testes de Desempenho
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.
96 Configurações da Ferramenta Bacula
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.
98 Configurações da Ferramenta 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
Total de respostas 30
# Resposta Barra Resposta %
Outra
Estatística Valor
D.1 Resultados do Questionário 101
D.1.0.4 Cabeçalho 2
«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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
Caso a resposta à pergunta 3 seja negativa, é realizado um "salto" para a pergunta 5.
102 Resultados do Questionário sobre Segurança na Cloud e Outros
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
Total de respostas 26
# Resposta Barra Resposta %
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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
D.1 Resultados do Questionário 103
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
Total de respostas 29
# Resposta Barra Resposta %
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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
104 Resultados do Questionário sobre Segurança na Cloud e Outros
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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
D.1.0.11 Cabeçalho 3
«"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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
D.1 Resultados do Questionário 105
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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
D.1.0.14 Pergunta 11
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
Total de respostas 30
# Resposta Barra Resposta %
Estatística Valor
106 Resultados do Questionário sobre Segurança na Cloud e Outros
D.1.0.15 Pergunta 12
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
Total de respostas 30
# Resposta Barra Resposta %
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
108 Resultados do Questionário sobre Segurança na Cloud e Outros
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
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.
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.
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.