uma arquitetura de referência guiada à conformidades de segurança para web services baseados em...

7/26/2019 Uma Arquitetura de Referncia Guiada Conformidades de Segurana para Web Services Baseados em Nuvem P

1/94

Ricardo Marinho de Melo

UMA ARQUITETURA DE REFERNCIA GUIADA A

CONFORMIDADES DE SEGURANA PARA WEB SERVICES

BASEADOS EM NUVEM PRIVADA

Dissertao de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE

2016
http://www.cin.ufpe.br/~posgraduacaohttp://www.cin.ufpe.br/~posgraduacao


2/94


UMA ARQUITETURA DE REFERNCIA GUIADA ACONFORMIDADES DE SEGURANA PARA WEB SERVICES

BASEADOS EM NUVEM PRIVADA

Trabalho apresentado ao Programa de do da Universi-

dade Federal de Pernambuco como requisito parcial para

obteno do grau de Mestre em Cincia da Computao.

Orientador:Vinicius Cardoso Garcia

RECIFE

2016


3/94

Catalogao na fonteBibliotecria Monick Raquel Silvestre da S. Portes, CRB4-1217

M528a Melo, Ricardo Marinho deUma arquitetura de referncia guiada a conformidades de segurana para

web services baseados em nuvem privada / Ricardo Marinho de Melo. 2016.93 p.: il., fig., tab.

Orientador: Vinicius Cardoso Garcia.Dissertao (Mestrado) Universidade Federal de Pernambuco. CIn,

Cincia da Computao, Recife, 2016.

Inclui referncias e apndice.

1. Engenharia de software. 2. Computao em nuvem. 3. Sistemasdistribudos. 4. Reuso de software. I. Garcia, Vinicius Cardoso (orientador). II.Ttulo.

005.1 CDD (23. ed.) UFPE- MEI 2016-088


4/94


Uma Arquitetura de Referncia Guiada Conformidades de Segurana

para Web Services Baseados em Nuvem Privada

Dissertao de Mestrado apresentada ao programa

de Ps-Graduao em Cincia da Computao da

Universidade Federal de Pernambuco, com requi-

sito parcial para a obteno do ttulo de Mestre em

Cincia da Computao

Aprovado em: 03/03/2016.

BANCA EXAMINADORA

Prof. Dr. Carlos Andr Guimares Ferraz

Centro de Informtica / UFPE

Prof. Dr. Julio Damasceno

Departamento de Estatstica e Informtica / UFRPE

Prof. Dr. Vinicius Cardoso Garcia

Centro de Informtica / UFPE

(Orientador)


5/94

Agradeo, inicialmente, a Deus, pela vida.

Agradeo a todos os professores que, de alguma forma,

contriburam para a concretizao da minha dissertao de

mestrado.


6/94

Agradecimentos

Primeiramente agradecer a Deus, por me iluminar e guiar sempre da melhor forma

possvel meu caminho.

Rafaela Arcoverde, pelo dedicao, pacincia, compreenso em minhas ausncias para

realizao deste trabalho.

Agradeo a todos os professores que, de alguma forma, contriburam para a concretizao

da minha ps-graduao.

Ao meu orientador, Vinicius Cardoso Garcia, pela oportunidade oferecida. Muito obri-

gado.

Agradeo tambm ao Carlo Marcelo pelas ideias trocadas, ajuda e motivao que foramfundamentais.

Ao Major Santos, Chefe da Subdiviso de Tecnologia da Informao do CINDACTA III,

por autorizar e fornecer toda infraestrutura necessria para meus estudos.

E por fim agradeo a mim mesmo, pela grande persistncia e determinao tida por todas

dificuldades enfrentadas ao longo de minha formao. Sou muito grato por ter conseguido chegar

at aqui.


7/94

Construmos muitos muros e poucas pontes

SIR ISAAC NEWTON


8/94

Resumo

Contexto:A crescente adoo de computao em nuvem ofereceu diversos benefcios,

como escalabilidade, eficincia e lucratividade, mas apresenta novos riscos de segurana que

comprometem a confidencialidade, integridade e disponibilidade dos servios prestados. Neste

contexto, as organizaes militares buscam modelos de nuvens privadas alinhadas com suas

preocupaes envolvendo segurana, conformidade e polticas. Atualmente, a segurana o

maior obstculo para ampla adoo da computao em nuvem.

Objetivo:Com base neste cenrio, o trabalho prope, a partir da anlise das normas e

implementaes de segurana paraWeb Services, definir uma arquitetura segura para mitigar

as principais ameaas de segurana em ambientes de nuvem, segundo o guia intitulado TheNotorious Nine: Cloud Computing Top Threats in 2013 da Cloud Security Alliance.

Metodologia:Atravs de um estudo na literatura sobre computao em nuvem e segu-

rana neste ambiente, foram utilizadas referncias da rea de pesquisa relacionadas ao problema

identificado. Especificou-se uma arquitetura segura como hiptese de soluo, e posterior-

mente avaliou-se tal hiptese por meio da implementao de um prottipo, evidenciando-se a

importncia desta soluo.

Resultados:Como resultado obteve-se uma arquitetura de referncia para minimizar os

riscos de segurana na implantao de nuvens privadas nas organizaes militares. Experimentosde campo contemplaram aquisies a respeito dos mecanismos de segurana aplicados, em parti-

cular os padresWS-Policy,WS-Securitye SAML, os quais conseguiram oferecer mecanismos

padro de segurana necessrios para realizar o intercmbio seguro de mensagens certificadas

em ambiente de nuvem.

Palavras-chave: Segurana da Informao. Web Services. Organizaes Militares. Computa-

o em Nuvem.


9/94

Abstract

Context:The ever increasing adoption of cloud computing has yielded several benefits,

such as scalability, efficiency and profitability. However, it does present new security threats

that compromise confidentiality, integrity and availability of the services offered. In this light,

military organizations search for private cloud models that comply with their concerns about

security, conformity and policies. Nowadays, security is the greatest obstacle for the widespread

adoption of cloud computing.

Objective:In this scenario, the work presented here aims, based on the analysis of the

current security rules and implementations for Web Services, to define a secure architecture to

mitigate the main security threats for cloud environment, as identified by the guide entitledTheNotorious Nine: Cloud Computing Top Threats in 2013issued by theCloud Security Alliance.

Method:Through a bibliographical study about cloud computing and security in such

environments, the main references on the problem were identified and used. In the sequel, a

secure architecture was specified as a solution hypothesis. Such hypothesis was then evaluated

through the implementation of a prototype, which has helped us to highlight the importance of

such solution.

Results:The main result of this work was a reference architecture that can be used to

minimize the security threats in the deployment of private clouds in military organizations. Fieldexperiments have taken into account inputs from the security mechanism patterns used, namely:

WS-Policy,WS-Securitye SAML. Such patterns offered the security levels needed for the secure

exchange of certified messages in cloud environments.

Keywords: Information Security. Web Services. Military Organizations. Cloud Computing.


10/94

Lista de Ilustraes

2.1 Relaes entre entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Arquitetura de normas deWeb Services(WS) proposta pelo W3C. . . . . . . . 23

2.3 Estrutura de uma mensagem SOAP. . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Estrutura de um documento WSDL. . . . . . . . . . . . . . . . . . . . . . . . 26

2.5 Formas de assinatura XMLDigital Signature . . . . . . . . . . . . . . . . . . 30

2.6 Relacionamento de Web Services, SOA e Computao em Nuvem . . . . . . . 39

4.1 Interao das Vises do Modelo 4+1 . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Viso lgica da Arquitetura de Referncia proposta . . . . . . . . . . . . . . . 504.3 Diagrama de Dependncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5 Exemplo de pacote HTTP capturado peloWireshark. . . . . . . . . . . . . . . 57

4.6 Diagrama de Sequncia Estudo de Caso 03 . . . . . . . . . . . . . . . . . . . 66

5.1 Fases da metodologia GQM . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Estrutura da Fase de Definio . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 Workflowdo ciclo de vida do Apache Axis 2 . . . . . . . . . . . . . . . . . . . 76

5.4 Anlise do aumento do tempo de resposta . . . . . . . . . . . . . . . . . . . . 79

5.5 Resultados da avaliao da Questo 01 . . . . . . . . . . . . . . . . . . . . . . 80




11/94

Lista de Tabelas

3.1 Comparativo entre as solues dos trabalhos relacionados para mitigao das

ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Propriedades de segurana afetadas por ameaas. . . . . . . . . . . . . . . . . 73

5.2 Ataques utilizados para cada ameaa . . . . . . . . . . . . . . . . . . . . . . . 73

5.3 Definio das Questes e Mtricas para avaliao . . . . . . . . . . . . . . . . 75


12/94

Lista de Acrnimos

AD Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

AWS Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

B2B business-to-business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

CaaS Components as a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

CINDACTA III Terceiro Centro Integrado de Defesa Area e Controle de Trfego Areo. .55

CN Computao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15CSA Cloud Security Alliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

DoS Denial of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

DDoS Distributed Denial-of-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

ePING Padres de Interoperabilidade de Governo Eletrnico . . . . . . . . . . . . . . . . . . . . . .17

