You are on page 1of 94

Ricardo Marinho de Melo

UMA ARQUITETURA DE REFERÊNCIA GUIADA A
CONFORMIDADES DE SEGURANÇA PARA WEB SERVICES
BASEADOS EM NUVEM PRIVADA

Dissertação de Mestrado

Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao

RECIFE
2016

Ricardo Marinho de Melo

UMA ARQUITETURA DE REFERÊNCIA GUIADA A
CONFORMIDADES DE SEGURANÇA PARA WEB SERVICES
BASEADOS EM NUVEM PRIVADA

Trabalho apresentado ao Programa de do da Universidade Federal de Pernambuco como requisito parcial para
obtenção do grau de Mestre em Ciência da Computação.

Orientador: Vinicius Cardoso Garcia

RECIFE
2016

Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

M528a

Melo, Ricardo Marinho de
Uma arquitetura de referência guiada a conformidades de segurança para
web services baseados em nuvem privada / Ricardo Marinho de Melo. – 2016.
93 p.: il., fig., tab.
Orientador: Vinicius Cardoso Garcia.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,
Ciência da Computação, Recife, 2016.
Inclui referências e apêndice.
1. Engenharia de software. 2. Computação em nuvem. 3. Sistemas
distribuídos. 4. Reuso de software. I. Garcia, Vinicius Cardoso (orientador). II.
Título.
005.1

CDD (23. ed.)

UFPE- MEI 2016-088

Ricardo Marinho de Melo
Uma Arquitetura de Referência Guiada à Conformidades de Segurança
para Web Services Baseados em Nuvem Privada

Dissertação de Mestrado apresentada ao programa
de Pós-Graduação em Ciência da Computação da
Universidade Federal de Pernambuco, com requisito parcial para a obtenção do título de Mestre em
Ciência da Computação

Aprovado em: 03/03/2016.

BANCA EXAMINADORA

———————————————————————–
Prof. Dr. Carlos André Guimarães Ferraz
Centro de Informática / UFPE

———————————————————————–
Prof. Dr. Julio Damasceno
Departamento de Estatística e Informática / UFRPE

———————————————————————–
Prof. Dr. Vinicius Cardoso Garcia
Centro de Informática / UFPE
(Orientador)

Agradeço, inicialmente, a Deus, pela vida.
Agradeço a todos os professores que, de alguma forma,
contribuíram para a concretização da minha dissertação de
mestrado.

Agradecimentos
Primeiramente agradecer a Deus, por me iluminar e guiar sempre da melhor forma
possível meu caminho.
À Rafaela Arcoverde, pelo dedicação, paciência, compreensão em minhas ausências para
realização deste trabalho.
Agradeço a todos os professores que, de alguma forma, contribuíram para a concretização
da minha pós-graduação.
Ao meu orientador, Vinicius Cardoso Garcia, pela oportunidade oferecida. Muito obrigado.
Agradeço também ao Carlo Marcelo pelas ideias trocadas, ajuda e motivação que foram
fundamentais.
Ao Major Santos, Chefe da Subdivisão de Tecnologia da Informação do CINDACTA III,
por autorizar e fornecer toda infraestrutura necessária para meus estudos.
E por fim agradeço a mim mesmo, pela grande persistência e determinação tida por todas
dificuldades enfrentadas ao longo de minha formação. Sou muito grato por ter conseguido chegar
até aqui.

“Construímos muitos muros e poucas pontes”
—SIR ISAAC NEWTON

Resumo
Contexto: A crescente adoção de computação em nuvem ofereceu diversos benefícios,
como escalabilidade, eficiência e lucratividade, mas apresenta novos riscos de segurança que
comprometem a confidencialidade, integridade e disponibilidade dos serviços prestados. Neste
contexto, as organizações militares buscam modelos de nuvens privadas alinhadas com suas
preocupações envolvendo segurança, conformidade e políticas. Atualmente, a segurança é o
maior obstáculo para ampla adoção da computação em nuvem.
Objetivo: Com base neste cenário, o trabalho propõe, a partir da análise das normas e
implementações de segurança para Web Services, definir uma arquitetura segura para mitigar
as principais ameaças de segurança em ambientes de nuvem, segundo o guia intitulado “The
Notorious Nine: Cloud Computing Top Threats in 2013” da Cloud Security Alliance.
Metodologia: Através de um estudo na literatura sobre computação em nuvem e segurança neste ambiente, foram utilizadas referências da área de pesquisa relacionadas ao problema
identificado. Especificou-se uma arquitetura segura como hipótese de solução, e posteriormente avaliou-se tal hipótese por meio da implementação de um protótipo, evidenciando-se a
importância desta solução.
Resultados: Como resultado obteve-se uma arquitetura de referência para minimizar os
riscos de segurança na implantação de nuvens privadas nas organizações militares. Experimentos
de campo contemplaram aquisições a respeito dos mecanismos de segurança aplicados, em particular os padrões WS-Policy, WS-Security e SAML, os quais conseguiram oferecer mecanismos
padrão de segurança necessários para realizar o intercâmbio seguro de mensagens certificadas
em ambiente de nuvem.
Palavras-chave: Segurança da Informação. Web Services. Organizações Militares. Computação 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 Ilustrações
2.1
2.2
2.3
2.4
2.5
2.6

Relações 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 Computação em Nuvem

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

22
23
24
26
30
39

4.1
4.2
4.3
4.4
4.5
4.6

Interação das Visões do Modelo 4+1 . . . . . . . .
Visão lógica da Arquitetura de Referência proposta
Diagrama de Dependências . . . . . . . . . . . . .
Arquitetura em Camadas . . . . . . . . . . . . . .
Exemplo de pacote HTTP capturado pelo Wireshark
Diagrama de Sequência 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 Definição . . . . . . .
Workflow do ciclo de vida do Apache Axis 2
Análise do aumento do tempo de resposta .
Resultados da avaliação da Questão 01 . . .
Resultados da avaliação da Questão 02 . . .
Resultados da avaliação da Questão 03 . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

71
74
76
79
80
81
82

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

Lista de Tabelas
3.1

5.1
5.2
5.3

Comparativo entre as soluções dos trabalhos relacionados para mitigação das
ameaças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

Propriedades de segurança afetadas por ameaças . . . . . . . . . . . . . . . . .
Ataques utilizados para cada ameaça . . . . . . . . . . . . . . . . . . . . . . .
Definição das Questões e Métricas para avaliação . . . . . . . . . . . . . . . .

73
73
75

Lista de Acrônimos
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 Aérea e Controle de Tráfego Aéreo . . 55
CN

Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

CSA

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

DoS

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

DDoS

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

ePING

Padrões de Interoperabilidade de Governo Eletrônico . . . . . . . . . . . . . . . . . . . . . . 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

Injeção 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 Públicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

TIC

Tecnologias de Informação e Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Sumário

1

2

Introdução

15

1.1

Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

1.2

Estabelecimento do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

1.3

Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

1.4

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

1.5

Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Referencial Teórico

21

2.1

Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.1.1

Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

2.1.2

Normalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Políticas para Web Services . . . . . . . . . . . . . . . . . . . . . . .

36

2.4.2

Web Services SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . .

37

Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

2.5.1

Modelos de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

2.5.2

Modelos de Implantação . . . . . . . . . . . . . . . . . . . . . . . . .

40

2.5.3

Ameaças à 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 Tráfego de Serviços . . . . . . . .

42

2.5.3.4

Interfaces Inseguras . . . . . . . . . . . . . . . . . . . . . .

43

2.5.3.5

Negação de Serviço . . . . . . . . . . . . . . . . . . . . . .

43

Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

2.2

2.3
2.4

2.5

2.6

3

Trabalhos Relacionados
3.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45
47

4

Implementação da Proposta
4.1 Metodologia 4+1 . . . . . . . . . . . . . . . . . . . . . .
4.2 Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Módulo de Serviço . . . . . . . . . . . . . . . . .
4.2.2 Módulo de Mecanismos de Segurança . . . . . . .
4.2.3 Módulo de Políticas de Segurança . . . . . . . . .
4.2.4 Módulo de Gerenciamento de Acesso e Identidade
4.3 Visão Dependência . . . . . . . . . . . . . . . . . . . . .
4.4 Visão Implementação . . . . . . . . . . . . . . . . . . . .
4.5 Visão Física . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Desenvolvimento da Aplicação . . . . . . . . . . .
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 Considerações 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

Considerações Finais
6.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83
84
84

5

6

Avaliação da Proposta
5.1 Metodologia . . . . . . . . . . . . . . . . . . . . .
5.1.1 Planejamento . . . . . . . . . . . . . . . .
5.1.1.1 Publico alvo e cenário de atuação
5.1.1.2 Critério de Avaliação . . . . . .
5.1.2 Definição . . . . . . . . . . . . . . . . . .
5.1.3 Coleta de Dados . . . . . . . . . . . . . .
5.1.4 Análise dos Resultados . . . . . . . . . . .
5.2 Limitações da Avaliação . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

Referências

85

Apêndice

89

A Certificado Digital

91

15

1
Introdução
O advento da Computação em Nuvem (CN), ou do inglês cloud computing, oferece
vantagens em investimentos operacionais por meio de custos sobre demanda, provido de um
ambiente dinâmico e facilmente escalável. A partir dos novos modelos de negócios estratégicos,
minimizam-se as preocupações de gerenciamento operacional, trazendo vantagens de mobilidade,
escalabilidade e disponibilidade das informações e serviços de dentro para fora da organização
(ARMBRUST et al., 2010). Como resultado, esses modelos de serviço são oferecidos por um
número crescente de provedores em nuvem.
Em contrapartida, esses modelos de serviço utilizados em ambiente da CN apresentam
diferentes níveis de riscos se comparados ao ambiente tradicional (CSA, 2011). Segundo o
relatório “The Notorious Nine: Cloud Computing Top Threats in 2013”, a Cloud Security
Alliance (CSA) identificou nove ameaças em ambientes de nuvem: vazamento de dados, perda
de dados, sequestro de contas ou de tráfego de serviços, interfaces inseguras, negação de
serviços, usuário mal intencionado, abuso de serviços da nuvem, investigação insuficiente e
vulnerabilidades de recursos compartilhados (CSA, 2013).
A crescente insatisfação com a segurança em serviços de processamento, transferência e
armazenamento de dados em nuvens é resultado de uma combinação de diversos fatores, dentre
os quais podem ser citados: a falta de padrões de interoperabilidade bem definidos (ISO/IEC,
2013); a perda de controle de dados e aplicações em nuvens computacionais, resultando em
indisponibilidades de serviços, vazamento e perda de dados; a falta de conhecimento dos riscos
existentes em ambientes de nuvem. Segundo a CSA (2011), a segurança é uma forte barreira
contra a ampla adoção da computação em nuvem.
Esses problemas de segurança são complexos, pois não envolvem apenas questões arquiteturais e tecnológicas, mas também mudanças de processos, em função dos novos modelos de
computação em nuvem. Organizações como World Wide Web Consortium (W3C) e Organization
for the Advancement of Structured Information Standards (OASIS) são responsáveis pelo conjunto de padrões de interoperabilidade e segurança dos Web Services (WS). Empresas como
International Business Machines (IBM) e Amazon Web Services (AWS), líderes do setor de
segurança em ambientes de nuvem, apoiam o desenvolvimento destes padrões (CSER, 2014).

16

1. INTRODUÇÃO

O advento da Web se deu em meio a um universo de empresas com seus peculiares
sistemas computacionais, os quais, quando desenvolvidos não visavam interoperabilidade, por
exemplo, com os sistemas computacionais de seus clientes (POTTS, 2003). A partir dessa
necessidade de interação entre diferentes aplicações, surge uma nova caracterização de sistemas
distribuídos que possibilitam o câmbio de dados e integração de sistemas já existentes: os Web
Services.
Os WS utilizam padrões neutros como Hyper Text Transfer Protocol (HTTP) e eXtensible
Markup Language (XML), permitindo que as diferentes aplicações sejam integradas através de
linguagens e protocolos largamente aceitos, assim garantindo interoperabilidade (W3C, 2004).
A W3C e OASIS têm por objetivo projetar e publicar especificações, ou padrões, que
cumprem a promessa dos WS: interoperabilidade entre as barreiras geográficas, de hardware,
de sistema operacional, de linguagem de programação e integração de plataformas a baixo
custo (POTTS, 2003). Contudo, a segurança dos serviços e a transição de dados tornaram-se
alvo de estudo porque no universo de WS, que vai além da transmissão de dados, segurança
significa mais do que inviolabilidade de informação. A segurança, nesse contexto, caracteriza-se
por uma gama de propriedades dentre as quais confidencialidade, integridade, disponibilidade,
não-repúdio e autenticidade estão inclusas.
Para garantir a segurança 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 especificações tornaram-se indispensáveis para a construção de WS seguros (OASIS, 2012a).
Neste contexto, com base na importância da segurança nos WS, este trabalho tem por
objetivo estudar os mecanismos de segurança, WSS, SAML e WSP, utilizados como padrão nos
WS, definindo, analisando, caracterizando e demonstrando sua aplicabilidade, através de um
estudo de caso.

1.1

Motivação

O crescimento e a complexidade da infraestrutura da Internet e redes corporativas fizeram
com que vários modelos de oferta de serviços de Tecnologias de Informação e Comunicação (TIC)
fossem apresentados como opção no contexto das organizações públicas 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 computação, em
que a prestação de serviços é realizada em máquinas reais, não havendo otimização de recursos
computacionais (SILVA, 2013). Estas empresas podem utilizar como alternativa o modelo de
computação em nuvem, na qual se utiliza a técnica de virtualização para instanciar máquinas
virtuais e aplicações, oferecendo custo reduzido, eficiência e escalabilidade dentro das fronteiras
1 Um

centro de processamento de dados (CPD) é o local onde são concentrados os equipamentos de processamento e armazenamento de dados de uma empresa ou organização

1.2. ESTABELECIMENTO DO PROBLEMA

17

do data center (DAMASCENO, 2015).
Ainda no âmbito de empresas governamentais, especificamente federais, há recomendações de interconexão na prestação dos serviços de governo eletrônico, onde se deve considerar
o nível de segurança que regulamentam a utilização da TIC na interoperabilidade de serviços
de governo eletrônico (EPING, 2016). Essas recomendações do Padrões de Interoperabilidade
de Governo Eletrônico (ePING) descrevem definições de um conjunto mínimo de premissas,
políticas e especificações técnicas que estabelecem as condições de interação com os demais
Poderes e esferas de governo e com a sociedade em geral.
Com toda essa infraestrutura de tecnologia disponível, os WS tornam-se uma nova opção
de negócio para as empresas que planejam utilizar a CN como meio de compartilhamento de
informações. A segurança é um elemento indispensável para a construção e desenvolvimento
de um ambiente de nuvem confiável. No entanto, garantir a segurança dos WS representa um
desafio devido às limitações dos padrões e à necessidade de dar suporte a uma considerável
demanda de serviços (POTTS, 2003).

1.2

Estabelecimento do Problema

Motivado pelas questões apresentadas na Seção anterior, o principal objetivo deste
trabalho é, em linhas gerais:
Especificar, projetar e implementar uma arquitetura de software para WS atendendo aos
padrões e políticas contidos na ePING e que permita o desenvolvimento de soluções de aplicações
que usam esses serviços com base nos mecanismos utilizados como padrão de segurança nos
serviços Web: WSS, SAML e WSP. Além disso, este trabalho visa prover uma implementação
de referência desta arquitetura de software.

