See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/283274571

Security Analysis of Cloud Computing Solutions

Chapter · May 2014

CITATION READS

1 254

8 authors, including:

Charles Miers Marcos Simplicio

Universidade do Estado de Santa Catarina University of São Paulo
25 PUBLICATIONS 167 CITATIONS 48 PUBLICATIONS 517 CITATIONS

SEE PROFILE SEE PROFILE

Tereza Cristina M. B. Carvalho Leonardo Horn Iwaya

University of São Paulo Karlstads Universitet
138 PUBLICATIONS 590 CITATIONS 10 PUBLICATIONS 65 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

SecSLA for Cloud Computing View project

Science DMZ View project

All content following this page was uploaded by Marco Antonio Torrez Rojas on 19 May 2016.

The user has requested enhancement of the downloaded file.

Capítulo

1
Análise de Segurança para Soluções de Computa-
ção em Nuvem

Charles Christian Miers (UDESC), Guilherme Piegas Koslovski (UDESC),

Marcos Antonio Simplicio Jr.(USP), Tereza Cristina Melo de Brito Carva-
lho(USP), Fernando Frota Redígolo(USP), Bruno Bastos Rodrigues(USP),
Bruno Medeiros de Barros(USP), Nelson Mimura Gonzalez(USP), Marco
Antonio Torrez Rojas(USP), Leonardo Horn Iwaya(USP)
Abstract
Cloud computing solutions are increasingly adopted by companies and government from
several sectors of the economy. In this scenario, the choice of cloud solutions can occur
either by hiring an external service (public or community cloud) or by creating an own
cloud to provide services only for this institution (private cloud). Even though the cloud
technology does bring some interesting benefits for its users, the security aspects related
to cloud computing solutions are not always fully understood before hiring such service or
even during its operation. The goal of this document is, building on theoretical research
and practical experience, to present the main security issues related to cloud computing.
We review the main concepts of cloud computing, focusing the discussion on the key issues
and safety standards specific to this scenario. Finally, aiming to illustrate how this body
of knowledge can be used in practice, we present a case study in which we analyze the
API communications on the OpenStack Havana solution.
Resumo
Soluções de computação em nuvem são cada vez mais adotadas por empresas e governo
dos mais diversos setores da economia. Nesse cenário, a escolha de soluções em nuvem
pode ocorrer tanto pela contratação de um serviço externo (nuvem pública ou nuvem co-
munitária) como pela criação de uma nuvem para disponibilizar os serviços apenas para
o interessado (nuvem privada). Apesar da tecnologia em nuvem apresentar importantes
vantagens para seus usuários, os aspectos de segurança relacionados a esse ambiente
nem sempre são tão bem entendidos antes da contratação de tal serviço ou mesmo du-
rante a sua operação. O objetivo do presente trabalho é, a partir de um levantamento
teórico e de experiência prática, apresentar o estado da arte dos principais aspectos de
segurança relacionados a nuvens computacionais. São revisados os principais concei-
tos de nuvens computacionais, como foco na discussão de pontos chaves dos aspectos
e normas de segurança específicas a este cenário. Por fim, para ilustrar como esse co-
nhecimento pode ser utilizado na prática, é apresentado um estudo de caso no qual é
analisada a comunicação via APIs da solução OpenStack Havana.
1.1. Conceitos básicos
A computação em nuvem, por ser um modelo de computação recente, ainda carece de uma
padronização geral sobre o tema. De fato, ainda ocorre alguma confusão e mal entendi-
dos pelo fato de uma nuvem computacional envolver um certo conjunto de tecnologias
existentes, organizadas de modo a fornecer determinados serviços de forma específica.
Sendo assim, o produto denominado de “nuvem computacional” chegou ao mercado an-
tes que houvesse sido estabelecida uma terminologia, fato este que levou diversas organi-
zações [1–3] a criar suas próprias definições. Dentre elas, a definição mais amplamente
aceita por pesquisadores para descrever nuvens computacionais é a do National Institute
of Standards and Technology (NIST) [2]: “A computação em nuvem é um modelo que
permite acesso de rede ubíquo, conveniente e sob demanda a um conjunto configurável
de recursos computacionais compartilhados, que podem ser rapidamente provisionados
e liberados com um mínimo esforço de gerenciamento ou interação do provedor de ser-
viço”.
Esta definição fundamenta de maneira sucinta a finalidade da computação em nu-
vem, determinando que, a partir de qualquer dispositivo com acesso à web e a qualquer
momento, um conjunto de recursos computacionais físicos ou virtuais deve estar à dis-
posição do usuário, liberando-se ou provisionando-se mais recursos conforme as neces-
sidades do mesmo. Para refinar esta definição, o NIST [2] definiu cinco características
essenciais [2, 4] para nuvens computacionais:

• Serviços sob demanda: o usuário pode definir automaticamente e sob demanda

o fornecimento de recursos da nuvem, tais como poder de processamento e ca-
pacidade de armazenamento, conforme sua necessidade e sem que haja interação
humana com o prestador de serviço.
• Acesso por banda larga: recursos estão disponíveis na rede e são acessados pelos
clientes através de variadas plataformas (e.g., smartphones, laptops, desktops, etc.).
• Conjunto de recursos: os recursos de computação (armazenamento, processa-
mento, memória, largura de banda e máquinas virtuais) do provedor são agrupados
para atender múltiplos usuários. Esses recursos, sejam eles físicos ou virtuais, são
atribuídos dinamicamente e de acordo com a demanda dos clientes.
• Elasticidade rápida: recursos podem ser rapidamente fornecidos para garantir a
escalabilidade dos serviços. Assim, o usuário tem a impressão de que os recur-
sos disponíveis são ilimitados e podem ser adquiridos em qualquer quantidade e a
qualquer momento.
• Serviço mensurável: a nuvem controla e otimiza o uso de recursos, fornecendo
métricas de acordo com o tipo de serviço sendo fornecido. Tanto o provedor quanto
o cliente podem monitorar e controlar a utilização dos recursos.

Para prover este conjunto de características, a computação em nuvem se utiliza

fortemente do conceito de virtualização de recursos, permitindo que em um mesmo hard-
ware sejam executados simultaneamente dois ou mais ambientes distintos e isolados, de-
nominados de máquinas virtuais (Virtual Machines – VMs) [5]. Assim, as VMs oferecem
grande flexibilidade na utilização de recursos, já que elas podem ser criadas e destruídas
facilmente [6]. Tal tecnologia faz ainda com que haja grande eficiência no uso do hard-
ware subjacente, utilizado capacidade que de outra forma poderia ficar ociosa, resultando
em economia direta para a infraestrutura de TI (Tecnologia da Informação). Por outro
lado, o uso de VMs induz o risco de disputa por recursos dentro de um mesmo hardware
(e.g., caso haja um pico de usuários em atividade no mesmo instante), o que implica na
necessidade de coordenação dessas VMs.

1.1.1. Modelos de Serviço

Os modelos de serviço referem-se à maneira como o conjunto configurável de recursos
computacionais da nuvem pode ser entregue ao usuário final, ou seja, a forma como todo
este conjunto gerenciável de recursos pode satisfazer as necessidades do usuário. No en-
tanto, há uma carência de padronização na terminologia geral por parte dos provedores de
serviços de nuvem, pois estes criam modelos de serviço de acordo com suas necessidades
e objetivos de negócio, dificultando o entendimento do conceito por parte dos principais
interessados: os usuários.
Tendo esse problema em vista, o NIST [2] definiu três modelos de serviço que são
utilizados como referência por diversos pesquisadores [6–8] e importantes organizações,
como CSA (Cloud Security Alliance) [3], ENISA (European Network and Information
Security Agency) [1] e o próprio NIST. Neste trabalho também é adotada a nomenclatura
do NIST, que define os seguintes modelos de serviço:

• Infraestrutura como Serviço/IaaS (Infrastructure as a Service): este é o modelo de

serviços mais básico oferecido pela nuvem, tendo como objetivo entregar os recur-
sos computacionais em sua forma mais fundamental (processamento, capacidade
de armazenamento, etc.). Tais recursos podem então ser empregados na operação
de qualquer software adquirido e/ou implementado pelo cliente, incluindo sistemas
operacionais (SOs), desde que estes não controlem ou gerenciem a infraestrutura
básica da nuvem [9]. Dentre todas as opções de modelo de serviço, o IaaS é parti-
cularmente interessante quando os objetivos de negócio do usuário necessitam sim-
plesmente de infraestrutura computacional, como um data center, mas por algum
motivo, ele não deseja adquirir e manter esta infraestrutura localmente (e.g., devido
a inviabilidade econômica). Assim, fica a cargo do provedor todas as tarefas de
manutenção e gerenciamento da infraestrutura de TI (espaço físico, climatização,
conectividade, energia elétrica, arquitetura de rede, segurança física e lógica, entre
outros), bem como as despesas correspondentes, permitindo ao usuário se concen-
trar diretamente em seu objetivo de negócio. De fato, a demanda por estruturas
computacionais robustas, aliada ao elevado preço de manutenção das mesmas, está
entre os principais fatores que levaram a criação de provedores especializados em
IaaS [10]. Exemplos de sucesso incluem Amazon Simple Storage Service (S3),
RackSpace Cloud Servers, OpenStack e CloudStack.

• Plataforma como Serviço/PaaS (Platform as a Service): este modelo possui be-

nefícios especialmente para desenvolvedores de aplicações, pois estes podem im-
plementar, testar e disponibilizar suas aplicações em ferramentas e linguagens que
 são suportadas diretamente pelo provedor da nuvem [9]. Assim, o objetivo prin-
cipal para clientes que adotam este modelo costuma ser o de reduzir os custos e a
complexidade de gerenciamento do hardware subjacente ao ambiente de desenvol-
vimento [1]. Embora possa ser vantajoso em diversos cenários, há também riscos
envolvidos, já que as aplicações desenvolvidas em uma PaaS normalmente ficam
presas ao fornecedor (provedor de nuvem). Tal fato merece atenção de potenciais
usuários ao escolher uma solução de PaaS, sendo este um grande fator inibidor para
a ampla adoção deste modelo [8]. Alguns exemplos de provedores de PaaS são
Google App Engine, Microsoft Azure e Red Hat OpenShift.

• Software como Serviço/SaaS (Software as a Service): este modelo oferece o pro-

duto final da computação em nuvem, a aplicação, pronta para ser utilizada pelo
consumidor através da web. Neste modelo o consumidor não gerencia ou controla
as camadas subjacentes de serviços, mas somente a própria aplicação [6]. Todo soft-
ware e os respectivos dados associados são armazenados de maneira centralizada,
facilitando o gerenciamento e suporte às aplicações por meio da nuvem. Apesar
desta facilidade, o SaaS também apresenta uma série de desafios a serem vencidos,
com destaque para problemas regulatórios, integração com os recursos internos da
organização, disponibilidade e, como é o foco do presente documento, a segurança
da informação [8]. Exemplos de serviços que adotam o modelo SaaS são Google
Docs e Microsoft Office Live.

Esses três tipos de modelos de serviço caracterizam em linhas gerais o que pode
ser oferecido em cada camada de abstração de serviços da nuvem, permitindo inclusive a
construção de modelos mais detalhados que permitam uma classificação mais específica
dos diversos serviços possíveis dentro de cada modelo (veja, por exemplo, a taxonomia
descrita em [11]). Além disso, esses modelos podem ser combinados de diferentes for-
mas, o mesmo ocorrendo para o conjunto de recursos necessário para disponibilizá-los
(Figura 1.1).

Figura 1.1: Diversas combinações para oferecer serviços de nuvem.

 Por exemplo, é possível fornecer um serviço de nuvem não apenas usando uma
infraestrutura específica para este fim, mas também a partir de outros serviços de nuvem.
A Figura 1.1 ilustra algumas das possíveis configurações de serviços da nuvem usando
modelo de serviço SPI (SaaS/PaaS/IaaS).

1.1.2. Abordagens de Implantação

Uma abordagem de implantação refere-se à forma como a nuvem é integrada ao ambiente
da empresa ou organização, em função das particularidades, objetivos de negócio ou tipos
da informação a serem armazenada por tal entidade [8]. Normalmente, as nuvens são
classificadas de acordo com a localização de sua infraestrutura e à forma como os usuários
a acessam. As quatro abordagens de implantação segundo o NIST são [2]:

1. Pública: é caracterizada por expor seus recursos computacionais sob a forma de

serviços que podem ser contratados por múltiplos usuários. A infraestrutura da nu-
vem é disponibilizada através da Internet para o público em geral e/ou para grandes
grupos industriais, sendo gerida por uma entidade que venda serviços em nuvem.
Por este motivo, em tais nuvens é mais difícil aplicar restrições de acesso no tocante
ao gerenciamento da rede que interliga a nuvem ao mundo externo, ou mesmo im-
plantar mecanismos de autenticação e autorização que previnam a nuvem de ser
alcançada por usuários potencialmente maliciosos [4, 8].
2. Privada: a infraestrutura da nuvem é utilizada exclusivamente por um único usuá-
rio ou organização. Geralmente, a nuvem é construída sobre um datacenter privado
e pode ser gerida pelo usuário/organização ou por terceiros. Os membros da orga-
nização têm exclusividade de uso dos recursos computacionais, obtendo uma maior
confiabilidade e confidencialidade sobre informações e dados críticos [12]. Em-
bora traga algumas facilidades por estar em ambiente privado, este modelo exige
gerenciamento interno, aumentando custos e potencialmente deixando o sistema
engessado em termos de automação de tarefas como verificação e aplicação de atu-
alizações [4, 8].
3. Comunitária: utilizada quando várias organizações apresentam requisitos seme-
lhantes (condições de segurança, políticas de segurança, etc.) e decidem compar-
tilhar parte de suas infraestruturas. A nuvem resultante pode ser gerenciada pelas
organizações participantes da comunidade ou por um terceiro, em implementação
local ou remota [4].
4. Híbrida: qualquer tipo de combinação de duas ou mais das categorias anteriores.
Um exemplo seria uma nuvem privada que automaticamente aloca recursos de uma
nuvem pública caso os seus próprios recursos sejam insuficientes para atender um
determinado pico de demanda.

Cada abordagem de implantação possui seu benefício de acordo com os objetivos

de quem está contratando o serviço de nuvem. Nuvens privadas garantem uma maior
segurança e controle sobre os ativos armazenados, pois a nuvem é mantida em uma rede
privada. Já as nuvens públicas oferecem uma eficiência maior para recursos compartilha-
dos; porém, estando expostas ao público geral, carregam consigo maiores preocupações
com segurança, aspecto este que deve ser eficiente e bem planejado. A abordagem co-
munitária pode ser entendida como uma nuvem de nuvens, cada parte sendo acessível
pelas organizações que compartilham as infraestruturas que compõem a nuvem completa.
Finalmente, a abordagem híbrida pode combinar as características de duas ou mais abor-
dagens de implantação. A Tabela 1.1 apresenta uma comparação entre as características
de cada abordagem considerando os seguintes aspectos: gerência, propriedade, localiza-
ção e segurança.

Tabela 1.1: Comparação entre abordagens de implantação (NIST). Adaptada de [3].

Gerência Propriedade Localização Segurança
Pública Terceiros Terceiros Externa ou Interna Baixa
Privada Própria Própria ou Terceiros Externa ou Interna Alta
Híbrida / Comunitária Própria ou Terceiros Própria ou Terceiros Externa ou Interna Média

A gerência diz respeito a quem controla a nuvem, ou seja, quem organiza e admi-
nistra os serviços. Assim, em nuvens privadas a gerência é feita pela própria instituição
que se utiliza de seus serviços, enquanto em nuvens públicas a gerência é realizada por
terceiros; já no caso de nuvens híbridas/comunitárias, a gerência pode ser própria ou de
terceiros. A propriedade indica quem fornece o serviço de nuvem: em uma nuvem pú-
blica, o serviço é fornecido por terceiros, enquanto nuvens públicas, híbridas e comunitá-
rias podem ser fornecidas tanto por terceiros ou usando recursos próprios. A localização
refere-se ao posicionamento da parte física da nuvem, como, por exemplo, a sala-cofre na
qual está localizado o hardware sob o qual as camadas da nuvem são construídas. Como
tecnologias de nuvem em geral fornecem um elevado grau de transparência na locali-
zação dos recursos subjacentes, nuvens computacionais podem ser colocadas tanto em
ambientes externos como internos à organização (ou mesmo uma combinação dos dois),
independentemente do seu tipo.
Finalmente, no tocante à segurança, com uma nuvem privada a organização man-
tém seus dados limitados ao acesso interno, garantindo um elevado nível de segurança
pois a gerência e utilização da nuvem são realizadas pela própria organização. Ao utili-
zar uma nuvem híbrida a organização permite que sua nuvem privada comunique-se com
uma nuvem (pública ou privada) sob gerência de outrem, tornando o nível de segurança
um pouco mais baixo devido à troca de dados com uma entidade cujas políticas de segu-
rança são possivelmente desconhecidas [1]. Já a nuvem pública é o tipo de nuvem que
possui nível de segurança mais baixo, pois está aberta a qualquer perfil de usuário que
conheça a localização do serviço.

1.1.3. Modelo de Referência

