TEC - CSA - Guia de Segurança para Cloud Computing

Guia de Segurança
para
Áreas Críticas Focado

em
Computação em Nuvem V2.1

Preparado por
Cloud Security Alliance

Dezembro 2009
Traduzido por
Cloud Security Alliance – Brazilian Chapter

Junho 2010
Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem V2.1
Introdução
O guia aqui fornecido é a segunda versão do documento da Cloud Security Alliance,

“Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem”
(“Security Guidance for Critical Areas of Focus in Cloud Computing”), o qual foi
originalmente lançado em Abril de 2009. Os locais de armazenamento para estes
documentos são:
http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (Versão em inglês

deste documento)
http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf (Versão 1)
Partindo da primeira versão do nosso guia, foi tomada a decisão de separar o guia
básico dos domínios principais de pesquisa. Cada domínio de pesquisa está sendo
lançado em seu próprio white paper. Estes white papers e uas agendasde lançamento
estão hospedadas em:
http://www.cloudsecurityalliance.org/guidance/domains/
Em outra mudança da nossa primeira versão, o Domínio 3: Legislação e o Domínio

4: Eletronic Discovery foram combinados em um único. Adicionalmente, o Domínio 6:
Gerenciamento do Ciclo de Vida da Informação e o Domínio 14: Armazenamento
foram combinados em um único domínio, renomeado para Gerenciamento do Ciclo de
Vida de Dados. Isto causou uma reordenação de domínios (13 na nova versão).
© 2009 Cloud Security Alliance. Todos os direitos reservados.

Você pode baixar, armazenar, exibir no seu computador, visualizar, imprimir
e referenciar ao Guia da Cloud Security Alliance em
www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf desde que: (a) o guia seja
usado exclusivamente para fim pessoal e não comercial; (b) o guia não seja modificado
ou alterado de qualquer maneira; (c) o guia não seja redistribuído; e (d) a marca
registrada, copyright ou outros avisos não sejam removidos. Você pode citar partes do
guia conforme permitido pela Fair Use provisions of the United States Copyright
Act, desde que você atribua ao Guia da Cloud Security Alliance Versão 2.1 (2009).
Copyright © 2009 Cloud Security Alliance 3

Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem V2.1
Sumário
Introdução ..................................................................................................................... 3
Prefácio .......................................................................................................................... 5
Carta dos Editores ......................................................................................................... 9
Nota Editorial Sobre Risco: Decidindo O Que, Quando e Como Mover Para a
Nuvem .......................................................................................................................... 11
Seção I. Arquitetura da Nuvem .................................................................................. 14
Domínio 1: Framework da Arquitetura de Computação em Nuvem ........................... 15
Seção II. Governança na Nuvem................................................................................. 33
Domínio 2: Governança e Gestão de Risco Corporativo............................................. 34
Domínio 3: Aspectos Legais e Electronic Discovery .................................................. 39
Domínio 4: Conformidade e Auditoria ....................................................................... 41
Domínio 5: Gerenciamento do Ciclo de Vida das Informações .................................. 44
Domínio 6: Portabilidade e Interoperabilidade ........................................................... 50
Seção III. Operando na Nuvem................................................................................... 53
Domínio 7: Segurança Tradicional, Continuidade de Negócios e Recuperação de
Desastres ................................................................................................................... 54
Domínio 8: Operações e Data center ......................................................................... 56
Domínio 9: Resposta a Incidente, Notificação e Remediação ..................................... 59
Domínio 10: Segurança de Aplicações ....................................................................... 62
Domínio 11: Criptografia e Gerenciamento de Chaves............................................... 65
Domínio 12: Gerenciamento de Identidade e Acesso. ................................................ 68
Domínio 13 - Virtualização ....................................................................................... 73
Referencias .................................................................................................................. 75

Prefácio
Bem vindo à segunda versão do “Guia de Segurança para Áreas Critícas Focado
em Computação em Nuvem” da Cloud Security Alliance. Como a marcha da Cloud
Security Alliance continua, temos novas oportunidades e novos desafios de segurança.
Nós humildemente esperamos fornecer a vocês instruções e inspiração para suportar as
necessidades do seu negócio enquanto gerenciam novos riscos.
Embora a Cloud Security Alliance seja mais conhecida por este guia, ao longo dos
próximos meses você verá uma ampla variedade de atividades, incluíndo capítulos
internacionais, parcerias, novas pesquisas e atividades orientadas a promover nossa
missão. Você pode acompanhar nossas atividades em www.cloudsecurityalliance.org.
O caminho para proteger a Computação em Nuvem é de fato longo e exige a participação

de um amplo conjunto de interessados e uma base global. Entretanto, devemos
orgulhosamente reconhecer o progresso que estamos vendo: novas soluções de
segurança na nuvem estão aparecendo regularmente, organizações estão utilizando nosso
guia para contratar provedores de serviços de nuvem e uma discussão saudável sobre
conformidade e questões de confiança surgiu pelo mundo. A vitória mais importante que
conquistamos é que profissionais de segurança estão vigorosamente engajados em
proteger o futuro, mais do que simplesmente proteger o presente.
Por favor, continue engajado neste assunto, trabalhando conosco para completarmos essa
importante missão.
Atenciosamente,
Jerry Archer
Alan Boehme
Dave Cullinane
Paul Kurtz
Nils Puhlmann
Jim Reavis
Diretoria Cloud Security Alliance

Agradecimentos
Editores
Glenn Brunette Rich Mogull
Colaboradores
Adrian Seccombe Jeffrey Ritter
Alex Hutton Jens Laundrup
Alexander Meisel Jesus Luna Garcia
Alexander Windel Jim Arlen
Anish Mohammed Jim Hietala
Anthony Licciardi Joe Cupano
Anton Chuvakin Joe McDonald
Aradhna Chetal Joe Stein
Arthur J. Hedge III Joe Wallace
Beau Monday Joel Weise
Beth Cohen John Arnold
Bikram Barman Jon Callas
Brian O’Higgins Joseph Stein
Carlo Espiritu Justin Foster
Christofer Hoff Kathleen Lossau
Colin Watson Karen Worstell
David Jackson Lee Newcombe
David Lingenfelter Luis Morales
David Mortman M S Prasad
David Sherry Michael Johnson
David Tyson Michael Reiter
Dennis Hurst Michael Sutton
Don Blumenthal Mike Kavis
Dov Yoran Nadeem Bukhari
Erick Dahan Pam Fusco
Erik Peterson Patrick Sullivan
Ernie Hayden Peter Gregory
Francoise Gilbert Peter McLaughlin
Geir Arild Engh-Hellesvik Philip Cox
Georg Hess Ralph Broom
Gerhard Eschelbeck Randolph Barr
Girish Bhat Rich Mogull
Glenn Brunette Richard Austin
Greg Kane Richard Zhao
Greg Tipps Sarabjeet Chugh
Hadass Harel Scott Giordano
James Tiller Scott Matsumoto
Jean Pawluk Scott Morrison
Jeff Reich Sean Catlett
Jeff Spivey Sergio Loureiro

Shail Khiyara Vern Williams
Shawn Chaput Warren Axelrod
Sitaraman Lakshminarayanan Wayne Pauley
Srijith K. Nair Werner Streitberger
Subra Kumaraswamy Wing Ko
Tajeshwar Singh Yvonne Wilson
Tanya Forsheit

Agradecimentos da versão Brasileira
Diretoria Cloud Security Alliance – Brazilian Chapter

Leonardo Goldim Jordan M. Bonagura
Anchises Moraes Olympio Rennó Ribeiro Jr
Jaime Orts Y Lugo
Editores
Hernan Armbruster
Thiago Bordini
Colaboradores
Alessandro Trombini Leonardo Goldim
Alexandre Pupo Luís Felipe Féres Santos
Anchises Moraes Marcelo Carvalho
Denyson Machado Marcelo Pinheiro
Dino Amaral Masaishi Yoshikawa
Eder Alvares Pereira de Souza Miguel Macedo
Filipe Villar Milton Ferreira
Gabriel Negreira Barbosa Nelson Novaes Neto
Gilberto Sudré Olympio Rennó Ribeiro Jr
Guilherme Bitencourt Rafael B. Brinhosa
Guilherme Ostrock Raphael Sanches
Hernan Armbruster Reginaldo Sarraf
Jaime Orts Y Lugo Ricardo Makino
Jimmy Cury Roney Médice
Jordan M. Bonagura Uélinton Santos
Julio Graziano Pontes
Carta dos Editores
É difícil de acreditar que há curtos sete meses, nós juntamos um grupo diversificado de
profissionais de todos os cantos do setor de tecnologia para publicar o primeiro “Guia de
Segurança para Áreas Críticas em Computação em Nuvem”. Desde seu lançamento, essa
publicação tem excedido nossas expectativas continuamente ao ajudar organizações ao redor do
mundo na tomada de decisão quanto a se, quando e como elas devem adotar os serviços e a
tecnologia de Computação em Nuvem. Mas ao longo destes sete meses nosso conhecimento e a
tecnologia de Computação em Nuvem têm evoluído em um grau surpreendente. Essa segunda
versão tem o objetivo de fornecer novos conhecimentos e uma maior profundidade para apoiar
essas decisões desafiadoras.
Adotar Computação em Nuvem é uma decisão complexa envolvendo inúmeros fatores. Nossa
expectativa é que o guia contido neste trabalho ajude você a entender melhor quais perguntas
fazer, as melhores práticas recomendadas e as armadilhas a serem evitadas. Através do nosso foco
nas questões centrais da segurança em Computação em Nuvem, nós tentamos trazer uma maior
transparência para um panorama complicado, que é frequentemente preenchido com informações
incompletas. Nosso foco nos 15 domínios originais (agora consolidados em 13) serve para
especificar e contextualizar a discussão sobre segurança em Computação em Nuvem: habilitando-
nos a ir além das generalizações brutas e entregar recomendações mais objetivas e perspicazes.
Em nossa jornada, temos sido procurados por uma crescente lista de organizações do setor,
corporações e profissionais que acreditam na nossa missão de desenvolver e promover as
melhores práticas para garantir a segurança na Computação em Nuvem. Suas perspectivas e
conhecimentos tem sido essenciais na criação de um trabalho sensato e imparcial que continua
servindo como uma excelente base sobre a qual podemos continuar trabalhando.
Computação em Nuvem é ainda um panorama em rápida evolução, que nos obriga a permanecer
atualizados ou ficamos para trás. Nesta publicação da segunda versão do nosso guia, nós partimos
da experiência e especialização coletiva da nossa grande e diversificada comunidade de
voluntários para criar um trabalho mais completo com maiores detalhes e precisão. Ainda assim,
nós não devemos estar satisfeitos. Como profissionais de segurança tem feito por anos, nós
devemos continuar a evoluir nossos processos, métodos e técnicas à luz das oportunidades que a
Computação em Nuvem trás para nosso setor. Essa evolução é essencial para nosso sucesso a
longo prazo conforme encontramos novos modos para aperfeiçoar a eficácia e eficiência da nossa
capacidade de execução de monitoramento de segurança.
Computação em nuvem não é necessariamente mais ou menos segura que o seu ambiente atual.
Assim como qualquer nova tecnologia, ela cria novos riscos e novas oportunidades. Em alguns
casos, migrar para nuvem prevê uma oportunidade de reestruturas aplicações antigas e
infraestrutura para adequar ou exceder requisitos modernos de segurança. Às vezes o risco de
mover dados confidenciais e aplicações para uma infraestrutura emergente pode estar além da sua
tolerância. Nosso objetivo neste guia não é dizer exatamente o que, onde ou como você deve
migrar para nuvem, mas fornecer a você recomendações práticas e questões básicas para fazer
uma migração mais segura possível, em seus termos.
Finalmente, em nome da Cloud Security Alliance e do Editorial Working Group, nós gostaríamos
de agradecer a cada voluntário por todo seu tempo e esforço que foi colocado no
desenvolvimento deste novo documento. Estávamos sempre insipirados pela dedicação das
equipes em ampliar e aperfeiçoar suas respectivas áreas e acreditamos que seus esforços

adicionaram um valor significativo a este trabalho. Este documento não seria o que é sem suas
contribuições.
Como sempre, estamos ansiosos para ouvir seu feedback sobre essa atualização do guia. Se você
achou este guia útil ou gostaria de ver ele melhorado, por favor, considere associar-se a Cloud
Security Alliance como um membro ou colaborador.
Glenn Brunette
Rich Mogull
Editores

Nota Editorial Sobre Risco: Decidindo O Que, Quando e Como Mover
Para a Nuvem
Ao longo deste guia nós fazemos extensas recomendações na redução do risco quando você adota
Computação em Nuvem, mas nem todas as recomendações são necessárias ou realistas para todos
os cenários. Como compilamos informações de diferentes grupos de trabalhos durante o processo
de edição, rapidamente percebemos que simplesmente não havia espaço suficiente para fornecer
recomendações completamente diferenciadas em todos os cenários possíveis de risco. Assim
como uma aplicação crítica pode ser tão importante para migrar para um provedor de nuvem
pública, pode ter pouca ou nenhuma razão para aplicar controles de segurança ao se migrar dados
de baixo valor para um armazenamento baseado na nuvem.
Com tantas opções diferentes de implantação de nuvem – incluindo o modelo de serviço SPI
(Software as a Service, Platform as a Service ou Infrastructure as a Service, explicados com
maiores detalhes no Domínio 1), implantações públicas vs privadas, hospedagem interna vs
externa e várias permutações híbridas – nenhuma lista de controles de segurança pode cobrir
todas as cirscunstâncias. Como em qualquer área da segurança, organizações devem adotar uma
abordagem baseada em riscos para migrar para nuvem e selecionar as opções de segurança. A
seguir está um framework simples para ajudar a avaliar inicialmente os riscos e informar as
decisões de segurança.
Este processo não é um framework completo de avaliação de riscos, nem uma metodologia para
determinar todos os requisitos de segurança. É um método rápido para avaliar sua tolerância em
mover um ativo para vários modelos de Computação em Nuvem.
Identificar o Ativo Para Implantação na Nuvem
Simplesmente, os ativos suportados pela nuvem se dividem em duas categorias:
1. Dados
2. Aplicações/Funções/Processamento
Estamos movendo informações para nuvem ou operações/processamento (de funções

parciais ou até aplicações completas).
Com a Computação em Nuvem nossos dados e aplicações não precisam estar no mesmo local e
podemos até mudar apenas partes de funções para a nuvem. Por exemplo, podemos hospedar
nossa aplicação e dados no nosso próprio data center, enquanto ainda terceirizamos uma parte de
sua funcionalidade para a nuvem através do modelo Platform as a Service.
O primeiro passo ao avaliar um risco na nuvem é determinar exatamente que dado ou função está
sendo considerado mover para a nuvem. Isto deve incluir potenciais utilizações do ativo uma vez
que este seja migrado para a nuvem para considerar o aumento do escopo. Volumes de dados e de
transações são frequentemente maiores que o esperado.
Avalie o Ativo
O próximo passo é determinar qual importância do dado ou função para a organização. Você não
precisa realizar uma avaliação detalhada a menos que sua organização possua um processo para

isso, mas você precisa de, pelo menos, uma avaliação do quão sensível o ativo é e do quão
importante a aplicação/função/processo é.
Para cada ativo, faça as perguntas abaixo:
1. Como poderíamos ser prejudicados se o ativo se tornou amplamente público e distribuído?

2. Como poderíamos ser prejudicados se um funcionário do provedor de serviço de nuvem
acessou o ativo?
3. Como poderíamos ser prejudicados se o processo ou função foi manipulado por terceiros?
4. Como poderíamos ser prejudicados se o processo ou função falhar ao fornecer os resultados
esperados?
5. Como poderíamos ser prejudicados se a informação/dado for alterada inesperadamente?
6. Como poderíamos ser prejudicados se o ativo estiver indisponível por um período de tempo?
Essecialmente estamos analisando os requisitos de confidencialidade, integridade e

disponibilidade para o ativo e como estes são afetados se manuseados na nuvem. É muito similar
a analisar um projeto de terceirização, exceto que com Computação em Nuvem temos uma gama
maior de opções de implantação, incluíndo modelos internos.
Mapear o Ativo ao Modelo de Implantação em Potencial
Agora nós devemos entender a importância do ativo. Nosso próximo passo é determinar qual
modelo de implantação será mais confortável adotar. Antes de começarmos a buscar por
potenciais provedores, nós devemos saber se nós podemos aceitar os riscos implícitos aos vários
modelos (privado, público, comunitário ou hibrido) e aos modos de hospedagem (interno, externo
ou combinado).
Para cada ativo, determine se você está disposto a aceitar as seguintes opções:
1. Público.
2. Privado, interno/dentro da organização.
3. Privado, externo (incluindo infraestrutura dedicada ou compartilhada).
4. Comunitário, levando em conta o local da hospedagem, provedor de serviço em
potencial e identificar outros membros da comunidade.
5. Hibrido. Para avaliar efetivamente o potencial de implantação hibrida, você deve ter
em mente pelo menos uma estrutura aproximada de onde os componentes, funções e
dados serão hospedados.
Neste estágio você deve ter uma boa idéia do seu nível de conforto na transição para a nuvem e
qual modelo e local de implantação adequados para seus requisitos de segurança e riscos.
Avalie Potenciais Modelos de Serviços na Nuvem e Provedores
Neste passo o foco é no grau de controle que você terá em cada camada de SPI para implementar
qualquer gerenciamento de riscos necessário. Se você estiver avaliando uma oferta específica,
neste ponto você pode mudar para uma avaliação de riscos completa.
Seu foco será no nível de controle que você tem que implementar para mitigar os riscos nas
diferentes camadas de SPI. Se você já possui requisitos especificos (ex.: para manipulação de
dados regulamentados) você pode incluir nesta avaliação.

Esboçar o Potencial Fluxo de Dados
Se você está analisando uma opção específica de implementação, mapeie o fluxo de dados entre
sua organização, o serviço de nuvem e qualquer cliente/outros pontos de acesso. Enquanto a
maioria destes passos for de alto nível, antes de tomar a decisão final é absolutamente necessário
entender se e como os dados podem se mover para dentro e fora da nuvem.
Se você ainda tem que decidir em uma oferta em especial, você vai querer esboçar um rascunho
do fluxo de dados para qualquer opção da sua lista de aceitação. Isto é para garantir que quando
você tomar sua decisão final, você será capaz de identificar pontos de exposição aos riscos.
Conclusões
Agora você deve entender a importância do que você está considerando mover para a nuvem, sua
tolerância ao risco (pelo menos em alto nível) e que combinações de modelos de implantações e
serviços são aceitáveis. Você também terá uma idéia aproximada dos potenciais pontos de
exposição das informações e operações sensíveis.
Este conjunto deve dar a você contexto suficiente para avaliar qualquer outro controle de
segurança neste guia. Para ativos menos valiosos você não precisa ter o mesmo nível de controles
de segurança e pode pular muitas das recomendações – como inspeções locais, facilidade de
descoberta e esquemas complexos de criptografia. Um ativo valioso e regulamentado implicará
em requisitos de auditoria e retenção de dados. Para outros ativos valiosos e não sujeitos a
restrições de regulamentações, você pode focar mais em controles técnicos de segurança.
Devido ao nosso espaço limitado, bem como a profundidade a quantidade de material para cobrir,
este documento contém listas extensivas de recomendações de segurança. Nem todas as
implantações de nuvem precisam de todos os controles de risco e segurança possíveis.
Empregando um pouco de tempo antecipadamente em uma avaliação da sua tolerância ao risco e
potenciais exposições proporcionará o contexto que você precisa para escolher a melhor opção
para sua organização e implementação.
Colaboradores da Versão Brasileira: Alexandre Pupo, Leonardo Goldim

Seção I. Arquitetura da Nuvem

Domínio 1: Framework da Arquitetura de Computação em Nuvem
Este domínio, o Framework da Arquitetura de Computação em Nuvem, descreve um framework
conceitual para o resto do guia da Cloud Security Alliance. O conteúdo deste domínio foca na
descrição de Computação em Nuvem, que é especificamente adaptada para a perspectiva única
dos profissionais de segurança e de redes. As próximas três seções definem esta perspectiva em
termos de:
 A terminologia usada por todo o guia, para fornecer um vocabulário consistente.

 Os requisitos de arquitetura e desafios para proteger as aplicações e serviços em nuvem.
 Um modelo referencial que descreve a taxonomia dos serviços e arquiteturas em nuvem.
A seção final deste domínio fornece uma introdução resumida para cada um dos demais domínios
do guia.
Entender o framework arquitetônico descrito neste domínio é um primeiro passo importante na

compreensão do restante do guia da Cloud Security Alliance. O framework define muito dos
conceitos e termos usados por todos os outros domínios.
O que é Computação em Nuvem?
Computação em nuvem (“Nuvem”) é um termo em evolução que descreve o desenvolvimento de

muitas das tecnologias e abordagens existentes em computação para algo distinto. A nuvem
separa as aplicações e os recursos de informação de sua infraestrutura básica, e os mecanismos
utilizados para entregá-los.
A nuvem realça a colaboração, agilidade, escalabilidade e disponibilidade, e oferece o potencial

para redução de custos através de computação eficiente e otimizada.
Mais especificamente, a nuvem descreve o uso de uma coleção de serviços, aplicações,