1.3

Justificativa

O presente trabalho justifica-se, primeiramente, pela necessidade de normas de segurança
para especificação de mecanismos de proteção para que os Web Services possam contemplar
os valores necessários à garantia da segurança na sua utilização. Para isso, já existem padrões
promissores para segurança: WSS (OASIS, 2012a), o qual oferece mecanismos padrões de
segurança necessários para realizar o intercâmbio seguro de mensagens certificadas em ambientes
de nuvem, através de assinaturas digitais e criptografia; WSP (W3C, 2007b), que provê um
modelo de propósito geral para descrever conjunto de regras da segurança; e por fim, o framework
SAML (OASIS, 2008), que define uma forma padrão para criar, trocar e interpretar asserções de
segurança entre entidades de uma aplicação distribuída de modelo Software as a Service (SaaS).
Este trabalho avalia a arquitetura de software proposta, através de experimentos de
campo com desenvolvimento de um protótipo para análise da tecnologia de serviços seguros
pelas normas WSS, SAML e WSP. A principal contribuição desta dissertação é o retrato atual

18

1. INTRODUÇÃO

do modelo de nuvem privada através da utilização da tecnologia de WS, com uma análise
aprofundada das normas e implementações de segurança propostas.

1.4

Objetivos

Com objetivo de atender à crescente demanda dos serviços TIC baseados em computação
em nuvem privada, este trabalho propõe especificar, projetar e implementar uma arquitetura de
software guiada por conformidades de segurança para WS em um ambiente de computação em
nuvem privada em uma organização militar. Para isto, serão implementados experimentos de
campo com objetivo de analisar os mecanismos de segurança utilizados como padrão nos WS.
Esta proposta objetiva adotar uma arquitetura de referência de oferta de serviços de
Tecnologia da Informação (TI) e garantir conformidades de segurança com as boas práticas de
segurança da informação.
Os objetivos específicos a serem atingidos incluem:
1. Mitigar as cinco principais ameaças à segurança em um ambiente de nuvem, conforme
identificado no relatório “The Notorious Nine: Cloud Computing Top Threats in
2013” da CSA (2013), com atenção especial ao modelo SaaS e à análise de risco
das principais propriedades básicas da segurança: confidencialidade, integridade,
disponibilidade, autenticidade e não repúdio;
2. Estudo da plataforma tecnológica de WS, com ênfase nas normas de segurança em
nível de serviço 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 referência através de um experimento de
campo com desenvolvimento de um protótipo para análise da tecnologia de serviços
seguros propostos pelas normas WSS, SAML e WSP.

1.5

Estrutura da Dissertação

A parte de introdução apresentou o contexto, a justificativa, a motivação para este
trabalho, uma visão geral da solução proposta. Os objetivos e contribuições deste trabalho
também foram apresentados. A presente dissertação está organizada de acordo com a seguinte
estrutura: 

Parte 2: apresenta os principais conceitos básicos de WS e CN. Também esclarece
alguns detalhes de funcionamento das normas de segurança estudadas: WSS, SAML
e WSP.

1.5. ESTRUTURA DA DISSERTAÇÃO    

19

Parte 3: cita os trabalhos relacionados ou que têm pontos em comum com esta
dissertação.
Parte 4: define as características básicas da arquitetura proposta e descreve as especificações do ambiente de implantação, além de apresentar as implementações dos
experimentos de campo das normas de segurança deste ambiente.
Parte 5: apresenta a validação da análise dos padrões de segurança, com base na
implementação dos experimentos de campo executados, relatando resultados no que
concerne à garantia dos atributos de segurança.
Parte 6: apresenta as considerações finais da dissertação e os trabalhos futuros.

21

2
Referencial Teórico
Através de cinco Seções esta parte tem como objetivo explanar os conceitos e estudos
utilizados como base para a presente pesquisa. Na primeira seção são apresentados os conceitos
dos WS. A segunda seção discute as noções da extensão WSS e seus mecanismos de segurança.
A terceira fornece detalhes da especificação SAML e a integração entre os diferentes sistemas
de autenticação e de autorização. A quarta seção aborda a estrutura do WSP para apoiar na
confecção das políticas de segurança. A quinta e última, aborda os conceitos e os principais
benefícios e ameaças da CN.

2.1

Web Services

WS são aplicações de software que possuem interfaces bem definidas e descritas em
XML, classificadas como um tipo específico de serviço. Esses serviços são identificados através
de um Uniform Resource Identifie (URI) e chamadas através das Remote Procedure Call (RPC),
como acontece em outros serviços distribuídos. O tipo de informação 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 aplicações. As interações com outras aplicações são realizadas pela troca de mensagens
XML em um formato Simple Object Access Protocol (SOAP) específico, utilizando padrões
da Internet. Os WS não são a primeira tecnologia a nos permitir isto, mas são diferentes das
tecnologias existentes, pelo fato de usarem padrões neutros de plataforma, como HTTP e XML.
Atualmente, as vantagens dos WS são atrativas para muitas aplicações, oferecendo
flexibilidade e interoperabilidade sobre outras tecnologias. Entre essas vantagens, encontra-se a
integração própria para business-to-business (B2B). No entanto, essas aplicações precisam de
algum nível de segurança necessário para que as mesmas se interconectem de forma confiável.
Dessa forma, a segurança tem sido considerada um obstáculo na adoção dos WS.

22

2. REFERENCIAL TEÓRICO

2.1.1

Arquitetura

A gestão da arquitetura dos WS é fornecida pelo modelo teórico da Service-Oriented
Architecture (SOA). Trata-se de um modelo simples que contém três entidades e três operações.
A Figura 2.1 ilustra esse modelo (POTTS, 2003).
Figura 2.1: Relações entre entidades

Fonte: W3C (2004) - adaptado.   

2.1.2

O Provedor de serviços: é responsável por duas atividades: a primeira é publicar
as interfaces dos serviços providos e a segunda é atender as requisições originadas
pelos clientes.
O cliente: após a consulta no diretório para registro de serviços e se o serviço foi
encontrado, invoca o serviço diretamente requisitando o provedor de serviços.
O diretório para registro de serviços: é o repositório responsável por informar
ao cliente a descrição dos serviços e a localização das interfaces dos mesmos. As
entidades interagem através de três operações fundamentais: publicar, localizar,
invocar. Inicialmente, o provedor de serviços publica as interfaces no diretório para
registro de serviços, onde ficarão registrados os serviços. Após a publicação, o cliente
poderá fazer uma consulta de um determinado serviço, se esse serviço for localizado
no diretório para registro de serviços, o cliente poderá invocar o mesmo ao provedor
de serviços toda vez que desejar usá-lo.

Normalização

A normalização 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 , organização responsável pela manutenção da
normalização da interoperabilidade, abrange uma série de recomendações 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
interação das três entidades mencionadas. Algumas dessas mais importantes normas de WS são
definidas pelo W3C2 (W3C, 2004).
Figura 2.2: Arquitetura de normas de WS proposta pelo W3C

Fonte: W3C (2004).

A seguir, cada um dos padrões XML, SOAP, Web Services Description Language
(WSDL) e Universal Description Discovery and Integration (UDDI) que compõem a pilha
básica de protocolos e tecnologia base dos WS são explicados em detalhes.

2.1.3

eXtensible Markup Language

A XML é um formato de texto simples e flexível, um subconjunto de Standard Generalized Markup Language3 (SGML). Criado em 1996 e formalizado em 1998, se tornou um
importante padrão de troca de dados na Web. O padrão 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 especificação XML contém um conjunto de
regras de sintaxe para descrição de dados que é definida por uso de Schemas, norma do W3C, que
contém regras de validação dos elementos e atributos de um documento XML. Outro componente
muito importante são os namespaces, mantido pela W3C. Os namespaces descrevem uma coleção
de nomes, identificados por uma referência URI, que são 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/,

Último Acesso em Novembro de 2015
Último Acesso em Novembro de 2015

3 https://www.w3.org/MarkUp/SGML/,

24

2. REFERENCIAL TEÓRICO

Os componentes schemas e namespaces se interagem para suportar suas aplicações,
permitindo a criação de sistemas que manipulem facilmente informações entre aplicações e
validadas de uma maneira mais padronizada.

2.1.4

Simple Object Access Protocol

O protocolo de comunicação SOAP é uma linguagem XML para troca de mensagens.
Baseia-se em normas como o XML Namespace e XML Schema, que permite independência de
linguagem e que trabalha com diversos sistemas operacionais e sobre protocolos de aplicação 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 implementações de WS.
O SOAP é uma das normas mais importantes dos WS, definida pelo consórcio W3C
(W3C, 2007c). A norma SOAP define a estrutura de documentos XML, proporcionando simplicidade e coerência para que uma aplicação envie mensagens XML para outra, garantindo a
independência 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 não só proteger os dados mas, além disso, possibilita transmissão
da mensagem SOAP por qualquer protocolo de transporte. O envelope é composto
por duas partes: o cabeçalho (SOAP Header) e o corpo (SOAP Body) da mensagem.

delimitada e protegida destinada para armazenar algo.

2.1. WEB SERVICES  

2.1.5

25

Cabeçalho SOAP (SOAP Header): é um elemento opcional e o primeiro elemento
filho do envelope. O cabeçalho da mensagem SOAP contém informações, divididas
em blocos, podendo conter zero ou mais blocos de cabeçalhos. Essas informações
ou diretivas são usadas para gerenciar ou prover segurança, tal como asserções de
autorização e autenticação entre outros.
Corpo SOAP (SOAP Body): é um elemento obrigatório e contém a mensagem
propriamente dita chamada carga útil (Payload). O corpo contém os dados de
negócio da mensagem ou qualquer tipo de informação XML. No corpo, também
pode estar contido o elemento Fault, que tem por objetivo transportar informações
sobre erros que possam vir a ocorrer no processamento dessas informações.

Web Services Description Language

A WSDL é uma gramática em XML para definir e especificar as interfaces de um WS.
Essas interfaces contêm informações do tipo, localização do serviço, o que o serviço pode fazer
e como poderá ser chamado, permitindo assim, a interação do serviço.
A WSDL é uma linguagem padrão usada para descrever as funcionalidades de um
WS, independente de linguagem e plataforma (W3C, 2007a). Tem como objetivo descrever os
serviços publicados pelos provedores e que, posteriormente, serão acessados pelos clientes.
O WSDL é codificado em XML Schema que obedece a uma estrutura fixa para especificar
interface de serviço. 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 vínculo 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 são:    

definitions: este é o elemento raiz a partir do qual os demais são definidos.
types: define os tipos de dados, utilizando o XML Schema, ao longo do documento
e que serão utilizados entre o servidor e o cliente durante a comunicação. Os tipos de
dados são definidos dentro deste elemento para que sejam posteriormente utilizados
no elemento message.
message: define, de forma abstrata, as mensagens que serão trocadas, contendo os
parâmetros de entrada e saída do serviço.
operation: este elemento representa a interação particular com o serviço, descrevendo as mensagens de entrada, saída e exceções possíveis e permitidas.

5 http://www.corba.org,

Último Acesso em Novembro de 2015

26

2. REFERENCIAL TEÓRICO
Figura 2.4: Estrutura de um documento WSDL

Fonte: W3C (2007a) - adaptado.    

2.1.6

portType: descreve um conjunto abstrato de operações mapeadas para suportar um
ou mais serviços. A cada operação, estão associados um pedido e uma resposta.
binding: este elemento especifica a ligação de cada elementos abstrato, operações,
mensagens e tipos de dados, com protocolo de rede que serão utilizados para transportar os elementos até o destino.
port: associa o elemento binding e o endereço de rede para prover assim um endereço
único para acessar um serviço.
service: descreve onde o serviço está disponível ou publicado, associando entre o
elemento binding e o endereço de rede onde o serviço pode ser encontrado, possuindo
assim um conjunto de port associados.

Universal Description, Discovery and Integration

O UDDI permite que WS disponíveis na Internet sejam facilmente encontrados, provendo
uma interface para utilização do cliente. Trata-se de um protocolo para registrar, publicar e
descobrir WS num ambiente distribuído (OASIS, 2004).
Os dados e metadados dos WS são registrados e armazenados em diretórios UDDI
registry. Associando a cada estrutura de dados um identificador único, chamado UDDI key,
cada empresa ou organização, cria suas próprias regras de classificação. A importância de
cada empresa possuir sua classificação permite que clientes realizem consultas mais refinadas,
escolhendo o serviço que melhor lhe atende.
Os diretórios UDDI não armazenam informações relativas à implementação de um WS,
como a WSDL do serviço. Este também contém informações relativas à empresa responsável

2.2. WEB SERVICES SECURITY

27

que prover o serviço. A disponibilidade dos serviços dos WS através de UDDI não é obrigatória
(OASIS, 2004).
No domínio de informação da UDDI, existem três tipos de informação que podem ser
consagrados no registro UDDI:   

2.2

Páginas Amarelas: aqui, são incluídos dados gerais como a entidade fornecedora
ou os serviços oferecidos. Assim, estes dados são classificados como categorias (i.e.
país de origem, a indústria, o produto, entre outros). A pesquisa um Web Service,
neste contexto, é feita com base nas categorias.
Páginas Brancas: onde, são incluídas informações básicas de contatos que permite
pesquisar um Web Service com base em dados atrelados à entidade fornecedora do
WS. Essas informações são constituídas (i.e. nome de um negócio, descrição do
negócio, informação de contato, endereço, fax, ou mesmo incluir identificadores de
negócios).
Páginas Verdes: contém um conjunto de informações técnicas sobre um WS, desta
forma o programador ao ter acesso a essas informações poderá desenvolver sua
aplicação que utilize ao WS em questão.

Web Services Security

A Web Service Security ou WS-Security (WSS) suporta, integra e unifica vários modelos,
mecanismos e tecnologias de segurança, oferecendo mecanismos padrão de segurança necessários
para realizar o intercâmbio seguro de mensagens certificadas em um ambiente de WS.
As especificações de segurança definem um conjunto de padrões para extensões de
cabeçalhos de mensagens SOAP, utilizados para oferecer integridade, confidencialidade e autenticidade. Essas especificações atendem esses três requisitos de segurança através do uso da
Assinatura XML (XML Signature), da Criptografia XML (XML Encryption) e da Autenticação
e Autorização XML (SAML) (OASIS, 2012a).

2.2.1

Arquitetura

A arquitetura do padrão WSS é construída sob a mensagem SOAP, definindo um esquema
XML, que possibilita incluir de forma padronizada as informações relacionadas à cifragem dos
dados e assinaturas digitais da mensagem SOAP para construção de WS seguros, fazendo uso
das especificações a XML Digital Signature e a XML Encryption.
A seguir, a XML apresenta uma mensagem SOAP que usa segurança baseada em tokens,
assinaturas digitais e criptografia:

28

2. REFERENCIAL TEÓRICO

2.2. WEB SERVICES SECURITY

29