Dentre as diversas questões que envolvem computação em nuvem, uma das que mais ca-
recem de consenso é qual a arquitetura ideal para esse tipo de solução. De fato, as arqui-
teturas dos diversos sistemas de computação em nuvem existentes são bastante diferen-
tes entre elas, dependendo da política adotada por cada provedor ou desenvolvedor [13].
Além disso, existem diversas definições de arquiteturas de referência, muitas delas forne-
cidas por organizações reconhecidas como ORACLE [14], IBM [13] e NIST [4]. Este é
um fato preocupante, pois um passo fundamental para o sucesso da adoção da nuvem por
qualquer entidade é exatamente ter uma arquitetura adequada para as suas necessidades.
Tendo este problema em vista, o presente trabalho novamente segue a linha do
NIST, por ser esta uma organização que estabelece padrões bem aceitos por pesquisadores
e organizações, através de seus guias e recomendações. Assim, a Figura 1.2 apresenta tal
arquitetura de referência, identificando seus principais atores, suas atividades e funções
na computação em nuvem.

Figura 1.2: Diversas combinações para oferecer serviços de nuvem. Adaptado de [4].
Conforme observado na Figura 1.2, a arquitetura de referência do NIST define
cinco atores principais (cada ator sendo uma entidade representando uma pessoa ou uma
organização que participa do processo ou realiza alguma tarefa):

• Consumidor: uma pessoa ou organização que mantém uma relação de negócios e

usa os serviços dos Fornecedores de nuvem.
• Fornecedor: uma pessoa, organização, ou entidade responsável por entregar um
serviço às partes interessadas.
• Auditor: uma parte que pode conduzir uma auditoria independente dos serviços
da nuvem, coletando informações sobre operações do sistema, desempenho e segu-
rança.
• Corretor: uma entidade que gerencia o uso, desempenho e entrega dos serviços da
nuvem, e negocia a relação entre Fornecedores e Consumidores.
• Portador: um intermediário que fornece conectividade entre o Fornecedor e o Con-
sumidor, permitindo o acesso aos serviços de nuvem.

Dois pontos nesse modelo de referência merecem destaque. Primeiro, percebe-se

que a preocupação com a segurança das nuvens computacionais é prevista como parte
do modelo (especificamente, no papel do auditor), e não como um componente opcional.
Além disso, o modelo delimita o escopo de cada ator mas não coibe que um ator combine
duas ou mais entidades na implementação de uma mesma parte da nuvem que está sob
sua responsabilidade.
1.2. Guias para segurança em computação em nuvem
A computação em nuvem já possui alguns materiais de referência que cobrem os aspectos
gerais de segurança, providos na forma de documentos, guias e padrões do CSA, ENISA
e NIST, os quais são analisados nesta seção. Contudo, cabe notar que a documentação
fornecida pelo CSA, ENISA e NIST, de um modo geral, abrange mais as questões proce-
dimentais e regulamentares sob uma ótica de gerenciamento e governança. Sendo assim,
esses trabalhos não abordam alguns detalhes técnicos operacionais das nuvens compu-
tacionais com relação aos recursos virtualizados nelas presentes. Isto acaba sendo um
problema porque a grande maioria das nuvens computacionais tem como unidade de con-
cessão de serviços a virtualização de algum recurso, como é o caso das VMs no caso
do OpenStack [15], ou, com uma granularidade menor, os chamados grains no Micro-
soft Orleans [16]. Portanto, nesta seção são também apresentados os principais guias
relacionados a segurança de recursos virtualizados, elencando pontos-chaves e questões
relevantes neste contexto.

1.2.1. Guias específicos para computação em nuvem

Inicialmente, são analisados os guias específicos para computação em nuvem, os quais
discutem questões de segurança tradicionais no contexto deste novo paradigma e também
novos desafios trazidos por tal tecnologia.

1.2.1.1. Guia Segurança NIST para Computação em Nuvem

Em resposta a um pedido do governo dos Estados Unidos para acelerar a adoção governa-
mental da computação em nuvem [17], o NIST elaborou um guia voltado para segurança
e privacidade cujo propósito declarado é [18]: “fornecer uma visão geral sobre os desafios
de segurança e privacidade envolvidos na computação em nuvem”.
Esse guia [18] afirma que as organizações que utilizam uma abordagem de com-
putação em nuvens privadas possuem um maior nível de controle sobre os dados. Por este
motivo, o documento é focado em abordagens de computação em nuvens públicas. De
uma forma geral, ele fornece uma visão ampla dos serviços de nuvem, discutindo bene-
fícios e problemas neste modelo do ponto de vista de segurança, indicando pontos chave
de segurança e privacidade, e fornecendo recomendações sobre terceirização de dados
para um provedor de nuvem qualquer. A Figura 1.3 apresenta as questões de segurança
elencadas pelo documento e a sua classificação de acordo com diferentes aspectos.
As questões 1 e 2 da Figura 1.3 tratam da governança e conformidade. O termo
governança1 refere-se ao conjunto de políticas, funções, responsabilidades e processos
que devem ser estabelecidos para orientar, direcionar e controlar como a organização usa
tecnologias para atingir as metas corporativas, ou seja, um conjunto de normas estabele-
cidas para atingir um determinado objetivo. Já a conformidade indica se a organização
atende às normas, leis e regulamentos em questão.
A questão 3 abrange diversos tópicos. O primeiro deles são as ameaças internas,
ou seja, de usuários internos ou inquilinos maliciosos, os quais representam um risco so-
1 http://www.gartner.com/it-glossary/it-governance/
 Figura 1.3: Questões de segurança em nuvens computacionais elencadas pelo NIST.

bre os dados hospedados na nuvem. Outro refere-se à propriedade dos dados na nuvem
e potenciais problemas de violação de propriedade intelectual. Há ainda uma discus-
são sobre a dificuldade em gerenciar a visibilidade dos inquilinos sobre os controles de
segurança utilizados na nuvem, dado que, ao mesmo tempo que tal visibilidade é essen-
cial para que usuários avaliem os riscos aos quais seus sistemas hospedados na nuvem
estão expostos, ela também facilita ataques por inquilinos maliciosos. São ainda discuti-
das questões relativas aos dados “adicionais” que surgem quando uma entidade adota o
serviço de nuvem, como informações bancárias usadas no pagamento pelos serviços do
provedor de nuvem, as quais também devem ser protegidas por este último.
As questões sobre arquitetura (item 4), discutem os sistemas de software utiliza-
dos na computação em nuvem. A descrição desse ponto de segurança se inicia alertando
que a introdução de monitores de máquinas virtuais (hypervisors) aumenta a superfície de
ataque na computação em nuvem, em comparação com o modelo tradicional de data cen-
ters. Além disso, o tráfego de dados que fica restrito a redes virtuais pode não ser visível
para ferramentas de segurança tradicionais de rede, como firewalls, sistemas de detecção/-
prevenção de intrusão (IDS/IPS), entre outros, potencialmente reduzindo sua efetividade.
Assim, torna-se necessário o uso de ferramentas especialmente adaptadas pra monitorar
essas redes virtuais. Outra questão levantada refere-se ao fato de que os dados sobre as
imagens de máquinas virtuais e serviços da nuvem podem conter informações relevantes
para atacantes e, portanto, necessitam de cuidados especiais. Finalmente, discute-se a
segurança do navegador web do cliente, a ferramenta básica para acesso aos serviços da
nuvem.
A discussão sobre gerenciamento de identidades e controle de acesso (questão 5)
tem como foco o uso de autenticação via SAML (Security Assertion Markup Language)
e XACML (eXtensible Access Control Markup Language) para controle de acesso, des-
crevendo uma linguagem para políticas de acesso e também um formato para mensagens
de requisição e resposta.
A questão 6, relativa a isolamento de software, discute ameaças que são deriva-
das diretamente do fato de nuvens apresentarem a característica de multi-tenancy (multi-
inquilinos), i.e., diversos usuários compartilhando o mesmo equipamento físico. Assim,
são discutidos problemas de interferências negativas entre VMs, especialmente se uma
VM for capaz de escapar ao ambiente a ela reservado pelo monitor de máquinas virtuais.
No contexto da proteção dos dados (questão 7), é dado destaque às diferenças
entre o modelo multi-tenancy, no qual os dados de diferentes usuários são colocados em
um único repositório, e o modelo multi-instâncias no qual cada usuário usa e administra
um repositório de dados separado. Além disso, é abordada a questão da exclusão segura
dos dados (eliminação lógica e física), essencial para garantir a confidencialidade dos
mesmos e a privacidade dos usuários da nuvem.
Já a discussão sobre disponibilidade (questão 8) aborda as ameaças indiretas pro-
venientes do compartilhamento de um mesmo fornecedor de nuvem com uma organização
que tem um grande potencial de sofrer ataques de negação de serviço (Denial of Service -
DoS). Afinal, esses ataques podem afetar a qualidade dos serviços providos na nuvem em
questão, afetando todos os inquilinos da mesma.
A última questão abordada é a da resposta a incidentes, tópico no qual é destacado
o papel fundamental do provedor de nuvem em detectar a ocorrência de ataques e agir de
acordo, além de prover acesso a dados detalhados de tais incidentes para permitir que os
inquilinos afetados também possam participar deste processo.
Além do levantamento de questões de segurança, listadas na Figura 1.3, que afe-
tam os serviços da nuvem, o guia também apresenta recomendações para cada ponto
chave (questão) definido. As recomendações são agrupadas de acordo com as questões
discutidas:

1. Governança: estender práticas organizacionais para englobar políticas, procedi-

mentos, e padrões utilizados para o desenvolvimento de aplicações e provisiona-
mento de serviços na nuvem, bem como fazer uso de ferramentas de auditoria para
garantir seu cumprimento.

2. Conformidade: entender os diversos tipos de leis e regulamentações de segurança

e privacidade que se aplicam à organização, os quais podem ter impactos nas ini-
ciativas de migração de serviços para a nuvem. Verificar também que tais aspectos
legais não apresentam conflitos com o contrato firmado com o provedor de nuvem
ou com os aspectos operacionais deste último.

3. Confiança: garantir que os acordos de serviço firmados incluam visibilidade su-

ficiente sobre os processos de controle de privacidade e segurança, permitindo o
monitoramento de seu desempenho. Estabelecer claramente os direitos de propri-
edade sobre os dados. Instituir um programa de gerenciamento de riscos que seja
 flexível o suficiente para adaptar-se constantemente ao ciclo de vida do sistema
hospedado na nuvem (i.e., da sua criação à finalização de sua operação). Monitorar
continuamente a segurança do sistema de informação para dar suporte às decisões
resultantes do processo de gerenciamento de riscos.
4. Arquitetura: compreender as tecnologias de camadas inferiores que a nuvem uti-
liza para provisionar serviços, em especial no que se refere ao seu impacto sobre a
segurança e privacidade do sistema, sobre o seu ciclo de vida e sobre seus compo-
nentes.
5. Gerenciamento de Identidade e Acesso: garantir que existem medidas adequa-
das para prover segurança aos processos de autenticação, autorização, controle de
acesso e de identidades.
6. Isolamento de Software: entender a virtualização e outras técnicas lógicas de iso-
lamento que o provedor da nuvem utiliza em sua arquitetura para dar suporte a
múltiplos inquilinos, avaliando os riscos envolvidos para a organização.
7. Proteção dos Dados: avaliar a adequação de soluções de gerenciamento de dados
e de chaves criptográficas fornecidas pelo provedor de nuvem para gerenciar os
dados organizacionais hospedados na nuvem, bem como a sua capacidade de prover
acesso aos dados e protegê-los durante todo o seu ciclo de vida. Ponderar sobre os
riscos de se hospedar os dados no mesmo ambiente em que organizações que podem
ser alvos preferenciais de ataques.
8. Disponibilidade: compreender os itens previstos no contrato com relação a dis-
ponibilidade, backup e recuperação de desastres, garantindo que elas estejam de
acordo com os planos de contingência e continuidade de negócios da organização.
9. Resposta a Incidentes: compreender os itens previstos no contrato relativos à res-
ponsabilidade sobre incidentes, garantindo que os procedimentos descritos estejam
de acordo com os requisitos da organização. Garantir que o provedor tenha um pro-
cesso transparente de resposta a incidentes, bem como mecanismos suficientes para
disponibilizar informações antes e durante o incidente. Garantir que a organização
e o provedor são capazes de responder a incidentes de forma coordenada, de acordo
com as suas devidas responsabilidades sobre o ambiente de nuvem.

De uma forma geral, pode-se dizer que o guia do NIST [18] discute as princi-
pais questões de segurança com as quais os fornecedores de nuvem devem se preocupar,
além de estabelecer as recomendações necessárias para garantir a segurança e a privaci-
dade dos serviços destes pontos de segurança. De fato, o documento é considerado um
dos mais completos guias de segurança em computação em nuvem, sendo um dos mais
referenciados por diversos autores (e.g., [6–8, 19], para citar alguns).

1.2.1.2. Guia de Segurança CSA

A CSA (Cloud Security Alliance) é uma organização sem fins lucrativos, fundada no
final de 2008 em uma iniciativa para reforçar a segurança da computação em nuvem.
Seus membros fundadores são principalmente representantes industriais, corporações e
associações (e.g., DMTF, ITU, OWASP, Dell, HP e eBay) [20]. Um dos seus principais
objetivos é incentivar a adoção de boas práticas para promover a segurança nos ambientes
de computação em nuvem. A discussão a seguir sobre as recomendações resultantes do
trabalho da CSA toma com base a sua versão 3.0 [3], por ser este o documento mais
recente disponível no momento em que este texto foi elaborado.
O texto do guia se inicia com uma nota editorial que descreve brevemente os
passos necessários para verificar se uma organização está pronta para a transição para o
modelo em nuvem. Esta nota editorial consiste em alguns itens: identificação e avalia-
ção dos ativos para a implantação do modelo em nuvem, mapeamento dos recursos para
verificar modelos de implantação possíveis (público, privado, híbrido ou comunitário),
avaliação de potenciais provedores de nuvem, entre outros. No Guia CSA, as questões
de segurança são chamadas de domínios de segurança. Porém, no presente documento
manteremos o termo “questão” para fins de padronização e para facilitar comparações.
O documento está dividido em três seções: (i) arquitetura da nuvem; (ii) gover-
nança da nuvem e (iii) operações na nuvem. Ao todo, o documento identifica treze ques-
tões de segurança nessas seções, apresentado diversos subtópicos dentro de cada uma
dessas seções. A Figura 1.4 sumariza essa estrutura, apresentando as questões e suas
respectivas subdivisões.
A discussão sobre segurança se inicia com colocações relativas à forma de se
governar a nuvem. Com relação a governança e o gerenciamento de risco empresarial
(questão 1), discute-se a necessidade de atenção com os processos organizacionais da
segurança da informação. É dado especial destaque aos acordos de níveis de serviço (Ser-
vice Level Agreements – SLAs), especificando-se que requisitos de segurança devem ser
especificados nesse documento e reforçadas por um contrato. No tópico gerenciamento
de risco, é advertido no documento para não avaliar somente o fornecedor da nuvem, mas
também os terceiros com quem o provedor está envolvido (i.e., para quem o provedor de
nuvem terceiriza serviços). As questões 2 e 3 discutem a conformidade com regulamen-
tações governamentais, normas da própria organização, aspectos legais (e.g., propriedade
intelectual, responsabilidades), entre outras, estabelecendo como estas regras podem in-
fluenciar a segurança interna da organização. A questão 4, descreve diversos aspectos
relacionados à manipulação dos dados, como segurança, localização, gerenciamento da
informação, entre outros, estabelecendo os modos em que os dados devem ser gerencia-
dos para evitar vulnerabilidades que possam expor os dados armazenados. Já a discussão
sobre portabilidade e interoperabilidade (questão 5) inicia com uma especificação de pos-
síveis razões para migrar os dados para o modelo de nuvem. Neste tópico, o documento
ressalta que a computação em nuvem ainda carece de uma padronização de diversos fato-
res, causando uma dificuldade para a interoperabilidade de serviços, e consequentemente,
a dificuldade de migrar serviços de um provedor de nuvem para outro. Por outro lado, é
importante notar a contribuição das plataformas de nuvem Open Source para mitigar esse
problema, já que elas que contribuem para o aumento da interoperabilidade entre prove-
dores através da divulgação de seus códigos e adoção de interfaces padronizadas (e.g.,
Open Cloud Computing Interface - OCCI, Virtual Infrastructure Modeling Language -
VXDL).
 Figura 1.4: Questões de segurança em nuvens computacionais elencadas pela CSA.

As questões de segurança na operações na nuvem, por outro lado, envolvem oito

