ricardo marinho de melo · web services baseados em nuvem privada / ricardo marinho de melo. –...

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 [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2016

www.cin.ufpe.br/~posgraduacao


UMA ARQUITETURA DE REFERÊNCIA GUIADA ACONFORMIDADES DE SEGURANÇA PARA WEB SERVICES

BASEADOS EM NUVEM PRIVADA

Trabalho apresentado ao Programa de do da Universi-

dade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Vinicius Cardoso Garcia

RECIFE2016

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


Uma Arquitetura de Referência Guiada à Conformidades de Segurançapara Web Services Baseados em Nuvem Privada

Dissertação de Mestrado apresentada ao programade Pós-Graduação em Ciência da Computação daUniversidade Federal de Pernambuco, com requi-sito parcial para a obtenção do título de Mestre emCiê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 formapossível meu caminho.

À Rafaela Arcoverde, pelo dedicação, paciência, compreensão em minhas ausências pararealização deste trabalho.

Agradeço a todos os professores que, de alguma forma, contribuíram para a concretizaçãoda minha pós-graduação.

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

Agradeço também ao Carlo Marcelo pelas ideias trocadas, ajuda e motivação que foramfundamentais.

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 todasdificuldades enfrentadas ao longo de minha formação. Sou muito grato por ter conseguido chegaraté 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 quecomprometem a confidencialidade, integridade e disponibilidade dos serviços prestados. Nestecontexto, as organizações militares buscam modelos de nuvens privadas alinhadas com suaspreocupações envolvendo segurança, conformidade e políticas. Atualmente, a segurança é omaior 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 eimplementações de segurança para Web Services, definir uma arquitetura segura para mitigaras 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 segu-

rança neste ambiente, foram utilizadas referências da área de pesquisa relacionadas ao problemaidentificado. Especificou-se uma arquitetura segura como hipótese de solução, e posterior-mente avaliou-se tal hipótese por meio da implementação de um protótipo, evidenciando-se aimportância desta solução.

Resultados: Como resultado obteve-se uma arquitetura de referência para minimizar osriscos de segurança na implantação de nuvens privadas nas organizações militares. Experimentosde campo contemplaram aquisições a respeito dos mecanismos de segurança aplicados, em parti-cular os padrões WS-Policy, WS-Security e SAML, os quais conseguiram oferecer mecanismospadrão de segurança necessários para realizar o intercâmbio seguro de mensagens certificadasem 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 threatsthat compromise confidentiality, integrity and availability of the services offered. In this light,military organizations search for private cloud models that comply with their concerns aboutsecurity, conformity and policies. Nowadays, security is the greatest obstacle for the widespreadadoption of cloud computing.

Objective: In this scenario, the work presented here aims, based on the analysis of thecurrent security rules and implementations for Web Services, to define a secure architecture tomitigate 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, asecure architecture was specified as a solution hypothesis. Such hypothesis was then evaluatedthrough the implementation of a prototype, which has helped us to highlight the importance ofsuch solution.

Results: The main result of this work was a reference architecture that can be used tominimize the security threats in the deployment of private clouds in military organizations. Fieldexperiments have taken into account inputs from the security mechanism patterns used, namely:WS-Policy, WS-Security e SAML. Such patterns offered the security levels needed for the secureexchange of certified messages in cloud environments.

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

Lista de Ilustrações

2.1 Relações entre entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Arquitetura de normas de Web Services (WS) proposta pelo W3C . . . . . . . . 232.3 Estrutura de uma mensagem SOAP . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Estrutura de um documento WSDL . . . . . . . . . . . . . . . . . . . . . . . . 262.5 Formas de assinatura XML Digital Signature . . . . . . . . . . . . . . . . . . 302.6 Relacionamento de Web Services, SOA e Computação em Nuvem . . . . . . . 39

4.1 Interação das Visões do Modelo 4+1 . . . . . . . . . . . . . . . . . . . . . . . 494.2 Visão lógica da Arquitetura de Referência proposta . . . . . . . . . . . . . . . 504.3 Diagrama de Dependências . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4 Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.5 Exemplo de pacote HTTP capturado pelo Wireshark . . . . . . . . . . . . . . . 574.6 Diagrama de Sequência Estudo de Caso 03 . . . . . . . . . . . . . . . . . . . 66

5.1 Fases da metodologia GQM . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2 Estrutura da Fase de Definição . . . . . . . . . . . . . . . . . . . . . . . . . . 745.3 Workflow do ciclo de vida do Apache Axis 2 . . . . . . . . . . . . . . . . . . . 765.4 Análise do aumento do tempo de resposta . . . . . . . . . . . . . . . . . . . . 795.5 Resultados da avaliação da Questão 01 . . . . . . . . . . . . . . . . . . . . . . 805.6 Resultados da avaliação da Questão 02 . . . . . . . . . . . . . . . . . . . . . . 815.7 Resultados da avaliação da Questão 03 . . . . . . . . . . . . . . . . . . . . . . 82

Lista de Tabelas

3.1 Comparativo entre as soluções dos trabalhos relacionados para mitigação dasameaças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Propriedades de segurança afetadas por ameaças . . . . . . . . . . . . . . . . . 735.2 Ataques utilizados para cada ameaça . . . . . . . . . . . . . . . . . . . . . . . 735.3 Definição das Questões e Métricas para avaliação . . . . . . . . . . . . . . . . 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 Introdução 151.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

2 Referencial Teórico 212.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

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

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

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

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

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

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

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

2.4.1 Políticas para Web Services . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.2 Web Services SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . . 37

2.5 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

2.6 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Trabalhos Relacionados 453.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Implementação da Proposta 494.1 Metodologia 4+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.1 Módulo de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.2 Módulo de Mecanismos de Segurança . . . . . . . . . . . . . . . . . . 514.2.3 Módulo de Políticas de Segurança . . . . . . . . . . . . . . . . . . . . 524.2.4 Módulo de Gerenciamento de Acesso e Identidade . . . . . . . . . . . 52

4.3 Visão Dependência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4 Visão Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.5 Visão Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.6.1 Desenvolvimento da Aplicação . . . . . . . . . . . . . . . . . . . . . . 564.6.2 Experimento de Campo . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.6.2.1 Estudo de Caso 01 . . . . . . . . . . . . . . . . . . . . . . . 574.6.2.2 Estudo de Caso 02 . . . . . . . . . . . . . . . . . . . . . . . 604.6.2.3 Estudo de Caso 03 . . . . . . . . . . . . . . . . . . . . . . . 65

4.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5 Avaliação da Proposta 715.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.1.1 Publico alvo e cenário de atuação . . . . . . . . . . . . . . . 725.1.1.2 Critério de Avaliação . . . . . . . . . . . . . . . . . . . . . 72

5.1.2 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.1.3 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.1.4 Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2 Limitações da Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Considerações Finais 836.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Referências 85

Apêndice 89

A Certificado Digital 91

151515

1Introdução

O advento da Computação em Nuvem (CN), ou do inglês cloud computing, oferecevantagens em investimentos operacionais por meio de custos sobre demanda, provido de umambiente 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 umnúmero crescente de provedores em nuvem.

Em contrapartida, esses modelos de serviço utilizados em ambiente da CN apresentamdiferentes níveis de riscos se comparados ao ambiente tradicional (CSA, 2011). Segundo orelató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, perdade dados, sequestro de contas ou de tráfego de serviços, interfaces inseguras, negação deserviços, usuário mal intencionado, abuso de serviços da nuvem, investigação insuficiente evulnerabilidades de recursos compartilhados (CSA, 2013).

A crescente insatisfação com a segurança em serviços de processamento, transferência earmazenamento de dados em nuvens é resultado de uma combinação de diversos fatores, dentreos 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 emindisponibilidades de serviços, vazamento e perda de dados; a falta de conhecimento dos riscosexistentes em ambientes de nuvem. Segundo a CSA (2011), a segurança é uma forte barreiracontra a ampla adoção da computação em nuvem.

Esses problemas de segurança são complexos, pois não envolvem apenas questões arqui-teturais e tecnológicas, mas também mudanças de processos, em função dos novos modelos decomputaçã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 con-junto de padrões de interoperabilidade e segurança dos Web Services (WS). Empresas comoInternational Business Machines (IBM) e Amazon Web Services (AWS), líderes do setor deseguranç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 peculiaressistemas computacionais, os quais, quando desenvolvidos não visavam interoperabilidade, porexemplo, com os sistemas computacionais de seus clientes (POTTS, 2003). A partir dessanecessidade de interação entre diferentes aplicações, surge uma nova caracterização de sistemasdistribuí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 delinguagens 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, quecumprem 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 baixocusto (POTTS, 2003). Contudo, a segurança dos serviços e a transição de dados tornaram-sealvo de estudo porque no universo de WS, que vai além da transmissão de dados, segurançasignifica mais do que inviolabilidade de informação. A segurança, nesse contexto, caracteriza-sepor 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 indispen-sá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 porobjetivo estudar os mecanismos de segurança, WSS, SAML e WSP, utilizados como padrão nosWS, definindo, analisando, caracterizando e demonstrando sua aplicabilidade, através de umestudo de caso.

1.1 Motivação

O crescimento e a complexidade da infraestrutura da Internet e redes corporativas fizeramcom 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 emseus data centers1 ou customizá-los, migrando de um modelo tradicional de computação, emque a prestação de serviços é realizada em máquinas reais, não havendo otimização de recursoscomputacionais (SILVA, 2013). Estas empresas podem utilizar como alternativa o modelo decomputação em nuvem, na qual se utiliza a técnica de virtualização para instanciar máquinasvirtuais e aplicações, oferecendo custo reduzido, eficiência e escalabilidade dentro das fronteiras

1Um centro de processamento de dados (CPD) é o local onde são concentrados os equipamentos de processa-mento 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 consideraro nível de segurança que regulamentam a utilização da TIC na interoperabilidade de serviçosde governo eletrônico (EPING, 2016). Essas recomendações do Padrões de Interoperabilidadede 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 demaisPoderes 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çãode negócio para as empresas que planejam utilizar a CN como meio de compartilhamento deinformações. A segurança é um elemento indispensável para a construção e desenvolvimentode um ambiente de nuvem confiável. No entanto, garantir a segurança dos WS representa umdesafio devido às limitações dos padrões e à necessidade de dar suporte a uma consideráveldemanda de serviços (POTTS, 2003).

1.2 Estabelecimento do Problema

Motivado pelas questões apresentadas na Seção anterior, o principal objetivo destetrabalho é, em linhas gerais:

Especificar, projetar e implementar uma arquitetura de software para WS atendendo aospadrões e políticas contidos na ePING e que permita o desenvolvimento de soluções de aplicaçõesque usam esses serviços com base nos mecanismos utilizados como padrão de segurança nosserviços Web: WSS, SAML e WSP. Além disso, este trabalho visa prover uma implementaçãode referência desta arquitetura de software.

1.3 Justificativa

O presente trabalho justifica-se, primeiramente, pela necessidade de normas de segurançapara especificação de mecanismos de proteção para que os Web Services possam contemplaros valores necessários à garantia da segurança na sua utilização. Para isso, já existem padrõespromissores para segurança: WSS (OASIS, 2012a), o qual oferece mecanismos padrões desegurança necessários para realizar o intercâmbio seguro de mensagens certificadas em ambientesde nuvem, através de assinaturas digitais e criptografia; WSP (W3C, 2007b), que provê ummodelo 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 deseguranç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 decampo com desenvolvimento de um protótipo para análise da tecnologia de serviços segurospelas 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áliseaprofundada 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çãoem nuvem privada, este trabalho propõe especificar, projetar e implementar uma arquitetura desoftware guiada por conformidades de segurança para WS em um ambiente de computação emnuvem privada em uma organização militar. Para isto, serão implementados experimentos decampo 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 deTecnologia da Informação (TI) e garantir conformidades de segurança com as boas práticas deseguranç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, conformeidentificado 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 riscodas 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 emní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 decampo com desenvolvimento de um protótipo para análise da tecnologia de serviçosseguros 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 estetrabalho, uma visão geral da solução proposta. Os objetivos e contribuições deste trabalhotambém foram apresentados. A presente dissertação está organizada de acordo com a seguinteestrutura:

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

1.5. ESTRUTURA DA DISSERTAÇÃO 19

� Parte 3: cita os trabalhos relacionados ou que têm pontos em comum com estadissertação.

� Parte 4: define as características básicas da arquitetura proposta e descreve as espe-cificações do ambiente de implantação, além de apresentar as implementações dosexperimentos 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 naimplementação dos experimentos de campo executados, relatando resultados no queconcerne à garantia dos atributos de segurança.

� Parte 6: apresenta as considerações finais da dissertação e os trabalhos futuros.

212121

2Referencial Teórico

Através de cinco Seções esta parte tem como objetivo explanar os conceitos e estudosutilizados como base para a presente pesquisa. Na primeira seção são apresentados os conceitosdos 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 sistemasde autenticação e de autorização. A quarta seção aborda a estrutura do WSP para apoiar naconfecção das políticas de segurança. A quinta e última, aborda os conceitos e os principaisbenefícios e ameaças da CN.

2.1 Web Services

WS são aplicações de software que possuem interfaces bem definidas e descritas emXML, classificadas como um tipo específico de serviço. Esses serviços são identificados atravésde 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 é oque os tornam diferentes de sites Web comuns (W3C, 2004).

O grande entusiasmo em torno dos WS é baseado na promessa de interoperabilidadeentre aplicações. As interações com outras aplicações são realizadas pela troca de mensagensXML em um formato Simple Object Access Protocol (SOAP) específico, utilizando padrõesda Internet. Os WS não são a primeira tecnologia a nos permitir isto, mas são diferentes dastecnologias 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, oferecendoflexibilidade e interoperabilidade sobre outras tecnologias. Entre essas vantagens, encontra-se aintegração própria para business-to-business (B2B). No entanto, essas aplicações precisam dealgum 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.

� O Provedor de serviços: é responsável por duas atividades: a primeira é publicaras interfaces dos serviços providos e a segunda é atender as requisições originadaspelos clientes.

� O cliente: após a consulta no diretório para registro de serviços e se o serviço foiencontrado, 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 informarao cliente a descrição dos serviços e a localização das interfaces dos mesmos. Asentidades interagem através de três operações fundamentais: publicar, localizar,invocar. Inicialmente, o provedor de serviços publica as interfaces no diretório pararegistro de serviços, onde ficarão registrados os serviços. Após a publicação, o clientepoderá fazer uma consulta de um determinado serviço, se esse serviço for localizadono diretório para registro de serviços, o cliente poderá invocar o mesmo ao provedorde serviços toda vez que desejar usá-lo.

2.1.2 Normalização

A normalização da plataforma de WS surge com o principal objetivo de orientar odesenvolvimento de maneira a manter a interoperabilidade. Um documento publicado pela Web

Services Interoperability Organization (WS-I)1, organização responsável pela manutenção danormalização da interoperabilidade, abrange uma série de recomendações a serem adotadas parao desenvolvimento de WS.

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

http://www.ws-i.org

2.1. WEB SERVICES 23

A pilha de protocolos dos WS apresentada na Figura 2.2 abrange normas que suportam ainteração das três entidades mencionadas. Algumas dessas mais importantes normas de WS sãodefinidas 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 pilhabá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 Gene-

ralized Markup Language3 (SGML). Criado em 1996 e formalizado em 1998, se tornou umimportante 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 paratroca entre sistemas de diferentes ambientes. A especificação XML contém um conjunto deregras de sintaxe para descrição de dados que é definida por uso de Schemas, norma do W3C, quecontém regras de validação dos elementos e atributos de um documento XML. Outro componentemuito importante são os namespaces, mantido pela W3C. Os namespaces descrevem uma coleçãode nomes, identificados por uma referência URI, que são usados para definir tipos de elementos eatributos de um documento XML. O uso de namespaces previne que documentos XML diferentestenham elementos como nomes conflitantes. Assim, pode-se atribuir um prefixo ao namespaces.

2https://www.w3.org/, Último Acesso em Novembro de 20153https://www.w3.org/MarkUp/SGML/, Último Acesso em Novembro de 2015

https://www.w3.org/

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


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 evalidadas 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 delinguagem 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 sim-plicidade e coerência para que uma aplicação envie mensagens XML para outra, garantindo aindependência do transporte utilizado.

Uma mensagem SOAP é um documento XML. A Figura 2.3 ilustra a estrutura de umamensagem SOAP e, em seguida, será realizado o estudo dos elementos que constitui sua estrutura:

Figura 2.3: Estrutura de uma mensagem SOAP

Fonte: W3C (2007c) - adaptado.

� Envelope SOAP: a mensagem SOAP fornece um envelope (SOAP Envelope) comoelemento raiz, este envelope é um container4 que protege os dados XML.Tendo comoprincipal objetivo não só proteger os dados mas, além disso, possibilita transmissãoda mensagem SOAP por qualquer protocolo de transporte. O envelope é compostopor duas partes: o cabeçalho (SOAP Header) e o corpo (SOAP Body) da mensagem.

4Área delimitada e protegida destinada para armazenar algo.

2.1. WEB SERVICES 25

� Cabeçalho SOAP (SOAP Header): é um elemento opcional e o primeiro elementofilho do envelope. O cabeçalho da mensagem SOAP contém informações, divididasem blocos, podendo conter zero ou mais blocos de cabeçalhos. Essas informaçõesou diretivas são usadas para gerenciar ou prover segurança, tal como asserções deautorização e autenticação entre outros.

� Corpo SOAP (SOAP Body): é um elemento obrigatório e contém a mensagempropriamente dita chamada carga útil (Payload). O corpo contém os dados denegócio da mensagem ou qualquer tipo de informação XML. No corpo, tambémpode estar contido o elemento Fault, que tem por objetivo transportar informaçõessobre erros que possam vir a ocorrer no processamento dessas informações.

2.1.5 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 fazere como poderá ser chamado, permitindo assim, a interação do serviço.

A WSDL é uma linguagem padrão usada para descrever as funcionalidades de umWS, independente de linguagem e plataforma (W3C, 2007a). Tem como objetivo descrever osserviç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 especificarinterface de serviço. WSDL descrevem um WS em duas fases fundamentais: um abstrato eum concreto (W3C, 2013). A parte abstrata descreve as capacidades do WS, em termo demensagem que este consome e produz. A parte concreta desempenha as mesmas tarefas daInterface Definition Language (IDL) na CORBA5, prover vínculo da interface, definindo umcontrato concreto para vincular fisicamente o cliente ao WS. Os principais elementos XML deum 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 documentoe que serão utilizados entre o servidor e o cliente durante a comunicação. Os tipos dedados são definidos dentro deste elemento para que sejam posteriormente utilizadosno elemento message.

� message: define, de forma abstrata, as mensagens que serão trocadas, contendo osparâmetros de entrada e saída do serviço.

� operation: este elemento representa a interação particular com o serviço, descre-vendo as mensagens de entrada, saída e exceções possíveis e permitidas.

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

http://www.corba.org


Figura 2.4: Estrutura de um documento WSDL

Fonte: W3C (2007a) - adaptado.

� portType: descreve um conjunto abstrato de operações mapeadas para suportar umou 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 trans-portar 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 oelemento binding e o endereço de rede onde o serviço pode ser encontrado, possuindoassim um conjunto de port associados.

2.1.6 Universal Description, Discovery and Integration

O UDDI permite que WS disponíveis na Internet sejam facilmente encontrados, provendouma interface para utilização do cliente. Trata-se de um protocolo para registrar, publicar edescobrir WS num ambiente distribuído (OASIS, 2004).

Os dados e metadados dos WS são registrados e armazenados em diretórios UDDIregistry. 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 decada 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 serconsagrados no registro UDDI:

� Páginas Amarelas: aqui, são incluídos dados gerais como a entidade fornecedoraou 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 permitepesquisar um Web Service com base em dados atrelados à entidade fornecedora doWS. Essas informações são constituídas (i.e. nome de um negócio, descrição donegócio, informação de contato, endereço, fax, ou mesmo incluir identificadores denegócios).

� Páginas Verdes: contém um conjunto de informações técnicas sobre um WS, destaforma o programador ao ter acesso a essas informações poderá desenvolver suaaplicação que utilize ao WS em questão.

2.2 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áriospara 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 decabeçalhos de mensagens SOAP, utilizados para oferecer integridade, confidencialidade e au-tenticidade. Essas especificações atendem esses três requisitos de segurança através do uso daAssinatura XML (XML Signature), da Criptografia XML (XML Encryption) e da Autenticaçãoe Autorização XML (SAML) (OASIS, 2012a).

2.2.1 Arquitetura

A arquitetura do padrão WSS é construída sob a mensagem SOAP, definindo um esquemaXML, que possibilita incluir de forma padronizada as informações relacionadas à cifragem dosdados e assinaturas digitais da mensagem SOAP para construção de WS seguros, fazendo usodas 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:


Conforme descrito nos comentários, a XML, apresentou a estrutura do padrão WSSfazendo uso de algumas especificações de segurança que serão abordadas nos próximos tópicosdesta 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 conterinformações suficientes para permitir que um cliente seja verificado usando o par de chavespública/privada. O uso do padrão XML Digital Signature não está estritamente voltado paraassinar documentos XML. Também, é possível assinar qualquer tipo de documento eletrônicodo tipo de arquivos binário ou textos, desta forma, a assinatura será representada através de umdocumento XML.

Uma característica fundamental da assinatura em documentos XML é a habilidade deassinar somente partes específicas da árvore do documento XML. Dessa forma, permite queoutras partes desse documento sofram modificações sem que isso invalide a parte assinada,permitindo compor assinaturas de modo que diferentes assinaturas sejam aplicadas a diferentespartes do documento. Isso é importante porque algumas mensagens SOAP obtêm informaçõesadicionais no seu ciclo de vida. Esta flexibilidade permite garantir a integridade de certas partesde um documento XML. O conteúdo abaixo apresenta um trecho de documento XML que mostraum exemplo de XML Digital Signature:

6Conjunto de instruções matemáticas baseadas na criptografia, que permite conferir autenticidade, privacidade einviolabilidade aos documentos digitais e transações comerciais efetuadas pela Internet.

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

https://www.oasis-open.org/

https://www.ietf.org/


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çãoassinada e contem o valor da assinatura digital, sempre codificada usando base64. O elemento<SignatureMethod> especifica o algoritmo usado para converter o SignedInfo canonizado noSignatureValue. Esta é uma combinação de um algoritmo que depende da chave e de umalgoritmo 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çade 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 oelemento <p class = ’a’ secure = "1"/> são equivalentes. Porém, ao criar uma assinatura expressaem XML referentes aos elementos citados, aplica-se um algoritmo gerando duas assinaturasdistintas.

Assim, documentos XML, que sejam sintaticamente diferentes, porém com lógicasequivalentes, permitem serem representados por uma mesma forma canônica. Isso é importanteporque, possibilita que os documentos XML possam ser assinados sem que haja preocupaçãocom a sintaxe dos mesmos.

Existem três formas diferentes de representar as assinaturas conforme apresentado naFigura 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çosWeb, inserida em mensagens SOAP;

� enveloping: a assinatura encapsula os dados assinados, ou seja, contido dentro daprópria estrutura da assinatura.

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

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

https://www.w3.org/TR/xml-c14n


Geralmente estes dados encontram-se na Web. É ideal para assinar documentos quesofrem 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 privaci-

dade 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 XML que c ontenha, ou faça r eferência, os 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


torna-se a raiz de um novo documento; elemento XML, o elemento <EncryptedData> substitui oelemento 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 dodocumento XML. O conteúdo abaixo apresenta um exemplo de documento XML sem criptografiados dados:

O documento XML mostrado acima, refere-se a informações de uma conta de um sistemabancário, informando os elementos: Nome, Numero, Limite e Senha do cliente responsável. Oconteú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 elementoNome foram criptografados. As informações extremamente importantes, como os elementosNumero, 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 indivi-

duais. 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 (XMLSignature, XML Encryption), bem como para os padrões que surgirão no futuro (POTTS, 2003).

2.3. SECURITY ASSERTION MARKUP LANGUAGE 33

2.3 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 man-

ter 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 comsucesso do usuário, que afirma que o emissor foi autenticado por um determinadomeio em um determinado momento;

� Atributo: uma afirmação contém detalhes específicos sobre uma declaração feitapelo emissor, que, assim especifica estar associado ao(s) atributo(s) específico(s) paradeterminar o papel que irá desempenhar dentro do sistema;

� Autorização: que indica os direitos que um emissor possui sobe um determinadorecurso em questão, sendo que esta declaração de asserções afirma que a requisiçãode 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 paraautenticação, atributos e autorização respectivamente:

10Conjunto de funcionalidades comuns para um determinado domínio de aplicações.11A 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 eainda, possibilita o uso de mecanismos não definidos na especificação.


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

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

2.3. SECURITY ASSERTION MARKUP LANGUAGE 35

A XML, comentada acima, exemplifica que a asserção de autorização contida no docu-mento que afirma que o cliente [email protected] está autorizado a consultar a páginahttp://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 elementoAuthorizationDecisionStatement informando Deny para negação, Permit para permissão e Inde-

treminate para indeterminação.

Mesmo prevendo o uso de autoridades responsáveis pela emissão dessas asserções, omodelo de uso SAML não as menciona. No entanto, as especificações ditam os protocolos quevisam à interação com essas autoridades (OASIS, 2008).

Portanto, verifica-se que o TLS/SSL tem capacidade de garantir a segurança necessáriapara chamadas de WS simples e não–hierárquicas. A SAML por sua vez, sobrepõe-se aoTLS/SSL, pois, apresenta em suas funcionalidades um protocolo de geração de mensagensbaseado em SOAP com dados estruturados em XML, desta maneira capacitando uma empresa adar testemunho dos direitos de identidade, autenticação e atualização de usuários humanos e deprograma (POTTS, 2003).

Vimos que o SAML permite que domínios da web seguros troquem a autenticação deusuário e os dados de autorização. Quando um provedor de serviços usa a SAML, ele podeentrar em contato com um provedor de identidade separado para autenticar usuários que estejamtentando acessar um conteúdo seguro.


2.4 Web Services Policy

A WSP é uma linguagem para definir políticas de serviços, oferecendo uma gramáticaflexível e extensível que permite definir como os recursos e restrições das normas de segurançapoderã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 asfuncionalidades presente em um WS. Isso permite aos provedores de serviços descreverem quaissão os serviços oferecidos, quais as informações são necessárias para processar as requisições einformando 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. Noentanto, 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 emque 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 qualqueroutro mecanismo de segurança.

A criação de uma política para anexar informações necessárias para definir requisitosadicionais (que deve ser cumpridos pelo cliente e pelo prestador do serviço para que a interaçãoentre ambos possa acontecer) que tornam necessário o surgimento de uma tecnologia WSP, comobjetivo 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 elementoraiz do documento é o elemento Policy. Dentro deste elemento, são representadas coleções deasserções (ou assertivas), que quando combinadas representam uma coleção válida de alternativasde 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 umaalternativa de política; All permite a combinação de todas as asserções apresentadas como umaalternativa de política (W3C, 2007b).

A seguir, a XML apresenta a estrutura simplificada para expressar políticas da especiali-zação WSP:

A especificação WSP é demasiada abstrata, expressa as capacidades, requisitos e ca-racterísticas gerais de entidades em um WS baseado em XML. Desta forma, mantendo o focodesse 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 ouWS-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 descrevecomo mensagens devem ser protegidas. A política pode aplicar-se a mensagens individuais, aoperações ou a toda a extremidade do serviço. As asserções (ou assertivas) WSSP referem-se àsfuncionalidades de segurança de WSS, WS-Trust12 e WS-SecureConversation13. Podem tambémreferir 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 detransporte. 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 umachave de certificado digital X.509 e outra pode ditar que a autenticação seja feita com a chave deum bilhete Kerberos.

A XML a seguir, apresenta a estrutura da WSSP de um serviço:

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

http://goo.gl/RHX5SJ

http://goo.gl/ULrS1L


A XML apresentou a existência de duas seções principais na definição da política: ovínculo de segurança e a proteção. A seção da política que define o vínculo de segurançareferente à 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çaem cada vínculo de segurança, permitindo a transferência de chave e estrutura dos cabeçalhosde segurança. Outra seção importante para a definição dos vínculos de segurança é a asserçãoSymmetricBinding. Essa asserção permite a conexão segura entre o emissor e o receptor comWSS, baseado em criptografia simétrica. Os tokens de segurança adicionados permitem tercombinaçõ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çõesde segurança definido da mensagem submetida. Uma seção de segurança contém sub-asserçõesque 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çãodos elementos de segurança), IncludeTimestamp (incluir marca temporal na mensagem), En-