Conforme descrito nos comentários, a XML, apresentou a estrutura do padrão WSS
fazendo uso de algumas especificações de segurança que serão abordadas nos próximos tópicos
desta Subseções.

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 informações digitais”. O XML Digital Signature
é um padrão 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 têm a função de conter
informações suficientes para permitir que um cliente seja verificado usando o par de chaves
pública/privada. O uso do padrão XML Digital Signature não está estritamente voltado para
assinar documentos XML. Também, é possível assinar qualquer tipo de documento eletrônico
do tipo de arquivos binário ou textos, desta forma, a assinatura será representada através de um
documento XML.
Uma característica fundamental da assinatura em documentos XML é a habilidade de
assinar somente partes específicas da árvore do documento XML. Dessa forma, permite que
outras partes desse documento sofram modificações 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 obtêm informações
adicionais no seu ciclo de vida. Esta flexibilidade permite garantir a integridade de certas partes
de um documento XML. O conteúdo abaixo apresenta um trecho de documento XML que mostra
um exemplo de XML Digital Signature:

6 Conjunto

de instruções matemáticas baseadas na criptografia, que permite conferir autenticidade, privacidade e
inviolabilidade aos documentos digitais e transações 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

2. REFERENCIAL TEÓRICO

Segundo W3C (2013), a informação assinada aparece dentro do elemento <SignedInfo>.
O algoritmo usado no cálculo do elemento <SignatureValue> é mencionado dentro da seção
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 combinação 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 padrão Canonical XML9 é uma especificação que descreve um processo de herança
de atributos XML namespace, definindo meios para representar documentos na forma canônica
(W3C, 2008). O interpretador XML expressa que o elemento <p class="a"secure="1"/> e o
elemento <p class = ’a’ secure = "1"/> são equivalentes. Porém, 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, porém com lógicas
equivalentes, permitem serem representados por uma mesma forma canônica. Isso é importante
porque, possibilita que os documentos XML possam ser assinados sem que haja preocupação
com a sintaxe dos mesmos.
Existem três 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 contém os dados,
assinando porções ou todo o documento. É ideal para ser utilizada com Serviços
Web, inserida em mensagens SOAP;
enveloping: a assinatura encapsula os dados assinados, ou seja, contido dentro da
própria 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

2.2. WEB SERVICES SECURITY

31

Geralmente estes dados encontram-se na Web. É ideal para assinar documentos que
sofrem constantes modificações.

2.2.3 XML Encryption
O padrão XML Encryption provê segurança fim-a-fim para aplicações que necessitam
realizar trocas de dados de forma segura (W3C, 2013). A segurança provida do padrão oferece
um nível de privacidade por cifrar os dados evitando que terceiros vejam seu conteúdo, 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 conteúdo referenciado por um documento XML.
De acordo com Singh (2010), "A codificação é 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 proprietário da Netscape Communication e o Transport Layer
Security (TLS) é a definição RFC 2246 do padrão da IETF. Os dois protocolos são semelhantes,
mas o TLS possui alguns aprimoramentos importantes. Os TLS/SSL são usados com mais
frequência para oferecer proteção e integridade dos dados sobre o protocolo HTTP.
Os protocolos TLS/SSL possuem algumas limitações em um ambiente de WS. Esses
protocolos, por si só, não podem fornecer autenticação, integridade de dados durante a existência
da mensagem se ela for roteada através de mais de um WS. A especialização XML Encryption
não pretende substituir TLS/SSL, mas garante confidencialidade persistente, garantindo assim
confidencialidade dos dados depois do término da s essão. Além disso, provê um mecanismo de
segurança que não é coberto pelo TLS/SSL, como a possibilidade de cifrar somente parte de um
dado e o estabelecimento de sessões 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 revelação de
informação para partes não autorizadas e garantam o acesso à informação, por partes autorizadas.
A XML a seguir apresenta, de maneira breve, a estrutura da sintaxe para a criptografia
XML. Os pontos de interrogação no código a seguir são substituídos 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 aça r eferência, o s dados
cifrados: dados arbitrários, o elemento <EncryptedData> pode tornar-se a raiz de um novo
documento XML, ou um elemento-filho; documento XML, o elemento <EncryptedData> pode

32

2. REFERENCIAL TEÓRICO

torna-se a raiz de um novo documento; elemento XML, o elemento <EncryptedData> substitui o
elemento ou conteúdo na versão criptografada do documento XML; conteúdo do elemento XML;
o elemento <EncryptedData> substitui o elemento ou o conteúdo na versão criptografada do
documento XML. O conteúdo abaixo apresenta um exemplo de documento XML sem criptografia
dos dados:

O documento XML mostrado acima, refere-se a informações de uma conta de um sistema
bancário, informando os elementos: Nome, Numero, Limite e Senha do cliente responsável. O
conteúdo apresenta um exemplo do documento anterior usando o padrão XML Encryption:

Ainda no documento XML, podemos observar que todos os dados exceto o elemento
Nome foram criptografados. As informações extremamente importantes, como os elementos
Numero, Limite e Senha são apresentados de forma criptografadas e colocadas entre as tags
<EncryptedData>, preservando a informação confidencial.
O WSS fornece estrutura para uma segurança completa e flexível às necessidades individuais. Para tanto, essa tecnologia propõe um conjunto de extensões de cabeçalho SOAP, que,
uma vez utilizados, poderão conter XML para os padrões já analisados anteriormente (XML
Signature, XML Encryption), bem como para os padrões que surgirão 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 especificações e esquemas XML, que juntos definem
uma forma padrão para criar, trocar e interpretar asserções de segurança entre
entidades de uma aplicação distribuída. No caso, são definidos meios para
expressar, em XML, informações sobre autenticação, autorização e atributos
de um sujeito, porém as especificações da SAML não definem uma nova
tecnologia ou forma para autenticação, mas sim uma tecnologia que visa garantir
a interoperabilidade entre os diferentes sistemas de autenticação11 .

O propósito tecnológico SAML dada em OASIS (2008) é: “. . . definir, melhorar, e manter um framework padrão baseado em XML para criação e trocas informações de autenticação
e autorização.”
Segundo Mello et al. (2006): “Uma asserção de segurança é um conjunto de afirmações, concedidas por um emissor SAML, sobre determinadas informações de um principal.”

2.3.1

A Anatomia da SAML
São definidos três tipos de asserções da especificação SAML:   

Autenticação: fornecida pelo emissor SAML após a declaração de autenticação com
sucesso do usuário, que afirma que o emissor foi autenticado por um determinado
meio em um determinado momento;
Atributo: uma afirmação contém detalhes específicos sobre uma declaração feita
pelo emissor, que, assim especifica estar associado ao(s) atributo(s) específico(s) para
determinar o papel que irá desempenhar dentro do sistema;
Autorização: que indica os direitos que um emissor possui sobe um determinado
recurso em questão, sendo que esta declaração de asserções afirma que a requisição
de acesso pode levar com base as asserções de autenticação e de atributos.

A seguir, os documentos em XML apresentam a estrutura das asserções SAML para
autenticação, atributos e autorização respectivamente:
10 Conjunto

de funcionalidades comuns para um determinado domínio de aplicações.
especificação da SAML prevê o uso de diferentes mecanismos para a autenticação: usuário e senha, Kerberos,
Secure Remote Password, certificados TLS/SSL, chave pública (X.509, SPKI, XKMS), XML Digital Signature e
ainda, possibilita o uso de mecanismos não definidos na especificação.
11 A

34

2. REFERENCIAL TEÓRICO

Conforme exemplificado nos comentários descritos, o documento XML, apresentou a
estrutura básica da asserção SAML de autenticação.

No segundo exemplo, a XML comentada, apresentou a estrutura básica da asserção
SAML de atributos.

2.3. SECURITY ASSERTION MARKUP LANGUAGE

35

A XML, comentada acima, exemplifica que a asserção de autorização contida no documento que afirma que o cliente tiad@cindacta3.aer.mil.br está autorizado a consultar a página
http://www.cindacta3.aer.mil.br/index.html e que pode submeter o formulário http://www.cindacta
3.aer.mil.br/cadastrar. As afirmações foram concebidas pelos atributos Decision do elemento
AuthorizationDecisionStatement informando Deny para negação, Permit para permissão e Indetreminate para indeterminação.
Mesmo prevendo o uso de autoridades responsáveis pela emissão dessas asserções, o
modelo de uso SAML não as menciona. No entanto, as especificações ditam os protocolos que
visam à interação com essas autoridades (OASIS, 2008).
Portanto, verifica-se que o TLS/SSL tem capacidade de garantir a segurança necessária
para chamadas de WS simples e não–hierárquicas. A SAML por sua vez, sobrepõe-se ao
TLS/SSL, pois, apresenta em suas funcionalidades um protocolo de geração de mensagens
baseado em SOAP com dados estruturados em XML, desta maneira capacitando uma empresa a
dar testemunho dos direitos de identidade, autenticação e atualização de usuários humanos e de
programa (POTTS, 2003).
Vimos que o SAML permite que domínios da web seguros troquem a autenticação de
usuário e os dados de autorização. Quando um provedor de serviços usa a SAML, ele pode
entrar em contato com um provedor de identidade separado para autenticar usuários que estejam
tentando acessar um conteúdo seguro.

36

2.4

2. REFERENCIAL TEÓRICO

Web Services Policy

A WSP é uma linguagem para definir políticas de serviços, oferecendo uma gramática
flexível e extensível que permite definir como os recursos e restrições das normas de segurança
poderão ser expressos para o ambiente de WS.

2.4.1

Políticas para Web Services

A WSDL, apresentado na Subseção 2.1.5, fornece um mecanismo para descrever as
funcionalidades presente em um WS. Isso permite aos provedores de serviços descreverem quais
são os serviços oferecidos, quais as informações são necessárias para processar as requisições e
informando em quais formatos o serviço deve enviar os dados para um cliente.
A WSDL tem como objetivo a descrição das propriedades funcionais de um serviço. No
entanto, se faz necessário, também, a descrição dos requisitos não funcionais de um serviço.
Esses requisitos, dentre outras características, podem estar relacionados com a segurança em
que o serviço possa prover ou exigir. Desta forma, pode-se determinar qual serviço escolher,
relacionado a um serviço que apresente uma política de privacidade bem definida ou qualquer
outro mecanismo de segurança.
A criação de uma política para anexar informações necessárias para definir requisitos
adicionais (que deve ser cumpridos pelo cliente e pelo prestador do serviço para que a interação
entre ambos possa acontecer) que tornam necessário o surgimento de uma tecnologia WSP, com
objetivo de prover um modelo de propósito geral para descrição de políticas.
As políticas de segurança são representadas através de documentos XML, cujo elemento
raiz do documento é o elemento Policy. Dentro deste elemento, são representadas coleções de
asserções (ou assertivas), que quando combinadas representam uma coleção válida de alternativas
de políticas. As asserções são combinadas através de dois tipos de operadores de políticas:
ExactlyOne indica que somente uma das asserções contidas na política poderá fazer parte de uma
alternativa de política; All permite a combinação de todas as asserções apresentadas como uma
alternativa de política (W3C, 2007b).
A seguir, a XML apresenta a estrutura simplificada para expressar políticas da especialização WSP:

A especificação WSP é demasiada abstrata, expressa as capacidades, requisitos e características gerais de entidades em um WS baseado em XML. Desta forma, mantendo o foco
desse trabalho nas normas de segurança em nível de segurança de serviço e de mensagem, com

2.4. WEB SERVICES POLICY

37

ênfase na implementação 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 especialização da WSP para definir políticas de segurança que descreve
como mensagens devem ser protegidas. A política pode aplicar-se a mensagens individuais, a
operações ou a toda a extremidade do serviço. As asserções (ou assertivas) WSSP referem-se às
funcionalidades de segurança de WSS, WS-Trust12 e WS-SecureConversation13 . Podem também
referir segurança no transporte, como no protocolo HTTP (OASIS, 2012c).
A especialização WSSP provê flexibilidade nas asserções com respeito a tipos de token,
algoritmos de criptografia e mecanismos usados, incluindo o uso de segurança em nível de
transporte. Assim, permite que as mensagens requisitadas evoluam ao longo do tempo (OASIS,
2012c). Por exemplo, uma política pode especificar que a mensagem seja assinada com uma
chave de certificado digital X.509 e outra pode ditar que a autenticação seja feita com a chave de
um bilhete Kerberos.
A XML a seguir, apresenta a estrutura da WSSP de um serviço:

12 http://goo.gl/RHX5SJ,
13 http://goo.gl/ULrS1L,

Último Acesso em Novembro de 2015
Último acesso em Novembro 2015

38

2. REFERENCIAL TEÓRICO

A XML apresentou a existência de duas seções principais na definição da política: o
vínculo de segurança e a proteção. A seção da política que define o vínculo de segurança
referente à criptografia declarada nos elementos: criptografia simétrica <SymmetricBinding>,
criptografia assimétrica <AsymmetricBinding> e segurança no transporte <TransportBinding>.
Assim, o uso de criptografia de segurança pode ser utilizado para adicionar tokens de segurança
em cada vínculo de segurança, permitindo a transferência de chave e estrutura dos cabeçalhos
de segurança. Outra seção importante para a definição dos vínculos de segurança é a asserção
SymmetricBinding. Essa asserção permite a conexão segura entre o emissor e o receptor com
WSS, baseado em criptografia simétrica. Os tokens de segurança adicionados permitem ter
combinações mutuamente exclusivas, tal como: 

EncryptionToken (cifra) e SignatureToken (assinatura); 

ProtectionToken (cifra e assinatura em simultâneo).

As requisições que compõem as mensagens de resposta assumem as mesmas indicações
de segurança definido da mensagem submetida. Uma seção de segurança contém sub-asserções
que são um conjunto de afirmações, concedidas por um emissor, sobre determinadas informações. Algumas sub-asserção disponíveis para detalhar a configuração são: Layout (ordenação
dos elementos de segurança), IncludeTimestamp (incluir marca temporal na mensagem), EncryptSignature (cifrar assinatura), EncryptBeforeSign (cifrar antes de assinar), AlgorithmSuite
(algoritmos criptográficos a utilizar), ProtectTokens (incluídos tokens de segurança na assinatura)
e OnlySignEntireHeadersAndBody (assinar apenas corpo e cabeçalhos que não os de segurança).
As asserções AsymmetricBinding e TransportBinding permitem garantir segurança no
transporte das mensagens com base no WSS. A AsymmetricBinding garante através de criptografia
simétrica entre o emissor e o receptor e a TransportBinding garante a correlação de segurança
por meios externos.
As asserções de tokens de segurança possuem propriedades que permitem identificar
quais são os tokens aceitos e qual o processamento de ser realizado. Desta forma, os tokens
asserção 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 segurança 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
não mais. Esta opção é usada para iniciar sessões seguras;
AlwaysToRecipient: o token deve ser enviado sempre que o emissor enviar uma
mensagem para o receptor. O mesmo já não deve acontecer na resposta;

2.5. COMPUTAÇÃO EM NUVEM  

39

AlwaysToInitiator: o token deve ser enviado sempre que o receptor enviar uma
mensagem para o emissor. O mesmo já não deve acontecer na solicitação;
Always: o token deve ser sempre enviado nas mensagens. Podemos destacar a seção
da política que tem como objetivo definir a proteção:

Destacamos a especialização do WSP, a WSSP. Essa especialização segue alguns propósitos que podemos destacar: informações suficientes para que participantes possam determinar
compatibilidade e interoperabilidade; e informações necessárias para que uma entidade possa
participar em uma troca segura de mensagens SOAP.

2.5

Computação em Nuvem

