Uma Arquitetura de Referência Guiada À Conformidades de Segurança para Web Services Baseados em Nuvem Privada

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

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE
2016
UMA ARQUITETURA DE REFERNCIA GUIADA A

CONFORMIDADES DE SEGURANA PARA WEB SERVICES
BASEADOS EM NUVEM PRIVADA
Trabalho apresentado ao Programa de do da Universidade Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.
Orientador: Vinicius Cardoso Garcia
RECIFE
2016
Catalogao na fonte
Bibliotecria Monick Raquel Silvestre da S. Portes, CRB4-1217
M528a
Melo, Ricardo Marinho de

Uma 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. Sistemas
distribudos. 4. Reuso de software. I. Garcia, Vinicius Cardoso (orientador). II.
Ttulo.
005.1
CDD (23. ed.)
UFPE- MEI 2016-088

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 requisito 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)
Agradeo, inicialmente, a Deus, pela vida.

Agradeo a todos os professores que, de alguma forma,
contriburam para a concretizao da minha dissertao de
mestrado.
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 obrigado.
Agradeo tambm ao Carlo Marcelo pelas ideias trocadas, ajuda e motivao que foram
fundamentais.
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.
Construmos muitos muros e poucas pontes

SIR ISAAC NEWTON
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 para Web Services, definir uma arquitetura segura para mitigar
as principais ameaas de segurana em ambientes de nuvem, segundo o guia intitulado The
Notorious Nine: Cloud Computing Top Threats in 2013 da Cloud Security Alliance.
Metodologia: Atravs de um estudo na literatura sobre computao em nuvem e segurana neste ambiente, foram utilizadas referncias da rea de pesquisa relacionadas ao problema
identificado. Especificou-se uma arquitetura segura como hiptese de soluo, e posteriormente 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. Experimentos
de campo contemplaram aquisies a respeito dos mecanismos de segurana aplicados, em particular os padres WS-Policy, WS-Security e 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. Computao em Nuvem.
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 entitled The
Notorious Nine: Cloud Computing Top Threats in 2013 issued by the Cloud 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. Field
experiments have taken into account inputs from the security mechanism patterns used, namely:
WS-Policy, WS-Security e 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.
Lista de Ilustraes
2.1
2.2
2.3
2.4
2.5
2.6
Relaes entre entidades . . . . . . . . . . . . . . . . . . . . . .

Arquitetura de normas de Web Services (WS) proposta pelo W3C .
Estrutura de uma mensagem SOAP . . . . . . . . . . . . . . . . .
Estrutura de um documento WSDL . . . . . . . . . . . . . . . . .
Formas de assinatura XML Digital Signature . . . . . . . . . . .
Relacionamento de Web Services, SOA e Computao em Nuvem
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
24
26
30
39
4.1
4.2
4.3
4.4
4.5
4.6
Interao das Vises do Modelo 4+1 . . . . . . . .

Viso lgica da Arquitetura de Referncia proposta
Diagrama de Dependncias . . . . . . . . . . . . .
Arquitetura em Camadas . . . . . . . . . . . . . .
Exemplo de pacote HTTP capturado pelo Wireshark
Diagrama de Sequncia Estudo de Caso 03 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
53
54
57
66
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Fases da metodologia GQM . . . . . . . .

Estrutura da Fase de Definio . . . . . . .
Workflow do ciclo de vida do Apache Axis 2
Anlise do aumento do tempo de resposta .
Resultados da avaliao da Questo 01 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
74
76
79
80
81
82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lista de Tabelas
3.1
5.1
5.2
5.3
Comparativo entre as solues dos trabalhos relacionados para mitigao das

ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
Propriedades de segurana afetadas por ameaas . . . . . . . . . . . . . . . . .

Ataques utilizados para cada ameaa . . . . . . . . . . . . . . . . . . . . . . .
Definio das Questes e Mtricas para avaliao . . . . . . . . . . . . . . . .
73
73
75
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
CSA
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
PaaS
Platform as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
PKI
Infraestrutura de Chaves Pblicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
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 Policy ou WS-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
WSS
Web Service Security ou WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
WSSP
Web Services SecurityPolicy ou WS-SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . . . . 37
X-KRSS
XML Key Registration Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
X-KISS
XML Key Information Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
XKMS
XML Key Management Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
XML
eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Sumrio
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
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
Web Services Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2.1
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2.2
XML Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.2.3
XML Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Security Assertion Markup Language . . . . . . . . . . . . . . . . . . . . . .
33
2.3.1
A Anatomia da SAML . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Web Services Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.4.1
Polticas para Web Services . . . . . . . . . . . . . . . . . . . . . . .
36
2.4.2
Web Services SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . .
37
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 . . . . . . . . . . . . . . . . . . . . . .
43
2.5.3.5
Negao de Servio . . . . . . . . . . . . . . . . . . . . . .
43
Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.2
2.3
2.4
2.5
2.6
Trabalhos Relacionados
3.1 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
47
Implementao da Proposta
4.1 Metodologia 4+1 . . . . . . . . . . . . . . . . . . . . . .
4.2 Viso Lgica . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Mdulo de Servio . . . . . . . . . . . . . . . . .
4.2.2 Mdulo de Mecanismos de Segurana . . . . . . .
4.2.3 Mdulo de Polticas de Segurana . . . . . . . . .
4.2.4 Mdulo de Gerenciamento de Acesso e Identidade
4.3 Viso Dependncia . . . . . . . . . . . . . . . . . . . . .
4.4 Viso Implementao . . . . . . . . . . . . . . . . . . . .
4.5 Viso Fsica . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Cenrios . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Desenvolvimento da Aplicao . . . . . . . . . . .
4.6.2 Experimento de Campo . . . . . . . . . . . . . . .
4.6.2.1 Estudo de Caso 01 . . . . . . . . . . . .
4.6.2.2 Estudo de Caso 02 . . . . . . . . . . . .
4.6.2.3 Estudo de Caso 03 . . . . . . . . . . . .
4.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
50
51
51
52
52
53
54
55
56
56
57
57
60
65
68
.
.
.
.
.
.
.
.
71
71
72
72
72
73
76
78
82
Consideraes Finais
6.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
84
84
Avaliao da Proposta
5.1 Metodologia . . . . . . . . . . . . . . . . . . . . .
5.1.1 Planejamento . . . . . . . . . . . . . . . .
5.1.1.1 Publico alvo e cenrio de atuao
5.1.1.2 Critrio de Avaliao . . . . . .
5.1.2 Definio . . . . . . . . . . . . . . . . . .
5.1.3 Coleta de Dados . . . . . . . . . . . . . .
5.1.4 Anlise dos Resultados . . . . . . . . . . .
5.2 Limitaes da Avaliao . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Referncias
85
Apndice
89
A Certificado Digital
91
15
1
Introduo
O 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 em
indisponibilidades de servios, vazamento e perda de dados; a falta de conhecimento dos riscos
existentes em ambientes de nuvem. Segundo a CSA (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 arquiteturais e tecnolgicas, mas tambm mudanas de processos, em funo dos novos modelos de
computao em nuvem. Organizaes como World Wide Web Consortium (W3C) e Organization
for the Advancement of Structured Information Standards (OASIS) so responsveis pelo conjunto de padres de interoperabilidade e segurana dos Web Services (WS). Empresas como
International Business Machines (IBM) e Amazon Web Services (AWS), lderes do setor de
segurana em ambientes de nuvem, apoiam o desenvolvimento destes padres (CSER, 2014).
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 sistemas
distribudos que possibilitam o cmbio de dados e integrao de sistemas j existentes: os Web
Services.
Os WS utilizam padres neutros como Hyper Text Transfer Protocol (HTTP) e eXtensible
Markup Language (XML), permitindo que as diferentes aplicaes sejam integradas atravs de
linguagens e protocolos largamente aceitos, assim garantindo interoperabilidade (W3C, 2004).
A W3C e OASIS tm por objetivo projetar e publicar especificaes, ou padres, que
cumprem a promessa dos WS: interoperabilidade entre as barreiras geogrficas, de hardware,
de sistema operacional, de linguagem de programao e integrao de plataformas a baixo
custo (POTTS, 2003). Contudo, a segurana dos servios e a transio de dados tornaram-se
alvo de estudo porque no universo de WS, 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 nos WS, algumas tecnologias foram criadas, entre elas, Web
Service Security ou WS-Security (WSS), Security Assertion Markup Language (SAML) e Web
Services Policy ou WS-Policy (WSP), de forma que as suas especificaes tornaram-se indispensveis para a construo de WS seguros (OASIS, 2012a).
Neste contexto, com base na importncia da segurana nos WS, este trabalho tem por
objetivo estudar os mecanismos de segurana, WSS, SAML e WSP, 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
seus data 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 fronteiras
1 Um
centro de processamento de dados (CPD) o local onde so concentrados os equipamentos de processamento e armazenamento de dados de uma empresa ou organizao
1.2. ESTABELECIMENTO DO PROBLEMA
17
do data center (DAMASCENO, 2015).

Ainda no mbito de empresas governamentais, especificamente federais, h recomendaes de interconexo na prestao dos servios de governo eletrnico, onde se deve considerar
o nvel de segurana que regulamentam a utilizao da TIC na interoperabilidade de servios
de 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, os WS tornam-se uma nova opo
de negcio para as empresas que planejam utilizar a CN como 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 WS representa 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 para WS atendendo aos
padres e polticas contidos na ePING e 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, SAML e WSP. 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 Services possam 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, o framework
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 de
campo com desenvolvimento de um prottipo para anlise da tecnologia de servios seguros
pelas normas WSS, SAML e WSP. A principal contribuio desta dissertao o retrato atual
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 servios TIC baseados em computao
em nuvem privada, este trabalho prope especificar, projetar e implementar uma arquitetura de
software guiada por conformidades de segurana para WS em 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 nos WS.
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 de
segurana 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 da CSA (2013), com ateno especial ao modelo SaaS e anlise de risco
das principais propriedades bsicas da segurana: confidencialidade, integridade,
disponibilidade, autenticidade e no repdio;
2. Estudo da plataforma tecnolgica de WS, com nfase nas normas de segurana em
nvel de servio e de mensagem (LADAN, 2011);
3. Atendimento a Portaria SLTI/MP n 92, de 24 de dezembro de 2014, no que tange as
reas cobertas pela ePING;
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 normas WSS, SAML e WSP.
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:
Parte 2: apresenta os principais conceitos bsicos de WS e CN. Tambm esclarece

alguns detalhes de funcionamento das normas de segurana estudadas: WSS, SAML
e WSP.
1.5. ESTRUTURA DA DISSERTAO

19
Parte 3: cita os trabalhos relacionados ou que tm pontos em comum com esta

dissertao.
Parte 4: define as caractersticas bsicas da arquitetura proposta e descreve as especificaes do ambiente de implantao, alm de apresentar as implementaes dos
experimentos de campo das normas de segurana deste ambiente.
Parte 5: 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.
Parte 6: apresenta as consideraes finais da dissertao e os trabalhos futuros.
21
2
Referencial Terico
Atravs de cinco Sees esta parte tem como objetivo explanar os conceitos e estudos
utilizados como base para a presente pesquisa. Na primeira seo so apresentados os conceitos
dos WS. A segunda seo discute as noes da extenso WSS e seus mecanismos de segurana.
A terceira fornece detalhes da especificao SAML e a integrao entre os diferentes sistemas
de autenticao e de autorizao. A quarta seo aborda a estrutura do WSP para apoiar na
confeco das polticas de segurana. A quinta e ltima, aborda os conceitos e os principais
benefcios e ameaas da CN.
2.1
Web Services
WS so 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 um Uniform Resource Identifie (URI) e chamadas atravs das Remote Procedure Call (RPC),
como acontece em outros servios distribudos. O tipo de informao oferecida pelos WS o
que os tornam diferentes de sites Web comuns (W3C, 2004).
O grande entusiasmo em torno dos WS 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. Os WS no so a primeira tecnologia a nos permitir isto, mas so diferentes das
tecnologias existentes, pelo fato de usarem padres neutros de plataforma, como HTTP e XML.
Atualmente, as vantagens dos WS so atrativas para muitas aplicaes, oferecendo
flexibilidade e interoperabilidade sobre outras tecnologias. Entre essas vantagens, encontra-se a
integrao prpria para business-to-business (B2B). No entanto, essas aplicaes precisam de
algum nvel de segurana necessrio para que as mesmas se interconectem de forma confivel.
Dessa forma, a segurana tem sido considerada um obstculo na adoo dos WS.
22
2. REFERENCIAL TERICO
2.1.1
Arquitetura
A gesto da arquitetura dos WS fornecida pelo modelo terico da Service-Oriented

Architecture (SOA). Trata-se de um modelo simples que contm trs entidades e trs operaes.
A Figura 2.1 ilustra esse modelo (POTTS, 2003).
Figura 2.1: Relaes entre entidades
Fonte: W3C (2004) - adaptado.
2.1.2
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 localizado
no diretrio para registro de servios, o cliente poder invocar o mesmo ao provedor
de servios toda vez que desejar us-lo.
Normalizao
A normalizao da plataforma de WS surge 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 para
o desenvolvimento de WS.
1 http://www.ws-i.org,
ltimo Acesso em Novembro de 2015
2.1. WEB SERVICES
23
A pilha de protocolos dos WS apresentada na Figura 2.2 abrange normas que suportam a
interao das trs entidades mencionadas. Algumas dessas mais importantes normas de WS so
definidas pelo W3C2 (W3C, 2004).
Figura 2.2: Arquitetura de normas de WS proposta 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 dos WS so explicados em detalhes.
2.1.3
eXtensible Markup Language
A XML um formato de texto simples e flexvel, um subconjunto de Standard Generalized 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 os namespaces, mantido pela W3C. Os namespaces descrevem 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 namespaces previne que documentos XML diferentes
tenham elementos como nomes conflitantes. Assim, pode-se atribuir um prefixo ao namespaces.
2 https://www.w3.org/,

3 https://www.w3.org/MarkUp/SGML/,
24
Os componentes schemas e namespaces se 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 o XML Namespace e XML 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 de WS.
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 simplicidade e coerncia para que uma aplicao envie mensagens XML para outra, garantindo a
independncia do transporte utilizado.
Uma mensagem SOAP um documento XML. A Figura 2.3 ilustra 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.
4 rea
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 composto
por duas partes: o cabealho (SOAP Header) e o corpo (SOAP Body) da mensagem.
delimitada e protegida destinada para armazenar algo.
2.1. WEB SERVICES

2.1.5
25
Cabealho SOAP (SOAP Header): 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 de
autorizao 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 elemento Fault, que tem por objetivo transportar informaes
sobre erros que possam vir a ocorrer no processamento dessas informaes.
Web Services Description Language
A WSDL 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 XML Schema que obedece a uma estrutura fixa para especificar
interface de servio. WSDL descrevem um WS em duas fases fundamentais: um abstrato e
um concreto (W3C, 2013). A parte abstrata descreve as capacidades do WS, 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 elementos XML de
um documento WSDL apresentados na Figura 2.4 so:
definitions: este o elemento raiz a partir do qual os demais so definidos.

types: define os tipos de dados, utilizando o XML Schema, 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 elemento message.
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, descrevendo as mensagens de entrada, sada e excees possveis e permitidas.
5 http://www.corba.org,
26
Figura 2.4: Estrutura de um documento WSDL
Fonte: W3C (2007a) - adaptado.
2.1.6
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 transportar os elementos at o destino.
port: associa o elemento binding e 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 binding e o endereo de rede onde o servio pode ser encontrado, possuindo
assim um conjunto de port associados.
Universal Description, Discovery and Integration
O UDDI permite que WS disponveis na Internet sejam facilmente encontrados, provendo

uma interface para utilizao do cliente. Trata-se de um protocolo para registrar, publicar e
descobrir WS num ambiente distribudo (OASIS, 2004).
Os dados e metadados dos WS so 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 um WS,
como a WSDL do servio. Este tambm contm informaes relativas empresa responsvel
2.2. WEB SERVICES SECURITY
27
que prover o servio. A disponibilidade dos servios dos WS atravs de UDDI no obrigatria
(OASIS, 2004).
No domnio de informao da UDDI, existem trs tipos de informao que podem ser
consagrados no registro UDDI:
2.2
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 um Web Service,
neste contexto, feita com base nas categorias.
Pginas Brancas: onde, so includas informaes bsicas de contatos que permite
pesquisar um Web Service com base em dados atrelados entidade fornecedora do
WS. Essas informaes so constitudas (i.e. nome de um negcio, descrio do
negcio, informao de contato, endereo, fax, ou mesmo incluir identificadores de
negcios).
Pginas Verdes: contm um conjunto de informaes tcnicas sobre um WS, desta
forma o programador ao ter acesso a essas informaes poder desenvolver sua
aplicao que utilize ao WS em questo.
Web Services Security
A Web Service Security ou WS-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 autenticidade. Essas especificaes atendem esses trs requisitos de segurana atravs do uso da
Assinatura XML (XML Signature), da Criptografia XML (XML Encryption) 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 mensagem SOAP para construo de WS seguros, fazendo uso
das especificaes a XML Digital Signature e a XML Encryption.
A seguir, a XML apresenta uma mensagem SOAP que usa segurana baseada em tokens,
assinaturas digitais e criptografia:
28
29
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
Segundo W3C (2008): O uso de assinaturas digitais6 uma forma de garantir as

propriedades de integridade e autenticidade de informaes digitais. O XML Digital Signature
um padro aberto controlado pela OASIS7 , proposta conjunta entre W3C e Internet Engineering
Task Force (IETF)8 , define regras para gerar e validar assinaturas digitais expressa em XML.
O XML Digital Signature um conjunto de tags XML. Essas tags tm a funo de conter
informaes suficientes para permitir que um cliente seja verificado usando o par de chaves
pblica/privada. O uso do padro XML Digital Signature no 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 diferentes
partes 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 XML Digital Signature:
6 Conjunto
de instrues matemticas baseadas na criptografia, que permite conferir autenticidade, privacidade e

inviolabilidade aos documentos digitais e transaes comerciais efetuadas pela Internet.
7 https://www.oasis-open.org/, ltimo Acesso em Novembro de 2015
8 https://www.ietf.org/, ltimo Acesso em Novembro de 2015
30
Segundo W3C (2013), a informao assinada aparece dentro do elemento <SignedInfo>.

O algoritmo usado no clculo do elemento <SignatureValue> mencionado dentro da seo
assinada e contem o valor da assinatura digital, sempre codificada usando base64. O elemento
<SignatureMethod> especifica o algoritmo usado para converter o SignedInfo canonizado no
SignatureValue. Esta uma combinao de um algoritmo que depende da chave e de um
algoritmo de resumo, neste caso, DSA e SHA-1. O elemento <KeyInfo> indica a chave que
usada para validar a assinatura.
O padro Canonical XML9 uma especificao que descreve um processo de herana
de atributos XML namespace, definindo meios para representar documentos na forma cannica
(W3C, 2008). O interpretador XML expressa que o elemento <p class="a"secure="1"/> e o
elemento <p class = a secure = "1"/> 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
Figura 2.5:
Figura 2.5: Formas de assinatura XML Digital 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 onde
se encontra a assinatura, portanto a assinatura fica separada dos dados assinados.
9 https://www.w3.org/TR/xml-c14n,
ltimo acesso em Janeiro de 2015
31
Geralmente estes dados encontram-se na Web. ideal para assinar documentos que
sofrem constantes modificaes.
2.2.3 XML Encryption

O padro XML Encryption prov segurana fim-a-fim para aplicaes que necessitam
realizar trocas de dados de forma segura (W3C, 2013). A segurana provida do padro oferece
um nvel de privacidade por cifrar os dados evitando que terceiros vejam seu contedo, desta
forma, a criptografia em XML fornece funcionalidades complementares para assinatura XML
(XML Signature) e permite criptografar um documento XML completo, partes selecionadas de
um documento XML ou contedo referenciado por um documento XML.
De acordo com Singh (2010), "A codificao o nico meio de proteger nossa privacidade e garantir o sucesso do mercado digital".
Segundo Potts (2003) esclarece: A maneira mais simples, embora mais til, de
proteger sua mensagem de WS usar o Security Socket Layer (SSL)..
O SSL um protocolo proprietrio da Netscape Communication e o Transport Layer
Security (TLS) a definio RFC 2246 do padro da IETF. Os dois protocolos so semelhantes,
mas o TLS possui alguns aprimoramentos importantes. Os TLS/SSL so usados com mais
frequncia para oferecer proteo e integridade dos dados sobre o protocolo HTTP.
Os protocolos TLS/SSL possuem algumas limitaes em um ambiente de WS. Esses
protocolos, por si s, no podem fornecer autenticao, integridade de dados durante a existncia
da mensagem se ela for roteada atravs de mais de um WS. A especializao XML Encryption
no pretende substituir TLS/SSL, mas garante confidencialidade persistente, garantindo assim
confidencialidade dos dados depois do trmino da s esso. Alm disso, prov um mecanismo de
segurana que no coberto pelo TLS/SSL, como a possibilidade de cifrar somente parte de um
dado e o estabelecimento de sesses seguras entre mais de duas partes.
Em um ambiente de WS, importante que os dados cifrados sejam representados de uma
forma estruturada que permitem o uso de diferentes chaves para cifrar parte do documento, desta
forma, o mesmo documento seja trocado entre diversas partes, sem que ocorra a revelao de
informao para partes no autorizadas e garantam o acesso informao, por partes autorizadas.
A XML a seguir apresenta, de maneira breve, a estrutura da sintaxe para a criptografia
XML. Os pontos de interrogao no cdigo a seguir so substitudos por entradas efetivas:
Segundo W3C (2013), o elemento <EncryptedData> est na primeira parte da sintaxe
da criptografia X ML q u e, c o mo o e l emento < E ncryptedKey>, u s ada p a ra t r ansportar as
chaves de criptografia, do originador at um receptor conhecido, e derivada do tipo abstrato
<EncryptedType>. Os dados a serem criptografados podem ser qualquer um dos seguintes,
resultados em um elemento de criptografia X ML q ue c ontenha, o u f aa r eferncia, o s dados
cifrados: dados arbitrrios, o elemento <EncryptedData> pode tornar-se a raiz de um novo
documento XML, ou um elemento-filho; documento XML, o elemento <EncryptedData> pode
32
torna-se a raiz de um novo documento; elemento XML, o elemento <EncryptedData> substitui o

elemento ou contedo na verso criptografada do documento XML; contedo do elemento XML;
o elemento <EncryptedData> substitui o elemento ou o contedo na verso criptografada do
documento 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 Senha do cliente responsvel. O
contedo apresenta um exemplo do documento anterior usando o padro XML Encryption:
Ainda no documento XML, 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
<EncryptedData>, preservando a informao confidencial.
O WSS fornece estrutura para uma segurana completa e flexvel s necessidades individuais. Para tanto, essa tecnologia prope um conjunto de extenses de cabealho SOAP, que,
uma vez utilizados, podero conter XML para os padres j analisados anteriormente (XML
Signature, XML Encryption), bem como para os padres que surgiro no futuro (POTTS, 2003).
2.3. SECURITY ASSERTION MARKUP LANGUAGE
2.3
33
Security Assertion Markup Language

Segundo OASIS (2008) apud Mello et al. (2006), o framework10 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 .
O propsito tecnolgico SAML dada em OASIS (2008) : . . . definir, melhorar, e manter um framework padro baseado em XML para criao e trocas informaes de autenticao
e autorizao.
Segundo Mello et al. (2006): Uma assero de segurana um conjunto de afirmaes, concedidas por um emissor SAML, sobre determinadas informaes de um principal.
2.3.1
A Anatomia da SAML
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:
10 Conjunto
de funcionalidades comuns para um determinado domnio de aplicaes.

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 e
ainda, possibilita o uso de mecanismos no definidos na especificao.
11 A
34
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.
2.3. SECURITY ASSERTION MARKUP LANGUAGE
35
A XML, comentada acima, exemplifica que a assero de autorizao contida no documento que afirma que o cliente tiad@cindacta3.aer.mil.br est 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 atributos Decision do elemento
AuthorizationDecisionStatement informando Deny para negao, Permit para permisso e Indetreminate para 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 pode
entrar em contato com um provedor de identidade separado para autenticar usurios que estejam
tentando acessar um contedo seguro.
36
2.4
Web Services Policy
A WSP uma linguagem para definir polticas de servios, oferecendo uma gramtica
flexvel e extensvel que permite definir como os recursos e restries das normas de segurana
podero ser expressos para o ambiente de WS.
2.4.1
Polticas para Web Services
A WSDL, apresentado na Subseo 2.1.5, fornece um mecanismo para descrever as

funcionalidades presente em um WS. 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.
A WSDL tem 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 interao
entre ambos possa acontecer) que tornam necessrio o surgimento de uma tecnologia WSP, com
objetivo de prover um modelo de propsito geral para descrio de polticas.
As polticas de segurana so representadas atravs de documentos XML, cujo elemento
raiz do documento o elemento Policy. 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:
ExactlyOne indica que somente uma das asseres contidas na poltica poder fazer parte de uma
alternativa de poltica; All permite a combinao de todas as asseres apresentadas como uma
alternativa de poltica (W3C, 2007b).
A seguir, a XML apresenta a estrutura simplificada para expressar polticas da especializao WSP:
A especificao WSP demasiada abstrata, expressa as capacidades, requisitos e caractersticas gerais de entidades em um WS baseado em XML. Desta forma, mantendo o foco
desse trabalho nas normas de segurana em nvel de segurana de servio e de mensagem, com
2.4. WEB SERVICES POLICY
37
nfase na implementao especializada do WSP chamada de Web Services SecurityPolicy ou