FTP File Transfer Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

HTTP Hyper Text Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

HTTPS Hyper Text Transfer Protocol Secure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

JSON JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

IaaS Infrastructure as a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

IF Injeo de Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

IBM International Business Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

IDL Interface Definition Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

IdP Provedor de Identidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53

IETF Internet Engineering Task Force. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

LDAP Lightweight Directory Access Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

MITC Man in the Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

NIST National Institute of Standards and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

OASIS Organization for the Advancement of Structured Information Standards. . . . .15

OLDAP OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52PaaS Platform as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

PKI Infraestrutura de Chaves Pblicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


13/94

QoS Quality of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

REST Representational State Transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

RPC Remote Procedure Call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

SaaS Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

SGC Sistema de Gerenciamento de Credenciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

SAML Security Assertion Markup Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

SMTP Simple Mail Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

SOA Service-Oriented Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

SOAP Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

SSL Security Socket Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

SSO Single-Sign On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

TI Tecnologia da Informao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

TIC Tecnologias de Informao e Comunicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

TLS Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

UDDI Universal Description Discovery and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 23

URI Uniform Resource Identifie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

W3C World Wide Web Consortium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

WS Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

WSDL Web Services Description Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

WS-I Web Services Interoperability Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

WSLA Web Service Level Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

WSP Web Services PolicyouWS-Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

WSS Web Service SecurityouWS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

WSSP Web Services SecurityPolicyouWS-SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . . . .37

X-KRSS XMLKey Registration Service Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

X-KISS XMLKey Information Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

XKMS XML Key Management Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

XML eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16


14/94

Sumrio

1 Introduo 15

1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Estabelecimento do Problema. . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.5 Estrutura da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Referencial Terico 21

2.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.2 Normalizao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.3 eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . 23

2.1.4 Simple Object Access Protocol. . . . . . . . . . . . . . . . . . . . . . 24

2.1.5 Web Services Description Language . . . . . . . . . . . . . . . . . . . 25

2.1.6 Universal Description, Discovery and Integration . . . . . . . . . . . . 26

2.2 Web Services Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.2 XML Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.3 XML Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3 Security Assertion Markup Language . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1 A Anatomia da SAML . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4 Web Services Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.1 Polticas para Web Services . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.2 Web Services SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . . 372.5 Computao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.5.1 Modelos de Servio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5.2 Modelos de Implantao . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5.3 Ameaas Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5.3.1 Vazamento de Dados . . . . . . . . . . . . . . . . . . . . . 41

2.5.3.2 Perda de Dados . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5.3.3 Sequestro de Contas ou de Trfego de Servios. . . . . . . . 42

2.5.3.4 Interfaces Inseguras . . . . . . . . . . . . . . . . . . . . . . 432.5.3.5 Negao de Servio . . . . . . . . . . . . . . . . . . . . . . 43

2.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


15/94

3 Trabalhos Relacionados 45


4 Implementao da Proposta 49

4.1 Metodologia 4+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Viso Lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.1 Mdulo de Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.2 Mdulo de Mecanismos de Segurana . . . . . . . . . . . . . . . . . . 51

4.2.3 Mdulo de Polticas de Segurana . . . . . . . . . . . . . . . . . . . . 52

4.2.4 Mdulo de Gerenciamento de Acesso e Identidade . . . . . . . . . . . 52

4.3 Viso Dependncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Viso Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5 Viso Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6 Cenrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.6.1 Desenvolvimento da Aplicao. . . . . . . . . . . . . . . . . . . . . . 56

4.6.2 Experimento de Campo. . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.6.2.1 Estudo de Caso 01 . . . . . . . . . . . . . . . . . . . . . . . 57

4.6.2.2 Estudo de Caso 02 . . . . . . . . . . . . . . . . . . . . . . . 60

4.6.2.3 Estudo de Caso 03 . . . . . . . . . . . . . . . . . . . . . . . 65


5 Avaliao da Proposta 71

5.1 Metodologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.1.1.1 Publico alvo e cenrio de atuao . . . . . . . . . . . . . . . 72

5.1.1.2 Critrio de Avaliao . . . . . . . . . . . . . . . . . . . . . 72

5.1.2 Definio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1.3 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.1.4 Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2 Limitaes da Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Consideraes Finais 83

6.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Referncias 85

Apndice 89

A Certificado Digital 91


16/94

151515

1IntroduoO advento da Computao em Nuvem (CN), ou do ingls cloud computing, oferece

vantagens em investimentos operacionais por meio de custos sobre demanda, provido de um

ambiente dinmico e facilmente escalvel. A partir dos novos modelos de negcios estratgicos,

minimizam-se as preocupaes de gerenciamento operacional, trazendo vantagens de mobilidade,

escalabilidade e disponibilidade das informaes e servios de dentro para fora da organizao

(ARMBRUST et al.,2010). Como resultado, esses modelos de servio so oferecidos por um

nmero crescente de provedores em nuvem.

Em contrapartida, esses modelos de servio utilizados em ambiente da CN apresentam

diferentes nveis de riscos se comparados ao ambiente tradicional (CSA,2011). Segundo o

relatrio The Notorious Nine: Cloud Computing Top Threats in 2013, a Cloud Security

Alliance(CSA) identificou nove ameaas em ambientes de nuvem: vazamento de dados, perda

de dados, sequestro de contas ou de trfego de servios, interfaces inseguras, negao de

servios, usurio mal intencionado, abuso de servios da nuvem, investigao insuficiente e

vulnerabilidades de recursos compartilhados (CSA,2013).

A crescente insatisfao com a segurana em servios de processamento, transferncia e

armazenamento de dados em nuvens resultado de uma combinao de diversos fatores, dentre

os quais podem ser citados: a falta de padres de interoperabilidade bem definidos ( ISO/IEC,

2013); a perda de controle de dados e aplicaes em nuvens computacionais, resultando emindisponibilidades de servios, vazamento e perda de dados; a falta de conhecimento dos riscos

existentes em ambientes de nuvem. Segundo aCSA(2011), a segurana uma forte barreira

contra a ampla adoo da computao em nuvem.

Esses problemas de segurana so complexos, pois no envolvem apenas questes arqui-

teturais e tecnolgicas, mas tambm mudanas de processos, em funo dos novos modelos de

computao em nuvem. Organizaes comoWorld Wide Web Consortium(W3C) eOrganization

for the Advancement of Structured Information Standards(OASIS) so responsveis pelo con-

junto de padres de interoperabilidade e segurana dos Web Services(WS). Empresas comoInternational Business Machines(IBM) e Amazon Web Services(AWS), lderes do setor de

segurana em ambientes de nuvem, apoiam o desenvolvimento destes padres (CSER,2014).


17/94

16

1.

INTRODUO

O advento da Web se deu em meio a um universo de empresas com seus peculiares

sistemas computacionais, os quais, quando desenvolvidos no visavam interoperabilidade, por

exemplo, com os sistemas computacionais de seus clientes (POTTS,2003). A partir dessa

necessidade de interao entre diferentes aplicaes, surge uma nova caracterizao de sistemasdistribudos que possibilitam o cmbio de dados e integrao de sistemas j existentes: os Web

Services.

OsWSutilizam padres neutros comoHyper Text Transfer Protocol(HTTP) eeXtensible

Markup Language(XML), permitindo que as diferentes aplicaes sejam integradas atravs de

linguagens e protocolos largamente aceitos, assim garantindo interoperabilidade (W3C,2004).

AW3CeOASIStm por objetivo projetar e publicar especificaes, ou padres, que

cumprem a promessa dosWS: interoperabilidade entre as barreiras geogrficas, de hardware,

de sistema operacional, de linguagem de programao e integrao de plataformas a baixocusto (POTTS,2003). Contudo, a segurana dos servios e a transio de dados tornaram-se

alvo de estudo porque no universo deWS,que vai alm da transmisso de dados, segurana

significa mais do que inviolabilidade de informao. A segurana, nesse contexto, caracteriza-se

por uma gama de propriedades dentre as quais confidencialidade, integridade, disponibilidade,

no-repdio e autenticidade esto inclusas.

Para garantir a segurana nosWS, algumas tecnologias foram criadas, entre elas,Web

Service SecurityouWS-Security(WSS),Security Assertion Markup Language(SAML) e Web

Services PolicyouWS-Policy(WSP), de forma que as suas especificaes tornaram-se indispen-

sveis para a construo deWSseguros (OASIS,2012a).

Neste contexto, com base na importncia da segurana nosWS, este trabalho tem por

objetivo estudar os mecanismos de segurana,WSS,SAMLeWSP,utilizados como padro nos

WS,definindo, analisando, caracterizando e demonstrando sua aplicabilidade, atravs de um

estudo de caso.

1.1 Motivao

O crescimento e a complexidade da infraestrutura da Internet e redes corporativas fizeram

com que vrios modelos de oferta de servios de Tecnologias de Informao e Comunicao (TIC)

fossem apresentados como opo no contexto das organizaes pblicas e privadas.

No mbito de empresas governamentais, estas podem realizar grandes investimentos em

seusdata centers1 ou customiz-los, migrando de um modelo tradicional de computao, em

que a prestao de servios realizada em mquinas reais, no havendo otimizao de recursos