De acordo com a definição do National Institute of Standards and Technology (NIST)
assume que “A computação em nuvem é um modelo para habilitar o acesso por rede ubíquo,
conveniente e sob demanda a um conjunto compartilhado de recursos de computação que possam
ser rapidamente provisionados e liberados com o mínimo de esforço de gerenciamento ou
interação com o provedor de serviços” (MELL; GRANCE, 2011).
Os grandes provedores de CN expõe um conjunto de Application Programming Interface (API) para interagir e gerenciar com os serviços oferecidos. Essas APIs são definidas e
especificadas pelas interfaces de um WS, como na WSDL descrita na Subseção 2.1.5. Independentemente dos propósitos de projetos de cada um, a abordagem de CN pode se relacionar com
a arquitetura SOA, através de padrões para WS, na utilização de componentes como um serviço Components as a Service (CaaS).
A Figura 2.6 utilização do diagrama de Venn14 para ilustrar a relação entre WS, SOA e
CN.
Figura 2.6: Relacionamento de Web Services, SOA e Computação em Nuvem

Fonte: Barry e Dick (2013) - adaptado.
14 Diagramas

usados em matemática para simbolizar graficamente propriedades, axiomas e problemas relativos

aos conjuntos e sua teoria.

40

2. REFERENCIAL TEÓRICO

O diagrama ilustrado acima, enfatiza a CN inserida dentro do conjunto de WS utilizando
SOA para indicar que a CN usa os serviços de WS, no entanto, a CN pode ser utilizada sem o
modelo SOA e WS. Nas próximas Subseções serão apresentados, de maneira sucinta e objetiva,
os modelos de serviço e de implantação. Dentre os aspectos as ameaças serão explanadas com
um pouco mais detalhes, visto que este é o aspecto de mais interesse desta pesquisa.

2.5.1

Modelos de Serviço

De acordo com o modelo de disponibilização de serviços oferecidos pelos provedores da
computação em nuvem, as nuvens computacionais podem ser classificadas da seguinte forma:   

2.5.2

Software como Serviço (Software as a Service - SaaS): Serviços de softwares de
propósito específico disponibilizado por meio de interfaces como um navegador de
internet. As aplicações em nuvens são multi-inquilinos, ou seja, são utilizadas por
diversos clientes simultaneamente.
Plataforma como Serviço (Platform as a Service - PaaS): Neste modelo o provedor
fornece serviços para ambiente para programação, sem a necessidade de instalar
ferramentas de desenvolvimento locais. O usuário possui o controle dessas ferramentas de gerenciamento de configuração, implantação e execução de aplicações nesta
infraestrutura.
Infraestrutura como Serviço (Infrastructure as a Service - IaaS): O serviço IaaS
fornece uma API de gerenciamento para utilização dos recursos de infraestrutura
computacional básica (capacidade de armazenamento e processamento).

Modelos de Implantação
De acordo com Mell e Grance (2011), há quatro modelos de implantação:   

Nuvem Comunitária: Uma nuvem de comunidade compartilha a infraestrutura
entre diversas organizações com interesses em comum (e.g. segurança, conformidade
ou jurisdição);
Nuvem Pública: Com uma nuvem pública, a infraestrutura da nuvem é de uso
aberto por qualquer tipo de cliente. Pode ser gerenciada, operada e pertencer a uma
empresa comercial, acadêmica ou governamental, ou uma combinação desses tipos
de organizações;
Nuvem Privada: Em uma nuvem privada, a infraestrutura é gerenciada e operada
exclusiva por uma organização, podendo ser administrada pela própria organização
ou por um terceiro;

2.5. COMPUTAÇÃO EM NUVEM 

2.5.3

41

Nuvem Híbrida: Uma nuvem híbrida é composta por duas ou mais nuvens de
quaisquer tipos mencionados acima. A conexão entre elas oferece benefícios dos
diversos modelos de implantação e permite portabilidade dos programas e dados seja
movidos facilmente de um sistema de implantação para outro.

Ameaças à Nuvem

O objetivo desta Seção é apresentar os riscos mais significativos de segurança associados
com a CN publicados pelo relatório “The Notorious Nine: Cloud Computing Top Threats in
2013”. Neste relatório, os especialistas identificaram as noves principais ameaças à segurança
em nuvem, que são: vazamento de dados, perda de dados, sequestro de contas ou tráfego de
serviços, interfaces inseguras, negação de serviços, usuário mal intencionado, abuso de serviços
da nuvem, investigação insuficiente e vulnerabilidades de recursos compartilhados (CSA, 2013).
Alinhado com os objetivos deste trabalho, nas normas de segurança em nível de serviço
e de mensagem e com base nesse relatório foi escolhido as cinco ameaças mais críticas do
modelo SaaS, contendo a análise de risco das principais propriedades básicas da segurança:
confidencialidade, integridade, disponibilidade, autenticidade e não r epúdio. A seguir serão
abordados os problemas a ser resolvido neste trabalho:

2.5.3.1

Vazamento de Dados

A ameaça de vazamento de dados ocupa a primeira posição no ranking de ameaças de
CN em 2013, segundo o relatório da CSA (2013). Esta ameaça aumenta pela características da
arquitetura do ambiente em nuvem. A proposta do modelo SaaS é prover aplicações que atendam
múltiplos clientes, chamados de multi-inquilinos, anulando a possibilidade de exclusividade
entre os clientes.
Por exemplo, um serviço de nuvem de banco de dados multi-inquilinos mal projetado,
permite o acesso indevido das informações de um cliente a partir de uma falha na aplicação,
comprometendo a confidencialidade das informações.
Outro exemplo preocupante, foram as notícias relacionadas à espionagem internacional,
através de monitoramento e colaboração de provadores de serviços de armazenamento e de
e-mails, informações sigilosas de governos e empresas vazaram, acompanhado com denúncias
de acesso a dados privados de cidadãos.

2.5.3.2

Perda de Dados

A ameaça de perda de dados subiu da quinta posição em 2010 para ocupar a segunda
posição em 2013 no Top Threat Ranking (CSA, 2013). Segundo o relatório Cloud Storage da
Fixya (2012), foram apontados problemas de segurança dos principais provedores do mercado

42

2. REFERENCIAL TEÓRICO

(Google Drive15 , SugarSync16 , iCloud17 , Box18 e Dropbox19 ), tais como abusos com relação à
privacidade, vazamento ou perda de dados, violação de direitos autorais, falhas na sincronização
de arquivos, dentre outros.
Conforme bem colocado pelo relatório 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 próprio nome sugere, ocorre
quando um usuário ou uma aplicação apaga, sobrescreve, altera os dados acidentalmente, sem
a intenção de prejudicar o proprietário das informações. E por fim, a perda de dados de forma
intencional dá-se quando também um usuário e uma aplicação apaga, sobrescreve, altera os
dados de forma proposital, motivado para causar algum tipo de dano ao detentor, comprometendo
principalmente a integridade da informação.
2.5.3.3

Sequestro de Contas ou de Tráfego de Serviços

O ataque de sequestro de contas ou de tráfego de serviços subiu da sexta posição em 2010
para ocupar a terceira posição no ranking de ameaças de CN em 2013, segundo o relatório da
CSA (2013). Os métodos de ataques como phishing, fraude e exploração de vulnerabilidades de
softwares não são mais considerados uma nova prática, mas ainda alcança resultados e acabam
por serem potencializados como o uso dos ambientes em nuvem. Isto ocorre porque são providos
milhares de contas de serviço, permitindo assim com que usuários 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, transações, manipular dados, retornar informações falsas e
redirecionar para outros usuários, o que amplifica o impacto de tais ataques. Em consequência
do comprometimento de uma conta de serviço do ambiente da nuvem, pode servir com uma nova
base para diferentes tipos de ataques, como o vazamento de dados de outras contas de serviço
que estejam na mesma nuvem (CSA, 2013).
Em abril de 2010, o bot Zeus20 , cavalo de troia que rouba informações da máquina
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 segurança, alvo desse tipo de vulnerabilidade (ZORZ, 2013). Pesquisadores
demonstraram um método de interceptar o tráfego SSL, a partir do software cliente Dropbox que
é instalado localmente, burlando o mecanismo de autenticação de dois passos e sequestrando
contas do provedor.
15 https://www.google.com/intl/pt-BR/drive/,

Último acesso em Novembro 2015
Último acesso em Novembro 2015
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/,

2.5. COMPUTAÇÃO EM NUVEM

43

Segundo o estudo realizado pela empresa de segurança Imperva22 , realizado em 2015
e disponibilizado através de um relatório23 , 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 relatório, não foi utilizado
nenhuma ferramenta de exploração ou qualquer código malicioso na fase inicial da "infecção",
tornando assim, muito difícil evitar este tipo de ataque. Os atacantes podem comprometer
o serviço de sincronização de arquivos na nuvem apenas roubando um token sem que seja
necessário comprometer a senha da vítima.
2.5.3.4

Interfaces Inseguras

A ameaça de Interfaces Inseguras desceu da segunda posição em 2010 para ocupar a
quarta posição 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 serviços. Essas APIs dão flexibilidades para interagir e gerenciar com serviços
em nuvem (e.g. gerenciamento, orquestração, provisionamento, monitoramento etc.), porém a
disponibilidade desses serviços depende de quão protegidas estão essas APIs.
O consumo indevido dessas interfaces por acesso anônimo, tokens ou senha reutilizáveis,
autenticação de texto não criptografado, controles de acesso inflexíveis ou autorizações indevidas,
entre outros aspectos que são negligenciados, oferecem um dos grandes riscos da computação
em nuvem privada (IBM, 2010). Segundo o estudo realizado por Wang et al. (2012),
relataram falhas preocupantes na implementação das API do mecanismo de autenticação SingleSign On (SSO) prestados pelas empresas como a Google ID, Facebook, PayPal e outros
serviços da Web. Essas falhas permite que o atacante acessem as contas das vítimas que utilizam
os serviços 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 são chamadas que não responde, 19% de falhas de
conteúdo de mensagens de erro, falta de dados, conteúdo errado e conteúdo não esperado, 12%
são falhas por respostas demoradas e 9% relacionadas a erros genéricos. Identificou-se que uma
das principais causas dessas falhas são as falhas de interações entre os sistemas.
2.5.3.5

Negação de Serviço

Um ataque de Negação de Serviço, ou do inglês Denial of Service (DoS) Attack, é uma
tentativa de tornar os recursos de um sistema indisponível ou mesmo responder de forma lenta
para os seus usuários. Não se trata de uma invasão ou coleta de informações do sistema, mas sim
destinado a impedir que os usuários, de um serviço de nuvem, sejam incapazes de acessar seus
dados ou suas aplicações.
22 http://www.imperva.com/,

Último Acesso em Novembro de 2015
Último Acesso em Novembro de 2015
24 https://goo.gl/F66SFu, Último acesso em Novembro 2015
23 http://goo.gl/KPD2Pc,

44

2. REFERENCIAL TEÓRICO

O atacante de DoS - ou atacantes, como é o caso de Distributed Denial-of-service
(DDoS) - exauri os recursos disponíveis por sobrecarga de duas formas: Esgotamento de recurso
como memória e processamento são sobrecarregados através de inúmeros processos criados e
executados, efetuando travamentos e erros. A segunda forma é o consumo da largura de banda de
rede, pois uma vez sobrecarregada a aplicação terá um acesso muito lento ou até mesmo perda
de acesso.
Segundo a CSA (2013), este ataque ganhou classificação para quinta posição do Top
Threat Ranking e aumentam a medida em que mais sistemas estão disponíveis online. Conforme
exposto por Holgersson e Soderstrom (2005), existem diversos tipos de ataques com a mesma
finalidade de comprometer a disponibilidade dos serviços prestados.

2.6

Considerações Finais

Nesta parte, foram descritas algumas das mais importantes normas que constitui a
arquitetura dos WS. A extensão WSS e suas tecnologias de segurança, também foram descritas,
bem como para os padrões que surgirão no futuro (POTTS, 2003). Apresentado a especificação
SAML que permite que domínios da web seguros troquem a autenticação de usuário e os dados
de autorização.
Também descrito a estrutura do WSP, a WSSP. Essa especialização segue alguns propósitos que podemos destacar: informações suficientes para que participantes possam determinar
compatibilidade e interoperabilidade; e informações necessárias para que uma entidade possa
participar em uma troca segura de mensagens SOAP. Por fim, uma explanação geral sobre
computação em nuvem foi realizada, destacando as ameaças mais significativas de segurança.
A próxima parte ira apresentar os principais trabalhos relacionados ao tema desta dissertação.

45

3
Trabalhos Relacionados
Para a presente dissertação, não foram encontrados trabalhos diretamente relacionados,
mas sim estudos que abordam: 1) análise de segurança para WS e CN; 2) utilização de testes de
segurança; 3) proposta de arquitetura de segurança. Além disso, a Tabela 3.1 elenca de maneira
sumarizada os trabalhos relacionados e avalia-os de acordo com as soluções propostas para
assegurar que as ameaças, descritas na Seção 2.5.3, sejam reduzidas a um nível aceitável.
Tabela 3.1: Comparativo entre as soluções dos trabalhos relacionados para mitigação das
ameaças

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

Negação
de Serviços

O

O

O

O
O

O
O

X
X
O

O
O
X
O
X
O
X

X
X
O

O

Fonte: própio autor.

No artigo de Macedo et al. (2010), é apresentada uma arquitetura de segurança 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 protótipo, com base nas especificações WSS, W S-BPEL1 e WSP. A limitação deste estudo
foi a análise em nível do tempo de processamento na troca das mensagens SOAP que trafegam
na rede informando requisições e autorizações.
Celesti et al. (2010) descrevem ambientes de nuvem heterogêneas e federadas,
denominado InterClouds. Como proposta, apresentam uma arquitetura de referência 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 autenticação. Os principais
requisitos levantados pela solução incluem a implementação do framework SAML para
estabelecer autenticação SSO e uma arquitetura SOA para enfrentar problemas de
interoperabilidade.
Dentre os objetivos apresentados no trabalho de Salas (2012), destaca-se a análise de
robustez dos WS, usando a técnica de Injeção de Falhas (IF), introduzindo falhas nas requisições
da mensagem SOAP. Destaca-se também o desenvolvimento de uma árvore de ataques para
selecionar os tipos de ataques a serem injetados e a construção dos cenários de ataques para
que sejam usados por testadores. Seus resultados demonstram que o padrão WSS reduz as
vulnerabilidades encontradas e melhora a robustez contra esses tipos de ataques.
Uma arquitetura como solução para o monitoramento de acordos de níveis de serviço
de segurança em nuvens é proposto por Ferreira (2013). Destaca-se o monitoramento dos
parâmetros de segurança de acordos Security-SLA, baseado em informações de desempenho
para detecção de anomalias de segurança. Utilizou-se a linguagem Web Service Level Agreement
(WSLA)2 e desenvolveu-se uma extensão para tratar a representação de políticas de segurança
desses acordos. Os resultados obtidos pela arquitetura proposta indicaram a possibilidade de
detecção de eventos de ataques do tipo negação de serviço e SQL-injection nos serviços em
execução em máquinas virtuais a partir de informações de desempenho.
A dissertação de Gonzalez (2014) propõe um Sistema de Gerenciamento de Credenciais (SGC) para computação em nuvem, que visa implementar uma solução de identificação de
entidades e controle de acesso à nuvem. Destacam-se a construção de uma arquitetura de gerenciamento de credenciais para autenticação e autorização baseada em OpenStack3, a construção
de uma taxonomia de serviços e de uma taxonomia de segurança em computação em nuvem. Os
resultados da solução proposta possibilitaram prover os mecanismos de segurança, implementados na linguagem de programação Python4, adequados para a nuvem sem a necessidade de
modificar as aplicações e serviços originais da mesma, alcançando uma solução transparente
para usuários, desenvolvedores e administradores da nuvem.
Em seu trabalho, Winckler (2014) avalia as soluções existentes e propõe um arquite-tura
de interoperação para nuvens que permita a criação de federações de nuvens computacionais
acadêmicas. Destacam-se a adoção de protocolos de comunicação como Representational State
Transfer (REST) e JavaScript Object Notation (JSON) e o framework SAML. Para validar a
solução apresentada foi desenvolvida um prova de conceito, a partir da combinação de alguns
componentes e protocolos já existentes, a arquitetura proposta é capaz de atender diversos
requisitos: autonomia local, descentralização, resiliência, manutenção, usabilidade, segurança 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 Março de 2016
3 https://www.openstack.org/,

