F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTOIPBrick Cloud: Segurança e
Encriptaçã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
Resumo
As previsões apontam para que num futuro relativamente próximo, as estratégias de negócio das empresas tecnológicas espalhadas pelo mundo seja fortemente influenciada pela computação em cloud. De facto, a flexibilidade ao nível da demanda e oferta de recursos computacionais e o parâmetro de acessibilidade intrínseco à tecnologia, tornam a cloud atrativa quer para os clientes que usufruem dos seus serviços, quer para os fornecedores que os disponibilizam. Contudo, o principal motivo causador de relutância em relação à migração de serviços existentes dentro de portas 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 isso propõe com que sejam criados mecanismos de segurança baseados em princípios criptográficos e outros que almejam a manutenção da confidencialidade, integridade e disponibilidade dos dados do cliente.
No seguimento das pretensões da IPBrick SA em relação à IPBrick cloud, desenvolveu-se o trabalho descrito ao longo da presente dissertação, e que engloba o estudo e implementação de uma estratégia de encriptação dos dados do cliente, e o estudo e implementação de uma estratégia de backup dos dados do cliente, ambas ao nível da IPBrick cloud.
Abstract
Predictions on the future business strategies of IT companies are indicating that they will be greatly influenced by cloud computing technologies. In fact, both the flexibility associated with the deployment of computing resources and the accessibility parameter of cloud computing, make this technology attractive to the services providers and their clients. However, the main reason why a part of the global IT community is somewhat afraid to migrate their services provided under 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 IT communications market and it wants to prevent possible objections to the use of this technology due to the lack of data security. So that IPBrick SA recommends the implementation of security mechanisms based on cryptographic principles and other security procedures aiming to maintain the 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 been developed and it is described in this dissertation, covering researching and implementation of an encryption strategy of the client’s data, and the researching and implementation of a backup strategy of the client’s data, both at the IPBrick cloud level.
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 todo o percurso previamente realizado que fez com que, passados 5 anos, conseguisse alcançar a reta final 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 longo dos ú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 dos objetivos 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ções para que pudesse alcançar este objetivo e porque foram o meu grande poço de motivação em todos os momentos deste trajeto.
Agradeço à minha irmã pelo seu apoio, pelos conselhos e pelo seu entusiasmo que contagiou todo o meu percurso até esta reta final.
Agradeço à minha namorada pois foi ela a pessoa que mais de perto acompanhou todos os momentos decisivos do meu percurso académico, pela sua paciência e generosidade, e porque sem 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 5 anos, pela companhia, apoio e bem estar que me proporcionaram, pelos momentos de festa e por todas 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 trabalho relativo à dissertação.
Agradeço à Faculdade de Engenharia da Universidade do Porto por ter sido a casa que me acolheu, e porque nela adquiri todo o conhecimento, toda a capacidade de análise e de introspeção e toda a cultura de engenharia, requisitos necessários para o sucesso de um engenheiro no contexto atual da sociedade tecnológica.
Ricardo M. Sousa
“Encryption protects our data. It protects our data when it’s sitting on our computers and in data centers, 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
Conteúdo
1 Introdução 1 1.1 Contexto . . . 1 1.2 Motivação . . . 2 1.3 Objetivos . . . 3 1.4 Estrutura da Dissertação . . . 4 2 Revisão Bibliográfica 5 2.1 Introdução . . . 52.2 Definição e Estrutura da Cloud . . . 6
2.2.1 O Conceito de Computação em Cloud . . . 6
2.2.2 Modelos da Cloud . . . 7
2.2.3 Ótica do Negócio . . . 8
2.2.4 Tecnologias Relevantes . . . 10
2.2.5 Virtualização . . . 11
2.2.6 Interfaces de Gestão . . . 13
2.2.7 Contextualização da IPBrick Cloud . . . 14
2.3 Segurança dos Dados na Cloud . . . 15
2.3.1 Conceitos de Segurança Computacional . . . 15
2.3.2 Ameaças e Vulnerabilidades nos Serviços em Cloud . . . 17
2.3.3 Tecnologias Criptográficas . . . 18
2.3.4 Disponibilidade e Backups dos Dados . . . 25
2.3.5 Classificação dos Dados . . . 27
2.4 Conclusão . . . 28
3 Projeto e Estrutura da Solução 29 3.1 Introdução . . . 29
3.2 Aplicações e Dados da IPBrick Cloud . . . 30
3.2.1 Tipos de Aplicações . . . 30
3.2.2 Dados da IPBrick Cloud . . . 30
3.3 Estratégias para Encriptação dos Dados na IPBrick Cloud . . . 31
3.3.1 Estratégia 1 - Encriptação na Extremidade do Cliente . . . 31
3.3.2 Estratégia 2 - Implementação do Algoritmo Full Homomorphic Encryption 32 3.3.3 Estratégia 3 - Encriptação na Extremidade da IPBrick Cloud . . . 33
3.4 Estratégia para Backups dos Dados da IPBrick Cloud . . . 34
3.4.1 Análise dos Requisitos . . . 34
3.4.2 Ferramenta a Adotar . . . 35
3.5 Estudo de Ferramentas Criptográficas . . . 35
3.5.1 Análise Qualitativa de Ferramentas de Encriptação do Disco . . . 36
3.5.2 Testes de Desempenho sobre Ferramentas de Encriptação do Disco . . . 37
3.5.3 Conclusões e Considerações . . . 42
3.6 Modelo-Solução . . . 43
3.6.1 Decisões sobre Estratégias e Ferramentas a Adotar . . . 43
3.6.2 Mecanismo de Segurança Adicional - Autenticação do Host . . . 46
3.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 49 4.1 Introdução . . . 49
4.2 Módulo de Encriptação de Dados . . . 50
4.2.1 Detalhes sobre o Funcionamento da Ferramenta de Encriptação Adotada . 50 4.2.2 Protocolo de Gestão de Chaves Criptográficas . . . 53
4.2.3 Desenvolvimento do Protótipo . . . 55
4.2.4 Implementação do Mecanismo de Autenticação do Host . . . 63
4.2.5 Testes Funcionais . . . 64
4.3 Módulo de Backups da IPBrick Cloud . . . 67
4.3.1 Detalhes sobre o Funcionamento da Ferramenta Bacula . . . 67
4.3.2 Configurações Realizadas na Ferramenta Bacula . . . 68
4.3.3 Funcionalidade de Encriptação de Backups . . . 68
4.3.4 Desenvolvimento do Protótipo . . . 70
4.3.5 Testes Funcionais . . . 75
4.4 Conclusão . . . 77
5 Conclusões e Trabalho Futuro 79 5.1 Objetivos Alcançados . . . 79
5.2 Trabalho Futuro . . . 80
5.2.1 Otimização do Módulo de Encriptação dos Dados . . . 80
5.2.2 Procedimentos Adicionais no Módulo de Backup dos dados . . . 81
5.2.3 Encriptação de Ficheiros na Rede Social Empresarial Cafe . . . 81
5.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 87 B.1 CryFS . . . 87
B.2 EncFS . . . 88
B.3 eCryptfs . . . 89
B.4 dm-crypt . . . 90
B.5 File-System ext4 . . . 91
C Configurações da Ferramenta Bacula 93 C.1 Director-Daemon - Servidor Bacula . . . 93
C.2 Storage-Daemon - Servidor Bacula . . . 96
C.3 File-Daemon - Cliente Bacula . . . 96
CONTEÚDO xi
D Resultados do Questionário sobre Segurança na Cloud e Outros 99
D.1 Resultados do Questionário . . . 99
D.2 Registo do E-mail enviado por Sebastian Messmer . . . 107
Lista de Figuras
2.1 Características das clouds públicas e privadas. . . 8
2.2 Representação de uma estrutura em pirâmide com taxonomias e exemplos. . . . 9
2.3 Canal de comunicação seguro em redes privadas. . . 11
2.4 Representação da arquitetura da virtualização através de um modelo de camadas. 11 2.5 Ilustração da estratégia da IPBrick cloud, baseada em SaaS. . . 15
2.6 Representação da tríade CID. . . 16
2.7 Modelo simplificado do processo de encriptação simétrica. . . 19
2.8 Ilustração do trade-off existente nas várias cifras e adaptações descritas (ilustração inspirada no relatório da SkyHigh Networks). . . 20
2.9 Modelo simplificado do processo de encriptação assimétrica com confidenciali-dade garantida. . . 21
2.10 Esquema de implementação do MAC sem confidencialidade garantida. . . 23
2.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. . . 32
3.2 Funcionamento conceptual da Full Homomorphic Encryption. . . 33
3.3 Encriptação do lado da IPBrick Cloud. . . 34
3.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 inspirada na figura 1 do relatório da IBM: "eCryptfs: An Enterprise-class Cryptographic Filesystem 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 é geincorpo-rada uma assinatura respetiva. . . 52
4.3 Partição do disco virtual "/dev/sda7" montada no diretório "/home1". . . 53
4.4 Diretório "/home1" montado nele próprio pela eCryptfs, encontrado-se assim pro-tegido. . . 54
4.5 Protocolo para gestão de chaves do cliente utilizado na implementação do módulo de encriptação de dados da IPBrick cloud. . . 54
4.6 Página principal da interface web de administração da IPBrick cloud. . . 56
4.7 Acesso ao módulo de encriptação do menu da interface de administração. . . 57
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. . . 57
4.9 Implementação da página informativa que faz a distinção entre os modos "Safe" e "Extremely Safe". . . 58
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 agora com 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ível desativação. . . 59
4.13 Ilustração de um aviso que é lançado sempre que o módulo de encriptação se encontre 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ódulo de encriptação na base de dados local da VM. . . 60
4.15 Protocolo de autenticação do host implementado. O círculo a tracejado representa uma operação de concatenação. . . 64
4.16 Exemplo de uma possível infraestrutura de rede de backups da IPBrick cloud. . . 67
4.17 Protocolo com vista à geração da estrutura PKI para encriptação dos dados dos backups, pela ferramenta Bacula. . . 69
4.18 Página principal do módulo de backups da IPBrick cloud. Aparecem listadas para exemplo, três tarefas com parametrizações distintas. . . 70
4.19 Página correspondente à parametrização de um backup diário. . . 71
4.20 Página correspondente à parametrização de um backup singular. . . 72
4.21 Página correspondente à parametrização da tarefa restore. . . 72
4.22 Resultado da implementação da página individual de cada tarefa. . . 73
4.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. . . 87 B.2 CryFS - teste 2. . . 88 B.3 CryFS - teste 3. . . 88 B.4 EncFS - teste 1. . . 88 B.5 EncFS - teste 2. . . 88 B.6 EncFS - teste 3. . . 89 B.7 eCryptfs - teste 1. . . 89 B.8 eCryptfs - teste 2. . . 89 B.9 eCryptfs - teste 3. . . 89 B.10 dm-crypt - teste 1. . . 90 B.11 dm-crypt - teste 2. . . 90 B.12 dm-crypt - teste 3. . . 90 B.13 ext4 - teste 1. . . 91 B.14 ext4 - teste 2. . . 91 B.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. . . 31
3.3 Avaliação qualitativa das ferramentas. . . 36
3.4 Resultados dos testes de escrita, leitura e reescrita. Na coluna mais à esquerda estão representadas as ferramentas testadas. . . 39
3.5 Média aritmética dos resultados obtidos na tabela3.4. . . 39
3.6 Resultados do teste de pesquisa aleatória. . . 40
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 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 da tabela 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ção dos dados da IPBrick cloud. . . 66
4.2 Testes efetuados para verificação das funcionalidades do módulo de backup dos dados da IPBrick cloud. . . 76
Abreviaturas e Símbolos
AES Advanced Encryption Standard API Application Programming Interface AWS Amazon Web Services
AGPL Affero General Public License CBC Cipher Block Chaining CLI Command-Line interface CPU Central Processing Unit CSP Cloud Service Provider CSB Cloud Service Broker DES Data Encryption Standard
DMTF Distributed Management Task Force FIPS Federal Information Processing Standard FPE Format Preserving Encryption
FHE Fully Homomorphic Encryption GUI Graphical User Interface IaaS Infrastructure as a Service IP Internet Protocol
IPsec IP Security Protocol
KVM Kernel-based Virtual Machine LAN Local Area Network
LDAP Lightweight Directory Access Protocol LUKS Linux Unified Key Setup
WAN Wide Area Network
MPLS Multi Protocol Label Switching MTA Message Tranfer Agent
NAS Network Attached Storage
NIST National Institute of Standards and Technology NFS Network File System
OPE Order-Preserving Encryption OS Operating System
PaaS Platform as a Service PKI Public Key Infrastructure
RAID Redudant Array of Independent Disks REST Representational State Transfer RFC Request For Comments
RSA Rivest-Shamir-Adleman R&D Research and Development SaaS Software as a Service
SDN Software-Defined Networking SSH Secure Shell
TLS Transport Layer Security UUID Universally Unique Identifier
ABREVIATURAS E SÍMBOLOS xix
VLAN Virtual Local Area Network VM Virtual Machine
VPN Virtual Private Network WiFi 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 anexoD.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
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 disponibilizaimplementa-das a partir do mesmo.
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.
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 cloudsmas 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 Figura2.1podem ser observadas características relativas aos dois modelos implementa-dos com maior frequência para disponibilização de serviços por parte implementa-dos CSPs.
Cloud Pública Cloud Privada
Recursos físicos e virtuais partilhados
Recursos físicos e virtuais partilhados num ambiente privado
Conectividade através da Internet sem restrições
Conectividade através da Internet utilizando redes privadas ou canais seguros (ex. VPN)
Confidencialidade da
informação não é privilegiada Mais garantias na segurança da informação
Configurada e controlada pelo fornecedor do serviço
Controlo geral e manutenção feita pela entidade privada
Menos custos associados Custos de utilização superiores
mas com tendência para diminuirem
Foco no utilizador final (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-deras 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 Linkedin Youtube Skype salesforce Azure Google App Engine
Figura 2.2: Representação de uma estrutura em pirâmide com taxonomias e exemplos.
2.2.3.2 Abordagem ao Mercado
Para serem compreendidas as várias fragilidades e condicionantes existentes nos serviços disponibilizados em cloud, é importante efetuar a contextualização do mercado de venda e/ou revenda de serviços pelos CSPs ou outros intermediários. Tendo em conta o ponto anterior que apresentam os três tipos de taxonomias disponibilizadas pelos CSPs, pode-se inferir de forma automática que existem três modelos de negócio distintos.
Existe ainda um outro modelo de negócio praticado por entidades intermediárias. Não pos-suem infraestruturas associadas a um IaaS ou PaaS provider, mas alugam-nas e acrescentam valor de mercado para posterior disponibilização ao cliente. São os designados Cloud Service Brokers (CSBs). O modelo de negócio dos CSBs pode basear-se na agregação e integração dos vários ser-viços existentes providenciados por diferentes fornecedores, oferecendo um serviço ao cliente sem que o mesmo tenha que se preocupar com as infraestruturas que o implementam. Um CSB pode também implementar as suas próprias aplicações tendo como suporte os serviços disponibilizados por um IaaS ou PaaS provider [8]. Devido às grandes dificuldades de interoperabilidade entre
clouds, assunto a abordar no ponto 2.2.6, os CSBs servem como interface de união estabelecendo uma linguagem comum entre as várias infraestruturas.
2.2.4 Tecnologias Relevantes
2.2.4.1 Dispositivos de Acesso
A variedade de dispositivos de acesso a serviços ou aplicações disponibilizadas através de plataformas em cloud, aumentou consideravelmente na última década sendo que, neste momento, basta que um dispositivo tenha a capacidade de estabelecer conectividade com a rede Internet para que sirva como ponto de acesso a uma aplicação em cloud. Para além dos tradicionais computado-res pessoais e empcomputado-resariais, 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 centerslocalizados 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
. . .
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 armaarma-zenamento. 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 guestOS.
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]:
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 em2.2.5.2pela 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 Figura2.5ilustra 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 ClienteFigura 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 sese-gurança computacional que irão ser abordados ao longo dos restantes capítulos. A organização norte-americana NIST define segurança computacional na sua publicação designada por Computer Se-curity Handbook, como sendo: "The protection afforded to an automated information system in order to attain the applicable objectives of preserving the integrity, availability, and confidenti-ality of information system resources (includes hardware, software, firmware, information/ data,
and telecommunications". Da definição é possível retirar três requisitos essenciais no que toca à segurança dos dados na cloud [15]:
• Confidencialidade dos Dados - Assegura que os dados sensíveis não estejam no formato original ou destapados a possíveis indivíduos que não possuam autorização para acesso aos mesmos.
• Integridade dos Dados - Requisito que indica que os dados só devem ser alterados por indivíduos devidamente autorizados.
• Disponibilidade dos Dados - Assegura o correto funcionamento do sistema em causa, soft-waree 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 (Figura2.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 fide nciali dade Integr idade 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 cloudsegundo a CSA, são:
1. Abuso e Uso Descontrolado das Capacidades da Cloud - IaaS e PaaS providers por mo-tivos ligados ao próprio marketing empresarial, criam a ilusão da oferta de recursos compu-tacionais ilimitados, ao cliente. A falta de segurança no processo de registo de utilizadores oferece uma oportunidade aos spammers e outro tipo de adversários de efetuar o arma-zenamento, em grandes quantidades, de conteúdo inapropriado, sem que o anonimato do adversário seja posto em causa [16].
2. Adversários Internos - Falta de políticas de vigilância e controlo no serviço em cloud de uma empresa pode levar a que colaboradores mal intencionados consigam perpetrar ataques através do acesso às respetivas contas com as credenciais correspondentes, sem que exista qualquer tipo de barreira de segurança [16].
3. Interfaces de Gestão e APIs Inseguras - As interfaces de gestão e comunicação com a cloud que podem ser oferecidas pelos CSPs ou consistir em bibliotecas open-source, são alvo de ataques às credenciais de autenticação e aos dados do cliente na cloud, em caso de falha nos mecanismos de segurança implementados nessa interface [16].
4. Partilha de Tecnologias - A partilha de infraestruturas e recursos computacionais em ar-quiteturas multi-tenant pode permitir o acesso não autorizado ao conteúdo pertencente a um dado cliente, por parte de outros clientes. É uma consequência da falta de propriedades de isolamento dos hypervisores utilizados na virtualização, das partições de discos, de caches e da própria rede do data-center [16].
5. Perda ou Fuga de Dados - Existem várias potenciais vulnerabilidades para o comprometi-mento dos dados. Operações como eliminação ou alteração de dados armazenados na cloud sem que exista um mecanismo de backup ou então, a falta de métodos criptográficos que assegurem a confidencialidade, integridade e autenticidade dos dados, fazem com que esta ameaça possa ter, em caso de concretização, um impacto irreversível no serviço [16]. 6. Hijacking de Contas e Serviço - O roubo de credenciais através de ataques como phishing,
exploração de vulnerabilidades do software e outros tipos de fraude, continuam a sortir efeito nos serviços disponibilizados em cloud. Na concretização da ameaça, um adversário
poderia, por exemplo, assumir a identidade do utilizador proprietário da conta associada ao serviço e executar vários tipos de ataques em nome do mesmo [16].
7. Falhas de Hardware - Falhas nas tecnologias físicas (ex. routers, servidores), podem colo-car em causa a disponibilidade dos dados em cloud [17].
8. Desastres Naturais - Causas naturais (ex. furacões, cheias, descargas elétricas), podem pôr em risco a segurança das infraestruturas físicas das clouds [17].
9. Desenho e Planeamento das Infraestruturas Inadequados - Situações de overload devido à deficiência na disponibilização de recursos computacionais ou falhas no desenho da rede do serviço cloud [17].
2.3.3 Tecnologias Criptográficas
Faz-se neste ponto, o levantamento das tecnologias criptográficas que permitem colmatar pos-síveis vulnerabilidades relacionadas com a confidencialidade, integridade e autenticidade dos da-dos, e outras que procuram manter otimizado, o nível de disponibilidade dos dados. São descritas técnicas clássicas de criptografia que continuam em uso e técnicas recentes, estas últimas com maior fator de adaptabilidade à computação em cloud.
2.3.3.1 Algoritmos para Encriptação dos Dados
São dois os algoritmos de encriptação mais comuns. Por cada algoritmo são dados exemplos de cifras e outros mecanismos criptográficos considerados seguros na atualidade:
• Encriptação Simétrica - O algoritmo de encriptação simétrica é um tipo de cripto-sistema em que a encriptação e a desencriptação são feitas usando a mesma chave. A encriptação de um texto em claro é realizada recorrendo a uma chave secreta com tamanho em número de bits suficientemente grande para serem evitados ataques de força bruta, onde são testadas re-cursivamente várias chaves até ser encontrada a chave correta. A chave secreta é distribuída por um canal seguro, diretamente de forma física entre as entidades comunicantes ou recor-rendo a uma terceira entidade de confiança com a responsabilidade de fazer a distribuição. Nas cifras simétricas distinguem-se algoritmos apropriados para comunicações síncronas que fazem a encriptação byte-a-byte ou bit-a-bit (ex. RC4), e algoritmos apropriados para comunicações assíncronas e envio de ficheiros ou segmentos de dados de tamanho conside-rável (ex. AES/CBC). As cifras simétricas assíncronas consideradas seguras pelo NIST e recomendadas para o uso na encriptação de dados, são as seguintes:
– Triple DES - A cifra consiste em três implementações do algoritmo DES de forma se-quencial, usando três chaves distintas, cada uma com o tamanho de 56 bits, perfazendo uma chave efetiva de 168 bits de tamanho [15].
– AES/CBC/256 - A cifra faz uso de uma chave de 256 bits e atua no modo de operação cipher block chaining(CBC) onde o segmento de dados em questão é repartido por
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]:
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ênexistên-cia 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].
S e gu ran ça (ap ro ximadamen te) 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ção inspirada 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 confidencialidade garantida.
2.3.3.2 Ferramentas para Encriptação do Disco
Existem ferramentas específicas de encriptação dos dados num disco de armazenamento. A encriptação do disco assegura que todos os ficheiros depositados num determinado diretório pro-tegido da file system presente no sistema, são guardados no disco num formato encriptado através da execução de algoritmos de encriptação simétrica. Os dados ficam disponíveis em formato de texto claro após um processo de autenticação por um utilizador creditado que normalmente passa pela disponibilização de uma password responsável por encriptar e desencriptar as chaves crip-tográficas simétricas. No contexto das ferramentas de encriptação do disco, existem dois tipo de soluções que se diferenciam pela granularidade da encriptação:
• Encriptação ao Nível da File System - Consiste na implementação de uma camada de en-criptação sobre uma file system existente (ex. file system ext4), que faz com que todos os ficheiros escritos num diretório com encriptação ativa, sejam encriptados antes de ser re-alizada a escrita propriamente dita, no disco. A encriptação é feita on-the-fly partindo da disponibilidade permanente de chaves criptográficas armazenadas, normalmente de forma encriptada, no próprio sistema, e que são geridas a partir de uma funcionalidade associada a um determinado sistema operativo (ex. keyctl do Linux Kernel). A interação do utili-zador com a ferramenta é feita apenas no momento em que é efetuado o mounting sobre um diretório pertencence à estrutura da file system existente, em que o mesmo deve inserir uma password secreta. O processo de mounting consiste na montagem de uma determinada partição de um disco de armazenamento, num diretório organizado pela estrutura da file systempresente 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 à caca-mada 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-sourcede 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.
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 procedicomprometi-mentos 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