informação e infraestrutura composta por pools de recursos computacionais, de rede, de
informação e de armazenamento. Estes componentes podem ser rapidamente organizados,
provisionados, implementados, desativados, e escalados para cima ou para baixo, provendo um
modelo de alocação e consumo baseado na demanda de recursos.
Sob a perspectiva da arquitetura, há muita confusão em torno de como a nuvem é tanto similar e
diferente dos modelos computacionais existentes, e como estas similaridades e diferenças
impactam nas abordagens organizacionais, operacionais, e tecnológicas para as práticas de
segurança da informação e de redes.
Existem muitas definições atualmente que tentam endereçar a nuvem da perspectiva de

acadêmicos, arquitetos, engenheiros, desenvolvedores, gerentes e consumidores. Este documento
foca na definição que é especificamente desenhada para a perspectiva única dos profissionais de
segurança de TI (Tecnologia da Infomação) e redes.
As chaves para entender como a arquitetura da nuvem impacta a arquitetura de segurança são
baseados em uma nomenclatura comum e concisa, associada com uma taxonomia consistente de
ofertas de como os serviços e arquiteturas de serviços na nuvem podem ser interpretadas,
mapeadas para um modelo de controles compensatórios de segurança e operacionais, frameworks
de análise e gerenciamento de risco, e de acordo com padrões de conformidade.

O que compreende a Computação em Nuvem?
A versão anterior do guia da Cloud Security Alliance utilizava definições que foram escritas antes
da publicação de trabalho dos cientistas do U.S. National Institute of Standards and Technology
(NIST) e seus esforços em definir Computação em Nuvem.
A publicação do NIST é geralmente bem aceita, e nós a escolhemos para estarmos alinhados com
a definição de trabalho do NIST para Computação em Nuvem (versão 15 no momento em que
este texto foi criado) trazendo assim coerência e consenso no uso de uma linguagem comum, de
forma que podemos focar em casos de uso e não em aspectos semânticos.
É importante notar que este guia tem a intenção de ser usado amplamente e aplicável para
organizações globalmente. Enquanto o NIST é uma entidade governamental americana, a seleção
deste modelo de referência não deveria ser interpretada de forma a sugerir a exclusão de outros
pontos de vista ou de outras regiões geográficas.
O NIST define Computação em Nuvem descrevendo cinco características essenciais, três modelos
de serviço e quatro modelos de implementação. Eles estão sumarizados visualmente na figura 1 e
explicados em detalhes a seguir.
Figura 1 – Modelo Visual de Definição de Computação em Nuvem do NIST

Características Essenciais de Computação em Nuvem
Os serviços na nuvem apresentam cinco características essenciais que demonstram suas relações e
diferenças das abordagens tradicionais de computação:
 Auto-atendimento sob demanda. Um consumidor pode unilateralmente provisionar

capacidades computacionais como tempo de servidor e armazenamento de rede
automaticamente conforme necessário, sem requerer interação humana com o provedor
de serviços.
 Amplo acesso a rede. Capacidades estão disponíveis na rede e acessadas através de

mecanismos padrões que promovem o uso por plataformas heterogêneas de clientes leves
(thin clients) ou não (por exemplo, telefones celulares, laptops, e PDAs) assim como
outros serviços de software tradicionais ou baseados em nuvem.
 Pool de Recursos. Os recursos de computação do provedor estão reunidos para servir a

múltiplos consumidores usando um modelo multilocação, com diferenças físicas e
recursos virtuais dinamicamente atribuídos e retribuídos de acordo com a demanda do
consumidor. Existe um grau de independência de localização nisto que o consumidor
geralmente não tem controle ou conhecimento sobre a localização exata dos recursos
providos, mas pode ser capaz de especificar a localização em um nível mais alto de
abstração (por exemplo, país, estado ou Data Center). Exemplos de recursos incluem
armazenamento, processamento, memória, largura de banda, e máquinas virtuais. Até
nuvens privadas tendem a reunir recursos entre diferentes partes da mesma organização.
 Elasticidade Rápida. Capacidades podem ser rapidamente e elasticamente provisionadas

– em alguns casos automaticamente – para rapidamente escalar, disponibilizar e escalar
de volta. Para o consumidor, as capacidades disponíveis para o provisionamento
geralmente parecem ser ilimitadas e podem ser contratadas em qualquer quantidade e a
qualquer hora.
 Serviços mensuráveis. Sistemas em Nuvem automaticamente controlam e otimizam o

uso de recursos alavancando a capacidade de mensurar em algum nível de abstração
apropriado para o tipo de serviço (por exemplo. armazenamento, processamento, largura
de banda ou contas de usuário ativas). O uso de recursos pode ser monitorado, controlado
e relatado – provendo transparência para ambos o provedor e o consumidor do serviço.
É importante reconhecer que os serviços em nuvem são geralmente, mas nem sempre, utilizados
em conjunto com, e habilitado por tecnologias de virtualização. Não existe requisito, no entanto,
que relaciona a abstração de recursos com as tecnologias de virtualização e no caso de muitas
ofertas, a virtualização por ambientes de sistemas operacionais ou hypervisors não são utilizadas.
Além do mais, deveria ser notado que a característica de multilocatário não é considerada
essencial pelo NIST, mas é geralmente discutido como se fosse. Favor se referir à seção sobre
“multilocatário” abaixo, apresentada após a descrição de implantação do modelo em nuvem, para
maiores detalhes.

Modelos de Serviços de Nuvem
A entrega de serviços de nuvem é dividida entre três modelos de arquitetura e várias combinações
derivadas. As três classificações fundamentais são geralmente referidas como “Modelo SPI”,
onde “SPI” significa Software, Plataforma e Infraestrutura (como um Serviço), respectivamente –
definidos, portanto como:
 Software em Nuvem como um Serviço (SaaS). A capacidade oferecida ao consumidor

consiste em utilizar as aplicações do provedor rodando em uma infraestrutura em nuvem.
As aplicações são acessíveis por vários dispositivos através de uma interface simples de
cliente como um browser web (exemplo: webmail). O consumidor não gerencia ou
controla a infraestrutura adjacente na nuvem, incluindo rede, servidores, sistemas
operacionais, armazenamento, ou nem mesmo as capacidades individuais da aplicação,
com a possível exceção de parâmetros limitados de configuração da aplicação específicos
para os usuários.
 Plataforma em Nuvem como um Serviço (PaaS). A capacidade oferecida ao

consumidor é para implementar na infraestrutura em nuvem criada para o usuário ou em
aplicações adquiridas usando linguagens de programação e ferramentas suportadas pelo
provedor. O consumidor não gerencia ou controla a infraestrutura adjacente na nuvem,
incluindo rede, servidores, sistemas operacionais, ou armazenamento, mas tem controle
sobre as aplicações implementadas e possivelmente configurações da aplicação referentes
ao ambiente do servidor.
 Infraestrutura em Nuvem como um Serviço (IaaS). A capacidade oferecida ao

consumidor é de provisionar processamento, armazenamento, redes e outros recursos
computacionais fundamentais onde o consumidor está apto a implementar e rodar os
softwares que desejar, o que pode incluir sistemas operacionais e aplicações. O
consumidor não gerencia ou controla as camadas adjacentes da infraestrutura na nuvem,
mas tem controle sobre o sistema operacional, armazenamento, aplicações
implementadas e possivelmente controle limitado de componentes específicos de rede
(exemplo: firewalls no servidor).
O modelo NIST e este documento não endereçam diretamente as definições de modelos de

serviços emergentes associados com os agentes de serviço na nuvem, estes provedores que
oferecem intermediação, monitoração, transformação/portabilidade, governança, provisionamento
e serviços de integração e negociam o relacionamento entre vários provedores de nuvem e os
consumidores.
No curto prazo, como a inovação estimula o desenvolvimento de soluções rápidas, consumidores

e provedores de serviços de nuvem terão a sua disposição vários métodos de interação com
serviços de nuvem na forma de APIs de desenvolvimento e interfaces e então os agentes de
serviços de nuvem irão surgir como um importante componente em todo o ecossistema na nuvem.
Agentes de serviços de nuvem irão abstrair os possíveis recursos incompatíveis e as interfaces no

lugar dos consumidores, para prover intermediação antes do surgimento de normas em comum,
abertas e de métodos padronizados para solucionar o problema a longo prazo através de
capacidades semânticas que darão fluidez e agilidade ao consumidor, estando este habilitado a
obter vantagem do modelo que melhor se adéqua às suas necessidades em particular.

É também importante notar o surgimento de muitos esforços centralizados ao redor do
desenvolvimento de APIs ao mesmo tempo abertas e proprietárias que busquem permitir recursos
como o gerenciamento, segurança e interoperabilidade para a nuvem. Alguns desses esforços
incluem o grupo de trabalho “Open Cloud Computing Interface Working Group”, a API da
Amazon EC2, a API vCloud da Vmware, submetida ao DMTF (Distributed Management Task
Force), a API Open Cloud da Sun, a API da Rackspace e a API da GoGrid, para citar apenas
algumas. APIs abertas e padronizadas vão ter um papel fundamental na portabilidade e
interoperabilidade da nuvem, assim como formatos genéricos em comum como o “Open
Virtualization Format” (OVF) da DMTF.
Enquanto há muitos grupos de trabalho, rascunhos e especificações publicadas sob consideração

neste momento é natural que a consolidação terá efeito assim que as forças de mercado, as
necessidades dos consumidores e a economia direcionarem o cenário para um conjunto mais
gerenciável e interoperável de fornecedores.
Modelos de Implantação de Nuvem
Independente do modelo de serviço utilizado (SaaS, PaaS ou IaaS) existem quatro modelos de
implantação de serviços de nuvem, com variações para atender a requisitos específicos:
 Nuvem Pública. A infraestrutura de nuvem é disponibilizada ao público em geral ou a

um grande grupo industrial e é controlada por uma organização que vende os serviços de
nuvem.
 Nuvem Privada. A infraestrutura da nuvem é operada exclusivamente por uma única

organização. Ela pode ser gerida pela organização ou por terceiros, e pode existir no local
ou fora do ambiente da empresa.
 Nuvem Comunitária. A infraestrutura da nuvem é compartilhada por diversas

organizações e suporta uma determinada comunidade que partilha interesses (por
exemplo, a missão, os requisitos de segurança, política ou considerações de
conformidade). Ela pode ser administrada pelas organizações ou por um terceiro e pode
existir no local ou fora do ambiente da empresa.
 Nuvem Híbrida. A infraestrutura da nuvem é uma composição de duas ou mais nuvens

(privada, comunitária ou pública) que permanecem como entidades únicas, mas estão
unidas pela tecnologia padronizada ou proprietária que permite a portabilidade de dados e
aplicativos (por exemplo, “cloud bursting” para balanceamento de carga entre as
nuvens).
É importante observar que existem modelos derivados de implementação de uma nuvem

surgindo, devido ao amadurecimento das ofertas de mercado e da demanda dos clientes. Um
exemplo típico são as nuvens virtuais privadas (virtual private clouds) – é uma maneira de
utilizar a infraestrutura de nuvem pública de forma privada ou semiprivada e interligar estes
recursos aos recursos internos do data center do consumidor, é feita geralmente através de
conectividade via redes privadas virtuais (virtual private network ou VPN).
As características da arquitetura utilizada ao desenhar as soluções terão implicação clara na futura

flexibilidade, segurança e mobilidade da solução final, assim como da sua capacidade de
colaboração. Como regra geral, as soluções que estabelecem perímetros são menos eficazes do

que as soluções sem perímetros definidos em cada um dos quatro modelos. Também deve ser
feita uma cuidadosa consideração à escolha entre as soluções proprietárias ou abertas pelos
mesmos motivos.
Multilocatário
Embora esta não seja uma característica essencial da Computação em Nuvem no modelo do
NIST, a CSA identificou a multilocação como um elemento importante da nuvem.
A multilocação de serviços de nuvem implica na necessidade de forçar a aplicação de políticas,

segmentação, isolamento, governança, níveis de serviço e modelos de cobrança
retroativa/faturamento aplicados a diferentes grupos de consumidores. Os consumidores poderão
utilizar serviços oferecidos por fornecedores de serviços de nuvem pública ou na verdade fazerem
parte da mesma organização, como no caso de unidades de negócios diferentes, em vez de
diferentes entidades organizacionais, mas ainda assim iriam compartilhar a infraestrutura.
Figura 2 - Multilocatário
Do ponto de vista de um provedor, a multilocação sugere uma abordagem de design e arquitetura

que permita economia de escala, disponibilidade, gestão, segmentação, isolamento e eficiência
operacional, aproveitando o compartilhamento da infraestrutura, dos dados, metadados, serviços e
das aplicações através de muitos consumidores diferentes.
A multilocação também pode ter definições diferentes, dependendo do modelo de serviço de

nuvem do provedor, na medida em que pode implicar na viabilidade das capacidades descritas
acima nos níveis da infraestrutura, do banco de dados, ou da aplicação. Um exemplo seria a
diferença entre a implantação de uma aplicação multilocação em SaaS e IaaS.
Modelos de implantação de nuvem têm importância diferenciada em multilocação. No entanto,

mesmo no caso de uma nuvem privada, uma única organização pode ter um grande número de
consultores e contratados terceirizados, bem como um desejo de um elevado grau de separação
lógica entre as unidades de negócio. Assim, as preocupações da multilocação devem ser sempre
consideradas.

Modelos de Referência de Nuvem
Entender as relações e dependências entre os

modelos de Computação em Nuvem é
fundamental para compreender os riscos de
segurança. IaaS é o fundamento de todos os
serviços de nuvem, com o PaaS sendo
construído com base na IaaS, e SaaS por sua
vez, sendo construído baseado no PaaS, como
descrito no diagrama do Modelo de Referência
de Nuvem. Desta forma, assim como as
capacidades são herdadas, também são
herdadas as questões de segurança da
informação e o risco. É importante notar que
provedores comerciais de nuvem podem não
se encaixar perfeitamente nos modelos de
serviços em camadas. No entanto, o modelo de
referência é importante para estabelecer uma
relação entre os serviços do mundo real e o
framework arquitetônico, bem como a
compreensão dos recursos e serviços que
exigem análise de segurança.
A IaaS inclui todos os recursos da pilha de

infraestrutura desde as instalações até as
plataformas de hardware que nela residem. Ela
incorpora a capacidade de abstrair os recursos
(ou não), bem como oferecer conectividade
física e lógica a esses recursos. Finalmente, a
IaaS fornece um conjunto de APIs que
permitem a gestão e outras formas de interação
com a infraestrutura por parte dos
Figura 3 – Modelo de Referência de Nuvem consumidores.
A PaaS trabalha em cima da IaaS e acrescenta uma camada adicional de integração com
frameworks de desenvolvimento de aplicativos, recursos de middleware e funções como banco de
dados, mensagens e filas, o que permite aos desenvolvedores criarem aplicativos para a
plataforma cujas linguagens de programação e ferramentas são suportadas pela pilha.
O SaaS por sua vez, é construído sobre as pilhas IaaS e PaaS logo abaixo, e fornece um ambiente
operacional autocontido usado para entregar todos os recursos do usuário, incluindo o conteúdo, a
sua apresentação, a(s) aplicação(ções) e as capacidades de gestão.
Consequentemente deve ficar claro que existem importantes compensações de cada modelo em
termos das funcionalidades integradas, complexidade versus abertura (extensibilidade), e
segurança. As compensações entre os três modelos de implantação da nuvem incluem:
 Geralmente, o SaaS oferece a funcionalidade mais integrada, construída diretamente

baseada na oferta, com a menor extensibilidade do consumidor, e um nível relativamente
elevado de segurança integrada (pelo menos o fornecedor assume a responsabilidade pela
segurança).

 A PaaS visa permitir que os desenvolvedores criem seus próprios aplicativos em cima da
plataforma. Como resultado, ela tende a ser mais extensível que o SaaS, às custas de
funcionalidades previamente disponibilizadas aos clientes. Esta troca se estende às
características e capacidades de segurança, onde as capacidades embutidas são menos
completas, mas há maior flexibilidade para adicionar uma a camada de segurança extra.
 A IaaS oferece pouca ou nenhuma característica típica de aplicações, mas enorme

extensibilidade. Isso geralmente significa menos recursos e funcionalidades integradas de
segurança além de proteger a própria infraestrutura. Este modelo requer que os sistemas
operacionais, aplicativos e o conteúdo possam ser gerenciados e protegidos pelo
consumidor da nuvem.
Uma conclusão fundamental sobre a arquitetura de segurança é que quanto mais baixo na pilha o
prestador de serviços de nuvem parar, mais recursos de segurança e gestão os consumidores terão
a responsabilidade de implementar e gerenciar por si próprios.
No caso do SaaS, isso significa que os níveis de serviço, segurança, governança, conformidade, e
as expectativas de responsabilidade do prestador de serviço estão estipuladas, gerenciadas e
exigidas contratualmente. No caso de PaaS ou IaaS é de responsabilidade dos administradores de
sistema do cliente gerenciar eficazmente o mesmo, com alguma compensação esperada pelo
fornecedor ao proteger a plataforma e componentes de infraestrutura subjacentes que garantam o
básico em termos de disponibilidade e segurança dos serviços. Deve ficar claro em qualquer caso
que se pode atribuir / transferir a responsabilidade, mas não necessariamente a responsabilidade
final.
Estreitando o escopo ou capacidades específicas bem como funcionalidades dentro de cada um

dos modelos de ofertas de nuvem, ou empregando o agrupamento funcional dos serviços e
recursos entre eles, podemos produzir classificações derivadas. Por exemplo, o “armazenamento
como um serviço” (“Storage as a Service”) é uma sub-oferta específica dentro da “família” do
IaaS.
Apesar de uma ampla revisão do crescente conjunto de soluções de Computação em Nuvem estar
fora do escopo deste documento, a taxotomia do OpenCrowd Cloud Solutions na figura abaixo
fornece um excelente ponto de partida. A taxonomia OpenCrowd demonstra os crescentes grupos
de soluções disponíveis hoje em cada um dos modelos previamente definidos.
Note que o CSA não endossa especificamente nenhuma das soluções ou as empresas exibidas
abaixo, mas fornece o diagrama para demonstrar a diversidade de ofertas disponíveis hoje.

Figura 4 - Taxonomia OpenCrowd
Para uma excelente visão geral dos muitos casos de uso da Computação em Nuvem, o Cloud
Computing Use Case Group elaborou um trabalho colaborativo para descrever e definir os casos
comuns e demonstrar os benefícios da nuvem, com o objetivo de “... reunir consumidores de
nuvem e fornecedores de nuvem para definir os casos de uso frequentes para a Computação em
Nuvem... e destacar os recursos e as necessidades que precisam ser padronizados em um
ambiente de nuvem para garantir a interoperabilidade, facilidade de integração e portabilidade.”
Modelo de Referência de Segurança em Nuvem
O modelo de referência de segurança em nuvem aborda as relações entre essas classes e as coloca
no contexto das preocupações e controles de segurança relevantes. Para organizações e indivíduos
que terão contato com a Computação em Nuvem pela primeira vez, é importante observar os
pontos abaixo para evitar potenciais armadilhas e confusões:
1. A forma como os serviços de nuvem são implantados é frequentemente usada de maneira

alternada com a idéia de onde eles são fornecidos e isso pode levar a confusões.
Ambientes públicos ou privados de Computação em Nuvem, por exemplo, podem ser
descritos como nuvens externas ou internas e isso pode não ser correto em todos os casos.
2. A maneira como os serviços de nuvem são consumidos é frequentemente descrita em
relação ao perímetro de gestão ou de segurança de uma organização (geralmente definido
pela presença de um firewall). Embora seja importante entender onde as fronteiras de

segurança deixam de existir em termos de Computação em Nuvem , a ideia de um
perímetro bem demarcado é um conceito anacrônico.
3. A reperimetrização e a erosão de fronteiras de confiança que já estão acontecendo nas
corporações são amplificadas e aceleradas pela Computação em Nuvem. Conectividade
onipresente, a natureza amorfa das trocas de informações e a ineficácia dos controles
estáticos de segurança que não conseguem tratar da natureza dinâmica dos serviços de
nuvem, todos requerem novas formas de pensamento quando se considera a Computação
em Nuvem. O fórum de Jericho produziu uma quantidade considerável de material sobre
a reperimetrização das redes corporativas, incluindo muitos estudos de casos.
As modalidades de implantação e consumo de nuvem devem ser pensadas não só no contexto do

‘interno’ versus ‘externo’, como em relação à localização física dos ativos, recursos e
informações, mas também no contexto de quem são os seus consumidores e de quem é o
responsável pela sua governança, segurança e conformidade com políticas e padrões.
Isto não é sugerir que a localização dentro ou fora da empresa de um ativo, um recurso ou uma
informação não afete a condição de segurança e de risco de uma organização porque elas são
afetadas – mas para ressaltar que esse risco também depende de:
 Os tipos de ativos, recursos e informações sendo gerenciados

 Quem as gerencia e como as gerencia
 Quais controles estão selecionados e como eles estão integrados
 Questões de conformidade