questões adicionais. Na questão 6 os pesquisadores da CSA discutem sobre as ameaças
internas da organização, recuperação de desastres, e continuidade de negócios. Especifi-
camente, o documento reforça que um SLA por si só não é suficiente para garantir que os
serviços do usuário estarão seguros na nuvem, sendo necessário uma verificação constante
dos pilares da segurança (confidencialidade, integridade e disponibilidade). As considera-
ções sobre a operação de data centers (questão 7) tratam principalmente das questões que
devem ser consideradas no momento da escolha do provedor de nuvem. Neste aspecto,
a CSA recomenda atenção aos seguintes pontos: auditoria, disponibilidade, desempenho,
gerenciamento de atualizações, compartimentalização e suporte. A resposta a inciden-
tes (questão 8), apresenta um informativo sobre ferramentas de detecção de incidentes
e análises para obtenção de informações das ferramentas para a prevenção dos mesmos.
Na questão 9, relativa a aplicações seguras, é descrito o ciclo de desenvolvimento de
aplicações, técnicas para garantir a segurança da informação (incluindo mecanismos de
autenticação, autorização e verificação de conformidade), gerenciamento de identidades,
entre outros. Uma recomendação feita pela CSA nesta questão é a avaliação de vulnerabi-
lidades através de testes de penetração periódicos, o que fornece maiores garantias sobre
a segurança da aplicação. Quanto à cifração de dados e gerenciamento de chaves (questão
10), é dada ênfase para a segurança da comunicação entre hosts, até mesmo com a comu-
nicação interna na rede do provedor. Um alerta importante neste sentido é que, devido à
característica de multi-tenancy da nuvem, a questão do gerenciamento de chaves torna-se
ainda mais complexa, sendo necessária atenção especial do usuário da nuvem quanto a
esse aspecto. Na questão 11 faz-se uma introdução à verificação de identidades na nuvem,
identificando aspectos que devem ser levados em consideração ao implementar um me-
canismo de identidades para esse ambiente. São tratados especificamente tópicos como
provisionamento de identidades, autenticação, entre outros, dando-se ênfase à dificuldade
de construir soluções escaláveis no modelo em nuvem devido ao grande número e diver-
sidade de identidades e atributos nesse ambiente (de usuários, organizações, dispositivos,
etc.). A questão 12 trata os aspectos de segurança da virtualização em si, considerando
elementos como as máquinas virtuais, o hypervisor, entre outros. O documento é finali-
zado com uma discussão a respeito da segurança como serviço (questão 13), que realça a
diferenciação do modelo de segurança da computação em nuvem em relação ao modelo
tradicional de data centers. São abordados aspectos como práticas de implementação,
benefícios de se implementar a “segurança como serviço” e a variedade de serviços que
podem ser assim categorizados.
Além do levantamento dos aspectos políticos/legais e técnicos que envolvem o
conceito de computação em nuvem, a CSA também fornece recomendações para cada
questão abordada. Como as recomendações costumam envolver diversos itens, a seguir
são apresentadas apenas alguns exemplos representativos:

1. Governança e Gerenciamento de Risco Empresarial: reinvestir o capital econo-

mizado com a adoção da nuvem em ferramentas que permitam verificar a segurança
do provedor de nuvem, na implantação de controles de segurança e na realização de
vistorias e auditorias. Levar em consideração aspectos de segurança no processo de
escolha de um provedor de nuvem, considerando controles estabelecidos, capaci-
dade de desenvolvimento de um processo colaborativo de governança e obrigações
previstas em contratos de SLA. Também devem ser adotadas métricas e padrões
para medir o desempenho e a efetividade do gerenciamento de segurança da infor-
mação na nuvem.

2. Aspectos Legais: Contratos e Descoberta Eletrônica: não são disponibilizadas

recomendações específicas no documento porque a legislação envolvida sofre mu-
danças de país para país.

3. Conformidade e Auditoria: utilizar auditores especializados no modelo de nuvem

para verificar a aplicabilidade de controles (novos ou existentes) a esse ambiente.
Contratos de SLA devem ser revisados por terceiros para garantir conformidade
com requisitos legais e regulamentações vigentes.

4. Gerenciamento de Informação e Segurança dos Dados: compreender a arqui-

tetura de armazenamento de dados adotada pelo provedor, dando preferência a so-
luções com dispersão de dados quando disponíveis; monitorar bases de dados na
 nuvem para identificar a exposição de dados sensíveis ou violações de políticas de
segurança no seu tratamento; cifrar dados sensíveis durante todo o seu ciclo de vida,
da criação ao descarte; entre diversas outras.

5. Interoperabilidade e Portabilidade: Com relação à interoperabilidade, recomenda-

se a adoção de soluções de segurança padronizadas e abertas, as quais devem ser
bem compreendidas, bem como usar virtualização na medida do possível (máquinas
virtuais, redes virtuais, etc.) para evitar diversos (embora não todos) os problemas
em nível hardware. Com relação à portabilidade, é importante considerar aspec-
tos diversos que impactam na migração de serviços, como os SLAs, arquiteturas
físicas e lógicas, mecanismos de segurança disponíveis, etc. São também feitas
recomendações para os diferentes modelos de serviço em nuvem.

6. Segurança Tradicional, Continuidade de Negócios e Recuperação de Desas-

tres: consumidores de nuvem não devem depender de um único provedor, mas
preferencialmente estabelecer contratos com múltiplos fornecedores e possuir fer-
ramentas para rápida recuperação em caso de incidentes em um (ou alguns) deles.
Também é recomendado que os clientes da nuvem exijam transparência com relação
à postura de segurança da nuvem, permitindo avaliações dos planos de contingência
do provedor contra desastres, da segurança física da infraestrutura, etc.

7. Operações de Data Center: o gerenciamento do data center deve envolver pro-

cessos, boas práticas e software que permitam entender e lidar com a tecnologia
e recursos nele presentes de forma ágil e com elevada disponibilidade. É também
importante compreender a missão das ferramentas sendo executadas dentro do data
center e como elas se adequam aos requisitos de segurança do ambiente. Final-
mente, devem ser estabelecidas as partes responsáveis por garantir conformidade
com requisitos de segurança e o papel de cada uma delas na avaliação de tal con-
formidade.

8. Resposta a Incidentes, Notificações e Correções: consumidores de nuvem de-

vem compreender como provedores definem os eventos de interesse no tocante à
detecção de incidentes de segurança e quais eventos/incidentes são reportados aos
usuários; consumidores devem possuir um meio de comunicação com o provedor
em caso de incidentes; dentre diversos outros.

9. Aplicações Seguras: realizar análises de risco para as aplicações; garantir uma

vistoria detalhada dos vetores de ataque e riscos no ambiente de nuvem; procurar
desenvolver e manter uma arquitetura de software segura; entre outras.

10. Gerenciamento de Chaves e Criptografia: utilizar boas práticas de gerenciamento

de chaves, bem como soluções de prateleira de fontes reconhecidas; utilizar algo-
ritmos padronizados de cifração considerados seguros atualmente; entre outras.

11. Identidade e Gerenciamento de Acesso: todos os atributos utilizados devem pos-

suir um nível de confiança a eles atribuídos e devem ser associados a uma iden-
tidade; desenvolvedores devem garantir que os serviços sejam capazes de impor-
tar/exportar dados seguindo padrões como XACML; entre outras.
 12. Virtualização: consumidores devem identificar o tipo de virtualização que o prove-
dor utiliza; desenvolvedores devem cifrar imagens de VMs quando as mesmas não
estiverem em uso; configurações padrões das VMs devem respeitar os requisitos
mínimos de segurança estabelecidos; entre outras.
13. Segurança como Serviço: desenvolvedores devem garantir o estabelecimento de
um canal de comunicação seguro entre os inquilinos da nuvem ; fornecedores de-
vem prover notificação automática de incidentes de segurança; consumidores de-
vem requisitar a presença de terceiros para intermediar a negociação da SLAs e
auditar serviços; entre outras.

1.2.1.3. Guia de Segurança ENISA

A ENISA (European Network and Information Security Agency) é uma organização que
visa [1]: “Aumentar a capacidade da União Européia, dos estados membros da União
Européia e da comunidade de negócios em prevenir, tratar e responder a problemas de
segurança da informação e redes.”
O documento se inicia com uma especificação dos benefícios de computação em
nuvem sob o prisma da segurança. Em seguida, é realizada a descrição de um processo de
análise e avaliação de riscos com base em três cenários de caso de uso: (i) computação em
nuvem em pequenas e médias empresas; (ii) impacto da computação em nuvem na resili-
ência de serviço e (iii) computação em nuvem para administração pública (eGovernment).
Essa análise é baseada na probabilidade de cenários de incidentes com uma estimativa de
impacto nos negócios e níveis de risco (baixo, médio ou alto).
A lista de questões de segurança contém não apenas riscos que são específicos
para o modelo de computação em nuvem, mas também riscos que não o são [7]. Para
maior concisão, neste documento são listadas apenas as questões de segurança direta-
mente ligadas à nuvem, enquanto os problemas não relacionados foram omitidos.
As questões de segurança (ou riscos, como definidos no documento da ENISA)
relevantes para computação em nuvem estão apresentadas na Figura 1.5. Ao contrário
dos guias apresentados nas subseções 1.2.1.1 e 1.2.1.2, a ENISA define as questões de
segurança especificamente e, por esse motivo, não existem subtópicos.
A lista de questões políticas e organizacionais se inicia com a discussão da questão
do lock-in (questão 1), relatando a situação de falta de portabilidade entre fornecedores
de nuvem em cada categoria de serviço na nuvem (IaaS, PaaS e SaaS). Após isto, gover-
nança (questão 2), conformidade (questão 3) e ameaças indiretas causadas por inquilinos
que estão utilizando um mesmo fornecedor (questão 4) são discutidas. É destacado que
desafios de disponibilidade podem ser resultado de problemas dentro do próprio provedor
da nuvem (questões 5 e 6) ou terceiros em que o provedor confia (questão 7).
A lista de questões técnicas se inicia com ameaças resultantes da exaustão de re-
cursos (questão 8), como: incapacidade de fornecer recursos (estabelecidos no SLA ou
adicionais) aos clientes, indisponibilidade de serviços, entre outros. A questão 9 trata
de falhas nos mecanismos que isolam recursos compartilhados entre usuários (falhas no
hypervisor). Em seguida são apresentadas as vulnerabilidades que causam ou podem vir
 Figura 1.5: Questões de segurança em nuvens computacionais elencadas pela ENISA.

a causar ameaças internas, como: funções e responsabilidades mal definidas, vulnera-

bilidades no sistema operacional, procedimentos de segurança física inadequados, entre
outros. Alguns dos riscos apresentados podem ser agrupados mais amplamente, como ge-
renciamento de interface (questão 11) e comprometimento de motor (engine) de serviços
(questão 19) que tratam da segurança de aplicações e listam vulnerabilidades no software
do provedor da nuvem. A interceptação de dados em trânsito na rede (questão 12) tam-
bém é análoga ao vazamento de dados em operações de upload e download, discutindo a
interceptação causada por vulnerabilidades na infraestrutura do fornecedor da nuvem ou
no enlace com o usuário.
As ameaças de negação de serviço (DoS) são apresentadas como dois riscos no
documento: negação de serviço distribuída (questão 15, Distributed Denial of Service
- DDoS), quando um ataque causa problemas de disponibilidade; e negação de serviço
econômica (questão 16), quando requisições maliciosas de serviço aumentam o tráfego
na rede e acabam causando uma amplificação no custo dos serviços para o usuário da
nuvem. Outros assuntos técnicos como detecção de varreduras maliciosas (questão 19)
internas à infraestrutura da nuvem, e esforços insuficientes do consumidor para garantir a
segurança da nuvem (questão 20) completam a lista de questões técnicas abordadas pela
ENISA.
A lista de aspectos legais contempla inicialmente procedimentos para responder
a processos de descoberta eletrônica e intimações judiciais (e.g., o governo pode requisi-
tar, por algum motivo, algum dado armazenado na nuvem - questão 21). As outras três
questões (22, 23 e 24) descrevem preocupações relativas a manipulação dos dados, como
conformidade de localização (questão 22) e de proteção (questão 23) dos dados armaze-
nados na nuvem e riscos provenientes da perda de propriedade intelectual dos mesmos
(questão 24).
As recomendações de segurança no Guia da ENISA são fornecidas na seção de
“Recomendações e Mensagens Chave”. Isso é feito utilizando uma estrutura diferente
da empregada para descrever as questões de segurança, dificultando o mapeamento en-
tre uma dada recomendação e sua respectiva vulnerabilidade. Essa falta de estrutura é
compensada por uma abordagem em que as recomendações de segurança são realizadas
através de questionamentos, aos quais o leitor deve responder para se guiar e evitar as
vulnerabilidades envolvidas, de modo que a abordagem acaba indo por um caminho mais
intuitivo, orientado a problemas.

1.2.1.4. Comparativo: NIS vs. CSA vs. ENISA

Para constatar as diferenças e resumir as questões elencadas nos guias do NIST, CSA
e ENISA, a Tabela 1.2 apresenta um comparativo considerando questões políticas, or-
ganizacionais e legais, enquanto a Tabela 1.3 resume as questões técnicas listadas nas
subseções do NIST, CSA e ENISA. Especificamente, essas tabelas verificam se as ques-
tões são ou não abordadas nos documentos: em caso positivo a coluna é marcada com
“Abordado”; caso contrário, a marcação é feita com “n.a.” (não abordado).

Tabela 1.2: Comparativo quanto a questões Políticas, Organizacionais e Legais.

Questões Políticas, Organiza- Subtópicos NIST CSA ENISA
cionais e Legais
1 - Governança e Gerencia- Abordado Abordado Abordado
mento de Risco
2 - Conformidades e Auditoria 2.1 - Conformidades de Leis e Regulamentos Abordado Abordado Abordado
2.2 - Conformidades de Localização dos Dados Abordado Abordado Abordado
3 - Aspectos legais: contratos Abordado Abordado Abordado
e descoberta eletrônica
4 - Ameaças Internas Abordado Abordado Abordado
5 - Tratamento dos Dados 5.1 - Proteção dos Dados a Respeito dos Usuários Abordado n.a. n.a
5.2 - Propriedade Intelectual Abordado Abordado Abordado
5.3 - Disponibilidade dos Dados p/ Análise Forense Abordado Abordado Abordado
6 - Relatórios de Incidentes Abordado Abordado Abordado
7 - Gerenciamento de Corre- Abordado Abordado Abordado
ções
8 - Vistorias 8.1 - Vistoria do Provedor Abordado Abordado Abordado
8.2 - Vistoria das Dependências do Provedor Abordado Abordado Abordado

A Tabela 1.2 usa como parâmetros de comparação aqueles definidos em [7], que
apresenta tópicos fundamentais para garantir a segurança da computação em nuvem: go-
vernança e gerenciamento de risco; conformidades e auditoria; aspectos legais (eletrô-
nicos e contratos); ameaças internas; tratamento dos dados; relatório de incidentes; ge-
renciamento de correções; e vistorias. Embora bastante amplos, cabe observar a lista de
parâmetros utilizados nas comparações realizadas não fornecem a noção de qual docu-
mento é o mais completo, pois representam apenas uma pequena parcela dos tópicos que
são abordados nos mesmos. Assim, os parâmetros podem variar em função das neces-
sidades de segurança, dos objetivos das organizações, entre outras variáveis. De fato, a
principal diferença encontrada entre os documentos foi na questão 5.1 da Tabela 1.2, rela-
tiva ao tratamento dos dados dos usuários: enquanto a CSA e ENISA se preocupam com
a segurança dos dados que o usuário pretende armazenar na nuvem, o NIST dá ênfase
na segurança dos dados do próprio usuário, como suas informações pessoais que podem
ser alvos de ataques. Já com relação à questão 2.2 da Tabela 1.2, conformidades de lo-
calização dos dados, embora a ENISA não faça uma discussão direta sobre o assunto,
indiretamente o mesmo é tratado.

Tabela 1.3: Comparativo Guias NIST, CSA e ENISA quanto a questões técnicas.
Questão Técnica Subtópicos NIST CSA ENISA
1 - Disponibilidade 1.1 - Interrupções Abordado Abordado Abordado
1.2 - Exaustão de recursos n.a. Abordado Abordado
1.3 - Ameaças de disponibilidades por ataques de Abordado n.a Abordado
DoS
1.4 - Ameaças por compartilhamento de dados Abordado Abordado Abordado
2 - Portabilidade 2.1 - Portabilidade de dados Abordado Abordado Abordado
2.2 - Portabilidade de imagens de VMs n.a. Abordado Abordado
2.3 - Portabilidade de aplicações Abordado Abordado Abordado
3 - Gerenciamentos de Dados 3.1 - Isolamento Abordado Abordado Abordado
3.2 - Backup e recuperação Abordado Abordado Abordado
3.3 - Exclusão Abordado Abordado Abordado
3.4 - Cifração Abordado Abordado Abordado
3.5 - Gerenciamento de chaves Abordado Abordado Abordado
3.6 - Verificação de integridade Abordado Abordado n.a.
4 - Identidade e Gerencia- 4.1 - Provisionamento e desprovisionamento de n.a. Abordado Abordado
mento de Acesso identidade
4.2 - Federação de identidade Abordado Abordado Abordado
4.3 - Autenticação Abordado Abordado Abordado
4.4 - Autorização e controle de acesso Abordado Abordado Abordado
5 - Segurança de Aplicação 5.1 - Proteção do Cliente Abordado Abordado Abordado
5.2 - Proteção do Servidor Abordado Abordado Abordado
5.3 - Proteção da Imagem da VM Abordado Abordado Abordado
5.4 - Proteção dos Arquivos de Log n.a. Abordado Abordado
6 - Virtualização 6.1 - Proteção do Hypervisor Abordado Abordado Abordado
6.2 - Proteção do Sistema Operacional Visitante Abordado Abordado Abordado
6.3 - Proteção da Rede Virtual Abordado Abordado Abordado