computacionais (SILVA, 2013). Estas empresas podem utilizar como alternativa o modelo de

computao em nuvem, na qual se utiliza a tcnica de virtualizao para instanciar mquinas

virtuais e aplicaes, oferecendo custo reduzido, eficincia e escalabilidade dentro das fronteiras1Um centro de processamento de dados (CPD) o local onde so concentrados os equipamentos de processa-

mento e armazenamento de dados de uma empresa ou organizao


18/94

1.2. ESTABELECIMENTO DO PROBLEMA 17

dodata center(DAMASCENO,2015).

Ainda no mbito de empresas governamentais, especificamente federais, h recomenda-

es de interconexo na prestao dos servios de governo eletrnico, onde se deve considerar

o nvel de segurana que regulamentam a utilizao daTICna interoperabilidade de serviosde governo eletrnico (EPING, 2016). Essas recomendaes do Padres de Interoperabilidade

de Governo Eletrnico (ePING) descrevem definies de um conjunto mnimo de premissas,

polticas e especificaes tcnicas que estabelecem as condies de interao com os demais

Poderes e esferas de governo e com a sociedade em geral.

Com toda essa infraestrutura de tecnologia disponvel, osWStornam-se uma nova opo

de negcio para as empresas que planejam utilizar aCNcomo meio de compartilhamento de

informaes. A segurana um elemento indispensvel para a construo e desenvolvimento

de um ambiente de nuvem confivel. No entanto, garantir a segurana dos WSrepresenta um

desafio devido s limitaes dos padres e necessidade de dar suporte a uma considervel

demanda de servios (POTTS,2003).

1.2 Estabelecimento do Problema

Motivado pelas questes apresentadas na Seo anterior, o principal objetivo deste

trabalho , em linhas gerais:

Especificar, projetar e implementar uma arquitetura de software paraWSatendendo aos

padres e polticas contidos na ePINGe que permita o desenvolvimento de solues de aplicaes

que usam esses servios com base nos mecanismos utilizados como padro de segurana nos

servios Web:WSS, SAMLeWSP.Alm disso, este trabalho visa prover uma implementao

de referncia desta arquitetura de software.

1.3 Justificativa

O presente trabalho justifica-se, primeiramente, pela necessidade de normas de segurana

para especificao de mecanismos de proteo para que os Web Servicespossam contemplar

os valores necessrios garantia da segurana na sua utilizao. Para isso, j existem padres

promissores para segurana: WSS(OASIS,2012a), o qual oferece mecanismos padres de

segurana necessrios para realizar o intercmbio seguro de mensagens certificadas em ambientes

de nuvem, atravs de assinaturas digitais e criptografia;WSP(W3C,2007b), que prov um

modelo de propsito geral para descrever conjunto de regras da segurana; e por fim, oframework

SAML(OASIS,2008), que define uma forma padro para criar, trocar e interpretar asseres de

segurana entre entidades de uma aplicao distribuda de modelo Software as a Service(SaaS).

Este trabalho avalia a arquitetura de software proposta, atravs de experimentos decampo com desenvolvimento de um prottipo para anlise da tecnologia de servios seguros

pelas normasWSS,SAMLeWSP.A principal contribuio desta dissertao o retrato atual


19/94

18

1.

INTRODUO

do modelo de nuvem privada atravs da utilizao da tecnologia de WS, com uma anlise

aprofundada das normas e implementaes de segurana propostas.

1.4 Objetivos

Com objetivo de atender crescente demanda dos serviosTICbaseados em computao

em nuvem privada, este trabalho prope especificar, projetar e implementar uma arquitetura de

software guiada por conformidades de segurana paraWSem um ambiente de computao em

nuvem privada em uma organizao militar. Para isto, sero implementados experimentos de

campo com objetivo de analisar os mecanismos de segurana utilizados como padro nosWS.

Esta proposta objetiva adotar uma arquitetura de referncia de oferta de servios de

Tecnologia da Informao (TI) e garantir conformidades de segurana com as boas prticas desegurana da informao.

Os objetivos especficos a serem atingidos incluem:

1. Mitigar as cinco principais ameaas segurana em um ambiente de nuvem, conforme

identificado no relatrio The Notorious Nine: Cloud Computing Top Threats in

2013 daCSA(2013), com ateno especial ao modelo SaaSe anlise de risco

das principais propriedades bsicas da segurana: confidencialidade, integridade,

disponibilidade, autenticidade e no repdio;

2. Estudo da plataforma tecnolgica deWS, com nfase nas normas de segurana em

nvel de servio e de mensagem (LADAN,2011);

3. Atendimento a Portaria SLTI/MP n92, de 24 de dezembro de 2014, no que tange as

reas cobertas pelaePING;

4. Implementar e avaliar a arquitetura de referncia atravs de um experimento de

campo com desenvolvimento de um prottipo para anlise da tecnologia de servios

seguros propostos pelas normasWSS, SAMLeWSP.

1.5 Estrutura da Dissertao

A parte de introduo apresentou o contexto, a justificativa, a motivao para este

trabalho, uma viso geral da soluo proposta. Os objetivos e contribuies deste trabalho

tambm foram apresentados. A presente dissertao est organizada de acordo com a seguinte

estrutura:

Parte2: apresenta os principais conceitos bsicos deWSeCN. Tambm esclarecealguns detalhes de funcionamento das normas de segurana estudadas:WSS,SAML

eWSP.


20/94

1.5. ESTRUTURA DA DISSERTAO 19

Parte3: cita os trabalhos relacionados ou que tm pontos em comum com esta

dissertao.

Parte4:define as caractersticas bsicas da arquitetura proposta e descreve as espe-

cificaes do ambiente de implantao, alm de apresentar as implementaes dos

experimentos de campo das normas de segurana deste ambiente.

Parte5: apresenta a validao da anlise dos padres de segurana, com base na

implementao dos experimentos de campo executados, relatando resultados no que

concerne garantia dos atributos de segurana.

Parte6: apresenta as consideraes finais da dissertao e os trabalhos futuros.


21/94


22/94

212121

2Referencial Terico

Atravs de cinco Sees esta parte tem como objetivo explanar os conceitos e estudosutilizados como base para a presente pesquisa. Na primeira seo so apresentados os conceitos

dosWS.A segunda seo discute as noes da extensoWSSe seus mecanismos de segurana.

A terceira fornece detalhes da especificaoSAMLe a integrao entre os diferentes sistemas

de autenticao e de autorizao. A quarta seo aborda a estrutura doWSP para apoiar na

confeco das polticas de segurana. A quinta e ltima, aborda os conceitos e os principais

benefcios e ameaas daCN.

2.1 Web Services

WSso aplicaes de software que possuem interfaces bem definidas e descritas em

XML,classificadas como um tipo especfico de servio. Esses servios so identificados atravs

de umUniform Resource Identifie(URI) e chamadas atravs dasRemote Procedure Call(RPC),

como acontece em outros servios distribudos. O tipo de informao oferecida pelosWS o

que os tornam diferentes de sites Web comuns (W3C, 2004).O grande entusiasmo em torno dosWS baseado na promessa de interoperabilidade

entre aplicaes. As interaes com outras aplicaes so realizadas pela troca de mensagens

XML em um formato Simple Object Access Protocol(SOAP) especfico, utilizando padres

da Internet. OsWSno so a primeira tecnologia a nos permitir isto, mas so diferentes das

tecnologias existentes, pelo fato de usarem padres neutros de plataforma, comoHTTPe XML.

Atualmente, as vantagens dos WSso atrativas para muitas aplicaes, oferecendo

flexibilidade e interoperabilidade sobre outras tecnologias. Entre essas vantagens, encontra-se a

integrao prpria parabusiness-to-business(B2B). No entanto, essas aplicaes precisam dealgum nvel de segurana necessrio para que as mesmas se interconectem de forma confivel.

Dessa forma, a segurana tem sido considerada um obstculo na adoo dosWS.


23/94

22 2. REFERENCIAL

TERICO

2.1.1 Arquitetura

A gesto da arquitetura dosWS fornecida pelo modelo terico da Service-Oriented

Architecture(SOA). Trata-se de um modelo simples que contm trs entidades e trs operaes.

A Figura2.1ilustra esse modelo (POTTS,2003).

Figura 2.1:Relaes entre entidades

Fonte:W3C(2004) - adaptado.

O Provedor de servios: responsvel por duas atividades: a primeira publicar

as interfaces dos servios providos e a segunda atender as requisies originadas

pelos clientes.

O cliente:aps a consulta no diretrio para registro de servios e se o servio foi

encontrado, invoca o servio diretamente requisitando o provedor de servios.

O diretrio para registro de servios: o repositrio responsvel por informar

ao cliente a descrio dos servios e a localizao das interfaces dos mesmos. As

entidades interagem atravs de trs operaes fundamentais: publicar, localizar,

invocar. Inicialmente, o provedor de servios publica as interfaces no diretrio para

registro de servios, onde ficaro registrados os servios. Aps a publicao, o cliente

poder fazer uma consulta de um determinado servio, se esse servio for localizadono diretrio para registro de servios, o cliente poder invocar o mesmo ao provedor