Um ambiente LAMP implantado no AWS EC2 da Amazon, por exemplo, seria classificado como
uma solução pública, fora do ambiente da empresa (off-premise) e IaaS gerenciada por terceiros,
mesmo se as instâncias, aplicações e dados contidos dentro dela fossem gerenciados pelo
consumidor ou por um terceirizado. Um ambiente de aplicação personalizado servindo múltiplas
unidades de negócio, implantado no Eucalyptus sob o controle, o gerenciamento e o domínio da
corporação poderia ser descrito como uma solução SaaS privada, dentro da empresa (on-premise)
e autogerenciada. Ambos os exemplos utilizam as capacidades de dimensionamento elástico e de
autoatendimento da nuvem.

A tabela a seguir sumariza esses pontos:
Tabela – Modelos de Implantação da Nuvem
Outra maneira de se visualizar as combinações dos modelos de serviços de Computação em

Nuvem, modelos de implantação, de localização física dos recursos e as atribuições de
propriedade e gerenciamento, é através do modelo “Cloud Cube Model” criado pelo Fórum
Jericho (www.jerichoforum.org), mostrado na figura abaixo:
Figura 5 – Modelo “Cloud Cube” do Jericho

O Cloud Cube Model mostra as inúmeras permutações possíveis nas ofertas de nuvem
disponíveis atualmente e apresenta quatro critérios/dimensões a fim de separar as ‘formas’ de
nuvem uma das outras e a maneira como são fornecidas, visando entender como a Computação
em Nuvem afeta a forma de abordar a questão da segurança.
O Cloud Cube Model também destaca os desafios em entender e mapear os modelos de nuvem
para frameworks e padrões de controle como a ISO/IEC 27002, que fornece “…uma série de
orientações e princípios gerais para a iniciar, implementar, manter e melhorar o gerenciamento da
segurança da informação dentro de uma organização.”
A seção 6.2 da ISO/IEC 27002, sobre objetivos de controle para “Parceiros Externos,” declara:
“…a segurança das informações e das instalações de processamento de informações da
organização não deve ser reduzida em função da introdução de produtos ou serviços de parceiros
externos...”
Da mesma forma, as diferenças nos métodos e na responsabilidade por proteger os três modelos
de serviço de nuvem significam que os clientes dos mesmos são confrontados com um esforço
desafiador. A menos que os provedores de nuvem possam divulgar facilmente seus controles de
segurança e o alcance da implementação dos mesmos para o cliente, e o cliente saiba quais
controles são necessários para manter a segurança de suas informações, existe um enorme
potencial para decisões equivocadas e resultados negativos.
Isto é crítico. Primeiro classifica-se um serviço de nuvem em comparação ao modelo de

arquitetura de Computação em Nuvem. A partir disso, torna-se possível mapear sua arquitetura de
segurança, bem como os requisitos de negócios, de regulamentações e outros requisitos de
conformidade, como em um exercício de análise de gap (gap-analysis). O resultado determina o
estado geral de segurança de um serviço e como ele se relaciona com a garantia dos ativos e os
requisitos de proteção.
A figura abaixo mostra um exemplo de como o mapeamento de serviço de Computação em

Nuvem pode ser comparado com um catalogo de controles de compensação para determinar quais
controles existem e quais não existem – como os fornecidos pelo cliente, por um provedor de
serviços de nuvem, ou um terceiro. Isto pode, por sua vez, ser comparado com um framework de
conformidade ou um conjunto de requisitos como o PCI DSS, conforme mostrado nesse exemplo.

Figura 6 – Mapeando o Modelo de Nuvem para o Modelo de Controles de Segurança &
Conformidade
Uma vez que a análise de gap esteja completa, baseada nos requisitos de qualquer
regulamentação ou pela exigência de conformidade, torna-se muito mais fácil determinar o que
precisa ser feito para que ela sirva de base para um framework de avaliação de riscos; isto, por
sua vez, ajuda a determinar como os gaps e, em última análise, os riscos devem ser tratados:
aceitando-os, transferindo-os ou mitigando-os.
É importante notar que o uso de Computação em Nuvem como um modelo operacional não prevê
e nem previne a obtenção de conformidade automaticamente. A habilidade para atender qualquer
requisito é um resultado direto dos modelos de serviço e de implantação utilizados e do desenho,
da implantação e do gerenciamento dos recursos definidos no escopo.
Para uma excelente visão geral dos frameworks de controle que fornecem bons exemplos do
framework genérico de controle mencionado acima, veja o conjunto de documentos sobre padrões
de arquitetura de segurança do Open Security Architecture Group, ou a versão 3 do catálogo de
controles de segurança recomendados número 800-53 (Recommended Security Controls for
Federal Information Systems and Organizations) do NIST, que é sempre útil e foi atualizado
recentemente.
O que é Segurança para Computação em Nuvem?
Para a maioria, controles de segurança de Computação em Nuvem não são diferentes dos
controles de segurança para qualquer ambiente de TI. No entanto, em função dos modelos de

serviço de nuvem que são empregados, os modelos operacionais e as tecnologias usadas para
habilitar tais serviços, a Computação em Nuvem pode apresentar riscos diferentes para uma
organização quando comparada com as soluções tradicionais de TI.
A Computação em Nuvem envolve a lenta perda de controle ao mesmo tempo em que mantemos
a responsabilidade, mesmo se a responsabilidade operacional recair sobre um ou mais terceiros.
Uma postura de segurança da organização é caracterizada pela maturidade, eficácia e a plenitude

dos controles de segurança implementados ajustados aos riscos. Esses controles são aplicados em
uma ou mais camadas que vão desde as instalações (segurança física), à infraestrutura de rede
(segurança da rede), até os sistemas de TI (segurança de sistemas), até a informação e as
aplicações (segurança de aplicações). Além disso, os controles são aplicados nos níveis das
pessoas e dos processos, tal como a separação de funções e de gestão de mudanças,
respectivamente.
Conforme descrito anteriormente neste documento, as responsabilidades de segurança do

provedor e do consumidor diferem muito entre os modelos de serviços de nuvem. A oferta de
infraestrutura como serviço da Amazon, AWS EC2, por exemplo, inclui a responsabilidade do
fornecedor pela segurança até o hypervisor, o que significa que pode incidir apenas sobre os
controles de segurança como a segurança física, segurança ambiental e segurança da
virtualização. O consumidor, por sua vez, é responsável pelos controles de segurança que se
relacionam com o sistema de TI (a instância), incluindo o sistema operacional, aplicativos e
dados.
O contrário é verdadeiro para a oferta SaaS de gestão de recursos de clientes (customer resource
management, ou CRM) da Salesforce.com. Como toda a “pilha” é fornecida pela Salesforce.com,
o provedor não é apenas responsável pelos controles de segurança física e ambiental, mas
também deve abordar os controles de segurança na infraestrutura, nas aplicações e nos dados. Isso
alivia muito da responsabilidade direta do consumidor pela operação.
Uma das atrações da Computação em Nuvem é a eficiência de custos proporcionada pelas

economias de escala, reutilização e padronização. Para viabilizar estas eficiências, os provedores
de serviço de nuvem têm que prestar serviços que sejam flexíveis o suficiente para atender a
maior base de clientes possível, maximizando o seu mercado-alvo. Infelizmente, integrar
segurança nestas soluções é frequentemente percebido como torná-las mais rígidas.
Essa rigidez se manifesta muitas vezes na incapacidade de ganhar a paridade na implantação de

controles de segurança em ambientes de nuvem em comparação a TI tradicional. Isso decorre
principalmente devido à abstração da infraestrutura e à falta de visibilidade e capacidade para
integrar muitos controles familiares de segurança, especialmente na camada de rede.
A figura abaixo ilustra estas questões: em ambientes SaaS, os controles de segurança e de seus
escopos são negociados em contratos de serviços: os níveis de serviço, privacidade e
conformidade são todos assuntos a serem tratados legalmente em contratos. Em uma oferta IaaS,
enquanto a responsabilidade de proteger a infraestrutura básica e camadas de abstração pertence
ao provedor, o restante da pilha é de responsabilidade do consumidor. PaaS oferece um equilíbrio
em algum lugar no meio, onde garantir a própria plataforma cai sobre o provedor, mas a
segurança das aplicações desenvolvidas para a plataforma e a tarefa de desenvolvê-las de forma
segura pertencem ambas ao consumidor.

Figura 7 – Como a Segurança é Integrada
Entender o impacto dessas diferenças entre os modelos de serviço e como eles são implementados
é fundamental para a gestão do posicionamento de uma organização frente ao risco.
Além da Arquitetura: As Áreas de Atenção Crítica
Os outros doze domínios, que incluem as demais áreas de preocupação para a Computação em
Nuvem destacadas pelo guia da CSA são ajustados para abordar tanto os pontos estratégicos e
táticos críticos de segurança dentro de um ambiente em nuvem e, podem ser aplicados a qualquer
combinação de serviços e de modelos de implantação da nuvem.
Os domínios são divididos em duas grandes categorias: governança e operações. Os domínios da

governança são amplos e endereçam questões estratégicas e de política dentro de um ambiente de
Computação em Nuvem, enquanto os domínios operacionais focam mais nas preocupações táticas
de segurança e sua implementação dentro da arquitetura.
Domínios de Governança
Domínio O Guia trata de…
A capacidade de uma organização para
governar e medir o risco empresarial
introduzido pela Computação em Nuvem. Ítens
como a precedência legal em caso de violação
Governança e Gestão de Riscos Corporativos
de acordo, a capacidade de organizações
usuárias para avaliar adequadamente o risco de
um provedor de nuvem, a responsabilidade para
proteger dados sensíveis quando o usuário e o

provedor podem falhar e, como as fronteiras
internacionais podem afetar estas questões, são
alguns dos itens discutidos.
Problemas legais em potencial quando se utiliza
Computação em Nuvem. Os assuntos abordados
nesta seção incluem os requisitos de proteção da
Aspectos Legais e Electronic Discovery
informação e de sistemas informáticos, leis de
divulgação de violações de segurança, os
requisitos regulatórios, requisitos de
privacidade, as leis internacionais, etc.
Manutenção e comprovação de conformidade
quando se faz uso da Computação em Nuvem.
Questões relativas à avaliação da forma como a
Computação em Nuvem afeta o cumprimento
das políticas de segurança interna, bem como
Conformidade e Auditoria
diversos requisitos de conformidade
(regulatórios, legislativos e outros) são
discutidos aqui. Este domínio inclui algumas
orientações de como provar a conformidade
durante uma auditoria.
Gerenciamento de dados que são colocados na
nuvem. Ítens em torno da identificação e
controle de dados na nuvem, bem como
controles compensatórios que podem ser usados
Gestão do Ciclo de Vida da Informação para lidar com a perda de controle físico ao
mover dados para a nuvem são discutidos aqui.
Outros ítens, como quem é responsável pela
confidencialidade, integridade e disponibilidade
dos dados são mencionados.
A habilidade de mover dados / serviços de um
provedor para outro, ou levá-lo totalmente de
Portabilidade e Interoperabilidade volta para a empresa. Problemas de
interoperabilidade entre os fornecedores
também são discutidos.
Domínios Operacionais
Como a Computação em Nuvem afeta os
processos e procedimentos operacionais
atualmente usados para implementar a
segurança, continuidade de negócios e
recuperação de desastres. O foco é discutir e
Segurança Tradicional, Continuidade de analisar os possíveis riscos da Computação em
Negócios e Recuperação de Desastres Nuvem, na esperança de aumentar o diálogo e
debate sobre a grande procura de melhores
modelos de gestão de riscos corporativos. Além
disso, a seção aborda sobre como ajudar as
pessoas a identificar onde a Computação em
Nuvem pode ajudar a diminuir certos riscos de

segurança, ou implica em aumento dos riscos
em outras áreas.
Como avaliar a arquitetura e a operação de um
fornecedor de data center. Este capítulo é
principalmente focado em ajudar os usuários a
identificar características comuns de data
Operação do Data Center
centers que podem ser prejudiciais para os
serviços em andamento, bem como
características que são fundamentais para a
estabilidade a longo prazo.
A correta e adequada detecção de incidentes, a
resposta, notificação e correção. Pretende-se
abordar itens que devem estar presentes tanto
no nível dos prestadores e dos usuários para
Resposta a Incidentes, Notificação e Correção permitir bom tratamento de incidentes e
forenses computacional. Este domínio vai
ajudá-lo a compreender as complexidades que a
nuvem traz para seu atual programa de gestão
de incidentes.
Protegendo o software aplicativo que está sendo
executado ou sendo desenvolvido na nuvem.
Isto inclui ítens tais como, se é apropriado
migrar ou projetar um aplicativo para ser
Segurança de Aplicação executado na nuvem, e em caso afirmativo, que
tipo de plataforma em nuvem é mais adequada
(SaaS, PaaS ou IaaS). Algumas questões de
segurança específicas relacionadas com a
nuvem também são discutidas.
Identificar o uso de criptografia e gestão de
chaves escalável. Esta seção não é prescritiva,
mas é mais informativa em discutir por que eles
Gestão de Criptografia e de Chaves são necessários e identificar as questões que
surgem na utilização, tanto para proteger o
acesso aos recursos, bem como para proteger os
dados.
Gerenciamento de identidades e alavancando os
serviços de diretório para fornecer controle de
acesso. O foco está em questões encontradas
quando se estende a identidade de uma
Gestão da Identidade e do Acesso organização para a nuvem. Esta seção fornece
insights para avaliar a prontidão da organização
para realizar a gestão da identidade e acesso
(Identity and Access Management, ou IAM)
baseados na nuvem.
O uso da tecnologia de virtualização em
Virtualização Computação em Nuvem. O domínio aborda
ítens tais como os riscos associados com

multilocação, o isolamento de VMs, a
corresidência de VMs, vulnerabilidades no
hypervisor, etc. Este domínio foca nas questões
da segurança em torno do sistema / hardware de
virtualização, ao invés de um levantamento
mais geral de todas as formas de virtualização.
Resumo
A chave para compreender como a arquitetura da nuvem impacta na arquitetura de segurança é

um vocabulário comum e conciso, acompanhado de uma taxonomia consistente das ofertas
através dos quais os serviços em nuvem e as arquiteturas podem ser desconstruídos, mapeados
para um modelo de controles de segurança e operacionais de compensação, frameworks de
avaliação de risco e de gestão e, em seguida, para padrões de conformidade.
Entender como a arquitetura, tecnologia, processo e as necessidades de capital humano alteram

ou permanecem os mesmos durante a implantação de serviços de Computação em Nuvem é
fundamental. Sem uma compreensão clara e de alto nível das implicações na arquitetura, é
impossível abordar racionalmente as questões mais detalhadas.
Esta visão geral da arquitetura, juntamente com as doze outras áreas de foco crítico, vai
proporcionar ao leitor uma base sólida para a avaliação, operacionalização, gerenciamento e
governança da segurança em ambientes de Computação em Nuvem.
Colaboradores da Versão Original: Glenn Brunette, Phil Cox, Carlo Espiritu, Christofer Hoff,
Mike Kavis, Sitaraman Lakshminarayanan, Kathleen Lossau, Erik Peterson, Scott Matsumoto,
Adrian Seccombe, Vern Williams, Richard Zhou
Colaboradores da Versão Brasileira: Alessandro Trombini, Alexandre Pupo, Anchises Moraes,

Denylson Machado, Jaime Orts Y. Lugo, Luís Felipe Féres Santos, Milton Ferreira, Olympio
Rennó Ribeiro Jr

Seção II. Governança na Nuvem

Domínio 2: Governança e Gestão de Risco Corporativo
A governança e o gerenciamento de risco corporativo eficazes em ambientes de Computação em
Nuvem vêm dos processos de governança de segurança da informação bem definidos, como parte
das determinações gerais de governança corporativa da organizaçãosobre os cuidados específicos
necessários com os ativos. . Os processos de governança bem definidos devem resultar em
programas de gerenciamento de segurança da informação que sejam escalonávies com o negócio,
aplicáveis em toda a organização, mensuráveis, sustentáveis, defensáveis, continuamente
melhorados e com orçamentos justificáveis.
As questões fundamentais da governança e da gestão de riscos corporativo em Computação em

Nuvem referem-se à identificação e implementação das estruturas organizacionais adequadas,
processos e controles para manter a efetiva governança da segurança da informação, gestão de
riscos e conformidade. As organizações também devem garantir a um nível razoável de segurança
das informações em toda a cadeia de fornecimento da informação, envolvendo fornecedores e
clientes de serviços de Computação em Nuvem e seus prestadores de serviço, em qualquer
modelo de implantação de nuvem.
Recomendações de Governança
 Uma parte da redução de custos decorrente da adoção de Computação em Nuvem deve

ser direcionada para o aumento dos controles dos recursos de segurança do provedor,
aplicação de controles de segurança e avaliações e auditorias detalhadas, para garantir
que as exigências de proteção de dados estão sendo continuamente verificadas..
 Tanto os clientes quanto os fornecedores de serviços de Computação em Nuvem devem

desenvolver uma governança de segurança da informação robusta, independentemente
do serviço ou modelo de implantação adotado. A governança de segurança da
informação deve ser uma colaboração entre clientes e fornecedores para alcançar os
objetivos acordados, que apoiam a missão da empresa e programas de segurança da
informação. O modelo de negócio pode ajustar os papéis e responsabilidades
colaborativamente na governança de segurança da informação e no gerenciamento de
riscos (com base no respectivo âmbito de controle para o usuário e prestador de
serviços), enquanto o modelo de implantação pode definir as responsabilidades e
expectativas (com base na avaliação de risco).
 As organizações clientes devem incluir a revisão de determinados processos e estruturas

de governança de segurança da informação, bem como de controles de segurança
específicos, como parte de seus cuidados na seleção de provedores de serviço de
nuvem. Os processos de governança de segurança e as atividades dos fornecedores
devem ser avaliados sob sua capacidade de suportar os processos do cliente, bem como
sua maturidade e coerência com os processos de gestão de segurança de informações.
Os controles de segurança dos provedores de nuvem devem ser comprovadamente
baseados no risco e claramente suportar estes processos de gestão.
 A estrutura e processos de governança colaborativa entre clientes e fornecedores devem

ser identificadas como necessárias, tanto no âmbito da concepção e desenvolvimento de
prestação de serviços, como avaliação de risco e de serviços e protocolos de gestão de
risco e, em seguida incorporado nos acordos de serviço.

 Departamentos de segurança devem ser envolvidos durante o estabelecimento de
Acordos de Nível de Serviço (SLA) e obrigações contratuais, para assegurar que os
requisitos de segurança são contratualmente aplicáveis.
 Métricas e padrões para medir o desempenho e eficácia do gerenciamento de segurança

da informação devem ser estabelecidos previamente à mudança para a Nuvem. Ao
menos, as organizações devem entender e documentar suas métricas atuais e como elas
mudam quando operações são movidas para a Nuvem, onde um provedor pode usar
diferentes (e potencialmente incompatíveis) métricas.
 Sempre que possível, métricas e padrões de segurança (particularmente aquelas

relacionadas a requisitos legais e de conformidade) devem ser incluídas em qualquer
Acordo de Nível de Serviço (SLA) e contratos. Estas métricas e padrões devem ser
documentadas e ser demonstráveis (auditáveis).
Recomendações para gerenciamento de riscos corporativos
Assim como em qualquer novo processo de negócios, é importante seguir as melhores práticas de
gerenciamento de riscos. As práticas devem ser proporcionais às especificações dos serviços em
nuvem, que podem variar de processamento inócuo de dados e tráfego de rede até processos de
negócios de missão crítica lidando com informação altamente sensível. Uma discussão completa
do gerenciamento de riscos corporativos e gerenciamento de risco da informação está além do
escopo deste guia, mas aqui há algumas recomendações específicas da Nuvem que você pode
incorporar em seus processos de gerenciamento de riscos existentes.
 Devido à falta de controle físico sobre a infraestrutura em muitas implantações de

Computação em Nuvem; SLAs, requisitos de contratos e documentação dos provedores
têm um papel em gerenciamento de riscos maior do que quando lidamos com a
tradicional infraestrturua própria das empresas..
 Devido ao provisionamento sob demanda e aos aspectos “multilocatário” de

Computação em Nuvem, formas tradicionais de auditoria e avaliação podem não estar
disponíveis ou podem ser modificadas. Por exemplo, alguns provedores restringem
avaliações de vulnerabilidades ou testes de invasão, enquanto outros limitam
disponibilidade de logs de auditoria e monitoramento de atividades. Se estes forem
exigidos por suas políticas internas, você pode precisar procurar opções alternativas de
avaliação, exceções contratuais específicas ou um provedor alternativo melhor alinhado
com seus requisitos de gerenciamento de riscos.
 Com relação ao uso de serviços de Nuvem para funções críticas da organização, a

abordagem de gerenciamento de riscos deve incluir a identificação e avaliação de
ativos, identificação e análise de ameaças e vulnerabilidades e seu potencial impacto
nos ativos (cenários de riscos e incidentes), análise de probabilidade de
eventos/cenários, níveis e critérios de aceitação de gerenciamento de riscos aprovado e
o desenvolvimento de planos de tratamento de riscos com múltiplas opções (controle,
prevenção, transferência, aceitação). Os resultados dos planos de tratamento de riscos
devem ser incorporados aos acordos de serviço.
 Abordagens de avaliação de riscos entre provedores e usuários devem ser consistentes,