WS-SecurityPolicy (WSSP) que est atrelada ao WSS.
2.4.2
Web Services SecurityPolicy
A WSSP uma especializao da WSP para 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) WSSP referem-se s
funcionalidades de segurana de WSS, WS-Trust12 e WS-SecureConversation13 . Podem tambm
referir segurana no transporte, como no protocolo HTTP (OASIS, 2012c).
A especializao WSSP prov 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 bilhete Kerberos.
A XML a seguir, apresenta a estrutura da WSSP de um servio:
12 http://goo.gl/RHX5SJ,
13 http://goo.gl/ULrS1L,

ltimo acesso em Novembro 2015
38
A XML apresentou 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 <SymmetricBinding>,
criptografia assimtrica <AsymmetricBinding> e segurana no transporte <TransportBinding>.
Assim, o uso de criptografia de segurana pode ser utilizado para adicionar tokens de 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 tokens de 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 informaes. Algumas sub-assero disponveis para detalhar a configurao so: Layout (ordenao
dos elementos de segurana), IncludeTimestamp (incluir marca temporal na mensagem), EncryptSignature (cifrar assinatura), EncryptBeforeSign (cifrar antes de assinar), AlgorithmSuite
(algoritmos criptogrficos a utilizar), ProtectTokens (includos tokens de segurana na assinatura)
e OnlySignEntireHeadersAndBody (assinar apenas corpo e cabealhos que no os de segurana).
As asseres AsymmetricBinding e TransportBinding permitem garantir segurana no
transporte das mensagens com base no WSS. A AsymmetricBinding garante atravs de criptografia
simtrica entre o emissor e o receptor e a TransportBinding garante a correlao de segurana
por meios externos.
As asseres de tokens de segurana possuem propriedades que permitem identificar
quais so os tokens aceitos e qual o processamento de ser realizado. Desta forma, os tokens
assero podem ser: HttpsToken, UsernameToken, X509Token, KerberosToken, SamlToken. Por
exemplo, o token X509Token especificar que a mensagem seja assinada com uma chave de
certificado digital X.509. Podemos destacar, ainda, o tokenTokenInlusion, que indica como os
tokens de segurana devem ser usados. Segue a propriedade de processamento do token:
Never: o token nunca pode ser transportado em mensagens, podendo apenas ser
referenciado;
Once: o token deve ser transportado uma vez na primeira mensagem, mas depois
no mais. Esta opo usada para iniciar sesses seguras;
AlwaysToRecipient: o token deve ser enviado sempre que o emissor enviar uma
mensagem para o receptor. O mesmo j no deve acontecer na resposta;
2.5. COMPUTAO EM NUVEM

39
AlwaysToInitiator: o token deve ser enviado sempre que o receptor enviar uma
mensagem para o emissor. O mesmo j no deve acontecer na solicitao;
Always: o token deve 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 propsitos 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 mensagens SOAP.
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 Interface (API) para interagir e gerenciar com os servios oferecidos. Essas APIs so definidas e
especificadas pelas interfaces de um WS, como na WSDL descrita na Subseo 2.1.5. Independentemente dos propsitos de projetos de cada um, a abordagem de CN pode se relacionar com
a arquitetura SOA, atravs de padres para WS, na utilizao de componentes como um servio Components as a Service (CaaS).
A Figura 2.6 utilizao do diagrama de Venn14 para ilustrar a relao entre WS, SOA e
CN.
Figura 2.6: Relacionamento de Web Services, SOA e Computao em Nuvem
Fonte: Barry e Dick (2013) - adaptado.

14 Diagramas
usados em matemtica para simbolizar graficamente propriedades, axiomas e problemas relativos
aos conjuntos e sua teoria.
40
O diagrama ilustrado acima, enfatiza a CN inserida dentro do conjunto de WS utilizando