de servios toda vez que desejar us-lo.

2.1.2 Normalizao

A normalizao da plataforma de WSsurge com o principal objetivo de orientar o

desenvolvimento de maneira a manter a interoperabilidade. Um documento publicado pela Web

Services Interoperability Organization(WS-I)1, organizao responsvel pela manuteno da

normalizao da interoperabilidade, abrange uma srie de recomendaes a serem adotadas parao desenvolvimento deWS.

1http://www.ws-i.org,ltimo Acesso em Novembro de 2015
http://www.ws-i.org/http://www.ws-i.org/http://www.ws-i.org/


24/94

2.1. WEB SERVICES 23

A pilha de protocolos dosWSapresentada na Figura2.2abrange normas que suportam a

interao das trs entidades mencionadas. Algumas dessas mais importantes normas deWSso

definidas pelo W3C2 (W3C, 2004).

Figura 2.2:Arquitetura de normas deWSproposta pelo W3C

Fonte:W3C(2004).

A seguir, cada um dos padres XML, SOAP, Web Services Description Language

(WSDL) e Universal Description Discovery and Integration (UDDI) que compem a pilha

bsica de protocolos e tecnologia base dosWSso explicados em detalhes.

2.1.3 eXtensible Markup Language

A XML um formato de texto simples e flexvel, um subconjunto deStandard Gene-

ralized Markup Language3 (SGML). Criado em 1996 e formalizado em 1998, se tornou um

importante padro de troca de dados na Web. O padro de XML registrado pelo W3C.Com o advento do XML, tornou-se simplificada a tarefa de preparar documentos para

troca entre sistemas de diferentes ambientes. A especificao XML contm um conjunto de

regras de sintaxe para descrio de dados que definida por uso de Schemas, norma do W3C, que

contm regras de validao dos elementos e atributos de um documento XML. Outro componente

muito importante so osnamespaces, mantido pela W3C. Osnamespacesdescrevem uma coleo

de nomes, identificados por uma referncia URI, que so usados para definir tipos de elementos e

atributos de um documento XML. O uso de namespacesprevine que documentos XML diferentes

tenham elementos como nomes conflitantes. Assim, pode-se atribuir um prefixo ao namespaces.2https://www.w3.org/,ltimo Acesso em Novembro de 20153https://www.w3.org/MarkUp/SGML/ ,ltimo Acesso em Novembro de 2015
https://www.w3.org/https://www.w3.org/https://www.w3.org/MarkUp/SGML/https://www.w3.org/MarkUp/SGML/https://www.w3.org/MarkUp/SGML/https://www.w3.org/


25/94

24

2.

REFERENCIAL

TERICO

Os componentesschemase namespacesse interagem para suportar suas aplicaes,

permitindo a criao de sistemas que manipulem facilmente informaes entre aplicaes e

validadas de uma maneira mais padronizada.

2.1.4 Simple Object Access Protocol

O protocolo de comunicao SOAP uma linguagem XML para troca de mensagens.

Baseia-se em normas como oXML NamespaceeXML Schema, que permite independncia de

linguagem e que trabalha com diversos sistemas operacionais e sobre protocolos de aplicao j

consolidados, com o HTTP, o File Transfer Protocol(FTP), o Simple Mail Transfer Protocol

(SMTP) e etc. As facilidades providas pelo HTTP e obviamente o que predomina no uso da Web,

tornou-se comum nas implementaes deWS.

O SOAP uma das normas mais importantes dos WS,definida pelo consrcio W3C(W3C, 2007c). A norma SOAP define a estrutura de documentos XML, proporcionando sim-

plicidade e coerncia para que uma aplicao envie mensagens XML para outra, garantindo a

independncia do transporte utilizado.

Uma mensagem SOAP um documento XML. A Figura2.3ilustra a estrutura de uma

mensagem SOAP e, em seguida, ser realizado o estudo dos elementos que constitui sua estrutura:

Figura 2.3:Estrutura de uma mensagem SOAP

Fonte:W3C(2007c) - adaptado.

Envelope SOAP:a mensagem SOAP fornece um envelope (SOAP Envelope) como

elemento raiz, este envelope um container4 que protege os dados XML.Tendo como

principal objetivo no s proteger os dados mas, alm disso, possibilita transmisso

da mensagem SOAP por qualquer protocolo de transporte. O envelope compostopor duas partes: o cabealho (SOAP Header) e o corpo (SOAP Body) da mensagem.

4rea delimitada e protegida destinada para armazenar algo.


26/94

2.1. WEB SERVICES 25

Cabealho SOAP (SOAPHeader): um elemento opcional e o primeiro elemento

filho do envelope. O cabealho da mensagem SOAP contm informaes, divididas

em blocos, podendo conter zero ou mais blocos de cabealhos. Essas informaes

ou diretivas so usadas para gerenciar ou prover segurana, tal como asseres deautorizao e autenticao entre outros.

Corpo SOAP (SOAP Body): um elemento obrigatrio e contm a mensagem

propriamente dita chamada carga til (Payload). O corpo contm os dados de

negcio da mensagem ou qualquer tipo de informao XML. No corpo, tambm

pode estar contido o elementoFault, que tem por objetivo transportar informaes

sobre erros que possam vir a ocorrer no processamento dessas informaes.

2.1.5 Web Services Description Language

AWSDL uma gramtica em XML para definir e especificar as interfaces de um WS.

Essas interfaces contm informaes do tipo, localizao do servio, o que o servio pode fazer

e como poder ser chamado, permitindo assim, a interao do servio.

A WSDL uma linguagem padro usada para descrever as funcionalidades de um

WS,independente de linguagem e plataforma (W3C,2007a). Tem como objetivo descrever os

servios publicados pelos provedores e que, posteriormente, sero acessados pelos clientes.

O WSDL codificado em XMLSchemaque obedece a uma estrutura fixa para especificarinterface de servio. WSDLdescrevem umWS em duas fases fundamentais: um abstrato e

um concreto (W3C,2013). A parte abstrata descreve as capacidades doWS, em termo de

mensagem que este consome e produz. A parte concreta desempenha as mesmas tarefas da

Interface Definition Language(IDL) na CORBA5, prover vnculo da interface, definindo um

contrato concreto para vincular fisicamente o cliente ao WS.Os principais elementosXMLde

um documento WSDL apresentados na Figura2.4so:

definitions:este o elemento raiz a partir do qual os demais so definidos.

types:define os tipos de dados, utilizando o XMLSchema, ao longo do documento

e que sero utilizados entre o servidor e o cliente durante a comunicao. Os tipos de

dados so definidos dentro deste elemento para que sejam posteriormente utilizados

no elementomessage.

message:define, de forma abstrata, as mensagens que sero trocadas, contendo os

parmetros de entrada e sada do servio.

operation: este elemento representa a interao particular com o servio, descre-vendo as mensagens de entrada, sada e excees possveis e permitidas.

5http://www.corba.org,ltimo Acesso em Novembro de 2015
http://www.corba.org/http://www.corba.org/http://www.corba.org/


27/94

26

2.

REFERENCIAL

TERICO

Figura 2.4:Estrutura de um documento WSDL

Fonte:W3C(2007a) - adaptado.

portType:descreve um conjunto abstrato de operaes mapeadas para suportar um

ou mais servios. A cada operao, esto associados um pedido e uma resposta.

binding:este elemento especifica a ligao de cada elementos abstrato, operaes,

mensagens e tipos de dados, com protocolo de rede que sero utilizados para trans-

portar os elementos at o destino.

port:associa o elementobindinge o endereo de rede para prover assim um endereo

nico para acessar um servio.

service:descreve onde o servio est disponvel ou publicado, associando entre o

elemento bindinge o endereo de rede onde o servio pode ser encontrado, possuindo

assim um conjunto deportassociados.

2.1.6 Universal Description, Discovery and IntegrationO UDDI permite queWSdisponveis na Internet sejam facilmente encontrados, provendo

uma interface para utilizao do cliente. Trata-se de um protocolo para registrar, publicar e

descobrirWSnum ambiente distribudo (OASIS,2004).

Os dados e metadados dos WSso registrados e armazenados em diretrios UDDI

registry. Associando a cada estrutura de dados um identificador nico, chamado UDDI key,

cada empresa ou organizao, cria suas prprias regras de classificao. A importncia de

cada empresa possuir sua classificao permite que clientes realizem consultas mais refinadas,

escolhendo o servio que melhor lhe atende.Os diretrios UDDI no armazenam informaes relativas implementao de umWS,

como a WSDL do servio. Este tambm contm informaes relativas empresa responsvel


28/94

2.2. WEB SERVICES SECURITY 27

que prover o servio. A disponibilidade dos servios dos WSatravs de UDDI no obrigatria

(OASIS,2004).

No domnio de informao da UDDI, existem trs tipos de informao que podem ser

consagrados no registro UDDI:

Pginas Amarelas:aqui, so includos dados gerais como a entidade fornecedora

ou os servios oferecidos. Assim, estes dados so classificados como categorias (i.e.

pas de origem, a indstria, o produto, entre outros). A pesquisa umWeb Service,