com consistência em critérios de análises de impacto e definição de probabilidades. O

usuário e o provedor juntos devem desenvolver cenários de risco para os serviços em
nuvem; isto deve ser intrínseco ao projeto do serviço prestado ao usuário e para a
avaliação do usuário do risco de serviços em nuvem.
 Inventario de ativos deve considerar os serviços de suporte de ativos na nuvem e sob

controle do provedor. Classificação de ativo e esquemas de avaliação deverem ser
coerentes entre usuário e provedor.
 O serviço, e não somente o fornecedor deve ser o alvo de uma avaliação de risco. O uso
de serviços na nuvem, os serviços especificos e modelos de desenvolvimento para
serem utilizados devem ser coerentes com os objetivos de gerenciamento de riscos da
organização assim como também com os objetivos do negócio.
 Quando o provedor não se demonstrar compreensivo e efetivo no processo de

gerenciamento de riscos em associação com estes serviços, clientes devem avaliar com
cuidado as habilidades tanto de fornecedores quanto dos próprios usuários no sentido de
compensar a brechas potenciais indicadas pelo gerenciamento de riscos.
 Clientes de serviços na nuvem devem questionar se seu sua gestão definiu a níveis de
tolerância a riscos com relação aos serviços na nuvem e aceita qualquer risco residual
inerente à utilização de serviços em nuvem.
Recomendação de Gerenciamento de Riscos da Informação
Gerenciamento de Riscos da Informação é o ato de alinhar a exposição ao risco e a capacidade de

gerenciá-lo, com a tolerancia ao risco do proprietário das informações. Desta forma, o
gerenciamento de risco é o principal meio de apoio às decisões para desenvolver ferramentas de
tecnologia da informação para proteger a confidencialidade, integridade e disponibilidade dos
ativos da informação.
 Adote um modelo de framework de gerenciamento de riscos para avaliar seu GRI

(Gerenciamento de Riscos da Informação) e um modelo de maturidade para avaliar a
efetividade do seu modelo de GRI.
 Estabeleça requisitos contratuais apropriados e controles tecnológicos para coletar

dados necessários para informar as decisões sobre os riscos à informação (ex. uso da
informação, controle de acesso, controles de segurança, localização, etc.).
 Adote um processo para determinar a exposição ao risco antes de elencar requisitos

para um projeto de Computação em Nuvem. Embora as categorias de informação
necessárias para entender a exposição e gestão sejam genéricas, as métricas atuais de
coleta de evidências são especificas para a natureza do modelo SPI (SaaS, PaaS e IaaS)
de Computação em Nuvem e que podem ser facilmente coletadas nas especificações do
serviço prestado.
 Quando utilizado SaaS (Software como serviço), a maior parte da informação deve ser
fornecida pelo provedor do serviço. Organizações devem estruturar processos de coleta
de informações analiticas nas obrigações contratuais do serviço SaaS.

 Quando utilizando o modelo PaaS (Plataforma como um Serviço), defina a coleta de
informações como definido no modelo SaaS acima, mas sempre que for possivel,
considere a capacidade de implantar e coletar informações de controles, bem como a
criação de itens contratuais para testar a efetividade destes controles.
 Quando utilizado um provedor de serviços sob o modelo IaaS (Infraestrutura como um

serviço), defina a transparência das informações em nível contratual para que possam
ser tratadas pela análise de riscos.
 Os provedores de serviço em nuvem devem incluir métricas e controles para auxiliar os

clientes na implementação dos seus requisitos de Gestão de Risco da Informação.
Recomendações para o Gerenciamento de Serviços Terceirizados
 Os clientes devem considerar os serviços e a segurança em nuvem como questões de

segurança da cadeia de suprimento (Supply Chain). Isso significa examinar e avaliar, na
medida do possível, a cadeia de suprimentos do fornecedor (relacionamentos dos
prestadores de serviço e seus terceirizados). Isso também significa examinar o
gerenciamento de serviços terceirizados pelo próprio fornecedor.
 A avaliação dos fornecedores de serviços terceirizados deve concentrar-se

especificamente no gerenciamento do fornecedor, nas políticas de recuperação de
desastres e continuidade de negócio, e em processos e procedimentos; deve, igualmente,
incluir o exame das instalações de back-up e co-location de suas instalações físicas.
Deve incluir também a revisão das avaliações internas do fornecedor destinadas a
cumprir as exigências de políticas e procedimentos próprios, e a avaliação das métricas
usadas pelo fornecedor para fornecer informações razoáveis sobre o desempenho e a
efetividade dos seus controles nessas áreas.
 O plano de recuperação de desastres e continuidade de negócios do usuário deve incluir

cenários de perda dos serviços prestados pelo fornecedor e de perda pelo fornecedor de
serviços terceirizados e de capacidades dependentes de terceiros. A realização dos testes
dessa parte do plano deve ser coordenada com o provedor de serviços de nuvem.
 A regulamentação da governança de segurança de informações, a gestão de riscos e as

estruturas e os processos do fornecedor devem ser amplamente avaliados:
o Solicite uma documentação clara sobre como as instalações e os serviços do

fornecedor são avaliados quanto aos riscos e auditados sob controles de
vulnerabilidades, a frequência de tais avaliações, e como as deficiências de controles
são devidamente mitigadas.
o Solicite uma definição do que o fornecedor considera fatores de sucesso de
segurança da informação e serviços críticos, indicadores chave de desempenho, e
como tais aspectos são mensurados relativamente à Gestão de Segurança de
Informações e Serviços de TI.
o Examine a abrangência dos processos de comunicação, avaliação e domínio dos
requisitos legais, regulatórios, industriais e contratuais do fornecedor.
o Implemente detalhados contratos para determinar papéis, funções e
responsabilidades. Assegure que será feito uma validação legal, incluindo uma

avaliação do cumprimento das normas contratuais e leis em jurisdições estrangeiras
ou fora do estado.
o Determinar se os requisitos contratuais compreendem todos os aspectos materiais
das relações dos provedores de serviço de nuvem, tais como a situação financeira, a
reputação (por exemplo, verificações de referências), controles, pessoal estratégico,
planos e testes de recuperação de desastres, seguros, capacidades de comunicações e
uso de terceirizados do provedor.
Colaboradores da Versão Original: Jim Arlen, Don Blumenthal, Nadeem Bukhari, Alex
Hutton, Michael Johnson, M S Prasad, Patrick Sullivan
Colaboradores da Versão Brasileira: Alessandro Trombini, Filipe Villar, Marcelo Pinheiro,

Masaishi Yoshikawa, Nelson Novaes Neto

Domínio 3: Aspectos Legais e Electronic Discovery
Computação em Nuvem cria uma nova dinâmica no relacionamento entre a organização e suas
informações, envolvendo a presença de um terceiro: o provedor de nuvem. Isto cria novos
desafios relacionados ao entendimento de como as leis se aplicam para uma ampla variedade de
cenários de gerenciamento da informação.
É preciso considerar as dimensões funcional, jurisdicional e contratual para realizar uma

completa análise das questões legais relacionadas à Computação em Nuvem.
 A dimensão funcional compreende a determinação de quais funções e serviços de

Computação em Nuvem têm implicações legais para os participantes e stakeholders.
 A dimensão jurisdicional compreende a maneira pelo qual os governos administram leis e

regulamentos que afetam os serviços de Computação em Nuvem, os stakeholders e os
ativos de dados envolvidos.
 A dimensão contratual compreende as estruturas, os termos e as condições de contrato, e

os mecanismos de cumprimento através dos quais as partes interessadas em ambientes de
Computação em Nuvem podem tratar e gerenciar as questões legais e de segurança.
Computação em Nuvem no geral pode se distinguir do outsourcing tradicional de três formas: o

tempo de serviço (sob demanda e intermitente), o anonimato da identidade do(s) prestador(es) de
serviço e o anonimato da localização do(s) servidor(es) envolvido(s). Considerando-se
especificamente IaaS e PaaS, uma grande quantidade de orquestração, configuração e
desenvolvimento de software é realizada pelo cliente — tal responsabilidade não pode ser
transferida para o provedor de serviço de nuvem.
Conformidade com as recentes exigências legislativas e administrativas em todo o mundo tem

obrigado uma maior colaboração entre advogados e profissionais do setor de tecnologia. Isto é
especialmente verdadeiro na Computação em Nuvem, devido ao potencial de novas áreas de risco
legal criado pela natureza distribuída da nuvem se comparado à tradicional infraestrutura interna
ou terceirizada.
Diversas leis e regulamentos de conformidade nos Estados Unidos e da União Européia imputam
responsabilidade a subcontratados ou exigem que as entidades empresariais sejam
contratualmente responsáveis por eles.
Os tribunais já estão percebendo que os serviços de gestão de segurança da informação são

fundamentais para a tomada de decisão sobre a aceitação da informação digital como evidência.
Embora se trate de uma questão para infraestrutura tradicional de TI, é especialmente relativa na
Computação em Nuvem, devido à ausência de fundamentação legal da nuvem.
Recomendações
 Clientes e provedores da nuvem devem estar mutuamente cientes dos respectivos papéis e
responsabilidades relacionados à Eletronic Discovery, incluindo atividades como litígio,
investigações, prover o testemunho de perito, etc.

 Provedores de nuvem são aconselhados a garantir que seus sistemas de segurança da
informação atendam às necessidades do cliente para preservar os dados como autênticos e
confiáveis, incluindo informações primárias e secundárias, tais como metadados e
arquivos de logs.
 Dados sob a custódia dos provedores de serviços de nuvem devem receber proteção
equivalente a que teriam se estivessem nas mãos de seu proprietário original ou
custodiante.
 Elaboração de um plano para o término esperado ou inesperado da relação contratual e

para um retorno adequado ou descarte seguro dos ativos.
 Due diligence (auditoria) pré-contratual, negociação dos termos do contrato,

monitoramento pós-contrato e rescisão contratual e a transição da custódia dos dados são
itens de cuidado obrigatório de um cliente de serviços de nuvem.
 Saber onde o provedor de serviços de nuvem irá hospedar os dados é um pré-requisito

para implementar as medidas necessárias para garantir conformidade com as leis locais
que restringem o fluxo de dados além das fronteiras.
 Como custodiante dos dados pessoais de seus funcionários ou clientes, bem como de
outros ativos de propriedade intelectual da instituição, uma empresa que utiliza serviços
de Computação em Nuvem deve assegurar que ele mantém a posse de seus dados em seu
formato original e autêntico.
 Diversas questões de segurança, tais como suspeitas de violação de dados, devem ser
abordadas através de disposições específicas do contrato de prestação de serviço, que
esclarecem as respectivas obrigações do provedor de serviços de nuvem e do cliente.
 O provedor de serviços de nuvem e o cliente devem adotar um processo unificado para

responder às intimações, citações e outros requisitos legais.
 O contrato de serviços de nuvem deve permitir que o cliente ou terceiro designado

monitore o desempenho do provedor de serviços e teste as vulnerabilidades no sistema.
 As partes em um contrato de serviços de nuvem devem assegurar que o acordo preveja a

ocorrência de problemas relativos à recuperação dos dados do cliente após o término da
relação contratual.
Colaboradores da Versão Original: Tanya Forsheit, Scott Giordano, Francoise Gilbert, David
Jackson, Peter McLaughlin, Jean Pawluk, Jeffrey Ritter
Colaboradores da Versão Brasileira: Nelson Novaes Neto, Reginaldo Sarraf P.

Rodrigues

Domínio 4: Conformidade e Auditoria
Com o desenvolvimento da Computação em Nuvem como um meio viável e rentável para a
terceirização de sistemas, ou mesmo de processos de negócio inteiros, torna-se difícil alcançar e
até mais difícil demonstrar para auditores e avaliadores a aderência a conformidades, com a
política de segurança e com os vários regulamentos e requisitos legislatórios aos quais sua
organização está sujeita.
Dos diversos regulamentos que tangem à tecnologia da informação e que as organizações devem
cumprir, poucos foram escritos levando a Computação em Nuvem em consideração. Auditores e
avaliadores podem não estar familiarizados com a mesma ou com um determinado serviço de
nuvem em particular. Sendo esse o caso, cabe ao cliente de Computação em Nuvem entender:
 A aplicabilidade regulatória para o uso do serviço de nuvem em questão;

 A divisão das responsabilidades pela conformidade entre o provedor do serviço e o
cliente de nuvem;
 A capacidade do provedor de serviço de nuvem em produzir as evidências necessárias
para a conformidade
 Papel do cliente em fazer a ponte entre o provedor do serviço de nuvem e o
auditor/avaliador
Recomendações
 Envolva os Departamentos Jurídicos e de Contratos. As cláusulas padrão de serviço

do provedor de Computação em Nuvem podem não atender suas necessidades de
conformidade e, por isso, é vantajoso ter pessoas das áreas jurídicas e de contratos
envolvidas desde o início para garantir que o contrato de prestação de serviços seja
adequado para atender as obrigações de conformidade e auditoria.
 Cláusula Sobre o Direito de Auditar. Os clientes, frequentemente, terão a necessidade

da capacidade de auditar o provedor de serviços de Computação em Nuvem, dada a
natureza dinâmica dos ambientes regulatório e de Computação em Nuvem. Uma
cláusula sobre o direito de auditar deve ser obtida sempre que possível,
particularmente quando se usa um provedor para um serviço onde o cliente tenha que
regulamentar o cumprimento das responsabilidades. Ao longo do tempo, a
necessidade deste direito deve ser reduzida e em muitos casos substituída por
certificações do provedor, relacionadas com as nossas recomendações para o escopo
da ISO/IEC 27001 que serão apresentadas posteriormente.
 Analisar o Escopo de Conformidade. Determinar se os regulamentos de

conformidade aos quais a organização está sujeita serão impactados pelo uso dos
serviços de Computação em Nuvem para um dado conjunto de aplicações e dados.
 Analisar o Impacto dos Regulamentos Sobre a Segurança dos Dados. Potenciais

usuários finais dos serviços de Computação em Nuvem devem ponderar quais
aplicações e dados estão sendo considerados para serem movidos para serviços de
Computação em Nuvem e em que medida eles estão sujeitos aos regulamentos de
conformidade.

 Revisar Parceiros e Provedores de Serviços Importantes. Esta é a recomendação geral
para assegurar que relacionamentos com provedores de serviços não afetem
negativamente a conformidade. Avaliar quais provedores estão processando os dados
sujeitos aos regulamentos de conformidade e então avaliar os controles de segurança
oferecidos pelos mesmos é fundamental. Muitas normas de conformidade têm
linguagens específicas na avaliação e na gestão de riscos de terceiros. Tal como
acontece com serviços de Tecnologia da Informação e com negócios não ligados à
Computação em Nuvem, organizações têm necessidade de entender quais de seus
parceiros de negócios estão processando dados relacionados à normas de
conformidade.
 Entender as Responsabilidades Contratuais Sobre a Proteção de Dados e os Contratos

Relacionados. O modelo de serviços de Computação em Nuvem determina, de uma
certa forma, se o cliente ou o provedor de serviços é responsável pela implantação de
controles de segurança. Em um cenário de implantação de IaaS, o cliente tem um alto
grau de controle e uma maior responsabilidade do que em um cenário de implantação
de SaaS. Do ponto de vista do controle de segurança, isto significa que clientes IaaS
terão que implantar muitos dos controles para a conformidade regulatório. Em um
cenário SaaS, o provedor de serviços de Computação em Nuvem deve fornecer os
controles necessários. De uma perspectiva contratual é importante entender os
requisitos específicos e garantir que o contrato de serviços, bem como os acordos de
nível de serviço, sejam tratados adequadamente.
 Analisar o Impacto das Regulamentações na Infraestrutura do Provedor. Na área de

infraestrutura, mover-se para serviços de Computação em Nuvem também requer
uma análise cuidadosa. Alguns requisitos regulatórios especificam controles que são
difíceis ou impossíveis de se atingir em certos tipos de serviços de nuvem.
 Analisar o Impacto de Regulamentações em Políticas e Procedimentos. Mover dados

e aplicações para serviços de Computação em Nuvem provavelmente causará um
impacto em políticas e procedimentos. Os clientes devem avaliar quais políticas e
procedimentos relacionados com regulamentações terão de ser alterados. Exemplos
de políticas e procedimentos impactados incluem relatórios de atividades, logs,
retenção de dados, resposta a incidentes, controles de testes e políticas de
privacidade.
 Preparar Evidências de como cada Exigência Está Sendo Cumprida. Coletar

evidências de conformidade através da multiplicidade de regulamentos e de requisitos
é um desafio. Clientes dos serviços de Computação em Nuvem devem desenvolver
processos para coletar e armazenar evidências de conformidade, incluindo logs de
auditoria e relatórios de atividades, cópias das configurações dos sistemas, relatórios
de gestão de mudanças e resultados de outros procedimentos de teste. Dependendo do
modelo de serviço o provedor pode precisar fornecer muitas dessas informações.
 Seleção e Qualificação de Auditores. Em muitos casos a organização não tem

nenhuma influência na seleção de auditores ou avaliadores de segurança. Se uma
organização participa da seleção, é altamente recomendável escolher um auditor que
conheça Computação em Nuvem, uma vez que muitos podem não estar
familiarizados com os desafios da virtualização e da Computação em Nuvem.

Questionar sua familiaridade com as nomenclaturas IaaS, PaaS e SaaS é um bom
ponto de partida.
 Provedores de Computação em Nuvem da Categoria SAS 70 Tipo II. Os provedores

devem ter, no mínimo, esta homologação, pois ela proporcionará um ponto de
referência reconhecido para auditores e avaliadores. Uma vez que auditorias SAS 70
Tipo II garantem apenas que os controles estão implementados como foram
documentados, é igualmente importante entender o escopo da auditoria SAS 70 e se
esses controles estão adequados aos seus requisitos.
 Roteiro de Certificação ISO/IEC 27001/27002 dos Provedores de Computação em

Nuvem. Provedores que buscam o fornecimento de serviços de missão crítica devem
adotar os padrões da ISO/IEC 27001 para sistemas de gerenciamento de segurança da
informação. Se o provedor não tiver alcançado a certificação ISO/IEC 27001, ele
deve demonstrar alinhamento com as práticas da ISO 27002.
 Escopo da ISO/IEC 27001/27002. A Cloud Security Alliance está emitindo uma

chamada na industria para alinhar provedores de Computação em Nuvem com a
certificação ISO/IEC 27001, para garantir que o escopo não omita critérios críticos da
certificação.
Colaboradores da Versão Original: Nadeem Bukhari, Anton Chuvakin, Peter Gregory, Jim
Hietala, Greg Kane, Patrick Sullivan
Colaboradores da Versão Brasileira: Alexandre Pupo, Ricardo Makino

Domínio 5: Gerenciamento do Ciclo de Vida das Informações
Um dos principais objetivos da segurança da informação é proteger os dados fundamentais que
suportam nossos sistemas e aplicações. Durante a transição para Computação em Nuvem, nossos
métodos tradicionais de proteção à informação são desafiados por arquiteturas baseadas na
nuvem. Elasticidade, multilocação, novas arquiteturas físicas e lógicas e controles abstratos
exigem novas estratégias de segurança de dados. Com muitas implementações de Computação
em Nuvem, nós estamos transferindo dados para ambientes externos – ou mesmo públicos - o que
seria impensado há poucos anos atrás.
Gerenciamento do Ciclo de Vida das Informações
O Ciclo de Vida da Segurança de Dados é diferente do Gerenciamento do Ciclo de Vida das

Informações, refletindo as diferentes necessidades do público de segurança. O Ciclo de Vida da
Segurança de Dados consiste de seis fases:
Figura 8 – Ciclo de vida da segurança de dados
Os desafios-chave relativos ao ciclo de vida da segurança de dados na nuvem incluem os

seguintes:
Segurança de dados. Confidencialidade, Integridade, Disponibilidade, Autenticidade,

Autorização, Autenticação e Irretratabilidade (não-repúdio).
Localização dos dados. Deve-se ter certeza que os dados, incluindo todas as suas cópias e
backups, estejam armazenados somente em localizações geográficas permitidas por contrato, SLA
e/ou regulação. Por exemplo, uso de armazenamento tal como exigido pela União Europeia para

armazenamento eletrônico de registros de saúde pode ser um desafio adicional para o proprietário
dos dados e provedores de serviço de nuvem.
Remanescência ou persistência de dados. Dados devem ser efetivamente e completamente

removidos para serem considerados “destruídos”. Portanto, técnicas para localizar completamente
e efetivamente dados que estejam na nuvem, apagar/destruir dados e assegurar que tenham sido
completamente removidos ou tornados irrecuperáveis devem estar disponíveis e ser usadas
quando exigido.
Mescla de dados com outros clientes da nuvem. Dados – especialmente dados classificados
/sensíveis – não devem ser mesclados com dados de outros clientes sem controles de
compensação enquanto em uso, armazenados ou em trânsito. A mistura ou mescla de dados será
um desafio quando as preocupações quanto à segurança de dados e à geolocalização aumentam.
Esquemas de backup e recuperação de dados para recuperação e restauração. Os dados