SOA para indicar que a CN usa os servios de WS, no entanto, a CN pode ser utilizada sem o
modelo SOA e WS. Nas prximas Subsees sero apresentados, de maneira sucinta e objetiva,
os modelos de servio e de implantao. Dentre os aspectos as ameaas sero explanadas com
um 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:
2.5.2
Software como Servio (Software as a Service - SaaS): Servios de softwares de

propsito especfico disponibilizado por meio de interfaces como um navegador de
internet. 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 ferramentas de gerenciamento de configurao, implantao e execuo de aplicaes nesta
infraestrutura.
Infraestrutura como Servio (Infrastructure as a Service - IaaS): O servio IaaS
fornece uma API de gerenciamento para utilizao dos recursos de infraestrutura
computacional bsica (capacidade de armazenamento e processamento).
Modelos de Implantao
De acordo com Mell e Grance (2011), h quatro modelos de implantao:
Nuvem Comunitria: Uma nuvem de comunidade compartilha a infraestrutura

entre 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 operada
exclusiva por uma organizao, podendo ser administrada pela prpria organizao
ou por um terceiro;

2.5.3
41
Nuvem Hbrida: Uma nuvem hbrida composta por duas ou mais nuvens de
quaisquer tipos mencionados acima. A conexo entre elas oferece benefcios dos
diversos modelos de implantao e permite portabilidade dos programas e dados seja
movidos facilmente de um sistema de implantao para outro.
Ameaas Nuvem
O objetivo desta Seo apresentar os riscos mais significativos de segurana associados

com a CN publicados pelo relatrio The Notorious Nine: Cloud Computing Top Threats in
2013. Neste relatrio, os especialistas identificaram as noves principais ameaas segurana
em nuvem, que so: vazamento de dados, perda de dados, sequestro de contas ou 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).
Alinhado com os objetivos deste trabalho, nas normas de segurana em nvel de servio
e de mensagem e com base nesse relatrio foi escolhido as cinco ameaas mais crticas do
modelo SaaS, contendo a anlise de risco das principais propriedades bsicas da segurana:
confidencialidade, integridade, disponibilidade, autenticidade e no r epdio. A seguir sero
abordados os problemas a ser resolvido neste trabalho:
2.5.3.1
Vazamento de Dados
A ameaa de vazamento de dados ocupa a primeira posio no ranking de ameaas de

CN em 2013, segundo o relatrio da CSA (2013). Esta ameaa aumenta pela caractersticas da
arquitetura do ambiente em nuvem. A proposta do modelo SaaS prover aplicaes que atendam
mltiplos clientes, chamados de multi-inquilinos, anulando a possibilidade de exclusividade
entre os clientes.
Por exemplo, um servio de nuvem de banco de dados multi-inquilinos mal projetado,
permite o acesso indevido das informaes de um cliente a partir de uma falha na aplicao,
comprometendo a confidencialidade das informaes.
Outro exemplo preocupante, foram as notcias relacionadas espionagem internacional,
atravs de monitoramento e colaborao de provadores de servios de armazenamento e de
e-mails, informaes sigilosas de governos e empresas vazaram, acompanhado com denncias
de acesso a dados privados de cidados.
2.5.3.2
Perda de Dados
A ameaa de perda de dados subiu da quinta posio em 2010 para ocupar a segunda
posio em 2013 no Top Threat Ranking (CSA, 2013). Segundo o relatrio Cloud Storage da
Fixya (2012), foram apontados problemas de segurana dos principais provedores do mercado
42
(Google Drive15 , SugarSync16 , iCloud17 , Box18 e Dropbox19 ), tais como abusos com relao
privacidade, vazamento ou perda de dados, violao de direitos autorais, falhas na sincronizao
de arquivos, dentre outros.
Conforme bem colocado pelo relatrio da Fixya (2012), a perda de dados preocupante
tanto para consumidores quanto para provedores. A perda de dados pode ser enquadrada em
dois tipos de perda: acidentais e intencionais. A acidental, como o prprio nome sugere, ocorre
quando um usurio ou uma aplicao apaga, sobrescreve, altera os dados acidentalmente, sem
a inteno de prejudicar o proprietrio das informaes. E por fim, a perda de dados de forma
intencional d-se quando tambm um usurio e uma aplicao apaga, sobrescreve, altera os
dados de forma proposital, motivado para causar algum tipo de dano ao detentor, comprometendo
principalmente a integridade da informao.
2.5.3.3
Sequestro de Contas ou de Trfego de Servios
O ataque de sequestro de contas ou de trfego de servios subiu da sexta posio em 2010

para ocupar a terceira posio no ranking de ameaas de CN em 2013, segundo o relatrio da
CSA (2013). Os mtodos de ataques como phishing, fraude e explorao de vulnerabilidades de
softwares no so mais considerados uma nova prtica, mas ainda alcana resultados e acabam
por serem potencializados como o uso dos ambientes em nuvem. Isto ocorre porque so providos
milhares de contas de servio, permitindo assim com que usurios mal intencionados tenham um
ponto centralizado para explorar (BERTINO et al., 2010).
Uma vez que o atacante captura as credenciais de acesso de uma conta, o mesmo
pode monitorar suas atividades, transaes, manipular dados, retornar informaes falsas e
redirecionar para outros usurios, o que amplifica o impacto de tais ataques. Em consequncia
do comprometimento de uma conta de servio do ambiente da nuvem, pode servir com uma nova
base para diferentes tipos de ataques, como o vazamento de dados de outras contas de servio
que estejam na mesma nuvem (CSA, 2013).
Em abril de 2010, o bot Zeus20 , cavalo de troia que rouba informaes da mquina
infectada, foi encontrado no ambiente de nuvem da empresa AWS21 sequestrando enumeras
contas do provedor. Em 2013, o Dropbox, um dos principais provedores do mercado, foi apontado
com problemas de segurana, alvo desse tipo de vulnerabilidade (ZORZ, 2013). Pesquisadores
demonstraram um mtodo de interceptar o trfego SSL, a partir do software cliente Dropbox que
instalado localmente, burlando o mecanismo de autenticao de dois passos e sequestrando
contas do provedor.
15 https://www.google.com/intl/pt-BR/drive/,

17 https://www.icloud.com/, ltimo acesso em Novembro 2015
18 https://www.box.com/, ltimo acesso em Novembro 2015
19 https://www.dropbox.com/, ltimo acesso em Novembro 2015
20 https://goo.gl/Yg2Yzd, ltimo Acesso em Novembro de 2015
21 https://aws.amazon.com/pt/, ltimo Acesso em Novembro de 2015
16 https://www.sugarsync.com/,
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 como Man in the Cloud (MITC). Essa vulnerabilidade foi identificada nos seguintes
provedores: Google Drive, Dropbox, OneDrive24 e Box. Segundo o relatrio, no foi utilizado
nenhuma 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 token sem que seja
necessrio comprometer a senha da vtima.
2.5.3.4
Interfaces Inseguras
A ameaa de Interfaces Inseguras desceu da segunda posio em 2010 para ocupar a

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
valor ao seus servios. Essas APIs do flexibilidades para interagir e gerenciar com servios
em nuvem (e.g. gerenciamento, orquestrao, provisionamento, monitoramento etc.), porm a
disponibilidade desses servios depende de quo protegidas esto essas APIs.
O consumo indevido dessas interfaces por acesso annimo, tokens ou senha reutilizveis,
autenticao de texto no criptografado, controles de acesso inflexveis ou autorizaes indevidas,
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),
relataram falhas preocupantes na implementao das API do mecanismo de autenticao SingleSign On (SSO) prestados pelas empresas como a Google ID, Facebook, PayPal e outros
servios da Web. Essas falhas permite que o atacante acessem as contas das vtimas que utilizam
os servios de SSO, mesmo sem saber a suas credenciais de acesso.
A pesquisa realizada por Lu et al. (2013), apresentaram um estudos das principais falhas
Amazon EC2 API, onde 60% das falhas so chamadas que no responde, 19% de falhas de
contedo de mensagens de erro, falta de dados, contedo errado e contedo no esperado, 12%
so falhas por respostas demoradas e 9% relacionadas a erros genricos. Identificou-se que uma
das principais causas dessas falhas so as falhas de interaes entre os sistemas.
2.5.3.5
Negao de Servio
Um ataque de Negao de Servio, ou do ingls Denial of Service (DoS) Attack, uma

tentativa de tornar os recursos de um sistema indisponvel ou mesmo responder de forma lenta
para os seus usurios. No se trata de uma invaso ou coleta de informaes do sistema, mas sim
destinado a impedir que os usurios, de um servio de nuvem, sejam incapazes de acessar seus
dados ou suas aplicaes.
22 http://www.imperva.com/,

24 https://goo.gl/F66SFu, ltimo acesso em Novembro 2015
23 http://goo.gl/KPD2Pc,
44
O atacante de DoS - ou atacantes, como o caso de Distributed Denial-of-service

(DDoS) - exauri os recursos disponveis por sobrecarga de duas formas: Esgotamento de recurso
como memria e processamento so sobrecarregados atravs de inmeros processos criados e
executados, efetuando travamentos e erros. A segunda forma o consumo da largura de banda de
rede, pois uma vez sobrecarregada a aplicao ter um acesso muito lento ou at mesmo perda
de acesso.
Segundo a CSA (2013), este ataque ganhou classificao para quinta posio do Top
Threat Ranking e aumentam a medida em que mais sistemas esto disponveis online. Conforme
exposto por Holgersson e Soderstrom (2005), existem diversos tipos de ataques com a mesma
finalidade de comprometer a disponibilidade dos servios prestados.
2.6
Consideraes Finais
Nesta parte, foram descritas algumas das mais importantes normas que constitui a
arquitetura dos WS. A extenso WSS e suas tecnologias de segurana, tambm foram descritas,
bem como para os padres que surgiro no futuro (POTTS, 2003). Apresentado a especificao
SAML que permite que domnios da web seguros troquem a autenticao de usurio e os dados
de autorizao.
Tambm descrito a estrutura do WSP, a WSSP. Essa especializao segue alguns propsitos 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 mensagens SOAP. Por fim, uma explanao geral sobre
computao em nuvem foi realizada, destacando as ameaas mais significativas de segurana.
A prxima parte ira apresentar os principais trabalhos relacionados ao tema desta dissertao.
45
3
Trabalhos Relacionados
Para a presente dissertao, no foram encontrados trabalhos diretamente relacionados,
mas sim estudos que abordam: 1) anlise de segurana para WS e CN; 2) utilizao de testes de
segurana; 3) proposta de arquitetura de segurana. Alm disso, a Tabela 3.1 elenca de maneira
sumarizada os trabalhos relacionados e avalia-os de acordo com as solues propostas para
assegurar que as ameaas, descritas na Seo 2.5.3, sejam reduzidas a um nvel aceitvel.
Tabela 3.1: Comparativo entre as solues dos trabalhos relacionados para mitigao das
ameaas
Legenda X = Mitiga completamente; O = Mitiga Parcialmente;
(MACEDO et al., 2010)

(CELESTI et al., 2010)
(SALAS, 2012)
(FERREIRA, 2013)
(GONZALEZ, 2014)
WINCKLER (2014)
MICHELIN (2015)
Vazamento
de Dados
Perda
de Dados
Sequestro
de Contas
Interfaces
Inseguras
Negao
de Servios
O
O
O
O
X
X
O
O
O
X
O
X
O
X
X
X
O
Fonte: prpio autor.
No artigo de Macedo et al. (2010), apresentada uma arquitetura de segurana e

um mecanismo de controle de acesso em WS que determina como as mensagens devem ser
formadas, transportadas e processadas, de modo a inibir ataques de Tampering e XML Signature
Wrapping Element. Como proposta para defesa contra esses tipos de ataques, ele desenvolveu
um prottipo, com base nas especificaes WSS, W S-BPEL1 e WSP. A limitao deste estudo
foi a anlise em nvel do tempo de processamento na troca das mensagens SOAP que trafegam
na rede informando requisies e autorizaes.
Celesti et al. (2010) descrevem ambientes de nuvem heterogneas e federadas,
denominado InterClouds. Como proposta, apresentam uma arquitetura de referncia capaz de
1 http://goo.gl/MdroAi,
ltimo Acesso em Fevereiro de 2016
46
3. TRABALHOS RELACIONADOS
resolver problemas de gerenciamento de identidades federadas no contexto InterClouds e

demonstram a aplicabilidade com sucesso para gerenciar a autenticao. Os principais
requisitos levantados pela soluo incluem a implementao do framework SAML para
estabelecer autenticao SSO e uma arquitetura SOA para enfrentar problemas de
interoperabilidade.
Dentre os objetivos apresentados no trabalho de Salas (2012), destaca-se a anlise de
robustez dos WS, usando a tcnica de Injeo de Falhas (IF), introduzindo falhas nas requisies
da mensagem SOAP. Destaca-se tambm o desenvolvimento de uma rvore de ataques para
selecionar os tipos de ataques a serem injetados e a construo dos cenrios de ataques para
que sejam usados por testadores. Seus resultados demonstram que o padro WSS reduz as
vulnerabilidades encontradas e melhora a robustez contra esses tipos de ataques.
Uma arquitetura como soluo para o monitoramento de acordos de nveis de servio
de segurana em nuvens proposto por Ferreira (2013). Destaca-se o monitoramento dos
parmetros de segurana de acordos Security-SLA, baseado em informaes de desempenho
para deteco de anomalias de segurana. Utilizou-se a linguagem Web Service Level Agreement
(WSLA)2 e desenvolveu-se uma extenso para tratar a representao de polticas de segurana
desses acordos. Os resultados obtidos pela arquitetura proposta indicaram a possibilidade de
deteco de eventos de ataques do tipo negao de servio e SQL-injection nos servios em
execuo em mquinas virtuais a partir de informaes de desempenho.
A dissertao de Gonzalez (2014) prope um Sistema de Gerenciamento de Credenciais (SGC) para computao em nuvem, que visa implementar uma soluo de identificao de
entidades e controle de acesso nuvem. Destacam-se a construo de uma arquitetura de gerenciamento de credenciais para autenticao e autorizao baseada em OpenStack3, a construo
de uma taxonomia de servios e de uma taxonomia de segurana em computao em nuvem. Os
resultados da soluo proposta possibilitaram prover os mecanismos de segurana, implementados na linguagem de programao Python4, adequados para a nuvem sem a necessidade de
modificar as aplicaes e servios originais da mesma, alcanando uma soluo transparente
para usurios, desenvolvedores e administradores da nuvem.
Em seu trabalho, Winckler (2014) avalia as solues existentes e prope um arquite-tura
de interoperao para nuvens que permita a criao de federaes de nuvens computacionais
acadmicas. Destacam-se a adoo de protocolos de comunicao como Representational State
Transfer (REST) e JavaScript Object Notation (JSON) e o framework SAML. Para validar a
soluo apresentada foi desenvolvida um prova de conceito, a partir da combinao de alguns
componentes e protocolos j existentes, a arquitetura proposta capaz de atender diversos
requisitos: autonomia local, descentralizao, resilincia, manuteno, usabilidade, segurana e
flexibilidade.
2 http://goo.gl/uQbNvt,
ltimo Acesso em Janeiro de 2016