neste contexto, feita com base nas categorias.

Pginas Brancas:onde, so includas informaes bsicas de contatos que permite

pesquisar umWeb Servicecom base em dados atrelados entidade fornecedora do

WS. Essas informaes so constitudas (i.e. nome de um negcio, descrio donegcio, informao de contato, endereo, fax, ou mesmo incluir identificadores de

negcios).

Pginas Verdes:contm um conjunto de informaes tcnicas sobre umWS,desta

forma o programador ao ter acesso a essas informaes poder desenvolver sua

aplicao que utilize aoWSem questo.

2.2 Web Services SecurityAWeb Service SecurityouWS-Security(WSS) suporta, integra e unifica vrios modelos,

mecanismos e tecnologias de segurana, oferecendo mecanismos padro de segurana necessrios

para realizar o intercmbio seguro de mensagens certificadas em um ambiente de WS.

As especificaes de segurana definem um conjunto de padres para extenses de

cabealhos de mensagens SOAP, utilizados para oferecer integridade, confidencialidade e au-

tenticidade. Essas especificaes atendem esses trs requisitos de segurana atravs do uso da

Assinatura XML (XMLSignature), da Criptografia XML (XMLEncryption) e da Autenticao

e Autorizao XML (SAML) (OASIS,2012a).

2.2.1 Arquitetura

A arquitetura do padro WSS construda sob a mensagem SOAP,definindo um esquema

XML,que possibilita incluir de forma padronizada as informaes relacionadas cifragem dos

dados e assinaturas digitais da mensagemSOAPpara construo deWSseguros, fazendo uso

das especificaes a XMLDigital Signaturee aXMLEncryption.

A seguir, aXMLapresenta uma mensagemSOAPque usa segurana baseada emtokens,

assinaturas digitais e criptografia:


29/94

28 2.

REFERENCIAL

TERICO


30/94


Conforme descrito nos comentrios, a XML, apresentou a estrutura do padro WSS

fazendo uso de algumas especificaes de segurana que sero abordadas nos prximos tpicos

desta Subsees.

2.2.2 XML Digital Signature

SegundoW3C(2008): O uso de assinaturas digitais6 uma forma de garantir as

propriedades de integridade e autenticidade de informaes digitais. O XMLDigital Signature

um padro aberto controlado pela OASIS7,proposta conjunta entre W3C eInternet Engineering

Task Force(IETF)8, define regras para gerar e validar assinaturas digitais expressa em XML.

O XMLDigital Signature um conjunto detagsXML. Essastagstm a funo de conter

informaes suficientes para permitir que um cliente seja verificado usando o par de chavespblica/privada. O uso do padro XML Digital Signatureno est estritamente voltado para

assinar documentos XML. Tambm, possvel assinar qualquer tipo de documento eletrnico

do tipo de arquivos binrio ou textos, desta forma, a assinatura ser representada atravs de um

documento XML.

Uma caracterstica fundamental da assinatura em documentos XML a habilidade de

assinar somente partes especficas da rvore do documento XML. Dessa forma, permite que

outras partes desse documento sofram modificaes sem que isso invalide a parte assinada,

permitindo compor assinaturas de modo que diferentes assinaturas sejam aplicadas a diferentespartes do documento. Isso importante porque algumas mensagens SOAP obtm informaes

adicionais no seu ciclo de vida. Esta flexibilidade permite garantir a integridade de certas partes

de um documento XML. O contedo abaixo apresenta um trecho de documento XML que mostra

um exemplo de XMLDigital Signature:

6Conjunto de instrues matemticas baseadas na criptografia, que permite conferir autenticidade, privacidade einviolabilidade aos documentos digitais e transaes comerciais efetuadas pela Internet.

7https://www.oasis-open.org/ , ltimo Acesso em Novembro de 20158https://www.ietf.org/,ltimo Acesso em Novembro de 2015
https://www.oasis-open.org/https://www.ietf.org/https://www.ietf.org/https://www.ietf.org/https://www.oasis-open.org/


31/94

30

2.

REFERENCIAL

TERICO

SegundoW3C(2013), a informao assinada aparece dentro do elemento.

O algoritmo usado no clculo do elemento mencionado dentro da seo

assinada e contem o valor da assinatura digital, sempre codificada usando base64. O elemento

especifica o algoritmo usado para converter o SignedInfocanonizado noSignatureValue. Esta uma combinao de um algoritmo que depende da chave e de um

algoritmo de resumo, neste caso, DSA e SHA-1. O elementoindica a chave que

usada para validar a assinatura.

O padroCanonicalXML9 uma especificao que descreve um processo de herana

de atributosXML namespace, definindo meios para representar documentos na forma cannica

(W3C, 2008). O interpretador XML expressa que o elemento
e o
elemento
so equivalentes. Porm, ao criar uma assinatura expressa
em XML referentes aos elementos citados, aplica-se um algoritmo gerando duas assinaturas

distintas.

Assim, documentos XML, que sejam sintaticamente diferentes, porm com lgicas

equivalentes, permitem serem representados por uma mesma forma cannica. Isso importante

porque, possibilita que os documentos XML possam ser assinados sem que haja preocupao

com a sintaxe dos mesmos.

Existem trs formas diferentes de representar as assinaturas conforme apresentado na

Figura2.5:

Figura 2.5:Formas de assinatura XMLDigital Signature

Fonte:W3C(2008) - adaptado.

enveloped:a assinatura encontra-se dentro do documento XML que contm os dados,

assinando pores ou todo o documento. ideal para ser utilizada com Servios

Web, inserida em mensagens SOAP;

enveloping:a assinatura encapsula os dados assinados, ou seja, contido dentro da

prpria estrutura da assinatura.

detached signature: a assinatura aplicada aos dados externos ao elemento ondese encontra a assinatura, portanto a assinatura fica separada dos dados assinados.

9https://www.w3.org/TR/xml-c14n ,ltimo acesso em Janeiro de 2015
https://www.w3.org/TR/xml-c14nhttps://www.w3.org/TR/xml-c14nhttps://www.w3.org/TR/xml-c14n


32/94


Geralmente estes dados encontram-se na Web. ideal para assinar documentos que

sofrem constantes modificaes.

2.2.3

XML

Encryption

OpadroXMLEncryptionprovseguranafim-a-fimparaaplicaesquenecessitam

realizartrocasdedadosdeformasegura(W3C,2013).Aseguranaprovidadopadrooferece

umnveldeprivacidadeporcifrarosdadosevitandoqueterceirosvejamseucontedo,desta

forma,acriptografiaemXMLfornecefuncionalidadescomplementaresparaassinaturaXML

(XMLSignature)epermitecriptografarumdocumentoXMLcompleto,partesselecionadasde

umdocumentoXMLoucontedoreferenciadoporumdocumentoXML.

De

acordo

com

Si

ngh

(201

0),

"A

codificao

o

nico

meio

de

proteger

nossa

privaci-dadeegarantirosucessodomercadodigital".

Segundo Potts (2003) esclarece: A maneira mais simples, embora mais til, de

protegersuamensagemdeWSusaroSecuritySocketLayer(SSL)..

OSSLumprotocoloproprietriodaNetscapeCommunicationeoTransportLayer

Security(TLS)adefinioRFC2246dopadrodaIETF.Osdoisprotocolossosemelhantes,

masoTLSpossuialgunsaprimoramentos importantes. OsTLS/SSLsousadoscommais

frequnciaparaoferecerproteoeintegridadedosdadossobreoprotocoloHTTP.

OsprotocolosTLS/SSLpossuemalgumaslimitaesemumambientedeWS. Esses

protocolos,porsis,nopodemfornecerautenticao,integridadededadosduranteaexistncia

damensagemseelaforroteadaatravsdemaisdeumWS.AespecializaoXMLEncryption

no

pretende

substituir

TLS/SSL,

mas

garante

confidencialidade

persistente,

garantindo

assim

confidencialidadedosdadosdepoisdotrminodasesso.Almdisso,provummecanismode

seguranaquenocobertopeloTLS/SSL,comoapossibilidadedecifrarsomentepartedeum

dadoeoestabelecimentodesessessegurasentremaisdeduaspartes.

EmumambientedeWS,importantequeosdadoscifradossejamrepresentadosdeuma

formaestruturadaquepermitemousodediferenteschavesparacifrarpartedodocumento,desta

forma,

o

mesmo

documento

seja

trocado

entre

diversas

partes,

sem

que

ocorra

a

revelao

de

informaoparapartesnoautorizadasegarantamoacessoinformao,porpartesautorizadas.

AXMLaseguirapresenta,demaneirabreve,aestruturadasintaxeparaacriptografia

XML.Ospontosdeinterrogaonocdigoaseguirsosubstitudosporentradasefetivas:

Segundo

W3C

(2013),

o

elemento

est

na

primeira

parte

da

sintaxe

da criptografiaX MLqu e,co moo elemento, usadapa ratransportaras

chavesdecriptografia,dooriginadoratumreceptorconhecido,ederivadadotipoabstrato

. Osdadosaseremcriptografadospodemserqualquerumdosseguintes,

resultados

em

um

elemento

de

criptografia

X ML

q ue