devem estar disponíveis e esquemas de backup e recuperação para Computação em Nuvem
devem estar ativos e efetivos, objetivando prevenir perda de dados, sobrescrita e destruição não
intencional de dados. Não assuma que dados baseados em Computação em Nuvem estejam a
salvo e sejam recuperáveis.
Descoberta de dados. Como o sistema legal continua focando a descoberta eletrônica de dados,
provedores de serviço de Computação em Nuvem e proprietários de dados necessitarão focar em
descoberta de dados, assegurando às autoridades legais e regulatórias que todos os dados
requisitados tenham sido obtidos. Em um ambiente de Computação em Nuvem esta questão é
extremamente difícil de ser respondida e exigirá controles administrativos, técnicos e legais
quando requerido.
Agregação e inferência de dados. Com dados na nuvem, existem preocupações adicionais de

inferência e agregação de dados que poderão resultar em violação de confidencialidade de
informações sensíveis e confidenciais. Portanto, devem ser definidas práticas que garantam ao
proprietário dos dados e às partes interessadas (stakeholders) que os dados ainda estejam
protegidos de uma súbita “violação” quando estiverem sendo mesclados e/ou agregados para
suportar outros sistemas que não o seu principal, revelando assim informação protegida (p. ex.,
dados médicos contendo nomes e informações médicas misturados com dados anônimos mas,
contendo o mesmo “campo de correlação”).
Recomendações
 Entenda como a integridade é mantida e como o comprometimento da integridade é

detectado e informado aos clientes. A mesma recomendação aplica-se à
confidencialidade quando apropriado.
 O provedor de serviço de nuvem deverá assegurar ao proprietário dos dados que eles
proveem divulgação de todas as suas informações (full disclosure) (também conhecida
como “transparência”) relativas às práticas e procedimentos de segurança de acordo com
o estabelecido em seus SLAs.
 Garantir a identificação específica de todos os controles usados durante o ciclo de vida

dos dados. Garanta as especificações de qual entidade é responsável por cada controle
entre o proprietário dos dados e o provedor de serviços de nuvem.

 Mantenha uma filosofia fundamentada no conhecimento de onde seus dados estão.
Assegure sua habilidade de conhecimento sobre a localização geográfica de
armazenamento. Estipule isto em seus SLAs e contratos. Garanta que controles
apropriados relativos às restrições de cada país envolvido no serviço estejam definidos e
reforçados.
 Entenda as circunstâncias pelas quais o armazenamento possa ser apreendido por um

terceiro ou entidade governamental. Verifique se seu SLA com o provedor de serviço de
nuvem inclui processo de notificação prévia ao proprietário dos dados (se possível) que
as informações do proprietário dos dados tenham sido ou serão apreendidas.
 Em alguns casos, uma intimação ou citação de e-discovery pode ser interposta contra o
provedor de serviços de Computação em Nuvem. Neste caso, quando o provedor possuir
custódia dos dados do cliente, o provedor de serviços de Computação em Nuvem deverá
ser forçado a informar ao proprietário dos dados que o provedor de serviços de
Computação em Nuvem será obrigado a divulgar a informação do proprietário dos dados.
 O sistema de penalidades de serviço deverá ser incluído no contrato entre o proprietário

dos dados e o provedor de serviços de nuvem. Especificamente, dados que seriam objetos
de infrações contra disposições legais estaduais e internacionais (por ex., California
Senate Bill 1386 ou as novas regras de violação de dados HIPAA) deverão ser protegidas
pelo provedor de serviços de nuvem.
 Será do proprietário dos dados a responsabilidade de determinar quem deverá acessar os

dados, quais serão seus direitos e privilégios e sob quais condições estes direitos de
acesso serão providos. O proprietário dos dados deverá manter uma política de “Negar
Tudo por Padrão” para ambos os funcionários do proprietário dos dados e os do provedor
de serviços de nuvem.
 Provedores de serviços de Computação em Nuvem deverão oferecer linguagem

contratual que garanta a negação de acesso aos dados como uma filosofia fundamental
(por ex., “Negar Tudo por Padrão”). Isto especificamente aplica-se aos funcionários de
serviços de Computação em Nuvem e seus outros clientes, exceto os funcionários e
pessoal autorizado pelo proprietário dos dados.
 É responsabilidade do proprietário dos dados definir e identificar a classificação dos

dados. É responsabilidade do provedor de serviços de Computação em Nuvem fazer valer
os requisitos de acesso do proprietário dos dados, baseados na classificação dos dados.
Tais responsabilidades deverão estar em contrato, reforçadas e auditadas para
conformidade.
 Quando um cliente é obrigado a divulgar informação, a contaminação de dados não

deverá ocorrer. Não somente o proprietário dos dados precisará garantir que todos os
dados requeridos por mandado de busca e apreensão, intimações, decisões de e-discovery,
etc. estejam intactos e sejam divulgados apropriadamente; o proprietário dos dados
deverá certificar-se que nenhum outro dado seja afetado.
 Criptografia de dados no “Cripografia de dados armazenados e criptografia de dados em

trânsito” (Domínio de Referência 11, Criptografia e Gerenciamento de Chaves.)
 Identifique limites de confiança através da arquitetura de TI e camadas de abstração.

Possibilite aos subsistemas somente transpor os limites de confiança quando necessário e

com apropriadas contramedidas para prevenir divulgação não autorizada, alteração ou
destruição de dados.
 Entenda quais técnicas de compartimentalização são aplicadas por um provedor para

isolar seus clientes uns dos outros. Um provedor poderá utilizar uma variedade de
métodos dependendo dos tipos e quantidade de serviços oferecidos.
 Entenda as capacidades e limitações de busca de dados do provedor de serviço de nuvem

quando tentar visualizar ‘dentro’ da série de dados para descoberta de dados.
 Entenda como a criptografia é gerenciada em armazenamento de multilocação. Existe

uma chave única para todos os proprietários de dados, uma chave por proprietário de
dados ou múltiplas chaves por proprietário de dados? Há um sistema para prevenir
diferentes proprietários de dados de possuir as mesmas chaves de criptografia?
 Os proprietários de dados deverão exigir que os provedores de serviço de Computação

em Nuvem garantam que seus dados de cópias de segurança não estejam misturados com
os dados de outro cliente de serviço de nuvem.
 Entenda o processo de descarte de dados armazenados pelo provedor de serviço de

nuvem. Destruição de dados é extremamente difícil em um ambiente de multilocação e o
provedor de serviço de nuvem deverá estar usando criptografia forte no armazenamento
que resulte em dados não legíveis quando o armazenamento for reciclado, descartado ou
acessado de qualquer maneira fora das aplicações, processos e entidades autorizadas.
 Escalonamento de retenção e destruição de dados são responsabilidades do proprietário

dos dados. É responsabilidade do provedor de serviço de Computação em Nuvem destruir
os dados quando solicitado, com especial ênfase na destruição de todos os dados em
todas as localizações, incluindo as “folgas” de armazenamento em estruturas de dados e
em mídia. O proprietário da informação deverá reforçar e auditar esta prática se possível.
 Entenda a segregação lógica de informação e os controles de proteção implementados.
 Entenda as restrições de privacidade inerentes aos dados confiados a sua companhia;

você poderá ter que designar seu provedor de serviço de nuvem como um tipo particular
de parceiro antes de confiar-lhes esta informação.
 Entenda as políticas e processos do provedor de serviço de nuvem para retenção e

destruição de dados e como eles se comparam à sua política organizacional interna.
Esteja ciente que garantir a retenção de dados pode ser mais fácil para o provedor de
serviço de nuvem demonstrar, enquanto para destruição de dados pode ser muito difícil.
 Negocie penalidades pagas pelo provedor de serviço de nuvem para violação de dados
para garantir que isso seja levado a sério. Se viável, clientes deverão buscar
ressarcimento de todos os custos por violações como parte de seus contratos com
provedor. Se inviável, clientes deverão explorar outros meios de transferência de risco
tais como seguro para recuperação de perdas por violação.
 Execute testes regulares de backup e recuperação para assegurar que a segregação lógica
e os controles são efetivos.

 Garanta que o pessoal do provedor de serviço de nuvem esteja disponível para prover
uma segregação lógica de funções.
 Entenda como criptografia é gerenciada em armazenamento de multilocação. Há uma

única chave para todos os clientes, uma chave por cliente, ou múltiplas chaves por
cliente?
Recomendações de Segurança de Dados por fase de GCVI
Algumas de nossas recomendações gerais, assim como outros controles específicos, são listadas
dentro do contexto de cada fase do ciclo de vida. Por favor, tenha em mente que dependendo do
modelo de serviço de Computação em Nuvem (SaaS, PaaS ou IaaS), algumas recomendações
necessitarão ser implementadas pelo cliente e outras deverão ser implementadas pelo provedor de
serviço de nuvem.
Crie
 Identifique capacidades disponíveis de identificação e classificação de dados.
 Soluções de gestão de permissões empresariais pode ser uma solução.
 O uso de rótulos (tagging) de dados está se tornando comum em ambientes Web

2.0 e pode ser usado como modelo para ajudar a classificação da informação
Armazene
 Identifique controles de acesso disponíveis nos ambientes de sistemas de
arquivos, DBMS, sistemas de gestão de documentos, etc.
 Soluções de criptografia, como aplicadas em correios eletrônicos, redes, bancos

de dados, arquivos e sistemas de arquivos.
 Ferramentas de proteção a conteúdos (como DLP, ou Data Loss Prevention)

podem auxiliar identificando e auditando dados que necessitem de controles.
Uso
 Monitoramento de sistemas e aplicações via correlação de logs e/ou ferramentas
baseadas em agentes
 Lógica de aplicações
 Controles em níveis de objetos em soluções baseadas em DBMS
Compartilhamento
 Monitoramento de sistemas e aplicações via correlação de logs e/ou ferramentas
baseadas em agentes
 Lógica de aplicações
 Controles em níveis de objetos em soluções baseadas em DBMS
 Identifique controles de acesso disponíveis nos ambientes de sistemas de

arquivos, DBMS, sistemas de gestão de documentos, etc.

 Soluções de criptografia, como aplicadas em correios eletrônicos, redes, bancos
de dados, arquivos e sistemas de arquivos.
 Ferramentas de proteção a conteúdos (como DLP, ou Data Loss Prevention)

podem auxiliar identificando e auditando dados que necessitem de controles.
Armazenamento
 Criptografia, como aplicada em fitas de backup e outros sistemas de
armazenamento de alta capacidade.
 Gestão e monitoramento de ativos
Descarte
 Crypto-shredding: Descarte de todos os dados principais relacionados à
informações criptografadas
 Descarte seguro através de limpeza de discos e técnicas relacionadas
 Destruição física, como desmagnetização de mídias.
 Tentativa de identificação de conteúdo para assegurar o processo de descarte.
Colaboradores da Versão Original: Richard Austin, Ernie Hayden, Geir Arild Engh-
Hellesvik, Wing Ko, Sergio Loureiro, Jesus Luna Garcia, Rich Mogull, Jeff Reich
Colaboradores da Versão Brasileira: Filipe Villar, Gilberto Sudré, Guilherme Bitencourt,

Roney Médice, Uélinton Santos

Domínio 6: Portabilidade e Interoperabilidade
As organizações devem considerar a adoção de uma nuvem compreendendo que talvez elas
tenham que mudar seus provedores futuramente. Portabilidade e interoperabilidade devem ser
consideradas desde o início como parte do gerenciamento de risco e da garantia da segurança de
quaisquer programas de adoção de uma nuvem.
Grandes provedores de Computação em Nuvem podem oferecer redundância geográfica na

nuvem, na esperança de garantir alta disponibilidade com um único provedor. No entanto, é
aconselhável que um plano básico de continuidade seja feito, para ajudar a minimizar os impactos
em um cenário de desastre. Diversas empresas, no futuro, inesperadamente irão se deparar com a
necessidade de trocar de provedor por várias razões, incluindo:
 Um aumento inaceitável nos custos de renovação de contrato.

 Um provedor encerra suas operações de negócio.
 Um provedor cancela repentinamente um ou mais serviços que estão sendo utilizados,
sem um plano de migração aceitável.
 Uma queda inaceitável na qualidade do serviço, como uma falha no cumprimento dos
requisitos de desempenho ou para alcançar os acordos de níveis de serviço (SLAs).
 Uma disputa comercial entre o cliente e o provedor da nuvem.
Algumas considerações arquiteturais simples podem ajudar a minimizar os danos causados

quando estes tipos de cenários ocorrerem. Entretanto, os meios para lidar com essas questões
dependem do tipo de serviço na nuvem.
Com o Software como um Serviço (SaaS), o cliente da nuvem, por definição, substitui os novos
softwares pelos antigos. Portanto, o foco não está na portabilidade das aplicações, mas em
preservar ou melhorar as funcionalidades de segurança providas pela aplicação legada e conseguir
uma migração dos dados bem sucedida.
Com a Plataforma como um Serviço (PaaS), a expectativa é que algum grau de modificação na
aplicação seja necessário para atingir a portabilidade. O foco é minimizar a quantidade de
recodificação da aplicação, enquanto os controles de segurança são mantidos ou melhorados,
juntamente com uma migração dos dados bem sucedida.
Com a Infraestrutura como um Serviço (IaaS), o foco e a expectativa é que ambas, aplicações e
dados, sejam capazes de serem migrados e executados em um novo provedor de nuvem.
Devido a uma falta de padrões de interoperabilidade e à falta de pressão suficiente do mercado

para a criação desses padrões, a transição entre provedores de nuvem pode se transformar em um
doloroso processo manual. A partir de uma perspectiva de segurança, nossa principal
preocupação é manter a consistência dos controles de segurança enquanto mudamos o ambiente.
Recomendações
Para Todas as Soluções de Computação em Nuvem:
 A substituição do provedor de serviços de nuvem é, em praticamente todos os casos,

uma transação de negócios negativa para pelo menos uma das partes, o que pode causar
uma reação inesperada do antigo provedor da nuvem. Isto deve ser planejado no

processo de contratação, conforme descrito no Domínio 3, no seu plano de continuidade
de negócios, descrito no Domínio 7 e como parte da sua governança global no Domínio
2.
 Entender o tamanho dos conjuntos de dados hospedados em um provedor de nuvem. O

tamanho dos dados pode causar uma interrupção do serviço durante a transição, ou um
período de transição maior do que o previsto. Muitos clientes descobriram que
transportar os discos rígidos pode ser mais rápido do que a transmissão eletrônica de
grandes massas de dados.
 Documentar a arquitetura de segurança e a configuração individual de cada componente

de controle de segurança, de forma que eles possam ser utilizados para ajudar nas
auditorias internas, bem como para facilitar a migração para novos provedores.
Para Soluções em Nuvem IaaS:
 Entender como imagens de máquinas virtuais podem ser capturadas e portadas para o
novo provedor de nuvem que pode utilizar uma tecnologia diferente de virtualização.
 Identificar e eliminar (ou pelo menos documentar) todas as extensões específicas do

provedor no ambiente de máquina virtual.
 Entender quais práticas são utilizadas para garantir uma desalocação apropriada das
imagens depois que uma aplicação é portada de um provedor de nuvem.
 Compreender as práticas utilizadas para o desmantelamento dos discos e dispositivos de

armazenamento.
 Identificar e entender as dependências baseadas em Hardware/Plataforma antes de

migrar a aplicação/dados.
 Solicitar acesso a logs do sistema, rastros e registros de acesso e de faturamento do

provedor de nuvem antigo.
 Identificar opções para continuar ou expandir o serviço com o provedor de nuvem

legado, em parte ou no todo, caso o novo serviço demonstre ser inferior.
 Determinar se existem quaisquer funções de nível gerencial, interfaces ou APIs

utilizadas que são incompatíveis ou não implantadas no novo provedor.
Para Soluções em Nuvem PaaS:
 Quando possível, utilize componentes de uma plataforma com sintaxes padronizadas,

APIs abertas e normas abertas.
 Entender quais ferramentas estão disponíveis para a transmissão segura dos dados, para
backup e para restauração.

 Entender e documentar os componentes da aplicação e módulos específicos para o
provedor de PaaS e desenvolver a arquitetura de uma aplicação com camadas de
abstração para minimizar o acesso direto aos módulos proprietários.
 Compreender como serviços básicos como monitoramento, logs e auditoria podem ser
transferidos para o novo provedor.
 Entender as funções de controle fornecidas pelo provedor de nuvem antigo e como será
feita a transferência para o novo provedor.
 Quando migrar para uma nova plataforma, conheça os impactos no desempenho e na

disponibilidade da aplicação e como estes impactos são calculados.
 Entender como testes são completados antes e depois da migração, para verificar se os
serviços ou aplicações estão operando corretamente. Garantir que a responsabilidade de
testar, de ambos, provedor e usuário, são bem conhecidas e documentadas.
Para Soluções em Nuvem SaaS:
 Executar extrações de dados e backups regulares para formatos que possam ser
utilizados fora do provedor de SaaS.
 Entender se os metadados podem ser preservados e migrados.
 Compreender que todas as ferramentas personalizadas terão que ser recodificadas ou, o
novo provedor deve fornecer novas ferramentas.
 Assegurar consistência eficaz dos controles entre o antigo e o novo provedor.
 Assegurar a possibilidade de migração de backups e outras cópias de logs, registros de

acesso e qualquer outra informação pertinente que possa ser necessária por razões legais
e conformidade.
 Entender o gerenciamento, o monitoramento e as interfaces de relatórios e suas

integrações entre os ambientes.
 Há uma disposição do novo provedor de testar e avaliar a aplicação antes da migração?
Colaboradores da Versão Original: Warren Axelrod, Aradhna Chetal, Arthur Hedge,

Dennis Hurst, Sam Johnston, Scott Morrison, Adam Munter, Michael Sutton, Joe Wallace
Colaboradores da Versão Brasileira: Alexandre Pupo, Guilherme Ostrock, Ricardo

Makino

Seção III. Operando na Nuvem

Domínio 7: Segurança Tradicional, Continuidade de Negócios e
Recuperação de Desastres
O conjunto de conhecimentos acumulados no âmbito da segurança física tradicional, do
planejamento de continuidade de negócios e da recuperação de desastres ainda é bastante
relevante para a Computação em Nuvem. O ritmo acelerado das mudanças e a falta de
transparência inerentes da Computação em Nuvem exigem que profissionais tradicionais de
Segurança, Planejamento de Continuidade de Negócios e de Recuperação de Desastres estejam
continuamente envolvidos no controle e monitoração dos seus provedores de nuvem escolhidos.
Nosso desafio é colaborar na identificação de risco, reconhecer interdependências, integrar e

alavancar os recursos de forma dinâmica e poderosa. A Computação em Nuvem e a infraestrutura
que a acompanha ajudam a diminuir determinados problemas de segurança, mas podem aumentar
outros e podem nunca eliminar a necessidade de segurança. Enquanto continuam a existir grandes
mudanças nos negócios e na tecnologia, os princípios tradicionais de segurança permanecem os
mesmos.
Recomendações
 Tenha em mente que a centralização dos dados significa que o risco de fraude interna
partindo de dentro do provedor de serviços de nuvem é uma preocupação significativa.
 Provedores de serviço de nuvem devem considerar adotar como padrão de segurança os

requisitos mais rigorosos dos clientes. Para que o alcance dessas práticas de segurança
não impacte negativamente na experiência do cliente, as práticas de segurança mais
rigorosas devem se mostrar economicamente eficazes no longo prazo em termos de
redução do risco, bem como na avaliação das várias áreas de preocupação, baseada nas
necessidades dos clientes.
 Os provedores devem ter uma segregação robusta das responsabilidades das funções,
verificar os antecedentes dos funcionários, exigir / aplicar acordos de não-divulgação de
dados para os seus funcionários e limitar o acesso às informações dos clientes aos
funcionários na medida do que for absolutamente necessário para a execução de suas
funções.
 Os clientes devem efetuar inspeções aos locais das instalações de seu provedor de
nuvem sempre que possível.
 Os clientes devem inspecionar os planos de recuperação de desastres e de continuidade

de negócios de seus provedores de nuvem.
 Os clientes devem identificar as interdependências físicas na infraestrutura do provedor.
 Garantir que há um detalhamento formal estabelecido no contrato para definir

claramente as obrigações contratuais relacionadas com segurança, recuperação e acesso
aos dados.
 Clientes devem solicitar a documentação dos controles de segurança internos e externos

do provedor e a adesão aos padrões da indústria.

 Assegurar que Objetivos de Tempo de Recuperação (Recovery Time Objectives, ou
RTO) do cliente são totalmente compreendidos e definidos nas relações contratuais e
baseados no processo de planejamento tecnológico. Certifique-se que roadmaps,
políticas e capacidades operacionais satisfaçam estes requisitos.
 Clientes precisam confirmar que o provedor tem uma política de Plano de Continuidade
de Negócios aprovada pelo conselho de administração do provedor.
 Clientes devem procurar evidências de apoio efetivo da gestão e revisão periódica do

Programa de Continuidade de Negócios para garantir que este esteja ativo.
 Clientes devem verificar se o Programa de Continuidade de Negócios é certificado e /

ou mapeado com normas internacionalmente reconhecidas como a BS 25999.
 Clientes devem verificar se o provedor tem algum recurso on-line dedicado à segurança
e BCP, onde a visão geral do programa e as fichas técnicas estejam disponíveis para
consulta.
 Certifique-se que os provedores de serviço de nuvem sejam controlados através do