3.1. CONSIDERAÇÕES FINAIS

47

Michelin (2015) foca especialmente em ataques de DoS, descrevendo
sistemas que utilizam o estilo REST autenticáveis através de tokens. A solução definida,
chamada de MADRA, propõe um mecanismo de mitigação de ataques de DoS que opere
em nível de aplicação, analisando as requisições no estilo REST. Após a validação de seu
conteúdo, é realizado o controle do tempo em que cada cliente ficará impossibilitado de enviar
novas chamadas. Utilizou-se para análise o componente Keystone, que é responsável pelo
mecanismo de autenticação e controle de acesso do sistema de gerenciamento de nuvem
OpenStack. Os resultados da avaliação da solução proposta demonstraram que o tempo de
resposta dos serviços ficaram próximos à utilização do sistema em condições normais de
operação, mesmo diante de um ataque DoS. Além do tempo de resposta, também reduziu o
uso do processador.

3.1 Considerações Finais
Esta parte apresentou diversos esforços propostos nas áreas de segurança para WS e
CN. Embora algumas das soluções apresentadas compartilhem características com o trabalho
proposto nesta dissertação, nenhuma das arquiteturas descritas atende completamente os controles
apropriados para assegurar que todas as cinco as ameças sejam reduzidas a um nível aceitável,
conforme apresentado na Tabela 3.1.
A escolha do protocolo SOAP sobre outros padrões, como REST, deve-se ao fato da
especificação SOAP fornecer mecanismo para controle de transações e suporte para comunicação
segura através da extensão WSS e também para atender aos padrões e políticas obrigatórias dos
ePING5 que tratam da forma de desenvolvimento de um WS, concebida como uma estrutura
básica para a estratégia de governo eletrônico, aplicada ao governo federal.

5 http://eping.governoeletronico.gov.br/,

Último Acesso em Março de 2016

49

4
Implementação da Proposta
A presente parte descreve a solução proposta e discute as características básicas da
arquitetura, seus componentes, funcionalidades e padrões, projetados para mitigar as principais
ameaças que impede a ampla adoção da computação em nuvem. E por fim, são analisados os
cenários de experimentos de campo a partir da utilização prática das especializações WSS, WSP
e SAML.

4.1

Metodologia 4+1

4+1 é um modelo de visão projetada por Kruchten (1995), que divide a arquitetura em
5 (cinco) visões: Visão Lógica, Visão Dependência, Visão de Implementação, Visão Física e
Cenários. Essas visões descrevem o sistema do ponto de vista das diferentes partes, em sua
essência, são fragmentos que ilustram os elementos “significativos em termos de arquitetura” dos
modelos. Também selecionados os cenários são utilizados para ilustrar a arquitetura servindo
como a visão ‘mais um’, definido o modelo 4+1 visualizações. Ele é composto pelas seguintes
visões:
Figura 4.1: Interação das Visões do Modelo 4+1

Fonte: Kruchten (1995) - adaptado. 

Visão Lógica: aborda os componentes significativos do projeto para a Arquitetura
adotada e a funcionalidade que o sistema fornece aos utilizadores finais;

50

4. IMPLEMENTAÇÃO DA PROPOSTA    

4.2

Visão Dependências: Ilustra as dependências existentes entre os módulos da Arquitetura;
Visão Implementação: A visão de implementação ilustra um sistema da perspectiva
de um desenvolvedor relacionados com a organização do código-fonte do sistema,
padrões de Arquitetura utilizada e as orientações e as normas para o desenvolvimento
do sistema;
Visão Física: Demonstra as configurações de hardware e os sistemas do ponto de
vista de um engenheiro de sistema. A topologia responsável pelos componentes de
softwares na camada física, bem como as ligações físicas entre esses componentes;
Cenários : Mostram um subconjunto dos Cenários dos Experimentos de Campo
significativos da Arquitetura. Os cenários servem como ponto de partida para testes
de um protótipo de arquitetura.

Visão Lógica

Esta Seção demonstra a organização da arquitetura proposta a partir de um ponto de vista
funcional. Os principais elementos, como módulo e componentes principais são especificados.
A Figura 4.2 ilustra a arquitetura de ponto de vista lógico:
Figura 4.2: Visão lógica da Arquitetura de Referência proposta

Fonte: próprio autor.

As Subseções seguintes explicitarão cada módulo, ressaltando sua responsabilidade e os
requisitos atendidos.

4.2. VISÃO LÓGICA

4.2.1

51

Módulo de Serviço

O Módulo de Serviço provê um catálogo de serviços oferecidos aos consumidores de
uma nuvem. Um catálogo de serviços é um documento XML, especificamente definido no padrão
WSDL, que obedece a uma estrutura fixa para especificar interface de serviço. O catálogo inclui
asserções de política, conjunto abstrato de operações implementadas por um serviço, formatos e
protocolos específicos. Esse módulo é constituído pelo seguinte componente: 

4.2.2

Provedor de Serviço: O componente Provedor de Serviço, estruturado na especialização WSDL, é responsável em definir e especificar as interfaces de serviço. Essas
interfaces contêm informações do tipo, localização do serviço, o que o serviço pode
fazer e como poderá ser chamado, permitindo assim, a interação do serviço. Esse
componente é responsável em descrever e publicar os serviços que posteriormente
serão consumidos pelos clientes.

Módulo de Mecanismos de Segurança

O Módulo de Mecanismo de Segurança, implementado pelas funcionalidades do padrão
WSS, é responsável em oferecer mecanismos padrões de segurança necessários para realizar o
intercâmbio seguro de mensagens certificadas em ambientes de nuvem, através de assinaturas
digitais e criptografia. Oferece também, o gerenciamento do ciclo de vida de chaves como
registro, distribuição e revogação. Dentre as funcionalidades oferecidas são constituídas dos
seguintes componentes:   

Proteção do Tráfego de Rede: O componente de Proteção do Tráfego de Rede é
guiado pelo padrão XML Encryption que provê segurança fim-a-fim para aplicações
que necessitam realizar trocas de dados de forma segura. Além disso, provê um
mecanismo de segurança que não é coberto pelo TLS/SSL, como a possibilidade de
cifrar somente parte de um dado e o estabelecimento de sessões seguras entre mais
de duas partes (W3C, 2013).
Encriptação de Dados: A segurança provida do componente, Encriptação de Dados,
oferece um nível de privacidade por cifrar os dados evitando que terceiros vejam seu
conteúdo, desta forma, a criptografia em XML fornece funcionalidades complementares para o padrão XML Digital Signature e permite criptografar um documento XML
completo, partes selecionadas de um documento XML ou conteúdo referenciado
por um documento XML. Esse componente também é guiado pelo padrão XML
Encryption.
XKMS: O componente XKMS é implementado pela especificação XML Key Management Specification (XKMS), definido um protocolo para registrar e distribuir

52

4. IMPLEMENTAÇÃO DA PROPOSTA
chaves criptográficas que utilizam Infraestrutura de Chaves Públicas (PKI). Esse
componente auxilia a distribuição de chaves públicas, que são essenciais para XML
Digital Signature e XML Encryption, possibilitando verificações de assinaturas e
criptografia em mensagens SOAP. Divide-se em duas especificações a XML Key
Registration Service Specification (X-KRSS), para o registro de chaves, e o XML
Key Information Service Specification (X-KISS), para requisição e distribuição de
informações referentes às chaves públicas registradas (W3C, 2005).

4.2.3

Módulo de Políticas de Segurança

O Módulo de Políticas de Segurança especifica requisitos, capacidades ou preferências
aplicadas em clientes e serviços de forma interoperável. O presente módulo permite expressar as
políticas que se referem a recursos de domínio específico, requisitos e características gerais.
O framework WSP fornece a estrutura do MPS para interpretação dos requisitos exigidos.
O presente módulo é constituído dos seguintes componentes:  

4.2.4

Alternativa de Política Alternativa de Política é responsável em definir uma coleção
não ordenada de asserções da políticas, define também uma expressão de política na
forma normal e um conjunto de regras que podem ser usadas para criar expressões de
políticas mais compactas.
Asserção de Política A Asserção da Política é responsável em especificar requisitos
tradicionais e capacidades que, em última instância, se manisfestarão em ligações,
por exemplo, no esquema de autenticação ou na seleção do protocolo de transporte.
Outras asserções da política possuem nenhuma manifestação de ligação, ainda que
adequados do serviço, por exemplo, política de privacidade e características de
Quality of Service (QoS).

Módulo de Gerenciamento de Acesso e Identidade

O Módulo de Gerenciamento de Acesso e Identidade (MGAI), conduzido pela especificação SAML, possui a responsabilidade de proteger os sistemas, dados e aplicativos de acesso
não autorizado. Permite criar, gerenciar usuários e grupo e usar permissões para conceder e
negar acesso aos recursos providos. Os componentes que constitui o MGAI são controlados
pelas funcionalidades da SAML. Este módulo é constituído por 3 (três) componentes que serão
escrito a seguir: 

Base de Entidades: A Base de Entidades é responsável em suportar o protocolo
Lightweight Directory Access Protocol (LDAP) para integração dos mecanismos de
autenticação como Active Directory (AD)1 da Microsoft e OpenLDAP (OLDAP)2 .

1 https://goo.gl/8OaMoZ,

Último Acesso em Novembro de 2015
Último Acesso em Novembro de 2015

2 http://www.openldap.org/,

4.3. VISÃO DEPENDÊNCIA

53

Ao utilizar o AD ou OLDAP como fonte de o acesso às funcionalidades, permissões
por usuários ou grupo, é recomendável utilizar a replicação de LDAP para garantir a
disponibilidade do serviço.  

4.3

Provedor de Identidade: O Provedor de Identidade (IdP) é responsável pela manutenção das informações sobre os usuários e por sua autenticação. O componente
Provedor de Serviço, abordado no módulo MS, requisita o IdP informando as credencias de acesso passada pelo usuário, por sua vez o IdP encaminhará uma afirmação
SAML, como parte da resposta de autenticação, que é gerada para obter credenciais
de segurança temporárias de acesso aos serviços providos.
Serviço de Token de Segurança: O Serviço de Token de Segurança é responsável
por gerenciar as credenciais temporárias de segurança que consistem em uma chave
de acesso e um token de sessão. A chave de acesso consiste em um ID chave de
acesso e uma chave secreta. Usuários (ou um aplicativo que o usuário executa) podem
usar essas credenciais para acessar os serviços providos na organização.

Visão Dependência

Esta seção visa ilustrar as dependências existentes entre os módulos da Arquitetura de
Software. A Figura 4.3 ilustra o diagrama de dependências entre os módulos desta proposta.
Figura 4.3: Diagrama de Dependências

Fonte: próprio autor.

Como pode ser observado na Figura 4.3, o módulo MPS é o mais utilizado. Deve-se
ao fato dos componentes dos módulos desta Arquitetura de Software estar dependente desse
módulo, no que lhe concerne das restrições de segurança que poderão ser expressas. Logo, o
MS depende do MPS relacionado as políticas que pretendem criar um processo para facilitar a

54

4. IMPLEMENTAÇÃO DA PROPOSTA

tarefa de encontrar, definir e gerenciar os serviços disponibilizados. Por fim, as dependências
dos módulos MMS e MGAI para atender aos requisitos de confidencialidade e autenticidade
respectivamente dos serviços prestados.
Assim como no diagrama de dependência, o MGAI contém dependência dos MPS e
MMS, deve-se ao fato do MMS ser o mecanismo padrão de segurança necessário para realizar
o intercâmbio seguro de mensagens, através de certificados digitais e criptografia e pelo MPS
definir as políticas para criar, trocar e interpretar asserções de segurança entre entidades de uma
aplicação.

4.4

Visão Implementação

Este tópico prover uma visão da implementação da arquitetura do protótipo do sistema. A
arquitetura definida utiliza frameworks e tecnologias para agilizar o processo de desenvolvimento
sendo estruturados em camadas para desacoplar o código fonte e facilitar futuras manutenções.
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, serão descritos cada um dos frameworks e tecnologias utilizadas nas camadas
da arquitetura do sistema:  

WSDL: Conforme apresentado na Parte 2 na Seção 2.1.5, a WSDL, será disponibilizada na camada de comunicação, fornecendo as funcionalidades presentes no Web
Service. Essas funcionalidades refletem as interfaces de serviços disponibilizadas na
camada de negócio.
Spring Framework3 : Esse framework oferece diversos módulos que podem ser
utilizados de acordo com as necessidades do projeto, como módulos voltados para
desenvolvimento Web, inversão de controle e programação orientada a aspectos,
injeção de dependências, desenvolvimento baseada em POJO e integração com
tecnologias de persistência e controle de transações como Hibernate. Compatibilizase com Spring Cloud Security4 na proteção da transmissão de tokens entre SSO e
aplicações nas nuvens.

3 https://goo.gl/oED3ey,

Último Acesso em Novembro de 2015
Último Acesso em Janeiro de 2016

4 http://cloud.spring.io/spring-cloud-security/,

4.5. VISÃO FÍSICA 

4.5

55

Hibernate Framework5 : É um framework para o mapeamento objeto-relacional
escrito na linguagem Java. Sua principal característica é a transformação das classes
em Java para tabelas de dados. O Hibernate gera as chamadas SQL e libera o
desenvolvedor do trabalho manual da conversão dos dados resultante, mantendo o
programa portável para quaisquer bancos de dados SQL.

Visão Física

O ambiente de nuvem privada adotado é contemplado pela solução VMware Integrated
OpenStack (K)ilo, suportando o VMware vSphere, especificamente o produto VMware ESXi
na versão 5.0.0. VMware ESXi é um hypervisor6 que consiste na virtualização do servidor,
armazenamento e rede, permitindo a execução de vários aplicativos em máquinas virtuais no
mesmo servidor físico (VMWARE, 2009; ABDELRAZIK et al., 2015).
Conforme descrito por Damasceno (2015), as imposições causadas pelas legislações
brasileira afetaram diretamente o uso da computação em nuvem pela administração pública
federal. Com objetivo de atender as estratégias das instituições como das Forças Armadas,
buscou-se a criação de ofertas de serviços de nuvem privada consistentes dentro das fronteiras
do data center do Terceiro Centro Integrado de Defesa Aérea e Controle de Tráfego Aéreo
(CINDACTA III).
Para validar a arquitetura de referência proposta, a solução de nuvem privada descrita
acima, utilizou 1 (uma) máquina servidora de aplicação rodando um hardware PowerEdge R710
da Dell7 . As configurações do servidor de aplicação são: 

4 processadores Intel(R) Xeon(R) CPU E5620 2.40GHz 

64GB de memória RAM 