contenha,

o u

faa

referncia,

o s

dados

cifrados: dadosarbitrrios,oelementopodetornar-searaizdeumnovo

documentoXML,ouumelemento-filho;documentoXML,oelementopode


33/94

32

2.

REFERENCIAL

TERICO

torna-se a raiz de um novo documento; elemento XML, o elementosubstitui o

elemento ou contedo na verso criptografada do documento XML; contedo do elemento XML;

o elementosubstitui o elemento ou o contedo na verso criptografada dodocumento XML. O contedo abaixo apresenta um exemplo de documento XML sem criptografia

dos dados:

O documento XML mostrado acima, refere-se a informaes de uma conta de um sistema

bancrio, informando os elementos: Nome, Numero, Limite e Senhado cliente responsvel. O

contedo apresenta um exemplo do documento anterior usando o padro XML Encryption:

Ainda no documentoXML,podemos observar que todos os dados exceto o elemento

Nome foram criptografados. As informaes extremamente importantes, como os elementos

Numero, Limite e Senha so apresentados de forma criptografadas e colocadas entre as tags

, preservando a informao confidencial.

OWSSfornece estrutura para uma segurana completa e flexvel s necessidades indivi-

duais. Para tanto, essa tecnologia prope um conjunto de extenses de cabealhoSOAP, que,uma vez utilizados, podero conterXMLpara os padres j analisados anteriormente (XML

Signature, XMLEncryption), bem como para os padres que surgiro no futuro (POTTS,2003).


34/94

2.3. SECURITY ASSERTION MARKUP LANGUAGE 33

2.3 Security Assertion Markup Language

SegundoOASIS(2008)apudMelloetal.(2006),oframework10 SAML:

consiste de um conjunto de especificaes e esquemas XML, que juntos definem

uma forma padro para criar, trocar e interpretar asseres de segurana entre

entidades de uma aplicao distribuda. No caso, so definidos meios para

expressar, em XML, informaes sobre autenticao, autorizao e atributos

de um sujeito, porm as especificaes da SAML no definem uma nova

tecnologia ou forma para autenticao, mas sim uma tecnologia que visa garantir

a interoperabilidade entre os diferentes sistemas de autenticao11

.

OpropsitotecnolgicoSAMLdadaemOASIS(2008):... definir,melhorar,eman-

terumframeworkpadrobaseadoemXMLparacriaoetrocasinformaesdeautenticao

e

autorizao.

SegundoMelloetal.(2006):Umaasserodeseguranaumconjuntodeafirma-

es,concedidasporumemissorSAML,sobredeterminadasinformaesdeumprincipal.

2.3.1 AAnatomiadaSAML

So definidos trs tipos de asseres da especificao SAML:

Autenticao:fornecida pelo emissor SAML aps a declarao de autenticao com

sucesso do usurio, que afirma que o emissor foi autenticado por um determinado

meio em um determinado momento;

Atributo:uma afirmao contm detalhes especficos sobre uma declarao feita

pelo emissor, que, assim especifica estar associado ao(s) atributo(s) especfico(s) para

determinar o papel que ir desempenhar dentro do sistema;

Autorizao:que indica os direitos que um emissor possui sobe um determinado

recurso em questo, sendo que esta declarao de asseres afirma que a requisio

de acesso pode levar com base as asseres de autenticao e de atributos.

A seguir, os documentos em XML apresentam a estrutura das asseres SAML para

autenticao, atributos e autorizao respectivamente:

10Conjunto de funcionalidades comuns para um determinado domnio de aplicaes.11A especificao da SAML prev o uso de diferentes mecanismos para a autenticao: usurio e senha, Kerberos,

Secure Remote Password, certificados TLS/SSL, chave pblica (X.509, SPKI, XKMS), XML Digital Signature eainda, possibilita o uso de mecanismos no definidos na especificao.


35/94

34

2.

REFERENCIAL

TERICO

Conforme exemplificado nos comentrios descritos, o documento XML, apresentou a

estrutura bsica da assero SAML de autenticao.

No segundo exemplo, a XML comentada, apresentou a estrutura bsica da assero

SAML de atributos.


36/94

2.3. SECURITY ASSERTION MARKUP LANGUAGE 35

AXML,comentada acima, exemplifica que a assero de autorizao contida no docu-

mento que afirma que o [email protected] autorizado a consultar a pgina

http://www.cindacta3.aer.mil.br/index.html e que pode submeter o formulrio http://www.cindacta

3.aer.mil.br/cadastrar. As afirmaes foram concebidas pelos atributosDecisiondo elemento

AuthorizationDecisionStatementinformandoDenypara negao,Permitpara permisso eInde-

treminatepara indeterminao.

Mesmo prevendo o uso de autoridades responsveis pela emisso dessas asseres, o

modelo de uso SAML no as menciona. No entanto, as especificaes ditam os protocolos que

visam interao com essas autoridades (OASIS,2008).

Portanto, verifica-se que o TLS/SSL tem capacidade de garantir a segurana necessria

para chamadas de WS simples e nohierrquicas. A SAML por sua vez, sobrepe-se ao

TLS/SSL, pois, apresenta em suas funcionalidades um protocolo de gerao de mensagens

baseado em SOAP com dados estruturados em XML, desta maneira capacitando uma empresa a

dar testemunho dos direitos de identidade, autenticao e atualizao de usurios humanos e de

programa (POTTS,2003).

Vimos que o SAML permite que domnios da web seguros troquem a autenticao de

usurio e os dados de autorizao. Quando um provedor de servios usa a SAML, ele podeentrar em contato com um provedor de identidade separado para autenticar usurios que estejam

tentando acessar um contedo seguro.


37/94

36

2.

REFERENCIAL

TERICO

2.4 Web Services Policy

AWSP uma linguagem para definir polticas de servios, oferecendo uma gramtica

flexvel e extensvel que permite definir como os recursos e restries das normas de seguranapodero ser expressos para o ambiente deWS.

2.4.1 Polticas para Web Services

AWSDL,apresentado na Subseo2.1.5, fornece um mecanismo para descrever as

funcionalidades presente em umWS. Isso permite aos provedores de servios descreverem quais

so os servios oferecidos, quais as informaes so necessrias para processar as requisies e

informando em quais formatos o servio deve enviar os dados para um cliente.AWSDLtem como objetivo a descrio das propriedades funcionais de um servio. No

entanto, se faz necessrio, tambm, a descrio dos requisitos no funcionais de um servio.

Esses requisitos, dentre outras caractersticas, podem estar relacionados com a segurana em

que o servio possa prover ou exigir. Desta forma, pode-se determinar qual servio escolher,

relacionado a um servio que apresente uma poltica de privacidade bem definida ou qualquer

outro mecanismo de segurana.

A criao de uma poltica para anexar informaes necessrias para definir requisitos

adicionais (que deve ser cumpridos pelo cliente e pelo prestador do servio para que a interaoentre ambos possa acontecer) que tornam necessrio o surgimento de uma tecnologiaWSP,com

objetivo de prover um modelo de propsito geral para descrio de polticas.

As polticas de segurana so representadas atravs de documentosXML,cujo elemento

raiz do documento o elementoPolicy. Dentro deste elemento, so representadas colees de

asseres (ou assertivas), que quando combinadas representam uma coleo vlida de alternativas

de polticas. As asseres so combinadas atravs de dois tipos de operadores de polticas:

ExactlyOneindica que somente uma das asseres contidas na poltica poder fazer parte de uma

alternativa de poltica;Allpermite a combinao de todas as asseres apresentadas como uma

alternativa de poltica (W3C,2007b).

A seguir, aXMLapresenta a estrutura simplificada para expressar polticas da especiali-

zaoWSP:

A especificaoWSP demasiada abstrata, expressa as capacidades, requisitos e ca-ractersticas gerais de entidades em umWSbaseado emXML.Desta forma, mantendo o foco

desse trabalho nas normas de segurana em nvel de segurana de servio e de mensagem, com


38/94

2.4. WEB SERVICES POLICY 37

nfase na implementao especializada doWSPchamada deWeb Services SecurityPolicyou

WS-SecurityPolicy(WSSP) que est atrelada aoWSS.

2.4.2 Web Services SecurityPolicy

AWSSP uma especializao daWSPpara definir polticas de segurana que descreve

como mensagens devem ser protegidas. A poltica pode aplicar-se a mensagens individuais, a

operaes ou a toda a extremidade do servio. As asseres (ou assertivas)WSSPreferem-se s

funcionalidades de segurana deWSS,WS-Trust12 e WS-SecureConversation13.Podem tambm

referir segurana no transporte, como no protocolo HTTP (OASIS,2012c).

A especializaoWSSPprov flexibilidade nas asseres com respeito a tipos de token,

algoritmos de criptografia e mecanismos usados, incluindo o uso de segurana em nvel de

transporte. Assim, permite que as mensagens requisitadas evoluam ao longo do tempo (OASIS,

2012c). Por exemplo, uma poltica pode especificar que a mensagem seja assinada com uma

chave de certificado digital X.509 e outra pode ditar que a autenticao seja feita com a chave de

um bilheteKerberos.

