anÁlise de seguranÇa dos sistemas cloud...
TRANSCRIPT
UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia de Computação
BIANCA TRAUZZULA COMPARONI
ANÁLISE DE SEGURANÇA DOS SISTEMAS CLOUD COMPUTING GOOGLE DRIVE E DROPBOX
Itatiba 2014
BIANCA TRAUZZULA COMPARONI – R.A. 002200900058
ANÁLISE DE SEGURANÇA DOS SISTEMAS CLOUD COMPUTING GOOGLE DRIVE E DROPBOX
Monografia apresentada ao Curso de Engenharia de Computação da Universidade São Francisco, como requisito parcial para obtenção do título de Bacharel em Engenharia de Computação. Orientador: Prof. Dr. Marcelo Augusto Gonçalves Bardi.
Itatiba 2014
Aos meus amados pais, Claudia e Vitório,
exemplos de vida que procuro trilhar,
e que me apoiaram a todo momento.
AGRADECIMENTOS
Agradeço primordialmente a Deus, por tudo que Ele tem me proporcionado ao
longo de minha vida.
Ao Prof. Marcelo Augusto Gonçalves Bardi, pelos seus incentivos, paciência,
sugestões, e críticas, pelo rigor científico e conduta acadêmica, e principalmente
pelo exemplo inesquecível de professor, pesquisador e orientador, que foi ao longo
desta caminhada.
Agradeço à Universidade São Francisco (USF), por intermédio da
Coordenação do Curso de Engenharia de Computação, de todo o corpo docente do
curso, e dos seus funcionários, pelo ambiente sadio, e infraestrutura oferecida.
E estendo meus agradecimentos a todos os amigos do curso que
contribuíram para o meu crescimento pessoal e profissional e um agradecimento
especial ao meu colega Allan Romanato o qual sugeriu e desenvolveu a ferramenta
de contagem, presente neste trabalho.
RESUMO Análise de Sistemas de Computação em Nuvem apresenta o conceito,
arquitetura, modelos, serviços e a capacidade de segurança de processamento nos servidores no momento de envio de arquivos remotamente via Internet. Para a análise do Sistema de Computação em Nuvem, este trabalho utilizará dois serviços de armazenamento em nuvem: Google Drive® e Dropbox®, respectivamente, contemplando suas principais características, tecnologias, arquiteturas e funcionalidades de cada sistema, apresentando também as diferenças entre as nuvens e abordando exatamente no que as ferramentas diferem entre si. Além de contar com a ajuda de um software farejador para que possa analisar a rede de tráfego de dados, quanto a questão de quais são os protocolos que passam no momento do envio de arquivos para a nuvem e se à questão de segurança das informações, e elencar se existem garantias de que os dados são transferidos com a devida privacidade, verificando assim a eficiência destas tecnologias em nuvens. Desta forma são apresentados os resultados mais importantes obtidos, incluindo a descrição do roteiro dos testes executados, assim como a utilização de uma rotina escrita para auxiliar na apuração dos dados, finalizando com as conclusões que visam destacar os resultados marcantes obtidas durante o desenvolvimento deste trabalho, e a contribuição do mesmo para o uso dos serviços testados.
Palavras-chave: Cloud Storage. Google Drive®. Dropbox®. Protocolos. Segurança.
ABSTRACT
Computer Systems Analysis in Cloud introduces the concept , architecture, models , services and the processing security capability on servers at the time of sending files remotely via the Internet. For the analysis of Cloud Computing System , this paper will use two cloud storage services : Google Drive® and Dropbox® , respectively , considering its main features , technologies , architectures and features of each system , also showing the differences between the clouds and addressing precisely in the tools differ. Besides having the help of a sniffer software so you can analyze the data traffic network, as the question of what are the protocols that pass when sending files to the cloud and to the information security issue , and to list is no guarantee that the data is transferred with due privacy, thus verifying the efficiency of these clouds technologies. Thus we present the most important results , including the description of the script of the testing performed, as well as the use of a written routine to assist in the determination of data , ending with the conclusions aimed at highlighting the remarkable results obtained during the development of this work and its contribution to the efficiency of the tested services.
Key-words: Cloud Storage. Google Drive®. Dropbox®. Protocols. Security.
LISTAS DE FIGURAS
FIGURA 1 – Ambiente de Computação em Nuvem .................................................. 19
FIGURA 2 – Nuvem Pública ...................................................................................... 20
FIGURA 3 – Nuvem Privada ..................................................................................... 20
FIGURA 4 – Tipos de nuvem .................................................................................... 21
FIGURA 5 – Modelos de Serviço da Computação em Nuvem .................................. 22
FIGURA 6 – SaaS - Software as a Service ............................................................... 22
FIGURA 7 – PaaS - Plataform as a Service .............................................................. 23
FIGURA 8 – IaaS - Infrastructure as a Service .......................................................... 24
FIGURA 9 – Camadas dos Modelos de Serviço ....................................................... 24
FIGURA 10 – Alguns nós de borda identificados do Google Drive® .......................... 27
FIGURA 11 – Comunicação do cliente Dropbox®...................................................... 30
FIGURA 12 – Camadas do modelo de referência OSI/ISO ....................................... 32
FIGURA 13 – Estabelecimento de Conexão TCP ..................................................... 34
FIGURA 14 – Cabeçalho do Protocolo UDP ............................................................. 35
FIGURA 15 – Funcionamento do Protocolo HTTP .................................................... 36
FIGURA 16 – Funcionamento do DNS ...................................................................... 38
FIGURA 17 – Como as mensagens IGMP são enviadas .......................................... 40
FIGURA 18 – Funcionamento do Protocolo SSL ...................................................... 41
FIGURA 19 – Interface inicial do software Wireshark................................................ 45
FIGURA 20 – Interface do Google Drive® ................................................................. 47
FIGURA 21 – Selecionando para fazer upload de arquivos ...................................... 48
FIGURA 22 - Página do Google Drive® e interface do Wireshark ............................. 48
FIGURA 23 – Escolha do arquivo a ser enviado ao Google Drive®........................... 49
FIGURA 24 – Wireshark analisando a transferência para o Google Drive® .............. 50
FIGURA 25 – Término de envio do arquivo para o Google Drive® ............................ 50
FIGURA 26 – Interface do Dropbox® ......................................................................... 51
FIGURA 27 – Acessando o envio de arquivo para o Dropbox® ................................. 52
FIGURA 28 – Envio de arquivo para o Dropbox® ...................................................... 52
FIGURA 29 – Escolha do arquivo a ser enviado ao Dropbox® .................................. 53
FIGURA 30 – Fluxograma do ambiente de teste ..................................................... 564
FIGURA 31 – Fluxograma da execução do programa............................................. 565
FIGURA 32 - Resultado da análise de IPs de destino...............................................56
FIGURA 33 – Comando ipconfig no prompt de comando..................................... 57
FIGURA 34 – Comando tracert no prompt de comando ....................................... 57
LISTAS DE TABELAS
TABELA 1 – Comparação entre as ferramentas Google Drive® e Dropbox® ............ 31
TABELA 2 – Quantidade de protocolos no upload do arquivo txt .............................. 58
TABELA 3 – Quantidade de protocolos no upload do arquivo xlsx ........................... 60
TABELA 4 – Quantidade de protocolos no upload do arquivo pptx ........................... 61
TABELA 5 – Quantidade de protocolos no upload do arquivo pdf ............................ 63
TABELA 6 – Quantidade de protocolos no upload do arquivo jpg ............................. 64
TABELA 7 – Quantidade de protocolos no upload do arquivo mp3 .......................... 66
TABELA 8 – Quantidade de protocolos no upload do arquivo wmv .......................... 67
TABELA 9 – Quantidade de protocolos no upload do arquivo newpdf ...................... 68
LISTAS DE GRÁFICOS
GRÁFICO 1 – Protocolos no upload do arquivo txt para o Google Drive® ................ 59
GRÁFICO 2 – Protocolos no upload do arquivo txt para o Dropbox® ........................ 59
GRÁFICO 3 – Protocolos no upload do arquivo xlsx para o Google Drive® .............. 60
GRÁFICO 4 – Protocolos no upload do arquivo xlsx para o Dropbox® ..................... 60
GRÁFICO 5 – Protocolos no upload do arquivo pptx para o Google Drive® ............. 62
GRÁFICO 6 – Protocolos no upload do arquivo pptx para o Dropbox® ..................... 62
GRÁFICO 7 – Protocolos no upload do arquivo pdf para o Google Drive® ............... 63
GRÁFICO 8 – Protocolos no upload do arquivo pdf para o Dropbox®....................... 63
GRÁFICO 9 – Protocolos no upload do arquivo jpg para o Google Drive® ............... 65
GRÁFICO 10 – Protocolos no upload do arquivo jpg para o Dropbox® ..................... 65
GRÁFICO 11 – Protocolos no upload do arquivo mp3 para o Google Drive® ........... 66
GRÁFICO 12 – Protocolos no upload do arquivo mp3 para o Dropbox®................... 66
GRÁFICO 13 – Protocolos no upload do arquivo wmv para o Google Drive® ........... 67
GRÁFICO 14 – Protocolos no upload do arquivo wmv para o Dropbox® .................. 68
GRÁFICO 15 – Protocolos no upload do arquivo newpdf para o Google Drive® ....... 69
GRÁFICO 16 – Protocolos no upload do arquivo newpdf para o Dropbox® .............. 69
LISTAS DE ABREVIATURAS E SIGLAS
AES Advanced Encryption Standard
ARP Address Resolution Protocol
ATM Asynchronous Transfer Mode
CA Certificate Authority
CaaS Communication as a Service
CPU Central Processing Unit
CSV Comma-Separated Values
DBaaS Data Base as a Service
DB-LSP-DISC Dropbox LAN Sync Discovery Protocol
DevaaS Development as a Service
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
EaaS Everything as a Service
EC2 Elastic Cloud Computing
FDDI Fiber Distributed Data Interface
GB Gigabyte
GHz Gigahertz
HDLC High-Level Data Link Control
HP® Hewlett-Packard®
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IaaS Infrastructure as a Service
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IGMP Internet Group Management Protocol
IP Internet Protocol
ISO International Organization for Standardization)
KB Kilobyte
LAN Local Area Network
LLMNR Link-Local Multicast Name Resolution
MB Megabyte
Mbps Megabit per second
mDNS Multicast Domain Name System
MIT Massachusetts Institute of Technology
NBNS NetBIOS Naming Service
OSI Open Systems Interconnection
PaaS Platform as a Service
PPP Point-to-Point Protocol
RAM Random Access Memory
RTT Round Trip Time
S3 Simple Storage Service
SaaS Software as a Service
SPDY Speedy
SSDP Simple Service Discovery Protocol
SSL Secure Sockets Layer
TB Terabyte
TCP Transmission Control Protocol
TLS Transport Layer Security
UDP User Datagram Protocol
USB Universal Serial Bus
VM Virtual Machine
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................... 15
2 DESENVOLVIMENTO ......................................................................................... 17
2.1 Fundamentação Teórica ................................................................................... 17
2.1.2.1 Arquitetura ..................................................................................................... 18
2.1.1.1 Modelos de Implantação ............................................................................. 20
2.1.1.2 Modelos de Serviço ..................................................................................... 21
2.1.2 Google Drive® ................................................................................................ 26
2.1.2.1 Arquitetura................................................................................................... 26
2.1.3 Dropbox® ........................................................................................................ 28
2.1.3.1 Arquitetura................................................................................................... 29
2.1.4 Comparativo entre Google Drive® e Dropbox® ............................................... 31
2.1.5 Protocolos ...................................................................................................... 32
2.1.5.1 Transmission Control Protocol (TCP) .......................................................... 33
2.1.5.2 User Datagram Protocol (UDP) ................................................................... 34
2.1.5.3 HyperText Transfer Protocol (HTTP) .......................................................... 36
2.1.5.4 NetBIOS Naming Service (NBNS) .............................................................. 36
2.1.5.5 Dynamic Host Configuration Protocol (DHCP) ............................................ 37
2.1.5.6 Simple Service Discovery Protocol (SSDP) ................................................ 37
2.1.5.7 Domain Name System (DNS) ..................................................................... 38
2.1.5.8 Multicast Domain Name System (mDNS) ................................................... 39
2.1.5.9 Link-Local Multicast Name Resolution (LLMNR) ......................................... 39
2.1.5.10 Internet Control Message Protocol (ICMP) ................................................ 39
2.1.5.11 Internet Group Management Protocol (IGMP) ........................................... 40
2.1.5.12 Secure Sockets Layer (SSL) ..................................................................... 40
2.1.5.13 Transport Layer Security (TLS) ................................................................. 42
2.1.5.14 Address Resolution Protocol (ARP) .......................................................... 42
2.1.5.15 Speedy (SPDY) ......................................................................................... 43
2.1.5.16 Dropbox LAN Sync Discovery Protocol (DB-LSP-DISC) ........................... 43
2.1.6 Wireshark ....................................................................................................... 44
2.2 Metodologia ....................................................................................................... 46
2.2.1 Descrição do Ambiente de Testes ................................................................. 46
2.2.2 Rotina de Testes ............................................................................................ 47
2.3 Resultados ........................................................................................................ 58
2.3.1 Cenário 1........................................................................................................ 58
2.3.2 Cenário 2........................................................................................................ 59
2.3.3 Cenário 3........................................................................................................ 61
2.3.4 Cenário 4........................................................................................................ 62
2.3.5 Cenário 5........................................................................................................ 64
2.3.6 Cenário 6........................................................................................................ 65
2.3.7 Cenário 7........................................................................................................ 67
2.3.8 Cenário 8........................................................................................................ 68
3 CONCLUSÃO ...................................................................................................... 70
REFERÊNCIAS ......................................................................................................... 71
APÊNDICE – CÓDIGO FONTE DO PROGRAMA .................................................... 74
15
1 INTRODUÇÃO
A integração dos mais diversos dispositivos computacionais com a Internet
está crescendo, e cada vez mais a necessidade de estar conectado, transmitindo e
compartilhando informações, além de sempre precisar se ter à mão dados
importantes, e a Computação em Nuvem supre esta necessidade com os serviços
de armazenamento on-line de uma maneira muito rápida e eficaz a todo instante de
qualquer lugar, desde que obtenha acesso à Internet.
Para melhorar e facilitar a transmissão e compartilhamento de dados e
informações, modelos de serviços estão sendo desenvolvidos para serem utilizados
tanto por usuários domésticos quanto por usuários corporativos – que podem variar
desde pequeno até grande porte (REIS; SILVA, 2014).
Com o desenvolvimento destes modelos de conceitos e ideias da
informatização, surgiu a Cloud Computing (Computação em Nuvem), que é um dos
serviços mais utilizados atualmente, atendendo às necessidades do mundo moderno
por meio de recursos como capacidade de processamento, armazenamento,
conectividade, plataformas, aplicações e serviços disponibilizados na Internet
(TAURION, 2009). De acordo com o autor, Computação em Nuvem é o conjunto de
todos estes recursos sendo armazenados, compartilhados, transferidos para a
nuvem mantendo os dados em servidores virtuais espalhados pelo mundo de uma
maneira bastante eficiente de maximizar e flexibilizar os recursos computacionais.
Conforme informam Sousa, Moreira e Machado (2009), o ambiente de
Computação em Nuvem é composto por um grande número de máquinas –
centenas e até mesmo milhares – sendo elas nós físicos conectadas entre si por
meio de uma rede que disponibiliza o acesso à Internet. Cada máquina física pode
ter variações no hardware em termos de armazenamento em disco, CPU e memória,
porém tem as mesmas configurações de software, sendo que em cada uma existe
um número variável de Máquinas Virtuais (Virtual Machine – VM) em execução, de
acordo com a capacidade de hardware disponível na máquina física. Com esta
infraestrutura é possível compartilhar recursos e ter acesso às informações
disponibilizadas para seus usuários, de qualquer lugar e com facilidade, dando a
impressão de um espaço infinito.
16
Para Veras (2012), Cloud Computing teoricamente possui escalabilidade
infinita, mas esta escalabilidade esbarra na arquitetura da aplicação e na
infraestrutura disponível. O sistema da Computação em Nuvem é implementado
conforme a necessidade de acesso e disponibilidade de ambientes.
Pelas suas características, a Computação em Nuvem traz grandes benefícios,
como a rápida e fácil transferência de dados, que pode ser feita de qualquer lugar
que tenha conexão com a Internet, e também por contribuir com a sustentabilidade,
já que proporciona redução na aquisição de equipamentos de hardware, em energia
e de espaço, sendo economicamente viável (SOUSA; MOREIRA; MACHADO,
2009).
Entre a variedade de serviços de armazenamento de arquivos na nuvem do
mercado, se destacam o Google Drive®, e o Dropbox®, contudo é de se questionar
qual o nível de segurança oferecido por estes serviços, já que é comum ver
vazamentos de informações como, por exemplo, de fotos íntimas de celebridades.
Desta maneira, o objetivo principal deste trabalho é analisar a segurança dos
serviços Google Drive® e Dropbox®, verificando o tráfego de dados a partir da
transferência de arquivos de diversos formatos. Para tanto, o fluxo será analisado
com um sniffer, que monitora vários tipos de protocolos de rede, utilizados na
transferência de arquivos de áudio, texto, imagem e vídeo, atentando à
interceptação dos dados transferidos.
Com a análise dos dados deste trabalho, será possível comparar os serviços
Google Drive® e Dropbox® quanto à questão de segurança das informações, e
elencar se existem garantias de que os dados são transferidos com a devida
privacidade, verificando assim a eficiência destas tecnologias em nuvens.
17
2 DESENVOLVIMENTO
Este capítulo comporta as seções de Fundamentação Teórica (onde são
explicitados os pressupostos teóricos que amparam esta monografia), Metodologia
(onde são descritas as técnicas e os processos empregados na análise
experimental) e Resultados (onde são apresentados e discutidos os resultados
alcançados com esta pesquisa).
2.1 Fundamentação Teórica
Esta seção traz a revisão da literatura embasando a metodologia empregada
neste trabalho. A revisão é iniciada apresentando a virtualização, e em seguida a
Cloud Computing, tratando dos conceitos desta arquitetura e seus modelos de
implantação e serviço. Seguindo, são abordados o Google Drive® e o Dropbox®,
contemplando suas principais características e arquitetura, e também um
comparativo entre os dois produtos. Prosseguindo, vem a explanação dos
Protocolos, que são abordados na análise deste trabalho. Por fim, é mostrado o
programa Wireshark, assim encerrando as revisões bibliográficas.
2.1.1 Virtualização
A virtualização é um processo que executa vários sistemas operacionais que
trabalham em um único servidor, através do compartilhamento de hardware, tratando
da junção de ambientes operacionais físicos e virtualizados, onde, em um único
servidor, pode-se criar e administrar vários outros servidores virtuais com sistemas
operacionais distintos.
Consequentemente, por causa destas características, a virtualização é uma
tecnologia que permite aos seus usuários ter um melhor reaproveitamento dos
recursos, além de portabilidade e otimização do espaço físico, uma vez que se pode
18
criar um espaço na rede em que é possível aproveitar todos os recursos de uma
máquina sem sobrecarregar aquela que o usuário está utilizando. Desta forma essa
técnica acaba se tornando essencial para todo tipo de projeto uma vez que
servidores, laptops, smartphones, tablets ou até mesmo dispositivos de
armazenamentos sejam armazenados e acessados como um único conjunto de
recursos de qualquer lugar ou ainda qualquer plataforma (VMWARE, 2014).
2.1.2 Cloud Computing
Segundo Taurion (2009), Computação em Nuvem é o conjunto de recursos
como capacidade de processamento, armazenamento, conectividade, plataformas,
aplicações e serviços disponibilizados na Internet, sendo armazenados,
compartilhados e transferidos de uma maneira bastante eficiente de maximizar e
flexibilizar os recursos computacionais, entendida assim como uma metáfora para a
Internet ou infraestrutura de comunicação entre os componentes arquiteturais,
baseada em uma abstração que oculta a complexidade da infraestrutura.
Souza, Moreira e Machado (2009) complementam, afirmando que a
Computação em Nuvem é economicamente viável e contribui com a
sustentabilidade, pois proporciona redução na aquisição de equipamentos de
hardware, em energia e em espaço, já que sua infraestrutura normalmente está
alocada em data centers, utilizando hardware compartilhado para computação e
armazenamento.
2.1.2.1 Arquitetura
A arquitetura da nuvem é dividida em camadas, as quais são uma divisão
lógica que é composta por hardwares e softwares.
O sistema de Computação em Nuvem é dividido em duas seções: o front-end,
onde está o computador do usuário e a aplicação necessária para acessar o sistema
de Computação em Nuvem, e o back-end que é a parte da nuvem (FIGURA 1).
19
A camada mais baixa é a de infraestrutura, que corresponde a clusters,
desktops e demais equipamentos. Essa mistura de componentes físicos mostra a
flexibilidade e a facilidade para agregar novos recursos quando se torna necessário.
Como explica Veras (2011), a organização não precisa projetar a
infraestrutura pelo pico, a Computação em Nuvem permite alocar recursos sob
demanda, tornando a escalabilidade uma realidade.
Fonte: <http://www.promise.com/single_page_session/page.aspx?region=de-DE&m=912&rsn=178>
FIGURA 1 – Ambiente de Computação em Nuvem
A camada de middleware é responsável por gerenciar a camada de
infraestrutura e tem objetivo fornecer as informações lógicas da nuvem. Na camada
acima do middleware, é dado o suporte para a criação de aplicações, com
ferramentas e ambientes de desenvolvimento, e essa camada é utilizada apenas
pelos desenvolvedores da nuvem. Na última camada estão as aplicações que
interagem com o usuário final da nuvem (SOUSA; MOREIRA; MACHADO, 2009).
Nem todos os sistemas de Computação em Nuvem tem a mesma interface
para o usuário. Serviços baseados na Web, como programas de e-mail, aproveitam
navegadores de Internet já existentes, como o Internet Explorer e o Mozilla Firefox,
20
já outros sistemas têm aplicações próprias que fornecem acesso a rede aos clientes,
como o Dropbox® e o Google Drive®.
2.1.1.1 Modelos de Implantação
A implantação da Computação em Nuvem é dividida conforme a necessidade
de acesso e disponibilidade de ambientes (COUTINHO et al., 2013).
A nuvem pública pode ser acessada conhecendo-se onde seu serviço está
localizado. Neste caso, seu acesso pode ser feito por um público em geral, não são
requisitadas autenticações e nem aplicadas restrições ao acesso (FIGURA 2).
FIGURA 2 – Nuvem Pública
A nuvem privada é o contrário, sendo utilizada por um grupo restrito de
usuários, como funcionários de uma empresa, e pode ser tanto local como remota.
Nesse modelo, são feitas restrições de acesso a determinados serviços utilizando
aplicações de administração de rede, autenticação e autorização para seus usuários
(FIGURA 3).
FIGURA 3 – Nuvem Privada
21
No modelo de nuvem comunidade, é feito o compartilhamento da nuvem por
diversos grupos de usuários distintos, visando uma comunidade com objetivos em
comum. A administração desse tipo de nuvem se dá por meio de alguns dos grupos
que compartilham a nuvem ou de uma empresa terceirizada. Ela também pode ser
implantada localmente ou remotamente (REIS; SILVA, 2014).
Para Coutinho et al. (2009), nuvem híbrida é formada pela junção de dois ou
mais tipos de nuvens, acima citados, como sendo uma só. Utilizam um padrão de
conexão para realizar a portabilidade de aplicações e dados (FIGURA 4).
Fonte: <http://blog.opus-
software.com.br/a-confusao-sobre-nuvem-privada/>
FIGURA 4 – Tipos de nuvem
2.1.1.2 Modelos de Serviço
No que diz respeito a modelos de serviço, o ambiente da Cloud Computing é
composto de três modelos distintos (Software como Serviço, Plataforma como
Serviço e Infraestrutura como Serviço), que definem um padrão arquitetural para
soluções de Computação em Nuvem (FIGURA 5) (COUTINHO et al., 2013).
22
Fonte: Coutinho et al. (2013)
FIGURA 5 – Modelos de Serviço da Computação em Nuvem
SaaS - Software as a Service (Software como Serviço): É oferecido um
software em forma de serviço. Esse software é executado em um servidor Web e
não é necessária a sua instalação no computador do usuário. Sendo assim não é
necessário que o usuário invista em um hardware com grande poder de
processamento, apenas é necessária uma boa conexão com o serviço. Muito usado
atualmente, um exemplo é o Google Drive®, que funciona totalmente on-line e seu
conjunto de aplicativos é composto por editores de texto, de planilhas, de
apresentações, de formulários e de desenhos, todos compatíveis com o OpenOffice,
KOffice e Microsoft® Office (FIGURA 6) (SOUSA; MOREIRA; MACHADO, 2009).
Fonte: <http://www.teleco.com.br/tutoriais/tutorialservnuvopers1/pagina_3.asp>
FIGURA 6 – SaaS - Software as a Service
23
PaaS - Plataform as a Service (Plataforma como Serviço): É uma plataforma
de desenvolvimento de aplicações como um serviço da Web. Nesta plataforma, são
feitas ações como desenvolver, compilar e testar uma aplicação diretamente na
nuvem. A grande vantagem desse tipo de serviço é não ter perda de hardware
alocado para determinada aplicação, diminuindo assim os custos e tornando o
manuseio de dados mais simples, pois não é necessário um contato direto com o
ambiente físico. Um exemplo do mercado é o Google App Engine®, que permite que
sejam criados e hospedados aplicativos da Web com os mesmos sistemas que
acionam os aplicativos do Google® (FIGURA 7) (SOUSA; MOREIRA; MACHADO,
2009).
Fonte: <http://www.teleco.com.br/tutoriais/tutorialservnuvopers1/pagina_3.asp>
FIGURA 7 – PaaS - Plataform as a Service
IaaS - Infrastructure as a Service (Infraestrutura como Serviço): É geralmente
usado com alguma configuração que é ajustada conforme a necessidade do serviço,
e utiliza apenas uma quantidade necessária de um servidor. Neste serviço, um
cliente em vez de comprar o hardware para rodar uma determinada aplicação, ele
contrata um serviço dentro de um data center de acordo com os requisitos de
infraestrutura necessários e tem acesso completo à plataforma e ao software.
Geralmente, esse tipo de serviço é cobrado de acordo com a utilização ou pela
reserva de recursos contratados. O Amazon Elastic Cloud Computing® (EC2) e o
Elastic Utility Computing Architecture Linking Your Programs To Useful Systems
(Eucalyptus) são exemplos de IaaS (FIGURA 8) (SOUSA; MOREIRA; MACHADO,
2009).
24
Fonte: <http://www.teleco.com.br/tutoriais/tutorialservnuvopers1/pagina_3.asp>
FIGURA 8 – IaaS - Infrastructure as a Service
Desta forma pode-se dizer que esses distintos serviços correspondem a
diferentes requisitos para o mercado, atingindo as necessidades de negócios
variados para determinadas áreas (FIGURA 9).
Fonte: <http://vitormeriat.com.br/2011/07/08/modelos-de-servio-na-nuvem-iaas-paas-e-saas/>
FIGURA 9 – Camadas dos Modelos de Serviço
Além desses serviços acima explanados, também existem outros que ainda
são pouco utilizados (VERAS, 2012):
EaaS - Everything as a Service (Tudo como Serviço): Fornece uma
abordagem total e prática de ambientes de aplicativos, permitindo agilizar o processo
de distribuição, do desenvolvimento dos diversos estágios de teste até a produção,
tendo assim flexibilidade na implantação e configuração, além de desmontar
ambientes complexos reduzindo drasticamente o custo da distribuição de softwares
e consecutivamente melhorando o tempo de fornecimento.
25
CaaS - Communication as a Service (Comunicação como Serviço): Uso de
uma solução de comunicação única alojada em um data center, que tem como
funcionalidade efetuar suporte para a distribuição automática de chamadas com
grande flexibilidade de configuração, monitoramento on-line, controle e integração
das posições de atendimento, acompanhando os níveis de serviço do data center,
ou seja, tudo relacionado a serviços de comunicação.
DevaaS - Development as a Service (Desenvolvimento como Serviço): As
ferramentas de desenvolvimento também podem ser utilizadas em nuvem como
ferramentas compartilhadas, ou ferramentas de desenvolvimento Web-based, e
serviços baseados em mashup.
DBaaS - Data Base as a Service (Banco de Dados como Serviço): É a
utilização do banco de dados como serviço, ou seja, é quando se contrata e utiliza
apenas os recursos do banco de dados, como memória e espaço, com isso
eliminando a necessidade por adquirir, instalar, gerenciar e suportar hardware e
software, agilizando ainda o desenvolvimento de projetos e a implantação de
ambientes de testes.
26
2.1.2 Google Drive®
O Google Drive® vem se tornando cada vez mais popular por ser gratuito,
assim como outros serviços prestados pelo Google® como, por exemplo, o Google
Agenda®. Além de gratuito é muito útil, pois o Google Drive® tem um pacote que se
assemelha ao Microsoft® Office, além de poder importar e exportar arquivos,
aplicativos, mídias e fotos, independentemente de suas extensões ou ainda
sistemas operacionais diferentes (GOOGLE, 2014).
Outra grande vantagem é a sua portabilidade, pois se trata de um serviço em
nuvem, ou seja, não há necessidade de um espaço físico para armazenamento dos
dados, basta apenas ter acesso à Internet para acessá-los, permitindo que várias
pessoas possam trabalhar ao mesmo tempo em um arquivo sem a necessidade de
enviar ou manter um controle de mudanças.
Desta forma, o Google Drive® é capaz de armazenar uma pequena
quantidade de dados que podem ser guardados em pastas, sendo o limite de 15 GB
e mais 2 MB por cada imagem que for anexada, ou se este espaço for insuficiente,
pode-se adquirir um espaço maior, bastando pagar por este serviço.
Assim pode-se dizer que as principais características do Google Drive® são a
popularidade, usabilidade, portabilidade, convergência e escalabilidade.
2.1.2.1 Arquitetura
Segundo Drago et al. (2013), muito pouco é conhecido da arquitetura de
sistema, capacidade de serviço e performance dos serviços de armazenamento na
nuvem do mercado, e o Google Drive® não é exceção. Para compreender como o
Google Drive® implementa seus serviços, os autores realizaram estudos
investigando o funcionamento da ferramenta, uma vez que estas informações não
são compartilhadas por se tratar de um produto comercial fornecendo soluções
proprietárias.
Como resultado dos estudos de engenharia reversa aplicada, os autores
concluem que, inicialmente, o cliente do Google Drive® troca tráfego usando o
protocolo HTTPS (HyperText Transfer Protocol Secure). Feito o login, a aplicação
autentica o usuário e checa se algum conteúdo tem que ser atualizado, e mesmo em
27
fase ociosa, continua mantendo troca de dados com a nuvem, em intervalos de 40
segundos.
As conexões TCP (Transmission Control Protocol) são terminadas no nó de
borda do Google® mais próximo (FIGURA 10), de onde o tráfego é roteado usando a
rede privada do Google®, para o data center de armazenamento/controle. É
desconhecido como o Google® gerencia o tráfego dentro da sua rede, desta maneira
impedindo a localização exata do data center utilizado. Essa arquitetura permite
reduzir o RTT (Round Trip Time) cliente-servidor e para descarregar o tráfego de
armazenamento da Internet pública. Assim o Google Drive® desfruta dos benefícios
da utilização da infraestrutura capilar e backbone privado do Google®, reduzindo a
latência de rede e acelerando o sistema (DRAGO et al., 2013).
Fonte: Drago et al. (2013)
FIGURA 10 – Alguns nós de borda identificados do Google Drive®
28
2.1.3 Dropbox®
O Dropbox® foi desenvolvido em 2007 por Drew Houston e Arash Ferdowsi,
dois alunos do MIT (Massachusetts Institute of Technology), cansados de enviar e-
mails para si mesmos com arquivos para poder trabalhar em mais de um
computador. Atualmente, mais de 300 milhões de pessoas em mais de 200 países,
de todos os continentes, usam o Dropbox®, que está disponível em 19 idiomas, com
seus usuários chegando a salvar cerca de 1 bilhão de arquivos a cada 24 horas
(DROPBOX, 2014b).
Assim como o Google Drive®, o Dropbox® é um serviço gratuito que permite
importar e exportar arquivos de diferentes extensões, de qualquer sistema
operacional, por meio de conexão com a Internet.
A utilização do Dropbox® é intuitiva para o usuário. Após instalar o software no
computador, uma pasta especial é criada, e ao adicionar qualquer arquivo a esta
pasta, automaticamente estará disponibilizado em todos os outros lugares que o
usuário tenha instalado o Dropbox®, como em seus computadores, smartphones e
até mesmo no site do Dropbox®. O armazenamento é de 2 GB de dados iniciais,
mas pode-se conseguir espaço adicional gratuito ao cumprir com algumas missões e
diversas atividades do site, como indicando amigos, fazendo um tour ou dando
opiniões. Outra opção de conseguir aumentar o espaço é pagando pelo serviço
(DROPBOX, 2014a).
O Dropbox® também tem o recurso de convidar pessoas para compartilhar
arquivos de qualquer pasta de usuário, sendo muito eficiente em casos como o de
fazer projetos em equipe, pois os arquivos ficam disponíveis para todos os
integrantes. Essa função é muito utilizada no Dropbox® para empresas, que é um
serviço pago, com o armazenamento inicial de 1 TB, e tendo o diferencial de trazer
sugestões inovadoras para seus clientes, que além de usar de qualquer lugar, têm
mais visibilidade e controle para gerenciar de forma otimizada as informações da
empresa, com isso visando o sincronismo entre eles, e otimizando a produtividade
dos colaboradores.
O Dropbox® provê interfaces de programação para que desenvolvedores
criem aplicações para diversos ambientes, como sistemas móveis baseados em
Android. A plataforma do Dropbox® conta com mais de 300 mil aplicativos
produzidos por desenvolvedores, com integrações que incluem Facebook®, Yahoo®,
29
Autodesk®, Adobe®, Vimeo®, HP®, Microsoft®, Samsung®, entre outros (DROPBOX,
2014b).
Graças à funcionalidade do Dropbox®, os arquivos estarão seguros, pois se
foram armazenados na nuvem e todos os aparelhos que estão sendo utilizados
também estiverem sincronizados e o usuário tenha o hábito de fazer backups ele
não terá problema, pois caso ocorra de perder algum dispositivo móvel, ou excluir
um arquivo por engano, pode-se então, encontrar o arquivo armazenado na nuvem,
e fazer download ou ainda caso tenha excluído da nuvem, existe a possibilidade der
restaurar e/ou corrigir sem maiores dificuldades, porque o Dropbox® permite que
desfaça erros e até mesmo restaure arquivos jogados na lixeira, mantendo até um
mês das suas atividades excluídas (DROPBOX, 2014a).
A segurança utilizada pelo Dropbox® parte da tecnologia de segurança SSL
(Secure Sockets Layer) e criptografia AES (Advanced Encryption Standard) de 256
bits. Esse padrão de criptografia é o mesmo usado por bancos para proteger os
dados dos clientes, garantindo assim a segurança e integridade das informações
enviadas e armazenadas no sistema (DROPBOX, 2014a).
2.1.3.1 Arquitetura
O serviço fornecido pelo Dropbox®, conforme explicam Drago, Vieira e Silva
(2013), baseia-se no armazenamento dos arquivos de seus usuários em servidores
com alta disponibilidade. Há dois componentes principais na arquitetura do
Dropbox®. O primeiro refere-se aos servidores de controle da aplicação, e são
mantidos diretamente pela empresa. O segundo componente refere-se aos
servidores de armazenamento de dados, e são hospedados pela Amazon® por meio
do serviço de armazenamento Amazon S3® (Simple Storage Service). Em ambos os
casos, subdomínios de dropbox.com permitem diferenciar as partes do serviço que
executam funcionalidades específicas.
Segundo os autores, durante a transferência de dados entre clientes e
servidores Dropbox®, registra-se uma redução no tamanho dos arquivos, e por
consequência, redução no tempo total da transferência, uma vez que todos os dados
são compactados ainda na estação cliente. Além disso, o cliente Dropbox® compara
versões de um mesmo arquivo, fazendo a transferência unicamente de suas
30
diferenças. Ainda, arquivos duplicados de um mesmo usuário são transferidos
apenas uma vez. Por fim, todos os dados trocados são criptografados, com o
protocolo HTTPS sendo utilizado para acessar a maior parte dos servidores
(DRAGO; VIEIRA; SILVA, 2013).
Para compreender a estrutura do Dropbox®, Drago et al. (2012) realizaram
estudos dissecando seu funcionamento, uma vez que estas informações não são
compartilhadas por se tratar de um produto comercial que fornece soluções
proprietárias.
Os autores explicam que a comunicação do cliente Dropbox® se dá conforme
mostra a FIGURA 11, que ilustra as mensagens observadas ao enviar um lote de
dados de até 4 MB. Depois de se registrar no centro de controle do Dropbox® via um
servidor clientX.dropbox.com, o comando list recupera as atualizações de
metadados. Assim que novos arquivos são adicionados localmente, um comando
commit_batch (no client-lb.dropbox.com) envia informações de metadados. Isso
pode acionar operações de armazenamento, realizadas diretamente com servidores
da Amazon® (em dl-clientX.dropbox.com). E finalmente, como os dados são
submetidos com sucesso, o cliente troca mensagens com os servidores centrais do
Dropbox® (novamente em client-lb.dropbox.com) para concluir as transações
(DRAGO et al., 2012).
Fonte: Drago et al. (2012)
FIGURA 11 – Comunicação do cliente Dropbox®
31
2.1.4 Comparativo entre Google Drive® e Dropbox®
O diferencial entre os dois serviços é que o Google Drive® possui integração
com aplicações para criação e edição de arquivos (texto, planilha, apresentação e
formulário). Já o Dropbox® possui limitador de banda, permitindo que a taxa de
download e upload entre cliente e servidor seja configurada pelo usuário.
No Dropbox® sempre que é adicionado um arquivo na nuvem, será
visualizado no cliente o status de sincronização. Se estiver sendo sincronizado é
exibido um símbolo azul de sincronização junto ao ícone da pasta, e quando estiver
sincronizado um símbolo verde. No Google Drive® porém, quando são incluidos
vários arquivos na aplicação, não há como saber qual arquivo está sincronizado com
a nuvem, apenas sabe-se que o programa está sincronizando, pois ao passar o
mouse sobre o ícone na barra de tarefas, é informado que está sendo feita a
atualização.
Na TABELA 1 estão sendo comparadas as principais características de cada
produto. Quanto à capacidade grátis de armazenamento que as ferramentas
disponibilizam ao usuário, o Dropbox® possui o menor valor inicial, porém com a
realização de tarefas, ele pode chegar à 18 GB. Em contrapartida no Google Drive®
a capacidade grátis é compartilhada com a sua plataforma de e-mail Gmail.
TABELA 1 – Comparação entre as ferramentas Google Drive® e Dropbox
®
Google Drive® Dropbox®
Armazenamento grátis 15 GB de 2 a 18 GB Armazenamento 1 TB/mês (US$) 9.99 9.99 Tamanho máximo de arquivo 10 GB 10 GB Aplicativo desktop Windows Sim Sim Aplicativo desktop Mac OS Sim Sim Aplicativo desktop Linux Não Sim Aplicativo móvel Ios Sim Sim Aplicativo móvel Android Sim Sim Aplicativo móvel WindowsPhone Não Não Acesso Web Sim Sim Compartilhamento público Sim Sim Compartilhamento privado Sim Sim Integração com outros aplicativos Sim Sim Streaming de mídia Sim Sim Limitador de banda Não Sim Interface em português Sim Sim
32
2.1.5 Protocolos
Segundo Kurose e Ross (2010), um protocolo define o formato e a ordem das
mensagens trocadas entre duas ou mais entidades comunicantes, bem como as
ações realizadas na transmissão e/ou no recebimento de uma mensagem em outro
evento.
Assim, um protocolo é um acordo realizado entre as partes que se
comunicam entre camadas do mesmo nível entre nós distintos. O modelo concebido
pela OSI/ISO (International Organization for Standardization / Open Systems
Interconnection) permite o intercâmbio de informações entre computadores de
fabricantes distintos, dividindo suas funcionalidades e capacidades em sete
camadas (Física, Enlace, Rede, Transporte, Sessão, Apresentação e Aplicação),
sendo que cada camada é responsável por uma determinada função específica
(FIGURA 12). A comunicação entre camadas é feita através da requisição de
serviços. Cada camada é responsável por um determinado conjunto de serviços,
oferecendo serviços para a camada superior e utilizando os serviços da camada
inferior. Já a comunicação entre camadas do mesmo nível entre nós distintos é feita
através de protocolos. Para que dois nós possam se comunicar ele devem
especificar o mesmo protocolo (TANENBAUM, 2003).
Fonte: Tanenbaum (2003)
FIGURA 12 – Camadas do modelo de referência OSI/ISO
33
Os protocolos podem ser classificados como orientados a conexão
(connection-oriented services) ou não-orientados a conexão (connectionless).
Os protocolos orientados a conexão são apresentados por meio do emissor e
do receptor, que primeiramente estabelecem uma conexão antes de transmitir
qualquer informação. Após ser concluída esta apresentação, é retornada uma
mensagem que foi estabelecida a conexão entre emissor e receptor, assim
oferecendo certo nível de garantia de entrega, um melhor controle de fluxo e
evitando congestionamento na transmissão de dados. No final da transferência é
realizado o término da conexão entre emissor e receptor. Um exemplo deste tipo de
protocolo é o TCP (KUROSE; ROSS, 2010).
Por outro lado, os protocolos não-orientados a conexão podem enviar dados
sem a necessidade de primeiramente estabelecer uma conexão entre emissor e
receptor. Assim, possibilitam que a entrega seja mais rápida, porém não oferecem
garantia de entrega, além de não se obter controle de fluxo e tampouco de
congestionamento. Exemplo deste tipo de protocolo é o UDP (KUROSE; ROSS,
2010).
Apresenta-se, a seguir, uma breve descrição dos principais protocolos de
rede empregados em ambiente Cloud Computing.
2.1.5.1 Transmission Control Protocol (TCP)
Conforme explicam Kurose e Ross (2010), o TCP (Transmission Control
Protocol) se encontra na camada de transporte do modelo OSI/ISO, é um dos
protocolos mais importantes, pois sem ele não seria possível que a transferência de
dados ponto-a-ponto, ou seja, entre um emissor e um único receptor, fosse
confiável. O funcionamento do TCP ocorre quando o cliente comunica a camada de
transporte que quer iniciar uma conexão com o servidor. Desta forma, é emitido para
o cliente um segmento especial TCP e o servidor responde com o mesmo segmento.
Finalmente o cliente responde novamente com outro segmento. Estes três
segmentos podem ser denominados de apresentação de três vias (three-way
handshake) (FIGURA 13).
34
Fonte: < http://pt.slideshare.net/MarquesSilva1/redes-de-computadores-volume-2.jpg>
FIGURA 13 – Estabelecimento de Conexão TCP
Considerando neste caso o primeiro processo de envio cliente/servidor,
mostra que o processo cliente passa por muitos dados por intermédio da porta de
processos (soquetes) chegando até o TCP que se encontra processando neste
próprio cliente, direcionando as informações para o buffer de envio que foi reservado
no momento o qual foi utilizado três segmentos, porém nunca se sabe quando se
devem enviar estas informações que estão armazenadas nos buffers, apenas se
sabe que o TCP deve enviá-las de acordo com a necessidade dele.
Portanto, o funcionamento do TCP acaba se adaptando as partes de
informações do cliente com um cabeçalho TCP, os quais formam os segmentos que
passa pela camada de rede onde são encapsulados um a um dentro dos
datagramas IP (Internet Protocol) que são transmitidos para a rede, desta forma
quando o TCP capta do outro lado, as informações do segmento são postas no
buffer e a aplicação acaba lendo as informações ali armazenadas, assim sendo cada
lado terá um buffer emissor e no outro receptor, fazendo assim o envio dos pacotes
(KUROSE; ROSS, 2010).
2.1.5.2 User Datagram Protocol (UDP)
O UDP (User Datagram Protocol) é um protocolo do tipo não-orientado a
conexão, e encontra-se na camada de transporte do modelo OSI/ISO. Sua função é
fazer a transferência de dados entre remetente e destinatário, porém este serviço é
35
não-confiável, por dois motivos: primeiro, porque o processo pode chegar fora de
ordem, e segundo, porque não se tem a garantia de que a mensagem chegue ao
receptor.
Segundo Tanenbaum (2003), o UDP transmite segmentos que consistem em
um cabeçalho de 8 bytes, seguido pela carga útil (FIGURA 14). As duas portas
servem para identificar os pontos extremos nas máquinas de origem e destino.
Quando um pacote UDP chega, sua carga útil é entregue ao processo associado à
porta de destino.
Fonte: Tanenbaum (2003)
FIGURA 14 – Cabeçalho do Protocolo UDP
De fato, o principal valor de se ter o UDP em relação ao uso do IP bruto é a
adição das portas origem e destino. Sem os campos de portas, a camada de
transporte não saberia o que fazer com o pacote. Com eles, a camada entrega
segmentos corretamente.
Ainda segundo Tanenbaum (2003), a porta de origem é usada principalmente
quando uma resposta dever ser devolvida à origem. Copiando o campo Source Port
do segmento de entrada no campo Destination Port do segmento de saída, o
processo que transmite a resposta pode especificar qual processo na máquina
transmissora deve recebê-lo.
Desta forma o campo UDP Length inclui o cabeçalho de 8 bytes e os dados.
O campo UDP Checksum é opcional e armazenado como 0 se não for calculado (um
valor 0 verdadeiro calculado é armazenado com todos os bits iguais a 1).
Contudo este protocolo é muito utilizado em aplicações de tempo real, como
multimídia, porque se pode haver uma quantidade pequena de perda de dados, mas
desde que atinjam uma taxa mínima de dados para que a mensagem seja enviada,
com isso o UDP consegue reagir bem ao controle de congestionamento,
contribuindo para aplicações nessas áreas (TANENBAUM, 2003).
36
2.1.5.3 HyperText Transfer Protocol (HTTP)
Conforme informam Kurose e Ross (2010), o HTTP (HyperText Transfer
Protocol) está situado na camada de aplicação do modelo OSI/ ISO, e é um
protocolo de comunicação entre sistemas de informação que permite a transferência
de dados entre redes de computadores.
O HTTP utiliza o protocolo TCP como seu protocolo de transporte utilizando-
se do modelo cliente-servidor, isso funciona com uma conexão estabelecida por
meio do TCP com o servidor onde os processos dos agentes de usuário (browser) e
o servidor acessam o TCP, feito isso o cliente envia uma solicitação para o browser
e o servidor procura o documento e quando localizado envia-o de volta a solicitação,
desfazendo a conexão (FIGURA 15).
Fonte: Kurose e Ross (2010)
FIGURA 15 – Funcionamento do Protocolo HTTP
2.1.5.4 NetBIOS Naming Service (NBNS)
O NBNS (NetBIOS Naming Service) é um protocolo de entrada e saída básica
de sistemas, está localizado na camada de sessão do modelo OSI/ISO, e sua
função é que máquinas de um mesmo ambiente se comuniquem.
De acordo com Santana (2011), o NetBIOS pode fazer uma conexão entre
aplicativos das camadas de sessão e transporte do TCP/IP e acaba fornecendo
operações de mensagens e de alocação de recursos. O NetBIOS também define
nomes lógicos sobre a rede, criando sessão entre dois nomes lógicos na rede, além
37
da assistência para a obtenção de uma comunicação confiável de informações entre
computadores com uma sessão criada.
Assim pode-se dizer que seu funcionamento ocorre quando um computador
pede ao departamento de serviço de registro que solicite o pedido de registro de
mensagens, a qual irá enviar um pedido unicast do nome que deve ser usado para o
servidor de nomes para que possa realizar o registro de recurso, porém caso ocorra
do nome ser igual a um já existente o computador enviará uma mensagem de erro.
Resumidamente este protocolo se comunica com os dispositivos de rede e pede o
acesso, logo após a solicitação é transmitida para todas as máquinas que estão
conectadas na rede, caso o acesso seja negado será necessário enviar uma nova
solicitação e começar novamente o processo (SANTANA, 2011).
2.1.5.5 Dynamic Host Configuration Protocol (DHCP)
O DHCP (Dynamic Host Configuration Protocol) está situado na camada de
aplicação do modelo OSI/ISO, mas que utiliza do protocolo UDP que está na
camada de transporte do modelo OSI/ISO. O DHCP permite que computadores
sejam configurados por meio de um servidor DHCP, seu funcionamento se baseia
em enviar uma mensagem para saber se o cliente está conectado, então se isso for
verdade a mensagem é validada e é retornada uma mensagem com o endereço IP,
em outro caso pode-se ter um roteador, que funcionará da mesma forma, porém
com a função de distribuir os endereços IP para todos os dispositivos conectados a
rede (KUROSE; ROSS, 2010).
2.1.5.6 Simple Service Discovery Protocol (SSDP)
Segundo Lemos (2011), o SSDP (Simple Service Discovery Protocol) tem
como funcionalidade não só descobrir, mas também anunciar os serviços de rede,
funcionando de uma maneira que não requer nenhum tipo de configuração,
tampouco de um servidor.
O autor afirma que este protocolo, além de ter um formato texto, é baseado
em protocolos HTTP e o de transporte UDP, que estão diretamente ligados à
38
aceitação ou exclusão de serviços para grupos multicast, isso influencia quando o
usuário quer descobrir quais são os serviços a disponíveis e acaba utilizando deste
protocolo HTTP, desta forma as respostas são endereçadas em unicast e a porta de
recebimento será entregue por serviços multicast (LEMOS, 2011).
2.1.5.7 Domain Name System (DNS)
De acordo com Kurose e Ross (2010), o DNS (Domain Name System) está
localizado na camada de aplicação do modelo OSI/ISO, sendo este responsável por
traduzir os nomes de domínios para endereços IP e vice-versa.
Por meio do endereço IP, que é uma identificação única de um dispositivo em
uma rede local ou pública, as máquinas se comunicarem na Internet. Para encontrar
um determinado nome (site) na Internet, primeiramente consulta-se o servidor
central, que retornará o endereço IP dos servidores, então será indicado os
servidores de nomes de domínio de alto nível que serão responsáveis por indicar os
órgãos pertencentes (org, gov, edu, entre outros) ou países, e em seguida os
servidores de autoridade que será o encarregado pelo domínio final (FIGURA 16)
(KUROSE; ROSS, 2010).
Fonte: <http://registro.br/tecnologia/dnssec.html?secao=dnssec>
FIGURA 16 – Funcionamento do DNS
39
2.1.5.8 Multicast Domain Name System (mDNS)
O mDNS (Multicast Domain Name System) é um protocolo com a mesma
função do DNS, portanto pertence a mesma camada no modelo OSI/ISO. Como o
mDNS é um protocolo DNS, porém Multicast, ele tem o poder de sempre estar
passando a mensagem para pontos diferentes, mas que são da mesma rede, ou
seja, o mDNS envia uma mensagem com todas as características do dispositivo,
contudo os outros dispositivos que receberem esta mensagem acabam
armazenando os dados, para que caso um dos dispositivos solicitem um serviço
entre na fila e receba a mesma mensagem armazenada (CHESHIRE; KROCHMAL,
2013).
2.1.5.9 Link-Local Multicast Name Resolution (LLMNR)
De acordo com Santana (2011), o LLMNR (Link-Local Multicast Name
Resolution) está situado na mesma camada do DNS, e o objetivo do protocolo é
habilitar a resolução de consultas de nome sem a necessidade de um servidor DNS.
O funcionamento deste protocolo ocorre por meio do envio de um pedido para
o multicast da rede, porém somente um remetente responde ao pedido, desde que
ele seja verdadeiro, se isso ocorrer a resposta será retransmitida por um endereço
unicast por intermédio do protocolo UDP, assim, ao obter uma resposta o emitente
processa o pedido para que possa começar a aquisição requerida pelo cliente
(SANTANA, 2011).
2.1.5.10 Internet Control Message Protocol (ICMP)
O ICMP (Internet Control Message Protocol) está localizado na camada de
redes do modelo OSI/ISO, sendo utilizado por roteadores para fornecer relatórios de
erro ocorrido, à fonte original. O ICMP funciona enviando-se uma mensagem, mas
ela não consegue por alguma razão chegar, ou seja, não consegue validar a
entrega, então este protocolo informa a origem que o roteador não conseguiu
descobrir o caminho, enviando a mensagem de “rede de destino inalcançável”.
40
Outra mensagem que é pouco comum é a de redução de fonte, útil para o
controle de congestionamento que permitiria que um roteador que esteja em um
engarrafamento envie uma mensagem ICMP de diminuição de fonte a um
hospedeiro para forçar este a reduzir sua aceleração de transmissão (KUROSE;
ROSS, 2010).
2.1.5.11 Internet Group Management Protocol (IGMP)
O IGMP (Internet Group Management Protocol) está localizado na mesma
camada do ICMP do modelo OSI/ISO. Este protocolo gerencia os grupos para
receber e enviar pacotes multicast, por meio dos hosts que repassam para outros
hosts que são encapsuladas em datagramas IP. A imagem (FIGURA 17) mostra
como as mensagens IGMP são encapsuladas e enviadas em datagramas IP
(LEMOS, 2011).
Fonte: <http://technet.microsoft.com/pt-br/library/cc787925(v=ws.10).aspx>
FIGURA 17 – Como as mensagens IGMP são enviadas
2.1.5.12 Secure Sockets Layer (SSL)
O SSL (Secure Sockets Layer) é um protocolo que não está somente em uma
camada como na maioria dos outros protocolos estudados, ele se encontra nas
camadas de aplicação, transporte e rede do modelo OSI/ISO. Segundo Kurose e
Ross (2010), se fosse encontrado somente na camada de rede ele acabaria
oferecendo um bom “cobertor de segurança” com a criptografia de todos os dados
da camada de transporte e com a autenticação de todos os endereços IP de origem,
41
mas não garantiria a segurança para o cliente. Por isso há a necessidade que as
outras camadas envolvidas participem deste processo para que permitam que
cliente/servidor troquem informações em segurança, protegendo o conteúdo com
integridade.
Conforme explicam Kurose e Ross (2010), o funcionamento do SSL se dá por
meio do browser que manda uma mensagem ao servidor para saber qual a versão
utilizada do SSL para negociarem qual será a chave criptografada utilizada, então o
servidor envia para o browser qual serão a versão e as preferências criptográficas e
seu certificado que contém a chave pública do servidor – que é certificada por uma
CA (Certificate Authority - Autoridade Certificadora) – sendo assim o certificado é
assinado com a chave privada da CA. O browser ao receber o certificado do servidor
verifica se a CA está na lista, pois caso ocorra de não estar será enviado uma
mensagem que a conexão não pode ser autenticada, mas se estiver na lista o
browser validará o certificado por meio da chave pública e conseguirá ter a chave
pública do servidor, desta forma o browser gera uma chave simétrica, que a
criptografa com a chave pública do servidor e envia essa nova chave ao servidor
informando que as mensagens futuras serão enviadas com essa nova chave e logo
em seguida o browser ainda envia outra mensagem, também criptografada,
comunicando que a parte dele foi finalizada (FIGURA 18).
Fonte: <http://publib.boulder.ibm.com/tividd/td/TRM/GC32-1323-00/pt_BR/HTML/admin231.htm>
FIGURA 18 – Funcionamento do Protocolo SSL
42
Por sua vez o servidor encaminha uma mensagem ao browser comunicando
que as futuras mensagens serão criptografadas com aquela nova chave, após ter
feito isso ele também envia outra mensagem informando que a parte dele também
foi finalizada.
Uma vez que as informações acima tenham sido confirmadas pelo browser e
pelo servidor, utilizam-se as chaves para trancar (criptografar) e destrancar
(descriptografar) os dados que foram enviados uns aos outros para que assim possa
autenticar a integridade do processo e efetuada a entregada da mensagem sem
difundir qualquer informação (KUROSE; ROSS, 2010).
2.1.5.13 Transport Layer Security (TLS)
O TLS (Transport Layer Security) descende do SSL, e sua função é garantir a
segurança de transferência de dados na Internet nas camadas de aplicação e
transporte do modelo OSI/ISO. Este protocolo trabalha encapsulando os outros
protocolos, como TCP e HTTP entre outros, porém para que a transmissão seja
confiável é necessária a participação de outros dois protocolos handshaking que
autentica cliente/servidor, além de escolher qual o tipo de criptografia que será
utilizado no pacote e tem também o protocolo de registro que faz a parte de
transmissão segura de dados após a autenticação de ambos os lados.
Como se pode notar não há uma diferença tão grande do protocolo SLL
exceto por ele ter uma camada a mais, mas como se podem notar ambos tem a
mesma finalidade e eficiência (DIERKS; RESCORLA, 2008).
2.1.5.14 Address Resolution Protocol (ARP)
O ARP (Address Resolution Protocol) está localizado na camada de rede do
modelo OSI/ISO, sua função é conhecer o endereço físico de uma placa de rede que
corresponda a um endereço IP.
Já se sabe que todo dispositivo ligado à rede tem um número de identificação
que é formado por um determinado tamanho de bits que é estipulado dependendo
da tecnologia da rede utilizada, este por sua vez esta diretamente relacionado com a
43
fabricação da placa, ou seja, de seu fabricante, porém não se pode utilizar este
número para se conectar a rede, porque cada vez que alguém trocasse a placa de
rede teria que alterar o endereço dos dispositivos conectados.
Para isso existe o protocolo ARP para fazer um mapeamento dinâmico entre
o endereço IP e os endereços físicos. Isso ocorre com o ARP perguntando para
cada máquina conectada à rede qual é o seu endereço físico, após ele ter as
respostas é feito uma tabela a qual terá os dois tipos de endereço, o físico e o IP,
que serão armazenados em uma memória, desta forma fará que uma máquina se
comunique com outra consultando a tabela que irá mostrar na memória a sua
localização. Caso ocorra de não encontrar o endereço o protocolo entrará em ação
fazendo um novo pedido na rede para que seja contatado (KUROSE; ROSS, 2010).
2.1.5.15 Speedy (SPDY)
O SPDY (pronuncia-se speedy) é um protocolo que se encontra na camada
de rede do modelo OSI/ISO, e sua principal função é acelerar o carregamento da
página Web por meio do cliente/servidor, que tem como objetivo apertar o cabeçalho
de resposta para que assim possa diminuir os cabeçalhos que se assemelham que
serão enviados repetitivamente por várias mensagens.
O SPDY permite que muitas solicitações HTTP simultâneas funcionem
através de uma única sessão TCP. Também reduz a largura de banda usada por
cabeçalhos HTTP comprimindo e eliminando cabeçalhos desnecessários.
Desta forma esse protocolo permite que vários pedidos sejam multiplexados
em uma exclusiva conexão, otimizando a comunicação entre cliente/servidor
evitando que haja o bloqueio de solicitação de recursos de menor importância para
os de maior importância (THE CHROMIUM PROJECTS, 2014).
2.1.5.16 Dropbox LAN Sync Discovery Protocol (DB-LSP-DISC)
Segundo Lemos (2011), o protocolo DB-LSP-DISC (Dropbox® LAN Sync
Discovery Protocol) pertence à aplicação do Dropbox®, portanto é um protocolo
proprietário. Sua principal funcionalidade é a sincronização entre as várias estações
44
em que o usuário tem o Dropbox® instalado, uma vez que ele utiliza-se da mesma
conta. Com isso é possível efetuar um acesso direto apenas com a rede local, sem
intervenção da nuvem.
Esta aplicação requer acesso à porta TCP 17500, e envia pacotes broadcast
com frequência para a rede local e tem como função informar a sua estada na rede.
Seu funcionamento ocorre por meio do recebimento dos pacotes, e uma estação na
rede local acaba descobrindo que outra estação também esta usando o Dropbox®
que será identificado com a conta que está sendo usada por meio do conteúdo da
mensagem enviada.
Com isso, o DB-LSP-DISC acelera a sincronização quando o arquivo existe
na LAN (Local Area Network), sendo uma vantagem adicional para uso em locais
onde os computadores estão ligados em rede sob o mesmo roteador (LEMOS,
2011).
2.1.6 Wireshark
O Wireshark Network Protocol Analyser é um software open source (código
aberto) que, como o próprio nome sugere, é um analisador de tráfego de rede.
Disponível para diversos sistemas operacionais – Microsoft® Windows, Linux, Mac
OS X, Oracle Solaris, FreeBSD, NetBSD, entre outros – é usado para
monitoramento e resolução de problemas de rede, desenvolvimento de softwares e
protocolos de comunicação, e fins educativos.
Este tipo de programa é conhecido como sniffer (farejador), e trabalha
verificando os pacotes transmitidos pelo dispositivo de comunicação do computador
(placa de rede, placa de fax modem, etc.). O Wireshark pode ser utilizado em tempo
real de execução (LAMPING; SHARPE; WARNICKE, 2014).
O Wireshark faz uma inspeção profunda em mais de 1000 protocolos, e os
dados podem ser lidos de fontes como Ethernet, IEEE 802.11, PPP (Point-to-Point
Protocol), HDLC (High-Level Data Link Control), ATM (Asynchronous Transfer
Mode), Bluetooth, USB, Token Ring, Frame Relay e FDDI (Fiber Distributed Data
Interface) (LAMPING; SHARPE; WARNICKE, 2014).
Uma das vantagens da ferramenta é ter uma interface gráfica, que organiza
os pacotes por protocolos e os exibe em uma lista de fácil navegação, podendo
45
exibir os campos, junto com seus significados, como especificado pelos diferentes
protocolos de rede (FIGURA 19).
FIGURA 19 – Interface inicial do software Wireshark
Este programa é muito utilizado por analistas e administradores de redes para
detectar problemas ou conexões suspeitas, auxiliar no desenvolvimento de
aplicativos, testar se as senhas usadas na rede estão realmente sendo
criptografadas, além de uma série de outras atividades relacionadas à segurança.
46
2.2 Metodologia
Esta seção apresenta a metodologia de desenvolvimento deste trabalho,
demonstrando quais recursos computacionais e softwares são utilizados, assim
como a operabilidade do experimento.
2.2.1 Descrição do Ambiente de Testes
Na realização dos testes, foi utilizado um notebook Dell® Inspiron com
processador Intel® Core™i5 2450M de 2.50 GHz, memória RAM de 4 GB com
sistema operacional Microsoft® Windows 7 Professional de 32 bits, e para o acesso à
Internet foi utilizado um modem/roteador FiberHome® modelo HG110-B, com serviço
de banda larga Vivo® Internet Fixa de 2 Mbps.
Estas configurações foram empregadas para analisar a segurança das
plataformas Google Drive® e Dropbox®, sendo necessário gerar um tráfego de dados
para ambos os serviços. Esse tráfego de dados é provido pelo upload de extensões
de arquivos distintos em um único computador, sem nenhum outro dispositivo
conectado à rede particular, onde foi realizado o teste de uma nuvem por vez, por
meio do navegador Google Chrome®. Em outras palavras, no momento em que
foram feitos os testes no Google Drive®, por exemplo, só havia esta página
específica aberta neste navegador, desta forma foi seguido este padrão para os
demais testes.
Para fazer tal análise, foi empregado o software Wireshark, o qual foi
instalado e executado para ministrar a proposta de verificação dos protocolos.
Como o teste será entre o Dropbox® e o Google Drive®, também será
necessário criar contas para que tenha acesso aos dois sistemas em nuvens, e a
instalação de ambos nesta máquina.
Após a conclusão desta etapa, foram selecionados aleatoriamente arquivos
de tamanhos diferentes e extensões variadas utilizadas nesta analise como: txt, xlsx,
pptx, pdf, jpg, mp3 e wmv. Tais tipos de arquivos foram selecionados por serem os
mais usuais no dia-a-dia, tanto para usuários domésticos como para usuários
corporativos.
47
2.2.2 Rotina de Testes
Depois de serem escolhidos os arquivos a serem utilizados nos testes, todos
os nós da rede local com acesso à Internet foram desligados, e na máquina de
testes foram fechados todos os navegadores e páginas Web que estavam abertos,
sendo acessado apenas o Google Drive® como mostra a FIGURA 20.
FIGURA 20 – Interface do Google Drive®
Desta forma, foi deixado tudo preparado para a primeira etapa de testes com
o Google Drive® e o programa de analise de protocolos Wireshark, assim como pode
ser visto na FIGURA 21 que mostra o caminho para se enviar um arquivo do
computador para o serviço em nuvem Google Drive®.
48
FIGURA 21 – Selecionando para fazer upload de arquivos
Porém, antes de se selecionar o arquivo a ser enviado, foi aberta a página do
Google Drive® e a interface do Wireshark juntas na mesma tela, como pode se ver
na FIGURA 22.
FIGURA 22 - Página do Google Drive® e interface do Wireshark
49
Já na FIGURA 23, é mostrada a escolha do arquivo juntamente com a página
do software em aberto, para que no momento em que determinasse o arquivo que
seria enviado para o Google Drive® conseguisse primeiramente iniciar o programa e,
simultaneamente, selecionar o arquivo para ser enviado, podendo assim
acompanhar quais dados estavam passando na rede no momento de upload do
arquivo conforme a FIGURA 24 e assim chegar até o momento da conclusão de
envio conforme a FIGURA 25, onde mostra que pode parar o programa, pois o
arquivo completou o seu destino.
FIGURA 23 – Escolha do arquivo a ser enviado ao Google Drive®
50
FIGURA 24 – Wireshark analisando a transferência para o Google Drive®
FIGURA 25 – Término de envio do arquivo para o Google Drive®
51
Esta necessidade de visualização ocorre pelo motivo de se analisar o tempo e
o período que passam os protocolos, pois caso não parasse o programa ele
continuaria a capturar mais protocolos, uma vez que o computador continuasse
conectado a rede.
Com o Dropbox® não foi diferente o procedimento de execução e análise.
Apenas abaixo seguem a FIGURA 26, FIGURA 27, FIGURA 28 e FIGURA 29 que
mostram o caminho para upload de arquivos.
FIGURA 26 – Interface do Dropbox®
52
FIGURA 27 – Acessando o envio de arquivo para o Dropbox®
FIGURA 28 – Envio de arquivo para o Dropbox®
53
FIGURA 29 – Escolha do arquivo a ser enviado ao Dropbox®
Com isso, foram analisados separadamente os dados da transferência de
cada arquivo que foi enviado como é mostrado na FIGURA 30, tanto pelo Dropbox®
quanto pelo Google Drive®, para averiguar criticamente o que acontece nesse
período em cada nuvem.
54
FIGURA 30 – Fluxograma do ambiente de teste
Para fazer esta análise, foi desenvolvida uma ferramenta na linguagem Java
(APÊNDICE – CÓDIGO FONTE DO PROGRAMA) que lista o campo desejado e faz
a contagem da quantidade de protocolos ou endereços IP encontrados no intervalo
de tempo estudado conforme a FIGURA 31. Para isso precisa-se exportar o arquivo
do Wireshark no formato CSV (Comma-Separated Values), porque este formato
transforma as informações dos dados coletados em texto usando a vírgula para
separar os campos, possibilitando que a ferramenta faça uma varredura a qual
mostra como resultado uma lista dos itens que serão analisados e sua respectiva
quantidade conforme a FIGURA .
56
FIGURA 32 – Resultado da análise de IPs de destino
A necessidade de automatizar a classificação de dados foi devido ao alto
número de pacotes, variedades de protocolos e endereços IP encontrados nas
transferências de arquivos para os dois serviços (Google Drive® e Dropbox®), e que
seriam contados manualmente caso a ferramenta não tivesse sido desenvolvida.
Desta forma automatizada, obteve-se maior produtividade e eficiência no
tempo. Para demonstrar essa agilidade, na ferramenta há um cronômetro que
mostra o tempo, em segundos, que demora a fazer a classificação dos dados do
arquivo CSV, conforme visto na FIGURA 32, onde foi listada uma contagem de IPs,
e na última linha o tempo gasto no processamento.
Desta forma, foi possível analisar os dados de cada transferência de arquivo,
com as quantidades de cada tipo de protocolo, e dos IPs de pesquisa e de
destinação.
Tais IPs foram analisados através do prompt de comando, fazendo uso do
comando ipconfig, para analisar os IPs que são da rede (FIGURA 303).
57
FIGURA 303 – Comando ipconfig no prompt de comando
Os IPs que são desconhecidos foram analisados um a um através do
comando tracert + o número do IP que se deseja verificar (FIGURA 34).
FIGURA 34 – Comando tracert no prompt de comando
58
2.3 Resultados
Nesta seção são apresentados e discutidos os resultados obtidos pelos
experimentos realizados neste trabalho.
2.3.1 Cenário 1
A TABELA 2 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de um arquivo texto (txt) de 50 KB para as nuvens
do Google Drive® e do Dropbox®. Assim esta análise foi feita respectivamente com
163 e 179 pacotes no intervalo de upload de aproximadamente 4,476 e 3,18
segundos.
Como pode notar através da TABELA 2, existem alguns protocolos que não
são utilizados comumente, neste caso são os pacotes HTTP e SSDP que aparecem
somente no Dropbox®. Esses dois protocolos aparecem porque o SSDP é composto
pelo HTTP para anunciar que tem um dispositivo na rede, neste caso não há outro
dispositivo a não ser um roteador Wi-Fi.
TABELA 2 – Quantidade de protocolos no upload do arquivo txt
Arquivo txt
Protocolo Google Drive® Dropbox®
ARP 3 3 HTTP 0 2 ICMP 4 2 SSDP 0 8 TCP 87 127 TLS 69 37
Nos gráficos abaixo estão representados em percentual a utilização de cada
protocolo, notando que no GRÁFICO 1, o protocolo TLS equivale o dobro do que no
GRÁFICO 2 porque a arquitetura do Google Drive® atualiza a cada 40 segundos o
sistema de segurança da nuvem. Já a cor verde no GRÁFICO 1 vale a metade do
GRÁFICO 2, mas isso se dá pela diferença de protocolos existentes em cada
serviço.
59
GRÁFICO 1 – Protocolos no upload do arquivo txt para o Google Drive®
GRÁFICO 2 – Protocolos no upload do arquivo txt para o Dropbox®
2.3.2 Cenário 2
A TABELA 3 apresenta os protocolos e a quantidade dos mesmos, no
momento de envio de uma planilha (xlsx) de 90 KB para as nuvens do Google Drive®
e do Dropbox®. Desta forma esta análise foi feita respectivamente com 227 e 241
pacotes no intervalo de upload de aproximadamente 4,302 e 4,01 segundos.
Assim como na TABELA 2 a TABELA 3 não são equivalentes, pela mesma
razão que a TABELA 2.
60
TABELA 3 – Quantidade de protocolos no upload do arquivo xlsx
Arquivo xlsx
Protocolo Google Drive® Dropbox®
ARP 1 3 HTTP 0 3 ICMP 9 3 SSDP 0 6 TCP 139 189 TLS 78 37
Nos gráficos abaixo estão representados em percentual a utilização de cada
protocolo, notando que no GRÁFICO 3, o protocolo TLS continua equivalente ao
dobro do que no GRÁFICO 4, e idêntico ao GRÁFICO 1 e GRÁFICO 2. Já a cor
verde no GRÁFICO 3 é menor que no GRÁFICO 4, mas isso se dá não só pela
diferença de protocolos, mas também pela quantidade que está passando.
GRÁFICO 3 – Protocolos no upload do arquivo xlsx para o Google Drive®
GRÁFICO 4 – Protocolos no upload do arquivo xlsx para o Dropbox®
61
2.3.3 Cenário 3
A TABELA 4 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de uma apresentação (pptx) de 143 KB para as
nuvens do Google Drive® e do Dropbox®. Assim esta análise foi feita
respectivamente com 286 e 280 pacotes no intervalo de upload de
aproximadamente 6,642 e 5,672 segundos.
Como pode notar através da TABELA 4, existem alguns protocolos que não
são utilizados comumente, neste caso são os pacotes HTTP que desta vez agem
apenas transferindo as mensagens dos cabeçalhos comunicando o conteúdo da
mensagem. Já o DB-LSP-DISC que aparece somente no Dropbox®, esses dois
protocolos só aparecem no Dropbox® porque o DB-LSP-DISC é um protocolo de uso
exclusivo que permite a sincronização entre as várias estações que o usuário tenha,
vendo que nas próximas tabelas também aparecerá este protocolo. Notando ainda
que a partir desta tabela surge um novo protocolo, o SSL, para os dois sistemas de
nuvem, ele surgiu não só para proteger o envio, mas provavelmente por causa de
seu tamanho e consequentemente o seu tempo de envio que proporcionou que este
pacote acabasse passando na rede para auxiliar na segurança.
TABELA 4 – Quantidade de protocolos no upload do arquivo pptx
Arquivo pptx
Protocolo Google Drive® Dropbox®
ARP 3 1 DB-LSP-DISC 0 3
HTTP 0 2 ICMP 6 2 SSL 1 1 TCP 182 237 TLS 94 34
62
GRÁFICO 5 – Protocolos no upload do arquivo pptx para o Google Drive®
GRÁFICO 6 – Protocolos no upload do arquivo pptx para o Dropbox®
2.3.4 Cenário 4
A TABELA 5 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de um arquivo no formato pdf de 225 KB para as
nuvens do Google Drive® e do Dropbox®. Assim esta análise foi feita
respectivamente com 415 e 445 pacotes no intervalo de upload de
aproximadamente 8,074 e 8,164 segundos.
Como pode notar, neste cenário tem-se o mesmo que na TABELA 4 exceto
pelo Dropbox® não ter nenhum SSL, mas o Drive sim, isso ocorre devido à
compensação com o HTTP que tem uma implementação do protocolo TLS.
63
TABELA 5 – Quantidade de protocolos no upload do arquivo pdf
Arquivo pdf
Protocolo Google Drive® Dropbox®
ARP 3 4 DB-LSP-DISC 0 3
HTTP 0 3 ICMP 1 1 SSL 1 0 TCP 281 391 TLS 129 43
GRÁFICO 7 – Protocolos no upload do arquivo pdf para o Google Drive®
GRÁFICO 8 – Protocolos no upload do arquivo pdf para o Dropbox®
64
2.3.5 Cenário 5
A TABELA 6 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de uma imagem (jpg) de 4096 KB para as nuvens do
Google Drive® e do Dropbox®. Assim esta análise foi feita respectivamente com 6003
e 5361 pacotes no intervalo de upload de aproximadamente 110,842 e 110,462
segundos.
Notando que apareceu o protocolo DNS que ao ser executado intermediou
junto com o endereço IP que se comunicasse para encontrar o endereço de destino.
E também o DHCP que se utiliza do protocolo UDP para um cliente enviar em
broadcast uma requisição DHCP capturando este pacote que solicitará um pacote
com configurações onde consta pelo menos, um endereço IP. Interessante ressaltar
que todos estes protocolos comentados que surgiram até agora se encontram na
camada de aplicação do modelo OSI/ISO, porque deve ser primeiramente passados
por esta camada para separar a comunicação em rede entre processos de diferentes
computadores.
TABELA 6 – Quantidade de protocolos no upload do arquivo jpg
Arquivo jpg
Protocolo Google Drive® Dropbox®
ARP 25 14 DB-LSP-DISC 0 9
DHCP 2 0 DNS 4 1 HTTP 2 9 ICMP 35 28 SSDP 0 16 SSL 2 33 TCP 4548 2825 TLS 1377 2426 UDP 6 0
65
GRÁFICO 9 – Protocolos no upload do arquivo jpg para o Google Drive®
GRÁFICO 10 – Protocolos no upload do arquivo jpg para o Dropbox®
2.3.6 Cenário 6
A TABELA 7 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de um áudio (mp3) de 6144 KB para as nuvens do
Google Drive® e do Dropbox®. Assim esta análise foi feita respectivamente com
10263 e 9171 pacotes no intervalo de upload de aproximadamente 185,85 e 186,33
segundos.
Como se pode verificar esta tabela não apresenta nenhuma alteração
significativa com relação à TABELA 6.
66
TABELA 7 – Quantidade de protocolos no upload do arquivo mp3
Arquivo mp3
Protocolo Google Drive® Dropbox®
ARP 62 27 DB-LSP-DISC 0 21
DNS 2 4 HTTP 2 22 ICMP 39 46 SSDP 60 24 SSL 8 0 TCP 7550 8537 TLS 2538 489 UDP 2 0
GRÁFICO 11 – Protocolos no upload do arquivo mp3 para o Google Drive®
GRÁFICO 12 – Protocolos no upload do arquivo mp3 para o Dropbox®
67
2.3.7 Cenário 7
A TABELA 8 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de um vídeo (wmv) de 50176 KB para as nuvens do
Google Drive® e do Dropbox®. Assim esta análise foi feita respectivamente com
170521 e 71988 pacotes no intervalo de upload de aproximadamente 1473,36 e
1480,77 segundos. Nesta tabela surge o protocolo LLMNR porque ele consulta os
nomes sem a necessidade depender somente do DNS, assim acaba sendo um
auxiliar para não sobrecarregar ou limitar o DNS. Já o protocolo NBNS aparece
porque, como é um arquivo muito grande, ele consegue assegurar comunicação
confiável de informações entre computadores com uma sessão criada.
TABELA 8 – Quantidade de protocolos no upload do arquivo wmv
Arquivo wmv
Protocolo Google Drive® Dropbox®
ARP 232 207 DB-LSP-DISC 0 147
DHCP 4 6 DNS 24 80 HTTP 31 149 ICMP 304 373
LLMNR 16 24 NBNS 12 18 SSDP 364 336 SSL 409 170 TCP 125546 53800 TLS 43574 17674
GRÁFICO 13 – Protocolos no upload do arquivo wmv para o Google Drive®
68
GRÁFICO 14 – Protocolos no upload do arquivo wmv para o Dropbox®
2.3.8 Cenário 8
A TABELA 9 apresenta o aparecimento dos protocolos e a quantidade dos
mesmos, no momento de envio de um arquivo no formato pdf de 102400 KB para as
nuvens do Google Drive® e do Dropbox®. Assim esta análise foi feita
respectivamente com 325479 e 146309 pacotes no intervalo de upload de
aproximadamente 3327,42 e 3117,88 segundos.
A funcionalidade deste Cenário 8 é comparar com o Cenário 4 para obter
algumas conclusões finais com relação a tamanho de arquivo e quantidade de
protocolos verificando se são diretamente proporcionais.
TABELA 9 – Quantidade de protocolos no upload do arquivo pdf
Arquivo newpdf
Protocolo Google Drive® Dropbox®
ARP 650 482 DB-LSP-DISC 0 0
DHCP 16 14 DNS 157 66 HTTP 98 61 ICMP 808 709
LLMNR 68 56 NBNS 51 42 SSDP 738 668 SSL 698 341 TCP 238552 109165 TLS 83635 34697
69
GRÁFICO 15 – Protocolos no upload do arquivo newpdf para o Google Drive®
GRÁFICO 16 – Protocolos no upload do arquivo newpdf para o Dropbox®
70
3 CONCLUSÃO
Com base nos resultados apresentados nesta monografia, a qual teve como
objetivo analisar os serviços Google Drive® e Dropbox® do ponto de vista da
segurança, conclui-se que o protocolo de maior frequência nas transferências de
arquivos para a nuvem é o TCP, que é responsável pela transmissão de dados pela
rede. Na sequência vem o protocolo TLS, que é responsável por fazer a segurança
dos pacotes que estão sendo transferidos.
Ambos os serviços em nuvem analisados apresentaram estes dois protocolos
em todos os testes realizados. Por outro lado, o protocolo SSL, que também é um
importante protocolo de segurança, não aparece em todos os casos estudados,
sendo mais recorrente no serviço Google Drive®.
Com isso pode-se aferir que o tamanho do arquivo, e consequentemente o
tempo de transferência do mesmo para a nuvem, influenciam diretamente na
quantidade total de protocolos envolvidos em seu upload, incluindo
proporcionalmente os protocolos de segurança, ou seja, quanto maior o arquivo e
maior for o tempo de transferência, maior é o número de protocolos de segurança
envolvidos no upload. Esta situação ocorre por causa do estilo de arquitetura de
cada um dos sistemas.
Pelo software analisador de tráfego Wireshark, foi possível concluir que não é
possível a leitura direta dos dados que trafegam na rede, pois estes dados estão
sempre criptografados por ambos os serviços testados.
Por fim, dentro das condições estudadas, e atendendo o objetivo deste
trabalho, pode-se afirmar que ambos os sistemas em nuvem, Google Drive® e
Dropbox®, estão criptografados sem maiores interferências.
71
REFERÊNCIAS
CHESHIRE, Stuart; KROCHMAL, Marc. Multicast DNS. Request for Comments.
Internet Engineering Task Force (IETF). n. 6762, 2013.
CLOUD SECURITY ALLIANCE. Guia de Segurança para Áreas Críticas Focado
em Computação em Nuvem. V. 2.1. 2010. 81 p. Disponível em:
<https://cloudsecurityalliance.org/guidance/CSAGuidance-pt-BR.pdf> Acesso em: 12
nov. 2014. Tradução de Security Guidance for Critical Areas of Focus in Cloud
Computing.
COUTINHO, Emanuel F. et al. Elasticidade em Computação na Nuvem: Uma
Abordagem Sistemática. In: SIMPÓSIO BRASILEIRO DE REDES DE
COMPUTADORES E SISTEMAS DISTRIBUÍDOS (SBRC 2013), 31. 2013. Brasília.
Anais... . Porto Alegre: Sociedade Brasileira de Computação (SBC), 2013. p. 215–
258.
DIERKS, Tim; RESCORLA, Eric. The Transport Layer Security (TLS) Protocol.
Request for Comments. Internet Engineering Task Force (IETF). n. 5246, 2008.
DRAGO, Idilio et al. Inside Dropbox: Understanding Personal Cloud Storage
Services. In: 12th ACM Internet Measurement Conference (IMC’12). 2012, Boston,
USA. Proceedings.... New York, USA: ACM, 2012. p. 481–494.
______. Benchmarking Personal Cloud Storage. In: 13th ACM Internet Measurement
Conference (IMC’13). 2013, Barcelona, Spain. Proceedings.... New York, USA:
ACM, 2013. p. 205–212.
DRAGO, Idilio; VIEIRA, Alex Borges; SILVA, Ana Paula Couto da. Caracterização
dos Arquivos Armazenados no Dropbox. In: SIMPÓSIO BRASILEIRO DE REDES
DE COMPUTADORES E SISTEMAS DISTRIBUÍDOS (SBRC 2013), 31. 2013.
Brasília. Anais... . Porto Alegre: Sociedade Brasileira de Computação (SBC), 2013.
p. 109–114.
DROPBOX. Central de Ajuda do Dropbox. Disponível em:
<https://www.dropbox.com/help>. Acesso em: 14 nov. 2014a.
DROPBOX. Informações da Empresa. Disponível em:
<https://www.dropbox.com/news/company-info>. Acesso em: 14 nov. 2014b.
GOOGLE. Central de Ajuda do Google Drive. Disponível em:
<https://support.google.com/drive/#>. Acesso em: 08 nov. 2014.
72
KUROSE, James F.; ROSS, Keith W. Redes de Computadores e a Internet: Uma
Abordagem Top-Down. 5. ed. São Paulo: Pearson Education do Brasil, 2010. 640 p.
LAMPING Ulf; SHARPE Richard; WARNICKE, Ed. Wireshark User’s Guide:
For Wireshark 1.99. Revision 3.2. 2014. 197 p. versão eletrônica. Disponível em:
<https://www.wireshark.org/download/docs/user-guide-a4.pdf>. Acesso em: 18 nov.
2014.
LEMOS, Hélder Tavares de. Descoberta Passiva de Estações em Redes 802.11.
2011. 229 f. Dissertação (Mestrado em Engenharia de Comunicações) - Curso do
Ciclo de Estudos Integrados Conducentes ao Grau de Mestre em Engenharia de
Comunicações, Escola de Engenharia, Universidade do Minho, Guimarães, Portugal.
2011. Disponível em: <http://hdl.handle.net/1822/20241>. Acesso em: 11 nov. 2014.
REIS, Tâmara Batista; SILVA, Paulo Caetano da. Uma Análise da Abordagem Cloud
Computing em Relação a Arquitetura Orientada a Serviços (SOA). In:
CONFERÊNCIA INTERNACIONAL SOBRE SISTEMAS DE INFORMAÇÃO E
GESTÃO DE TECNOLOGIA (CONTECSI), 11. 2014. São Paulo. Disponível em:
<http://www.contecsi.fea.usp.br/envio/index.php/contecsi/11contecsi/paper/view/660
>.Acesso em: 08 nov. 2014.
SANTANA, Reginaldo Reis de. Definição Protocolo LLMNR (Link Local Multicast
Name Resolution) e Diferenças em Relação ao Protocolo NetBIOS. WebArtigos,
2010. Disponível em:<http://www.webartigos.com/artigos/definicao-protocolo-llmnr-
link-local-multicast-name-resolution-e-diferencas-em-relacao-ao-protocolo-
netbios/52380/>. Acesso em: 12 nov. 2014.
SOUSA, Flávio R. C.; MOREIRA, Leonardo O.; MACHADO, Javam C. Computação
em Nuvem: Conceitos, Tecnologias, Aplicações e Desafios. In: ESCOLA REGIONAL
DE COMPUTAÇÃO CEARÁ, MARANHÃO E PIAUÍ (ERCEMAPI 2009), III. 2009,
Parnaíba, PI. Anais... . Teresina: Sociedade Brasileira de Computação (SBC), 2009.
p. 150–175.
STEDING-JESSEN, Klaus; HOEPERS, Cristine; MONTES, Antonio. Mecanismos
para Contenção de Tráfego Malicioso de Saída em Honeynets. In: SIMPÓSIO
SOBRE SEGURANÇA EM INFORMÁTICA (SSI’2003), V. 2003. São José dos
Campos. Anais... .São José dos Campos: CTA/ITA/IEC, 2003. p. 101–106.
Disponível em: <ftp://143.107.200.66/pub1/SSI/SSI2003/Artigos/A19.pdf> Acesso
em: 10 nov. 2014.
TANENBAUM, Andrew Stuart. Rede de Computadores. 4. ed. Rio de Janeiro:
Campus, 2003. 945 p.
73
TAURION, Cezar. Cloud Computing - Computação em Nuvem: Transformando o
mundo da Tecnologia da Informação. Rio de Janeiro: Brasport, 2009. 228 p. ISBN
978-85-7452-423-8.
THE CHROMIUM PROJECTS. SPDY: An experimental protocol for a faster web.
Disponível em: <http://www.chromium.org/spdy/spdy-whitepaper>. Acesso em: 19
nov. 2014.
VERAS, Manoel. Cloud Computing: Nova Arquitetura da TI. Rio de Janeiro:
Brasport, 2012. 240 p. ISBN 978-85-7452-489-4.
______. Virtualização: Componente Central do Datacenter. Rio de Janeiro:
Brasport, 2011. 364 p. ISBN 978-85-7452-467-2.
VMWARE. Virtualização. Disponível em:<http://www.vmware.com/br/virtualization>.
Acesso em: 08 nov. 2014.
74
APÊNDICE – Código Fonte do Programa
1. package org.tcc.usf.csv;
2.
3. import java.io.BufferedReader;
4. import java.io.FileReader;
5. import java.io.IOException;
6. import java.util.ArrayList;
7. import java.util.Collections;
8. import java.util.HashSet;
9. import java.util.Set;
10.
11. public class CSV2XLS {
12. public static void main(String[] args) throws IOException{
13. ArrayList<String> protocols = new ArrayList<String>();
14. BufferedReader br = new BufferedReader(new FileReader("entrada.txt"));
15. String line = null;
16. long entrada = System.currentTimeMillis();
17. while ((line = br.readLine()) != null) {
18. protocols.add(line.split(",")[3].replaceAll("\"", ""));
19. }
20. Set<String> unique = new HashSet<String>(protocols);
21. for (String key : unique) {
22. if(key.equals("Protocol")){
23. //do nothing
24. }
25. else
26. System.out.println(key + ":
" + Collections.frequency(protocols, key));
27. }
28. br.close();
29. long saida = System.currentTimeMillis();
30. saida = saida-entrada;
31. System.out.println("Tempo de processamento: " + saida);
32. }
33. }