300 GB de disco 

4 Interfaces de Rede GigabitEthernet

Para executar os testes deste trabalho, a máquina servidora permitiu gerenciar máquinas
virtuais com as seguintes configurações: 

2 processadores 

4GB de memória RAM 

50 GB de disco

5 https://goo.gl/SLtiHm,

Último Acesso em Novembro de 2015
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

4. IMPLEMENTAÇÃO DA PROPOSTA 

Sistema Operacional Linux Debian Squeeze8 de 64bits

Os testes foram realizados utilizando em um Notebook Dell Inspiron 14 Série 5000 com
cliente de requisição ao servidor de aplicação. As configurações da máquina do cliente são:

4.6 

1 processador Intel(R) Core(TM) i7-4510U CPU 2.60GHz 

16GB de memória RAM 

1TB de disco 

Sistema Operacional Windows 10 Home Single Language de 64bits

Cenários

Esta Seção visa apresentar alguns dos principais cenários, descritos em experimentos de
campo, da Arquitetura de Software proposta.

4.6.1

Desenvolvimento da Aplicação

Esta Subseção tem como objetivo demonstrar a utilização prática da especialização WSS,
WSP e SAML como parte do trabalho desta dissertação. Demonstra as principais atividades
dos serviços oferecidos pela solução proposta, implementado em um protótipo de um aplicação,
com objetivo de utilizar os principais conceitos relacionados à segurança de WS nas mensagens
SOAP apresentados neste trabalho.
Inicialmente, a ferramenta Axis 2, que será apresentada na próxima parte, gerou um WS
a partir da interface LogonServiceImpl.java do sistema. A interface como o WS gerado possui o
método autenticar passando em dois parâmetros: duas string apresentando o usuário e senha
referente as credencias de acesso a aplicação. O WS implementado, no arquivo AccessControl.wsdl, recebeu todos os serviços propostos pela aplicação. O método autenticar retorna ao
cliente uma mensagem no console de sucesso, de erro ou de exceção.
O Cliente do WS, por sua vez, implementou o arquivo WSLogonServiceClient.java,
através da classe LogonServiceImplStub.java realiza as chamadas aos métodos da interface
do WS, enviando os dados necessários para consumir os serviços disponibilizados. Após a
invocação do serviço, o cliente recebe uma mensagem de sucesso, confirmando a transação da
operação ou uma mensagem de erro ou de exceção, informando que a transação não foi efetuada
corretamente.
A comunicação entre o cliente e o WS só é realizada através do acordo entre as definições
das políticas de comunicação, através do lado do cliente pelo arquivo policyClient.xml e pelo lado
do WS o arquivo policyService.xml. Ambos definem a segurança desejada da mensagem SOAP
8 https://www.debian.org/,

Último Acesso em Dezembro de 2015

4.6. CENÁRIOS

57

do WS em estudo. Através dessas políticas de comunicação, a mensagem SOAP monitorada foi
composta pelos mecanismos de segurança definidos.

4.6.2

Experimento de Campo

Esta Subseção apresenta uma análise dos padrões WSS, WSP e SAML, destacando suas
aplicabilidades através de cenários de experimentos de campo que visa avaliar estes padrões
de segurança. A seguir, será apresentada a parte de maior interesse para o presente trabalho: a
implementação de WS com objetivo de mitigar as cinco ameaças, descritas na Subseção anterior,
em nível de serviços e de transporte de mensagem. A análise 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 tráfego da rede INTRAER. Especificamente, aplicamos a expressão de filtro: "http && ip.src = 10.80.8.85", com
objetivo de controlar o tráfego de pacotes HTTP enviados pela máquina com o IP "10.80.8.85".
Conforme ilustrado na Figura 4.5, apresenta a requisição de um pacote HTTP, contendo uma mensagem SOAP. Percebe-se que as credenciais de acesso, destacadas em vermelho, são facilmente
obtidas pelo monitoramento da rede INTRAER.
Figura 4.5: Exemplo de pacote HTTP capturado pelo Wireshark

Fonte: próprio autor.
9 https://www.soapui.org/
10 https://www.wireshark.org/

58

4. IMPLEMENTAÇÃO DA PROPOSTA

O cenário, apresentado, exemplificou o sequestro de credenciais de acesso de uma conta.
Diante do exposto e descrito na Seção 2.5.3, foi confeccionado o estudo de caso 01, com objetivo
de mitigar tais ameaças. Utilizou-se a especificação WSS, especificamente XML Signature, para
gerenciar as credencias declarada no cabeçalho da mensagem SOAP, e aplicado a técnica de
autenticação de criação de senha com três atributos. Assim, o formato da mensagem SOAP de
requisição é representada:

Como pode ser observado na mensagem SOAP, demonstra a utilização do elemento
<UsernameToken> (OASIS, 2012b) com o gerenciamento de credenciais declarada no cabeçalho
da mensagem SOAP. Este experimento é inicializado quando o usuário (Web Service Client)
realiza uma requisição ao serviço de segurança de tokens, solicitando um token válido 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 combinação do elemento nonce, o tempo
de criação, a partir do elemento <wsu:Created>, e mais a senha em texto claro. Esta função,
passwordDigest, é resumida em: Base64(SHA-1(Nonce + Created + Password)). O elemento
<wsse:Nonce> é um número 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 criação e de uso único. O nonce nunca se repete, um serviço gerencia
a criação do nonce para evitar ataques de replay, aonde a mesma mensagem é capturada em
trânsito e re-enviada na tentativa de confundir ou interromper o serviço, 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 autenticação para recuperar a senha relacionado com o nome do usuário, o
Nonce e o tempo de criação da mensagem, gerando uma função hash que é validada com o
PasswordDigest da mensagem SOAP recebida. Se os resultados estão de acordo, o WS retorna
uma mensagem informando que autenticação foi realizada com sucesso.
É recomendável o uso de segurança em nível de transporte na utilização do método
UsernameToken, como SSL (e.g. Hyper Text Transfer Protocol Secure (HTTPS)) ou o uso da

4.6. CENÁRIOS

59

especificação XML Encryption, pois as credenciais de acesso podem ser interceptadas a qualquer
um que seja capaz de monitorar a mensagem.
A especificação WS-PolicySecurity foi utilizada para definir políticas no esquema de
autenticação e na seleção do protocolo de transporte. O elemento <sp:UsernameToken> contem
o atributo IncludeToken para definir o tipo de fluxo de mensagens especificando a inclusão 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 política de segurança como
um todo. Para aplicá-la, o elemento <wsp:PolicyReference> foi declarado informando seu
atributo URI para referenciar a política em questão, em nível de serviço (autenticar) do trecho do
arquivo WSDL. Conforme exemplificado abaixo:

60

4. IMPLEMENTAÇÃO DA PROPOSTA

A conexão segura, utilizou o protocolo HTTPS, foi estabelecida a partir das configurações
realizadas no Apache Tomcat, conforme descrito no Apêndice A.
4.6.2.2

Estudo de Caso 02

Este estudo de caso tem como objetivo demonstrar a aplicabilidade das especializações
XML Digital Signature e XML Encryption, conforme apresentadas nas Subseções 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 cabeçalho da mensagem SOAP e nas encriptações dos elementos
declarados no corpo da mensagem SOAP.

4.6. CENÁRIOS

61

62

4. IMPLEMENTAÇÃO DA PROPOSTA

Através da análise do cabeçalho da requisição SOAP, expresso pela XML acima, nota-se
a criação do elemento EncryptedKey definindo a chave que será usada para cifrar os dados. O
método usado para cifrar a chave é o RSA versão 1.5. Outro elemento criado foi o KeyInfo que
possui várias informações sobre a chave, como por exemplo, o tipo do certificado utilizado, que
no caso é X509v3.
O elemento KeyInfo indica também a chave a ser usada para validação da assinatura. O
elemento BinarySecurityToken foi declarado para criação de um token binário que vai ser usado
na assinatura da mensagem. Após a criação do token é iniciada a criação da assinatura em si
com o elemento Signature. Dentro do elemento Signature, temos várias configurações referentes
à assinatura, que são:   

SignatureMethod: especifica o algoritmo usado na assinatura, no caso, RSA-SHA1;
DigestMethod: especifica o método usado para criar o resumo criptográfico, que no
caso foi o SHA-1;
DigestValue: valor do resumo criptográfico.

Depois de especificadas as configurações da assinatura, podemos ver o valor da assinatura
que está no elemento SignatureValue. Ainda dentro da assinatura, temos informações sobre a
chave usada, onde, como podemos ver, foi usado o token binário criado anteriormente.
Também temos outro elemento, o Timestamp, igualmente importante para a assinatura,
pois ele possui a data de criação e de expiração da assinatura. O usuário define o tempo de
expiração, geralmente em segundos. Caso o servidor identifique a mensagem em um tempo
maior do que o declarado, a mensagem SOAP é rejeitada. A utilização correta dessa tag faz
necessário que seja disponibilizado um serviço de sincronização dos relógios do servidor e do
cliente, para evitar que as mensagens SOAP válidas sejam rejeitadas.
Após a especificação das informações da chave, o padrão XML Encryption permitiu cifra
a conteúdo do corpo da mensagem SOAP informando no elemento CipherValue. Aninhado com
este elemento, é definido o método que será usado para cifrar os dados (EncryptionMethod), que
é o triple DES em modo cbc.
Desse modo, termina o cabeçalho da requisição SOAP onde foram criados a chave e a
assinatura necessários para cifrar e assinar o documento XML.

4.6. CENÁRIOS

63

64

4. IMPLEMENTAÇÃO DA PROPOSTA

A resposta da mensagem SOAP exibida acima, é idêntica a requisição que a originou,
com a chave e assinatura definidos no cabeçalho e o corpo da mensagem cifrado.

4.6. CENÁRIOS

65

A especialização WS-Policy, descrita na XML acima, foi declarada no WSDL e definido
um ID para uma política, Rule1. Aninhado com o elemento <wsp:Policy>, o elemento <wsp:All>
exige que todas as políticas compreendidas devem ser atendidas. A política foi concebida com
objetivo de transmitir condições de uma interação entre o cliente e o servidor.
Dessa forma, o elemento <sp:AsymmetricBinding> foi declarado para indicar um vínculo
de segurança de criptografia assimétrica obrigatória. 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 proteção em troca
de mensagem.
O elemento <sp:TransportBinding> é usado para especificar a segurança do transporte
de mensagens e correlação de segurança fornecida por outros meios, no caso, um transporte
seguro utilizando o protocolo HTTPS, conforme definido pelo elemento <sp:TransportToken>.
A declaração obrigatória do elemento <sp:AlgorithmSuite> define o algoritmo necessário para
a realização das operações criptográficas com tokens de segurança simétrica. O elemento
<sp:Layout> foi declarado para indicar um requisito rigoroso no layout de segurança do cabeçalho da mensagem SOAP com propriedade e o elemento <sp:IncludeTimestamp> defini uma
janela de tempo durante o qual a requisição será válida.
E por fim, o elemento <sp:EncryptedParts>, contém um elemento <sp:Body/> aninhado,
o que significa que o corpo da mensagem SOAP é obrigado a ser criptografado.
As especificações XML Digital Signature e XML Encryption são componentes importantes na segurança no transporte de dados da mensagem SOAP e no consumo dos serviços
disponibilizados. Fornece um mecanismo de assinatura digital muito flexível. A especialização
WS-Policy, por sua vez, prover uso de políticas que definem como os serviços disponibilizados
estão autorizados a interagir com outros clientes e serviços.
4.6.2.3

Estudo de Caso 03

O estudo de caso 03 apresenta a tecnologia SAML baseado no mecanismo de autenticação
Single Sign-On (SSO). O Diagrama de Sequência apresentado na Figura 4.6, ilustra a sequência
de mensagens entras as entidades: Provedor de Identidade (IdP), Provedor de Serviço (SP) e
o usuário/aplicação. Dessa forma, este estudo de caso pretende apresentar duas mensagens
SOAP, com declarações SAML, incluindo um pedido de requisição de autenticação e a última
mensagem de resposta da autenticação contendo uma asserção SAML.

66

4. IMPLEMENTAÇÃO DA PROPOSTA
Figura 4.6: Diagrama de Sequência Estudo de Caso 03

Fonte: próprio autor.

A especificação WSS especifica assertivas ou tokens de segurança SAML integrada no
mecanismo de segurança da mensagem SOAP.

A mensagem SOAP apresentada acima, descreve implementações capaz de processar

4.6. CENÁRIOS

67

referencias de asserção SAML que ocorrem em um elemento <wsse:Security> do cabeçalho da
mensagem SOAP. O elemento <wsse:SecurityTokenReference> declarou um token de segurança,
com objetivo em assinar as asserções do SAML. A aplicação assume um usuário com a conta
tiad@cindacta3.aer.mil.br, declarado no elemento <samlp:Subject>, está tentando consumir um
serviço declarado no WS.
O elemento <saml:Assertion> define o local, ligação, e consulta que podem ser utilizados
para adquirir a afirmação identificada em uma asserção SAML. O valor do atributo ID do
elemento <samlp:AuthnRequest> é enviado para o provedor de identidade (IdP) do Serviço de
SSO que inclui autenticação e autorização.

68

4. IMPLEMENTAÇÃO DA PROPOSTA

Nesta etapa, é apresentada a mensagem SOAP de resposta do SAML indicando que
o usuário tiad@cindacta3.aer.mil.br está autorizado a acessar o serviço, confirmado pela tag
<samlp:StatusCode>. Dessa forma, todas as afirmações SAML são incorporadas na mensagem
de resposta, com objetivo da criação de um único contexto de autenticação.
A mensagem de resposta SAML contém 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 afirmação identificada da asserção SAML.
NOT_BEFORE: Timestamp de controle para identificar a data e hora anterior a
resposta SAML é considerada inválida.
NOT_ON_OR_AFTER: Timestamp de controle para identificar a data e hora após
a resposta SAML é considerada inválida.
AUTHN_INSTANT: Timestamp indicando a data e hora em que o usuário foi autenticado.

O estudo de caso 03 apresentou os mecanismo e procedimentos de segurança representada
pelas as asserções SAML na mensagem SOAP, juntamente integrada a especificação WS-Security.
A criação das asserções SAML integrada a especialização WSS permitiu realizar a comunicação
de autenticação e autorização do usuário, e as informações de atributos. Segurança de mensagens
SOAP não introduz novas ameaças além das identificadas para SAML ou pelo WSS.

4.7

Considerações Finais

Esta Parte iniciou-se apresentando o guia de descrição da arquitetura proposta, conhecido
como método 4+1, mostrando-se bastante efetiva para o contexto desta dissertação.

4.7. CONSIDERAÇÕES FINAIS

69

Em seguida, a arquitetura proposta foi apresentada, de acordo com as visões desse
método: Lógica (Seção 4.2), Dependência (Seção 4.3), Implementação (Seção 4.4) e Física
(Seção 4.5). E por fim, foram analisados os cenários de experimentos de campo a partir da
utilização prática das especializações WSS, WSP e SAML.
Na próxima Parte será descrita a avaliação da arquitetura proposta, bem como a utilização
das normas de segurança abordadas ao longo deste trabalho, apresentando os resultados obtidos
pelos experimentos de campos analisados.

71