cryptSignature (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 notransporte das mensagens com base no WSS. A AsymmetricBinding garante através de criptografiasimétrica entre o emissor e o receptor e a TransportBinding garante a correlação de segurançapor meios externos.

As asserções de tokens de segurança possuem propriedades que permitem identificarquais 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. Porexemplo, o token X509Token especificar que a mensagem seja assinada com uma chave decertificado digital X.509. Podemos destacar, ainda, o tokenTokenInlusion, que indica como ostokens de segurança devem ser usados. Segue a propriedade de processamento do token:

� Never: o token nunca pode ser transportado em mensagens, podendo apenas serreferenciado;

� Once: o token deve ser transportado uma vez na primeira mensagem, mas depoisnão mais. Esta opção é usada para iniciar sessões seguras;

� AlwaysToRecipient: o token deve ser enviado sempre que o emissor enviar umamensagem 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 umamensagem 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çãoda 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 determinarcompatibilidade e interoperabilidade; e informações necessárias para que uma entidade possaparticipar 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 possamser rapidamente provisionados e liberados com o mínimo de esforço de gerenciamento ouinteração com o provedor de serviços” (MELL; GRANCE, 2011).

Os grandes provedores de CN expõe um conjunto de Application Programming Inter-

face (API) para interagir e gerenciar com os serviços oferecidos. Essas APIs são definidas eespecificadas pelas interfaces de um WS, como na WSDL descrita na Subseção 2.1.5. Indepen-dentemente dos propósitos de projetos de cada um, a abordagem de CN pode se relacionar coma 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 eCN.

Figura 2.6: Relacionamento de Web Services, SOA e Computação em Nuvem

Fonte: Barry e Dick (2013) - adaptado.14Diagramas usados em matemática para simbolizar graficamente propriedades, axiomas e problemas relativos

aos conjuntos e sua teoria.


O diagrama ilustrado acima, enfatiza a CN inserida dentro do conjunto de WS utilizandoSOA para indicar que a CN usa os serviços de WS, no entanto, a CN pode ser utilizada sem omodelo 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 comum 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 dacomputação em nuvem, as nuvens computacionais podem ser classificadas da seguinte forma:

� Software como Serviço (Software as a Service - SaaS): Serviços de softwares depropósito específico disponibilizado por meio de interfaces como um navegador deinternet. As aplicações em nuvens são multi-inquilinos, ou seja, são utilizadas pordiversos clientes simultaneamente.

� Plataforma como Serviço (Platform as a Service - PaaS): Neste modelo o provedorfornece serviços para ambiente para programação, sem a necessidade de instalarferramentas de desenvolvimento locais. O usuário possui o controle dessas ferramen-tas de gerenciamento de configuração, implantação e execução de aplicações nestainfraestrutura.

� Infraestrutura como Serviço (Infrastructure as a Service - IaaS): O serviço IaaS

fornece uma API de gerenciamento para utilização dos recursos de infraestruturacomputacional básica (capacidade de armazenamento e processamento).

2.5.2 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 infraestruturaentre diversas organizações com interesses em comum (e.g. segurança, conformidadeou jurisdição);

� Nuvem Pública: Com uma nuvem pública, a infraestrutura da nuvem é de usoaberto por qualquer tipo de cliente. Pode ser gerenciada, operada e pertencer a umaempresa comercial, acadêmica ou governamental, ou uma combinação desses tiposde organizações;

� Nuvem Privada: Em uma nuvem privada, a infraestrutura é gerenciada e operadaexclusiva por uma organização, podendo ser administrada pela própria organizaçãoou por um terceiro;


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

2.5.3 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


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

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

https://www.google.com/intl/pt-BR/drive/

https://www.sugarsync.com/

https://www.icloud.com/

https://www.box.com/

https://www.dropbox.com/

https://goo.gl/Yg2Yzd

https://aws.amazon.com/pt/


Segundo o estudo realizado pela empresa de segurança Imperva22, realizado em 2015e disponibilizado através de um relatório23, identificou uma nova modalidade de ataque, estedenominado como Man in the Cloud (MITC). Essa vulnerabilidade foi identificada nos seguintesprovedores: Google Drive, Dropbox, OneDrive24 e Box. Segundo o relatório, não foi utilizadonenhuma 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 comprometero serviço de sincronização de arquivos na nuvem apenas roubando um token sem que sejanecessá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 Single-

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

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

http://www.imperva.com/

http://goo.gl/KPD2Pc

https://goo.gl/F66SFu


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 disser-tação.

454545

3Trabalhos 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 dasameaças

Legenda X = Mitiga completamente; O = Mitiga Parcialmente;

Vazamentode Dados

Perdade Dados

Sequestrode Contas

InterfacesInseguras

Negaçãode Serviços

(MACEDO et al., 2010) O O X O O(CELESTI et al., 2010) X O

(SALAS, 2012) O O O O X(FERREIRA, 2013) O O O(GONZALEZ, 2014) X XWINCKLER (2014) X OMICHELIN (2015) O X

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, WS-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

1http://goo.gl/MdroAi, Último Acesso em Fevereiro de 2016

http://goo.gl/MdroAi

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 Creden-ciais (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 geren-ciamento 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, implemen-tados 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.

2http://goo.gl/uQbNvt, Último Acesso em Janeiro de 20163https://www.openstack.org/, Último Acesso em Fevereiro de 20164http://wiki.python.org.br/, Último Acesso em Março de 2016

http://goo.gl/uQbNvt

https://www.openstack.org/

http://wiki.python.org.br/

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.


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.

5http://eping.governoeletronico.gov.br/, Último Acesso em Março de 2016

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

494949

4Implementaçã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 Arquiteturaadotada e a funcionalidade que o sistema fornece aos utilizadores finais;

50 4. IMPLEMENTAÇÃO DA PROPOSTA

� Visão Dependências: Ilustra as dependências existentes entre os módulos da Arqui-tetura;

� Visão Implementação: A visão de implementação ilustra um sistema da perspectivade 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 desenvolvimentodo sistema;

� Visão Física: Demonstra as configurações de hardware e os sistemas do ponto devista de um engenheiro de sistema. A topologia responsável pelos componentes desoftwares 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 Camposignificativos da Arquitetura. Os cenários servem como ponto de partida para testesde um protótipo de arquitetura.

4.2 Visão Lógica

Esta Seção demonstra a organização da arquitetura proposta a partir de um ponto de vistafuncional. 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 osrequisitos atendidos.

4.2. VISÃO LÓGICA 51

4.2.1 Módulo de Serviço

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

� Provedor de Serviço: O componente Provedor de Serviço, estruturado na especiali-zação WSDL, é responsável em definir e especificar as interfaces de serviço. Essasinterfaces contêm informações do tipo, localização do serviço, o que o serviço podefazer e como poderá ser chamado, permitindo assim, a interação do serviço. Essecomponente é responsável em descrever e publicar os serviços que posteriormenteserão consumidos pelos clientes.

4.2.2 Módulo de Mecanismos de Segurança

O Módulo de Mecanismo de Segurança, implementado pelas funcionalidades do padrãoWSS, é responsável em oferecer mecanismos padrões de segurança necessários para realizar ointercâmbio seguro de mensagens certificadas em ambientes de nuvem, através de assinaturasdigitais e criptografia. Oferece também, o gerenciamento do ciclo de vida de chaves comoregistro, distribuição e revogação. Dentre as funcionalidades oferecidas são constituídas dosseguintes 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çõesque necessitam realizar trocas de dados de forma segura. Além disso, provê ummecanismo de segurança que não é coberto pelo TLS/SSL, como a possibilidade decifrar somente parte de um dado e o estabelecimento de sessões seguras entre maisde 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 seuconteúdo, desta forma, a criptografia em XML fornece funcionalidades complementa-res para o padrão XML Digital Signature e permite criptografar um documento XMLcompleto, partes selecionadas de um documento XML ou conteúdo referenciadopor um documento XML. Esse componente também é guiado pelo padrão XMLEncryption.

� XKMS: O componente XKMS é implementado pela especificação XML Key Ma-

nagement Specification (XKMS), definido um protocolo para registrar e distribuir


chaves criptográficas que utilizam Infraestrutura de Chaves Públicas (PKI). Essecomponente auxilia a distribuição de chaves públicas, que são essenciais para XMLDigital Signature e XML Encryption, possibilitando verificações de assinaturas ecriptografia em mensagens SOAP. Divide-se em duas especificações a XML Key

Registration Service Specification (X-KRSS), para o registro de chaves, e o XMLKey Information Service Specification (X-KISS), para requisição e distribuição deinformaçõ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ênciasaplicadas em clientes e serviços de forma interoperável. O presente módulo permite expressar aspolí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:

� Alternativa de Política Alternativa de Política é responsável em definir uma coleçãonão ordenada de asserções da políticas, define também uma expressão de política naforma normal e um conjunto de regras que podem ser usadas para criar expressões depolíticas mais compactas.

� Asserção de Política A Asserção da Política é responsável em especificar requisitostradicionais 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 queadequados do serviço, por exemplo, política de privacidade e características deQuality of Service (QoS).

4.2.4 Módulo de Gerenciamento de Acesso e Identidade

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

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

1https://goo.gl/8OaMoZ, Último Acesso em Novembro de 20152http://www.openldap.org/, Último Acesso em Novembro de 2015

4.3. VISÃO DEPENDÊNCIA 53

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

� Provedor de Identidade: O Provedor de Identidade (IdP) é responsável pela ma-nutenção das informações sobre os usuários e por sua autenticação. O componenteProvedor de Serviço, abordado no módulo MS, requisita o IdP informando as creden-cias de acesso passada pelo usuário, por sua vez o IdP encaminhará uma afirmaçãoSAML, como parte da resposta de autenticação, que é gerada para obter credenciaisde 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ávelpor gerenciar as credenciais temporárias de segurança que consistem em uma chavede acesso e um token de sessão. A chave de acesso consiste em um ID chave deacesso e uma chave secreta. Usuários (ou um aplicativo que o usuário executa) podemusar essas credenciais para acessar os serviços providos na organização.

4.3 Visão Dependência

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

Figura 4.3: Diagrama de Dependências


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


tarefa de encontrar, definir e gerenciar os serviços disponibilizados. Por fim, as dependênciasdos módulos MMS e MGAI para atender aos requisitos de confidencialidade e autenticidaderespectivamente dos serviços prestados.

Assim como no diagrama de dependência, o MGAI contém dependência dos MPS eMMS, deve-se ao fato do MMS ser o mecanismo padrão de segurança necessário para realizaro intercâmbio seguro de mensagens, através de certificados digitais e criptografia e pelo MPSdefinir as políticas para criar, trocar e interpretar asserções de segurança entre entidades de umaaplicação.

4.4 Visão Implementação

Este tópico prover uma visão da implementação da arquitetura do protótipo do sistema. Aarquitetura definida utiliza frameworks e tecnologias para agilizar o processo de desenvolvimentosendo 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á disponibili-zada na camada de comunicação, fornecendo as funcionalidades presentes no Web

Service. Essas funcionalidades refletem as interfaces de serviços disponibilizadas nacamada de negócio.

� Spring Framework3: Esse framework oferece diversos módulos que podem serutilizados de acordo com as necessidades do projeto, como módulos voltados paradesenvolvimento Web, inversão de controle e programação orientada a aspectos,injeção de dependências, desenvolvimento baseada em POJO e integração comtecnologias de persistência e controle de transações como Hibernate. Compatibiliza-se com Spring Cloud Security4 na proteção da transmissão de tokens entre SSO eaplicações nas nuvens.

3https://goo.gl/oED3ey, Último Acesso em Novembro de 20154http://cloud.spring.io/spring-cloud-security/, Último Acesso em Janeiro de 2016

4.5. VISÃO FÍSICA 55

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

4.5 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áquinasvirtuais com as seguintes configurações:

� 2 processadores


� 50 GB de disco5https://goo.gl/SLtiHm, Último Acesso em Novembro de 20156O Hypervisor é uma camada de software localizada entre a camada de hardware e o sistema operacional.7http://www.dell.com.br/, Último Acesso em Dezembro de 2015


� Sistema Operacional Linux Debian Squeeze8 de 64bits

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

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


� 1TB de disco

� Sistema Operacional Windows 10 Home Single Language de 64bits

4.6 Cenários

Esta Seção visa apresentar alguns dos principais cenários, descritos em experimentos decampo, 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 atividadesdos 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 mensagensSOAP apresentados neste trabalho.

Inicialmente, a ferramenta Axis 2, que será apresentada na próxima parte, gerou um WSa partir da interface LogonServiceImpl.java do sistema. A interface como o WS gerado possui omé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 AccessCon-

trol.wsdl, recebeu todos os serviços propostos pela aplicação. O método autenticar retorna aocliente 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 interfacedo WS, enviando os dados necessários para consumir os serviços disponibilizados. Após ainvocação do serviço, o cliente recebe uma mensagem de sucesso, confirmando a transação daoperação ou uma mensagem de erro ou de exceção, informando que a transação não foi efetuadacorretamente.

A comunicação entre o cliente e o WS só é realizada através do acordo entre as definiçõesdas políticas de comunicação, através do lado do cliente pelo arquivo policyClient.xml e pelo ladodo WS o arquivo policyService.xml. Ambos definem a segurança desejada da mensagem SOAP

8https://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 foicomposta 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 suasaplicabilidades através de cenários de experimentos de campo que visa avaliar estes padrõesde segurança. A seguir, será apresentada a parte de maior interesse para o presente trabalho: aimplementaçã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-seas ferramentas SoapUI9 e Wireshark10.

4.6.2.1 Estudo de Caso 01

Inicialmente, executamos o programa Wireshark para analisar o tráfego da rede IN-TRAER. Especificamente, aplicamos a expressão de filtro: "http && ip.src = 10.80.8.85", comobjetivo 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 men-sagem SOAP. Percebe-se que as credenciais de acesso, destacadas em vermelho, são facilmenteobtidas pelo monitoramento da rede INTRAER.

Figura 4.5: Exemplo de pacote HTTP capturado pelo Wireshark


9https://www.soapui.org/10https://www.wireshark.org/


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 objetivode mitigar tais ameaças. Utilizou-se a especificação WSS, especificamente XML Signature, paragerenciar as credencias declarada no cabeçalho da mensagem SOAP, e aplicado a técnica deautenticação de criação de senha com três atributos. Assim, o formato da mensagem SOAP derequisiçã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çalhoda 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 noelemento <wsse:Password>. O resumo da senha é a combinação do elemento nonce, o tempode 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 16bytes de comprimento e é repassado com o valor base64 codificado. O hash da senha é criadoa partir do momento da criação e de uso único. O nonce nunca se repete, um serviço gerenciaa criação do nonce para evitar ataques de replay, aonde a mesma mensagem é capturada emtrânsito e re-enviada na tentativa de confundir ou interromper o serviço, este controle é realizadopelo estrutura de cache de nonces usados pelo Servidor.

A mensagem SOAP é enviada ao WS com as credenciais declarada, que realiza o mesmomecanismo de autenticação para recuperar a senha relacionado com o nome do usuário, oNonce e o tempo de criação da mensagem, gerando uma função hash que é validada com oPasswordDigest da mensagem SOAP recebida. Se os resultados estão de acordo, o WS retornauma 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étodoUsernameToken, 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 qualquerum que seja capaz de monitorar a mensagem.

A especificação WS-PolicySecurity foi utilizada para definir políticas no esquema deautenticação e na seleção do protocolo de transporte. O elemento <sp:UsernameToken> contemo atributo IncludeToken para definir o tipo de fluxo de mensagens especificando a inclusão detoken e o elemento <sp:HttpsToken>, aninhada com o elemento <wsp:Policy>, foi declaradopara 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 comoum todo. Para aplicá-la, o elemento <wsp:PolicyReference> foi declarado informando seuatributo URI para referenciar a política em questão, em nível de serviço (autenticar) do trecho doarquivo WSDL. Conforme exemplificado abaixo:


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


Este estudo de caso tem como objetivo demonstrar a aplicabilidade das especializaçõesXML Digital Signature e XML Encryption, conforme apresentadas nas Subseções 2.2.2 e2.2.3 respectivamente. O experimento de campo a seguir, baseia-se nas regras para gerar evalidar assinaturas digitais no cabeçalho da mensagem SOAP e nas encriptações dos elementosdeclarados no corpo da mensagem SOAP.

4.6. CENÁRIOS 61


Através da análise do cabeçalho da requisição SOAP, expresso pela XML acima, nota-sea criação do elemento EncryptedKey definindo a chave que será usada para cifrar os dados. Ométodo usado para cifrar a chave é o RSA versão 1.5. Outro elemento criado foi o KeyInfo quepossui várias informações sobre a chave, como por exemplo, o tipo do certificado utilizado, queno caso é X509v3.

O elemento KeyInfo indica também a chave a ser usada para validação da assinatura. Oelemento BinarySecurityToken foi declarado para criação de um token binário que vai ser usadona assinatura da mensagem. Após a criação do token é iniciada a criação da assinatura em sicom 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 nocaso foi o SHA-1;

� DigestValue: valor do resumo criptográfico.

Depois de especificadas as configurações da assinatura, podemos ver o valor da assinaturaque está no elemento SignatureValue. Ainda dentro da assinatura, temos informações sobre achave 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 deexpiração, geralmente em segundos. Caso o servidor identifique a mensagem em um tempomaior do que o declarado, a mensagem SOAP é rejeitada. A utilização correta dessa tag faznecessário que seja disponibilizado um serviço de sincronização dos relógios do servidor e docliente, 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 cifraa conteúdo do corpo da mensagem SOAP informando no elemento CipherValue. Aninhado comeste 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 aassinatura necessários para cifrar e assinar o documento XML.

4.6. CENÁRIOS 63


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 definidoum 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 comobjetivo 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ínculode segurança de criptografia assimétrica obrigatória. O elemento <sp:X509Token>, aninhadocom o elemento <sp:ProtectionToken>, indica que o certificado X.509 v3 utilizado com acriptografia Triple DES em modo cbc, é para ser usado por ambas as partes no proteção em trocade mensagem.

O elemento <sp:TransportBinding> é usado para especificar a segurança do transportede mensagens e correlação de segurança fornecida por outros meios, no caso, um transporteseguro utilizando o protocolo HTTPS, conforme definido pelo elemento <sp:TransportToken>.A declaração obrigatória do elemento <sp:AlgorithmSuite> define o algoritmo necessário paraa 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 umajanela 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 impor-tantes na segurança no transporte de dados da mensagem SOAP e no consumo dos serviçosdisponibilizados. Fornece um mecanismo de assinatura digital muito flexível. A especializaçãoWS-Policy, por sua vez, prover uso de políticas que definem como os serviços disponibilizadosestão autorizados a interagir com outros clientes e serviços.


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


Figura 4.6: Diagrama de Sequência Estudo de Caso 03


A especificação WSS especifica assertivas ou tokens de segurança SAML integrada nomecanismo 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 damensagem 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 [email protected], declarado no elemento <samlp:Subject>, está tentando consumir umserviço declarado no WS.

O elemento <saml:Assertion> define o local, ligação, e consulta que podem ser utilizadospara adquirir a afirmação identificada em uma asserção SAML. O valor do atributo ID doelemento <samlp:AuthnRequest> é enviado para o provedor de identidade (IdP) do Serviço deSSO que inclui autenticação e autorização.


Nesta etapa, é apresentada a mensagem SOAP de resposta do SAML indicando queo usuário [email protected] está autorizado a acessar o serviço, confirmado pela tag

<samlp:StatusCode>. Dessa forma, todas as afirmações SAML são incorporadas na mensagemde 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 gera-dos aleatoriamente.

� ISSUE_INSTANT: Timestamp indicando a data e hora em que a resposta SAML foigerada.

� ASSERTION_ID: Atributo da afirmação identificada da asserção SAML.

� NOT_BEFORE: Timestamp de controle para identificar a data e hora anterior aresposta SAML é considerada inválida.

� NOT_ON_OR_AFTER: Timestamp de controle para identificar a data e hora apósa resposta SAML é considerada inválida.

� AUTHN_INSTANT: Timestamp indicando a data e hora em que o usuário foi auten-ticado.

O estudo de caso 03 apresentou os mecanismo e procedimentos de segurança representadapelas 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çãode autenticação e autorização do usuário, e as informações de atributos. Segurança de mensagensSOAP não introduz novas ameaças além das identificadas para SAML ou pelo WSS.


Esta Parte iniciou-se apresentando o guia de descrição da arquitetura proposta, conhecidocomo 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 dessemé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 dautilizaçã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çãodas normas de segurança abordadas ao longo deste trabalho, apresentando os resultados obtidospelos experimentos de campos analisados.

717171

5Avaliaçã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. AVALIAÇÃO DA PROPOSTA

5.1.1 Planejamento

A fase de planejamento trata-se da logística de aplicação do GQM e principais plano deprojeto, no qual se descreve o ambiente, ferramentas e o que será avaliado. O primeiro passodeste trabalho foi realizar a implantação e desenvolvimento dos estudos de caso descritos naParte 4. O experimento de campo tem como objetivo conduzir um cenário real, a fim de testaruma determinada causa de efeito. Para a realização dessa avaliação, foram estudadas as técnicase os padrões descritos nas documentações publicadas pelas organizações W3C e OASIS, guiandoa 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 daInformá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émuma Organização regional, dispondo, além de sua Sede em Recife-PE, de dez Destacamentos deControle 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, BomJesus da Lapa-BA e Petrolina-PE.

O data center, dos sistemas administrativos, é localizado no CINDACTA III e de respon-sabilidade do Chefe da Seção da TIAd. A Seção da TIAd concentra toda infraestrutura necessáriapara implantação de Nuvem Privada dos sistemas administrativos, que são acessados por todosos Destacamentos Subordinados do CINDACTA III através da Rede de Dados do Comando daAeroná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órioda CSA, usado dois critérios: As ameaças classificadas pelo modelo SaaS e pelas propriedadesbásicas de segurança. Tais critérios foram delineados com foco da avaliação dos objetivos destetrabalho.

Seguindo os critérios anteriormente mencionados, os estudos de caso serão avaliados emsua 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 partirda Tabela 5.1 de forma sumarizada, das principais propriedades de segurança afetadas por cadauma das ameaças.

5.1. METODOLOGIA 73

Tabela 5.1: Propriedades de segurança afetadas por ameaças``````````````̀Propriedades

Ameaças Vazamentode Dados

Perdade Dados

Sequestrode Contas

InterfacesInseguras


Confidencialidade X X XIntegridade X X

Disponibilidade X X XNão Repúdio X XAutenticação X X

Fonte: CSA (2013).

A CSA também classificou, em sua análise de risco, uma série de ataques que podemutilizar 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

XXXXXXXXXXXXAtaquesAmeaças Vazamento

de DadosPerda

de DadosSequestrode Contas

InterfacesInseguras


Spoofing XAdulteração de Dados X X

Divulgação de Informação X X XRepúdio X X X

Negação de Serviço X XElevação de Privilégios X X

Fonte: CSA (2013).

De posse dos experimentos de campo, os estudos de caso contemplam assim os requisitosnecessários para a avaliação da arquitetura de referência com base nas normas e implementaçõesde 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 respon-didas e definir e refinar as métricas, seguindo a estrutura conforme ilustrada na Figura 5.2 edesenvolvido na Tabela 5.3.

Os protótipos desenvolvidos, com base nos estudos de caso, irão disponibilizar serviçosque serão consumidos pela ferramenta soapUI, em seguida a ferramenta de monitoramentoWireshak irá auxiliar na análise do comportamento de requisição e resposta entre as partesenvolvidas.


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

[Q1] Quão eficaz é aproteção das

tecnologias utilizadasno Estudo de Caso 01diante das ameaças?

Vazamento de DadosSubseção 2.5.3.1

Perda de DadosSubseção 2.5.3.2

Sequestro de ContasSubseção 2.5.3.3

Interfaces InsegurasSubseção 2.5.3.4

Negação de ServiçoSubseção 2.5.3.5

1. XML Signature2. Security Tokens

3. WS-SecurityPolicy4. HTTPS

Estudo de Caso 01Subseção 4.6.2.1

0 - Não se aplica1 - Fraco

2 à 3 - Razoável4 - Satisfatório5 - Excelente








1. XML Signature2. XML Encryption

3. WS-Policy4. Certificado Digital

5. CriptografiaTriple DES

em modo cbc6. HTTPS











1. SAML2. XML Signature






5.1.3 Coleta de Dados

A coleta de dados foi realizada com base nas questões e métricas definidas na seçãoDescrição. As métricas foram obtidas por meio da execução de Teste Funcionais que tem comoobjetivo demonstrar a operacionalidade das funções que foram especificadas. Na Engenharia deSoftware, 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çosprovidos, portanto o método de avaliação será baseado em testes funcionais, também conhecidoscomo caixa preta.

Os participantes dessa avaliação foram as ferramentas soapUI e Wireshark, que execu-taram as métricas para avaliar o comportamentos dos mecanismos de segurança usados comopadrão nos WS. Cada tecnologia foi avaliada a partir dos cenários definidos, também foramavaliadas 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 imple-mentar o protótipo, com necessidade de um mecanismo de processamento SOAP para analisarsintaticamente 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á atualmentena versão 1.7.0. O Axis 2 trata-se de um projeto desenvolvido pela Apache para proporcionarmuitos recursos não presentes na implementação atual do SOAP Apache. Axis 2 fornece asferramentas 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 asimplementações de segurança para o mecanismo de serviços da Web do Axis2 referente asespecificaçõ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çãode 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

1http://www.apache.org/, Último Acesso em Novembro de 20152https://axis.apache.org/axis2/java/rampart/, Último Acesso em Novembro de 2015

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 SOAPusando a classe LogonServiceImplStub.java, especificamente a URI de destino, osdetalhes do serviço (como o nome do serviço, o nome do método e parâmetros deentrada). A seguir, a mensagem SOAP é enviada pelo cliente ao nó do processamentoda 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 deseguranças exigidas (policyClient.xml e policyService.xml).

� Passo 2 – O receptor de transporte converte a mensagem vinda do cliente em umobjeto Message e o inclui em um objeto MessageContext. Ele também carrega váriaspropriedades como atributos do SOAP (cabeçalho SOAP) e define a propriedadetransportName no MessageContext. Desta forma, a mensagem SOAP é enviada aodispatcher.

� Passo 3 – O dispatcher é responsável pelo caminhamento da requisição ao WS dedestino.

� Passo 4 – WS (AccessControl.wsdl) executa o método e retorna a resposta ao dispat-

cher,

� 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. Oobjeto 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 damensagem, os detalhes da sessão e etc.

A arquitetura do Axis 2 pode ser facilmente integrada à qualquer aplicação web, inde-pendente 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 ocliente 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 foramimplementadas conforme as especificações desejadas e de forma autônoma usando a bibliotecaApache Commons Policy 1.0.

A criação de um cliente teve como objetivo realizar as chamadas dos serviços e aplicaros mecanismos de segurança: WSS, WSP e SAML. Foram criadas definições de políticas tantodo lado do cliente quanto do lado do WS, policyClient.wsse e policyService.wsse, enfatizado aWS-SecurityPolicy que especializa a WS-Policy para políticas de segurança. A política definida

3http://www.eclipse.org/, Último Acesso em Novembro de 2015


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 expe-rimentos 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 comprovaa identidade do emissor e permite acesso aos serviços do provedor, sempre e quando o provedorrealiza a validação do passwordDisgest. Por outro lado, a solução sem segurança não realizaa 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 desintaxes na resposta.

Figura 5.4: Análise do aumento do tempo de resposta


Além disso, a arquitetura proposta proveu segurança fim-a-fim para aplicações quenecessitam realizar trocas de dados de forma segura, e em conjunto, a especialização WS-

SecurityPolicy possibilitou a declaração o uso do protocolo HTTPS para conexões seguras. Epor fim, a criação de uma cadeia aleatória (nonce), permitindo rejeitar as mensagens SOAPmanipuladas com intuito de sobrecarregar o sistema. A aplicação manteve um tempo de respostapara os clientes abaixo de 400 milissegundos.


Figura 5.5: Resultados da avaliação da Questão 01



Seguindo a análise das especializações XML Digital Signature, XML Encryption eWS-Policy, conforme implementado no estudo de caso 02, obteve-se os resultados ilustrado naFigura 5.6.

A especialização XML Digital Signature garantiu os atributos de autenticidade, integri-dade e permitiu suporte para não repúdio aos dados assinados. Uma característica fundamentalda XML Digital Signature, permitida no experimento, é a capacidade de assinar apenas partesespecíficas da mensagem SOAP, essa flexibilidade é importante para garantir o atributo deintegridade 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 assinaturaincluída na mensagem conforme demonstrado neste estudo de caso.

Desta forma, os atributos de autenticidade, integridade e não repúdio receberam a classi-ficação de "Excelente", devido as regras de processamento de assinatura digital. A propriedadenã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údodo corpo da mensagem SOAP, fornecendo qualidade de proteção através de integridade, confiden-cialidade e autenticação única de mensagens. Por esse motivo, a propriedade confidencialidaderecebeu a escala quatro de "Satisfatório".

E por fim, as afirmações declaradas da especialização WS-Policy permitiram definircomo 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




Uma das principais dificuldades de realizar esse cenário de teste se concentrou na tarefade 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 deexperiência com esse protocolo e sua complexidade. Uma vez superada essa etapa, foi necessárioa configuração do servidor AD apropriado, estabelecendo a relação de confiança entre o provedorde 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 experimentoanalisado no estudo de caso 03, permitiu analisar a criação da solução SSO, a qual estabeleceuum círculo de confiança através do intercâmbio das mensagens SOAP entre as entidades IdPe SP. A SAML também permitiu melhorar a produtividade na redefinição das credenciais desegurança para uma mesma identidade, garantido assim a propriedade de disponibilidade. Autilizaçã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 aespecialização no suporte à autenticação com proteção de integridade em nível de mensagem.




5.2 Limitações da Avaliação

Devido às restrições de ferramentas, não foi possível desenvolver um ambiente controladocapaz de avaliar todas as variações de ameaças possíveis acerca dos dados do usuário, os quaisforam apresentados por este estudo, oferecendo assim um número ainda maior de métricas aserem submetidas nas questões de avaliação. Este crescimento na diversidade das métricaspoderia proporcionar uma análise mais quantitativa, o que em tese garantiria uma maior precisãoquanto aos resultados obtidos nos testes. Além disso, não foi possível realizar uma análisecomparativa 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 destacamentoslocalizados em Rio Largo-AL, Fernando de Noronha-PE e Bom Jesus da Lapa-BA, onde odesempenho da rede INTRAER é considerado insatisfatório, fazendo com que o tempo derequisição e resposta sejam maior que 5 segundos, comprometendo a solução de validação dotempo de expiração da mensagem SOAP.

A próxima Parte irá abordar sobre os mecanismos de segurança estudados, bem comoapontar melhorarias e trabalhos futuros.

838383

6Consideraçõ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 WS-

Security, 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. CONSIDERAÇÕES FINAIS

6.1 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 meca-nismo 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).

858585

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.

ARMBRUST, M. et al. A View of Cloud Computing. New York, US: Communications of the ACM, 2010, v.53, n.4, p. 50 – 58.

BARRY, D.; DICK, D. Cloud Computing. In: WEB services, service oriented architectures and cloud computing. 2th. Boston: Elsevier, 2013. cap. 4, p. 35 – 44.

BASILI, V.; CALDEIRA, G.; ROMBACH, H. Experience factory. In: MARCINAIK, John J. (Ed.). The goal question metric paradigm. New York: Encyclopedia of Software Engineering, 1994. p. 469 - 476.

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.

https://goo.gl/yHqONF

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.

LADAN, M. Web services: security challenges. In: INTERNET SECURITY (WORLDCIS), 2011, Lodon. Anais... Lodon: IEEE Press, 2011. p.160–163.

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 1.3, 2012. Disponível em: <http://goo.gl/bx6Fj9>. Acesso em: 25 nov. 2015.

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

919191

ACertificado 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 secomunicar 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 umaAutoridade 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 valordas senhas. Caso não deseje registrar o certificado oficialmente, ou seja, que ele sejaassinado digitalmente por uma autoridade certificadora, pule para o passo 5.

2. Depois de criado um certificado local usando o comando de keytool, use o comandopara 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 AutoridadeCertificadora (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árioencontrado e siga as instruções. Iremos acessar a StartSSL para obter certificadoteste:

https://www.startssl.com/

Depois que você seguir todos os passos do site da VeriSign, você receberá um arquivochamado 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údocompleto desde —–BEGIN NEW CERTIFICATE REQUEST—– até —–END NEWCERTIFICATE REQUEST—– e crie um arquivo com extensão CER colando oconteú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 certifi-cados 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 cadastradano comando do passo 1.

5. O procedimento para configurar o conector SSL no Tomcat é simples. No arquivoserver.xml encontrado na pasta /conf no diretório raiz do Tomcat, você tem essaconfiguração comentada, como mostrando a seguir:



No caso, você deverá substituir pelas linhas mostradas abaixo e deverão ser informa-dos o caminho onde se encontra o arquivo keystore e a senha do mesmo:

https://www.startssl.com/

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 pelaslinhas 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 foiinformado localhost acesse https://localhost:8443/.

ricardo marinho de melo · web services baseados em nuvem privada / ricardo marinho de melo. –...

Documents