AXMLa seguir, apresenta a estrutura daWSSPde um servio:

12http://goo.gl/RHX5SJ,ltimo Acesso em Novembro de 201513http://goo.gl/ULrS1L,ltimo acesso em Novembro 2015
http://goo.gl/RHX5SJhttp://goo.gl/RHX5SJhttp://goo.gl/ULrS1Lhttp://goo.gl/ULrS1Lhttp://goo.gl/ULrS1Lhttp://goo.gl/RHX5SJ


39/94

38

2.

REFERENCIAL

TERICO

AXMLapresentou a existncia de duas sees principais na definio da poltica: o

vnculo de segurana e a proteo. A seo da poltica que define o vnculo de segurana

referente criptografia declarada nos elementos: criptografia simtrica ,

criptografia assimtricae segurana no transporte .Assim, o uso de criptografia de segurana pode ser utilizado para adicionar tokensde segurana

em cada vnculo de segurana, permitindo a transferncia de chave e estrutura dos cabealhos

de segurana. Outra seo importante para a definio dos vnculos de segurana a assero

SymmetricBinding. Essa assero permite a conexo segura entre o emissor e o receptor com

WSS, baseado em criptografia simtrica. Os tokensde segurana adicionados permitem ter

combinaes mutuamente exclusivas, tal como:

EncryptionToken(cifra) e SignatureToken(assinatura);

ProtectionToken(cifra e assinatura em simultneo).

As requisies que compem as mensagens de resposta assumem as mesmas indicaes

de segurana definido da mensagem submetida. Uma seo de segurana contm sub-asseres

que so um conjunto de afirmaes, concedidas por um emissor, sobre determinadas informa-

es. Algumas sub-assero disponveis para detalhar a configurao so: Layout(ordenao

dos elementos de segurana), IncludeTimestamp(incluir marca temporal na mensagem), En-

cryptSignature (cifrar assinatura),EncryptBeforeSign(cifrar antes de assinar),AlgorithmSuite

(algoritmos criptogrficos a utilizar),ProtectTokens(includostokensde segurana na assinatura)e OnlySignEntireHeadersAndBody(assinar apenas corpo e cabealhos que no os de segurana).

As asseresAsymmetricBindingeTransportBindingpermitem garantir segurana no

transporte das mensagens com base noWSS. AAsymmetricBindinggarante atravs de criptografia

simtrica entre o emissor e o receptor e a TransportBindinggarante a correlao de segurana

por meios externos.

As asseres de tokensde segurana possuem propriedades que permitem identificar

quais so os tokensaceitos e qual o processamento de ser realizado. Desta forma, os tokens

assero podem ser: HttpsToken,UsernameToken,X509Token,KerberosToken,SamlToken. Porexemplo, o token X509Tokenespecificar que a mensagem seja assinada com uma chave de

certificado digital X.509. Podemos destacar, ainda, o tokenTokenInlusion, que indica como os

tokensde segurana devem ser usados. Segue a propriedade de processamento do token:

Never: o tokennunca pode ser transportado em mensagens, podendo apenas ser

referenciado;

Once:otokendeve ser transportado uma vez na primeira mensagem, mas depois

no mais. Esta opo usada para iniciar sesses seguras;

AlwaysToRecipient: o tokendeve ser enviado sempre que o emissor enviar uma

mensagem para o receptor. O mesmo j no deve acontecer na resposta;


40/94

2.5. COMPUTAO EM NUVEM 39

AlwaysToInitiator: o tokendeve ser enviado sempre que o receptor enviar uma

mensagem para o emissor. O mesmo j no deve acontecer na solicitao;

Always:o tokendeve ser sempre enviado nas mensagens. Podemos destacar a seo

da poltica que tem como objetivo definir a proteo:

Destacamos a especializao do WSP, a WSSP. Essa especializao segue alguns prop-

sitos que podemos destacar: informaes suficientes para que participantes possam determinar

compatibilidade e interoperabilidade; e informaes necessrias para que uma entidade possa

participar em uma troca segura de mensagensSOAP.

2.5 Computao em Nuvem

De acordo com a definio do National Institute of Standards and Technology(NIST)

assume que A computao em nuvem um modelo para habilitar o acesso por rede ubquo,

conveniente e sob demanda a um conjunto compartilhado de recursos de computao que possam

ser rapidamente provisionados e liberados com o mnimo de esforo de gerenciamento ou

interao com o provedor de servios (MELL; GRANCE,2011).

Os grandes provedores de CN expe um conjunto de Application Programming Inter-

face(API) para interagir e gerenciar com os servios oferecidos. EssasAPIs so definidas e

especificadas pelas interfaces de umWS,como na WSDL descrita na Subseo2.1.5.Indepen-dentemente dos propsitos de projetos de cada um, a abordagem de CN pode se relacionar com

a arquitetura SOA, atravs de padres paraWS, na utilizao de componentes como um servio -

Components as a Service(CaaS).

A Figura2.6utilizao do diagrama deVenn14 para ilustrar a relao entreWS,SOAe

CN.

Figura 2.6:Relacionamento de Web Services, SOA e Computao em Nuvem

Fonte:

Barry e Dick

(2013)

-

adaptado.14Diagramas

usados

em

matemtica

para

simbolizar

graficamente

propriedades,

axiomas

e

problemas

relativos

aos

conjuntos

e

sua

teoria.


41/94

40

2.

REFERENCIAL

TERICO

O diagrama ilustrado acima, enfatiza aCNinserida dentro do conjunto deWSutilizando

SOApara indicar que aCNusa os servios deWS,no entanto, aCNpode ser utilizada sem o

modeloSOAeWS. Nas prximas Subsees sero apresentados, de maneira sucinta e objetiva,

os modelos de servio e de implantao. Dentre os aspectos as ameaas sero explanadas comum pouco mais detalhes, visto que este o aspecto de mais interesse desta pesquisa.

2.5.1 Modelos de Servio

De acordo com o modelo de disponibilizao de servios oferecidos pelos provedores da

computao em nuvem, as nuvens computacionais podem ser classificadas da seguinte forma:

Software como Servio(Software as a Service- SaaS): Servios de softwaresde

propsito especfico disponibilizado por meio de interfaces como um navegador deinternet. As aplicaes em nuvens so multi-inquilinos, ou seja, so utilizadas por

diversos clientes simultaneamente.

Plataforma como Servio(Platform as a Service- PaaS): Neste modelo o provedor

fornece servios para ambiente para programao, sem a necessidade de instalar

ferramentas de desenvolvimento locais. O usurio possui o controle dessas ferramen-

tas de gerenciamento de configurao, implantao e execuo de aplicaes nesta

infraestrutura.

Infraestrutura como Servio(Infrastructure as a Service - IaaS): O servio IaaS

fornece umaAPIde gerenciamento para utilizao dos recursos de infraestrutura

computacional bsica (capacidade de armazenamento e processamento).

2.5.2 Modelos de Implantao

DeacordocomMell eGrance(2011),hquatromodelosdeimplantao:

Nuvem Comunitria: Uma nuvem de comunidade compartilha a infraestruturaentre diversas organizaes com interesses em comum (e.g. segurana, conformidade

ou jurisdio);

Nuvem Pblica: Com uma nuvem pblica, a infraestrutura da nuvem de uso

aberto por qualquer tipo de cliente. Pode ser gerenciada, operada e pertencer a uma

empresa comercial, acadmica ou governamental, ou uma combinao desses tipos

de organizaes;

Nuvem Privada:Em uma nuvem privada, a infraestrutura gerenciada e operadaexclusiva por uma organizao, podendo ser administrada pela prpria organizao

ou por um terceiro;


42/94


43/94

42

2.

REFERENCIAL

TERICO

(GoogleDrive15,SugarSync16,iCloud17,Box18 eDropbox19),taiscomoabusoscomrelao

privacidade,vazamentoouperdadedados,violaodedireitosautorais,falhasnasincronizao

dearquivos,dentreoutros.

ConformebemcolocadopelorelatriodaFixya(2012),aperdadedadospreocupantetantoparaconsumidoresquantoparaprovedores. Aperdadedadospodeserenquadradaem

doistiposdeperda:acidentaiseintencionais.Aacidental,comooprprionomesugere,ocorre

quando

um

usurio

ou

uma

aplicao

apaga,

sobrescreve,

altera

os

dados

acidentalmente,

sem

aintenodeprejudicaroproprietriodasinformaes.Eporfim,aperdadedadosdeforma

intencionald-sequandotambmumusurioeumaaplicaoapaga,sobrescreve,alteraos

dadosdeformaproposital,motivadoparacausaralgumtipodedanoaodetentor,comprometendo

principalmenteaintegridadedainformao.

2.5.3.3 SequestrodeContasoudeTrfegodeServios

Oataquedesequestrodecontasoudetrfegodeserviossubiudasextaposioem2010

paraocuparaterceiraposionorankingdeameaasdeCNem2013,segundoorelatrioda

CSA(2013).Osmtodosdeataquescomophishing,fraudeeexploraodevulnerabilidadesde

softwaresnosomaisconsideradosumanovaprtica,masaindaalcanaresultadoseacabam