ltimo Acesso em Fevereiro de 2016
4 http://wiki.python.org.br/, ltimo Acesso em Maro de 2016
3 https://www.openstack.org/,
3.1. CONSIDERAES FINAIS
47
Michelin (2015) foca especialmente em ataques de DoS, descrevendo

sistemas que utilizam o estilo REST autenticveis atravs de tokens. A soluo definida,
chamada de MADRA, prope um mecanismo de mitigao de ataques de DoS que opere
em nvel de aplicao, analisando as requisies no estilo REST. Aps a validao de seu
contedo, realizado o controle do tempo em que cada cliente ficar impossibilitado de enviar
novas chamadas. Utilizou-se para anlise o componente Keystone, que responsvel pelo
mecanismo de autenticao e controle de acesso do sistema de gerenciamento de nuvem
OpenStack. Os resultados da avaliao da soluo proposta demonstraram que o tempo de
resposta dos servios ficaram prximos utilizao do sistema em condies normais de
operao, mesmo diante de um ataque DoS. Alm do tempo de resposta, tambm reduziu o
uso do processador.
3.1 Consideraes Finais

Esta parte apresentou diversos esforos propostos nas reas de segurana para WS e
CN. Embora algumas das solues apresentadas compartilhem caractersticas com o trabalho
proposto nesta dissertao, nenhuma das arquiteturas descritas atende completamente os controles
apropriados para assegurar que todas as cinco as ameas sejam reduzidas a um nvel aceitvel,
conforme apresentado na Tabela 3.1.
A escolha do protocolo SOAP sobre outros padres, como REST, deve-se ao fato da
especificao SOAP fornecer mecanismo para controle de transaes e suporte para comunicao
segura atravs da extenso WSS e tambm para atender aos padres e polticas obrigatrias dos
ePING5 que tratam da forma de desenvolvimento de um WS, concebida como uma estrutura
bsica para a estratgia de governo eletrnico, aplicada ao governo federal.
5 http://eping.governoeletronico.gov.br/,
ltimo Acesso em Maro de 2016
49
4
Implementao da Proposta
A presente parte descreve a soluo proposta e discute as caractersticas bsicas da
arquitetura, seus componentes, funcionalidades e padres, projetados para mitigar as principais
ameaas que impede a ampla adoo da computao em nuvem. E por fim, so analisados os
cenrios de experimentos de campo a partir da utilizao prtica das especializaes WSS, WSP
e SAML.
4.1
Metodologia 4+1
4+1 um modelo de viso projetada por Kruchten (1995), que divide a arquitetura em
5 (cinco) vises: Viso Lgica, Viso Dependncia, Viso de Implementao, Viso Fsica e
Cenrios. Essas vises descrevem o sistema do ponto de vista das diferentes partes, em sua
essncia, so fragmentos que ilustram os elementos significativos em termos de arquitetura dos
modelos. Tambm selecionados os cenrios so utilizados para ilustrar a arquitetura servindo
como a viso mais um, definido o modelo 4+1 visualizaes. Ele composto pelas seguintes
vises:
Figura 4.1: Interao das Vises do Modelo 4+1
Fonte: Kruchten (1995) - adaptado.
Viso Lgica: aborda os componentes significativos do projeto para a Arquitetura

adotada e a funcionalidade que o sistema fornece aos utilizadores finais;
50
4. IMPLEMENTAO DA PROPOSTA
4.2
Viso Dependncias: Ilustra as dependncias existentes entre os mdulos da Arquitetura;

Viso Implementao: A viso de implementao ilustra um sistema da perspectiva
de um desenvolvedor relacionados com a organizao do cdigo-fonte do sistema,
padres de Arquitetura utilizada e as orientaes e as normas para o desenvolvimento
do sistema;
Viso Fsica: Demonstra as configuraes de hardware e os sistemas do ponto de
vista de um engenheiro de sistema. A topologia responsvel pelos componentes de
softwares na camada fsica, bem como as ligaes fsicas entre esses componentes;
Cenrios : Mostram um subconjunto dos Cenrios dos Experimentos de Campo
significativos da Arquitetura. Os cenrios servem como ponto de partida para testes
de um prottipo de arquitetura.
Viso Lgica
Esta Seo demonstra a organizao da arquitetura proposta a partir de um ponto de vista

funcional. Os principais elementos, como mdulo e componentes principais so especificados.
A Figura 4.2 ilustra a arquitetura de ponto de vista lgico:
Figura 4.2: Viso lgica da Arquitetura de Referncia proposta
Fonte: prprio autor.
As Subsees seguintes explicitaro cada mdulo, ressaltando sua responsabilidade e os

requisitos atendidos.
4.2. VISO LGICA
4.2.1
51
Mdulo de Servio
O Mdulo de Servio prov um catlogo de servios oferecidos aos consumidores de

uma nuvem. Um catlogo de servios um documento XML, especificamente definido no padro
WSDL, que obedece a uma estrutura fixa para especificar interface de servio. O catlogo inclui
asseres de poltica, conjunto abstrato de operaes implementadas por um servio, formatos e
protocolos especficos. Esse mdulo constitudo pelo seguinte componente:
4.2.2
Provedor de Servio: O componente Provedor de Servio, estruturado na especializao WSDL, responsvel em definir e especificar as interfaces de servio. 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. Esse
componente responsvel em descrever e publicar os servios que posteriormente
sero consumidos pelos clientes.
Mdulo de Mecanismos de Segurana
O Mdulo de Mecanismo de Segurana, implementado pelas funcionalidades do padro

WSS, responsvel em oferecer mecanismos padres de segurana necessrios para realizar o
intercmbio seguro de mensagens certificadas em ambientes de nuvem, atravs de assinaturas
digitais e criptografia. Oferece tambm, o gerenciamento do ciclo de vida de chaves como
registro, distribuio e revogao. Dentre as funcionalidades oferecidas so constitudas dos
seguintes componentes:
Proteo do Trfego de Rede: O componente de Proteo do Trfego de Rede

guiado pelo padro XML Encryption que prov segurana fim-a-fim para aplicaes
que necessitam realizar trocas de dados de forma segura. Alm disso, prov um
mecanismo de segurana que no coberto pelo TLS/SSL, como a possibilidade de
cifrar somente parte de um dado e o estabelecimento de sesses seguras entre mais
de duas partes (W3C, 2013).
Encriptao de Dados: A segurana provida do componente, Encriptao de Dados,
oferece um nvel de privacidade por cifrar os dados evitando que terceiros vejam seu
contedo, desta forma, a criptografia em XML fornece funcionalidades complementares para o padro XML Digital Signature e permite criptografar um documento XML
completo, partes selecionadas de um documento XML ou contedo referenciado
por um documento XML. Esse componente tambm guiado pelo padro XML
Encryption.
XKMS: O componente XKMS implementado pela especificao XML Key Management Specification (XKMS), definido um protocolo para registrar e distribuir
52
chaves criptogrficas que utilizam Infraestrutura de Chaves Pblicas (PKI). Esse
componente auxilia a distribuio de chaves pblicas, que so essenciais para XML
Digital Signature e XML Encryption, possibilitando verificaes de assinaturas e
criptografia em mensagens SOAP. Divide-se em duas especificaes a XML Key
Registration Service Specification (X-KRSS), para o registro de chaves, e o XML
Key Information Service Specification (X-KISS), para requisio e distribuio de
informaes referentes s chaves pblicas registradas (W3C, 2005).
4.2.3
Mdulo de Polticas de Segurana
O Mdulo de Polticas de Segurana especifica requisitos, capacidades ou preferncias

aplicadas em clientes e servios de forma interopervel. O presente mdulo permite expressar as
polticas que se referem a recursos de domnio especfico, requisitos e caractersticas gerais.
O framework WSP fornece a estrutura do MPS para interpretao dos requisitos exigidos.
O presente mdulo constitudo dos seguintes componentes:
4.2.4
Alternativa de Poltica Alternativa de Poltica responsvel em definir uma coleo

no ordenada de asseres da polticas, define tambm uma expresso de poltica na
forma normal e um conjunto de regras que podem ser usadas para criar expresses de
polticas mais compactas.
Assero de Poltica A Assero da Poltica responsvel em especificar requisitos
tradicionais e capacidades que, em ltima instncia, se manisfestaro em ligaes,
por exemplo, no esquema de autenticao ou na seleo do protocolo de transporte.
Outras asseres da poltica possuem nenhuma manifestao de ligao, ainda que
adequados do servio, por exemplo, poltica de privacidade e caractersticas de
Quality of Service (QoS).
Mdulo de Gerenciamento de Acesso e Identidade
O Mdulo de Gerenciamento de Acesso e Identidade (MGAI), conduzido pela especificao SAML, possui a responsabilidade de proteger os sistemas, dados e aplicativos de acesso
no autorizado. Permite criar, gerenciar usurios e grupo e usar permisses para conceder e
negar acesso aos recursos providos. Os componentes que constitui o MGAI so controlados
pelas funcionalidades da SAML. Este mdulo constitudo por 3 (trs) componentes que sero
escrito a seguir:
Base de Entidades: A Base de Entidades responsvel em suportar o protocolo

Lightweight Directory Access Protocol (LDAP) para integrao dos mecanismos de
autenticao como Active Directory (AD)1 da Microsoft e OpenLDAP (OLDAP)2 .
1 https://goo.gl/8OaMoZ,

2 http://www.openldap.org/,
4.3. VISO DEPENDNCIA
53
Ao utilizar o AD ou OLDAP como fonte de o acesso s funcionalidades, permisses

por usurios ou grupo, recomendvel utilizar a replicao de LDAP para garantir a
disponibilidade do servio.
4.3
Provedor de Identidade: O Provedor de Identidade (IdP) responsvel pela manuteno das informaes sobre os usurios e por sua autenticao. O componente
Provedor de Servio, abordado no mdulo MS, requisita o IdP informando as credencias de acesso passada pelo usurio, por sua vez o IdP encaminhar uma afirmao
SAML, como parte da resposta de autenticao, que gerada para obter credenciais
de segurana temporrias de acesso aos servios providos.
Servio de Token de Segurana: O Servio de Token de Segurana responsvel
por gerenciar as credenciais temporrias de segurana que consistem em uma chave
de acesso e um token de sesso. A chave de acesso consiste em um ID chave de
acesso e uma chave secreta. Usurios (ou um aplicativo que o usurio executa) podem
usar essas credenciais para acessar os servios providos na organizao.
Viso Dependncia
Esta seo visa ilustrar as dependncias existentes entre os mdulos da Arquitetura de

Software. A Figura 4.3 ilustra o diagrama de dependncias entre os mdulos desta proposta.
Figura 4.3: Diagrama de Dependncias
Como pode ser observado na Figura 4.3, o mdulo MPS o mais utilizado. Deve-se
ao fato dos componentes dos mdulos desta Arquitetura de Software estar dependente desse
mdulo, no que lhe concerne das restries de segurana que podero ser expressas. Logo, o
MS depende do MPS relacionado as polticas que pretendem criar um processo para facilitar a
54
tarefa de encontrar, definir e gerenciar os servios disponibilizados. Por fim, as dependncias

dos mdulos MMS e MGAI para atender aos requisitos de confidencialidade e autenticidade
respectivamente dos servios prestados.
Assim como no diagrama de dependncia, o MGAI contm dependncia dos MPS e
MMS, deve-se ao fato do MMS ser o mecanismo padro de segurana necessrio para realizar
o intercmbio seguro de mensagens, atravs de certificados digitais e criptografia e pelo MPS
definir as polticas para criar, trocar e interpretar asseres de segurana entre entidades de uma
aplicao.
4.4
Viso Implementao
Este tpico prover uma viso da implementao da arquitetura do prottipo do sistema. A

arquitetura definida utiliza frameworks e tecnologias para agilizar o processo de desenvolvimento
sendo estruturados em camadas para desacoplar o cdigo fonte e facilitar futuras manutenes.
A Figura 4.4 apresenta a estrutura da arquitetura em camadas do sistema:
Figura 4.4: Arquitetura em Camadas
Fonte: Potts (2003) - adaptado.
A seguir, sero descritos cada um dos frameworks e tecnologias utilizadas nas camadas
da arquitetura do sistema:
WSDL: Conforme apresentado na Parte 2 na Seo 2.1.5, a WSDL, ser disponibilizada na camada de comunicao, fornecendo as funcionalidades presentes no Web
Service. Essas funcionalidades refletem as interfaces de servios disponibilizadas na
camada de negcio.
Spring Framework3 : Esse framework oferece diversos mdulos que podem ser
utilizados de acordo com as necessidades do projeto, como mdulos voltados para
desenvolvimento Web, inverso de controle e programao orientada a aspectos,
injeo de dependncias, desenvolvimento baseada em POJO e integrao com
tecnologias de persistncia e controle de transaes como Hibernate. Compatibilizase com Spring Cloud Security4 na proteo da transmisso de tokens entre SSO e
aplicaes nas nuvens.
3 https://goo.gl/oED3ey,

ltimo Acesso em Janeiro de 2016
4 http://cloud.spring.io/spring-cloud-security/,
4.5. VISO FSICA

4.5
55
Hibernate Framework5 : um framework para o mapeamento objeto-relacional

escrito na linguagem Java. Sua principal caracterstica a transformao das classes
em Java para tabelas de dados. O Hibernate gera as chamadas SQL e libera o
desenvolvedor do trabalho manual da converso dos dados resultante, mantendo o
programa portvel para quaisquer bancos de dados SQL.
Viso Fsica
O ambiente de nuvem privada adotado contemplado pela soluo VMware Integrated

OpenStack (K)ilo, suportando o VMware vSphere, especificamente o produto VMware ESXi
na verso 5.0.0. VMware ESXi um hypervisor6 que consiste na virtualizao do servidor,
armazenamento e rede, permitindo a execuo de vrios aplicativos em mquinas virtuais no
mesmo servidor fsico (VMWARE, 2009; ABDELRAZIK et al., 2015).
Conforme descrito por Damasceno (2015), as imposies causadas pelas legislaes
brasileira afetaram diretamente o uso da computao em nuvem pela administrao pblica
federal. Com objetivo de atender as estratgias das instituies como das Foras Armadas,
buscou-se a criao de ofertas de servios de nuvem privada consistentes dentro das fronteiras
do data center do Terceiro Centro Integrado de Defesa Area e Controle de Trfego Areo
(CINDACTA III).
Para validar a arquitetura de referncia proposta, a soluo de nuvem privada descrita
acima, utilizou 1 (uma) mquina servidora de aplicao rodando um hardware PowerEdge R710
da Dell7 . As configuraes do servidor de aplicao so:
4 processadores Intel(R) Xeon(R) CPU E5620 2.40GHz
64GB de memria RAM
300 GB de disco
4 Interfaces de Rede GigabitEthernet
Para executar os testes deste trabalho, a mquina servidora permitiu gerenciar mquinas
virtuais com as seguintes configuraes:
2 processadores
4GB de memria RAM
50 GB de disco
5 https://goo.gl/SLtiHm,

