ANÁLISE DE SEGURANÇA DOS SISTEMAS CLOUD …lyceumonline.usf.edu.br/salavirtual/documentos/2700.pdf · BIANCA TRAUZZULA COMPARONI – R.A. 002200900058 ANÁLISE DE SEGURANÇA DOS

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.

“O começo de todas as ciências é o espanto de as coisas serem o que são.”

Aristóteles, Metafísica

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


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


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 .

55

FIGURA 31 – Fluxograma da execução do programa.

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


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


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


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


mesmos, no momento de envio de um arquivo no formato pdf de 225 KB para as




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



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


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



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


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



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


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



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


mesmos, no momento de envio de um arquivo no formato pdf de 102400 KB para as




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



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

Documents

ANÁLISE DE SEGURANÇA DOS SISTEMAS CLOUD …lyceumonline.usf.edu.br/salavirtual/documentos/2700.pdf · BIANCA TRAUZZULA COMPARONI – R.A. 002200900058 ANÁLISE DE SEGURANÇA DOS