porserempotencializadoscomoousodosambientesemnuvem.Istoocorreporquesoprovidos

milharesdecontasdeservio,permitindoassimcomqueusuriosmalintencionadostenhamum

ponto

centralizado

para

explorar

(BERTINO

et

al.,

2010).Uma vez que o atacante captura as credenciais de acesso de uma conta, o mesmo

podemonitorarsuasatividades, transaes, manipulardados, retornar informaes falsase

redirecionarparaoutrosusurios,oqueamplificaoimpactodetaisataques.Emconsequncia

docomprometimentodeumacontadeserviodoambientedanuvem,podeservircomumanova

baseparadiferentestiposdeataques,comoovazamentodedadosdeoutrascontasdeservio

queestejamnamesmanuvem(CSA,2013).

Emabrilde2010, o botZeus20, cavalode troiaquerouba informaesdamquina

infectada,

foi

encontrado

no

ambiente

de

nuvem

da

empresa

AWS21

sequestrando

enumerascontasdoprovedor.Em2013,oDropbox,umdosprincipaisprovedoresdomercado,foiapontado

comproblemasdesegurana,alvodessetipodevulnerabilidade(ZORZ,2013).Pesquisadores

demonstraramummtododeinterceptarotrfegoSSL,apartirdosoftwareclienteDropboxque

instaladolocalmente,burlandoomecanismodeautenticaodedoispassosesequestrando

contasdoprovedor.

15https://www.google.com/intl/pt-BR/drive/ ,ltimo acesso em Novembro 201516https://www.sugarsync.com/ ,ltimo acesso em Novembro 201517https://www.icloud.com/ ,ltimo acesso em Novembro 2015

18https://www.box.com/,ltimo acesso em Novembro 201519https://www.dropbox.com/ ,ltimo acesso em Novembro 201520https://goo.gl/Yg2Yzd,ltimo Acesso em Novembro de 201521https://aws.amazon.com/pt/ ,ltimo Acesso em Novembro de 2015
https://www.google.com/intl/pt-BR/drive/https://www.google.com/intl/pt-BR/drive/https://www.sugarsync.com/https://www.sugarsync.com/https://www.icloud.com/https://www.icloud.com/https://www.box.com/https://www.box.com/https://www.dropbox.com/https://www.dropbox.com/https://goo.gl/Yg2Yzdhttps://goo.gl/Yg2Yzdhttps://aws.amazon.com/pt/https://aws.amazon.com/pt/https://aws.amazon.com/pt/https://goo.gl/Yg2Yzdhttps://www.dropbox.com/https://www.box.com/https://www.icloud.com/https://www.sugarsync.com/https://www.google.com/intl/pt-BR/drive/


44/94

2.5. COMPUTAO EM NUVEM 43

Segundo o estudo realizado pela empresa de segurana Imperva22,realizado em 2015

e disponibilizado atravs de um relatrio23,identificou uma nova modalidade de ataque, este

denominado comoMan in the Cloud(MITC). Essa vulnerabilidade foi identificada nos seguintes

provedores:Google Drive,Dropbox,OneDrive24

eBox. Segundo o relatrio, no foi utilizadonenhuma ferramenta de explorao ou qualquer cdigo malicioso na fase inicial da "infeco",

tornando assim, muito difcil evitar este tipo de ataque. Os atacantes podem comprometer

o servio de sincronizao de arquivos na nuvem apenas roubando um tokensem que seja

necessrio comprometer a senha da vtima.

2.5.3.4 InterfacesInseguras

AameaadeInterfacesInsegurasdesceudasegundaposioem2010paraocupara

quarta

posio

em

2013

no

Top

Threat

Ranking

(CSA,

2013).

Diversos

provedores

de

nuvem

disponibilizam um conjunto de APIs para que seus clientes as utilizem de modo a agregar

valoraoseusservios. EssasAPIsdoflexibilidadesparainteragiregerenciarcomservios

em

nuvem

(e.g.

gerenciamento,

orquestrao,

provisionamento,

monitoramento

etc.),

porm

a

disponibilidadedessesserviosdependedequoprotegidasestoessasAPIs.

Oconsumoindevidodessasinterfacesporacessoannimo,tokensousenhareutilizveis,

autenticaodetextonocriptografado,controlesdeacessoinflexveisouautorizaesindevidas,

entre

outros

aspectos

que

so

negligenciados,

oferecem

um

dos

grandes

riscos

da

computao

em

nuvem

privada

(IBM,

2010).

Segundo

o

estudo

realizado

por

Wang et al.

(2012),relataramfalhaspreocupantesnaimplementaodasAPIdomecanismodeautenticaoSingle-

Sign On (SSO) prestados pelas empresas como a Google ID, Facebook, PayPal e outros

serviosdaWeb. Essasfalhaspermitequeoatacanteacessemascontasdasvtimasqueutilizam

os

servios

de

SSO,

mesmo

sem

saber

a

suas

credenciais

de

acesso.

ApesquisarealizadaporLuetal.(2013),apresentaramumestudosdasprincipaisfalhas

AmazonEC2API,onde60%dasfalhassochamadasquenoresponde,19%defalhasde

contedodemensagensdeerro,faltadedados,contedoerradoecontedonoesperado,12%

sofalhasporrespostasdemoradase9%relacionadasaerrosgenricos.Identificou-sequeuma

das

principais

causas

dessas

falhas

so

as

falhas

de

interaes

entre

os

sistemas.

2.5.3.5

Negao

de

Servio

UmataquedeNegaodeServio,oudoinglsDenialofService(DoS)Attack,uma

tentativadetornarosrecursosdeumsistemaindisponveloumesmoresponderdeformalenta

paraosseususurios.Nosetratadeumainvasooucoletadeinformaesdosistema,massim

destinadoaimpedirqueosusurios,deumserviodenuvem,sejamincapazesdeacessarseus

dadosousuasaplicaes.

22http://www.imperva.com/,ltimo Acesso em Novembro de 201523http://goo.gl/KPD2Pc,ltimo Acesso em Novembro de 201524https://goo.gl/F66SFu,ltimo acesso em Novembro 2015
http://www.imperva.com/http://www.imperva.com/http://goo.gl/KPD2Pchttp://goo.gl/KPD2Pchttps://goo.gl/F66SFuhttps://goo.gl/F66SFuhttps://goo.gl/F66SFuhttp://goo.gl/KPD2Pchttp://www.imperva.com/


45/94

44

2.

REFERENCIAL

TERICO

O atacante de DoS - ou atacantes, como o caso deDistributedDenial-of-service

(DDoS)-exauriosrecursosdisponveisporsobrecargadeduasformas:Esgotamentoderecurso

comomemriaeprocessamentososobrecarregadosatravsdeinmerosprocessoscriadose

executados,efetuandotravamentoseerros.Asegundaformaoconsumodalarguradebandaderede,poisumavezsobrecarregadaaaplicaoterumacessomuitolentoouatmesmoperda

deacesso.

SegundoaCSA(2013),esteataqueganhouclassificaoparaquintaposiodoTop

ThreatRankingeaumentamamedidaemquemaissistemasestodisponveisonline. Conforme

expostoporHolgersson e Soderstrom(2005),existemdiversos tiposdeataquescomamesma

finalidadedecomprometeradisponibilidadedosserviosprestados.

2.6

Consideraes

FinaisNesta parte, foram descritas algumas das mais importantes normas que constitui a

arquiteturadosWS.AextensoWSSesuastecnologiasdesegurana,tambmforamdescritas,

bemcomoparaospadresquesurgironofuturo(POTTS,2003).Apresentadoaespecificao

SAMLquepermitequedomniosdawebsegurostroquemaautenticaodeusurioeosdados

deautorizao.

TambmdescritoaestruturadoWSP,aWSSP.Essaespecializaoseguealgunsprop-

sitosquepodemosdestacar:informaessuficientesparaqueparticipantespossamdeterminar

compatibilidadeeinteroperabilidade;einformaesnecessriasparaqueumaentidadepossa

participaremumatrocasegurademensagensSOAP. Porfim,umaexplanaogeralsobre

computaoemnuvemfoirealizada,destacandoasameaasmaissignificativasdesegurana.

A prxima parte ira apresentar os principais trabalhos relacionados ao tema desta disser-

tao.


46/94

454545

3Trabalhos RelacionadosParaapresentedissertao,noforamencontradostrabalhosdiretamenterelacionados,

massimestudosqueabordam:1)

anlisedeseguranaparaWS

eCN;2)

utilizaodetestesde

segurana;3)propostadearquiteturadesegurana. Almdisso,aTabela3.1elencademaneira

sumarizadaos trabalhos relacionados eavalia-osdeacordocom assoluespropostas para

assegurarqueasameaas,descritasnaSeo2.5.3,sejamreduzidasaumnvelaceitvel.

Tabela3.1:Comparativoentreassoluesdostrabalhosrelacionadosparamitigaodasameaas

Legenda

X

=

Mitiga

completamente;

O

=

Mitiga

Parcialmente;

Vazamento

de Dados

Perda

de Dados

Sequestro

de Contas

In

uma arquitetura de referência guiada à conformidades de segurança para web services baseados em...

Documents