Processo de Segurança de Fornecedores (Vendor Security Process - VSP) para que haja
uma clara compreensão de quais dados devem ser compartilhados e quais controles
devem ser utilizados. As determinações do VSP devem alimentar o processo de tomada
de decisão e avaliação se o risco é aceitável ou não.
 A natureza dinâmica da Computação em Nuvem e sua relativa juventude justificam

ciclos mais frequentes de todas as atividades acima para a descoberta de mudanças não
comunicadas aos clientes.
Colaboradores da Versão Original: Randolph Barr, Luis Morales, Jeff Spivey, David Tyson
Colaboradores da Versão Brasileira: Anchises Moraes, Rafael B. Brinhosa

Domínio 8: Operações e Data center
O número de provedores de Computação em Nuvem continua a aumentar à medida que empresas
e consumidores de serviços de TI se movem para a nuvem. Houve um crescimento similar
em data centers para atender à prestação de serviços de Computação em Nuvem. Provedores
de nuvem de todos os tipos e tamanhos, inclusive líderes de tecnologia e milhares de iniciantes e
empresas emergentes estão fazendo grandes investimentos nesta nova abordagem promissora para
a prestação de serviços de TI.
O compartilhamento de recursos de TI para criar eficiências e economias de escala não é um

conceito novo. No entanto, o modelo de negócio na nuvem funciona melhor se os grandes
investimentos, tradicionalmente, em operações de data centers são distribuídos a um número
maior de consumidores. Historicamente, arquiteturas de data center foram deliberadamente
superdimensionadas para superar picos de carga periódicos, o que significa que os recursos
do Data center devem estar frequentemente sem utilização ou subutilizados, por longas extensões
de tempo, durante os períodos de demanda baixa ou normal. Provedores de serviço de nuvem, por
outro lado, procuram otimizar o uso de recursos, tanto humanos quanto tecnológicos, a fim de
ganhar vantagem competitiva e maximizar as margens de lucro na operação.
O desafio para consumidores de serviços de nuvem é descobrir o modo de avaliação das

capacidades do provedor para executar serviços apropriados e de baixo custo, não deixando de
proteger os próprios dados e interesses do cliente. Não presuma que o provedor tenha os melhores
interesses de seus clientes como sua prioridade máxima. Com o modelo comum de operadora
(carrier) para entrega de serviços, do qual a Computação em Nuvem é uma forma, o provedor de
serviço normalmente tem pouco ou nenhum acesso aos dados e sistemas que se situam além do
nível contratado de gerenciamento, tampouco tem controle sobre eles. Certamente essa é a
abordagem correta a se ter, mas algumas arquiteturas em nuvem tomam liberdades com a
integridade e a segurança dos dados dos clientes que os deixariam desconfortáveis se delas eles
estivessem cientes. Os consumidores devem educar-se acerca dos serviços sobre os quais estão
pensando em contratar para fazerem perguntas apropriadas e, se familiarizarem com as
arquiteturas básicas e as áreas com potenciais de vulnerabilidade de segurança.
Ao tomar a decisão de mover toda ou parte das operações de TI para a nuvem, é útil
primeiramente entender como um provedor de nuvem implementou as “Cinco Principais
Características da Computação em Nuvem” do Domínio 1 e como essa arquitetura e
infraestrutura tecnológica afeta a sua habilidade de satisfazer os acordos de nível de serviço e de
endereçar preocupações com a segurança. A tecnologia específica da arquitetura tecnológica do
provedor pode ser uma combinação de produtos de TI e outros serviços de nuvem como, por
exemplo, se aproveitar vantajosamente do serviço de armazenamento IaaS de outro provedor.
A arquitetura e a infraestrutura tecnológica dos provedores de serviço de nuvem podem variar,

mas para satisfazer requisitos de segurança, todos eles devem poder demonstrar
compartimentalização abrangente dos sistemas, dados, redes, gerenciamento, fornecimento e
pessoal. Os controles separando cada camada da infraestrutura devem ser propriamente
integrados para que elas não interfiram umas com as outras. Por exemplo, investigue se a
compartimentagem do armazenamento pode ser facilmente ignorada por ferramentas de gestão ou
mau gerenciamento de chaves.
Por último, compreenda como o provedor de nuvem lida com a democratização e dinamismo dos
recursos para melhor prever os níveis apropriados de disponibilidade do sistema e de desempenho

durante as flutuações normais de negócio. Lembre-se, a teoria de Computação em Nuvem ainda
excede, em alguma medida, a prática: muitos clientes fazem pressuposições incorretas sobre o
nível de automação atualmente disponível. Na medida em que o recurso provisionado é
consumido, o provedor é responsável por garantir que recursos adicionais são alocados
imperceptivelmente para o cliente.
Recomendações
É imperativo que uma organização, considerando a compra de serviços de nuvem, sejam eles de
qualquer tipo, esteja totalmente ciente do tipo exato de serviços que serão contratados e do que
não está incluso. Abaixo está um sumário de informações que precisam ser revisadas como parte
do processo de seleção do vendedor e questões adicionais para ajudar a qualificar os provedores e
comparar melhor os seus serviços com as necessidades da organização.
 Quaisquer que sejam as certificações que os provedores de nuvem mantêm, é importante

obter o compromisso e a permissão de conduzir auditorias feitas pelo cliente ou por
terceiros.
 Os clientes de serviços de nuvem devem compreender como os provedores implementam

as “Cinco Principais Características da Computação em Nuvem” do Domínio 1.
 Ainda que as arquiteturas tecnológicas dos provedores de nuvem variem, todos eles
devem poder demonstrar divisão compreensiva de sistemas, redes, gerenciamento,
provisão e pessoal.
 Compreenda como a democratização de recursos ocorre dentro da nuvem de seu provedor

para prever melhor a disponibilidade e desempenho do sistema durante suas flutuações de
negócios. Se possível, descubra os outros clientes do provedor de nuvem para avaliar o
impacto que as flutuações de negócios deles podem ter sobre a sua vivência como cliente
do provedor de nuvem. No entanto, isso não substitui a garantia de que os acordos acerca
do nível de serviço estejam claramente definidos, mensuráveis, executáveis e adequados
para a sua necessidade.
 Os clientes dos serviços de nuvem devem entender as políticas e procedimentos de

correção do provedor e como eles podem influenciar os seus ambientes. Essa
compreensão deve estar refletida no contrato.
 A contínua melhoria é particularmente importante em um ambiente de nuvem, pois

qualquer melhoria nas políticas, processos e procedimentos, ou ferramentas para um
cliente determinado podem resultar em melhoria do serviço para todos os clientes.
Procure por provedores de nuvem com processos padrão de melhoria contínua.
 Suporte técnico ou central de serviço são frequentemente uma janela pela qual o cliente
pode ver as operações do provedor. Para obter uma experiência de suporte suave e
uniforme para seus usuários finais, é essencial assegurar que os processos,
procedimentos, ferramentas e horário de suporte do provedor são compatíveis com as
suas.
 Como no Domínio 7, reveja os planos de recuperação de desastres e de continuidade do

negócio a partir da perspectiva de TI e perceba como eles se relacionam com pessoas e

processos. Uma arquitetura tecnológica do provedor de nuvem pode usar novos métodos,
porém não testados para tolerância a falhas, por exemplo. A continuidade do próprio
negócio do cliente deve também abranger os impactos e limitações da Computação em
Nuvem.
Colaboradores da Versão Original: John Arnold, Richard Austin, Ralph Broom, Beth Cohen,
Wing Ko, Hadass Harel, David Lingenfelter, Beau Monday, Lee Newcombe, Jeff Reich,
Tajeshwar Singh, Alexander Windel, Richard Zhao.
Colaboradores da Versão Original: Eder Alvares Pereira de Souza, Olympio Rennó Ribeiro Jr,
Raphael Sanches

Domínio 9: Resposta a Incidente, Notificação e Remediação
O principio de Computação em Nuvem torna difícil determinar quem contatar em caso de
incidente de segurança, vazamento de informação ou qualquer outro evento que necessite de
investigação e resposta. Mecanismos padrão de resposta a incidentes de segurança podem ser
adaptados para acomodar as mudanças requeridas pelas responsabilidades compartilhadas de
notificação. Este domínio provê um guia de como tratar desses incidentes.
O problema para o cliente de Computação em Nuvem é que aplicações disponíveis em

provedores de Computação em Nuvem nem sempre são desenhadas com os princípios de
segurança e integridade de dados em mente. Isso pode resultar em aplicações vulneráveis sendo
implementadas em ambientes de nuvem, desencadeando incidentes de segurança.
Adicionalmente, falhas na arquitetura de infraestrutura, erros cometidos durante procedimentos
de “hardening” e simples descuidos representam riscos significativos para operações em nuvem.
Obviamente, vulnerabilidades semelhantes também põem sob risco operações tradicionais de
data center.
Experiência técnica obviamente é necessária na resposta a incidentes, porém, privacidade e

questões legais têm muito a contribuir para segurança em nuvem. Ela também tem um papel
importante na resposta a incidente referente à notificação, remediação e possível subsequente
ação legal. Uma organização que cogita usar os serviços de Computação em Nuvem precisa
revisar quais mecanismos foram implementados em relação ao acesso a dados de empregados que
não são regidos por contratos de usuário e políticas de privacidade. Dados de aplicação que não
são gerenciados por uma aplicação do próprio provedor de nuvem, tais como IaaS e arquiteturas
PaaS, geralmente têm controles diferentes daqueles gerenciados pela aplicação de um provedor
de SaaS.
As complexidades de grandes provedores de Computação em Nuvem oferecendo SaaS, PaaS e

IaaS criam problemas significativos de resposta a incidente, os quais devem ser analisados por
potenciais clientes para um nível aceitável de serviço. Ao avaliar provedores de nuvem, é
importante ter consciência de que o provedor pode estar hospedando centenas de milhares de
instancias de aplicações. Do ponto de vista de monitoração de resposta a incidente, quaisquer
aplicações externas aumentam a responsabilidade do centro de operações de segurança (do inglês
SOC). Normalmente um SOC monitora os alertas e outros indicadores de incidente, tais como
aqueles produzidos por sistemas de detecção de intrusão e firewalls. Porém, o número de fontes
de informação a serem monitoradas e o volume de notificações pode crescer exponencialmente
num ambiente de “open cloud”, pois o SOC teria que monitorar a atividade entre clientes, assim
como incidentes externos.
Uma organização precisará entender a estratégia de resposta a incidente do provedor escolhido.

Esta estratégia deve endereçar identificação e notificação, assim como oferecer opções para
remedição de acesso não autorizado a dados de aplicação. Para tornar ainda mais complexa, a
gestão de dados de aplicações e acessos têm significados e requisitos regulatórios diferentes
conforme a localização física dos dados. Por exemplo, um incidente pode ocorrer envolvendo
dados armazenados na Alemanha. Se os mesmos dados estivessem sendo armazenados nos
Estados Unidos, esse mesmo evento poderia não ser considerado um incidente. Essa complicação
torna a identificação de incidentes particularmente desafiadora.

Recomendações
 Clientes de Computação em Nuvem precisam definir claramente e comunicar aos

provedores o que eles consideram incidentes (tais como roubo de dados) versus meros
eventos (tais como alertas de suspeita de intrusão) antes de implementar o serviço.
 Clientes de Computação em Nuvem podem vir a ter um envolvimento limitado com as

atividades de resposta a incidente do provedor. Portanto, é crucial para os clientes
entender os canais de comunicação predefinidos para contatar a equipe de resposta a
incidentes.
 Clientes de Computação em Nuvem devem investigar quais ferramentas de detecção e

analise de incidentes o provedor utiliza para garantir que eles sejam compatíveis com
seus próprios sistemas. Um formato de log proprietário ou incomum poderia ser um
grande problema em investigações conjuntas, particularmente aqueles que envolvam
questões legais ou intervenção governamental.
 Sistemas e aplicações desenvolvidas com baixo nível de segurança podem facilmente

sobrecarregar qualquer capacidade de resposta a incidente. A condução de uma avaliação
de riscos adequada nos sistemas e a utilização da prática de segurança em camadas são
essenciais para reduzir as chances de um incidente de segurança.
 Centros de Operações de Segurança (do inglês SOC) normalmente assumem um modelo

único de governança relacionado à resposta a incidente, o qual não é apropriado para
provedores multilocatários de nuvem. Um processo robusto e bem gerenciado de
“Gestão de Eventos e Informações de Segurança - SIEM”, que identifica as fontes
disponíveis de informação (logs de aplicação, logs de firewall, logs de IDS, etc.) e as
combina com uma plataforma comum de analise e notificação, pode ajudar
consideravelmente o SOC na detecção de incidentes dentro da plataforma de Computação
em Nuvem.
 Para facilitar a analise detalhada de informação “off-line”, procure por provedores de

Computação em Nuvem que tenham a habilidade de fornecer “fotografias” do ambiente
virtual do cliente – firewalls, redes (switches), sistemas, aplicações e dados.
 Contenção é uma corrida entre o controle de danos e coleta de evidência. Estratégias de

contenção que foquem na tríade confidencialidade-integridade-disponibilidade podem ser
eficazes.
 Remediação destaca a importância de poder restaurar um sistema para um estado anterior

e até mesmo retornar 6 a 12 meses atrás em uma configuração tida como confiável.
Mantendo em mente as possibilidades e requerimentos legais, a remediação pode também
vir a suportar registros forenses de dados de incidentes.
 Qualquer dado classificado como privado para efeito regulatório em relação a roubo de
informações deve ser sempre criptografado para reduzir as consequências de um
incidente de roubo de dado. Clientes devem estipular os requisitos de criptografia
contratualmente, conforme Domínio 11.

 Alguns provedores de Computação em Nuvem podem hospedar um número significativo
de clientes com aplicações únicas. Esses provedores de Computação em Nuvem devem
considerar estruturas de registros (logging frameworks) de camada de aplicação com o
intuito de rastrear incidentes a um cliente em especifico. Esses provedores de
Computação em Nuvem devem também criar um registro de proprietários das aplicações
por interface de aplicação (URL, serviços de SOA, etc.)
 Firewalls de aplicação, proxies e outras ferramentas de log são capacidades básicas

atualmente disponíveis para suportar a resposta a incidentes em um ambiente
multilocatário.
Colaboradores da Versão Original: John Arnold, Richard Austin, Ralph Broom, Beth Cohen,
Wing Ko, Hadass Harel, David Lingenfelter, Beau Monday, Lee Newcombe, Jeff Reich,
Tajeshwar Singh, Alexander Windel, Richard Zhao
Colaboradores da Versão Brasileira: Filipe Villar, Marcelo Carvalho

Domínio 10: Segurança de Aplicações
Ambientes de nuvem – em virtude de sua flexibilidade, receptividade e frequente disponibilidade
pública - desafiam muitas suposições fundamentais sobre segurança de aplicações. Algumas
destas suposições já são bem compreendidas; no entanto, muitas ainda não são. Esta seção visa
documentar como a Computação em Nuvem influencia a segurança através do tempo de vida de
uma aplicação – desde o design até as operações de desativação. Este guia é para todos os
stakeholders – incluindo desenvolvedores de aplicações, profissionais de segurança, pessoal de
operação e gerenciamento técnico – tratando sobre a melhor forma de mitigar os riscos e
gerenciar garantias em aplicações de Computação em Nuvem.
Computação em Nuvem é um desafio particular para aplicações através das camadas de Software
como um Serviço (SaaS), Platforma como um Serviço (PaaS) e Infraestrutura como um
Serviço(IaaS). Aplicações de software baseadas em nuvem requerem um rigor de design
semelhante a aplicações que residem em uma DMZ clássica. Isto inclui uma profunda análise
inicial cobrindo todos os tradicionais aspectos de confidencialidade, integridade e disponibilidade
do gerenciamento da informação.
Aplicações em ambientes de nuvem irão tanto impactar como serem impactadas pelos seguintes
aspectos principais:
 Arquitetura de Segurança da Aplicação – Considerações devem ser dadas à realidade

de que a maioria das aplicações possui dependências em diversos outros sistemas. Com
Computação em Nuvem, as dependências de aplicações podem ser altamente dinâmicas,
até mesmo ao ponto onde cada dependência represente uma discreta parte de um
provedor de serviço. As características de nuvem fazem o gerenciamento de configuração
e o provisionamento contínuo significativamente mais complexos do que no
desenvolvimento de aplicações tradicionais. O ambiente leva às necessidades de
modificações arquiteturais para garantir segurança de aplicação.
 Ciclo de Vida de Desenvolvimento de Software (SDLC) – A Computação em Nuvem

afeta todos os aspectos do SDLC, abrangendo arquiteturas de aplicativos, projeto,
desenvolvimento, garantia de qualidade, documentação, implantação, gerenciamento,
manutenção e desativação.
 Conformidade – Conformidade claramente afeta os dados, mas também influencia

aplicações (por exemplo, regulando como um programa implementa uma função
criptográfica em particular), plataformas (talvez pela prescrição dos controles e
configurações de sistema operacional) e processos (tais como reportar requisitos para
incidentes de segurança).
 Ferramentas e Serviços – A Computação em Nuvem introduz uma série de novos

desafios ao redor das ferramentas e serviços requeridos para construir e manter as
aplicações em execução. Estes desafios incluem ferramentas de desenvolvimento e teste,
utilitários de gerenciamento de aplicações, o acoplamento com serviços externos e
dependências nas bibliotecas e serviços do sistema operacional, que podem ser originados
de provedores de nuvem. Compreender as ramificações de que provê, detém, opera e
assume a responsabilidade por cada um destes itens é fundamental.

 Vulnerabilidades – Estas incluem não somente as bem documentadas – e continuamente
em evolução – vulnerabilidades associadas com aplicações web, mas também
vulnerabilidades associadas com aplicações SOA máquina-a-máquina, que estão sendo
implantadas de modo crescente na nuvem.
Recomendações
 A segurança no ciclo de vida de desenvolvimento de software (SDLC) é importante e

deve abordar em alto nível estas três principais áreas de diferenciação com
desenvolvimento baseado em nuvem: 1) ameaças atualizadas e modelos de confiança, 2)
ferramentas de avaliação de aplicações para ambientes de nuvem e 3) processos de SDLC
e checkpoints de qualidade para contabilizar mudanças arquiteturais de segurança para
aplicações.
 IaaS, PaaS e SaaS criam diferentes limites de confiança para o ciclo de vida de
desenvolvimento de software; que devem ser contabilizados durante o desenvolvimento,
testes e implantação de aplicações em produção.
 Para IaaS, um fator chave de sucesso é a presença de imagens de máquinas virtuais

confiáveis. A melhor alternativa é a capacidade de fornecer sua própria imagem de
máquina virtual em conformidade com as políticas internas.
 As melhores práticas disponíveis para fortificar sistemas host dentro de DMZs devem ser
aplicadas para máquinas virtuais. Limitar os serviços disponíveis somente aqueles
necessários para suportar a pilha da aplicação é apropriado.
 Proteger a comunicação inter-host deve ser uma regra; não pode haver nenhuma
suposição de um canal seguro entre hosts, quer esteja em um data center comum ou ainda
em um mesmo dispositivo de hardware.
 Gerenciar e proteger credenciais e materiais chave de aplicações são pontos críticos.
 Cuidado adicional deve ser realizado no gerenciamento de arquivos usados para os

registros (logs) e depuração (debugging) das aplicações, bem como a localização destes
arquivos podem ser remotos ou desconhecidos e a informação confidencial.
 Consideração para administração externa e multilocatários nos modelos de ameaça da

aplicação.
 Aplicações suficientemente complexas para influenciar um Enterprise Service Bus (ESB)

precisam proteger diretamente o ESB, influenciando um protocolo, como o WS-Security.
A capacidade de segmentar ESBs não está disponível em ambientes PaaS.
 Métricas precisam ser aplicadas para avaliar a eficácia de programas de segurança de

aplicação. Entre as métricas diretas específicas de segurança disponíveis estão escores de
vulnerabilidade e cobertura de correções. Essas métricas podem indicar a qualidade da
codificação de aplicação. Métricas de manipulação indireta de dados tais como o

percentual de dados cifrados, podem indicar que decisões responsáveis estão sendo
tomadas a partir de uma perspectiva de arquitetura da aplicação.
 Provedores de nuvem devem suportar ferramentas de segurança de análise dinâmica para

aplicações web às aplicações hospedadas em seus ambientes.
 Atenção deve ser dada para como os atores maliciosos irão reagir às novas arquiteturas de
aplicações de nuvem, que obscurecem componentes de aplicações de seus exames
minuciosos. Hackers tendem a atacar códigos visíveis, incluindo, mas não limitado ao
código que está rodando no contexto do usuário. Eles são suscetíveis a atacar
infraestruturas e realizar extensos testes em caixa-preta.
 Clientes devem obter permissão contratual para realizar avaliações de vulnerabilidades