5
Avaliação da Proposta
Esta Parte descreve a avaliação da proposta, na busca de analisar as normas de segurança
em nível de serviço e de mensagem para WS. A abordagem dessa avaliação inicia-se pela
descrição da metodologia utilizada, objetivos e componentes necessários para reproduzir os
experimentos de campo. Em seguida, são descritos os resultados obtidos quanto à garantia
das propriedades básica da segurança. E por fim, são apresentadas as conclusões acerca dos
resultados dos estudos de caso.

5.1

Metodologia

A metodologia utilizada para avaliação baseou-se na abordagem GQM (Goal, Question,
Metric) proposta por Basili e Caldeira (1994), com intuito de proporcionar um formalismo e
planejamento quando à medição 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. Definição; 3. Coleta de Dados; e 4. Interpretação.
Figura 5.1: Fases da metodologia GQM

Fonte: Basili e Caldeira (1994).

72

5.1.1

5. AVALIAÇÃO DA PROPOSTA

Planejamento

A fase de planejamento trata-se da logística de aplicação 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 implantação e desenvolvimento dos estudos de caso descritos na
Parte 4. O experimento de campo tem como objetivo conduzir um cenário real, a fim de testar
uma determinada causa de efeito. Para a realização dessa avaliação, foram estudadas as técnicas
e os padrões descritos nas documentações publicadas pelas organizações W3C e OASIS, guiando
a implementação da arquitetura.
5.1.1.1

Publico alvo e cenário de atuação