Hypervisor uma camada de software localizada entre a camada de hardware e o sistema operacional.
7 http://www.dell.com.br/, ltimo Acesso em Dezembro de 2015
6O
56
Sistema Operacional Linux Debian Squeeze8 de 64bits
Os testes foram realizados utilizando em um Notebook Dell Inspiron 14 Srie 5000 com
cliente de requisio ao servidor de aplicao. As configuraes da mquina do cliente so:
4.6
1 processador Intel(R) Core(TM) i7-4510U CPU 2.60GHz
16GB de memria RAM
1TB de disco
Sistema Operacional Windows 10 Home Single Language de 64bits
Cenrios
Esta Seo visa apresentar alguns dos principais cenrios, descritos em experimentos de
campo, da Arquitetura de Software proposta.
4.6.1
Desenvolvimento da Aplicao
Esta Subseo tem como objetivo demonstrar a utilizao prtica da especializao WSS,
WSP e SAML como parte do trabalho desta dissertao. Demonstra as principais atividades
dos servios oferecidos pela soluo proposta, implementado em um prottipo de um aplicao,
com objetivo de utilizar os principais conceitos relacionados segurana de WS nas mensagens
SOAP apresentados neste trabalho.
Inicialmente, a ferramenta Axis 2, que ser apresentada na prxima parte, gerou um WS
a partir da interface LogonServiceImpl.java do sistema. A interface como o WS gerado possui o
mtodo autenticar passando em dois parmetros: duas string apresentando o usurio e senha
referente as credencias de acesso a aplicao. O WS implementado, no arquivo AccessControl.wsdl, recebeu todos os servios propostos pela aplicao. O mtodo autenticar retorna ao
cliente uma mensagem no console de sucesso, de erro ou de exceo.
O Cliente do WS, por sua vez, implementou o arquivo WSLogonServiceClient.java,
atravs da classe LogonServiceImplStub.java realiza as chamadas aos mtodos da interface
do WS, enviando os dados necessrios para consumir os servios disponibilizados. Aps a
invocao do servio, o cliente recebe uma mensagem de sucesso, confirmando a transao da
operao ou uma mensagem de erro ou de exceo, informando que a transao no foi efetuada
corretamente.
A comunicao entre o cliente e o WS s realizada atravs do acordo entre as definies
das polticas de comunicao, atravs do lado do cliente pelo arquivo policyClient.xml e pelo lado
do WS o arquivo policyService.xml. Ambos definem a segurana desejada da mensagem SOAP
8 https://www.debian.org/,
ltimo Acesso em Dezembro de 2015
4.6. CENRIOS
57
do WS em estudo. Atravs dessas polticas de comunicao, a mensagem SOAP monitorada foi

composta pelos mecanismos de segurana definidos.
4.6.2
Experimento de Campo
Esta Subseo apresenta uma anlise dos padres WSS, WSP e SAML, destacando suas
aplicabilidades atravs de cenrios de experimentos de campo que visa avaliar estes padres
de segurana. A seguir, ser apresentada a parte de maior interesse para o presente trabalho: a
implementao de WS com objetivo de mitigar as cinco ameaas, descritas na Subseo anterior,
em nvel de servios e de transporte de mensagem. A anlise dos resultados foi feita usando-se
as ferramentas SoapUI 9 e Wireshark10 .
4.6.2.1
Estudo de Caso 01
Inicialmente, executamos o programa Wireshark para analisar o trfego da rede INTRAER. Especificamente, aplicamos a expresso de filtro: "http && ip.src = 10.80.8.85", com
objetivo de controlar o trfego de pacotes HTTP enviados pela mquina com o IP "10.80.8.85".
Conforme ilustrado na Figura 4.5, apresenta a requisio de um pacote HTTP, contendo uma mensagem SOAP. Percebe-se que as credenciais de acesso, destacadas em vermelho, so facilmente
obtidas pelo monitoramento da rede INTRAER.
Figura 4.5: Exemplo de pacote HTTP capturado pelo Wireshark

9 https://www.soapui.org/
10 https://www.wireshark.org/
58
O cenrio, apresentado, exemplificou o sequestro de credenciais de acesso de uma conta.

Diante do exposto e descrito na Seo 2.5.3, foi confeccionado o estudo de caso 01, com objetivo
de mitigar tais ameaas. Utilizou-se a especificao WSS, especificamente XML Signature, para
gerenciar as credencias declarada no cabealho da mensagem SOAP, e aplicado a tcnica de
autenticao de criao de senha com trs atributos. Assim, o formato da mensagem SOAP de
requisio representada:
Como pode ser observado na mensagem SOAP, demonstra a utilizao do elemento

<UsernameToken> (OASIS, 2012b) com o gerenciamento de credenciais declarada no cabealho
da mensagem SOAP. Este experimento inicializado quando o usurio (Web Service Client)
realiza uma requisio ao servio de segurana de tokens, solicitando um token vlido que ser
informado no elemento <wsse:Username>.
Em seguida a senha ocultada usando o algoritmo SHA1 codificado em base64 no
elemento <wsse:Password>. O resumo da senha a combinao do elemento nonce, o tempo
de criao, a partir do elemento <wsu:Created>, e mais a senha em texto claro. Esta funo,
passwordDigest, resumida em: Base64(SHA-1(Nonce + Created + Password)). O elemento
<wsse:Nonce> um nmero gerado aleatoriamente que adicionado mensagem, possuindo 16
bytes de comprimento e repassado com o valor base64 codificado. O hash da senha criado
a partir do momento da criao e de uso nico. O nonce nunca se repete, um servio gerencia
a criao do nonce para evitar ataques de replay, aonde a mesma mensagem capturada em
trnsito e re-enviada na tentativa de confundir ou interromper o servio, este controle realizado
pelo estrutura de cache de nonces usados pelo Servidor.
A mensagem SOAP enviada ao WS com as credenciais declarada, que realiza o mesmo
mecanismo de autenticao para recuperar a senha relacionado com o nome do usurio, o
Nonce e o tempo de criao da mensagem, gerando uma funo hash que validada com o
PasswordDigest da mensagem SOAP recebida. Se os resultados esto de acordo, o WS retorna
uma mensagem informando que autenticao foi realizada com sucesso.
recomendvel o uso de segurana em nvel de transporte na utilizao do mtodo
UsernameToken, como SSL (e.g. Hyper Text Transfer Protocol Secure (HTTPS)) ou o uso da
4.6. CENRIOS
59
especificao XML Encryption, pois as credenciais de acesso podem ser interceptadas a qualquer
um que seja capaz de monitorar a mensagem.
A especificao WS-PolicySecurity foi utilizada para definir polticas no esquema de
autenticao e na seleo do protocolo de transporte. O elemento <sp:UsernameToken> contem
o atributo IncludeToken para definir o tipo de fluxo de mensagens especificando a incluso de
token e o elemento <sp:HttpsToken>, aninhada com o elemento <wsp:Policy>, foi declarado
para utilizar o protocolo de transporte seguro, conforme exemplificado no arquivo XML a seguir:
Note, na XML descrita, o atributo Id identifica o conjunto da poltica de segurana como

um todo. Para aplic-la, o elemento <wsp:PolicyReference> foi declarado informando seu
atributo URI para referenciar a poltica em questo, em nvel de servio (autenticar) do trecho do
arquivo WSDL. Conforme exemplificado abaixo:
60
A conexo segura, utilizou o protocolo HTTPS, foi estabelecida a partir das configuraes
realizadas no Apache Tomcat, conforme descrito no Apndice A.
4.6.2.2
Estudo de Caso 02
Este estudo de caso tem como objetivo demonstrar a aplicabilidade das especializaes
XML Digital Signature e XML Encryption, conforme apresentadas nas Subsees 2.2.2 e
2.2.3 respectivamente. O experimento de campo a seguir, baseia-se nas regras para gerar e
validar assinaturas digitais no cabealho da mensagem SOAP e nas encriptaes dos elementos
declarados no corpo da mensagem SOAP.
4.6. CENRIOS
61
62
Atravs da anlise do cabealho da requisio SOAP, expresso pela XML acima, nota-se
a criao do elemento EncryptedKey definindo a chave que ser usada para cifrar os dados. O
mtodo usado para cifrar a chave o RSA verso 1.5. Outro elemento criado foi o KeyInfo que
possui vrias informaes sobre a chave, como por exemplo, o tipo do certificado utilizado, que
no caso X509v3.
O elemento KeyInfo indica tambm a chave a ser usada para validao da assinatura. O
elemento BinarySecurityToken foi declarado para criao de um token binrio que vai ser usado
na assinatura da mensagem. Aps a criao do token iniciada a criao da assinatura em si
com o elemento Signature. Dentro do elemento Signature, temos vrias configuraes referentes
assinatura, que so:
SignatureMethod: especifica o algoritmo usado na assinatura, no caso, RSA-SHA1;

DigestMethod: especifica o mtodo usado para criar o resumo criptogrfico, que no
caso foi o SHA-1;
DigestValue: valor do resumo criptogrfico.
Depois de especificadas as configuraes da assinatura, podemos ver o valor da assinatura

que est no elemento SignatureValue. Ainda dentro da assinatura, temos informaes sobre a
chave usada, onde, como podemos ver, foi usado o token binrio criado anteriormente.
Tambm temos outro elemento, o Timestamp, igualmente importante para a assinatura,
pois ele possui a data de criao e de expirao da assinatura. O usurio define o tempo de
expirao, geralmente em segundos. Caso o servidor identifique a mensagem em um tempo
maior do que o declarado, a mensagem SOAP rejeitada. A utilizao correta dessa tag faz
necessrio que seja disponibilizado um servio de sincronizao dos relgios do servidor e do
cliente, para evitar que as mensagens SOAP vlidas sejam rejeitadas.
Aps a especificao das informaes da chave, o padro XML Encryption permitiu cifra
a contedo do corpo da mensagem SOAP informando no elemento CipherValue. Aninhado com
este elemento, definido o mtodo que ser usado para cifrar os dados (EncryptionMethod), que
o triple DES em modo cbc.
Desse modo, termina o cabealho da requisio SOAP onde foram criados a chave e a
assinatura necessrios para cifrar e assinar o documento XML.
4.6. CENRIOS
63
64
A resposta da mensagem SOAP exibida acima, idntica a requisio que a originou,

com a chave e assinatura definidos no cabealho e o corpo da mensagem cifrado.
4.6. CENRIOS
65
A especializao WS-Policy, descrita na XML acima, foi declarada no WSDL e definido

um ID para uma poltica, Rule1. Aninhado com o elemento <wsp:Policy>, o elemento <wsp:All>
exige que todas as polticas compreendidas devem ser atendidas. A poltica foi concebida com
objetivo de transmitir condies de uma interao entre o cliente e o servidor.
Dessa forma, o elemento <sp:AsymmetricBinding> foi declarado para indicar um vnculo
de segurana de criptografia assimtrica obrigatria. O elemento <sp:X509Token>, aninhado
com o elemento <sp:ProtectionToken>, indica que o certificado X.509 v3 utilizado com a
criptografia Triple DES em modo cbc, para ser usado por ambas as partes no proteo em troca
de mensagem.
O elemento <sp:TransportBinding> usado para especificar a segurana do transporte
de mensagens e correlao de segurana fornecida por outros meios, no caso, um transporte
seguro utilizando o protocolo HTTPS, conforme definido pelo elemento <sp:TransportToken>.
A declarao obrigatria do elemento <sp:AlgorithmSuite> define o algoritmo necessrio para
a realizao das operaes criptogrficas com tokens de segurana simtrica. O elemento
<sp:Layout> foi declarado para indicar um requisito rigoroso no layout de segurana do cabealho da mensagem SOAP com propriedade e o elemento <sp:IncludeTimestamp> defini uma
janela de tempo durante o qual a requisio ser vlida.
E por fim, o elemento <sp:EncryptedParts>, contm um elemento <sp:Body/> aninhado,
o que significa que o corpo da mensagem SOAP obrigado a ser criptografado.
As especificaes XML Digital Signature e XML Encryption so componentes importantes na segurana no transporte de dados da mensagem SOAP e no consumo dos servios
disponibilizados. Fornece um mecanismo de assinatura digital muito flexvel. A especializao
WS-Policy, por sua vez, prover uso de polticas que definem como os servios disponibilizados
esto autorizados a interagir com outros clientes e servios.
4.6.2.3
Estudo de Caso 03
O estudo de caso 03 apresenta a tecnologia SAML baseado no mecanismo de autenticao

Single Sign-On (SSO). O Diagrama de Sequncia apresentado na Figura 4.6, ilustra a sequncia
de mensagens entras as entidades: Provedor de Identidade (IdP), Provedor de Servio (SP) e
o usurio/aplicao. Dessa forma, este estudo de caso pretende apresentar duas mensagens
SOAP, com declaraes SAML, incluindo um pedido de requisio de autenticao e a ltima
mensagem de resposta da autenticao contendo uma assero SAML.
66
Figura 4.6: Diagrama de Sequncia Estudo de Caso 03
A especificao WSS especifica assertivas ou tokens de segurana SAML integrada no

mecanismo de segurana da mensagem SOAP.
A mensagem SOAP apresentada acima, descreve implementaes capaz de processar
4.6. CENRIOS
67
referencias de assero SAML que ocorrem em um elemento <wsse:Security> do cabealho da

mensagem SOAP. O elemento <wsse:SecurityTokenReference> declarou um token de segurana,
com objetivo em assinar as asseres do SAML. A aplicao assume um usurio com a conta
tiad@cindacta3.aer.mil.br, declarado no elemento <samlp:Subject>, est tentando consumir um
servio declarado no WS.
O elemento <saml:Assertion> define o local, ligao, e consulta que podem ser utilizados
para adquirir a afirmao identificada em uma assero SAML. O valor do atributo ID do
elemento <samlp:AuthnRequest> enviado para o provedor de identidade (IdP) do Servio de
SSO que inclui autenticao e autorizao.
68
Nesta etapa, apresentada a mensagem SOAP de resposta do SAML indicando que