Os parâmetros de comparação para as questões técnicas da Tabela 1.3 também

foram estabelecidos com base em [7], a saber: disponibilidade; portabilidade; gerenci-
amento de dados; identidade e gerenciamento de acesso; segurança de aplicação; e vir-
tualização. A partir da análise dessa tabela, pode-se perceber que a grande maioria das
questões são abordadas por todos os guias, com apenas algumas questões não sendo abor-
dadas em pontos específicos.
Começando com a questão da disponibilidade (questão 1), pode-se subdividi-la
nos tópicos: interrupções, exaustão de recursos, ameaças de disponibilidade causadas por
ataques de negação de serviço, e ameaças resultantes do compartilhamento de dados. As
interrupções (questão 1.1) podem ser causadas por falhas de hardware ou nas instalações
(falta de energia elétrica), ou desastres naturais, todos esses aspectos sendo abordados nos
documentos do NIST, CSA e ENISA. A exaustão de recursos (questão 1.2) pode acontecer
quando o provedor de nuvem não se prepara adequadamente para prever o quanto de
recursos os usuários podem necessitar, de modo que a demanda pelos mesmos supera a
capacidade de fornecimento do provedor. Na teoria, o fornecimento dos recursos deve ser
realizado automaticamente (conforme demanda do usuário). No entanto, o guia CSA [3]
alerta que “a teoria da computação em nuvem ainda é muito maior do que a parte prática,
e muitos consumidores se confundem com isto”. Durante a análise, não foi encontrada
uma discussão no documento do NIST sobre a exaustão de recursos.
A negação de serviços (DoS, questão 1.3) é outra ameaça relacionada à disponi-
bilidade, que é discutida nos documentos do NIST e da ENISA, porém é omitida no guia
da CSA. Além do ataque de negação de serviço tradicional, o documento da ENISA des-
creve um tipo de ataque de negação de serviço econômica, na qual o objetivo é causar um
aumento no custo dos serviços do usuário, algo factível em cenários em que o preço do
serviço depende do número de serviços requisitados. As ameaças indiretas de outros usuá-
rios (causadas pela característica de multi-tenancy) são discutidas nos três documentos.
Um exemplo seria um ataque de DoS em um usuário com quem se está compartilhando
algum recurso, tornando este serviço indisponível.
A questão da portabilidade (questão 2) ou (ausência de) lock-in, pode variar tam-
bém de acordo com o modelo de serviço (IaaS/PaaS/SaaS). Para um usuário transferir
dados e aplicações para outro provedor de nuvem, é necessário um nível suficiente de
portabilidade de dados (questão 2.1) e aplicações (questão 2.3). No caso de IaaS, a por-
tabilidade de imagens de VMs (questão 2.3) também deve ser considerada. Avaliando os
três documentos, foi possível notar que o NIST não discute em sua seção de arquitetura a
questão de portabilidade de imagens de VMs.
Analisando os documentos sob o prisma do gerenciamento de dados (questão 3),
observam-se os subtópicos: isolamento em ambiente multi-tenancy (questão 3.1), exclu-
são segura dos dados (questão 3.3), e backup e recuperação de dados (questão 3.2), ci-
fração de dados em trânsito e em repouso (questão 3.4), backup e recuperação de chaves
(questão 3.5) e verificação de integridade (questão 3.6). É dada maior atenção à questão
de backup e recuperação dos dados no documento da CSA, enquanto nos documentos
da ENISA e NIST, é dada maior importância na cifração dos dados durante o backup e
na exclusão dos dados das cópias de segurança. Todos os documentos abordam esses
temas, exceto a ENISA, que não faz menção à verificação de integridade das chaves crip-
tográficas. Quanto ao gerenciamento de acesso e identidade (questão 4), no comparativo
entre os documentos observado-se que o documento do NIST não aborda a questão 4.1
(provisionamento e desprovisionamento de identidade).
A segurança de aplicação (questão 5) inclui os seguintes subtópicos: proteção do
cliente (questão 5.1) e servidor (questão 5.2), proteção da imagem da VM (questão 5.3) e
proteção dos arquivos de log (questão 5.4). O comparativo entre os documentos revela que
todos esses subtópicos são discutidos, exceto pela ausência do tema gerenciamento de ar-
quivos de log no documento do NIST. Isto pode ser visto como uma lacuna relevante, pois
as informações geradas nos arquivos de log podem conter informações sensíveis, sendo
atenção extra no gerenciamento destes arquivos pois as informações neles armazenadas
podem pertencer a diversos usuários que compartilham recursos de um provedor [6].
A questão de virtualização (questão 6) finaliza o quadro de questões técnicas,
com o seguintes subtópicos: proteção do hypervisor (questão 6.1), proteção do sistema
operacional visitante (questão 6.2) e proteção da rede virtual (questão 6.3). Todos os
documentos apresentam tópicos discutindo tais problemas.
Em resumo, comparando-se de forma geral os documentos apresentados, pode-se
concluir que, para os parâmetros definidos em [7] e adotados neste trabalho, o documento
do NIST obtém maior destaque com respeito às questões políticas, organizacionais e le-
gais, abordando todos os parâmetros utilizados. O documento da ENISA apresentou o
melhor resultado sobre questões técnicas, abordando todos os parâmetros utilizados.
1.2.2. Virtualização: NIST, PCI Security Standards Council e Red Hat
Um dos recursos mais importantes envolvidos na computação em nuvem é a virtualização,
pois tal tecnologia tem influência direta na redução dos custos de uma infraestrutura com-
putacional ao permitir um aproveitamento mais racional dos seus recursos físicos [21].
A virtualização diz respeito à criação de ambientes virtuais, tipicamente composto por
máquinas virtuais [22] interconectadas por redes virtuais [23]. As máquinas virtuais pos-
suem um papel importante no suporte a sistemas de IaaS e, com isto, também torna-se
um alvo em potencial para ataques. Soluções tradicionais de segurança, baseadas na con-
fiança que o núcleo do SO possui os recursos de isolamento adequados, não são soluções
efetivas para garantir a segurança da infraestrutura virtual do modelo de IaaS [21]. Tendo
isto em vista, esta seção apresenta os principais guias de segurança em virtualização de
recursos, e em seguida um comparativo avaliando os pontos relatados por eles.

1.2.2.1. Guia sobre Virtualização NIST

Com o crescente uso de produtos e serviços resultantes da virtualização de recursos, o

NIST elaborou uma publicação específica [22] à segurança em virtualização, visando
complementar o guia para computação em nuvens públicas [4] e apresentando preocupa-
ções e recomendações para garantir a segurança na virtualização de recursos. A Tabela 1.4
apresenta as seções e os tópicos abordados pelo NIST [22].

Tabela 1.4: Guia de segurança para virtualização NIST SP 800-125.

Seção
1 - Introdução
2 – Introdução a Virtualização Total
3 – Visão Geral da Segurança na Virtualização
4 – Recomendações de Segurança para Virtualização
de Componentes
5 – Virtualização Segura, Planejamento e Utilização
Tópicos
Apresentação do documento, estruturação dos tópicos, apre-
sentação do público e do propósito e escopo
2.1 - Motivações para virtualização
2.2 - Tipos de virtualização total
2.3 - Virtualização de hardware, rede e armazenamento
2.4 - Casos de virtualização total (servidores e desktop)
3.1 - Isolamento dos sistemas operacionais virtualizados
3.2 - Monitoramento e gerenciamento de imagens e snapshots
4.1 – Segurança do hypervisor
4.2 – Segurança do SO Visitante
4.3 – Segurança da infraestrutura virtualizada
4.4 – Segurança na virtualização de desktops
5.1 – Inicialização
5.2 – Planejamento e projeto
5.3 – Implementação
5.4 – Operações e Manutenção
5.5 – Disposição

O guia inicia apresentando uma introdução à virtualização de recursos, primeira-

mente com uma definição de conceitos e tipos de virtualização que podem ser empregados
tanto para servidores como para desktops. Logo em seguida, ele apresenta uma motivação
para o uso da virtualização, apresentando alguns benefícios proporcionados por sua utili-
zação, sendo o principal deles a grande eficiência na utilização dos recursos de hardware.
O guia [22] evidencia que existem diversas razões para o uso da virtualização em
desktops. Por exemplo, ela proporciona suporte para aplicações que executam em um
sistema operacional específico, além de permitir que mudanças realizadas em um sistema
operacional que afetam negativamente a sua segurança sejam mais facilmente revertidas.
Em seguida, o documento aborda os tipos de virtualização existentes. Na virtua-
lização denominada bare-metal, o hypervisor é executado diretamente sobre o hardware,
sem necessitar de um SO (podendo até ser implementado no próprio firmware do com-
putador). Na arquitetura de virtualização hosted, o hypervisor executa sobre um SO,
que pode ser qualquer um dos sistemas operacionais mais comuns (e.g., MS-Windows e
GNU/Linux). No armazenamento virtualizado, os sistemas de hypervisors possuem di-
versas maneiras de simular o armazenamento de disco para os ambientes virtualizados.
Todos hypervisors possuem no mínimo discos rígidos virtuais, enquanto alguns possuem
mais algumas opções de armazenamento virtual. Mais especificamente, alguns hypervi-
sors podem utilizar interfaces de armazenamento, como Network Attached Storage (NAS)
e Storage Area Networks (SAN). Finalmente, no item 2.4 são descritos alguns casos de
virtualização total, como “servidor único para virtualização”, “múltiplos servidores para
virtualização” e a virtualização para desktops.
O capítulo 3 inicia com uma visão geral sobre a segurança na virtualização, discu-
tindo questões como: isolamento dos recursos virtualizados, a camada do hypervisor e o
SO; o propósito e os mecanismos para o monitoramento das máquinas virtuais hospedadas
(guests) em um sistema hospedeiro (hosts); e o gerenciamento de imagens e snapshots.
Um ponto importante explicitado é que migrar recursos computacionais para um ambiente
virtualizado tem pouco ou nenhum efeito no que diz respeito às suas vulnerabilidades e
ameaças intrínsecas. No entanto, o documento descreve que a virtualização pode ajudar
a reduzir a exploração dessas vulnerabilidades, embora tal tecnologia possa também abrir
brechas para outros tipos de ataque. Assim, antes de adotar uma solução de virtualização,
é necessário avaliar os riscos e benefícios envolvidos para determinar a melhor solução a
ser implantada.
O capítulo 4 trata das recomendações de segurança para os componentes de vir-
tualização, no que diz respeito à segurança do hypervisor e das máquinas hospedeiras.
Na discussão é destacado que, assim como na computação em nuvem, a virtualização
também é o resultado da junção de tecnologias, de modo que sua segurança depende da
segurança individual de cada um dos seus componentes, como hypervisors, máquinas
hospedeiras, máquinas hospedadas, aplicações, entre outros. O guia reforça ainda que
todas as considerações de segurança aplicadas a um SO que executa em um hardware
real também devem ser aplicadas ao guest, embora devam existir algumas considerações
a mais para esses SOs. Por exemplo, para executar em uma VM, um SO só pode utilizar
drivers de vídeo, som, teclado, mouse e rede que são específicas ao hypervisor, os quais
podem possuir bugs de programação ou de segurança que não estão presentes em drivers
genéricos.
Outro ponto importante destacado pelo documento é que, em muitos cenários de
virtualização, é permitido ao SO hospedado trocar informações com o SO hospedeiro,
por meio de discos ou diretórios compartilhados. Em caso de um SO estar infectado com
um malware, por exemplo, este pode se espalhar pelo diretório ou disco compartilhado.
Esse é um tipo de vulnerabilidade que é específica aos ambientes virtualizados e merece
atenção do administrador de rede.
 O documento discorre ainda sobre a segurança da infraestrutura virtualizada, re-
lacionada à simulação de mecanismos de armazenamento e rede. Muitos sistemas de
virtualização possuem dispositivos que fornecem controle de acesso ao hardware virtual,
particularmente os de armazenamento e rede, de modo que essa infraestrutura virtual é
tão importante quanto uma infraestrutura do ambiente físico. O documento recomenda
que a permissão de acesso a esses dispositivos virtuais deve ser concedida estritamente
aos dispositivos virtuais que irão utilizá-los. Algumas recomendações para os disposi-
tivos virtuais de rede também são fornecidas, como estabelecer políticas (processo este
semelhante ao realizado em redes físicas), realizar constantemente monitoramento, entre
outras tarefas.
O guia também alerta sobre a segurança na virtualização em desktops, estabele-
cendo que a principal diferença entre a virtualização em servidores e em desktops é a
capacidade de gerenciamento de imagens. No ambiente de servidores o gerenciamento
das imagens é usualmente limitado para administradores, enquanto que em um ambiente
de desktop, os usuários finais podem criar, modificar, duplicar e excluir imagens. Re-
comendações são feitas para organizações que desejam adotar esse tipo de virtualização,
delimitando que estas devem estar atentas, sob o prisma da segurança, em quais cenários
podem ser aplicadas tais soluções descentralizadas (de desktop) de virtualização e em
quais devem ser aplicadas as soluções centralizadas (de servidores).
Finalmente, o capítulo 5 apresenta cinco fases de planejamento e abordagem para
garantir uma utilização segura de mecanismos de virtualização:

1. Inicialização: inclui tarefas que uma organização deve realizar para projetar/pla-
nejar a solução de virtualização, identificando os requisitos, desenvolvendo uma
política de virtualização, identificando plataformas e aplicações que podem ser vir-
tualizadas, entre outras tarefas.

2. Planejamento e projeto: especificar as características técnicas da solução de vir-

tualização e os componentes relacionados. Isto inclui os métodos de autenticação e
mecanismos de cifração utilizados para proteger a comunicação.

3. Implementação: nesta fase, os equipamentos são configurados de acordo com os

requisitos de segurança estabelecidos, com um protótipo instalado e devidamente
testado, e então ativados e colocados em produção. A implementação inclui alterar
a configuração de outros controles de segurança e tecnologias, como eventos de log
de segurança, gerenciamento de rede e integração dos servidores de autenticação.

4. Operação e manutenção: esta fase inclui as tarefas de segurança que uma orga-
nização deve realizar constantemente, como revisão de logs, detecção de ataques,
entre outras operações de monitoramento.

5. Descarte: esta fase reforça as tarefas que ocorrem quando uma solução de vir-
tualização está sendo removida, incluindo preservação das informações de acordo
com os requisitos legais, sanitização adequada dos dados, e descarte apropriado dos
equipamentos.
 Para cada uma dessas fases do ciclo de vida de soluções de virtualização, são
definidos os cuidados e considerações que devem ser levados em consideração visando
garantir a segurança dos dados armazenados na infraestrutura virtualizada. O documento
ainda expõe que essas fases representam apenas uma abordagem geral para a utilização
segura do recurso de virtualização, e que existem diversas outras opções complementares
que podem ser utilizadas em cada uma das etapas definidas.

1.2.2.2. Guia de Virtualização PCI Security Standards Council

A PCI DSS (Payment Card Industry - Data Security Standard) é uma organização pro-
prietária de segurança da informação que presta serviços para empresas que realizam
operações com cartões de crédito nos Estados Unidos (Visa, Mastercard, American Ex-
press, entre outras). O objetivo dessa organização é garantir a segurança da informação
nas tecnologias que estas transações utilizam, dentre elas a virtualização. O guia [24] é
dividido em quatro partes, como apresenta a Tabela 1.5.

Tabela 1.5: Guia de segurança para virtualização PCI.

Seção Tópicos
1 - Introdução 1.1 – Público
1.2 – Uso do guia
2 – Visão geral de virtualização 2.1 - Virtualização: conceitos e classes
2.2 – Componentes da virtualização e escopo do guia
3 – Riscos para ambientes virtualizados 3.1 - Vulnerabilidades no ambiente físico aplicado em um ambiente vir-
tual
3.2 - Vulnerabilidades proporcionadas pelo hypervisor
3.3 - Aumento da complexidade dos sistemas virtualizados e redes
3.4 - Multifuncionalidade por sistema físico
3.5 - Mistura de VM’s de diferentes níveis de confiança
3.6 - Falta de separação de funções
3.7 - VM’s em estado de espera
3.8 - Imagens e snapshots
3.9 - Imaturidade das funções de monitoramento
3.10 - Vazamento de informações entre segmentos virtuais de rede
4 – Recomendações 4.1 – Recomendações gerais
4.2 – Recomendações para ambientes mistos
4.3 – Recomendações para ambientes de computação em nuvem
4.4 – Guia para avaliar riscos em ambientes virtuais