remotas, incluindo a tradicional (rede/host) e avaliações de vulnerabilidades de
aplicações. Muitos provedores de nuvem restringem avaliações de vulnerabilidades
devido à incapacidade do provedor de distinguir tais testes de ataques reais e para evitar
potenciais impactos sobre outros clientes.
Colaboradores da Versão Original: John Arnold, Warren Axelrod, Aradhna Chetal, Justin
Foster, Arthur J. Hedge III, Georg Hess, Dennis Hurst, Jesus Luna Garcia, Scott Matsumoto,
Alexander Meisel, Anish Mohammed, Scott Morrison, Joe Stein, Michael Sutton, James Tiller,
Joe Wallace, Colin Watson
Colaboradores da Versão Brasileira: Gabriel Negreira Barbosa, Jordan M. Bonagura, Luís

Felipe Féres Santos

Domínio 11: Criptografia e Gerenciamento de Chaves
Clientes e provedores de nuvem precisam precaver-se contra perda e roubo de dados. Hoje em
dia, a criptografia de dados pessoais e empresariais é altamente recomendada e, em alguns casos,
exigida por leis e regulamentações ao redor do mundo. Os clientes de nuvem querem que seus
provedores cifrem seus dados para assegurar que os mesmos estejam protegidos não importando
onde estejam localizados fisicamente. Da mesma forma, o provedor de nuvem precisa proteger os
dados sensíveis de seus clientes.
Criptografia forte com gerenciamento de chaves é um dos mecanismos fundamentais que os

sistemas de Computação em Nuvem devem utilizar para proteger dados. Embora a cifragem, por
si só, não necessariamente impeça a perda de dados, as disposições legais e regulamentações
tratam dados cifrados perdidos como se os mesmos não tivessem sido perdidos. A cifragem
fornece proteção de recursos enquanto o gerenciamento de chaves permite o acesso a recursos
protegidos.
Criptografia para Confidencialidade e Integridade
Ambientes de nuvem são compartilhados com muitos locatários e provedores de serviços têm
acesso privilegiado aos dados que estão nesses ambientes. Portanto, os dados confidenciais
hospedados em uma nuvem devem ser protegidos através de uma combinação de controles de
acesso (ver Domínio 12), responsabilidade contratual (ver Domínios 2, 3 e 4) e criptografia, que
descrevemos nesta seção. Destes três pontos, a criptografia oferece os benefícios da mínima
confiança no provedor de serviços de nuvem e da independência em casos de detecção de falhas
operacionais.
Criptografar dados em trânsito através de redes. Existe a extrema necessidade de criptografar

credenciais multiuso em trânsito através da Internet, tais como números de cartão de crédito,
senhas e chaves privadas. Embora as redes de provedores de nuvem possam ser mais seguras que
a Internet aberta, elas são, pela sua própria arquitetura, compostas de muitos elementos diferentes
e diferentes organizações compartilham a nuvem. Por isso, é importante proteger essas
informações sensíveis e regulamentadas em trânsito até mesmo dentro da rede dos provedores de
nuvem. Normalmente, isso pode ser implementado com a mesma facilidade em ambientes SaaS,
PaaS e IaaS.
Criptografar dados em repouso. Criptografar dados em disco ou em um banco de dados de

produção ativo possui valor, visto que isto pode proteger contra um provedor de serviços de
nuvem malicioso ou um colocatário mal-intencionado, bem como contra alguns tipos de abuso de
aplicações. Para o armazenamento de arquivos a longo prazo, alguns clientes criptografam seus
próprios dados e então os enviam como texto cifrado para um fornecedor de armazenamento de
dados em nuvem. O cliente, então, controla e detém as chaves criptográficas e, se necessário,
decifra os dados em seu próprio ambiente. Criptografar dados em repouso é comum dentro de
ambientes IaaS utilizando uma variedade de ferramentas de terceiros e provedores. Criptografar
dados em repouso dentro de ambientes PaaS é, geralmente, mais complexo, necessitando
instrumentação de ofertas do provedor ou customização especial. Criptografar dados em repouso
dentro de ambientes SaaS é um recurso que clientes de nuvem não podem implementar
diretamente e precisam solicitar a seus provedores.

Criptografar dados em mídias de backup. Isto pode proteger contra mau uso de uma mídia
perdida ou roubada. Idealmente, o provedor de serviço de nuvem implementa tal mecanismo de
forma transparente. Entretanto, como cliente e provedor de dados, é sua responsabilidade
verificar que tal criptografia é utilizada. Uma consideração para a infraestrutura de criptografia é
lidar com a longevidade dos dados.
Além desses usos comuns de criptografia, a possiblidade de ataques exóticos contra provedores
de nuvem também justifica uma maior exploração de meios para criptografar dados dinâmicos,
incluindo dados residentes em memória.
Gerenciamento de Chaves
Provedores de serviço de nuvem existentes podem prover esquemas básicos de chaves de

criptografia para proteger o desenvolvimento de aplicações e serviços de nuvem, ou podem
delegar todas essas medidas de proteção para seus clientes. Enquanto provedores de serviço de
nuvem estão progredindo para suportar esquemas robustos de gerenciamento de chaves, mais
trabalho é necessário para superar barreiras para adoção. Padrões emergentes podem solucionar
este problema em um futuro próximo, mas o trabalho ainda está em desenvolvimento. Existem
muitos problemas e desafios de gerenciamento de chaves dentro da Computação em Nuvem:
Repositórios seguros de chaves. Repositórios de chaves devem ser protegidos assim como
qualquer outro dado sensível. Eles devem ser protegidos no armazenamento, no trânsito e nos
backups. O armazenamento impróprio de chaves pode levar ao comprometimento de todos os
dados cifrados.
Acesso aos repositórios de chaves. O acesso a repositórios de chaves deve ser limitado às
entidades que necessitem especificamente de chaves individuais. Devem existir ainda políticas
que utilizem separação de papeis regendo os repositórios de chaves, para auxiliar o controle de
acessos; uma entidade que utiliza uma dada chave não deve ser a mesma entidade que a
armazena.
Backup e recuperação de chaves. Perda de chaves inevitavelmente significa perda dos dados
que as mesmas protegem. Enquanto isso é uma forma efetiva para destruir dados, a perda
acidental de chaves que protegem dados críticos fundamentais de organizações seria devastadora
para um negócio; então, soluções seguras de backup e recuperação devem ser implementadas.
Existem vários padrões e diretrizes aplicáveis ao gerenciamento de chaves na nuvem. O Key

Management Interoperability Protocol (KMIP), da OASIS, é um padrão emergente para um
gerenciamento de chaves interoperável na nuvem. Os padrões IEEE 1619.3 cobrem criptografia
de armazenamento e gerenciamento de chaves, especialmente no que diz respeito a
armazenamento IaaS.
Recomendações
 Utilizar criptografia para separar posse de dados de uso de dados.
 Segregar o gerenciamento de chaves do provedor de nuvem que hospeda os

dados, criando uma cadeia de separação. Isso protege tanto o provedor quanto o cliente

de nuvem de conflitos quando houver obrigação de fornecer dados devido a um
mandato legal.
 Quando estipular a criptografia em linguagem de contrato, assegurar que a

criptografia adira a padrões existentes de indústria e governo, como for aplicável.
 Tomar conhecimento de como, as instalações do provedor de nuvem provêm

gerenciamento de papéis e separação de funções.
 Nos casos onde o provedor de nuvem deve efetuar o gerenciamento de chaves, se

inteirar se o provedor possui processos definidos para um ciclo de vida do
gerenciamento de chaves: como as chaves são geradas, utilizadas, armazenadas,
submetidas a backup, recuperadas, rotacionadas e apagadas. Além disso, tomar
conhecimento se a mesma chave é utilizada para todos os clientes ou se cada cliente
tem seu próprio conjunto de chaves.
 Assegurar que dados regulamentados e/ou sensíveis de clientes sejam

criptografados quando estiverem em trânsito através da rede interna do provedor de
nuvem, além de serem criptografados quando estiverem em repouso. A
responsabilidade de implementar tal recomendação é do cliente de nuvem em ambientes
IaaS, de ambos (provedor e cliente) em ambientes PaaS e do provedor de nuvem em
ambientes PaaS.
 Em ambientes IaaS, se inteirar como informações sensíveis e materiais chave

quando não protegidos por criptografia tradicional podem ser expostos durante o uso.
Por exemplo, arquivos de swap de máquinas virtuais e outros locais temporários de
armazenamento de dados podem também necessitar ser criptografados.
Colaboradores da Versão Original: John Arnold, Girish Bhat, Jon Callas, Sergio Loureiro, Jean
Pawluk, Michael Reiter, Joel Weise
Colaboradores da Versão Brasileira: Dino Amaral, Eder Alvares Pereira de Souza, Gabriel
Negreira Barbosa, Jimmy Cury, Jordan M. Bonagura, Julio Graziano Pontes, Raphael Sanches

Domínio 12: Gerenciamento de Identidade e Acesso.
O gerenciamento de identidades e controle de acesso para aplicações corporativas permanece um
dos maiores desafios enfrentados atualmente por TI. Mesmo que uma empresa possa viabilizar
vários serviços de Computação em Nuvem sem uma boa estratégia de gerenciamento de
identidade e acesso, em longo prazo, estender os serviços de identidade da empresa à nuvem será
um requisito necessário para o uso de serviços de computação sob demanda. Suportar a atual
adoção agressiva de um ecossistema reconhecidamente imaturo de nuvem requer uma sincera
avaliação de quão preparada está a empresa para conduzir o Gerenciamento de Identidade e
Acesso GIA (Identity and Access Management - IAM) baseado na nuvem, assim como entender
as capacidades de seus provedores de serviço de nuvem.
Discutiremos as principais funções do IAM essenciais para o gerenciamento efetivo e bem

sucedido de identidades na nuvem:
 Provisionamento / desaprovisionamento de identidade

 Autenticação
 Federação
 Autorização & gerenciamento de perfil de usuários
Conformidade é uma consideração chave em todos os pontos.
Provisionamento de Identidade: Um dos maiores desafios para a adoção de serviços de

Computação em Nuvem pelas empresas é o gerenciamento seguro e ágil da concessão
(provisionamento) e revogação (desaprovisionamento) de usuários na nuvem. Além disso, as
organizações que investem em processos de gerenciamento de usuários dentro da empresa
buscarão estender esses processos e práticas aos serviços de nuvem.
Autenticação: Quando as organizações começam a utilizar os serviços de nuvem, autenticar

usuários de uma forma confiável e gerenciável é uma exigência vital. As organizações devem
resolver os desafios relacionados à autenticação, como o gerenciamento de credenciais,
autenticação forte (tipicamente definida como autenticação multifator), delegação de autenticação
e gerenciamento de confiança para todos os tipos de serviços de nuvem.
Federação: Em um ambiente de Computação em Nuvem, o Gerenciamento de Identidades

Federadas tem um papel fundamental ao permitir que as organizações autentiquem seus usuários
de serviços de nuvem usando o provedor de identidade por ela escolhido (PId). Nesse contexto,
trocar atributos de identidade entre o provedor de serviços (PS) e o PId de uma forma segura é
também uma exigência importante. As organizações que consideram o gerenciamento de
identidades federadas na nuvem precisam entender os vários desafios e possíveis soluções com
respeito ao gerenciamento do ciclo de vida da identidade, métodos de autenticação disponíveis
para proteger a confidencialidade e a integridade; ao mesmo tempo em que suportam o não-
repúdio.
Autorização & gerenciamento de perfil de usuários: As exigências para a política de controle

de acesso e perfis dos usuários variam conforme o usuário está agindo em nome próprio (como
um consumidor) ou como um membro de uma organização (como um funcionário, universidade,
hospital ou outra empresa). As exigências de controle de acesso em ambientes de SPI incluem
estabelecer o perfil de usuário confiável e a informação da política, usando-os para controlar o
acesso ao serviço de nuvem, executando isto de uma forma auditável.

Provisionamento de Identidade – Recomendações
 As capacidades oferecidas pelos provedores de nuvem atualmente não são adequadas às

exigências das empresas. Os clientes devem evitar soluções proprietárias assim como
criar conectores personalizados unicamente para os provedores de nuvem, já que isto
aumenta a complexidade do gerenciamento.
 Os clientes devem usar conectores padrão fornecidos pelos provedores de nuvem como
uma medida prática, preferencialmente construídos no esquema SPML. Se seu provedor
de nuvem não oferece SPML, você deverá solicitá-lo.
 Os clientes de nuvem devem modificar ou estender seus repositórios autoritativos de

identidade de tal forma que englobem as aplicações e processos na nuvem.
Autenticação – Recomendações
Ambos, provedor de serviços de nuvem e empresas clientes, devem considerar os desafios

associados ao gerenciamento de credenciais e autenticação forte e implementar soluções de baixo
custo que reduzam apropriadamente o risco.
Provedores de SaaS e PaaS fornecem tipicamente duas opções: serviços próprios de autenticação
para suas aplicações ou plataformas, ou delegar a autenticação às empresas.
Os clientes têm as seguintes opções:
√ Autenticação para empresas. As empresas devem considerar autenticar os usuários através de

seus Provedores de Identidade (PId) e estabelecer confiança com o fornecedor de SaaS através da
federação.
√ Autenticação para usuários individuais agindo por conta própria. As empresas devem
considerar usar autenticação centrada em usuário como do Google, Yahoo, OpenID, Live ID, etc.,
para permitir o uso de um conjunto único de credenciais válido para múltiplos sites.
√ Qualquer provedor de SaaS que requeira métodos proprietários para delegar a autenticação (ex.
manipulação de confiança por meio de um cookie criptografado compartilhado ou outros meios)
deve ser cuidadosamente avaliado com uma análise de segurança adequada, antes de continuar. A
preferência geral deve ser para o uso de padrões abertos.
Para IaaS, estratégias de autenticação podem usar as capacidades existentes da empresa.
√ Para o pessoal de TI, estabelecer uma VPN dedicada será uma opção melhor, já que se pode
aproveitar sistemas e processos existentes.
√ Algumas possíveis soluções incluem a criação de um túnel da VPN dedicado para a rede
corporativa ou da federação. Um túnel da VPN dedicado funciona melhor quando a aplicação usa

os sistemas existentes de gerenciamento de identidade (como uma solução de autenticação
baseada em SSO ou LDAP que fornece uma fonte autorizada de dados de identidade).
√ Em casos onde um túnel VPN dedicado não é factível, as aplicações devem ser desenhadas para
aceitar os pedidos de autenticação em vários formatos (SAML, Federação-WS, etc), combinadas
com criptografia padrão de rede como SSL. Esta abordagem permite às organizações implantar
SSO federados não apenas dentro da empresa, mas também para aplicações na nuvem.
√ OpenID é outra opção quando a aplicação é direcionada para além dos usuários corporativos.
Contudo, pelo fato do controle das credenciais do OpenID estar fora da empresa, os privilégios de
acesso fornecido a estes usuários deve ser limitado.
√ Qualquer serviço local de autenticação implementado pelo provedor de serviços de nuvem deve
estar em conformidade com o OATH. Com uma solução com suporte a OATH, as empresas
podem evitar ficar presas a credenciais de autenticação fornecidas por um fabricante.
√ Para permitir a autenticação forte (independente da tecnologia), as aplicações de nuvem devem

suportar a característica de delegar a autenticação para a empresa que está consumindo os
serviços, como através de SAML.
√ Os provedores de nuvem devem considerar o suporte a várias opções de autenticação forte, tais
como senhas de um único uso (OTP), biometria, certificados digitais e Kerberos. Isto oferecerá
outra opção às empresas de usar sua infraestrutura existente.
Recomendações de Federação
Em um ambiente de Computação em Nuvem, a federação de identidade é chave para permitir a

empresas aliadas se autenticar, prover Single-Sign-On (SSO)ou Reduced-Sign-On e trocar
atributos de identidade entre o provedor de serviços (PS) e o provedor de Identidade (PId). As
organizações, ao considerar o gerenciamento de identidades federadas na nuvem devem entender
os vários desafios e possíveis soluções relacionadas ao gerenciamento do ciclo de vida da
identidade, métodos de autenticação, formatos de token e não-repúdio.
√ As empresas que buscam por um provedor de nuvem devem verificar se o provedor suporta ao
menos um dos padrões proeminentes (SAML e Federação-WS). SAML está despontando como um
padrão de federação amplamente suportado e é utilizado pelos principais provedores de SaaS e
PaaS. Suporte a múltiplos padrões permite um alto grau de flexibilidade.
√ Os provedores de nuvem devem ter flexibilidade para aceitar os formatos padrão de federação
de diferentes provedores de identidade. Contudo, as maiorias dos provedores de serviços de
nuvem, na época deste documento, só suportavam um único padrão, ex. SAML 1.1 ou SAML 2.0.
Os provedores de serviços de nuvem que desejam suportar múltiplos formatos de token de
federação devem considerar a implementação de algum tipo de gateway de federação.
√ As organizações podem avaliar SSO Público Federado versus SSO Privado Federado. SSO
Público Federado é baseado em padrões como SAML e Federação-WS com o provedor de serviços

de nuvem, enquanto Federado Privado utiliza a arquitetura existente sobre VPN. A longo prazo, o
SSO Público Federado seria o ideal, enttretanto, em empresas com uma arquitetura madura de
SSO e com um número limitado de implementações em nuvem, pode-se ganhar benefícios de
custo de curto prazo com o SSO Privado Federado.
√ As organizações podem optar por gateways de federação para externalizar sua implementação,
de forma a gerenciar a emissão e verificação de tokens. Usando este método, as organizações
delegam a emissão de vários tipos de token para o gateway da federação, que então manipula a
tradução de tokens de um formato para outro.
Recomendações de Controle de Acesso
Ao selecionar ou revisar a adequação das soluções de controle de acesso para serviços de nuvem
existem muitos aspectos que implicam considerar o seguinte:
√ Revisar a adequação do modelo de controle de acesso para o tipo de serviço ou dados.
√ Identificar as fontes autoritativas de política e informações de perfil do usuário.
√ Avaliar o suporte às políticas de privacidade necessárias para os dados.
√ Selecionar um formato no qual especificará a política e a informação do usuário.
√ Determinar o mecanismo para transmitir a política de um Ponto de Administração da Política

(PAP) para um Ponto de Decisão da Política (PDP).
√ Determinar o mecanismo para transmitir a informação do usuário de um Ponto de Informação

da Política (PIP) para um Ponto de Decisão da Política (PDP).
√ Solicitar uma decisão de política de um Ponto de Decisão de Política (PDP).
√ Aplicar a decisão de política no Ponto de Cumprimento de Política (PCP).
√ Registrar a informação necessária para auditorias.
Recomendação de IDaaS
Identity as a Service (IDaaS) deve seguir as mesmas boas práticas que uma implementação
interna que o IAM utiliza, além de considerações adicionais para privacidade, integridade e
auditoria.
√ Para os usuários corporativos internos, tutores devem revisar as opções dos provedores de
serviço de nuvem para oferecer acesso seguro, seja através de uma VPN direta ou através de um
padrão da indústria como o SAML e autenticação forte. A redução de custos advinda do uso da
nuvem necessita ser balanceada contra as medidas de mitigação dos riscos para endereçar as

considerações de privacidade inerentes ao fato de se ter as informações dos colaboradores
armazenadas externamente.
√ Para os usuários externos como parceiros, os donos da informação necessitam incorporar as

interações com os provedores de IAM dentro de seu SDLC, assim como em suas análises de
ameaças. Segurança da aplicação – as interações entre os vários componentes e as
vulnerabilidades criadas por essa situação (tal como SQL Injection e Cross Site Scripting, dentre
muitas outras) – devem ser também consideradas e protegidas.
√ Os clientes de PaaS devem pesquisar a dimensão em que os fornecedores de IDaaS suportam os

padrões da indústria para provisionamento, autenticação, comunicação de políticas de controle de
acesso e informação de auditoria.
√ Soluções proprietárias apresentam um risco significativo para os componentes de um ambiente

de IAM na nuvem, por causa da falta de transparência dos componentes proprietários. Protocolos
de rede proprietários, algoritmos de encriptação e comunicação de dados são frequentemente
menos seguros e menos interoperáveis. É importante usar normas abertas para os componentes do
IAM que você utilizará externamente.
√ Para os clientes de IaaS, imagens de terceiros usadas para iniciar os servidores virtuais precisam
ser analisadas para verificar a autenticidade do usuário e da imagem. Uma revisão do suporte
fornecido para o gerenciamento do ciclo de vida da imagem deve verificar os mesmos princípios
do software instalado em sua rede interna.
Colaboradores da Versão Original: Subra Kumaraswamy, Sitaraman Lakshminarayanan,

Michael Reiter, JosephStein e Yvonne Wilson.
Colaboradores da Versão Brasileira: Hernan Armbruster, Jordan M. Bonagura, Julio Graziano

Pontes, Miguel Macedo

Domínio 13 - Virtualização
A capacidade de prover serviços em nuvem multilocação no nível de infraestrutura, plataforma,
ou aplicativo é frequentemente sustentada pela habilidade em prover alguma forma de
virtualização para criar escala econômica. Contudo, o uso dessas tecnologias traz preocupações
adicionais relacionadas à segurança. Este domínio relaciona-se a essas questões de segurança.
Enquanto existem diversas formas de virtualização, de longe a mais comum está relacionada a
sistemas operacionais virtualizados, e este é o foco nesta versão do nosso guia. Se a tecnologia de
máquina virtual (VM) está sendo usada na infraestrutura de serviços de nuvem, então devemos
nos preocupar com a compartimentalização e elevação do nível de segurança destes sistemas
virtuais.
A realidade das práticas atuais relacionadas ao gerenciamento de sistemas operacionais virtuais é