o usurio tiad@cindacta3.aer.mil.br est autorizado a acessar o servio, confirmado pela tag
<samlp:StatusCode>. Dessa forma, todas as afirmaes SAML so incorporadas na mensagem
de resposta, com objetivo da criao de um nico contexto de autenticao.
A mensagem de resposta SAML contm os seguintes elementos:
RESPONSE_ID: Uma string de 160 bits contendo um conjunto de caracteres gerados aleatoriamente.
ISSUE_INSTANT: Timestamp indicando a data e hora em que a resposta SAML foi
gerada.
ASSERTION_ID: Atributo da afirmao identificada da assero SAML.
NOT_BEFORE: Timestamp de controle para identificar a data e hora anterior a
resposta SAML considerada invlida.
NOT_ON_OR_AFTER: Timestamp de controle para identificar a data e hora aps
a resposta SAML considerada invlida.
AUTHN_INSTANT: Timestamp indicando a data e hora em que o usurio foi autenticado.
O estudo de caso 03 apresentou os mecanismo e procedimentos de segurana representada

pelas as asseres SAML na mensagem SOAP, juntamente integrada a especificao WS-Security.
A criao das asseres SAML integrada a especializao WSS permitiu realizar a comunicao
de autenticao e autorizao do usurio, e as informaes de atributos. Segurana de mensagens
SOAP no introduz novas ameaas alm das identificadas para SAML ou pelo WSS.
4.7
Consideraes Finais
Esta Parte iniciou-se apresentando o guia de descrio da arquitetura proposta, conhecido

como mtodo 4+1, mostrando-se bastante efetiva para o contexto desta dissertao.
4.7. CONSIDERAES FINAIS
69
Em seguida, a arquitetura proposta foi apresentada, de acordo com as vises desse

mtodo: Lgica (Seo 4.2), Dependncia (Seo 4.3), Implementao (Seo 4.4) e Fsica
(Seo 4.5). E por fim, foram analisados os cenrios de experimentos de campo a partir da
utilizao prtica das especializaes WSS, WSP e SAML.
Na prxima Parte ser descrita a avaliao da arquitetura proposta, bem como a utilizao
das normas de segurana abordadas ao longo deste trabalho, apresentando os resultados obtidos
pelos experimentos de campos analisados.
71
5
Avaliao da Proposta
Esta Parte descreve a avaliao da proposta, na busca de analisar as normas de segurana
em nvel de servio e de mensagem para WS. A abordagem dessa avaliao inicia-se pela
descrio da metodologia utilizada, objetivos e componentes necessrios para reproduzir os
experimentos de campo. Em seguida, so descritos os resultados obtidos quanto garantia
das propriedades bsica da segurana. E por fim, so apresentadas as concluses acerca dos
resultados dos estudos de caso.
5.1
Metodologia
A metodologia utilizada para avaliao baseou-se na abordagem GQM (Goal, Question,

Metric) proposta por Basili e Caldeira (1994), com intuito de proporcionar um formalismo e
planejamento quando medio dos resultados a serem obtidos nos experimentos de campo
submetidos aos estudos de caso. Conforme ilustrado na Figura 5.1, essa abordagem divide o
processo em quatro fases: 1. Planejamento; 2. Definio; 3. Coleta de Dados; e 4. Interpretao.
Figura 5.1: Fases da metodologia GQM
Fonte: Basili e Caldeira (1994).
72
5.1.1
5. AVALIAO DA PROPOSTA
Planejamento
A fase de planejamento trata-se da logstica de aplicao do GQM e principais plano de

projeto, no qual se descreve o ambiente, ferramentas e o que ser avaliado. O primeiro passo
deste trabalho foi realizar a implantao e desenvolvimento dos estudos de caso descritos na
Parte 4. O experimento de campo tem como objetivo conduzir um cenrio real, a fim de testar
uma determinada causa de efeito. Para a realizao dessa avaliao, foram estudadas as tcnicas
e os padres descritos nas documentaes publicadas pelas organizaes W3C e OASIS, guiando
a implementao da arquitetura.
5.1.1.1
Publico alvo e cenrio de atuao
O pblico alvo so os usurios que utilizam os sistemas administrativos da Seo da

Informtica Administrativa (TIAd) do CINDACTA III, portanto, o cenrio de atuao.
O CINDACTA III uma organizao militar do Comando da Aeronutica (COMAER) e
subordinado diretamente ao Departamento de Controle do Espao Areo (DECEA). tambm
uma Organizao regional, dispondo, alm de sua Sede em Recife-PE, de dez Destacamentos de
Controle do Espao Areo (DTCEA) localizados em Recife-PE, Parnamirim-RN, Fortaleza-CE,
Rio Largo-AL, Aracaju-SE, Salvador-BA, Porto Seguro-BA, Fernando de Noronha-PE, Bom
Jesus da Lapa-BA e Petrolina-PE.
O data center, dos sistemas administrativos, localizado no CINDACTA III e de responsabilidade do Chefe da Seo da TIAd. A Seo da TIAd concentra toda infraestrutura necessria
para implantao de Nuvem Privada dos sistemas administrativos, que so acessados por todos
os Destacamentos Subordinados do CINDACTA III atravs da Rede de Dados do Comando da
Aeronutica (INTRAER).
5.1.1.2
Critrio de Avaliao
O estudo selecionou as cinco ameaas mais crticas classificadas pelo referido relatrio
da CSA, usado dois critrios: As ameaas classificadas pelo modelo SaaS e pelas propriedades
bsicas de segurana. Tais critrios foram delineados com foco da avaliao dos objetivos deste
trabalho.
Seguindo os critrios anteriormente mencionados, os estudos de caso sero avaliados em
sua completude de garantir as propriedades bsicas de segurana das 5 ameaas selecionadas.
Conforme abordado as ameaas na Subseo 2.5.3, a CSA apresenta a anlise de risco, a partir
da Tabela 5.1 de forma sumarizada, das principais propriedades de segurana afetadas por cada
uma das ameaas.
5.1. METODOLOGIA
73
Tabela 5.1: Propriedades de segurana afetadas por ameaas