O público alvo do guia são os provedores de serviços que utilizam ou irão utilizar
as tecnologias de virtualização em seus ambientes. Assim, o documento provê um guia
suplementar para a utilização da virtualização, definindo alguns riscos de segurança e
fornecendo recomendações.
Após introduzir os conceitos gerais de virtualização e seus componentes, o guia
apresenta os riscos de segurança proporcionados pelo ambiente de virtualização. O pri-
meiro risco elencado é proveniente das vulnerabilidades no ambiente físico em que é
aplicada a virtualização, ressaltando que os sistemas virtuais estão sujeitos aos mesmos
ataques e vulnerabilidades que existem na infraestrutura física. Afinal, uma aplicação
que tem falhas em sua configuração ou é vulnerável a exploits ainda terá as mesmas fa-
lhas e vulnerabilidades quando for instalada uma implementação virtual. Por outro lado,
o hypervisor cria uma nova superfície de ataque, pois proporciona um único ponto de
acesso a todo ambiente virtual: se ele for comprometido, todas as VMs hospedadas na-
quele hypervisor também o serão. Por exemplo, tal vulnerabilidade pode ser causada por
uma simples má configuração, um erro muito comum. Outras vulnerabilidades desta-
cadas no documento são: isolamento deficiente, reduzido controle de acesso a recursos
físicos, falha em aplicar técnicas de endurecimento (hardening) da segurança e correções.
O documento conclui ainda que é crítico que o acesso ao hypervisor seja restrito somente
aos administradores da rede, e que tarefas como revisões e monitoramentos devem ser
realizadas constantemente como se estivessem sendo operadas em um ambiente físico.
Outro ponto destacado no guia refere-se ao aumento da complexidade dos siste-
mas devido à virtualização. Especificamente, as configurações virtuais podem ser clas-
sificadas como sistemas e redes. Por exemplo: VMs podem transmitir dados umas às
outras por meio do hypervisor, como também sobre uma conexão de rede virtual e/ou por
meio de aplicações de segurança de redes virtuais, como um firewall. Enquanto as con-
figurações virtuais oferecem diversos benefícios, essas abstrações adicionais de software
causam um aumento na complexidade total do sistema, exigindo um cuidado maior em
seu gerenciamento e na elaboração de políticas de segurança para as mesmas.
O documento apresenta ainda os riscos decorrentes da presença de mais de uma
função por sistema físico. Uma preocupação neste contexto é que, se uma função de um
ambiente virtual particular está comprometida, ela poderá comprometer outras funções
no mesmo ambiente físico. Um exemplo ilustrativo desse problema é um cenário em que
uma VM comprometida utiliza os mecanismos da camada virtual de comunicação para
lançar ataques contra outras VMs no mesmo host ou até contra o hypervisor. As tecno-
logias de virtualização devem ser capazes de mitigar alguns riscos caso sejam capazes de
reforçar a separação entre diferentes funções. Entretanto, ao menos até que tais meca-
nismos adquiram um nível de maturidade adequado, o risco associado com a alocação de
múltiplas funções ou componentes em um único sistema físico ainda deve ser conside-
rado. Outro ponto abordado são os riscos decorrentes da mistura de VMs com diferentes
níveis de confiança em um host em particular. O documento destaca que esse é um grande
desafios quando se planeja a virtualização de um sistema, pois identificar as configurações
apropriadas para a potencialmente grande variedade de tecnologias de virtualização é uma
tarefa complexa. Em especial, o risco de hospedar VMs de diferentes níveis de confiança
no mesmo host precisa ser cuidadosamente avaliado. Afinal, uma VM com baixo nível de
confiança tipicamente tem um nível baixo de segurança se comparada a uma VM de alto
nível de confiança. Portanto, estas VMs com baixo nível de confiança podem ser mais
fáceis de se comprometer, servindo como base para ataque a VMs com níveis superiores
de confiança.
A falta de separação de tarefas para as VMs é também abordado no guia como um
fator que requer atenção, dada a dificuldade de se definir papéis granulares (e.g., separação
da administração de rede e de servidor), e políticas de acesso em um sistema distribuído
e virtualizado. O risco advindo de uma definição inapropriada de papéis e políticas é
significante, pois o acesso impróprio ao hypervisor potencialmente fornece amplo acesso
a componentes importantes da infraestrutura.
O guia discorre também sobre as imagens de VM e snapshots. Por meio delas,
obtém-se uma maneira rápida de abortar ou restaurar sistemas virtuais em múltiplos hosts
em um período curto de tempo. Por outro lado, esta conveniência é acompanhada de
riscos de segurança, pois imagens e snapshots de VMs podem conter dados importan-
tes presentes no sistema no momento que a imagem foi criada (e.g., chaves criptográficas
presentes na memória), exigindo-se atenção especial na sua preparação e armazenamento.
Além do acesso a informações sensíveis, se as imagens não estiverem propriamente pro-
tegidas contra modificações, um atacante que ganhe acesso às mesmas pode inserir vulne-
rabilidades ou malwares na imagem. A imagem comprometida pode então ser replicada
para uso em todo o ambiente, resultando em um comprometimento rápido de todos os
hosts. Preocupações semelhantes aplicam-se também a VMs em estado de espera (i.e.,
que tiveram seu processamento temporariamente suspenso): embora não estejam ativas,
elas ainda podem abrigar dados importantes como credenciais de autenticação, chaves de
cifração, ou informações críticas de configuração, as quais devem ser protegidas contra
acesso indevido.
Também é dado destaque aos riscos decorrentes da imaturidade das soluções de
monitoramento atuais. Embora seja amplamente reconhecida a necessidade por ferra-
mentas para geração de logs e monitoramento em ambientes virtualizados, é igualmente
reconhecido que as ferramentas para realizar tais tarefas nesses ambientes não evoluí-
ram no passo adequado. Especificamente, se comparadas às ferramentas tradicionais para
monitorar uma rede física, as ferramentas para sistemas virtuais podem não fornecer o
mesmo nível de eficácia para as comunicações ou o fluxo de tráfego entre as VMs em
uma rede virtual, que ficam “invisíveis” aos sistemas de monitoramento. Portanto, o de-
senvolvimento de ferramentas especializadas de monitoramento e de geração de logs para
ambientes virtuais é uma necessidade bastante atual.
Finalmente, a última categoria de riscos abordada pelo documento refere-se ao
vazamento de informações entre segmentos virtuais da rede, fazendo com que tais dados
sejam levados para fora de locais conhecidos, contornando os controles que deveriam
ser a eles aplicados. O vazamento de informações no plano de controle ou plano de
gerenciamento pode ser explorado para permitir o vazamento de informações no plano de
dados, ou para influenciar rotas de rede para passar por controles de segurança de rede.
Após a discussão sobre riscos, o documento trata das recomendações gerais para
garantir a segurança de ambientes virtualizados. Um primeiro ponto levantado diz res-
peito à avaliação dos riscos associados com as tecnologias de virtualização, esclarecendo
que as entidades devem saber avaliar cuidadosamente os riscos de se virtualizar cada com-
ponente antes de selecionar e implementar uma solução de virtualização. Em seguida, o
guia trata da restrição de acesso físico aos hosts, discorrendo sobre os cuidados neces-
sários para evitar que um atacante ganhe acesso físico a um host que hospeda múltiplas
VMs. Similarmente a um ambiente físico, a defesa em profundidade é uma prática co-
mum para assegurar os dados e outros ativos. Outra recomendação é isolar as funções
de segurança, fazendo com que as funções de segurança implementadas na VM sigam o
mesmo processo de separação existente no ambiente físico. É especialmente recomen-
dado que este requisito seja implementado em ambientes virtualizados, pois esta medida
dificulta significantemente as chances de um atacante comprometer os componentes de
um sistema virtual. As recomendações passam então para uma avaliação adequada do hy-
pervisor, discutindo os cuidados necessários na configuração desse componente vital no
ambiente virtual, para o uso de ferramentas eficazes de monitoramento e geração de logs,
entre outros aspectos relevantes. O guia termina com medidas para avaliar os riscos no
ambiente virtualizado, processo que envolve identificar o ambiente e seus componentes
(incluindo hypervisors, redes, consoles de gerenciamento, etc.), mapear as vulnerabilida-
des existentes no sistema e definir as medidas cabíveis contra potenciais ameaças.

1.2.2.3. Guia Virtualização Red Hat

A Red Hat é uma empresa norte americana reconhecida por produtos voltados tanto para
empresas quanto para usuários finais, incluindo sua distribuição de GNU/Linux, o Red
Hat Linux e uma distribuição própria do OpenStack. Uma característica marcante da
empresa é a elaboração de guias e manuais visando o uso seguro de seus produtos [25].
Neste sentido, a Red Hat elaborou um guia de segurança em virtualização para dar suporte
a seus produtos de virtualização. A Tabela 1.6 apresenta a estrutura do documento, que é
discutido a seguir.

Tabela 1.6: Guia de segurança para virtualização Red Hat.

Seção Tópicos
1 - Introdução 1.1 – Ambiente virtualizado e não virtualizado
1.2 – Importância da segurança de virtualização
2 – Segurança do Host 2.1 - Importância da segurança do host
2.2 - Práticas recomendadas para a versão do Red Hat Enter-
prise Linux
2.3 – Práticas recomendadas para a segurança do host
3 – Segurança dos Guests 3.1 - Importância da segurança dos Guests
3.2 - Práticas de segurança recomendadas
4 – Segurança de rede em um ambiente virtualizado 4.1 – Visão geral
4.2 – Práticas recomendadas
4.3 – Segurança de conectividade
4.4 – Segurança de armazenamento

O guia inicia explicitando as oportunidades para a descoberta de vulnerabilidades

em ambientes virtualizados e não virtualizados, destacando a existência de novas vulne-
rabilidades nos primeiros que não estão presentes nos últimos. De maneira geral, a seção
de introdução destaca a importância de se assegurar a confiança nos ambientes virtualiza-
dos, tomando medidas de segurança tanto para os hosts como para os guests. A seção 1.2
destaca as seguintes considerações de segurança no ambiente virtualizado [25]:

• O host/hypervisor se torna o principal alvo. De fato, estes são os pontos centrais de

falha para os guests e seus dados.

• VMs podem interferir umas com as outras de maneiras indesejáveis.

• Recursos e serviços podem se tornar difíceis de se rastrear e manter. Assim, com

a rápida adoção dos sistemas virtualizados, torna-se necessário o uso de ferramen-
tas de gerenciamento de recursos cada vez melhores, incluindo capacidades como
lançamento de correções, monitoramento e facilidade de manutenção.

• Recursos como armazenamento podem estar espalhados por diversas máquinas, as

quais podem apresentar dependências entre elas. Isto pode tornar o sistema alta-
mente complexo, gerando uma enorme dificuldade de se gerenciar e manter.
 • A virtualização não remove qualquer dos riscos de segurança apresentados pelos
ambientes tradicionais: a pilha inteira da solução de virtualização, não só uma ca-
mada, deve estar segura.

O capítulo 2 trata da segurança do host, destacando que, ao se implantar as tecno-

logias de virtualização, a segurança do host deve ser um fator primordial, pois os guests
são tão seguros quanto seu host. São listada práticas recomendadas, tanto em cenários
genéricos (e.g., realização de auditorias, uso de mecanismos de controle de acesso, etc.)
como algumas específicas de nuvens públicas, dados que estas últimas estão expostas a
um número de riscos de segurança muito além da virtualização tradicional. Neste con-
texto, é discutido com certo destaque o isolamento entre o host e os guests, algo crucial
devido às ameaças proporcionadas pelo grande número de usuários da nuvem e os re-
quisitos de segurança sobre os dados, como confidencialidade e integridade, em toda a
infraestrutura de virtualização.
A terceira seção do guia, diz respeito à segurança dos guests. Enquanto a segu-
rança do host é crucial para garantir a segurança dos SOs executando no host, isto não
remove a necessidade de segurança individual para cada SO hospedado. Algumas das
práticas elencadas no documento incluem:

• Quando todo o gerenciamento do guest é realizado remotamente, deve-se garantir

que o gerenciamento do sistema seja realizado por canais seguros. Protocolos de
rede como SSH e SSL/TLS podem ser utilizados para este fim.

• Algumas tecnologias de virtualização utilizam agentes virtuais especiais ou drivers

para permitir alguns recursos avançados de virtualização. Assim, deve-se garantir
que essas aplicações sejam seguras.

• Em ambientes virtualizados existe um grande risco de dados relevantes serem aces-

sados de fora dos limites de proteção do SO hospedado. Esses dados devem ser
protegidos utilizando criptografia com nível de segurança adequado.

O capítulo 4 finaliza o guia tratando sobre a segurança de rede em um ambiente

virtualizado. A seção discute primeiramente a importância da rede nesses sistemas, pois
a rede é o único meio de acesso ao sistema em si e a suas aplicações e interfaces de geren-
ciamento. Portanto, é crucial garantir a disponibilidade dos canais de segurança do host
para os sistemas virtualizados e vice-versa. As práticas de segurança recomendadas têm
como objetivo assegurar a segurança dos canais de comunicação, incluindo a necessidade
de garantir que aplicações que estejam transferindo dados relevantes o façam por meio de
canais seguros, de se configurar firewalls adequadamente e de realizar testes e revisões de
segurança, políticas, entre outras.

1.2.2.4. Comparativo Guias de Virtualização

A Tabela 1.7 apresenta uma comparação com base em itens de segurança comuns entre
os guias de virtualização apresentados.
 Tabela 1.7: Comparativo guias virtualização: NIST, Red Hat e PCI.
Aspectos NIST Red Hat PCI
1 – Segurança do hypervisor (monitoramento/logs/configuração/restri- Abordado Abordado Abordado
ções de acesso administrativo)
2 – Segurança da infraestrutura virtual Abordado Abordado Abordado
3 - Mistura de VM’s de diferentes níveis de confiança no mesmo host n.a. n.a. Abordado
4 - Segurança em virtualização de servidores Abordado Abordado Abordado
5 - Segurança em virtualização de desktop Abordado n.a. Abordado
6 - Vazamento de informações entre segmentos virtuais de rede Abordado n.a. Abordado
7 - Imaturidade das funções de monitoramento n.a. n.a. Abordado
8 – Segurança na geração de imagens e snapshots n.a. n.a. Abordado
9 – Isolamento de Rede Abordado Abordado Abordado
10 – Proteção da Imagem da VM Abordado n.a. Abordado
11 – Segurança dos dados da VM Abordado Abordado Abordado
12 - Segurança das API’s do hypervisor n.a. n.a. n.a.

A análise da Tabela 1.7 mostra que o documento que aborda mais tópicos é o da
PCI, seguido pelo NIST, enquanto o mais básico dentre eles é o da Red Hat. Os pontos
críticos em comum abordados pelos guias são os de maior importância na virtualização,
como: segurança do hypervisor, segurança dos guests e segurança da infraestrutura vir-
tual. O hypervisor é destacado nos documentos como um componente fundamental na
virtualização, pois tem a função de coordenar as VMs e permitir acesso destas ao hard-
ware físico. Portanto, se esse componente for comprometido, a chance de todas as VMs
naquele host também o serem é grande. Segundo os três guias, os guests devem estar com
uma configuração semelhante a um SO físico, pois, além de compartilharem as mesmas
vulnerabilidades, ainda existem riscos provenientes do ambiente virtual. Portanto, dada
a complexidade adicionada pela camada de virtualização, deve ser dedicado cuidado es-
pecial para garantir a segurança das VMs. A infraestrutura virtual, outro ponto destacado
pelos três guias, envolve garantir a segurança da rede virtual, a qual deve estar com os
canais de comunicação seguros. Embora não sejam cobertos em detalhes em todos os
documentos, mas principalmente no guia da PCI, outros aspectos importantes para garan-
tir um alto nível de segurança são: imagens e snapshots; imaturidade das ferramentas de
geração de logs e monitoramento; e mistura de VMs com diferentes níveis de confiança
em um mesmo host.

1.3. Análise de segurança

Grande parte das tecnologias utilizadas para viabilizar a computação em nuvem como,
por exemplo, os mecanismos de virtualização, não foi desenvolvida especificamente para
o modelo de nuvens computacionais, mas foram adaptadas para sua utilização visando a
maximização dos recursos disponíveis [20]. Esta união de diferentes paradigmas, que
por si só já possuem vulnerabilidades intrínsecas, proporciona o surgimento de novas
vulnerabilidades decorrentes de sua associação. Assim, tal combinação pode ocasionar
novos pontos de vulnerabilidade que expõem os dados armazenados, comprometendo a
confiança no modelo de nuvem. Esta insegurança é um grande entrave para a adoção
da computação em nuvem por parte de grandes organizações e empresas, sendo tema de
diversas pesquisas que visam propor soluções adequadas para os problemas identificados.
Neste sentido, esta seção tem como objetivo fornecer uma análise de segurança do
modelo de computação em nuvem. Assim, a seguir são abordados tópicos fundamentais
para a análise, como a definição das fronteiras da nuvem, a elucidação de responsabilida-
des dos diferentes atores nesse ambiente, e a identificação de pontos-chave para coleta de
informações, para então realizar uma análise de segurança bem fundamentada. Especifi-
camente, a definição de fronteiras da nuvem estabelece o limite das operações (internas
e externas) realizadas na nuvem. O estabelecimento das responsabilidades dos atores é
importante para delimitar o que deve e não deve ser feito no ambiente de nuvem, tanto
para o provedor quanto para o consumidor do serviço, visando definir obrigações e pe-
nalidades. A identificação de pontos-chave estabelece os principais pontos inseguros no
ambiente de nuvem elencados pela literatura, permitindo a concepção de um arcabouço
de análise de segurança neste ambiente. Essa análise, juntamente como os guias da se-
ção 1.2, servirão como base para o estudo de caso do presente trabalho: a avaliação dos
aspectos de segurança da plataforma OpenStack versão Havana.