que muitos dos processos que fornecem segurança por padrão estão ausentes e atenção especial
deve ser dada para substituí-los. O núcleo da tecnologia de virtualização por si só introduz novas
interfaces de ataque no hypervisor e outros componentes de gerenciamento, mas o mais
importante são os vários impactos que tem a virtualização na segurança de rede. Máquinas
virtuais agora se comunicam sobre um backplane de hardware, ao invés de rede. Como resultado,
controles padrão de segurança de rede não enxergam esse tráfego e não podem realizar
monitoramento ou bloqueio em linha. Esses controles precisam de uma nova forma para
funcionar dentro do ambiente virtual.
O agrupamento de dados em serviços centralizados e repositórios é outra preocupação. Uma base

de dados centralizada e fornecida por um serviço de computação de nuvem deve teoricamente
melhorar a segurança sobre os dados distribuídos sobre um vasto número e variedade de clientes
finais. Contudo, isto também é uma centralização de risco, aumentando as consequências de uma
falha na segurança.
Outra preocupação é o agrupamento de máquinas virtuais que manipulam informações de

diferentes níveis de sensibilidades e segurança. Em ambientes de Computação em Nuvem, o
menor denominador comum de segurança será compartilhado por todos os clientes/usuários
dentro do ambiente virtual a não ser que uma nova arquitetura de segurança possa ser alcançada
de modo que não esteja amarrada a qualquer dependência de rede para proteção.
Recomendações
 Identificar quais tipos de virtualização seu provedor de nuvem usa, se houver.
 Sistemas operacionais virtualizados devem ser protegidos por tecnologia de terceiros para
fornecer controles de segurança em camadas e reduzir a dependência unicamente sobre o
provedor de plataforma.
 Compreender quais controles de segurança estão implementados dentro das máquinas

virtuais além do isolamento incorporado do hypervisor – tais como detecção de intrusões,
antivírus, escaneamento de vulnerabilidades, etc. Configuração segura por padrão deve
ser assegurada por seguir ou exceder os padrões definidos pelas melhores práticas da
indústria.

 Compreender quais controles de segurança estão implementados externamente às
máquinas virtuais para proteger interfaces administrativas (baseadas na web, APIs, etc.)
expostas para os clientes.
 Validar a procedência e integridade de qualquer máquina virtual ou modelo originado do

provedor de nuvem antes de utilizá-la.
 Mecanismos de segurança específicos de máquinas virtuais embarcados dentro das APIs

do hypervisor devem ser utilizados para prover monitoração granular do tráfego
atravessando os backplanes das máquinas virtuais, os quais são opacos aos controles
tradicionais de segurança de rede.
 Acesso administrativo e controle de sistemas operacionais virtualizados são cruciais e

devem incluir autenticação forte integrada ao gerenciamento de identidade corporativo,
bem como mecanismo de registro à prova de falsificação e ferramentas de
monitoramento de integridade.
 Considerar a eficácia e viabilidade de segregar máquinas virtuais criando zonas de

segurança por tipo de uso (estação x servidor), etapas de produção (desenvolvimento,
produção, teste) e sensibilidade dos dados em componentes físicos de hardware separados
como servidores, armazenamento, etc.
 Ter um mecanismo de relatórios que forneça evidências de isolação e emita alertas caso
ocorra uma violação.
 Estar ciente em situações de multilocação envolvendo suas máquinas virtuais onde

preocupações regulatórias podem requerer sua segregação.
Colaboradores da Versão Original: Bikram Barman, Girish Bhat, Sarabjeet Chugh, Philip Cox,
Joe Cupano, Srijith K. Nair, Lee Newcombe, Brian O’Higgins.
Colaboradores da Versão Brasileira: Alessandro Trombini, Jimmy Cury, Jordan M. Bonagura,

Julio Graziano Pontes, Luís Felipe Féres Santos

Referencias
A guide to security metrics. SANS Institute, June 2006. http://www.sans.org
Amazon EC2 API - http://docs.amazonwebservices.com/AWSEC2/2006-10-01/DeveloperGuide/
Amazon Elastic Compute Cloud Developer Guide,

http://docs.amazonwebservices.com/AWSEC2/2009-03-01/DeveloperGuide/
Amazon Simple Queue Service Developer Guide,

http://docs.amazonwebservices.com/AWSSimpleQueueService/2008-01-
01/SQSDeveloperGuide/
Amazon Simple Storage Service Developer Guide,

http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
Amazon SimpleDB Developer Guide,

http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/
Amazon web services blog: Introducing amazon virtual private cloud (vpc), Amazon, August
2009. http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-cloud-vpc.html
Amazon Web Services: Overview of Security Processes, September 2008
An Innovative Policy-based Cross Certification methodology for Public Key Infrastructures.

Casola V., Mazzeo A., Mazzocca N., Rak M. 2nd EuroPKI Workshop. Springer-Verlag LNCS
35. Editors: D. Chadwick, G. Zhao. 2005.
Auditing the Cloud, Grid Gurus, http://gridgurus.typepad.com/grid_gurus/2008/10/auditing-the-

cl.html, October 20, 2008
Azure Services Platform, http://msdn.microsoft.com/en-us/library/dd163896.aspx
Balanced Scorecard for Information Security Introduction”, Published: March 06, 2007,
http://technet.microsoft.com/en-us/library/bb821240.aspx
BITS Kalculator and BITS Financial Services Shared Assessments Program (third party provider
assessment methodology)
Building Security In Maturity Model, http://www.bsi-mm.com/
Business case for a comprehensive approach to identity and access management, May 2009
https://wiki.caudit.edu.au/confluence/display/CTSCIdMWG/Business+case
Business Roundtable, Principles of Corporate Governance, 2005
Business Roundtable, Statement on Corporate Governance, 1997.
Business Software Alliance, Information Security Governance: Towards a Framework for Action
Centers for Medicare and Medicaid Services Information Security Risk Assessment Methodology

Cloud Computing and Compliance: Be Careful Up There, Wood, Lamont, ITWorld, January 30,
2009
Cloud computing definition, by P. Mell and T. Grance, NIST June 2009.

http://csrc.nist.gov/groups/SNS/cloud-computing/index.html
Cloud Computing is on the Up, but what are the Security Issues?, Mather, Tim, Secure
Computing Magazine (UK), March 2, 2009.
Cloud Computing Use Case Group Whitepaper -http://www.scribd.com/doc/17929394/Cloud-

Computing-Use-Cases-Whitepaper
Cloud computing use cases whitepaper, August 2009.

http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper
Cloud computing use cases whitepaper, August 2009.

http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper
Cloud computing vocabulary (cloud computing wiki)

http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary
Cloud Computing: Bill of Rights,

http://wiki.cloudcomputing.org/wiki/CloudComputing:Bill_of_Rights
Cloud Cube Model: Selecting Cloud Formations for Secure Collaboration, Jericho Forum, V 1.0,
April 2009
Cloud Security and Privacy – An Enterprise perspective on Risks and Compliance from O’Reilly
- http://oreilly.com/catalog/9780596802776/ -
Cloud Standards Organization - http://cloud-standards.org/
Cloud Storage Strategy, Steve Lesem, July 19, 2009,

http://www.cloudstoragestrategy.com/2009/07/cloud-storage-and-the-innovators-dilemma.html
Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration
Vulnerabilities (DRAFT), 2009. http://csrc.nist.gov/publications/drafts/nistir-7502/Draft-
NISTIR-7502.pdf
Contracting for Certified Information Security: Model Contract Terms and Analysis (published
by the Internet Security Alliance and available at www.cqdiscovery.com)
Contracting for Information Security: Model Contract Terms (published by the Internet Security
Alliance and available at www.cqdiscovery.com)
CPMC ClearPoint Metric Catalog, 2009 Online Available:

http://www.clearpointmetrics.com/newdev_v3/catalog/MetricApplicationPackage.aspx
CVSS A Complete Guide to the Common Vulnerability Scoring System, Version 2.0, 2007
Online Available: http://www.first.org/cvss/cvss-guide.html

Data Lifecycle Management Model Shows Risks and Integrated Data Flow, by Ernie Hayden,
Information Security Magazine, July 2009
http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1321704_mem1,00.htm
l
Data Privacy Clarification Could Lead to Greater Confidence in Cloud Computing, Raywood,
Dan, Secure Computing Magazine (UK), March 9, 2009.
Defending Electronic Mail as Evidence—The Critical E-Discovery Questions, Jeffrey Ritter,

(available at www.cqdiscovery.com)
Does Every Cloud Have a Silver Compliance Lining?, Tom McHale, July 21, 2009 Online
Available: http://blog.ca-grc.com/2009/07/does-every-cloud-have-a-silver-Compliance-lining/
Encryption of Data At-Rest: Step-by-step Checklist”, a whitepaper prepared by the Security

Technical Working Group of the Storage Network Industry Association (SNIA).
ENISA - http://www.enisa.europa.eu/
Fedora Infrastructure Metrics, 2008. http://fedoraproject.org/wiki/Infrastructure/Metrics
Few Good Information Security Metrics, By Scott Berinato, July 2005 Online Available:
http://www.csoonline.com/article/220462/A_Few_Good_Information_Security_Metrics
Force.com Web Services API Developer’s Guide,

http://www.salesforce.com/us/developer/docs/api/index.htm
Global Privacy & Security, Francoise Gilbert, (Aspen Publishing 2009).
GoGrid API - http://wiki.gogrid.com/wiki/index.php/API
GSA to launch online storefront for cloud computing services, August 2009.
http://www.nextgov.com/nextgov/ng_20090715_3532.php
Guidelines for Media Sanitization,” NIST’s Special Publication 800-88
Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds,
T. Ristenpart, et al,
http://blog.odysen.com/2009/06/security-and-identity-as-service-idaas.html
http://blogs.forrester.com/srm/2007/08/two-faces-of-id.html
http://blogs.intel.com/research/2008/10/httpseverywhere_encrypting_the.php
http://code.google.com/apis/accounts/docs/AuthForWebApps.html
http://code.google.com/apis/accounts/docs/OpenID.html
http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf
http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf
http://csrc.nist.gov/publications/PubsSPs.html
http://en.wikipedia.org/wiki/Statement_on_Auditing_Standards_No._70:_Service_Organizations
http://www.aspeninstitute.org/publications/identity-age-cloud-computing-next-generation-
internets-impact-business-governance-socia
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
http://www.sas70.com
https://siswg.net/index.php?option=com_docman&task=cat_view&gid=21&Itemid=99999999
Information Security Governance: A Call to Action, National Cyber Security Summit Task Force,
Corporate Governance Task Force Report, April 2004.
Information Security Law: Emerging Standard for Corporate Compliance, Thomas Smedinghoff,
(ITGP 2008).
ISACA, IT Governance Institute, Control Objectives for Information and related Technology
(CobiT), 4.1
ISO/IEC 19011:2002 Guidelines for quality and/or environmental management systems auditing
ISO/IEC 20000-1:2005 Information technology—service management—Part 1: Specification
ISO/IEC 20000-1:2005 Information technology—service management—Part 2: Code of practice
ISO/IEC 21827:2008 Information technology—Systems Security Engineering—Capability

Maturity Model (SSE-CMM®)
ISO/IEC 27000:2009 Information technology—Security techniques—Information security

management systems—Overview and vocabulary
ISO/IEC 27001:2005 Information technology—Security techniques—Information security

management systems—Requirements.
ISO/IEC 27002:2005 Information technology—Security techniques—Code of practice for

information security management
ISO/IEC 27005:2008 Information technology—Information security techniques—Information

security risk management
ISO/IEC 27006:2007 Information technology—Security techniques—Requirements for bodies

providing audit and certification of information security management systems

ISO/IEC 28000:2007 Specification for security management systems for the Supply Chain
ISO/IEC 38500:2008 Corporate governance of information technology
IT Governance Institute, Board Briefing on Governance, 2nd Edition, 2003
IT Governance Institute, Information Security Governance: Guidance for Boards of Directors and
Executive Management, 2nd Edition, 2006
ITGI Enterprise Risk: Identify Govern and Manage IT Risk—The Risk IT Framework, Exposure
Draft version 0.1 February 2009.
Jericho Forum - http://www.opengroup.org/jericho/ and the Jericho Cloud Cube model

http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf
Justify Identity Management Investment with Metrics, by Roberta J. Witty, Kris Brittain and Ant
Allan, 23 Feb 2004. Gartner Research ID number TG-22-1617.
Managing Assurance, Security and Trust for Services. Online. Available: http://www.master-
fp7.eu/
National Association for Information Destruction Inc -

http://www.naidonline.org/forms/cert/cert_program_us.pdf
NIST Guidelines for Media Sanitization (800-88) - http://csrc.nist.gov/publications/nistpubs/800-

88/NISTSP800-88_rev1.pdf
NIST Recommended Security Controls for Federal Information Systems (SP800-53)
NIST SP 800-30 Risk Management Guide for Information Technology Systems
OATH- http://www.openauthentication.org
OCEG, Foundation Guidelines Red Book, v1 10/27/2008
OCTAVE-S Implementation Guide, Christopher Alberts, Audrey Dorofee, James Stevens, Carol
Woody, Version 1, 2005
OECD Guidelines for the Security of Information Systems and Networks: Towards a Culture of
Security
Open Cloud Computing Interface Working Group - http://www.occi-wg.org/doku.php
Open Security Architecture Group - http://www.opensecurityarchitecture.org
OpenCrowd - http://www.opencrowd.com/views/cloud.php
OpenID – http://openid.net

OpenID attribute exchange http://openid.net/specs/openid-attribute-exchange-1_0.htmlOAuth
(created by a small group of individuals) http://OAuth.net/
OpenSocial – sharing SOCial networking information http://www.opensocial.org/
ORCM Overcoming Risk And Compliance Myopia, August 2006 Online Available:
http://logic.stanford.edu/POEM/externalpapers/grcdoc.pdf
OSAG Security Landscape - http://www.opensecurityarchitecture.org/cms/foundations/osa-

landscape
OWASP Top Ten Project, http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Princeton Startup Lawyer, “Company Formation-Fiduciary Duties (the basics)”, June 17, 2009,
http://princetonstartuplawyer.wordpress.com/2009/06/17/company-formation-fiduciary-duties-
the-basics/
Python Runtime Environment, http://code.google.com/appengine/docs/
Rackspace API - http://www.rackspacecloud.com/cloud_hosting_products/servers/api
Sailing in Dangerous Waters: A Director’s Guide to Data Governance, E. Michael Power &
Roland L. Trope, (American Bar Association, 2005).
SAML- http://www.oasis-open.org/specs/index.php#saml
Security Guidance for Critical Areas of Focus in Cloud Computing, Version 1, by Cloud Security
Alliance, April 2009
Service Level Agreements: Managing Cost and Quality in Service Relationships, Hiles, A.
(1993), London:Chapman & Hall
SNIA Encryption of Data At Rest: A Step-by-Step Checklist
http://www.snia.org/forums/ssif/knowledge_center/white_papers/forums/ssif/knowledge_center/
white_papers/Encryption-Steps-Checklist_v3.060830.pdf
SNIA Introduction to Storage Security

http://www.snia.org/forums/ssif/knowledge_center/white_papers/Storage-Security-
Intro1.051014.pdf
SNIA Storage Security Best Current Practices

http://www.snia.org/forums/ssif/forums/ssif/programs/best_practices/
Storage Security Best Current Practices (BCPs)” by the Security Technical Working Group of
SNIA
Sun Project Kenai API - http://kenai.com/projects/suncloudapis
The Committee of Sponsoring Organizations of the Treadway Commission (COSO), Enterprise

Risk Management—Integrated Framework (2004).
The Darker Side of Cloud Computing, by Matthew D. Sarrel, PC Mag.com, February 1, 2009

The Force.com Workbook, http://wiki.developerforce.com/index.php/Forcedotcomworkbook
The Institute of Internal Auditors, Critical Infrastructure Assurance Project, “Information Security
Governance: What Directors Need to Know”, 2001
The International Grid Trust Federation (IGTF). http://www.igtf.net
United States General Accounting Office, Information Security Risk Assessment Practices of
Leading Organizations, 1999.
United States Sentencing Commission, Guidelines Manual
vCloud API - http://www.vmware.com/solutions/cloud-computing/vcloud-api.html
Where We’re Headed: New Developments and Trends in the Law of Information Security,
Thomas J. Smedinghoff, Privacy and Data Security Law Journal, January 2007, pps. 103-138
Windows Azure SDK, http://msdn.microsoft.com/en-us/library/dd179367.aspx
Windows Cardspace - http://msdn.microsoft.com/en-us/library/aa480189.aspx
WS-Federation : http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-
os.html

TEC - CSA - Guia de Segurança para Cloud Computing

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TEC - CSA - Guia de Segurança para Cloud Computing

Transféré par

Droits d'auteur :

Formats disponibles

Guia de Segurança

Áreas Críticas Focado

Computação em Nuvem V2.1

Cloud Security Alliance

Cloud Security Alliance – Brazilian Chapter

O guia aqui fornecido é a segunda versão do documento da Cloud Security Alliance,

http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (Versão em inglês

Em outra mudança da nossa primeira versão, o Domínio 3: Legislação e o Domínio

© 2009 Cloud Security Alliance. Todos os direitos reservados.

Copyright © 2009 Cloud Security Alliance 3

Copyright © 2009 Cloud Security Alliance 4

O caminho para proteger a Computação em Nuvem é de fato longo e exige a participação

Diretoria Cloud Security Alliance

Copyright © 2009 Cloud Security Alliance 6

Copyright © 2009 Cloud Security Alliance 7

Diretoria Cloud Security Alliance – Brazilian Chapter

Copyright © 2009 Cloud Security Alliance 9

Copyright © 2009 Cloud Security Alliance 10

Identificar o Ativo Para Implantação na Nuvem

Simplesmente, os ativos suportados pela nuvem se dividem em duas categorias:

Estamos movendo informações para nuvem ou operações/processamento (de funções

Copyright © 2009 Cloud Security Alliance 11

Para cada ativo, faça as perguntas abaixo:

1. Como poderíamos ser prejudicados se o ativo se tornou amplamente público e distribuído?

Essecialmente estamos analisando os requisitos de confidencialidade, integridade e

Mapear o Ativo ao Modelo de Implantação em Potencial

Avalie Potenciais Modelos de Serviços na Nuvem e Provedores

Copyright © 2009 Cloud Security Alliance 12

Colaboradores da Versão Brasileira: Alexandre Pupo, Leonardo Goldim

Copyright © 2009 Cloud Security Alliance 13

Copyright © 2009 Cloud Security Alliance 14

 A terminologia usada por todo o guia, para fornecer um vocabulário consistente.

Entender o framework arquitetônico descrito neste domínio é um primeiro passo importante na

O que é Computação em Nuvem?

Computação em nuvem (“Nuvem”) é um termo em evolução que descreve o desenvolvimento de

A nuvem realça a colaboração, agilidade, escalabilidade e disponibilidade, e oferece o potencial

Mais especificamente, a nuvem descreve o uso de uma coleção de serviços, aplicações,

Existem muitas definições atualmente que tentam endereçar a nuvem da perspectiva de

Copyright © 2009 Cloud Security Alliance 15

Figura 1 – Modelo Visual de Definição de Computação em Nuvem do NIST

Copyright © 2009 Cloud Security Alliance 16

 Auto-atendimento sob demanda. Um consumidor pode unilateralmente provisionar

 Amplo acesso a rede. Capacidades estão disponíveis na rede e acessadas através de

 Pool de Recursos. Os recursos de computação do provedor estão reunidos para servir a

 Elasticidade Rápida. Capacidades podem ser rapidamente e elasticamente provisionadas

 Serviços mensuráveis. Sistemas em Nuvem automaticamente controlam e otimizam o

Copyright © 2009 Cloud Security Alliance 17

 Software em Nuvem como um Serviço (SaaS). A capacidade oferecida ao consumidor

 Plataforma em Nuvem como um Serviço (PaaS). A capacidade oferecida ao

 Infraestrutura em Nuvem como um Serviço (IaaS). A capacidade oferecida ao

O modelo NIST e este documento não endereçam diretamente as definições de modelos de

No curto prazo, como a inovação estimula o desenvolvimento de soluções rápidas, consumidores

Agentes de serviços de nuvem irão abstrair os possíveis recursos incompatíveis e as interfaces no

Copyright © 2009 Cloud Security Alliance 18

Enquanto há muitos grupos de trabalho, rascunhos e especificações publicadas sob consideração

Modelos de Implantação de Nuvem

 Nuvem Pública. A infraestrutura de nuvem é disponibilizada ao público em geral ou a

 Nuvem Privada. A infraestrutura da nuvem é operada exclusivamente por uma única

 Nuvem Comunitária. A infraestrutura da nuvem é compartilhada por diversas

 Nuvem Híbrida. A infraestrutura da nuvem é uma composição de duas ou mais nuvens

É importante observar que existem modelos derivados de implementação de uma nuvem

As características da arquitetura utilizada ao desenhar as soluções terão implicação clara na futura

Copyright © 2009 Cloud Security Alliance 19