O público alvo são os usuários que utilizam os sistemas administrativos da Seção da
Informática Administrativa (TIAd) do CINDACTA III, portanto, o cenário de atuação.
O CINDACTA III é uma organização militar do Comando da Aeronáutica (COMAER) e
é subordinado diretamente ao Departamento de Controle do Espaço Aéreo (DECEA). É também
uma Organização regional, dispondo, além de sua Sede em Recife-PE, de dez Destacamentos de
Controle do Espaço Aéreo (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 Seção da TIAd. A Seção da TIAd concentra toda infraestrutura necessária
para implantação de Nuvem Privada dos sistemas administrativos, que são acessados por todos
os Destacamentos Subordinados do CINDACTA III através da Rede de Dados do Comando da
Aeronáutica (INTRAER).
5.1.1.2

Critério de Avaliação

O estudo selecionou as cinco ameaças mais críticas classificadas pelo referido relatório
da CSA, usado dois critérios: As ameaças classificadas pelo modelo SaaS e pelas propriedades
básicas de segurança. Tais critérios foram delineados com foco da avaliação dos objetivos deste
trabalho.
Seguindo os critérios anteriormente mencionados, os estudos de caso serão avaliados em
sua completude de garantir as propriedades básicas de segurança das 5 ameaças selecionadas.
Conforme abordado as ameaças na Subseção 2.5.3, a CSA apresenta a análise de risco, a partir
da Tabela 5.1 de forma sumarizada, das principais propriedades de segurança afetadas por cada
uma das ameaças.

5.1. METODOLOGIA

73

Tabela 5.1: Propriedades de segurança afetadas por ameaças
```
```
``` Ameaças Vazamento
```
de Dados
Propriedades
``
`

Confidencialidade
Integridade
Disponibilidade
Não Repúdio
Autenticação

Perda
de Dados

X
X
X

Sequestro
de Contas

Interfaces
Inseguras

X
X
X
X
X

X
X

Negação
de Serviços

X
X

Fonte: CSA (2013).

A CSA também classificou, em sua análise de risco, uma série de ataques que podem
utilizar as ameaças analisadas. Na Tabela 5.2 é apresentada de forma sumarizada qual ataque é
aplicado a cada ameaça.
Tabela 5.2: Ataques utilizados para cada ameaça
XX
XXX
XXAmeaças
XXX
Ataques
XX

Spoofing
Adulteração de Dados
Divulgação de Informação
Repúdio
Negação de Serviço
Elevação de Privilégios

Vazamento
de Dados

Perda
de Dados

X
X
X

Sequestro
de Contas

Interfaces
Inseguras

X
X
X
X

X
X
X

Negação
de Serviços

X
X

X

Fonte: CSA (2013).

De posse dos experimentos de campo, os estudos de caso contemplam assim os requisitos
necessários para a avaliação da arquitetura de referência com base nas normas e implementações
de segurança propostas neste estudo.

5.1.2

Definição

Na fase de definição deve-se definir os objetivos do GQM, as questões a serem respondidas e definir e refinar as métricas, seguindo a estrutura conforme ilustrada na Figura 5.2 e
desenvolvido na Tabela 5.3.
Os protótipos desenvolvidos, com base nos estudos de caso, irão disponibilizar serviços
que serão consumidos pela ferramenta soapUI, em seguida a ferramenta de monitoramento
Wireshak irá auxiliar na análise do comportamento de requisição e resposta entre as partes
envolvidas.

74

5. AVALIAÇÃO DA PROPOSTA
Figura 5.2: Estrutura da Fase de Definição

Fonte: Basili e Caldeira (1994) - adaptado.

O objetivo esperado é que as tecnologias de serviço seguros propostos pela normas
WSS, SAML e WSSP garantam as propriedades básicas de segurança das serviços providos. As
métricas são baseadas nos principais recursos oferecidos por essas normas descritas neste estudo.
A escala foi definida de acordo com a mitigação das ameaças de cada métrica e garantia dos
atributos básicos de segurança.

5.1. METODOLOGIA

75

Tabela 5.3: Definição das Questões e Métricas para avaliação

Questões

Descrição

Métricas

Contexto

Escala

Estudo de Caso 01
Subseção 4.6.2.1

0 - Não se aplica
1 - Fraco
2 à 3 - Razoável
4 - Satisfatório
5 - Excelente

Estudo de Caso 02
Subseção 4.6.2.2

0 - Não se aplica
1 - Fraco
2 à 3 - Razoável
4 - Satisfatório
5 - Excelente

Estudo de Caso 03
Subseção 4.6.2.3

0 - Não se aplica
1 - Fraco
2 à 3 - Razoável
4 - Satisfatório
5 - Excelente

Vazamento de Dados
Subseção 2.5.3.1

[Q1] Quão eficaz é a
proteção das
tecnologias utilizadas
no Estudo de Caso 01
diante das ameaças?

Perda de Dados
Subseção 2.5.3.2
Sequestro de Contas
Subseção 2.5.3.3

1. XML Signature
2. Security Tokens
3. WS-SecurityPolicy
4. HTTPS

Interfaces Inseguras
Subseção 2.5.3.4
Negação de Serviço
Subseção 2.5.3.5
Vazamento de Dados
Subseção 2.5.3.1

[Q2] Quão eficaz é a
proteção das
tecnologias utilizadas
no Estudo de Caso 02
diante das ameaças?

Perda de Dados
Subseção 2.5.3.2
Sequestro de Contas
Subseção 2.5.3.3
Interfaces Inseguras
Subseção 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

Negação de Serviço
Subseção 2.5.3.5
Vazamento de Dados
Subseção 2.5.3.1

[Q3] Quão eficaz é a
proteção das
tecnologias utilizadas
no Estudo de Caso 03
diante das ameaças?

Perda de Dados
Subseção 2.5.3.2
Sequestro de Contas
Subseção 2.5.3.3

1. SAML
2. XML Signature

Interfaces Inseguras
Subseção 2.5.3.4
Negação de Serviço
Subseção 2.5.3.5

Fonte: próprio autor.

76

5. AVALIAÇÃO DA PROPOSTA

5.1.3

Coleta de Dados

A coleta de dados foi realizada com base nas questões e métricas definidas na seção
Descrição. As métricas foram obtidas por meio da execução de Teste Funcionais que tem como
objetivo demonstrar a operacionalidade das funções que foram especificadas. Na Engenharia de
Software, o Teste Funcional é realizado olhando-se o software apenas através de suas interfaces.
Como o objetivo é a mitigação das ameaças, discutidas nas partes anteriores, dos serviços
providos, portanto o método de avaliação será baseado em testes funcionais, também conhecidos
como caixa preta.
Os participantes dessa avaliação foram as ferramentas soapUI e Wireshark, que executaram as métricas para avaliar o comportamentos dos mecanismos de segurança usados como
padrão nos WS. Cada tecnologia foi avaliada a partir dos cenários definidos, também foram
avaliadas a combinação das tecnologias de segurança aplicadas nos estudos de caso.
Utilizou-se a ferramenta Apache eXtensible Interaction System 2 (Axis 2) para implementar o protótipo, com necessidade de um mecanismo de processamento SOAP para analisar
sintaticamente as mensagens recebidas e para chamar os métodos que a mensagem indica.
O Axis 2 é um projeto open source da Apache Software Foundation1 e está atualmente
na versão 1.7.0. O Axis 2 trata-se de um projeto desenvolvido pela Apache para proporcionar
muitos recursos não presentes na implementação atual do SOAP Apache. Axis 2 fornece as
ferramentas necessárias para trabalharmos com os Web Services de forma fácil e simplificada.
Utilizou-se, também, o módulo Rampart2 do Apache Axis2 na versão 2.1.4 para fornecer as
implementações de segurança para o mecanismo de serviços da Web do Axis2 referente as
especificações propostas.
A arquitetura do Apache Axis 2 é construída sobre o alicerce de um mecanismo SOAP.
No diagrama exibido na Figura 5.3, ilustra a sequência numerada das etapas para a consumação
de serviços 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 necessários ao processamento de uma requisição
1 http://www.apache.org/,

Último Acesso em Novembro de 2015
Último Acesso em Novembro de 2015

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) constrói uma requisição do SOAP
usando a classe LogonServiceImplStub.java, especificamente a URI de destino, os
detalhes do serviço (como o nome do serviço, o nome do método e parâmetros 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 específico quanto ao protocolo e as políticas de
seguranças 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 também carrega várias
propriedades como atributos do SOAP (cabeçalho SOAP) e define a propriedade
transportName no MessageContext. Desta forma, a mensagem SOAP é enviada ao
dispatcher.
Passo 3 – O dispatcher é responsável pelo caminhamento da requisição ao WS de
destino.
Passo 4 – WS (AccessControl.wsdl) executa o método 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 através 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 requisição e o destino da resposta/falha da
mensagem, os detalhes da sessão e etc.

A arquitetura do Axis 2 pode ser facilmente integrada à qualquer aplicação web, independente do container. Nas próximos Seções, será detalhada a arquitetura do Apache Axis2.
O container Apache TomCat foi utilizado como servidor web do protótipo. O WS e o
cliente do protótipo foram implementados através das ferramentas Axis 2 e IDE Eclipse3 Mars
4.5 utilizando linguagem de programação Java. As políticas de segurança do protótipo foram
implementadas conforme as especificações desejadas e de forma autônoma usando a biblioteca
Apache Commons Policy 1.0.
A criação de um cliente teve como objetivo realizar as chamadas dos serviços e aplicar
os mecanismos de segurança: WSS, WSP e SAML. Foram criadas definições de políticas 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 políticas de segurança. A política definida
3 http://www.eclipse.org/,

Último Acesso em Novembro de 2015

78

5. AVALIAÇÃO DA PROPOSTA

teve finalidade de expressar os requisitos de segurança de forma declarativa, importando como o
serviço pode ser invocado com segurança no transporte ou com segurança na mensagem.
A configuração dessas políticas de segurança teve por objetivo a segurança em nível
de transmissão de dados ou da mensagem, objetivando atender os requisitos de identificação,
autenticação, integridade, privacidade e não-repúdio.

5.1.4

Análise dos Resultados

Com base na Tabela 5.3, foram submetidos três 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 interpretação e qualificação das escalas.
Observou-se que em alguns casos a escala foi definido um nível de qualificação como
"Satisfatório", outro se estendem até o "Excelente". Os casos como ausência definição do nível
refere-se aos ambientes de teste que, devido à falta de cenários prontos e o tempo e esforço para
desenvolvê-los, não contemplam todos os aspectos de ameaças descritos no estudo.
Em contrapartida, esses estudos de caso abrangem os comportamentos mais elementares
levantados nesta pesquisa.
Além disso, todos os aspectos pertinentes às ameaças em CN estão de acordo com os
estudos de casos proposto. Outro fato relevante é que os falso positivos não foram considerados
nestes testes, uma vez que o estudo atribui o fator humano responsável pela correções dos erros
da análise. Sendo assim os estudos de caso apresentados foram definidos como ameaças reais
aos serviços providos. Nesta seção serão descritas as considerações do estudo realizando com
base nos resultados extraídos para as questões citadas na Tabela 5.3.
Resultado da Questão 01
O gráfico da Figura 5.4 apresenta a execução dos mecanismos de segurança utilizados
no Estudo de Caso 01 das especificações WSS e W SP. Sua validação serviu com base para
identificação do problema de aumento do tempo de resposta durante a sobrecarga do sistema
diante da injeção de ataques, como negação de serviço e XML Injection. Assim, a ferramente
SoapUI facilitou todo o processo de criação e depuração dos testes por meio de sua interface
gráfica.
Durante a execução dos testes é medido o tempo de resposta em milissegundos de
requisições com tokens válidos e com tokens inválidos. Assim, o tempo médio de resposta, para
uma requisição de geração e validação de token válido, é aproximado de 550 milissegundos. Em
contrapartida, o tempo médio de resposta, para uma requisição de geração e validação de token
inválido, é aproximadamente de 810 milissegundos.
Conforme observado no gráfico d a F igura 5 .4, a d iferença d o t empo d e r esposta é
aproximadamente 45% mais rápido que o mesmo cenário sem a solução. Essa performance é

5.1. METODOLOGIA

79

devido ao uso de credenciais de segurança, mais conhecida como Security Tokens, que comprova
a identidade do emissor e permite acesso aos serviços do provedor, sempre e quando o provedor
realiza a validação do passwordDisgest. Por outro lado, a solução sem segurança não realiza
a validação das credenciais de acesso e faz com que o servidor retorne o status de requisição
"HTTP 400 – Bad Request" ou "HTTP 500 – Internal Server Error" descrevendo um erro de
sintaxes na resposta.
Figura 5.4: Análise do aumento do tempo de resposta

Fonte: própio autor.

Além disso, a arquitetura proposta proveu segurança fim-a-fim para aplicações que
necessitam realizar trocas de dados de forma segura, e em conjunto, a especialização WSSecurityPolicy possibilitou a declaração o uso do protocolo HTTPS para conexões seguras. E
por fim, a criação de uma cadeia aleatória (nonce), permitindo rejeitar as mensagens SOAP
manipuladas com intuito de sobrecarregar o sistema. A aplicação manteve um tempo de resposta
para os clientes abaixo de 400 milissegundos.

80

5. AVALIAÇÃO DA PROPOSTA
Figura 5.5: Resultados da avaliação da Questão 01

Fonte: própio autor.

Resultado da Questão 02
Seguindo a análise das especializações 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 especialização XML Digital Signature garantiu os atributos de autenticidade, integridade e permitiu suporte para não repúdio aos dados assinados. Uma característica fundamental
da XML Digital Signature, permitida no experimento, é a capacidade de assinar apenas partes
específicas da mensagem SOAP, essa flexibilidade é importante para garantir o atributo de
integridade dessas partes. Outra característica para garantir integridade, desta especialização,
é a troca de mensagens assinadas, permitindo a validação do documento a partir da assinatura
incluída na mensagem conforme demonstrado neste estudo de caso.
Desta forma, os atributos de autenticidade, integridade e não repúdio receberam a classificação de "Excelente", devido as regras de processamento de assinatura digital. A propriedade
não repúdio foi assegurada pela utilização da criptografia assimétrica.
Por sua vez, o padrão XML Encryption demonstrou a capacidade de codificar o conteúdo
do corpo da mensagem SOAP, fornecendo qualidade de proteção através de integridade, confidencialidade e autenticação única de mensagens. Por esse motivo, a propriedade confidencialidade
recebeu a escala quatro de "Satisfatório".
E por fim, as afirmações declaradas da especialização WS-Policy permitiram definir
como os serviços disponibilizados estão autorizados a interagir com outros usuários e serviços.
Portanto, o atributo disponibilidade obteve o grau quatro, "Satisfatório", na escala.

5.1. METODOLOGIA

81
Figura 5.6: Resultados da avaliação da Questão 02

Fonte: própio autor.

Resultado da Questão 03
Uma das principais dificuldades de realizar esse cenário de teste se concentrou na tarefa
de estabelecer a relação de confiança entre o provedor de identidade, pelo protocolo LDAP,
e o provedor de recursos utilizando SAML. Contribuíram para essa dificuldade a falta de
experiência com esse protocolo e sua complexidade. Uma vez superada essa etapa, foi necessário
a configuração do servidor AD apropriado, estabelecendo a relação de confiança entre o provedor
de identidade e o provedor de recursos proposto pelo padrão 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 preservação dos atributos de integridade, autenticidade e autorização. O experimento
analisado no estudo de caso 03, permitiu analisar a criação da solução SSO, a qual estabeleceu
um círculo de confiança através do intercâmbio das mensagens SOAP entre as entidades IdP
e SP. A SAML também permitiu melhorar a produtividade na redefinição das credenciais de
segurança para uma mesma identidade, garantido assim a propriedade de disponibilidade. A
utilização dessa abordagem se faz comum em ambiente de nível INTRANET.
O padrão WS-Security permitiu a declaração de um token de segurança, auxiliando a
especialização no suporte à autenticação com proteção de integridade em nível de mensagem.

82

5. AVALIAÇÃO DA PROPOSTA
Figura 5.7: Resultados da avaliação da Questão 03

Fonte: própio autor.

5.2

Limitações da Avaliação

Devido às restrições de ferramentas, não foi possível desenvolver um ambiente controlado
capaz de avaliar todas as variações de ameaças possíveis acerca dos dados do usuário, os quais
foram apresentados por este estudo, oferecendo assim um número ainda maior de métricas a
serem submetidas nas questões de avaliação. Este crescimento na diversidade das métricas
poderia proporcionar uma análise mais quantitativa, o que em tese garantiria uma maior precisão
quanto aos resultados obtidos nos testes. Além disso, não foi possível realizar uma análise
comparativa em relação aos mecanismos de segurança devido as limitações disponíveis no
âmbito das ferramentas apresentadas.
Outra limitação 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 insatisfatório, fazendo com que o tempo de
requisição e resposta sejam maior que 5 segundos, comprometendo a solução de validação do
tempo de expiração da mensagem SOAP.
A próxima Parte irá abordar sobre os mecanismos de segurança estudados, bem como
apontar melhorarias e trabalhos futuros.

83

6
Considerações Finais
Os Web Services firmaram-se no cenário de comunicação em ambientes de nuvem como
forma de integração entre organizações, aplicações e processos de negócio. O advento do Web
Services quebrou alguns paradigmas de segurança. Existe agora a possibilidade de garantir
segurança dentro do próprio, tal façanha é possível com o uso de padrão SOAP e como protocolo
de transporte HTTP.
As tecnologias estudadas e analisadas ofereceram a proteção de mensagens: como
proteger o conteúdo das mensagens e dos serviços, garantindo a proteção necessária para
confidencialidade, integridade, disponibilidade, não-repúdio e autenticidade.
No estudo de caso, foi usado a ferramenta Apache Axis 2, que implementou a arquitetura
do protótipo e facilitou o uso dos principais padrões de seguranças abordados ao longo deste
trabalho. O protótipo desenvolvido possibilitou demonstrar a aplicação prática do padrão WSSecurity, WS-Police e SAML. Permitiu, ainda, a realização de uma análise, através da execução
e observação das mensagens trocadas entre o WS e o cliente, ambos implementados no estudo
de caso deste trabalho.
Mesmo existentes soluções de mercado e soluções comerciais, devido à natureza do
negócio e estratégica como das forças armadas, essas soluções podem vir a não atender todas as
necessidades exigidas e demandariam customizações que, na sua grande maioria, não seriam
atendidas pelos grandes empresas como VMware, IBM e HP, já que que suas soluções são
padronizadas Damasceno (2015).
As especificações de segurança para o ambiente dos Web Services estão alcançando
maturidade notável. Permitindo a possibilidade de oferecer ao mercado e aos clientes o fator
fundamental da arquitetura de segurança para Web Services. Para oferecer novas aplicações de
Web Services ao mercado e aumentar a segurança de suas atuais aplicações de Web Services
é necessário o uso das recomendações das normas de implementações e a padronização do
gerenciamento de políticas, sendo estas uma infraestrutura confiável no ambiente em nuvem
privada segura.

84

6.1

6. CONSIDERAÇÕES FINAIS

Contribuições

A principal contribuição deste trabalho foi a definição e especificação de uma arquitetura
de software de referência para implementação de ambientes de nuvem em uma organização
militar, respeitando a legislação corrente às recomendações para o uso de computação em nuvem
privada pelo governo federal.
Outra contribuição, não menos importante, foi a vantagem do padrão WS-Security
suportar a vários tipos de protocolos e tokens. Entretanto, ele não oferece informações de como
deixar esses protocolos seguros.
A ferramenta Axis 2 suportou asserções SAML no caso de uso realizado, mas o módulo
de segurança ainda está muito instável. A documentação é pouca e, em geral, de má qualidade.
Desta forma, fica uma sugestão para trabalhos futuros.
Nenhuma ferramenta atualmente disponível no mercado permite realizar negociação de
políticas de forma integrada. No protótipo, a negociação de políticas foi efetuada para exemplos
simples e de forma autônoma.
A política descrita no caso de uso é muito importante, pois possibilita a configuração
de segurança utilizada. Desta forma, aumenta o conteúdo da mensagem consideradamente,
tornando-a complexa.
Os Web Services seguem no bom caminho, no que respeita a segurança, os mecanismos
analisados suportaram o cenário mais comum na solução dos problemas como identificação,
autenticação, integridade, privacidade, não-repúdio e evolução das políticas de segurança nas
mensagens.

6.2

Trabalhos Futuros

Como sugestão para trabalhos futuros, um tema não abordado neste trabalho, mas que,
sem dúvida, é importante ao ponto de ser fonte de inspiração para os mecanismos de segurança
expostos nesta pesquisa, é a necessidade de estudar os ataques e vulnerabilidades através das
falhas em aplicações, tratando dos padrões de segurança 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 comunicação segura, similar apresentado por Kumari e Rath (2015) em
seu artigo. Além disso, também poderia ser explorado um arquitetura segura que abrangessem
os modelos de serviços como Platform as a Service (PaaS) e Infrastructure as a Service (IaaS).

85

Referências
ABDELRAZIK, A. et al. Adding Speed and Agility to Virtualized Infrastructure with
OpenStack, 2015. Disponível em: <https://goo.gl/InIokG>. Acesso em: 8 dez. 2015.
APACHE. Apache Axis2 Architecture Guide, 2015. Disponível 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.

Disponível em: <https://goo.gl/DCOQM>. Acesso em: 15 fev. 2015.

CSA. The Notoriuous Nine Cloud Computing Top Threats in 2013, 2013. Disponível 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. Disponível em: <https://goo.gl/CvUiYk>. Acesso em: 15 nov. 2015.
DAMASCENO, J. C. UCloud: Uma Abordagem para Implantação de Nuvem Privada
para a Administração Pública Federal. 2015. Tese (Doutorado em Ciência da
Computação) — Universidade Federal de Pernambuco, Centro de Informática, Recife. 2015.

171p.

EPING. Padrões de Interoperabilidade de Governo Eletrônico, 2016. Disponível em:

<http://goo.gl/8jNLGV>. Acesso em: 15 jan. 2016.

FERREIRA, A. S. Uma arquitetura para monitoramento de segurança baseada em
acordos de níveis de serviço para nuvens de infraestrutura. 2013. Dissertação
(Mestrado em Ciência da Computação) — Universidade Estadual de Campinas, Campinas.

2013.

86

REFERÊNCIAS

FIXYA. Cloud Storage Report, 2012. Disponível 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 solução de gerenciamento de credenciais
para autenticação e autorização em ambientes de computação em nuvem.
2014. Dissertação (Mestrado em Ciência da Computação) — Escola Politécnica da
Universidade de São Paulo, São 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.138–146.
IBM. Idéias de computação em nuvem experiência em 110 projetos de implementação.
International business machines. Nova Iorque: Pesquisa da Academia de Tecnologia da IBM.

2010. 7p.

ISO/IEC. ISO/IEC 27002:2013 tecnologia da informação técnicas de segurança – código
de prática para controles de segurança da informação, 2013. Disponível 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.42–50.
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.1656–1660.
M. Web services: security challenges. In: INTERNET
(WORLDCIS), 2011, Lodon. Anais... Lodon: IEEE Press, 2011. p.160–163.

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
segurança para mecanismos de controle de acesso baseados em serviços web. In: X
SIMPÓSIO BRASILEIRO DE SEGURANÇA DE COMPUTADORES E SISTEMAS
COMPUTACIONAIS (SBSEG), 2010, Porto Alegre. Anais... Porto Alegre: SBC,
2010. v. 1, p.1–14.
MELL, P., GRANCE, T. SP 800-145. The NIST Definition of Cloud Computing. [S.l.]:
National Institute of Standards and Technology, Gaithersburg, 2011.

REFERÊNCIAS

87

MELLO, E.; WANGHAM, M.; FRAGA, J.; CAMARGO, E. Segurança em serviços web.
In: VI SIMPÓSIO BRASILEIRO DE SEGURANÇA DA INFORMAÇÃO E DE
SISTEMAS COMPUTACIONAIS (SBSEG), 2006, Porto Alegre. Anais... Porto Alegre:
Sociedade Brasileira de Computação, 2006. p. 1–48.
MICHELIN, R. A. Mitigação de Ataques de Negação de Serviço em Rests
Autenticáveis na Nuvem. 2015. Dissertação (Mestrado em Ciência da
Computação) — Universidade Católica 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. Disponível em: <http://goo.gl/RFPylm>. Acesso em: 7 fev. 2014.
OASIS. Security Assertion Markup Language (SAML) V2.0 Technical Overview,

2008. Disponível em: <https://goo.gl/usJ0W>. Acesso em: 21 nov. 2014.

OASIS. Web Services Security: soap message security version 1.1.1, 2012. Disponível

em: <http://goo.gl/e4zFFJ>. Acesso em: 14 fev. 2015.

OASIS. Web Services Security Username Token Profile Version 1.1.1, 2012.

Disponível em: <http://goo.gl/X4YDzH>. Acesso em: 25 nov. 2014.
OASIS.

WS-SecurityPolicy

Acesso em: 25 nov. 2015.

1.3,

2012.

Disponível

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 Segurança para Análise de Robustez de Web
Services pela Injeção de Ataques. 2012. Dissertação (Mestrado em Ciência da
Computação) —Universidade Estadual de Campinas, Campinas. 2012.
SILVA, J. L. C. da. Adoção de Computação em Nuvem Privada em uma Empresa de
Processamento de Dados Estadual: os impactos de implantação em seu ambiente corporativo.
2013. Dissertação (Mestrado em Ciência da Computação) — Centro de
Informática da Universidade Federal de Pernambuco, Recife. 2013.
SINGH, S. O livro dos códigos. 8th ed. Rio de Janeiro: Editora Record, 2010. 13 p.
VIEIRA, M. State-of-the-art and Research Opportunities, 2010. Disponível em:

<http://goo.gl/7BOK5a>. Acesso em: 22 fev. 2014.

VMWARE, I. VMware ESX e VMware ESXi: os hypervisores líderes do mercado com
produção comprovada, 2009. Disponível em: <https://goo.gl/yRxjNq>. Acesso em: 5 out.

2015.

W3C. Web Services Architecture - W3C Working Group, 2004. Disponível em:

<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/>. Acesso em: 15 nov. 2014.

88

REFERÊNCIAS

W3C. XML Key Management Specification (XKMS 2.0), 2005. Disponível 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. Disponível em: <http://www.w3.org/TR/wsdl20/>. Acesso em: 20
nov. 2013.
W3C. Web Services Policy 1.5 - Framework, 2007. Disponível em: <https://
www.w3.org/TR/ws-policy/>. Acesso em: 12 nov. 2015.
W3C. SOAP Version 1.2 Part 2 Adjuncts (Second Edition), 2007. Disponível em:
<https://www.w3.org/TR/soap12-part2/>. Acesso em: 17 jul. 2014.
W3C. XML-Signature Syntax and Processing (Second Edition), 2008. Disponível em:

<http://www.w3.org/TR/xmldsig-core>. Acesso em: 10 fev. 2014.

W3C. XML Encryption Syntax and Processing Version 1.1, 2013. Disponível 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. 365–379.
WINCKLER, G. A. von. Proposta de arquitetura para federações de nuvens
computacionais acadêmicas. 2014. Dissertação (Mestrado em Ciência da
Computação) — Instituto de Matemática e Estatística da Universidade de São Paulo, São
Paulo. 2014.
ZORZ, Z. Researchers detail attacks for compromising dropbox user accounts,

2013. Disponível em: <https://goo.gl/avg4uQ>. Acesso em: 14 ago. 2014.

Apêndice

91

A
Certificado Digital
O intuito deste apêndice é apresentar um breve roteiro sobre a utilização da ferramenta,
de gerenciamento de chaves e certificados, Keytool. Para configurar o Apache Tomcat para se
comunicar através de uma conexão segura, deverá seguir os seguintes passos abaixo:
1. Criar o keystore do certificado que contém um certificado assinado pessoalmente,
com validade de 365 dias, que é gerado por você, e não 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 Domínio. Ex.: localhost

[ou]

Cargo. Ex.: Chefe da TIAd

[o]

Organização. Ex.: FAB

[l]

Cidade. Ex.: Recife

[S]

Estado. Ex.: PE

[c]

País. Ex.: BR

Os campos <senha_keystore> e <senha_storepass> devem conter as mesmas valor
das senhas. Caso não 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

APÊNDICE A. CERTIFICADO DIGITAL
A opção de -certreq cria um arquivo CSR que você pode submeter uma Autoridade
Certificadora (CA). A senha solicitada na execução 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 conteúdo do arquivo no formulário
encontrado e siga as instruções. 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, também conhecido como Root Certificate (Certificado Raiz).
E receberá por e-mail o conteúdo do certificado intermediário. Copie o conteúdo
completo desde —–BEGIN NEW CERTIFICATE REQUEST—– até —–END NEW
CERTIFICATE REQUEST—– e crie um arquivo com extensão CER colando o
conteúdo 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_intermediário>
Sempre começar pelo Certificado Raiz, e depois ir seguindo a sequencia. Os certificados deverão ser importados para o arquivo keystore gerado no comando do passo 1.
A senha solicitada na execução 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 diretório raiz do Tomcat, você tem essa
configuração 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 deverão 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 versão 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 endereço que foi informado no passo 1 ou caso foi
informado localhost acesse https://localhost:8443/.