```
```
``` Ameaas Vazamento
```
de Dados
Propriedades
``
`
Confidencialidade
Integridade
Disponibilidade
No Repdio
Autenticao
Perda
de Dados
X
X
X
Sequestro
de Contas
Interfaces
Inseguras
X
X
X
X
X
X
X
Negao
de Servios
X
X
Fonte: CSA (2013).
A CSA tambm classificou, em sua anlise de risco, uma srie de ataques que podem
utilizar as ameaas analisadas. Na Tabela 5.2 apresentada de forma sumarizada qual ataque
aplicado a cada ameaa.
Tabela 5.2: Ataques utilizados para cada ameaa
XX
XXX
XXAmeaas
XXX
Ataques
XX
Spoofing
Adulterao de Dados
Divulgao de Informao
Repdio
Negao de Servio
Elevao de Privilgios
Vazamento
de Dados
Perda
de Dados
X
X
X
Sequestro
de Contas
Interfaces
Inseguras
X
X
X
X
X
X
X
Negao
de Servios
X
X
Fonte: CSA (2013).
De posse dos experimentos de campo, os estudos de caso contemplam assim os requisitos

necessrios para a avaliao da arquitetura de referncia com base nas normas e implementaes
de segurana propostas neste estudo.
5.1.2
Definio
Na fase de definio deve-se definir os objetivos do GQM, as questes a serem respondidas e definir e refinar as mtricas, seguindo a estrutura conforme ilustrada na Figura 5.2 e
desenvolvido na Tabela 5.3.
Os prottipos desenvolvidos, com base nos estudos de caso, iro disponibilizar servios
que sero consumidos pela ferramenta soapUI, em seguida a ferramenta de monitoramento
Wireshak ir auxiliar na anlise do comportamento de requisio e resposta entre as partes
envolvidas.
74
Figura 5.2: Estrutura da Fase de Definio
Fonte: Basili e Caldeira (1994) - adaptado.
O objetivo esperado que as tecnologias de servio seguros propostos pela normas

WSS, SAML e WSSP garantam as propriedades bsicas de segurana das servios providos. As
mtricas so baseadas nos principais recursos oferecidos por essas normas descritas neste estudo.
A escala foi definida de acordo com a mitigao das ameaas de cada mtrica e garantia dos
atributos bsicos de segurana.
5.1. METODOLOGIA
75
Tabela 5.3: Definio das Questes e Mtricas para avaliao
Questes
Descrio
Mtricas
Contexto
Escala
Estudo de Caso 01
Subseo 4.6.2.1
0 - No se aplica
1 - Fraco
2 3 - Razovel
4 - Satisfatrio
5 - Excelente
Estudo de Caso 02
Subseo 4.6.2.2
0 - No se aplica
1 - Fraco
2 3 - Razovel
4 - Satisfatrio
5 - Excelente
Estudo de Caso 03
Subseo 4.6.2.3
0 - No se aplica
1 - Fraco
2 3 - Razovel
4 - Satisfatrio
5 - Excelente
Vazamento de Dados
Subseo 2.5.3.1
[Q1] Quo eficaz a

proteo das
tecnologias utilizadas
no Estudo de Caso 01
diante das ameaas?
Perda de Dados
Subseo 2.5.3.2
Sequestro de Contas
Subseo 2.5.3.3
1. XML Signature
2. Security Tokens
3. WS-SecurityPolicy
4. HTTPS
Subseo 2.5.3.4
Negao de Servio
Subseo 2.5.3.5
Vazamento de Dados
Subseo 2.5.3.1
[Q2] Quo eficaz a

proteo das
diante das ameaas?
Perda de Dados
Subseo 2.5.3.2
Sequestro de Contas
Subseo 2.5.3.3
Subseo 2.5.3.4
1. XML Signature
2. XML Encryption
3. WS-Policy
4. Certificado Digital
5. Criptografia
Triple DES
em modo cbc
6. HTTPS
Negao de Servio
Subseo 2.5.3.5
Vazamento de Dados
Subseo 2.5.3.1
[Q3] Quo eficaz a

proteo das
diante das ameaas?
Perda de Dados
Subseo 2.5.3.2
Sequestro de Contas
Subseo 2.5.3.3
1. SAML
2. XML Signature
Subseo 2.5.3.4
Negao de Servio
Subseo 2.5.3.5
76
5.1.3
Coleta de Dados
A coleta de dados foi realizada com base nas questes e mtricas definidas na seo
Descrio. As mtricas foram obtidas por meio da execuo de Teste Funcionais que tem como
objetivo demonstrar a operacionalidade das funes que foram especificadas. Na Engenharia de
Software, o Teste Funcional realizado olhando-se o software apenas atravs de suas interfaces.
Como o objetivo a mitigao das ameaas, discutidas nas partes anteriores, dos servios
providos, portanto o mtodo de avaliao ser baseado em testes funcionais, tambm conhecidos
como caixa preta.
Os participantes dessa avaliao foram as ferramentas soapUI e Wireshark, que executaram as mtricas para avaliar o comportamentos dos mecanismos de segurana usados como
padro nos WS. Cada tecnologia foi avaliada a partir dos cenrios definidos, tambm foram
avaliadas a combinao das tecnologias de segurana aplicadas nos estudos de caso.
Utilizou-se a ferramenta Apache eXtensible Interaction System 2 (Axis 2) para implementar o prottipo, com necessidade de um mecanismo de processamento SOAP para analisar
sintaticamente as mensagens recebidas e para chamar os mtodos que a mensagem indica.
O Axis 2 um projeto open source da Apache Software Foundation1 e est atualmente
na verso 1.7.0. O Axis 2 trata-se de um projeto desenvolvido pela Apache para proporcionar
muitos recursos no presentes na implementao atual do SOAP Apache. Axis 2 fornece as
ferramentas necessrias para trabalharmos com os Web Services de forma fcil e simplificada.
Utilizou-se, tambm, o mdulo Rampart2 do Apache Axis2 na verso 2.1.4 para fornecer as
implementaes de segurana para o mecanismo de servios da Web do Axis2 referente as
especificaes propostas.
A arquitetura do Apache Axis 2 construda sobre o alicerce de um mecanismo SOAP.
No diagrama exibido na Figura 5.3, ilustra a sequncia numerada das etapas para a consumao
de servios disponibilizado pelo WS.
Figura 5.3: Workflow do ciclo de vida do Apache Axis 2
Fonte: Apache (2015) - adaptado.
Os itens a seguir descrevem os passos necessrios ao processamento de uma requisio

1 http://www.apache.org/,

2 https://axis.apache.org/axis2/java/rampart/,
5.1. METODOLOGIA
77
de entrada para WS alvo seguindo o modelo da arquitetura Axis 2 apresentado na Figura 5.3.
Passo 1 - O cliente (WSLogonServiceClient.java) constri uma requisio do SOAP

usando a classe LogonServiceImplStub.java, especificamente a URI de destino, os
detalhes do servio (como o nome do servio, o nome do mtodo e parmetros de
entrada). A seguir, a mensagem SOAP enviada pelo cliente ao n do processamento
da mensagem do Axis 2, no receptor de transporte. A mensagem SOAP do cliente,
neste ponto, est em um formato especfico quanto ao protocolo e as polticas de
seguranas exigidas (policyClient.xml e policyService.xml).
Passo 2 O receptor de transporte converte a mensagem vinda do cliente em um
objeto Message e o inclui em um objeto MessageContext. Ele tambm carrega vrias
propriedades como atributos do SOAP (cabealho SOAP) e define a propriedade
transportName no MessageContext. Desta forma, a mensagem SOAP enviada ao
dispatcher.
Passo 3 O dispatcher responsvel pelo caminhamento da requisio ao WS de
destino.
Passo 4 WS (AccessControl.wsdl) executa o mtodo e retorna a resposta ao dispatcher,
Passo 5 que encaminha a resposta ao remetente do transporte.
Passo 6 O remetente do transporte, junto com o objeto do contexto do transporte,
envia a mensagem SOAP de volta atravs do protocolo de rede ao requisitante. O
objeto do contexto do transporte encapsula os detalhes do receptor do transporte,
o contexto relacionado ao iniciador da requisio e o destino da resposta/falha da
mensagem, os detalhes da sesso e etc.
A arquitetura do Axis 2 pode ser facilmente integrada qualquer aplicao web, independente do container. Nas prximos Sees, ser detalhada a arquitetura do Apache Axis2.
O container Apache TomCat foi utilizado como servidor web do prottipo. O WS e o
cliente do prottipo foram implementados atravs das ferramentas Axis 2 e IDE Eclipse3 Mars
4.5 utilizando linguagem de programao Java. As polticas de segurana do prottipo foram
implementadas conforme as especificaes desejadas e de forma autnoma usando a biblioteca
Apache Commons Policy 1.0.
A criao de um cliente teve como objetivo realizar as chamadas dos servios e aplicar
os mecanismos de segurana: WSS, WSP e SAML. Foram criadas definies de polticas tanto
do lado do cliente quanto do lado do WS, policyClient.wsse e policyService.wsse, enfatizado a
WS-SecurityPolicy que especializa a WS-Policy para polticas de segurana. A poltica definida
3 http://www.eclipse.org/,
78
teve finalidade de expressar os requisitos de segurana de forma declarativa, importando como o

servio pode ser invocado com segurana no transporte ou com segurana na mensagem.
A configurao dessas polticas de segurana teve por objetivo a segurana em nvel
de transmisso de dados ou da mensagem, objetivando atender os requisitos de identificao,
autenticao, integridade, privacidade e no-repdio.
5.1.4
Anlise dos Resultados
Com base na Tabela 5.3, foram submetidos trs estudos de caso aos testes destes experimentos de campo, com os resultados obtidos pela pelas ferramentas de monitoramento. As
pesquisas publicadas por Goettelmann et al. (2015) e Mohapatra, Gulati e Luthra (2012)
guiaram na interpretao e qualificao das escalas.
Observou-se que em alguns casos a escala foi definido um nvel de qualificao como
"Satisfatrio", outro se estendem at o "Excelente". Os casos como ausncia definio do nvel
refere-se aos ambientes de teste que, devido falta de cenrios prontos e o tempo e esforo para
desenvolv-los, no contemplam todos os aspectos de ameaas descritos no estudo.
Em contrapartida, esses estudos de caso abrangem os comportamentos mais elementares
levantados nesta pesquisa.
Alm disso, todos os aspectos pertinentes s ameaas em CN esto de acordo com os
estudos de casos proposto. Outro fato relevante que os falso positivos no foram considerados
nestes testes, uma vez que o estudo atribui o fator humano responsvel pela correes dos erros
da anlise. Sendo assim os estudos de caso apresentados foram definidos como ameaas reais
aos servios providos. Nesta seo sero descritas as consideraes do estudo realizando com
base nos resultados extrados para as questes citadas na Tabela 5.3.
Resultado da Questo 01
O grfico da Figura 5.4 apresenta a execuo dos mecanismos de segurana utilizados
no Estudo de Caso 01 das especificaes WSS e W SP. Sua validao serviu com base para
identificao do problema de aumento do tempo de resposta durante a sobrecarga do sistema
diante da injeo de ataques, como negao de servio e XML Injection. Assim, a ferramente
SoapUI facilitou todo o processo de criao e depurao dos testes por meio de sua interface
grfica.
Durante a execuo dos testes medido o tempo de resposta em milissegundos de
requisies com tokens vlidos e com tokens invlidos. Assim, o tempo mdio de resposta, para
uma requisio de gerao e validao de token vlido, aproximado de 550 milissegundos. Em
contrapartida, o tempo mdio de resposta, para uma requisio de gerao e validao de token
invlido, aproximadamente de 810 milissegundos.
Conforme observado no grfico d a F igura 5 .4, a d iferena d o t empo d e r esposta
aproximadamente 45% mais rpido que o mesmo cenrio sem a soluo. Essa performance
5.1. METODOLOGIA
79
devido ao uso de credenciais de segurana, mais conhecida como Security Tokens, que comprova
a identidade do emissor e permite acesso aos servios do provedor, sempre e quando o provedor
realiza a validao do passwordDisgest. Por outro lado, a soluo sem segurana no realiza
a validao das credenciais de acesso e faz com que o servidor retorne o status de requisio
"HTTP 400 Bad Request" ou "HTTP 500 Internal Server Error" descrevendo um erro de
sintaxes na resposta.
Figura 5.4: Anlise do aumento do tempo de resposta
Fonte: prpio autor.
Alm disso, a arquitetura proposta proveu segurana fim-a-fim para aplicaes que
necessitam realizar trocas de dados de forma segura, e em conjunto, a especializao WSSecurityPolicy possibilitou a declarao o uso do protocolo HTTPS para conexes seguras. E
por fim, a criao de uma cadeia aleatria (nonce), permitindo rejeitar as mensagens SOAP
manipuladas com intuito de sobrecarregar o sistema. A aplicao manteve um tempo de resposta
para os clientes abaixo de 400 milissegundos.
80
Figura 5.5: Resultados da avaliao da Questo 01
Fonte: prpio autor.
Seguindo a anlise das especializaes XML Digital Signature, XML Encryption e
WS-Policy, conforme implementado no estudo de caso 02, obteve-se os resultados ilustrado na
Figura 5.6.
A especializao XML Digital Signature garantiu os atributos de autenticidade, integridade e permitiu suporte para no repdio aos dados assinados. Uma caracterstica fundamental
da XML Digital Signature, permitida no experimento, a capacidade de assinar apenas partes
especficas da mensagem SOAP, essa flexibilidade importante para garantir o atributo de
integridade dessas partes. Outra caracterstica para garantir integridade, desta especializao,
a troca de mensagens assinadas, permitindo a validao do documento a partir da assinatura
includa na mensagem conforme demonstrado neste estudo de caso.
Desta forma, os atributos de autenticidade, integridade e no repdio receberam a classificao de "Excelente", devido as regras de processamento de assinatura digital. A propriedade
no repdio foi assegurada pela utilizao da criptografia assimtrica.
Por sua vez, o padro XML Encryption demonstrou a capacidade de codificar o contedo
do corpo da mensagem SOAP, fornecendo qualidade de proteo atravs de integridade, confidencialidade e autenticao nica de mensagens. Por esse motivo, a propriedade confidencialidade
recebeu a escala quatro de "Satisfatrio".
E por fim, as afirmaes declaradas da especializao WS-Policy permitiram definir
como os servios disponibilizados esto autorizados a interagir com outros usurios e servios.
Portanto, o atributo disponibilidade obteve o grau quatro, "Satisfatrio", na escala.
5.1. METODOLOGIA
81
Fonte: prpio autor.
Uma das principais dificuldades de realizar esse cenrio de teste se concentrou na tarefa
de estabelecer a relao de confiana entre o provedor de identidade, pelo protocolo LDAP,
e o provedor de recursos utilizando SAML. Contriburam para essa dificuldade a falta de
experincia com esse protocolo e sua complexidade. Uma vez superada essa etapa, foi necessrio
a configurao do servidor AD apropriado, estabelecendo a relao de confiana entre o provedor
de identidade e o provedor de recursos proposto pelo padro SAML.
Para medir os testes, pode-se avali-lo com base nos resquisitos da arquitetura proposta:
Conforme descrito na Figura 5.7, o framework SAML apresentou um comportamento
excelente na preservao dos atributos de integridade, autenticidade e autorizao. O experimento
analisado no estudo de caso 03, permitiu analisar a criao da soluo SSO, a qual estabeleceu
um crculo de confiana atravs do intercmbio das mensagens SOAP entre as entidades IdP
e SP. A SAML tambm permitiu melhorar a produtividade na redefinio das credenciais de
segurana para uma mesma identidade, garantido assim a propriedade de disponibilidade. A
utilizao dessa abordagem se faz comum em ambiente de nvel INTRANET.
O padro WS-Security permitiu a declarao de um token de segurana, auxiliando a
especializao no suporte autenticao com proteo de integridade em nvel de mensagem.
82
Fonte: prpio autor.
5.2
Limitaes da Avaliao
Devido s restries de ferramentas, no foi possvel desenvolver um ambiente controlado

capaz de avaliar todas as variaes de ameaas possveis acerca dos dados do usurio, os quais
foram apresentados por este estudo, oferecendo assim um nmero ainda maior de mtricas a
serem submetidas nas questes de avaliao. Este crescimento na diversidade das mtricas
poderia proporcionar uma anlise mais quantitativa, o que em tese garantiria uma maior preciso
quanto aos resultados obtidos nos testes. Alm disso, no foi possvel realizar uma anlise
comparativa em relao aos mecanismos de segurana devido as limitaes disponveis no
mbito das ferramentas apresentadas.
Outra limitao identificada, foi a respeito da infraestrutura de rede dos destacamentos
localizados em Rio Largo-AL, Fernando de Noronha-PE e Bom Jesus da Lapa-BA, onde o
desempenho da rede INTRAER considerado insatisfatrio, fazendo com que o tempo de
requisio e resposta sejam maior que 5 segundos, comprometendo a soluo de validao do
tempo de expirao da mensagem SOAP.
A prxima Parte ir abordar sobre os mecanismos de segurana estudados, bem como
apontar melhorarias e trabalhos futuros.
83
6
Consideraes Finais
Os Web Services firmaram-se no cenrio de comunicao em ambientes de nuvem como
forma de integrao entre organizaes, aplicaes e processos de negcio. O advento do Web
Services quebrou alguns paradigmas de segurana. Existe agora a possibilidade de garantir
segurana dentro do prprio, tal faanha possvel com o uso de padro SOAP e como protocolo
de transporte HTTP.
As tecnologias estudadas e analisadas ofereceram a proteo de mensagens: como
proteger o contedo das mensagens e dos servios, garantindo a proteo necessria para
confidencialidade, integridade, disponibilidade, no-repdio e autenticidade.
No estudo de caso, foi usado a ferramenta Apache Axis 2, que implementou a arquitetura
do prottipo e facilitou o uso dos principais padres de seguranas abordados ao longo deste
trabalho. O prottipo desenvolvido possibilitou demonstrar a aplicao prtica do padro WSSecurity, WS-Police e SAML. Permitiu, ainda, a realizao de uma anlise, atravs da execuo
e observao das mensagens trocadas entre o WS e o cliente, ambos implementados no estudo
de caso deste trabalho.
Mesmo existentes solues de mercado e solues comerciais, devido natureza do
negcio e estratgica como das foras armadas, essas solues podem vir a no atender todas as
necessidades exigidas e demandariam customizaes que, na sua grande maioria, no seriam
atendidas pelos grandes empresas como VMware, IBM e HP, j que que suas solues so
padronizadas Damasceno (2015).
As especificaes de segurana para o ambiente dos Web Services esto alcanando
maturidade notvel. Permitindo a possibilidade de oferecer ao mercado e aos clientes o fator
fundamental da arquitetura de segurana para Web Services. Para oferecer novas aplicaes de
Web Services ao mercado e aumentar a segurana de suas atuais aplicaes de Web Services
necessrio o uso das recomendaes das normas de implementaes e a padronizao do
gerenciamento de polticas, sendo estas uma infraestrutura confivel no ambiente em nuvem
privada segura.
84
6.1
6. CONSIDERAES FINAIS
Contribuies
A principal contribuio deste trabalho foi a definio e especificao de uma arquitetura

de software de referncia para implementao de ambientes de nuvem em uma organizao
militar, respeitando a legislao corrente s recomendaes para o uso de computao em nuvem
privada pelo governo federal.
Outra contribuio, no menos importante, foi a vantagem do padro WS-Security
suportar a vrios tipos de protocolos e tokens. Entretanto, ele no oferece informaes de como
deixar esses protocolos seguros.
A ferramenta Axis 2 suportou asseres SAML no caso de uso realizado, mas o mdulo
de segurana ainda est muito instvel. A documentao pouca e, em geral, de m qualidade.
Desta forma, fica uma sugesto para trabalhos futuros.
Nenhuma ferramenta atualmente disponvel no mercado permite realizar negociao de
polticas de forma integrada. No prottipo, a negociao de polticas foi efetuada para exemplos
simples e de forma autnoma.
A poltica descrita no caso de uso muito importante, pois possibilita a configurao
de segurana utilizada. Desta forma, aumenta o contedo da mensagem consideradamente,
tornando-a complexa.
Os Web Services seguem no bom caminho, no que respeita a segurana, os mecanismos
analisados suportaram o cenrio mais comum na soluo dos problemas como identificao,
autenticao, integridade, privacidade, no-repdio e evoluo das polticas de segurana nas
mensagens.
6.2
Trabalhos Futuros
Como sugesto para trabalhos futuros, um tema no abordado neste trabalho, mas que,
sem dvida, importante ao ponto de ser fonte de inspirao para os mecanismos de segurana
expostos nesta pesquisa, a necessidade de estudar os ataques e vulnerabilidades atravs das
falhas em aplicaes, tratando dos padres de segurana como agente minimizadores de riscos
abordado no artigo de Vieira (2010).
Na continuidade do presente trabalho, poderia ser explorado o estilo REST como mecanismo de suporte para comunicao segura, similar apresentado por Kumari e Rath (2015) em
seu artigo. Alm disso, tambm poderia ser explorado um arquitetura segura que abrangessem
os modelos de servios como Platform as a Service (PaaS) e Infrastructure as a Service (IaaS).
85
Referncias
ABDELRAZIK, A. et al. Adding Speed and Agility to Virtualized Infrastructure with
OpenStack, 2015. Disponvel em: <https://goo.gl/InIokG>. Acesso em: 8 dez. 2015.
APACHE. Apache Axis2 Architecture Guide, 2015. Disponvel em: <https://
axis.apache.org/axis/java/architecture-guide.html>. Acesso em: 5 jan. 2016.

al. A View of Cloud Computing.
Communications of the ACM, 2010, v.53, n.4, p. 50 58.
ARMBRUST,
M.
et
New
York, US:
BARRY, D.; DICK, D. Cloud Computing. In: WEB services, service oriented
architectures and cloud computing. 2th. Boston: Elsevier, 2013. cap. 4, p. 35 44.
ROMBACH, H. Experience factory. In:

MARCINAIK, John J. (Ed.). The goal question metric paradigm. New York:
Encyclopedia of Software Engineering, 1994. p. 469 - 476.
BASILI,
V.;
CALDEIRA,
G.;
CELESTI, A.; TUSA, F.; VILLARI, M.; PULIAFITO, A. Security and cloud computing:
intercloud
identity
management
infrastructure.
In: INTERNATIONAL
WORKSHOP ON ENABLING TECHNOLOGIES: INFRASTRUCTURES FOR
COLLABORATIVE ENTERPRISES (WETICE), 19., 2010, Washington. Anais...
Washington: IEEE Press, 2010. p. 263 265.
CSA. Security Guidance for Critical Areas of Focus in Cloud Computing V3.0, 2011.
Disponvel em: <https://goo.gl/DCOQM>. Acesso em: 15 fev. 2015.
CSA. The Notoriuous Nine Cloud Computing Top Threats in 2013, 2013. Disponvel em:
<https://goo.gl/yHqONF>. Acesso em: 15 fev. 2015.
CSER, A. et. al. The Forrester Wave: public cloud platform service providers'
security, q4, 2014. Disponvel em: <https://goo.gl/CvUiYk>. Acesso em: 15 nov. 2015.
DAMASCENO, J. C. UCloud: Uma Abordagem para Implantao de Nuvem Privada
para a Administrao Pblica Federal. 2015. Tese (Doutorado em Cincia da
Computao) Universidade Federal de Pernambuco, Centro de Informtica, Recife. 2015.
171p.
EPING. Padres de Interoperabilidade de Governo Eletrnico, 2016. Disponvel em:
<http://goo.gl/8jNLGV>. Acesso em: 15 jan. 2016.
FERREIRA, A. S. Uma arquitetura para monitoramento de segurana baseada em

acordos de nveis de servio para nuvens de infraestrutura. 2013. Dissertao
(Mestrado em Cincia da Computao) Universidade Estadual de Campinas, Campinas.
2013.
86
REFERNCIAS
FIXYA. Cloud Storage Report, 2012. Disponvel em: <http://www.fixya.com/reports/

cloud-storage>. Acesso em: 15 jan. 2016.
GOETTELMANN, E. et. al. Information systems engineeringin complex environments:
CAiSE Forum
2014,
Thessaloniki,
Greece,
june
16-20,
2014,
Selected
Extended Papers. In: NURCAN, S.; PIMENIDIS, E., 2th ed. Cham: Springer
International Publishing, 2015. p. 3 19.
GONZALEZ, N. M. Proposta de arquitetura e soluo de gerenciamento de credenciais
para autenticao e autorizao em ambientes de computao em nuvem.
2014. Dissertao (Mestrado em Cincia da Computao) Escola Politcnica da
Universidade de So Paulo, So Paulo, 2014.
HOLGERSSON, J.; SODERSTROM, E. Web service security - vulnerabilities and
threats within the context of WS-security. In: STANDARDIZATION AND
INNOVATION
IN INFORMATION TECHNOLOGY (SIIT), 4., 2005, Geneva.
Anais... Geneva: IEEE, 2005. p.138146.
IBM. Idias de computao em nuvem experincia em 110 projetos de implementao.
International business machines. Nova Iorque: Pesquisa da Academia de Tecnologia da IBM.
2010. 7p.
ISO/IEC. ISO/IEC 27002:2013 tecnologia da informao tcnicas de segurana cdigo

de prtica para controles de segurana da informao, 2013. Disponvel em: <http://
goo.gl/l2kj02>. Acesso em: 18 nov. 2015.
KRUCHTEN, P. B. The 4+1 view model of architecture. IEEE Software, 1995. v.12,
n.6, p.4250.
KUMARI, S.; RATH, S. K. Performance comparison of SOAP and REST based web services
for enterprise application integration. In: INTERNATIONAL CONFERENCE ON
ADVANCES IN COMPUTING, COMMUNICATIONS AND INFORMATICS

(ICACCI), 2015, Kochi. Anais... Kochi: IEEE Xplore, 2015. p.16561660.
M. Web services: security challenges. In: INTERNET
(WORLDCIS), 2011, Lodon. Anais... Lodon: IEEE Press, 2011. p.160163.
LADAN,
SECURITY
LU, Q.; ZHU, L; BASS L.; XU, X.; LI, Z.; WADA. H. Cloud API issues: an empirical
study and impact. In: INTERNATIONAL ACM SIGSOFT CONFERENCE ON
QUALITY OF SOFTWARE ARCHITECTURES (QoSA '13), 9th ed. 2013, New York.
Proceending... New York: ACM, 2013. p. 23-32.
MACEDO, R.; MOZZAQUATRO, B.; NETO, L.; NONES, R. Uma arquitetura de
segurana para mecanismos de controle de acesso baseados em servios web. In: X
SIMPSIO BRASILEIRO DE SEGURANA DE COMPUTADORES E SISTEMAS
COMPUTACIONAIS (SBSEG), 2010, Porto Alegre. Anais... Porto Alegre: SBC,
2010. v. 1, p.114.
MELL, P., GRANCE, T. SP 800-145. The NIST Definition of Cloud Computing. [S.l.]:
National Institute of Standards and Technology, Gaithersburg, 2011.
REFERNCIAS
87
MELLO, E.; WANGHAM, M.; FRAGA, J.; CAMARGO, E. Segurana em servios web.
In: VI SIMPSIO BRASILEIRO DE SEGURANA DA INFORMAO E DE
SISTEMAS COMPUTACIONAIS (SBSEG), 2006, Porto Alegre. Anais... Porto Alegre:
Sociedade Brasileira de Computao, 2006. p. 148.
MICHELIN, R. A. Mitigao de Ataques de Negao de Servio em Rests
Autenticveis na Nuvem. 2015. Dissertao (Mestrado em Cincia da
Computao) Universidade Catlica de Rio Grande do Sul, Porto Alegre, 2015.
MOHAPATRA, K.; GULATI, A.; LUTHRA, R. A novel approach to secured network
selection. International Journal of Computer applications, New York, v.47, n.3, p.7
11, 2012.
OASIS. UDDI Spec Technical Committee Specification Draft. UDDI Version 3.0.2,
2004. Disponvel em: <http://goo.gl/RFPylm>. Acesso em: 7 fev. 2014.

OASIS. Security Assertion Markup Language (SAML) V2.0 Technical Overview,
2008. Disponvel em: <https://goo.gl/usJ0W>. Acesso em: 21 nov. 2014.
OASIS. Web Services Security: soap message security version 1.1.1, 2012. Disponvel
em: <http://goo.gl/e4zFFJ>. Acesso em: 14 fev. 2015.
OASIS. Web Services Security Username Token Profile Version 1.1.1, 2012.
Disponvel em: <http://goo.gl/X4YDzH>. Acesso em: 25 nov. 2014.

OASIS.
WS-SecurityPolicy
Acesso em: 25 nov. 2015.
1.3,
2012.
Disponvel
em:
<http://goo.gl/bx6Fj9>.
POTTS, S., KOPACK, M. Aprenda em 24 Horas Web Services. Rio de Janeiro:

Campus, 2003. p. 292 - 305.
SALAS, M. I. P. Metodologia de Testes de Segurana para Anlise de Robustez de Web
Services pela Injeo de Ataques. 2012. Dissertao (Mestrado em Cincia da
Computao) Universidade Estadual de Campinas, Campinas. 2012.
SILVA, J. L. C. da. Adoo de Computao em Nuvem Privada em uma Empresa de
Processamento de Dados Estadual: os impactos de implantao em seu ambiente corporativo.
2013. Dissertao (Mestrado em Cincia da Computao) Centro de
Informtica da Universidade Federal de Pernambuco, Recife. 2013.
SINGH, S. O livro dos cdigos. 8th ed. Rio de Janeiro: Editora Record, 2010. 13 p.
VIEIRA, M. State-of-the-art and Research Opportunities, 2010. Disponvel em:
<http://goo.gl/7BOK5a>. Acesso em: 22 fev. 2014.
VMWARE, I. VMware ESX e VMware ESXi: os hypervisores lderes do mercado com

produo comprovada, 2009. Disponvel em: <https://goo.gl/yRxjNq>. Acesso em: 5 out.
2015.
W3C. Web Services Architecture - W3C Working Group, 2004. Disponvel em:
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/>. Acesso em: 15 nov. 2014.
88
REFERNCIAS
W3C. XML Key Management Specification (XKMS 2.0), 2005. Disponvel em:
<https://www.w3.org/TR/xkms2/>. Acesso em: 15 nov. 2014.
W3C. Web Services Description Language (WSDL) Version 2.0 Part 1: core
language, 2007. Disponvel em: <http://www.w3.org/TR/wsdl20/>. Acesso em: 20
nov. 2013.
W3C. Web Services Policy 1.5 - Framework, 2007. Disponvel em: <https://
www.w3.org/TR/ws-policy/>. Acesso em: 12 nov. 2015.
W3C. SOAP Version 1.2 Part 2 Adjuncts (Second Edition), 2007. Disponvel em:
<https://www.w3.org/TR/soap12-part2/>. Acesso em: 17 jul. 2014.
W3C. XML-Signature Syntax and Processing (Second Edition), 2008. Disponvel em:
<http://www.w3.org/TR/xmldsig-core>. Acesso em: 10 fev. 2014.
W3C. XML Encryption Syntax and Processing Version 1.1, 2013. Disponvel em:
<https://www.w3.org/TR/xmlenc-core1/>. Acesso em: 1 nov. 2015.
WANG, R.; CHEN, S.; WANG, X. Signing me onto your accounts through facebook
and google: A traffic-guided security study of commercially deployed single-sign-on

web services. In: SYMPOSIUM ON SECURITY AND PRIVACY, 2012, Washington.
Proceedings... Washington: IEEE Computer Society, 2012. p. 365379.
WINCKLER, G. A. von. Proposta de arquitetura para federaes de nuvens
computacionais acadmicas. 2014. Dissertao (Mestrado em Cincia da
Computao) Instituto de Matemtica e Estatstica da Universidade de So Paulo, So
Paulo. 2014.
ZORZ, Z. Researchers detail attacks for compromising dropbox user accounts,
2013. Disponvel em: <https://goo.gl/avg4uQ>. Acesso em: 14 ago. 2014.
Apndice
91
A
Certificado Digital
O intuito deste apndice apresentar um breve roteiro sobre a utilizao da ferramenta,
de gerenciamento de chaves e certificados, Keytool. Para configurar o Apache Tomcat para se
comunicar atravs de uma conexo segura, dever seguir os seguintes passos abaixo:
1. Criar o keystore do certificado que contm um certificado assinado pessoalmente,
com validade de 365 dias, que gerado por voc, e no est garantido por uma
Autoridade Certificadora:
%JAVA_HOME%\bin\keytool -genkey -alias <nome_alias>
-keyalg RSA -keystore <nome_keystore> -dname
"cn=<[cn]>, ou=<[ou]>, o=<[o]>, l=<[l]>, S=<[S]>,
c=<[c]>" -keypass <senha_keystore> -storepass
<senha_storepass> -validity 365
[cn]
Nome do Domnio. Ex.: localhost
[ou]
Cargo. Ex.: Chefe da TIAd
[o]
Organizao. Ex.: FAB
[l]
Cidade. Ex.: Recife
[S]
Estado. Ex.: PE
[c]
Pas. Ex.: BR
Os campos <senha_keystore> e <senha_storepass> devem conter as mesmas valor

das senhas. Caso no deseje registrar o certificado oficialmente, ou seja, que ele seja
assinado digitalmente por uma autoridade certificadora, pule para o passo 5.
2. Depois de criado um certificado local usando o comando de keytool, use o comando
para criar o certificate signing request (CSR).
%JAVA_HOME%\bin\keytool -certreq -keystore <nome_keystore>
-alias <nome_alias>
92
APNDICE A. CERTIFICADO DIGITAL

A opo de -certreq cria um arquivo CSR que voc pode submeter uma Autoridade
Certificadora (CA). A senha solicitada na execuo do comando senha do keystore
que foi cadastrada no comando do passo 1.
3. Para submeter seu CSR, v at a CA e informe o contedo do arquivo no formulrio
encontrado e siga as instrues. Iremos acessar a StartSSL para obter certificado
teste:
https://www.startssl.com/
Depois que voc seguir todos os passos do site da VeriSign, voc receber um arquivo
chamado getcacert.cer, tambm conhecido como Root Certificate (Certificado Raiz).
E receber por e-mail o contedo do certificado intermedirio. Copie o contedo
completo desde BEGIN NEW CERTIFICATE REQUEST at END NEW
CERTIFICATE REQUEST e crie um arquivo com extenso CER colando o
contedo copiado.
4. Para importar os certificados, voc executar os seguintes comandos:
keytool -import -alias root -keystore <nome_keystore>
-trustcacerts -file getcacert.cer
keytool -import -alias <nome_alias> -keystore <nome_keystore>
-trustcacerts -file <nome_certificado_intermedirio>
Sempre comear pelo Certificado Raiz, e depois ir seguindo a sequencia. Os certificados devero ser importados para o arquivo keystore gerado no comando do passo 1.
A senha solicitada na execuo do comando senha do keystore que foi cadastrada
no comando do passo 1.
5. O procedimento para configurar o conector SSL no Tomcat simples. No arquivo
server.xml encontrado na pasta /conf no diretrio raiz do Tomcat, voc tem essa
configurao comentada, como mostrando a seguir:
<!-<Connector port="8443" protocol="HTTP/1.1"
SSLEnabled="true" maxThreads="150" scheme="https"
secure="true" clientAuth="false" sslProtocol="TLS"/>
-->
No caso, voc dever substituir pelas linhas mostradas abaixo e devero ser informados o caminho onde se encontra o arquivo keystore e a senha do mesmo:
93
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" keystoreFile="<caminho_keystore>"
keystorePass="<senha_keystore>" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"/>
Caso esteja usando a verso Apache Tomcat 6.0 ou superior, dever substituir pelas
linhas mostradas abaixo:
<Connector protocol="org.apache.coyote.http11.Http11Protocol"
port="8443" minSpareThreads="5" maxSpareThreads="75"
enableLookups="true" disableUploadTimeout="true"
acceptCount="100" maxThreads="200" scheme="https"
secure="true" SSLEnabled="true"
keystoreFile="<caminho_keystore>"
keystorePass="<senha_keystore>" clientAuth="false"
sslProtocol="TLS"/>
Reinicie o Tomcat e acesse o endereo que foi informado no passo 1 ou caso foi
informado localhost acesse https://localhost:8443/.

Uma Arquitetura de Referência Guiada À Conformidades de Segurança para Web Services Baseados em Nuvem Privada

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Uma Arquitetura de Referência Guiada À Conformidades de Segurança para Web Services Baseados em Nuvem Privada

Încărcat de

Drepturi de autor:

Formate disponibile

Ricardo Marinho de Melo

UMA ARQUITETURA DE REFERNCIA GUIADA A

Universidade Federal de Pernambuco

Ricardo Marinho de Melo

UMA ARQUITETURA DE REFERNCIA GUIADA A

Orientador: Vinicius Cardoso Garcia

Melo, Ricardo Marinho de

CDD (23. ed.)

UFPE- MEI 2016-088

Ricardo Marinho de Melo

Dissertao de Mestrado apresentada ao programa

Aprovado em: 03/03/2016.

Prof. Dr. Carlos Andr Guimares Ferraz

Prof. Dr. Julio Damasceno

Prof. Dr. Vinicius Cardoso Garcia

Agradeo, inicialmente, a Deus, pela vida.

Construmos muitos muros e poucas pontes

Relaes entre entidades . . . . . . . . . . . . . . . . . . . . . .

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

Fases da metodologia GQM . . . . . . . .

Comparativo entre as solues dos trabalhos relacionados para mitigao das

Propriedades de segurana afetadas por ameaas . . . . . . . . . . . . . . . . .

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

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

Cloud Security Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Web Services Interoperability Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

Web Services Policy ou WS-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Web Service Security ou WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Web Services SecurityPolicy ou WS-SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . . . . 37

XML Key Registration Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

XML Key Information Service Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

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

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

eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . .

Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . .

Web Services Description Language . . . . . . . . . . . . . . . . . . .