1.3.1. Fronteiras da nuvem

Os modelos de serviço da nuvem oferecem flexibilidade aos consumidores, propiciando
escolhas que se adaptam às necessidades dos clientes. No entanto, ao utilizar um mo-
delo computacional de larga escala que atende múltiplos consumidores ao mesmo tempo,
deve existir um balanço entre a segurança e as facilidades (e.g., baixo custo) proporciona-
das pelos mesmos. De fato, cada modelo de serviço possui características distintas, com
diferentes requisitos de segurança. Portanto, para cada modelo os riscos devem ser avali-
ados e mitigados de forma específica. Neste sentido, as fronteiras da nuvem delimitam as
responsabilidades do provedor e consumidor dos serviços de nuvem quanto à segurança
oferecida, elucidando até que ponto é obrigação do provedor garantir a segurança de um
determinado serviço, algo fundamental para permitir a utilização segura da nuvem. A
Figura 1.6 apresenta essa divisão de responsabilidades.

Figura 1.6: Divisão de responsabilidades entre usuários e provedores.

A Figura 1.6 possibilita uma visão das responsabilidades do consumidor e prove-
dor dos serviços de nuvem em cada um de seus modelos. Em um ambiente de SaaS, em
que o provedor fornece serviços por meio de aplicações hospedadas em uma infraestru-
tura de computação em nuvem, dado que tal infraestrutura é geralmente compartilhada
por uma larga escala de usuários na nuvem, o controle da segurança e o seu escopo são
negociados no contrato de serviço com o provedor [3], e a maior parte das responsabi-
lidades cabe ao provedor. Já no modelo de serviço PaaS, a responsabilidade é melhor
dividida entre o provedor e o consumidor, e a segurança deve ser avaliada por meio de
uma combinação de fatores, envolvendo a negociação do contrato de serviço e as ferra-
mentas disponibilizadas para que o consumidor gerencie a segurança dos seus dados. No
modelo IaaS, ainda há uma pequena parcela de responsabilidade na segurança por parte
do provedor, mas ela é menor do que no PaaS e SaaS, uma vez que o consumidor possui
maior controle sobre os recursos compartilhados. Assim, no modelo de serviço IaaS o
consumidor é o maior responsável por garantir e gerenciar a segurança do ambiente.
De um modo geral, quanto menor a pilha de serviços oferecida pelo provedor,
maior é a responsabilidade do consumidor por implementar e gerenciar a segurança dos
dados. Uma vez que as necessidades de segurança variam, a natureza e tipos de conhe-
cimentos necessários para avaliar e gerenciar os riscos também diferem de acordo com o
modelo de serviço escolhido [26]. Desta forma, o modelo IaaS exige um conhecimento
mais específico de segurança do consumidor do que o PaaS e o SaaS.

1.3.2. Responsabilidades x Consequências

Apesar das diferenças entre os os modelos de serviço de nuvem, em todos eles o prin-
cipal mecanismo de segurança é o contrato de nível de serviço (SLA). Em resumo, um
SLA é um contrato estabelecido entre o provedor e o consumidor de um determinado
serviço, projetado para criar um entendimento comum sobre qualidade de serviço, pri-
oridades, responsabilidades entre outros aspectos inerentes ao serviço ou produto forne-
cido [12, 27, 27–29] Nesse contrato são estabelecidas responsabilidades e eventuais pe-
nalidades a cada serviço prestado pelo provedor, de modo que o consumidor possa es-
tar ciente do nível, características e penalidades previstas. Destacam-se como principais
aspectos técnicos abordados os parâmetros de qualidade de serviço relacionados à segu-
rança, principalmente devido ao aumento da infraestrutura computacional da Internet e de
sua utilização como pilar para transações comerciais. De especial interesse no presente
documento é o chamado Sec-SLA, um subconjunto de um SLA que lida especificamente
com métricas relacionadas à segurança ao invés de métricas tradicionais de telecomuni-
cações como vazão, atraso, perda de pacotes e outras métricas similares [28]. A Figura
1.7 ilustra essa diferenciação entre os aspectos cobertos em um SLA convencional e um
Sec-SLA, mostrando exemplos de métricas específicas em cada tipo de SLA.

Figura 1.7: Sec-SLA x SLA Convencional. Adaptada de [28].

O surgimento de Sec-SLAs está diretamente relacionado às modificações nos pa-
radigmas tradicionais de computação distribuída trazidos com a nuvem, o que levou à
necessidade de reforço na segurança dos SLAs tradicionais [28]. Desta forma, um Sec-
SLA de computação em nuvem deve considerar tanto requisitos gerais provenientes do
modelo de nuvem quanto requisitos específicos propiciados pela necessidade de segu-
rança de cada consumidor, abrangendo ainda a variação no nível de segurança exigida
pelos mesmos. Cada requisito identificado deve possuir um mecanismo de segurança
equivalente, de modo que a nuvem satisfaça o acordo estabelecido no Sec-SLA e não
sofra penalidades. O objetivo geral dos mecanismos de segurança é manter três propri-
edades básicas: confidencialidade, integridade e disponibilidade. A nuvem deve possuir
mecanismos de segurança fundamentados nas necessidades básicas do modelo adotado,
como mecanismos de autenticação, autorização e de auditoria.

1.3.3. Identificação de pontos-chave

A seção 1.2 forneceu várias questões e recomendações de segurança para computação
em nuvem. Contudo, muitos observações dos guias são genéricas e necessitam de um
detalhamento maior para aplicar a soluções reais de nuvem computacional. Um aspecto
que não pode ser ignorado são os documentos sobre aspectos específicos de segurança,
muitos deles elaborados pelos mesmos órgãos que criaram os guias (e.g., NIST, CSA
e ENISA). Nesse sentido, essa seção complementa os guias já apresentados com docu-
mentos adicionais que se concentram em questões específicas de segurança das nuvens
computacionais. A Tabela 1.8 fornece uma relação das principais publicações produzi-
das pelas organizações mencionadas, e que tem servido de referência na implantação de
serviços de computação em nuvem nos últimos anos.

Tabela 1.8: Referência para pontos-chave em segurança para computação em nuvem.

Organização Publicação Ano Ref.
NIST The NIST definition of cloud computing 2011 [2]
NIST NIST Cloud Computing Reference Architecture 2011 [4]
NIST Guidelines on security and privacy in public cloud computing 2011 [18]
NIST NIST Cloud Computing Standards Roadmap 2011 [30]
NIST Guide to Security for Full Virtualization Technologies 2011 [22]
NIST NIST Cloud Computing Security Reference Architecture 2013 [31]
CSA Top Threats to Cloud Computing V1.0 2010 [32]
CSA Security Guidance for Critical Areas of Focus in Cloud Computing V3.0 2011 [3]
CSA The Notorious Nine Cloud Computing Top Threats in 2013 2013 [33]
CSA Cloud Computing Vulnerability Incidents: A Statistical Overview 2013 [34]
ENISA Cloud Computing Benefits, risks and recommendations for information security 2011 [1]
ENISA ENISA Threat Landscape 2013: Overview of current and emerging cyber-threats 2013 [35]
Gartner Assessing the security risks of cloud computing 2008 [36]
Gartner Gartner: Seven cloud-computing security risks 2008 [37]

Dentre os documentos relacionados na Tabela 1.8, pode-se destacar o documento

“The Notorious Nine Cloud Computing Top Threats in 2013” [33], produzido pela CSA
ao final do ano de 2013, como uma atualização da primeira versão do documento, “Top
Threats to Cloud Computing V1.0”, lançado em 2010 [32]. Esse documento tem por ob-
jetivo expor as principais preocupações da indústria ao considerar a adoção desse novo
paradigma tecnológico como (parte de) sua infraestrutura de TI. A versão atual do docu-
mento traz um ranking das nove principais ameaças de segurança no cenário de computa-
ção em nuvem, como mostrado e explicado resumidamente na Tabela 1.9.
 Tabela 1.9: As nove maiores ameaças de segurança em computação em nuvem - CSA.
Posição Ameaça
1 Violação de dados
2 Perda de dados
3 Captura de Serviços
4 APIs e interfaces não seguras
5 Negação de Serviços
6 Usuário autorizado malicioso
7 Abuso dos serviços de nuvem
8 Insuficiência por falta de diligência
9 Tecnologias de compartilhamento
Descrição
Informações sigilosas podem ser violadas por meio dos recursos com-
putacionais compartilhados da nuvem, viabilizando atividades de espi-
onagem industrial e outras
Dados podem ser perdidos na nuvem por diversas razões como ataques
de usuários maliciosos, equívoco do provedor de serviços de computa-
ção em nuvem, desastres naturais e outros
Serviços de computação em nuvem estão sujeitos a acesso não autori-
zado por meio da captura de credenciais, através de métodos de ataques
que utilizam phishing, fraudes ou exploração de vulnerabilidades de
software
APIs e Interfaces utilizadas para comunicação entre usuário e os ser-
viços de computação em nuvem, assim como para comunicação entre
diferentes serviços, estão sujeitas a problemas como interceptação, al-
teração e replicação de dados
O serviço de computação em nuvem é forçado a consumir grandes
quantidades de recursos (e.g., processador, memória, banda de rede,
etc.), diminuindo sua capacidade de resposta do provedor e impedindo
usuários acessarem seus dados e aplicações
Usuários com acesso aos recursos de computação em nuvem (e.g., fun-
cionário ou parceiro do provedor de serviços) podem reduzir a quali-
dade do serviço prestado por meio de ações mal intencionadas
Utilização dos serviços oferecidos pelo provedor de computação em nu-
vem para fins maliciosos, como ataques distribuídos de negação de ser-
viços, quebra de senhas e distribuição de malwares e softwares piratas
Organizações fazem uso de serviços de computação em nuvem sem pos-
suir o conhecimento necessário dos riscos envolvidos, aumentando, as-
sim, a vulnerabilidade de seus dados e aplicações
Nem todas as tecnologias empregadas no compartilhamento de recur-
sos, como infraestrutura computacional, plataformas e aplicações, fo-
ram projetadas para prover o isolamento necessário entre os múltiplos
usuários dos serviços prestados

Esse documento da CSA, ainda que descreva em alto nível as ameaças relaciona-
das, serve de guia para os atuais e futuros esforços despendidos na identificação e solução
dos principais problemas de segurança em computação em nuvem, viabilizando, assim, a
diminuição das barreiras para a implantação e a utilização deste novo modelo de serviço.
A CSA [3] estabelece ainda treze áreas críticas de segurança a serem considera-
das na implementação e implantação de serviços de computação em nuvem (definidas
na subseção 1.2.1.2, agrupando essas áreas em três grandes domínios de segurança que
abrangem o projeto, a gestão e a operação de serviços.
Outros trabalhos da Tabela 1.8 também tiveram grande importância na compre-
ensão dos aspectos principais da segurança em serviços de computação em nuvem, em
especial: [1, 36]. Estes documentos tiveram e têm papel fundamental no entendimento
dos riscos a serem considerados pelos consumidores de serviços de computação em nu-
vem ao selecionar um provedor.
Considerando aspectos de segurança de computação em nuvem como ameaças,
riscos e domínios de segurança, abordados na literatura mencionada, é possível construir
uma base sólida dos fundamentos e pontos chave de segurança a serem avaliados nas
soluções de TI que envolvam este modelo de serviço. Tomando como base estes funda-
mentos, aliados aos aspectos levantados nos guias da seção 1.2, é possível ainda propor
um arcabouço para análise de segurança destas soluções, conforme discutido a seguir.
1.3.4. Análise de segurança de uma nuvem computacional
Os desafios advindos da computação em nuvem têm sido enfrentados por meio de es-
forços provenientes dos ambientes corporativo e acadêmico, promovendo, muitas vezes,
a sinergia entre seus interesses. O documento da CSA [32] fornece uma base para a
TI corporativa na análise dos riscos envolvidos na contratação e utilização de serviços
de computação em nuvem, e pode servir de base para trabalhos de pesquisa importantes
na análise de segurança deste modelo de serviço (e.g., [38]). Esse trabalho propõe uma
análise da segurança em serviços de computação em nuvem baseada em três seções prin-
cipais: Categorias de segurança, segurança nos diferentes modelos de serviço e dimensões
de segurança. A Figura 1.8 ilustra o modelo organizacional proposto.

Figura 1.8: Organização do modelo de segurança em computação em nuvem. [38]

Esse modelo permite identificar os diferentes aspectos de segurança a serem anali-

sados em uma solução de computação em nuvem, e a organização proposta auxilia a busca
de referências para fundamentar essa análise. Assim, sugere-se uma divisão clara de res-
ponsabilidades sobre a resolução dos problemas de segurança na nuvem entre provedores
de serviço e seus consumidores. Porém, essa divisão está intimamente relacionada com o
modelo de serviço oferecido. A Figura 1.9 ilustra a dinâmica de divisão de responsabili-
dades sobre a segurança dos serviços de computação em nuvem de acordo com o modelo
de serviço prestado.
O modelo organizacional proposto sugere ainda a análise dos aspectos de segu-
rança associados aos diferentes modelos de serviços de computação em nuvem (IaaS,
PaaS e SaaS). Alguns trabalhos de pesquisa [39,40] exploram os diferentes riscos de segu-
rança intrínsecos à natureza de cada um dos modelos de serviços relacionados. Tomando
como base esses estudos, a Tabela 1.10 destaca diferentes requisitos a serem cumpridos
por provedores dos diferentes modelos de serviços de computação em nuvem.
 Figura 1.9: Divisão de responsabilidades sobre a segurança dos serviços de nuvem.

Tabela 1.10: Requisitos de segurança para os diferente modelos de serviços de computa-

ção em nuvem. Adaptada de [40]
Modelo de Serviço Requisitos de Segurança
SaaS - Privacidade em ambiente multiusuário
- Proteção contra a exposição de dados (incluindo dados remanescentes)
- Controle de acesso
- Proteção da comunicação
- Segurança de software
- Disponibilidade de serviço
PaaS - Controle de acesso
- Segurança de aplicações
- Segurança de dados (armazenados, em trânsito ou remanescentes)
- Segurança da comunicação
IaaS - Controle de acesso
- Segurança de dados (armazenados, em trânsito ou remanescentes)
- Segurança no controle de gerenciamento da nuvem
- Arquivos das instâncias virtuais seguras (e.g., imagem de VM)
- Proteção da camada de virtualização;
- Segurança da comunicação
- Segurança contra abusos dos serviços de computação em nuvem
- Segurança do Hardware
- Confiabilidade do hardware
- Proteção dos meios de comunicação

Finalmente, o modelo de análise de segurança apresentado introduz o estudo dos

aspectos de segurança da nuvem relacionados às diferentes dimensões de segurança en-
volvidas. A partir da organização das dimensões de segurança em três grupos (domínios
de segurança, riscos e ameaças), o modelo permite avaliar os principais aspectos de segu-
rança na nuvem segundo os guias e documentos de referência apresentados anteriormente.
A Figura 1.10 apresenta os documentos a serem utilizados como referência na análise dos
domínios de segurança, permitindo a definição de requisitos a serem cumpridos para ga-
rantir a qualidade e segurança dos serviços prestados.

1.4. Estudo de caso com o OpenStack Havana

O OpenStack é um projeto de computação em nuvem criado em julho de 2010, fruto de
uma iniciativa entre a RackSpace e a NASA. Essa iniciativa tem por objetivo oferecer um
 Figura 1.10: Documentos de referência para análise das dimensões de segurança.

serviço de computação em nuvem que possa ser executado em hardware de servidores

padrão. Sua primeira versão oficial, o Austin, surgiu quatro meses depois. Ademais, com
o intuito de realizar atualizações e correções em períodos curtos de tempo, a partir da
quinta versão do OpenStack ficou estabelecido o período de seis meses [15] entre uma
atualização e outra.
O projeto OpenStack é uma coleção de componentes de código aberto utilizados
por organizações para configurar e gerenciar nuvens de computação. Esse projeto visa
construir uma comunidade open source com pesquisadores, desenvolvedores e empresas,
que compartilham um objetivo comum: criar uma nuvem simples de ser implementada,
altamente escalável e com vários recursos avançados [41, 42]. Assim, todo o código do
OpenStack é aberto aos desenvolvedores, sendo que qualquer pessoa pode utilizar ou
submeter modificações ao projeto, bem como construir aplicativos sobre a plataforma.

1.4.1. Componentes
Na versão Havana, a plataforma OpenStack é composta em seu repositório padrão por
nove componentes, listados na Tabela 1.11 juntamente com uma breve descrição.

Tabela 1.11: Componentes do OpenStack Havana e suas funções.

Serviço Codinome Descrição
Armazenamento de obje- Swift Permite armazenar e recuperar arquivos que não estejam montados em um diretó-
tos rio. É um sistema de armazenamento a longo prazo para os dados permanentes ou
estáticos.
Painel de Controle / dash- Horizon Fornece uma interface web modular para todos os componentes do OpenStack, tor-
board nando possível seu gerenciamento direto a partir de um navegador web comum.
Gerenciamento de nuvem Nova É o software que controla a infraestrutura de IaaS, alocando ou liberando recursos
computacionais, como rede, autenticação, entre outros.
Serviço de imagens Glance Fornece um catálogo e repositório para imagens de disco virtuais. Essas imagens são
manipuladas pelo Nova, responsável pelo gerenciamento das mesmas.
Armazenamento de blocos Cinder Fornece um armazenamento de blocos para as máquinas virtuais.
Serviço de rede Neutron Provisiona serviços de rede para os componentes que são gerenciados pelo Nova.
Especificamente, permite que os usuários criem e anexem interfaces de rede virtuais
(vNICs) a esses componentes.
Serviço de identidade Keystone Fornece autenticação e autorização para todos os serviços do OpenStack.
Contabilidade Ceilometer Monitora e mede o OpenStack para efetuar cobranças, medição de desempenho, es-
calabilidade e geração de estatísticas.
Orquestração Heat Orquestra a nuvem, permitindo o gerenciamento dos demais componentes por meio
de uma interface única
 O Ceilometer e o Heat são dois componentes novos introduzidos na passagem da
versão Grizzly (a penúltima) para a Havana (a mais atual no momento da escrita deste do-
cumento). O Ceilometer surgiu da necessidade de uma infraestrutura centralizada para a
coleta, monitoramento e medição dos dados na nuvem, de modo que não existam dois ou
mais agentes coletando os mesmos dados na estrutura e que cada um deles possa realizar
medições/monitoramentos de forma independente. Com isto, os componentes têm apenas
um ponto centralizado de entrega de dados, facilitando serviços de rastreamento e audito-
ria. Já o Heat é um componente que surgiu da necessidade de agilidade no gerenciamento
de um coletivo de instâncias na nuvem. Por exemplo, se um usuário deseja criar ou al-
terar uma topologia ou configurar um grupo de instâncias, o Heat fornece uma interface
simples e ágil para essa tarefa. Para dar uma visão geral da arquitetura do OpenStack Ha-
vana, a Figura 1.11 ilustra como todos componentes da Tabela 1.11 estão nela dispostos.
A mesma figura também apresenta a hierarquia e conexões do OpenStack em alto nível,
sendo que no nível de APIs existem muito mais conexões [43]. Ressalta-se aqui que, ape-
sar do suporte a SSL/TLS na APIs, em alguns componentes esse recurso de segurança é
desligado na sua configuração padrão.

Figura 1.11: Visão geral da Arquitetura do OpenStack Havana.

Além da inclusão do Ceilometer e o Heat no projeto, diversas melhorias e cor-

reções foram realizadas nos demais componentes com o surgimento da versão Havana.
Dentre estas melhorias, destacam-se [44]:

• Novos recursos focados nas aplicações, como clusters globais para o armazena-
mento de objetos e qualidade de serviço por meio de drivers de armazenamento em
bloco para garantir o desempenho das aplicações.

• Melhorias na experiência do usuário com a nuvem. Especificamente, o módulo

Horizon recebeu novas funções, como capacidade de medição de estatísticas de
uso, gerenciamento de VPNs (Virtual Private Networks) e firewalls.

• No Nova, foram adicionadas novas possibilidades para realizar a migração sem

interrupção (live) de instâncias para servidores maiores ou menores.

• Melhorias no Keystone, com a adição de recursos como cifração fim a fim em todos
os drivers de armazenamento em bloco (provendo maior segurança dos dados em
repouso), suporte a SSL (Secure Socket Layer) em todas APIs e o armazenamento
dos dados de autorização e credenciais em backends separados.

1.4.2. Ciclo de vida de VMs

O modelo de serviço da plataforma OpenStack tem por objetivo fornecer uma IaaS para o
consumidor, de modo que o fornecimento dessa infraestrutura envolve a disponibilização
de diversos componentes, como serviços de rede, armazenamento, processamento, entre
outros. Neste sentido, conhecer todas as etapas para a criação de uma máquina virtual é
vital para entender o funcionamento da plataforma. Esse conjunto de etapas que engloba
todos os estados em que uma máquina virtual pode estar em qualquer momento é comu-
mente chamado de “ciclo de vida” [45–47]. Em conjunto com a definição de ciclo de
vida de uma máquina virtual, vem a necessidade do gerenciamento do ciclo de vida, cuja
tarefa é uma das principais preocupações relacionadas à segurança dentro de um ambiente
virtualizado e altamente compartilhado.
No OpenStack, o ciclo de vida de uma máquina virtual é orquestrado pelo seu
principal componente da arquitetura, o OpenStack Nova. O Nova controla toda a infra-
estrutura da nuvem, nas etapas de criação, utilização e exclusão de uma máquina virtual.
A Figura 1.12 ilustra as principais etapas do ciclo de vida de VMs no OpenStack e os
estados que elas podem assumir, os quais são detalhados a seguir:

1. Criação da VM: esta etapa envolve três estágios distintos para a disponibilização da
VM para o usuário:

(a) Preparação: envolve toda a preparação e conbfiguração da VM. Esse processo

normalmente envolve o upload de uma determinada imagem para o módulo
Glance, o que pode ser feito por meio da interface web disponibilizada pelo
Horizon ou diretamente via API do Glance (i.e., via interface de linha de co-
mando – Command Line Interface, ou CLI), embora esta última forma exija
um conhecimento um pouco maior da API disponibilizada pela plataforma.
 Figura 1.12: Etapas do ciclo de vida de uma VM.

(b) Clonagem do template: a imagem enviada no estágio anterior é armazenada

como um template no Glance, a partir do qual podem ser criadas as demais
VMs. O Nova então pode realizar requisições dos templates armazenados para
personalizar a VM.
(c) Inicialização da VM: nesta fase, a VM é entregue ao usuário de acordo com
a configuração requisitada. A requisição do usuário em si pode ser feita por
meio de uma mensagem enviada do Horizon ao Nova, ou diretamente pela
API do Nova por meio de linha de comando.
2. Utilização da VM: esta etapa envolve dois estágios em que a VM pode estar durante
sua operação:
(a) Execução da VM: o usuário executa diretamente sua instância via SSH.
(b) Migração da VM: a VM pode estar sendo migrada de uma instância para uma
outra mais conveniente. A migração de VMs pode ocorrer tanto sem que
haja uma interrupção no serviço fornecido ao usuário (live) ou enquanto a
instância não estiver em uso (off-line). O comando para migração de VMs é
disponibilizado no OpenStack por meio de uma API.
3. Desligamento da VM: após as etapas de criação e utilização da VM, é necessário
desligar a instância que não está mais sendo utilizada pelo usuário. Esta etapa
envolve dois estágios:
 (a) Desligamento da máquina: uma vez que a instância não está mais em uso
pelo usuário (i.e., após o usuário desligar a VM, por exemplo por meio de um
comando via SSH), é necessário que a plataforma desligue adequadamente a
instância, salvando a configuração do ambiente.
(b) Armazenamento do estado da VM: uma vez que a instância é desligada e os
recursos são desalocados, é necessário salvar o estado da VM. O resultdo deste
processo de salvamento é a criação de um snapshot, que armazena o estado de
um sistema em um determinado período de tempo para uso posterior.

4. Exclusão da VM: uma vez que o usuário não deseja mais utilizar a VM, é necessário
que a plataforma realize a exclusão segura dos dados do usuário. Nesta etapa,
o usuário faz uma requisição via Horizon ou API para o Nova, para que a VM
instanciada seja excluída.

Com relação à segurança no gerenciamento do ciclo de vida na plataforma, todas

as etapas envolvidas, desde a criação até a exclusão da VM, podem ser executas via API,
utilizando uma comunicação cifrada por HTTPS, ou diretamente via SSH. Esta ação pode
ser realizada tanto pelo usuário como por um gerente de rede.

1.4.3. APIs e interfaces de comunicação

Todos os serviços oferecidos pelo OpenStack podem ser configurados e manipulados por
meio de APIs. Embora os serviços sejam instalados separadamente, as APIs trabalham
conjuntamente. O OpenStack Havana disponibiliza as seguintes APIs [43]:

• Block Storage Service API: para gerenciamento de volumes e snapshots. Também

é chamada genericamente de “serviços do Cinder”.

• Compute API: utilizada para inicializar VMs a partir de um snapshot ou de imagens

armazenadas em volumes persistentes.

• Identity Service API: lida com tokens de autenticação que permitem o acesso à
Compute API.

• Image Service API: permite a criação, edição e exclusão de metadados associados

a uma imagem, bem como o compartilhamento das imagens entre usuários.

• Networking API: provê os serviços de redes virtuais entre dispositivos gerenciados

pelo nó de computação do OpenStack, bem como a criação de redes e sub-redes,
alocação de blocos de IP, e demais configurações das redes do Neutron.

• Object Storage API: utilizada para gerenciar contas, containers e objetos do sis-
tema Object Storage.

• Orchestration API: provê uma linguagem modelo para orquestração dos serviços
do OpenStack.

• Telemetry API: gerencia as operações de telemetria da nuvem (e.g., faturamento,

benchmarking, escalabilidade e fins estatísticos).
 Um usuário primeiramente se autentica por meio do serviço de identidade (i.e.,
Keystone). Após sua autenticação, ele então pode criar e gerenciar recursos na nuvem
OpenStack. Um exemplo é a inicialização de instâncias de imagens e a associação de
metadados por meio da Compute API, acessados através de ferramentas de linha de co-
mando ou clientes REST acessíveis via navegador web, que executam as chamadas para
APIs por meio de mensagens HTTP(S).

1.4.4. Funcionamento
Sendo o projeto OpenStack prover uma plataforma IaaS, existem diversas maneiras de se
utilizar os serviços de rede, armazenamento, máquinas virtuais, entre outros, oferecidos
pela plataforma. Para facilitar o gerenciamento dessa miríade de possibilidades, para cada
serviço disponibilizado existe um processo específico. Assim, com o objetivo de ilustrar
o funcionamento do OpenStack tendo em vista analisar sua segurança, apresenta-se aqui
um caso de uso simples da plataforma: a criação de uma VM para o usuário, caso que é
explorado mais detalhadamente na subseção 1.4.5.
Conforme discutido na seção 1.4.2, a criação de uma VM é feita após o envio de
uma requisição do usuário, por meio do Horizon ou CLI. Do ponto de vista da segurança,
neste processo é essencial o serviço de identidade na nuvem, pois, caso contrário, pode
ocorrer o acesso indevido às VMs armazenadas. O Keystone é responsável por permitir
ou negar qual usuário deve ter acesso a um determinado serviço, fazendo isso com base
no papel atribuído a seu tenant. Mais precisamente, um tenant é definido pelo projeto
gerenciado por um determinado cliente da nuvem, criando um container que agrupa e
isola recursos e/ou objetos de identidade que pertencem aos usuários daquele projeto.
Assim, delimita-se o escopo de um usuário a uma porção de recursos pertinentes a seu
papel dentro dos projetos dos quais ele faz parte. A Figura 1.13 ilustra a requisição de
um serviço na nuvem (disponibilização de uma VM para um usuário), com o objetivo
de esclarecer como ocorre o processo de requisições e respostas entre o usuário e os
componentes, para que o usuário obtenha acesso aos serviços que está requisitando.
O processo de requisição para criação de uma VM (Figura 1.13) envolve cinco
componentes do OpenStack. Tudo se inicia com o usuário enviando suas credenciais para
o Keystone, que o autentica e em seguida gera e envia um token temporário para o usuário.
Com o token, o usuário envia para o Keystone a requisição dos serviços e endpoints que
deseja utilizar. Após a analisar a requisição, o Keystone retorna os serviços e endpoints
permitidos, de acordo com o projeto do qual o usuário faz parte. Assim, o usuário recebe a
permissão para requisitar a criação de uma instância ao Nova por meio da apresentação de
tal token. Para saber se pode ou não satisfazer à requisição de um usuário qualquer, o Nova
autentica o token apresentado pelo usuário junto ao Keystone. Caso o token seja válido,
o Nova então requisita uma imagem ao Glance, que repete o processo de validação junto
ao Keystone, e em seguida, envia o token em uma requisição ao Neutron para a conexão
de uma interface virtual na rede. O Neutron repete o processo de autenticação junto ao
Keystone e retorna a mensagem de sucesso ao Nova, que a replica para o usuário.
Observa-se neste processo que o elemento central para acessar os componentes do
OpenStack é o token temporário gerado para o usuário, o qual é autenticado a cada vez que
um novo componente se envolve no processo de requisição do serviço. Tal fato permite
 Figura 1.13: Solicitação de uma VM no OpenStack Havana.

exemplificar a importância do Keystone para que seja garantida a segurança dos diversos
processos envolvidos no uso da nuvem, indo de ações simples como uma requisição de
criação de VM, até processo mais complexos como configuração de uma infraestrutura
completa de máquinas ligadas por uma rede virtual.

1.4.5. Demonstração prática (coleta, análise e testes)

Para realizar a análise prática da segurança da plataforma OpenStack Havana, foi utili-
zado o caso de uso de criação de uma VM. A análise consiste em monitorar os dados
gerados pela comunicação entre os componentes observados (APIs), coletando os dados
da autenticação do usuário no Keystone e a requisição de uma imagem de VM no Glance,
verificando-se a segurança da comunicação interna na plataforma. Para realizar o moni-
toramento, é utilizada uma ferramenta de análise de tráfego, o Wireshark. Para os testes,
a VM é criada utilizando a API do Nova, que disponibiliza diversas funções para realizar
as operações de gerenciamento do ciclo de vida das VMs. Uma operação básica para a
criação de uma VM consiste nas seguintes etapas:

• Adição da VM em um grupo de segurança: consiste em verificar quais grupos de

segurança estão disponíveis na plataforma, criando ou personalizando um se neces-
sário. Os grupos de segurança permitem associar regras de rede para um grupo de
VMs ligadas a um projeto ou tenant, proporcionando maneiras de impor restrições
ao acesso das VMs. Essas restrições podem ser, por exemplo, a habilitação dos
protocolos SSH e ICMP.
• Associação de um par de chaves: criar/associar um par de chaves criptográficas à
VM.
• Verificação dos tipos e imagens das VMs: as VMs no OpenStack podem ser de
diferentes tipos, variando em termos de poder computacional de acordo com a ne-
 cessidade do usuário. Uma vez determinado o tipo da VM, é necessário determinar
a imagem a ser utilizada. Por padrão, o OpenStack disponibiliza a imagem Cirros
para a criação de VMs.

• Criação da VM: uma vez que as etapas anteriores tenham sido concluídas, a cria-
ção da VM é feita via API do Nova, passando como argumento o tipo da VM, o
identificador da imagem, o par de chaves e o grupo de segurança.

A Figura 1.14 apresenta o resultado da criação da VM, mostrando as propriedades

da VM criada. Cabe notar que, quando o usuário utiliza o Horizon para a criação de VMs,
nem todas essas informações são mostradas a ele na interface.

Figura 1.14: Exemplo de criação de uma VM.

Após a criação da VM, o resultado do tráfego gerado pela comunicação entre os

componentes foi analisado via Wireshark (Figura 1.15). No estudo de caso em questão, o
monitoramento foi realizada nos componentes Keystone e Glance, que estão por padrão
nas portas :5000 e :9292, respectivamente. A princípio, o único filtro aplicado no Wi-
reshark foi pelo IP e porta, listando somente os pacotes destinados aos componentes. Foi
verificado que, por padrão, a plataforma utiliza o protocolo HTTP para a comunicação in-
terna entre os componentes, algo preocupante dado que o HTTP não um protocolo seguro
para o tráfego de dados sensíveis como credenciais do usuário e da imagem requisitada
no Glance. Desta forma, com o filtro utilizado no Wireshark foi possível obter a própria
senha utilizada pelo usuário.
 Figura 1.15: Autenticação Keystone - Glance

Como observado na Figura 1.15, o OpenStack não utiliza por padrão canais se-
guros de comunicação entre os seus componentes, e, com isso, é possível capturar as
informações de qualquer usuário na rede (desde que, obviamente, se tenha acesso ao trá-
fego interno da nuvem). Neste caso, o pacote se trata de uma autenticação da token do
usuário do Glance para o Keystone. O mesmo fato se repete nos pacotes filtrados da
comunicação com o Keystone, conforme observado na Figura 1.16. O mesmo resultado
pode ser observado na requisição de autenticação do Glance para o Keystone, que envia a
senha “semsenha” para o endereço do Keystone (192.168.0.100:5000/v2.0). Essa troca de
informações para autenticação também pode ser observada em pacotes de diversos com-
ponentes, comprovando que a plataforma não utiliza canais seguros de comunicação por
padrão entre os nós da plataforma.

Figura 1.16: Autenticação Glance - Keystone.

Em conclusão, toda requisição e confirmação de autenticação é realizada com o

nome de usuário e sua senha sendo enviada às claras, permitindo que qualquer usuário
interno malicioso possa capturar credenciais de outros usuários na nuvem. Entretanto,
a plataforma fornece suporte à conexão segura entre os componentes, tanto para cifrar
os metadados das imagens no Glance, quanto a cifração da comunicação na plataforma.
A cifração dos metadados da imagem obscurece o acesso às informações da imagem, o
que é realizado na API do Glance por meio da utilização da biblioteca AES ( Advan-
ced Encryption Standard [48]) para cifrar a localização dos metadados da imagem. O
OpenStack Havana permite a utilização do protocolo HTTPS com os protocolos cripto-
gráficos SSL/TLS, de modo a verificar a autenticidade das chaves por meio de certificados
digitais. Entretanto, embora as ferramentas para realizar comunicação interna de forma
segura estejam disponíveis, essa opção não é configurada por padrão na plataforma: para
configurar o uso de SSL na plataforma é necessário utilizar a API do Keystone, com o co-
mando “keystone-manage ssl setup”. É importante observar que os certificados utilizados
por padrão são gerados pelo próprio Keystone, algo razoável para efeito de testes (como
é o caso do presente estudo). No entanto, para maior segurança no caso de uma nuvem de
produção é fortemente recomendado utilizar certificados externos para validar os tokens.
Um comentário final com relação à segurança do OpenStack refere-se à forma de
armazenamento das senhas dos usuários na plataforma. Especificamente, as senhas são
armazenadas pelo Keystone usando simplesmente a função de hash SHA-2 [49] com uma
saída de 384 bits, conforme mostra o trecho de código da Figura 1.17 (extraído de [50]).

Figura 1.17: Trecho de código que mostra como são tratadas as senhas no Keystone.

O problema com essa estratégia é que, caso esses hashes sejam descobertos (e.g.,
por meio da sua captura na rede, pelo roubo do banco de dados, ou mesmo pelo acesso
usuários internos maliciosos), a tarefa de descobrir a senha correspondente se resume a
usar tabelas pré-construídas com senhas comuns [51–53]. Isto permitiria ao atacante não
apenas se passar pelo usuário no OpenStack, mas também possivelmente reusar a senha
obtida em outros contextos, já que muitos usuários reutilizam a mesma senha para acessar
diferentes serviços. Para resolver esse problema, recomenda-se o uso de esquemas de
derivação de chaves, tais como PBKDF2 [52] ou Lyra [53]. O benefício de tais esquemas
é que eles exigem que a senha seja combinada com uma sequência de bits aleatórios
(denominada salt), o que impede o uso de tabelas pré-construídas, além de permitir a
parametrização o custo computacional de verificação das senhas (e, assim, o custo de
ataques de força bruta).

1.5. Considerações
A fundamentação sobre guias de segurança relacionados a nuvens computacionais e VMs
(seção 1.2) indica que já há um bom nível de conhecimento sobre aspectos de segurança
essenciais para se levar em consideração no contexto de computação em nuvem. Contudo,
a diversidade de serviços de nuvem, aliada aos diferentes modelos de serviço (SaaS/Pa-
aS/IaaS) e abordagens de implantação (Privada/Pública/Comunitária/Híbrida), tornam a
execução da análise de segurança nesses ambiente uma tarefa complexa. Deste modo,
é necessário avaliar cada solução de computação em nuvem de modo a identificar quais
questões de segurança são oriundas dos elementos que a compõem (e.g., vulnerabilida-
des do Xen) e quais são diretamente relacionadas à solução de computação. As questões
de segurança oriundas de elementos não específicos da nuvem tipicamente já apresentam
alguma abordagem de tratamento, antes mesmo de sua incorporação à nuvem (vide se-
ção 1.3). Entretanto, as questões intrínsecas da nuvem exigem o início de novos estudos
de segurança. Nesse sentido, o presente texto (seção 1.4) exemplificou este aspecto atra-
vés da análise do tráfego de controle no OpenStack (mais especificamente envolvendo o
componentes Nova e Keystone) e sobre o armazenamento das senhas do Keystone com
uma abordagem problemática.
Uma consideração importante oriunda deste estudo é que o OpenStack vem evo-
luindo constantemente, tanto em termos de recursos como aspectos de segurança. Esta
preocupação com segurança e suas implicações devem nortear tanto o desenvolvimento
de soluções de nuvens como a sua implantação. Entretanto, é essencial que os clientes da
nuvem preocupem-se não apenas com a escolha e verificação de recursos de segurança em
nuvem, mas também em habilitá-los e usá-los corretamente quando incorporem a nuvem
em seus ambientes.

Agradecimentos
Agradecemos o Centro de Inovação, Ericsson Telecomunicações S.A., Brasil pelo suporte
e financiamento do projeto correlacionado ao tema desse artigo.
Este trabalho foi parcialmente financiado pelo Conselho Nacional de Desenvolvimento
Científico e Tecnológico (CNPq) por meio da bolsa de produtividade 305350/2013-7.
Agradecemos a Universidade do Estado de Santa Catarina (UDESC) pelo suporte e finan-
ciamento do projeto correlacionado ao tema deste trabalho.

Referências
[1] ENISA, Cloud Computing: Benefits, Risks and Recommendations for Information
Security. ENISA Agency, European Network and Information Security, 2011.

[2] P. M. Mell and T. Grance, “SP 800-145. the NIST definition of cloud computing,”
National Institute of Standards & Technology, Gaithersburg, MD, United States,
Tech. Rep., 2011.

[3] CSA, “Security guidance for critical areas of focus in cloud computing
v3.0,” Cloud Security Alliance, Tech. Rep., 2011. [Online]. Available: https:
//downloads.cloudsecurityalliance.org/initiatives/guidance/csaguide.v3.0.pdf

[4] F. Liu, J. Tong, J. Mao, R. Bohn, J. Messina, L. Badger, and D. Leaf, NIST Cloud
Computing Reference Architecture: Recommendations of the National Institute of
Standards and Technology (Special Publication 500-292). USA: CreateSpace In-
dependent Publishing Platform, 2012.
 [5] G. J. Popek and R. P. Goldberg, “Formal requirements for virtualizable third
generation architectures,” Commun. ACM, vol. 17, no. 7, p. 412–421, jul 1974.
[Online]. Available: http://doi.acm.org/10.1145/361011.361073

[6] A. Marcon Jr, M. Laurenano, A. Santin, and C. Maziero, “Aspectos de segurança

e privacidade em ambientes de computação em nuvem.” in MiniCursos do SBSeg
2010. Porto Alegre: Sociedade Brasileira de Computação, 2010, pp. 53–102.

[7] R. Slipetskyy, Security Issues in OpenStack. Norwegian University of Science and

Technology, Department of Telematics, 2011.

[8] R. C. d. Castro, L. Domingos, G. Luz, C. Pereira, and M. Gomes, “Gestão de vulne-

rabilidades em cloud computing: Um cenário da nuvem pública,” in Anais Infobrasil
2012, Ceará, 2012, p. 6.

[9] P. Cigoj, “Security aspects of OpenStack - department of knowledge ...” Master

Degree, osef Stefan International Postgraduate School, Ljubljana, 2012.

[10] D. Orlando, “Modelos de serviço de computação em nuvem, parte 1: Infraestrutura

como serviço,” apr 2011. [Online]. Available: http://www.ibm.com/developerworks/
br/cloud/library/cl-cloudservices1iaas/

[11] N. Gonzalez, C. Miers, F. Redígolo, M. Simplicio, T. Carvalho, M. Näslund, and

M. Pourzandi, “A taxonomy model for cloud computing services,” vol. 1. No-
ordwijkerhout, The Netherlands: Thomson Reuters Conference Proceedings, may
2011, pp. 56—65.

[12] G. P. Koslovski, P. V.-B. Primet, and A. S. Charão, “VXDL: virtual resources and
interconnection networks description language,” in Networks for Grid Applications,
ser. Lecture Notes of the Institute for Computer Sciences, Social Informatics and
Telecommunications Engineering, P. V.-B. Primet, T. Kudoh, and J. Mambretti, Eds.
Springer Berlin Heidelberg, jan 2009, no. 2, pp. 138–154.

[13] M. Behrendt, B. Glasner, P. Kopp, R. Dieckmann, G. Breiter, S. Pappe, H. Kre-

ger, and A. Arsanji, “Introduction and architecture overview IBM cloud computing
reference architecture 2.0,” IBM, Technical Report, 2012.

[14] Oracle, “Cloud reference architecture,” White Paper, nov 2012.

[Online]. Available: http://www.oracle.com/technetwork/topics/entarch/
oracle-wp-cloud-ref-arch-1883533.pdf

[15] OpenStack, “OpenStack open source cloud computing software,” 2014. [Online].
Available: https://www.openstack.org/

[16] S. Bykov, A. Geller, G. Kliot, J. R. Larus, R. Pandya, and J. Thelin, “Orleans:

Cloud computing for everyone,” in Proceedings of the 2Nd ACM Symposium
on Cloud Computing, ser. SOCC ’11. New York, NY, USA: ACM, 2011, p.
16:1–16:14. [Online]. Available: http://doi.acm.org/10.1145/2038916.2038932
[17] L. Badger, D. Bernstein, R. Bohn, F. d. Vaulx, M. Hogan, J. Mao, J. Messina,
K. Mills, A. Sokol, J. Tong, F. Whiteside, and D. Leaf, “High-priority requirements
to further USG agency cloud computing adoption,” NIST, Gaithersburg, MD, United
States, Techncical Report SP 500-293, nov 2011.
[18] W. Jansen and T. Grance, “SP 800-144. guidelines on security and privacy in public
cloud computing,” National Institute of Standards & Technology, Gaithersburg, MD,
United States, Tech. Rep., 2011.
[19] A. Corradi, M. Fanelli, and L. Foschini, “VM consolidation: A real case based on
OpenStack cloud,” Future Generation Comp. Syst., vol. 32, pp. 118–127, 2014.
[20] N. Gonzalez, C. Miers, F. Redígolo, T. Carvalho, M. Simplicio, M. Näslund, and
M. Pourzandi, “A quantitative analysis of current security concerns and solutions
for cloud computing - extended version,” Journal of Cloud Computing: Advances,
Systems and Applications (JoCCASA), vol. 1, 2012.
[21] A. Ibrahim, J. Hamlyn-Harris, J. Grundy, and M. Almorsy, “CloudSec: a security
monitoring appliance for virtual machines in the IaaS cloud model,” in 5th Interna-
tional Conference on Network and System Security (NSS), sep 2011, pp. 113–120.
[22] K. A. Scarfone, M. P. Souppaya, and P. Hoffman, “SP 800-125. guide to security
for full virtualization technologies,” National Institute of Standards & Technology,
Gaithersburg, MD, United States, Tech. Rep., 2011.
[23] F. Anhalt, G. Koslovski, and P. V.-B. Primet, “Specifying and Provisioning Virtual
Infrastructures with HIPerNET,” Int. J. Network Management, vol. 20, no. 3, pp.
129–148, 2010.
[24] P. DSS, “PCI data security standard (PCI DSS) v2.0,” jun 2011. [Online]. Available:
https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf
[25] Red Hat, “Red hat enterprise linux, virtualization guide,” 2013. [Online]. Avai-
lable: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_
Linux/5/html-single/Virtualization/index.html
[26] S. Bates, “Security thoughts: Understanding risk management approaches
in the cloud computing service model,” nov 2010. [Online]. Available:
http://shaynebates.blogspot.com.br/2010/11/understanding-risk-management.html
[27] R. R. Righi, F. R. Pelissari, and C. Westphall, “Sec-SLA: especificação e validação
de métricas para acordos de níveis de serviço orientados à segurança,” in Anais
CESEG 2004, 2004, pp. 199–210.
[28] S. d. Chaves, C. Westphall, and F. Lamin, “SLA perspective in security management
for cloud computing,” in 2010 Sixth International Conference on Networking and
Services (ICNS), mar 2010, pp. 212–217.
[29] M. Torkashvan and H. Haghighi, “CSLAM: a framework for cloud service level
agreement management based on WSLA,” in 2012 Sixth International Symposium
on Telecommunications (IST), nov 2012, pp. 577–585.
[30] M. D. Hogan, F. Liu, A. Sokol, and T. Jin, “NIST-SP 500-291, NIST cloud
computing standards roadmap,” 2011. [Online]. Available: http://www.nist.gov/
customcf/get_pdf.cfm?pub_id=909024

[31] W. W. Armour, J. Kickenson, J. Koilpillai, and M. A. Salim, “NIST SP 500-299:

Cloud computing security reference architecture,” may 2013. [Online]. Available:
http://bigdatawg.nist.gov/_uploadfiles/M0007_v1_3376532289.pdfâĂŐ

[32] R. Los, D. Gray, D. Shackleford, and B. Sullivan, “Top threats to cloud

computing : Cloud security alliance,” mar 2010. [Online]. Available: https:
//cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf

[33] R. Los, D. Shackleford, and B. Sullivan, “The notorious nine

cloud computing top threats in 2013,” feb 2013. [Online]. Avai-
lable: https://downloads.cloudsecurityalliance.org/initiatives/top_threats/The_
Notorious_Nine_Cloud_Computing_Top_Threats_in_2013.pdf

[34] R. Ko and S. S. G. Lee, “Cloud computing vulnerability incidents: A

statistical overview,” mar 2013. [Online]. Available: https://cloudsecurityalliance.
org/download/cloud-computing-vulnerability-incidents-a-statistical-overview/

[35] L. Marinos, “ENISA threat landscape 2013 - overview of current and

emerging cyber-threats — ENISA,” dec 2013. [Online]. Available: http:
//www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/
enisa-threat-landscape-2013-overview-of-current-and-emerging-cyber-threats

[36] J. Heiser and M. Nicolett, “Assessing the security risks of cloud computing,”
Gartner Group, Technical Report G00157782, jun 2008. [Online]. Available:
https://www.gartner.com/doc/685308/assessing-security-risks-cloud-computing

[37] G. Group, “Gartner: Seven cloud-computing security risks | security central

- InfoWorld,” jun 2008. [Online]. Available: http://www.infoworld.com/d/
security-central/gartner-seven-cloud-computing-security-risks-853

[38] M. T. Khorshed, A. S. Ali, and S. A. Wasimi, “A survey on gaps, threat remediation

challenges and some thoughts for proactive attack detection in cloud computing,”
Future Gener. Comput. Syst., vol. 28, no. 6, p. 833–851, jun 2012. [Online].
Available: http://dx.doi.org/10.1016/j.future.2012.01.006

[39] S. Subashini and V. Kavitha, “A survey on security issues in service delivery models
of cloud computing,” J. Netw. Comput. Appl., vol. 34, no. 1, p. 1–11, jan 2011.
[Online]. Available: http://dx.doi.org/10.1016/j.jnca.2010.07.006

[40] D. Zissis and D. Lekkas, “Addressing cloud computing security issues,” Future
Gener. Comput. Syst., vol. 28, no. 3, p. 583–592, mar 2012. [Online]. Available:
http://dx.doi.org/10.1016/j.future.2010.12.006

[41] X. Wen, G. Gu, Q. Li, Y. Gao, and X. Zhang, “Comparison of open-source cloud
management platforms: OpenStack and OpenNebula,” in 2012 9th International
Conference on Fuzzy Systems and Knowledge Discovery, may 2012, pp. 2457–2461.
 [42] K. Jackson, Openstack Cloud Computing Cookbook. Packt Publishing Ltd, 2012.

[43] OpenStack, “OpenStack docs: APIs,” 2013. [Online]. Available: http:

//api.openstack.org/

[44] R. Pystin, “Mirantis/swift-encrypt,” 2013. [Online]. Available: https://github.com/

Mirantis/swift-encrypt

[45] C. Cruzen, G. Cartee, and J. Wade, “Utilizing virtual missions to achieve real ope-
rations savings,” in 2011 IEEE Aerospace Conference, mar 2011, pp. 1–8.

[46] S. Al-Haj and E. Al-Shaer, “A formal approach for virtual machine migration plan-
ning,” in 2013 9th International Conference on Network and Service Management
(CNSM), oct 2013, pp. 51–58.

[47] M. Simonin, E. Feller, A. Orgerie, Y. Jegou, and C. Morin, “An autonomic and
scalable management system for private clouds,” in 2013 13th IEEE/ACM Interna-
tional Symposium on Cluster, Cloud and Grid Computing (CCGrid), may 2013, pp.
198–199.

[48] NIST, Federal Information Processing Standard (FIPS 197) – Advanced Encryption
Standard (AES), National Institute of Standards and Technology, November 2001,
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.

[49] NIST, Federal Information Processing Standard (FIPS 180-4) – Secure Hash Stan-
dard, National Institute of Standards and Technology, U.S. Department of Com-
merce, March 2012.

[50] OPENSTACK, “Cliente keystone: código fonte,” https://github.com/openstack/

python-keystoneclient/blob/master/keystoneclient/middleware/memcache_crypt.
py, 2014, Último acesso em 14/03/2014.

[51] J. Kelsey, B. Schneier, C. Hall, and D. Wagner, “Secure applications of low-entropy

keys,” in Proc. of the 1st International Workshop on Information Security, ser. ISW
’97. London, UK, UK: Springer-Verlag, 1998, pp. 121–134.

[52] B. Kaliski, PKCS#5: Password-Based Cryptography Specification Version 2.0,

2000, http://www.ietf.org/rfc/rfc2898.txt.

[53] L. C. Almeida, E. R. Andrade, P. S. L. M. Barreto, and M. A. Simplicio Jr,

“Lyra: password-based key derivation with tunable memory and processing costs,”
Journal of Cryptographic Engineering, pp. 1–15, 2014, see also http://lyra-kdf.net/.
[Online]. Available: http://dx.doi.org/10.1007/s13389-013-0063-5

View publication stats