Guia Csa V 3.0.1 PT BR Final

GUIA DE SEGURANÇA PARA ÁREAS CRÍTICAS
FOCADO EM COMPUTAÇÃO EM NUVEM V3.0
GUIA DE SEGURANÇA
PARA ÁREAS CRÍTICAS
FOCADO EM COMPUTAÇÃO
EM NUVEM V3.0
©2011 CLOUD SECURITY ALLIANCE | 0

INTRODUÇÃO
O guia aqui apresentado é a terceira versão do “Guia de Segurança para Áreas Críticas Focado em Computação
em Nuvem” (“Security Guidance for Critical Areas of Focus in Cloud Computing”) da Cloud Security Alliance,
originalmente lançado em Abril de 2009. As versões destes documentos estão armazenadas nos seguintes locais:
http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf (este guia na versão em inglês)
http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (a 2ª versão do guia)
http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf (a 1ª versão do guia)
A partir da segunda versão do nosso guia, cada domínio foi atribuído ao seu próprio editor e revisado por
especialistas do setor. A estrutura e a numeração dos domínios estão alinhadas com os padrões do setor e as
melhores práticas. Estimulamos a adoção deste guia como uma boa prática operacional na gestão estratégica dos
serviços em nuvem. Estes white papers e seu cronograma de lançamento estão localizados na página:
http://www.cloudsecurityalliance.org/guidance/
Outra alteração da segunda versão é que alguns nomes de domínios foram atualizados. Seguem abaixo essas
alterações: Domínio 3: Legislação: Contratos e Electronic Discovery e Domínio 5: Gerenciamento da Informação
e Segurança de Dados. Foi adicionado outro domínio a esta versão, que é o Domínio 14: Segurança como um
Serviço (Security as a Service).
© 2011 Cloud Security Alliance.
Todos os direitos reservados. Você pode baixar, armazenar, exibir no seu computador, visualizar, imprimir e,
referenciar a página http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf do guia da Cloud Security
Alliance, desde que: (a) o guia seja utilizado exclusivamente para seu uso pessoal, informativo 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) não sejam
removidos a marca registrada, os direitos autorais ou demais avisos. Você pode citar partes do guia, conforme
permitido pelas disposições de uso legal da lei de direitos autorais dos Estados Unidos, desde que mencione o
Guia da Cloud Security Alliance Versão 3.0 (de 2011).

SUMÁRIO
Introdução ................................................................................................................................................................ 1
Prefácio .................................................................................................................................................................... 3
Agradecimentos ........................................................................................................................................................ 4
Carta dos Editores ..................................................................................................................................................................7
Uma Observação Editorial Sobre Risco .................................................................................................................................9
Seção I. Arquitetura em Nuvem ...........................................................................................................................................12
Domínio 1: Framework da Arquitetura da Computação em Nuvem ....................................................................................13
Seção II. Governança na Nuvem .............................................................................................................................. 31
Domínio 2: Governança e Gerenciamento de Risco Empresarial..........................................................................................32
Domínio 3: Questões Legais: Contratos e Mapeamento Eletrônico de Informações ...........................................................38
Domínio 4: Gerenciamento de Conformidade e Auditoria ..................................................................................................48
Domínio 5: Gerenciamento da Informação e Segurança de Dados .....................................................................................53
Domínio 6: Interoperabilidade e Portabilidade .....................................................................................................................68
Seção III. Operando na Nuvem ................................................................................................................................. 78
Domínio 7: Segurança Tradicional, Continuidade de Negócios e Recuperação de Desastres .............................................79
Domínio 8: Operações de Centro de Processamento de Dados ...........................................................................................95
Domínio 9: Resposta a Incidentes .........................................................................................................................................99
Domínio 10: Segurança de Aplicação .................................................................................................................................110
Domínio 11: Criptografia e Gerenciamento de Chaves ......................................................................................................137
Domínio 12: Identidade, Titularidade e Gerenciamento de Acesso ...................................................................................145
Domínio 13: Virtualização ...................................................................................................................................................168
Domínio 14: Segurança como um Serviço........................................................... ...............................................................173

PREFÁCIO
Bem-vindo à terceira versão do “Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem” da
Cloud Security Alliance. Com o amadurecimento da computação em nuvem, a gestão das oportunidades e os
desafios de segurança tornaram-se cruciais para o desenvolvimento dos negócios. Esperamos oferecer a vocês
instruções e inspiração para auxiliar suas necessidades nos negócios enquanto gerenciam novos riscos.
A Cloud Security Alliance delineou as melhores práticas de atuação nas versões anteriores deste guia. À medida
que continuamos a suprir as ferramentas para que as empresas façam a transição para os serviços em nuvem com
riscos reduzidos, esse guia norteará a nossa direção futura. Na v3.0, você encontrará uma série de fatos e
opiniões colhidos de mais de setenta especialistas do setor do mundo todo. Reunimos esta informação de uma
série de atividades, incluindo capítulos internacionais, parcerias, novas pesquisas e eventos de conferências
visando levar adiante a nossa missão. Você pode acompanhar nossas atividades em
www.cloudsecurityalliance.org.
Uma computação em nuvem segura é um longo percurso que exige a ampla participação conjunta das partes
interessadas em âmbito global. No entanto, felizmente podemos reconhecer o progresso que estamos vendo:
novas soluções de segurança em nuvem estão surgindo com frequência, as empresas estão usando o nosso guia
para se envolver com os provedores de nuvem, iniciando no mundo todo um diálogo público saudável sobre as
questões de conformidade e de confiança. Nossa vitória mais importante é ter conseguido que os profissionais de
segurança se empenhassem em garantir o futuro, em vez de simplesmente proteger o presente.
Envolva-se com este tema e continue a trabalhar conosco para cumprir esta importante missão.
Atenciosamente,
Jerry Archer Dave Cullinane Nils Puhlmann
Alan Boehme Paul Kurtz Jim Reavis
Diretoria da Cloud Security Alliance

AGRADECIMENTOS
Autores/Colaboradores de Domínios
Domínio 1: Chris Hoff, Paul Simmonds
Domínio 2: Marlin Pohlman, Becky Swain, Laura Posey, Bhavesh Bhagat
Domínio 3: Francoise Gilbert, Pamela Jones Harbour, David Kessler, Sue Ross, Thomas Trappler
Domínio 4: Marlin Pohlman, Said Tabet
Domínio 5: Rich Mogull, Jesus Luna
Domínio 6: Aradhna Chetal, Balaji Ramamoorthy, Jim Peterson, Joe Wallace, Michele Drgon, Tushar Bhavsar
Domínio 7: Randolph Barr, Ram Kumar, Michael Machado, Marlin Pohlman
Domínio 8: Liam Lynch
Domínio 9: Michael Panico, Bernd Grobauer, Carlo Espiritu, Kathleen Moriarty, Lee Newcombe, Dominik Birk, Jeff
Reed
Domínio 10: Aradhna Chetal, Balaji Ramamoorthy, John Kinsella, Josey V. George, Sundararajan N., Devesh Bhatt,
Tushar Bhavsar
Domínio 11: Liam Lynch
Domínio 12: Paul Simmonds, Andrew Yeomans, Ian Dobson, John Arnold, Adrian Secombe, Peter Johnson, Shane
Tully, Balaji Ramamorthy, Subra Kumaraswamy, Rajiv Mishra, Ulrich Lang, Jens Laundrup, Yvonne Wilson
Domínio 13: Dave Asprey, Richard Zhao, Kanchanna Ramasamy Balraj, Abhik Chaudhuri, Melvin M. Rodriguez
Domínio 14: Jens Laundrup, Marlin Pohlman, Kevin Fielder
Revisores
Valmiki Mukherjee, Bernd Jaeger, Ulrich Lang, Hassan Takabi, Pw Carey, Xavier Guerin, Troy D. Casey, James
Beadel, Anton Chuvakin, Tushar Jain, M S Prasad, Damir Savanovic, Eiji Sasahara, Chad Woolf, Stefan Pettersson,
M S Prasad, Nrupak Shah, Kimberley Laris, Henry St. Andre, Jim Peterson, Ariel Litvin, Tatsuya Kamimura, George
Ferguson, Andrew Hay, Danielito Vizcayno,
K.S. Abhiraj, Liam Lynch, Michael Marks, JP Morgenthal, Amol Godbole, Damu Kuttikrishnan, Rajiv Mishra, Dennis
F. Poindexter, Neil Fryer, Andrea Bilobrk, Balaji Ramamoorthy, Damir Savanovic
Equipe Editorial
Archie Reed: Domínios 3, 8, 9
Chris Rezek: Domínios 2, 4, 5, 7, 13, 14
Paul Simmonds: Domínios 1, 6, 10, 11, 12

Funcionários da CSA
Redator/Editor Técnico: Amy L. Van Antwerp
Designer Gráfico: Kendall Scoboria
Diretor de Pesquisa: J.R. Santos

AGRADECIMENTOS DA VERSÃO BRASILEIRA
Diretoria Cloud Security Alliance – Brazilian Chapter
Anchises Moraes
Paulo Pagliusi
André Serralheiro
Leonardo Goldim
Reginaldo Sarraf
Lincoln Werneck
Marcelo Carvalho
Uelinton Santos
Fernando Fonseca
Marco Sinhoreli
Walter Capanema
Filipe Villar
Eduardo Fedorowicz
Luiz Felipe Ferreira
Editor
Uelinton Santos
Colaboradores
André Serralheiro
Alexandre Pupo
Eduardo Fedorowicz
Marcelo Carvalho
Uelinton Santos
Colaborador Institucional
Trend Micro Brasil

CARTA DOS EDITORES

Nos últimos três anos, a Cloud Security Alliance atraiu cerca de 120 membros corporativos e conquistou ampla
competência para abordar todos os aspectos da segurança em nuvem, incluindo o cumprimento da legislação
global em matéria de segurança e regulamentação, do gerenciamento de identidade e do desafio de
monitoramento e auditoria de segurança em toda a cadeia de suprimentos de TI baseado em nuvem. A CSA está
se tornando o ponto central para os padrões de segurança em nível mundial, alinhando várias políticas
governamentais díspares sobre segurança em nuvem e propondo normas para a ratificação pelos organismos
internacionais de normatização.
A CSA se vê como uma incubadora dos padrões de segurança em nuvem, de modo que seus projetos de pesquisa
utilizam rápidas técnicas de desenvolvimento para produzir rápidos resultados. Com este fim, a equipe editorial
do Guia da CSA tem o orgulho de apresentar a terceira versão do seu título principal “Guia de Segurança para
Áreas Críticas Focado em Computação em Nuvem”. Este trabalho é um conjunto das melhores práticas de
segurança que a CSA reuniu em 14 domínios que envolvem a governança ou a operação em nuvem (arquitetura
em nuvem, governança e gestão de riscos corporativos, legislação: Contratos e Electronic Discovery,
Conformidade e Auditoria, Gestão de Informação e Segurança de Dados, Portabilidade e Interoperabilidade,
Segurança Tradicional, Continuidade de Negócios e Recuperação de Desastres, Operações de Centro de Dados,
Resposta a Incidentes, Notificação e Correção, Segurança de Aplicações, Criptografia e Gerenciamento de Chaves,
Gerenciamento de Identidade e Acesso, Virtualização e Segurança como um Serviço).
O guia da CSA procura estabelecer na sua terceira edição uma base estável e segura para as operações em
nuvem. Este esforço proporciona um roteiro prático e aplicável para os gestores que querem adotar o paradigma
da nuvem de forma confiável e segura. Os domínios foram reescritos para enfatizar a segurança, a estabilidade e
a privacidade, garantindo a privacidade corporativa em um ambiente de multilocatário (do inglês - multi-tenant).
Nos últimos dois anos, a versão 2.1 do guia serviu como base para a pesquisa em diversas áreas da segurança em
nuvem. As entregas que estão em uso desde a Arquitetura da Iniciativa de Nuvem Confiável (do inglês TCI
Architecture - Trusted Cloud Initiative) até a Pilha de GRC (Governança, Gerenciamento de Risco e Conformidade,
do inglês GRC Stack -Governance, Risk Management and Compliance) foram inspiradas nas versões anteriores do
guia e, esperamos que esta versão não seja diferente. O guia serve como uma cartilha de alto nível para
executivos, consumidores e instaladores que queiram adotar os serviços em nuvem como uma alternativa ou
complemento à infraestrutura tradicional. No entanto, o guia é elaborado com a inovação em mente. Aqueles
com uma mentalidade empreendedora devem ler este trabalho com um olhar para os serviços conclusivos e para
as abordagens dos muitos autores inclusos na criação do domínio. Os investidores e os tomadores de decisões
corporativos também acharão esta obra interessante, já que serve como um roteiro para a inovação e o
desenvolvimento já em curso nas empresas do mundo inteiro. Os profissionais de segurança e os educadores
encontrarão elementos deste livro, tanto autoritários como instigantes e, à medida que a indústria evolui, o valor
incluso pelos autores se mostra influente e oportuno.
Na terceira edição, o guia assume uma maturidade estrutural paralela ao desenvolvimento dos padrões
multinacionais de nuvem tanto em estrutura como em conteúdo. A versão 3.0 estende o conteúdo apresentado
nas versões anteriores, com recomendações e requisitos práticos para serem medidos e auditados. Observe as
diferentes interpretações do termo "requisitos” utilizado em todo o documento. Nosso guia não representa uma
obrigação legal, mas os "requisitos" foram escolhidos para representar uma orientação adequada a praticamente

todos os casos de uso imagináveis e, também alinhados à nossa orientação com documentos similares e bem
aceitos. Os autores especialistas do setor da CSA têm se esforçado para apresentar um produto útil que é
mensurado e balanceado entre os interesses dos provedores de nuvem e locatários. Os controles focam na
preservação da integridade de propriedade dos dados do locatário ao abranger o conceito de infraestrutura física
compartilhada. A versão 3.0 do guia incorpora a natureza altamente dinâmica da computação em nuvem, a curva
de aprendizagem do setor e, os novos desenvolvimentos no âmbito de outros projetos de pesquisa, como a
Matriz de Controles em Nuvem (Cloud Controls Matrix), a Iniciativa nos Consensos de Avaliações (Consensus
Assessments Initiative), a Iniciativa de Nuvem Confiável (Trusted Cloud Initiative) e a Iniciativa de Pilha de GRC
(Governança, Gerenciamento de Risco e Conformidade, GRC Stack Initiative) e vincula as melhores práticas nas
diversas atividades da CSA em um abrangente nível executivo (C-level). A versão 3.0 do guia de segurança servirá
de porta de entrada para os padrões emergentes que estão sendo desenvolvidos na organização de padrões
mundiais e, é elaborada para servir como uma cartilha de nível executivo para qualquer organização que busque
uma transição estável e segura para hospedar suas operações de negócios na nuvem.
Em nome da Cloud Security Alliance, gostaríamos de agradecer a cada voluntário pelo seu tempo e esforço para o
desenvolvimento e edição desta nova versão do nosso principal guia. Acreditamos ser este nosso melhor e mais
amplamente revisado trabalho até a presente data, porém, o tema ainda está em evolução e, embora a nossa
intenção principal seja orientar, pretendemos também inspirar os leitores a se envolverem na sua melhoria e
comentarem sobre a direção daqueles que compõem o corpo do trabalho exposto. Respeitosamente,
apresentamos esse esforço para o setor e aguardamos o componente mais importante de qualquer diálogo, que é
a sua opinião. Estamos ansiosos para ouvir seus comentários a respeito deste guia atualizado. Se você achou este
guia útil ou se gostaria de vê-lo melhorado, pedimos que considere juntar-se à Cloud Security Alliance como um
membro ou colaborador.
Atenciosamente,
Paul Simmonds Chris Rezek Archie Reed
Editores do Guia de Segurança v3.0

UMA OBSERVAÇÃO EDITORIAL SOBRE RISCO

Neste guia fazemos extensas recomendações sobre como reduzir o risco ao adotar a computação em nuvem, mas
nem todas as recomendações são necessárias, ou mesmo realistas, para todas as implantações em nuvem. À
medida que reunimos as informações dos diferentes grupos de trabalho durante o processo editorial, logo
percebemos que simplesmente não havia espaço suficiente para fornecer recomendações totalmente
diferenciadas para todos os possíveis cenários de risco. Assim como pode ser muito importante mover uma
aplicação crítica para um provedor público de nuvem, pode haver pouca ou nenhuma razão para aplicar controles
extensivos de segurança nos dados de baixo valor migrando para armazenamento baseado em nuvem.
Com tantas opções diferentes de implantação em nuvem - incluindo os modelos de serviço do SPI (SPI refere-se
ao Software como um Serviço, Plataforma como um Serviço ou Infraestrutura como um Serviço, detalhado no
Domínio 1); implantações públicas versus privadas, hospedagem interna versus externa e várias permutações
híbridas – não existe uma lista de controles de segurança que possa cobrir todas as circunstâncias. Como em
qualquer área de segurança, as organizações devem adotar uma abordagem baseada em risco para se mover para
a nuvem e selecionar as opções de segurança. Segue uma estrutura simples que ajuda a avaliar os riscos iniciais
de nuvens e informar as decisões de segurança.
Este processo não é uma estrutura de avaliação de risco completa, nem uma metodologia para determinar todas
as suas necessidades de segurança. É um método rápido para avaliar a sua tolerância para mover um recurso a
vários modelos de computação em nuvem.
Identificar o Ativo para a implantação em nuvem
Os ativos suportados pela nuvem dividem-se em duas categorias gerais nos casos mais simples:
1. Dados
2. Aplicações/Funções/Processos
Ou estamos movendo informações para a nuvem, ou realizando transações/processamentos (de todas as

maneiras de funções parciais até aplicações completas).
Com a computação em nuvem, nossos dados e aplicações não precisam residir no mesmo local e, podemos optar
por mudar apenas partes de funções para a nuvem. Por exemplo, podemos hospedar o nosso aplicação e os
dados em nosso próprio centro de dados e, ao mesmo tempo, alocar uma parte de sua funcionalidade para a
nuvem através de uma Plataforma como um Serviço.
O primeiro passo para avaliar o risco em nuvem é determinar exatamente quais dados ou função estão sendo
considerados em nuvem. Isto deve incluir usos potenciais do ativo, uma vez que se move para a nuvem para dar
conta do aumento de escopo. Os volumes de dados e transações são frequentemente mais elevados do que o
esperado.
Avaliar o Ativo

O próximo passo é determinar a importância dos dados ou da função para a organização. A menos que a sua
organização disponha de um processo para isso, não é preciso realizar uma avaliação detalhada, mas você precisa
de pelo menos uma avaliação aproximada do quão sensível é um ativo e, o quão importante é um
aplicativo/função/processo.
Questione o seguinte para cada ativo:
1. Como poderíamos ser prejudicados se o ativo se tornasse amplamente público e distribuído?
2. Como poderíamos ser prejudicados se um empregado do nosso provedor de nuvem acessasse o ativo?
3. Como poderíamos ser prejudicados se o processo ou função fossem manipulados por um estranho?
4. Como poderíamos ser prejudicados se o processo ou função falhasse ao apresentar os resultados

esperados?
5. Como poderíamos ser prejudicados se as informações/dados fossem inesperadamente alteradas?
6. Como poderíamos ser prejudicados se o ativo estivesse indisponível por um período de tempo?
Estamos essencialmente avaliando a confidencialidade, a integridade e os requisitos de disponibilidade para o

ativo, e; como os riscos se alteram se todo ou parte do ativo é tratado na nuvem. É muito semelhante à avaliação
de terceirização de um projeto em potencial, exceto que, com a computação em nuvem, temos uma ampla gama
de opções de implantação, incluindo modelos internos.
Mapeie o Ativo para modelos potenciais de implantação em nuvem
Precisamos agora compreender a importância do ativo. Nosso próximo passo é determinar quais modelos de
implantação nos deixam confortáveis. Antes de iniciar a busca por potenciais fornecedores, precisamos saber se
podemos aceitar os riscos implícitos para os diversos modelos de implantação: privado, público, comunitário ou
híbrido, e; os cenários de hospedagem: internos, externos, ou combinados.
Determine se está disposto a aceitar as seguintes opções para o ativo:
1. Pública.
2. Privada, interna/no local (on-premesis).
3. Privada, externa (inclusa a infraestrutura dedicada ou compartilhada).
4. Comunitária; considerando o local da hospedagem, o provedor dos serviços em potencial e a identificação

dos outros membros da comunidade.
5. Híbrido. Para avaliar efetivamente uma implantação híbrida em potencial, você deve ter pelo menos uma
ideia de uma arquitetura aproximada de onde os componentes, as funções e os dados irão residir.
Nesta fase você deve ter uma boa ideia do seu nível de conforto para a transição para a nuvem e, de que modelos
de implantação e locais atendem às suas necessidades de segurança e de risco.

Avalie os Modelos Potenciais de Serviços em Nuvem e os Provedores
Nesta fase, foque no grau de controle que você terá em cada camada de SPI para implantar qualquer gestão de
riscos necessária. Neste ponto, você pode mudar para uma avaliação completa dos riscos, caso esteja avaliando
uma oferta específica.
Seu foco será no grau de controle disponível para implantar as reduções de risco nas diferentes camadas de SPI.
Caso já disponha das necessidades específicas (por exemplo, a manipulação de dados regulados), você pode
incluí-los na avaliação.
Mapeie o Fluxo de Dados em Potencial
Caso esteja avaliando uma determinada opção de implantação, mapeie o fluxo de dados entre a sua organização,
o serviço em nuvem e todos os clientes/outros nós. Embora a maioria destas etapas seja de nível superior, antes
de tomar uma decisão final é absolutamente essencial compreender se e, como, os dados podem ser movidos
para dentro e para fora da nuvem.
Caso ainda tenha que decidir sobre determinada proposta, você precisará esboçar o fluxo de dados aproximados
para todas as opções aceitáveis da sua lista. Isto é para garantir que, assim que tomar as decisões finais, poderá
identificar os pontos de exposição ao risco.
Conclusões
Você compreende agora a importância do que considerar ao mover para a nuvem, sua tolerância ao risco (pelo
menos em um nível superior) e quais combinações de modelos de implantação e de serviços são aceitáveis. Você
tem também uma boa ideia dos potenciais pontos de exposição às informações e operações confidenciais.
Isso tudo em conjunto lhe proporciona suficiente contexto para avaliar todos os outros controles de segurança
neste guia. Para os ativos de baixo valor, não é preciso o mesmo nível de controles de segurança e você pode
ignorar muitas das recomendações, como inspeções locais, descoberta e esquemas de criptografia complexos.
Um ativo de alto valor que seja regulado pode implicar em necessidades de auditoria e de retenção de dados.
Para outro ativo de alto valor que não esteja sujeito a restrições regulatórias, você pode se concentrar mais em
controles técnicos de segurança.
Devido ao nosso espaço limitado, bem como à profundidade e à extensão do material a cobrir, este documento
contém extensas listas de recomendações de segurança. Nem todas as implantações em nuvem precisam de cada
possível controle de segurança e risco. Avalie antecipadamente a sua tolerância ao risco e às potenciais
exposições para ter o contexto que precisa para escolher as melhores opções para a sua organização e
implantação.

SEÇÃO I //
ARQUITETURA EM
NUVEM

DOMÍNIO 1 //
FRAMEWORK DA ARQUITETURA DA COMPUTAÇÃO EM NUVEM
O domínio Framework da Arquitetura da Computação em Nuvem fornece uma estrutura conceitual para o
restante do guia da Cloud Security Alliance. O conteúdo deste domínio foca em uma descrição da computação em
nuvem, que é especificamente adaptado à perspectiva única de profissionais de rede de TI e segurança.
A seção final deste domínio apresenta uma breve introdução de cada um dos demais domínios.
A compreensão do framework da arquitetura descrita neste domínio é o primeiro passo importante na

compreensão do restante do guia da Cloud Security Alliance. A estrutura define muitos dos conceitos e termos
utilizados nos demais domínios.
Visão geral. As três seções seguintes definem essa perspectiva arquitetônica em termos de:
 A terminologia utilizada no guia de modo a proporcionar um vocabulário consistente
 Os requisitos arquitetônicos e os desafios para proteção de aplicações e serviços em nuvem
 Um modelo de referência que descreve uma taxonomia de serviços e arquiteturas em nuvem
1.1 O que é Computação em Nuvem?
A computação em nuvem é um modelo para permitir um acesso à rede onipresente (ubíqua), conveniente e sob
demanda, para um “pool” compartilhado de recursos computacionais configuráveis (por exemplo, redes,
servidores, armazenamento, aplicações e serviços). A computação em nuvem é uma tecnologia disruptiva que
tem o potencial de aumentar a colaboração, a agilidade, o dimensionamento e a disponibilidade e, fornece as
oportunidades de redução de custos através da computação otimizada e eficiente. O modelo em nuvem prevê um
mundo onde os componentes podem ser rapidamente orquestrados, provisionados, implementados e
desativados e, escalados para cima ou para baixo para fornecer um modelo utilitário de alocação e consumo sob
demanda.
Do ponto de vista arquitetônico, há muita confusão em torno de como a nuvem é ao mesmo tempo similar e
distinta dos modelos existentes de computação e, como essas semelhanças e diferenças impactam as abordagens
organizacionais, operacionais e tecnológicas para a rede e para as práticas de segurança da informação. Há uma
tênue linha entre a computação convencional e computação em nuvem. No entanto, a computação em nuvem
impactará as abordagens organizacionais, operacionais e tecnológicas para a proteção de dados, proteção da rede
e as boas práticas de segurança da informação.
Hoje, existem muitas definições que tentam abordar a nuvem sob a perspectiva dos acadêmicos, arquitetos,
engenheiros, desenvolvedores, gerentes e consumidores. Este documento foca em uma definição concebida
especificamente para perspectivas exclusivas de profissionais de rede de TI e segurança.

1.2 No que consiste a Computação em Nuvem?
Esta versão do guia da Cloud Security Alliance apresenta definições que são baseadas em trabalhos publicados
dos cientistas do Instituto Nacional de Padrões e Tecnologia (NIST)1 e seus esforços em torno de definir a
computação em nuvem.
Normalmente, a publicação do NIST é bem aceita e o Guia está alinhado com a definição do NIST na Definição de
Trabalho da Computação em Nuvem (do inglês Working Definition of Cloud Computing) (como descrito no NIST
800-145) para dar coerência e consenso em torno de uma linguagem comum, para se concentrar em casos de uso
em vez de em nuances semânticas.
É importante observar que este guia pretende ser amplamente utilizável e aplicável a organizações do mundo
inteiro. Enquanto que o NIST é uma organização governamental dos EUA, a opção por este modelo de referência
não deve ser interpretada para sugerir a exclusão de outros pontos de vista ou geografias.
O NIST define a computação em nuvem descrevendo cinco características essenciais, três modelos de serviços em
nuvem e quatro modelos de implantação em nuvem. Eles estão resumidos visualmente na Figura 1 e explicados
com detalhes abaixo.
Figura 1 - Modelo Visual da Definição da Computação em Nuvem2
1
NIST - Instituto Nacional de Normatizações e Tecnologia

1.3 As características da Computação em Nuvem
É importante reconhecer que os serviços em nuvem geralmente são utilizados em conjunto e ativados por
tecnologias de virtualização, mas nem sempre o são. Não há
qualquer exigência, no entanto, que vincule a captação de
recursos às tecnologias de virtualização e, em muitas ofertas de
virtualização não utiliza-se hypervisor ou container de sistema
operacional.
Além disso, é preciso observar que multilocatário não é

considerada como uma característica essencial da nuvem pelo
NIST mas, frequentemente é mencionado como tal. Apesar de
não ser uma característica essencial da computação em nuvem
no modelo do NIST, a CSA identificou o multilocatário como um
elemento importante da nuvem.
1.4 Multilocatário
Para este documento o multilocatário é considerado um

elemento importante e, a próxima seção explanará o
entendimento e a definição da CSA da sua importância para a
computação em nuvem.
Na sua mais simples forma, o multilocatário implica na

utilização dos mesmos recursos ou do aplicação por vários
consumidores que podem pertencer à mesma organização ou a
uma organização diferente. O impacto do multilocatário é a
visibilidade de dados residuais ou traços operacionais por outro
usuário ou locatário.
Os modelos de serviços em nuvem de multilocatário implicam

em uma necessidade orientada por políticas de aplicação, Figura 2 - Multilocatário
segmentação, isolamento, governança, níveis de serviço e
modelos de ressarcimento/faturamento para diferentes públicos
A Infraestrutura como um Serviço
consumidores.
(IaaS), entrega uma infraestrutura de
Os consumidores podem optar por utilizar o serviço em nuvem computação (normalmente uma
oferecido por um provedor público baseado em um usuário plataforma em ambiente virtual) como
individual ou, no caso de hospedagem em nuvem privada, uma um serviço, juntamente com o
organização pode segmentar usuários como diferentes unidades armazenamento e a rede em estado
de negócios que compartilham uma infraestrutura comum. bruto. Em vez de adquirir servidores,
software, espaço de centro de dados
Do ponto de vista de um provedor, o multilocatário sugere uma ou equipamentos de rede, os clientes
abordagem de arquitetura e design para possibilitar economias de compram esses recursos como um
escala, disponibilidade, gestão, segmentação, isolamento e serviço totalmente terceirizado.
eficiência operacional. Estes serviços aproveitam a infraestrutura
compartilhada, os dados, os metadados, os serviços e as aplicações em muitos diferentes consumidores.

Ainda, o multilocatário pode assumir diferentes definições,

dependendo do modelo de serviços em nuvem do provedor, à O Software como um Serviço (SaaS),
medida que possa implicar em permitir os recursos acima descritos, algumas vezes referido como "software
nos níveis de infraestrutura, banco de dados ou aplicações. Um sob demanda", é um modelo de
exemplo seria a diferença entre a implantação multilocatário de entrega de software no qual o software
uma Infraestrutura como um Serviço (IaaS)2, um Software como um e seus dados associados são
Serviço (SaaS)3 e uma Plataforma como um Serviço (PaaS)4 hospedados de modo centralizado
(tipicamente na (Internet) nuvem) e
Os modelos de implantação em nuvem atribuem diferentes normalmente são acessados por
importâncias ao multilocatário. Porém, mesmo no caso de uma usuários que utilizam um “thin client”,
nuvem privada, uma única organização pode ter uma infinidade de normalmente usando um navegador da
consultores terceirizados e contratados, bem como o desejo de um Web através da Internet.
alto grau de separação lógica entre as unidades de negócios. Assim,
as preocupações multilocatário sempre devem ser consideradas.
1.5 Modelo de referência em nuvem
Compreender as relações e dependências entre os modelos de computação em nuvem é fundamental para a

compreensão dos riscos de segurança. O IaaS é a base de todos os serviços em nuvem, com a implantação da
PaaS sobre a IaaS e, o SaaS por sua vez sobre a PaaS, conforme descrito no diagrama do Modelo de Referência da
Nuvem. Desta maneira, assim como as capacidades são herdadas, assim o são os problemas de segurança da
informação e risco. É importante observar que os provedores de nuvem comerciais não se encaixam
perfeitamente nos modelos de serviços de camadas. Entretanto, o modelo de referência é importante para
relacionar os serviços do mundo real para uma estrutura arquitetônica e entender que os recursos e serviços
requerem uma análise de segurança.
A IaaS inclui uma completa infraestrutura de pilha de recursos das instalações para as plataformas de hardware
que nela residem. Ela incorpora a capacidade de abstrair recursos (ou não), bem como entregar conectividade
física e lógica a esses recursos. Em última análise, a IaaS fornece um conjunto de APIs5, que permite a gestão e
outras formas de interação com a infraestrutura pelos consumidores.
2
IaaS - Infraestrutura como um Serviço
3
SaaS - Software como um Serviço
4
PaaS - Plataforma como um Serviço
5
API - Interface de Programação de Aplicativo

A PaaS fica acima da IaaS e adiciona uma camada de integração com

infraestruturas de desenvolvimento de aplicações, recursos de A Plataforma como um Serviço (PaaS),
“middleware” e funções, tais como banco de dados, mensagens e é a entrega de uma plataforma de
enfileiramento. Estes serviços permitem aos desenvolvedores criarem computação e solução de pilha como
aplicações na plataforma com as linguagens de programação e um serviço. As propostas de PaaS
ferramentas que são suportadas pelas pilhas. facilitam a implantação de aplicações
sem o custo e a complexidade de
O SaaS por sua vez, é implantado sobre as pilhas subjacentes da IaaS e comprar e gerenciar o hardware e o
da PaaS e fornece um ambiente operacional independente que é usado software de base e, o provisionamento
para entregar toda a experiência do usuário, incluindo o conteúdo, sua dos recursos de hospedagem. Isso
apresentação, a(s) aplicações(s) e, os recursos de gerenciamento. fornece todas as instalações
necessárias para atender o ciclo de
Assim, deve ficar claro que existem importantes compensações para
vida completo de estabelecer e
cada modelo em termos de funcionalidades integradas, complexidade
entregar aplicações e, serviços da Web
versus abertura (extensibilidade) e segurança. Geralmente, o SaaS
totalmente disponíveis na Internet.
fornece a mais integrada funcionalidade feita diretamente na proposta,
com a mínima extensibilidade dos consumidores e, um nível
relativamente elevado de segurança integrada (pelo menos o provedor tem uma responsabilidade pela
segurança).
A PaaS visa permitir que os desenvolvedores criem suas próprias aplicações sobre a plataforma. Como resultado,
ela tende a ser mais extensível que o SaaS, em detrimento das características prontas para o cliente. Essa
compensação se estende a recursos de segurança e capacidades, onde os recursos internos são menos
completos, mas há mais flexibilidade para acomodar segurança adicional.
A IaaS fornece pouco ou nenhum recurso semelhante a aplicações, mas uma enorme extensibilidade. Isso
geralmente se traduz em menos recursos e funcionalidades de segurança integrada, além de proteger a própria
infraestrutura. Este modelo requer que os sistemas operacionais, aplicações e o conteúdo sejam gerenciados e
protegidos pelo consumidor na nuvem.
O principal argumento para a arquitetura de segurança é que quanto mais abaixo na pilha o provedor de nuvem
para, mais os consumidores são responsáveis por implantar e gerir os recursos de segurança e de gerenciamento
por conta própria.
Os níveis de serviço, segurança, governança, conformidade e, as expectativas de responsabilidade do serviço e do

provedor estão contratualmente estipulados, geridos e impostos quando um acordo em nível de serviço (SLA)6 é
proposto ao consumidor. Há dois tipos de SLAs: negociável e não negociável. Na ausência de um SLA, o
consumidor administra todos os aspectos da nuvem sob o seu controle. Quando é oferecido um SLA não
negociável, o provedor administra essas partes estipuladas no acordo. No caso de PaaS ou IaaS, normalmente a
gestão eficaz dos serviços residuais especificados no SLA é de responsabilidade dos administradores de sistemas
do consumidor, com alguma compensação esperada pelo provedor, para garantir os componentes da plataforma
e da infraestrutura subjacente, para assegurar a disponibilidade dos serviços básicos e de segurança. Em todos os
casos, deve ficar clara a possibilidade de designar/transferir a responsabilidade, mas não necessariamente suas
obrigações.
Limitar o escopo ou as capacidades específicas e funcionalidades dentro de cada um dos modelos de

fornecimento em nuvem ou empregar a conjunção funcional dos serviços e das capacidades através deles, pode
6
SLA - Contrato de Nível de Serviço (do inglês, Service Level Agreement)

produzir classificações derivadas. Por exemplo, o “Armazenamento de Dados como um Serviço” (do inglês
Storage as a Service) é uma subproposta específica dentro da ‘família’ da IaaS.
Enquanto uma revisão mais ampla do crescente conjunto de soluções de computação em nuvem está fora do
escopo deste documento, a taxonomia das Soluções em Nuvem da OpenCrowd (do inglês OpenCrowd Cloud
Solutions) na figura abaixo fornece um excelente ponto de partida, apesar da CSA não endossar especificamente
nenhuma das soluções ou empresas abaixo apresentadas. Ela fornece o diagrama abaixo para demonstrar a
diversidade de propostas atualmente disponíveis.
Figura 3 - Taxonomia OpenCrowd7
7
http://www.opencrowd.com/assets/images/views/views_cloud-tax-lrg.png

Para uma visão geral excelente dos muitos casos de uso da computação em nuvem, o Grupo de Casos de Uso de
Computação em Nuvem (do inglês Cloud Computing Use Case Group) produziu um trabalho colaborativo para
descrever e definir os casos comuns e demonstrar os benefícios da nuvem com o objetivo de "... reunir
consumidores e provedores de nuvem para definir casos de uso comuns para a computação em nuvem... e
destacar as capacidades e necessidades que precisam ser padronizadas em um ambiente de nuvem para garantir
a interoperabilidade, facilidade de integração e portabilidade".
1.5.1 Modelo de Referência de Segurança em Nuvem
O modelo de referência de segurança em nuvem aborda as relações dessas classes e coloca-as no contexto de
seus controles e as preocupações de segurança relevantes. Para as organizações e indivíduos que enfrentam a
computação em nuvem pela primeira vez e, para evitar potenciais armadilhas e confusões é importante observar
o seguinte:
 A noção de como os serviços em nuvem são implantados é muitas vezes utilizada como sinônimo de onde
eles são fornecidos, o que pode levar à confusão. As nuvens públicas ou privadas podem ser descritas
como externa ou interna, o que pode não ser correto em todas as situações.
 A maneira pela qual os serviços em nuvem são consumidos é muitas vezes descrita em relação ao local de
gerenciamento ou da segurança do perímetro da organização (geralmente definida pela presença de um
demarcador conhecido). Enquanto ainda é importante compreender onde se encontram as fronteiras de
segurança em termos de computação em nuvem, a noção de um perímetro bem demarcado é um
conceito anacrônico para a maioria das organizações.
 A redefinição do perímetro e a deterioração dos limites de confiança que já estão ocorrendo na empresa
são amplificadas e aceleradas pela computação em nuvem. A conectividade onipresente, a natureza
amorfa de intercâmbio de informações e a ineficiência dos controles de segurança estáticos tradicionais
que não podem tratar com a natureza dinâmica de serviços em nuvem, requerem um novo pensamento
em relação à computação em nuvem. O Fórum Jericho8 produziu uma quantidade considerável de
material sobre a redefinição do perímetro de redes corporativas, incluindo diversos estudos de caso.
As modalidades de implantação e consumo em nuvem devem ser pensadas não apenas dentro do contexto
"interno" versus "externo" e, como elas se relacionam com a localização física dos ativos, recursos e informações,
mas também por quem elas estão sendo consumidas e, quem é responsável pela sua governança, segurança e
conformidade com as políticas e normas.
Isto não é para sugerir que a localização interna ou externa de um ativo, um recurso ou das informações não afeta
a postura de segurança e risco de uma organização porque eles fazem, mas para ressaltar que o risco também
depende de:
 Os tipos de ativos, recursos e informações que estão sendo gerenciados
 Quem os controla e como
 Quais controles são selecionados e como eles estão integrados
 Questões de conformidade
8
http://www.jerichoforum.org

Por exemplo, uma pilha LAMP9 implantada no AWS EC2 da Amazon seria classificada como uma solução pública,
externa e gerenciada por terceiros de IaaS, mesmo se as instâncias e aplicações/dados nela contidas fossem
gerenciadas pelo consumidor ou por um terceiro. Uma pilha de aplicações personalizadas que serve várias
unidades de negócios, implantada no Eucalyptus sob controle, gestão e propriedade de uma corporação, poderia
ser descrita como uma solução privada, interna e autogerida de SaaS. Ambos os exemplos utilizam os recursos
escalonáveis e de autosserviço flexíveis da nuvem.
A tabela a seguir resume estes pontos:
Tabela 1 – Modelos de Implantação de Computação em Nuvem
9
O sistema operacional LAMP-Linux , o Apache HTTP Server, o MySQL (software de banco de dados) e o Perl/PHP/Python são
os componentes principais para construir um servidor da Web de uso geral viável

Outra forma de visualizar as combinações de modelos de serviços de nuvem, os modelos de implantação, a

localização física de recursos e a atribuição de gerenciamento e propriedade, é o Modelo Cloud Cube do Fórum
Jericho10, mostrado na figura à direita:
O Modelo Cloud Cube ilustra as muitas permutações

disponíveis nas atuais propostas de nuvem e apresenta
quatro critérios/dimensões para diferenciar as
"formações" de nuvem umas das outras e a maneira se
seu aprovisionamento, para compreender como a
computação em nuvem afeta a forma como a
segurança pode ser abordada.
O Modelo Cloud Cube também evidencia os desafios da

compreensão e do mapeamento dos modelos de
nuvem para frameworks e normas de controle, como a ISO/IEC 27002, que fornece "... uma série de diretrizes e
princípios gerais para iniciar, implantar, manter e aprimorar o gerenciamento da segurança da informação dentro
de uma organização".
Figura 4 - Modelo Cloud Cube do Jericho
O objetivo de controle da Seção 6.2 "Entidades Externas" da ISO/IEC 27002 declara: "... a segurança das
informações e das instalações de processamento da organização não deve ser reduzida pela introdução de
produtos ou serviços externos de terceiros..."
Como tal, as diferenças de métodos e a responsabilidade para garantir os três modelos de serviços em nuvem faz
com que os consumidores de serviços em nuvem sejam confrontados com uma tarefa desafiadora. A não ser que
os provedores de nuvem possam facilmente revelar ao consumidor os seus controles de segurança e até que
ponto eles são implantados e, o consumidor saiba quais controles são necessários para manter a segurança de
suas informações, há um enorme potencial para decisões de gerenciamento de risco equivocadas e resultados
negativos.
Primeiro, um qualifica um serviço em nuvem contra o modelo de arquitetura em nuvem. Em seguida, é possível
compará-lo com a sua arquitetura de segurança, assim como de negócios, de regulamentações e de outros
requisitos de conformidade, como um exercício de análise de lacunas (do inglês gap-analysis). O resultado
determina a postura geral de "segurança" de um serviço e como ela se relaciona com a garantia e os requisitos de
proteção de um ativo.
10
http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf

A figura abaixo mostra um exemplo de como um mapeamento de serviços em nuvem pode ser comparado com
um catálogo de controles de compensação para determinar quais controles existem e quais não, conforme
previsto pelo consumidor, pelo fornecedor de serviços em nuvem, ou por um terceiro. Por sua vez, este pode ser
comparado a uma estrutura de conformidade ou a um conjunto de requisitos, tais como PCI DSS, conforme
mostrado.
Figura 5 - Mapeamento do Modelo de Nuvem para o Controles de Segurança e Conformidade
Assim que esta análise de lacunas estiver concluída, torna-se muito mais fácil determinar o que é preciso ser feito
para retroalimentar uma estrutura de avaliação de risco, pelos requisitos de quaisquer regulamentações ou de
outras normas de conformidade. Por sua vez, isto ajuda a determinar como as lacunas e os riscos, em última
análise, devem ser abordados: aceitos, transferidos ou minimizados.
É importante observar que o uso da computação em nuvem como um modelo operacional não proporciona ou
impede o cumprimento da conformidade inerentemente. A capacidade de cumprir todos os requisitos é um
resultado direto do modelo de serviço e de implantação utilizados e, do design, da implantação e do
gerenciamento dos recursos no escopo.
Para uma visão geral excelente dos frameworks de controle que fornecem bons exemplos framework de controle
genérico acima citadas, consulte o “panorama” da documentação dos padrões de arquitetura de segurança do
Open Security Architecture Group11, ou o sempre útil e recém-atualizado catálogo de controle de segurança do
NIST 800-53 revisão 3 Recommended Security Controls for Federal Information Systems and Organizations.
11
www.opensecurityarchitecture.org

1.5.2 O que é Segurança para a Computação em Nuvem?
Em sua maior parte, os controles de segurança da computação em nuvem não são diferentes dos controles de
segurança em qualquer ambiente de TI. Porém, a computação em nuvem pode apresentar diferentes riscos das
soluções tradicionais de TI para uma organização, por causa dos modelos de serviço de nuvem empregados e dos
modelos operacionais e tecnologias utilizadas para habilitar os serviços em nuvem.
A postura de segurança de uma organização é caracterizada pela maturidade, eficiência e integridade dos
controles de segurança implantados em função do risco. Esses controles são implantados em uma ou mais
camadas que vão desde as instalações (segurança física), à infraestrutura de rede (segurança da rede), para os
sistemas de TI (segurança do sistema) e, em todas as formas de informações e aplicações (segurança de
aplicações). Além disso, os controles são implantados nos níveis de pessoas e processo, tais como a separação de
tarefas e o gerenciamento de alterações, respectivamente.
Conforme descrito anteriormente neste documento, as responsabilidades de segurança tanto do provedor como
do consumidor diferem muito entre os modelos de serviço em nuvem. A proposta de Infraestrutura como um
Serviço do AWS EC2 da Amazon, por exemplo, inclui a responsabilidade do fornecedor pela segurança até o
hypervisor, isto é, eles podem tratar apenas dos controles de segurança, tais como a segurança física, a segurança
ambiental e segurança de virtualização. Por sua vez, o consumidor é responsável pelos controles de segurança
relacionados ao sistema de TI (instância), incluindo o sistema operacional, aplicações e dados.
O inverso é verdadeiro para a proposta de SaaS de gerenciamento de recursos de clientes (do inglês Customer
Resource Management - CRM) da Salesforce.com. Dado que o Salesforce.com fornece toda a “pilha”, o provedor
não é apenas responsável pelos controles de segurança física e ambiental, mas também deve tratar os controles
de segurança na infraestrutura, aplicações e dados. Isso alivia bastante a responsabilidade operacional direta do
consumidor.
Não há atualmente alguma maneira para que um consumidor inexperiente em serviços em nuvem simplesmente
entenda pelo que exatamente é responsável [embora a leitura deste guia possa ajudar], mas há esforços em
andamento por parte da CSA e de outros órgãos para definir os padrões em torno de uma auditoria em nuvem.
Um dos atrativos da computação em nuvem é a eficiência de custos propiciada pelas economias de escala,
reutilização e padronização. Para fazer uso dessas eficiências, os provedores de nuvem devem fornecer serviços
que sejam flexíveis o suficiente para atender a maior base possível de clientes, maximizando o seu mercado em
potencial. Infelizmente, integrar segurança a essas soluções é muitas vezes considerado como enrijecê-las.
Muitas vezes, esta rigidez se manifesta na impossibilidade de ganhar paridade na implantação dos controles de
segurança em ambientes de nuvem comparados aos tradicionais de TI. Isto se deve à abstração da infraestrutura,
bem como da falta de visibilidade e da capacidade de integrar muitos controles de segurança conhecidos,
especialmente na camada de rede.

A figura abaixo ilustra estas questões: em ambientes de SaaS, os controles de segurança e seu escopo são
negociados nos contratos de serviço; nos níveis de serviço, na privacidade e na conformidade, que são as
questões a serem tratadas legalmente nos contratos. Em uma proposta de IaaS, enquanto a responsabilidade de
assegurar as camadas de infraestrutura e de abstração subjacente pertence ao provedor, o restante do
empilhamento é de responsabilidade do consumidor. A PaaS oferece um equilíbrio em algum ponto
intermediário, onde fixar a plataforma cai sobre o provedor, mas proteger as aplicações desenvolvidos contra a
plataforma assim como desenvolvê-los de forma segura, pertence ao consumidor.
Figura 6 - Como Obter Segurança Integrada
Compreender o impacto destas diferenças entre os modelos de serviços e como eles são implantados é
fundamental para gerenciar a postura de risco de uma organização.
1.5.3 Além da Arquitetura: As Áreas de Foco Crítico
Os demais treze domínios compreendidos no restante do guia da CSA destacam as áreas de preocupação da
computação em nuvem e estão sintonizados para tratar tanto das questões críticas de estratégias como das
táticas de segurança dentro de um ambiente em nuvem e podem ser aplicados a qualquer combinação de modelo
de serviço em nuvem e de implantação.
Os domínios estão divididos em duas grandes categorias: de governança e operacionais. Os domínios de

governança são amplos e tratam de questões estratégicas e políticas dentro de um ambiente de computação em
nuvem, enquanto os domínios operacionais concentram-se em questões de segurança mais táticas e de
implantação dentro da arquitetura.

Tabela 2a - Domínios de Governança
DOMÍNIO CONTEÚDO TRATADO
A capacidade de uma organização governar e medir os riscos empresariais

introduzidos pela computação em nuvem. Itens como precedentes legais para
Gerenciamento de Governança e violações de contrato, a capacidade das organizações de usuários para avaliar
Risco Empresarial adequadamente o risco de um provedor de nuvem, a responsabilidade de
proteger dados confidenciais quando tanto o usuário quanto o provedor podem
ser culpados e, como fronteiras internacionais podem afetar estas questões.
Questões legais potenciais ao utilizar a computação em nuvem. As questões

Questões legais: Contratos e apresentadas nesta seção incluem os requisitos de proteção para os sistemas de
Electronic Discovery informação e computação, as leis de descoberta de brechas de segurança, os
requisitos regulatórios e de privacidade, as leis internacionais, etc.
Sustentar e comprovar a conformidade ao utilizar a computação em nuvem.

Aqui, são discutidas as questões relativas à avaliação de como a computação
em nuvem afeta o cumprimento das políticas de segurança interna, bem como
Conformidade e Auditoria os demais requisitos de conformidade (regulatórios, legislativos e de outra
espécie). Este domínio inclui algumas diretivas para comprovar a conformidade
durante uma auditoria.
Gerenciar dados colocados na nuvem. Aqui, são discutidas as questões que

envolvem a identificação e o controle dos dados em nuvem, bem como os
Gerenciamento da Informação e controles de compensação que podem ser utilizados para tratar a perda do
Segurança de Dados controle físico ao mover dados para a nuvem. São mencionadas outras questões
como, quem é responsável pela confidencialidade, integridade e disponibilidade
de dados.
A capacidade de mover dados/serviços de um provedor a outro ou, internalizar

Portabilidade e Interoperabilidade tudo de volta. E também com as questões que envolvem a interoperabilidade
entre os provedores.

Tabela 2b - Domínios Operacionais
DOMÍNIO
CONTEÚDO TRATADO
Como a computação em nuvem afeta os processos e os procedimentos

operacionais utilizados atualmente para implantar a segurança, a continuidade
de negócios e a recuperação de desastres. O foco é discutir e analisar os
Segurança Tradicional, Continuidade
possíveis riscos da computação em nuvem, na esperança de aumentar o diálogo
de Negócios e Recuperação de
e o debate sobre a avassaladora demanda por melhores modelos de gestão de
Desastres
riscos empresariais. Além disso, a seção trata de ajudar as pessoas a identificar
onde a computação em nuvem pode auxiliar a diminuir alguns riscos de
segurança ou acarretar crescimentos em outras áreas.
Como avaliar a arquitetura e as operações do centro de dados de um provedor.

Este é focado principalmente em ajudar os usuários a identificar as
Operações de Centro de Dados características comuns de centros de dados que podem ser prejudiciais aos
serviços em curso, bem como as características que são fundamentais para a
estabilidade em longo prazo.
A correta e adequada detecção de incidentes, a resposta, a notificação e a

correção. Este tenciona abordar os itens que devem estar no local, tanto nos
Resposta aos Incidentes, Notificação níveis dos provedores como dos usuários, para permitir o tratamento forense e
e Correção adequado de incidentes. Este domínio ajudará a compreender as
complexidades que a nuvem traz para o seu programa atual de tratamento de
incidentes.
Proteger o software de aplicação que está em execução ou em

desenvolvimento na nuvem. Isso inclui itens como se é apropriado migrar ou
Segurança de Aplicações
criar uma aplicação para ser executado na nuvem e, em caso afirmativo, qual o
tipo de plataforma em nuvem mais adequado (SaaS, PaaS, ou IaaS).
Identificar o uso adequado e escalonado de criptografia e gerenciamento de

Criptografia e Gerenciamento de chaves. Esta seção não é prescritiva, mas é mais informativa para discutir por
Chaves que eles são necessários e, para identificar os problemas que surgem com o
uso, tanto para proteger o acesso aos recursos, como para proteger os dados.
Gerenciar identidades e aproveitar os serviços de diretório para fornecer

controle de acesso. O foco é nas questões encontradas ao estender a
identidade de uma organização para a nuvem. Esta seção proporciona uma
Gerenciamento de Identidade e percepção para avaliar o quanto uma organização está pronta para conduzir a
Acesso gestão baseada em nuvem de Identidades, Direitos e Acessos (do inglês (IdEA)
Identity, Entitlement, and Access Management).

A utilização da tecnologia de virtualização na computação em nuvem. O

domínio aborda itens como os riscos associados ao multilocatário, o isolamento
da máquina virtual (do inglês VM - Virtual Machine), corresidência da VM,
Virtualização
vulnerabilidades do hypervisor, etc. Este domínio foca nas questões de
segurança que envolve a virtualização do sistema/hardware, em vez de uma
inspeção mais geral sobre todas as formas de virtualização.
Fornecer garantia de segurança, gerenciamento de incidentes, atestado de

conformidade e, supervisão de identidade de acesso facilitados por terceiros. A
segurança como um serviço é a delegação da detecção, da correção e da
Segurança como um Serviço (Security
governança da infraestrutura de segurança a um terceiro de confiança, com as
as a Service)
ferramentas e conhecimentos adequados. Os usuários deste serviço recebem o
benefício da experiência de especialistas e, a tecnologia de ponta na luta para
proteger e enrijecer as operações comerciais confidenciais.
1.6 Modelos de Implantação em Nuvem
Independentemente do modelo de serviço utilizado (SaaS, PaaS ou IaaS), existem quatro modelos de implantação
de serviços em nuvem, com variações de derivativos que abordam necessidades específicas.
É importante observar que devido à maturação das propostas de mercado e, à demanda do cliente estão surgindo
modelos derivados de implantação em nuvem. Um exemplo desse tipo são as nuvens privadas virtuais – um jeito
de utilizar a infraestrutura de nuvem pública de uma maneira privada ou semiprivada e interligar esses recursos
aos recursos internos do centro de dados do consumidor, geralmente através de conectividade de uma rede
privada virtual (VPN, do inglês Virtual Private Network).
A mentalidade arquitetônica utilizada na concepção de "soluções" tem implicações claras sobre flexibilidade,
segurança e mobilidade futuras da solução resultante, assim como as suas possibilidades colaborativas. Como
regra geral, as soluções com perímetros definidos são menos eficazes do que as soluções sem perímetros
definidos em cada uma das quatro áreas. Por razões similares, uma consideração cuidadosa deve ser dada à
escolha entre soluções proprietárias e aberta.
Modelos de implantação
 Nuvem Pública. A infraestrutura em nuvem é disponibilizada ao público em geral ou a um grande grupo

setorial e, é propriedade de uma organização que vende os serviços em nuvem.
 Nuvem Privada. A infraestrutura em nuvem é operada exclusivamente para uma única organização. Pode
ser gerenciada pela organização ou por um terceiro e pode estar localizada interna ou externamente.
 Nuvem Comunitária. A infraestrutura em nuvem é compartilhada por diversas organizações e atende a

uma comunidade específica, com preocupações comuns (por exemplo, missão, requisitos de segurança,
política ou, considerações de conformidade). Pode ser gerenciada pelas organizações ou por um terceiro
e pode estar localizada interna ou externamente.
 Nuvem Híbrida. A infraestrutura em nuvem é uma composição de duas ou mais nuvens (privada,
comunitária ou pública) que permanecem como entidades únicas, mas são unidas por tecnologia
padronizada ou proprietária que permite a portabilidade de dados e aplicações (por exemplo, a ruptura
da nuvem para o balanceamento de carga entre nuvens).

1.7 Recomendações
A prestação de serviços em nuvem é dividida em três arquetípicos modelos e diversas combinações de

derivativos. As três classificações fundamentais são muitas vezes referidas como o "Modelo SPI", onde "SPI"
refere-se a Software, Plataforma ou Infraestrutura (como um Serviço), respectivamente.
o Software como um Serviço em Nuvem (SaaS). O recurso fornecido ao consumidor é a utilização de

aplicações do provedor rodando em uma infraestrutura em nuvem. As aplicações são acessíveis de vários
dispositivos clientes, através de um navegador da web em uma interface thin client (por exemplo, um e-
mail via Web). O consumidor não gerencia ou controla a infraestrutura subjacente em nuvem, incluindo a
rede, os servidores, os sistemas operacionais, o armazenamento ou até mesmo os recursos das aplicações
individuais, com a possível exceção de configurações limitadas específicas de aplicações do usuário.
o Plataforma como um Serviço em Nuvem (PaaS). O recurso fornecido ao consumidor é para implantar as
aplicações adquiridas ou criadas pelo consumidor na infraestrutura em nuvem, utilizando linguagens de
programação e ferramentas suportadas pelo provedor. O consumidor não gerencia ou controla a
infraestrutura subjacente em nuvem, incluindo a rede, os servidores, os sistemas operacionais ou o
armazenamento, mas tem o controle sobre as aplicações implantadas e, possivelmente, sobre
configurações de ambiente de aplicações de hospedagem.
o Infraestrutura como um Serviço em Nuvem (IaaS). O recurso fornecido ao consumidor é para suprir o
processamento, o armazenamento, as redes e os outros recursos computacionais fundamentais, em que
o consumidor é capaz de implantar e executar softwares arbitrários que podem incluir sistemas
operacionais e aplicações. O consumidor não gerencia nem controla a infraestrutura em nuvem
subjacente, mas tem o controle sobre os sistemas operacionais, o armazenamento, as aplicações
implantadas e possivelmente o controle limitado de componentes selecionados de rede (por exemplo, os
firewalls do servidor).
O modelo do NIST e este documento não abordam diretamente as definições emergentes de modelos de serviços
associados aos agentes de serviços em nuvem, aqueles provedores que oferecem serviços de intermediação,
monitoramento, transformação/portabilidade, governança, provisionamento e integração e, negociam as
relações entre vários provedores de nuvem e consumidores.
Em curto prazo, como a inovação direciona para o desenvolvimento de uma solução rápida, os consumidores e os
provedores de serviços em nuvem desfrutarão de variados métodos para interagir com os serviços em nuvem na
forma de desenvolvimento de API e interfaces e, assim, os agentes de serviços em nuvem surgirão como um
importante componente no ecossistema global em nuvem.
Os agentes de serviços em nuvem abstrairão esses recursos e interfaces em nome dos consumidores,
possivelmente incompatíveis para representação antes da chegada de maneiras comuns, abertas e padronizadas
de resolver o problema em um longo prazo, com uma capacidade semântica que permite ao consumidor fluidez e
agilidade ao ser capaz de tirar vantagem do modelo que funciona melhor para suas necessidades específicas.
É importante observar também o surgimento de muitos esforços centrados no desenvolvimento de APIs abertas e
proprietárias, que visam permitir coisas como o gerenciamento, a segurança e a interoperabilidade em nuvem.
Para citar apenas alguns, inclui-se nesses esforços o Open Cloud Computing Interface Working Group, a API EC2
da Amazon, a API vCloud submetidos à DMTF pela VMware, a API Open Cloud da Sun, a API da Rackspace e a API
do GoGrid. Os padrões de APIs abertas desempenharão um papel fundamental na portabilidade e na
interoperabilidade em nuvem, assim como os formatos comuns de containers como o Open Virtualization Format
da DMTF (OVF).

Embora neste momento haja muitos grupos de trabalho, projetos e especificações publicadas em consideração, é
natural que a consolidação se dê de acordo com o mercado, pela demanda do consumidor e quando a economia
adaptar este panorama a um conjunto mais flexível e interoperável de atores (players).
1.8 Requisitos
Os serviços em nuvem apresentam cinco características essenciais que demonstram sua relação e suas diferenças
às abordagens computacionais tradicionais.
 Autosserviço sob demanda. Um consumidor pode unilateralmente provisionar os recursos de

computação, tais como o tempo do servidor e o armazenamento de rede, conforme necessário e
automaticamente, sem a necessidade da interação humana com um provedor de serviços.
 Amplo acesso à rede. Os recursos estão disponíveis através da rede e são acessados através de
mecanismos padrão que promovem a utilização de plataformas por thin ou thick client heterogêneos (por
exemplo, telefones celulares, laptops e PDAs)12, bem como de outros serviços de software tradicionais ou
baseados em nuvem.
 Agrupamento de recursos. Os recursos de computação do provedor são agrupados para servir vários
consumidores utilizando um modelo multilocatário com diferentes recursos físicos e virtuais atribuídos e
realocados dinamicamente conforme a demanda do consumidor. Há um grau de independência da
localização em que o cliente geralmente não tem controle ou conhecimento sobre a localização exata dos
recursos disponibilizados, mas consegue especificar o local em um nível maior de abstração (por exemplo,
o país, o estado ou o centro de dados). Exemplos de recursos incluem o armazenamento, o
processamento, a memória, a largura de banda da rede e as máquinas virtuais. Mesmo as nuvens
privadas tendem a agrupar os recursos entre as diferentes partes da mesma organização.
 Flexibilidade rápida. Os recursos podem ser rápidos e flexivelmente provisionados - em alguns casos,
automaticamente – para escalonar externamente e liberar para escalonar internamente de modo bem
rápido. Para o consumidor, os recursos disponíveis para provisionamento frequentemente parecem ser
ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer momento.
 Serviço medido. Sistemas em nuvem automaticamente controlam e aperfeiçoam a utilização dos

recursos, aproveitando uma capacidade de medição em algum nível de abstração apropriado para o tipo
de serviço (por exemplo, o armazenamento, o processamento, a largura de banda ou as contas de
usuários ativos). A utilização dos recursos pode ser monitorada, controlada e relatada, oferecendo
transparência tanto para o provedor como para o consumidor do serviço.
A chave para a compreensão de como a arquitetura da nuvem impacta na arquitetura de segurança é formada
por um vocabulário simples e conciso, associado a uma taxonomia consistente de propostas, pelos quais os
serviços em nuvem e a arquitetura podem ser desconstruídos, mapeados para um modelo de compensação de
controles de segurança e operacionais, de frameworks de avaliação de risco e de frameworks de gerenciamento,
e; por sua vez, em padrões de conformidade.
É fundamental entender como a arquitetura, a tecnologia, os processos e requisitos de capital humano mudam
ou permanecem os mesmos durante a implantação de serviços de computação em nuvem. Sem uma clara
compreensão das implicações arquitetônicas de alto nível é impossível tratar racionalmente as questões mais
detalhadas. Esta visão geral da arquitetura, juntamente com as outras treze áreas de foco crítico, fornecerá ao
12
PDA - Assistente Pessoal Digital (do inglês, Personal Digital Assistant)

leitor uma base sólida para a avaliação, operacionalização, gerenciamento e administração da segurança em
ambientes de computação em nuvem.
REFERÊNCIAS
[1] Definição de nuvem pelo NIST.

NIST 500-292 “NIST Cloud Computing Reference Architecture”
[2] Definições do NIST e páginas iniciais da API.

www.cloud-standards.org
[3] Modelo Cloud Cube do fórum Jericho.

www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf

SEÇÃO II //
GOVERNANÇA NA
NUVEM

DOMÍNIO 2 //
GOVERNANÇA E GERENCIAMENTO DE RISCO EMPRESARIAL
As questões fundamentais sobre governança e gerenciamento de risco empresarial em computação em nuvem

relacionam-se com a identificação e a implementação de uma estrutura organizacional adequada, com processos
e com controles para a efetiva manutenção da governança da segurança da informação, do gerenciamento de
risco e da conformidade. As organizações devem, também, assegurar um nível razoável de segurança da
informação sobre toda a cadeia de informações, abrangendo provedores e clientes de serviços de computação
em nuvem e fornecedores terceirizados em qualquer modelo de implantação de computação em nuvem.
Um programa efetivo de governança e de gerenciamento de risco empresarial em computação em nuvem tem

origem em processos bem desenvolvidos de governança de segurança da informação como parte das obrigações
gerais de governança corporativa da organização. Processos de governança de segurança da informação bem
desenvolvidos resultam em programas de gerenciamento de segurança da informação que são escaláveis de
acordo com as necessidades dos negócios, repetíveis em toda a organização, mensuráveis, sustentáveis,
justificáveis, continuamente melhoráveis e de baixo custo ao longo do tempo.
Para muitas implantações de computação em nuvem um elemento importante da governança será o acordo
entre o provedor e o cliente. Para ambientes personalizados, cuidados extras podem ser negociados e tomados
para cada provisionamento. Para clientes e provedores de grande porte existirá um dilema entre atenção ao
detalhe e escalabilidade. Atenção pode ser priorizada baseando-se na criticidade ou no valor do risco de uma
carga de trabalho (por exemplo, tempo de operação e disponibilidade podem ser mais importantes para um
sistema de E-Mail do que para um sistema da área de recursos humanos). À medida que houver amadurecimento,
projetos como o Cloud Audit ou o STAR fornecerão mais métodos de governança padronizados e, por
consequência, maior escalabilidade.
Visão Geral. Esse domínio trata de:
 Governança
Essa seção faz referência à Matriz de
 Gerenciamento de Risco Empresarial
Controles em Nuvem DG-01, IS-02
e ao uso do GRC-XML e CloudAudit
2.1 Governança Corporativa para estabelecer resoluções.
Governança corporativa é o conjunto de processos, tecnologias, agentes alfandegários, políticas, leis e instituições
que afetam o modo como uma empresa é dirigida, administrada ou controlada. A governança corporativa
também inclui a relação entre as diversas partes interessadas e os objetivos da companhia. A boa governança é
baseada na aceitação dos direitos dos acionistas, como os verdadeiros donos da empresa e o papel da alta
gerência como fiéis depositários. Existem muitos modelos de governança corporativa, no entanto, todos seguem
cinco princípios básicos:
 Auditorias das cadeias de abastecimento
 Existência de estrutura e processo de administração e de gerenciamento
 Responsabilidade corporativa e conformidade

 Transparência financeira e divulgação de informações
 Estrutura de propriedade e exercício de direitos de controle
Um fator chave na decisão do cliente de contratar uma corporação é a confiança de que as expectativas serão
atendidas. Para serviços de computação em nuvem, a interdependência entre múltiplos serviços torna mais difícil
para um cliente classificar a parte responsável. Se isso resultar em menos confiança em determinado fornecedor
é menos provável que haja maior envolvimento com o mesmo. Se essa menor confiança tornar-se uma
característica sistêmica, a perda de confiança em um ator será propagada para os outros e as deficiências do
mercado irão aumentar a probabilidade de surgirem ações externas, bem como participantes alternativos.
As partes interessadas devem considerar cuidadosamente os mecanismos de controle que sejam adequados e
necessários para o desempenho e o crescimento consistentes da empresa.
2.2 Gerenciamento de Risco Empresarial
O Gerenciamento de Risco Empresarial (ERM, na sigla em Inglês) tem origem no compromisso de todas as
organizações fornecerem valor para as partes interessadas. Todos os negócios enfrentam incertezas e um dos
desafios dos gerentes é determinar como uma organização pode medi-las, gerenciá-las e mitigá-las. Incertezas
apresentam tanto oportunidades quanto riscos que têm potencial para aumentarem ou diminuírem o valor da
organização e das estratégias da mesma.
O gerenciamento de risco da informação é o processo de identificar e compreender a exposição ao risco e a

capacidade de gerenciá-lo, de forma alinhada com o apetite ao risco e com a tolerância do proprietário dos
dados. Consequentemente, é o recurso primário de suporte à decisão em relação aos recursos de TI dedicados
que são responsáveis pela garantia da confidencialidade, da integridade e da disponibilidade de ativos
informacionais.
O Gerenciamento de Risco Empresarial em negócios inclui os

Essa seção faz referência à Matriz de
métodos e processos usados pelas organizações para gerenciarem
Controles em Nuvem DG-08 e ao uso
riscos e para capturarem oportunidades relacionadas ao das diretrizes da ISO31000, ISF e ISACA
atingimento dos objetivos da companhia. Em um ambiente de para estabelecer resoluções.
computação em nuvem a gerência seleciona uma estratégia de
resposta para riscos específicos identificados e analisados que
podem incluir:
 Anular – deixar de fazer as atividades que dão origem ao risco
 Reduzir – agir para reduzir a probabilidade ou o impacto relacionado ao risco
 Compartilhar ou segurar – transferir ou compartilhar uma parte do risco financiando-o
 Aceitar – nenhuma ação é tomada em função de uma decisão relacionada ao custo-benefício
O gerenciamento de risco é, naturalmente, um processo de balanceamento com o objetivo de, não

necessariamente, minimizar incerteza ou variação, mas sim de maximizar valor de forma alinhada com o apetite
ao risco e com a estratégia.

Existem muitas variáveis, valores e riscos em qualquer oportunidade ou planejamento da computação em nuvem
que afetam a decisão sobre se um serviço deve ser adotado a partir do ponto de vista do risco ou do negócio.
Cada corporação tem que ponderar tais variáveis para decidir se a computação em nuvem é uma solução
apropriada.
A computação em nuvem oferece muitos benefícios para as empresas e alguns deles são:
 Uso otimizado de recursos
 Redução de custos para os clientes de computação em nuvem
 Transição de despesas de capital (CAPEX) para despesas operacionais (OPEX)
 Escalabilidade dinâmica de capacidade de TI para os clientes
 Encurtamento do ciclo de vida de desenvolvimento ou de implantação de novas aplicações
 Encurtamento do tempo necessário para a implementação de novos negócios
Os clientes devem ver os serviços de computação em nuvem e de segurança como questões de segurança da
cadeia de fornecimento. Isso significa analisar e avaliar a cadeia do fornecedor (relacionamentos e dependências
do prestador de serviços) na medida do possível. Isso também significa examinar a própria gestão de terceiros
que é feita pelo provedor. A avaliação dos prestadores de serviços deve visar, especificamente, a gestão de
incidentes feita pelos provedores, as políticas de continuidade de negócios e de recuperação de desastres, bem
como processos e procedimentos e, deve incluir a revisão de instalações de locação compartilhadas e de backup.
Isso deve incluir a revisão das avaliações internas de conformidade dos provedores com as próprias políticas e
procedimentos de avaliação de métricas usadas pelos mesmos para que se obtenham informações razoáveis em
relação ao desempenho e eficácia dos controles nessas áreas. Informações sobre incidentes podem ser
especificadas em contratos, SLAs, ou outros acordos e, podem ser comunicadas automaticamente ou
periodicamente, diretamente em sistemas de notificação ou entregues ao pessoal-chave da empresa. O nível de
atenção e de segurança deve estar conectado ao valor em risco – se o terceiro não acessar diretamente os dados
da empresa, então o nível de risco cai significativamente e vice-versa.
Os clientes devem rever os processos de gestão de risco e de governança de seus fornecedores para garantirem
que as práticas são consistentes e alinhadas.
2.3 Permissões
Permissões
 Adotar uma estrutura para monitorização e medição de riscos corporativos.
 Adotar métricas para a medição de desempenho da gestão de risco (como o Content Security Automation
Protocol (SCAP)13, o Cybersecurity Information Exchange Framework (CYBEX)14 ou o GRC-XML15).
13
SCAP - Security Content Automation Protocol
14
CYBEX - Cybersecurity Information Exchange Framework
15
GRC-XML - padrões tecnológicos para a habilitação e a melhoria do compartilhamento de informações entre diversas
tecnologias que suportam a aplicação do GRC

 Adotar uma perspectiva de governança corporativa que seja centrada no risco, com a alta gerência
assumindo o papel de administradora tanto para os acionistas como para as partes interessadas na cadeia
de fornecimento.
 Do ponto de vista legal, adotar uma estrutura para lidar com as diferenças entre jurisdições.
2.4 Recomendações
o Reinvestir as economias obtidas com os serviços de computação em nuvem em análises mais detalhadas
das capacidades de segurança do provedor, em aplicação de controles de segurança e em avaliações e
auditorias detalhadas para garantir que os requisitos sejam atendidos continuamente.
o As organizações devem incluir a revisão de estruturas específicas de governança de segurança da

informação e de processos, bem como de controles de segurança específicos, como parte de sua
diligência nos futuros prestadores de serviços. Os processos e as capacidades de governança de segurança
do provedor devem ser avaliados quanto à suficiência, maturidade e coerência com processos de gestão
de segurança da informação dos usuários. Os controles de segurança da informação do provedor devem
estar baseados em riscos e devem apoiar os processos de gestão.
o Estruturas e processos colaborativos de governança entre clientes e fornecedores devem ser identificados
como indispensáveis, seja como parte do projeto e do desenvolvimento da prestação de serviços, ou
como avaliação de risco dos serviços e como protocolo de gestão de risco para, então, serem
incorporados como parte integrante dos acordos de serviços.
o Departamentos de segurança devem ser envolvidos durante o estabelecimento de Acordos de Nível de

Serviço (SLAs na sigla em Inglês)16 e de obrigações contratuais para assegurarem que os requisitos de
segurança sejam aplicáveis contratualmente.
o Métricas e padrões para a medição de desempenho e da eficácia da gestão de segurança da informação

devem ser estabelecidos antes de uma mudança para a computação em nuvem. As organizações devem,
no mínimo, compreender e documentar as métricas atuais e como elas mudarão quando as operações
forem movidas para um serviço de computação em nuvem, que pode ser um provedor onde as métricas
usadas sejam diferentes (potencialmente incompatíveis).
o Devido à falta de controle físico sobre infraestrutura por parte dos clientes, em muitas implementações
de computação em nuvem os SLAs, os requisitos do contrato e a documentação do provedor
desempenham um papel maior na gestão de risco do que em infraestruturas tradicionais próprias.
o Devido ao provisionamento sob demanda e aos aspectos multicliente da computação em nuvem, as

formas tradicionais de auditoria e de avaliação podem não estar disponíveis ou podem não ser
modificáveis. Alguns provedores, por exemplo, podem restringir as avaliações de vulnerabilidade e os
testes de invasão, enquanto outros podem limitar a disponibilidade de logs de auditoria e de
monitoramento de atividades. Se as suas políticas internas exigirem esses requisitos, você precisará
procurar opções de avaliação, exceções contratuais específicas ou um fornecedor alternativo melhor
alinhado com suas necessidades de gestão de risco.
o Se os serviços prestados na nuvem são essenciais para as operações empresariais, uma abordagem de
gestão de risco deve incluir a identificação e a avaliação de ativos, a identificação e a análise de ameaças e
16
SLA - Service Level Agreement

de vulnerabilidades e, o potencial impacto das mesmas sobre os ativos (risco e cenários de incidentes), a
análise das probabilidades de eventos/cenários, os níveis e critérios de aceitação de riscos aprováveis
pela gerência, bem como 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 risco devem
ser parte integrante dos acordos de serviços.
o Abordagens de avaliação de risco entre fornecedor e usuário devem ser consistentes em termos de
critérios de análise de impacto e de definição de probabilidade. O usuário e o fornecedor devem
desenvolver, conjuntamente, os cenários de risco para o serviço de computação em nuvem e essa prática
deve ser intrínseca ao desenho do serviço para o usuário feito pelo provedor, bem como à avaliação dos
riscos do serviço feitas pelos usuários.
o Devido à natureza evolutiva da computação em nuvem e dos fornecedores, devem ser tomados cuidados
para inclusão do risco do fornecedor como, por exemplo, a sobrevivência dos fornecedores, a
portabilidade de dados e de aplicações e a interoperabilidade dos serviços.
o Inventários de ativos devem contabilizar os ativos que suportam os serviços em nuvem e que estejam sob
o controle do provedor. A classificação de ativos e os sistemas de avaliação devem ser coerentes entre o
usuário e o provedor.
o Além do fornecedor, o serviço também deve ser objeto de avaliação de risco. O uso de serviços de
computação em nuvem, os modelos específicos de serviço e de implementação a serem utilizados devem
ser consistentes com os objetivos de gestão de risco da organização, bem como com os objetivos de
negócios.
o Clientes de serviços de computação em nuvem e provedores de serviço devem desenvolver uma

governança de segurança informação robusta, independentemente dos modelos de serviço ou
implantação. A governança de segurança da informação deve ser uma colaboração entre clientes e
fornecedores para alcançar as metas acordadas que suportem a missão empresarial e o programa de
segurança da informação. A governança deve incluir revisões periódicas e o modelo de serviço pode
sofrer ajustes nos papéis e nas responsabilidades definidas na governança colaborativa e na gestão de
risco de segurança da informação (com base no respectivo escopo de controle para o usuário e para o
prestador de serviços), enquanto o modelo de implantação pode definir a responsabilidade e as
expectativas (com base na avaliação de risco).
o Os clientes de serviços de computação em nuvem devem se autoquestionar se a própria gerência definiu

tolerâncias ao risco no que diz respeito aos serviços de computação em nuvem e se aceitou qualquer
risco residual resultante da utilização de tais serviços.
o Caso o prestador de serviços não demonstre processos abrangentes e eficazes de gestão risco associados
aos serviços, os clientes devem avaliar cuidadosamente o uso desse fornecedor, bem como as próprias
habilidades do usuário para compensar as potenciais lacunas de gestão de risco.
o As organizações devem definir métricas de risco para a contratação dos prestadores de serviços, baseadas
em aspectos técnicos e de negócios. Essas métricas podem incluir o tipo de dados, a variedade de tipos de
usuários relacionadas com a informação e os fornecedores, bem como outras partes envolvidas.

2.5 Requisitos
 Prover transparência aos investidores e acionistas, demonstrando a resolução fiscal e a transparência

organizacional.
 Respeitar a interdependência dos riscos inerentes à cadeia de fornecimento da computação em nuvem,

comunicar a postura de risco corporativo e a disponibilidade para os consumidores e, para os demais
dependentes.
 Inspecionar e considerar os riscos herdados de outros membros da cadeia de fornecimento da

computação em nuvem e tomar providências para mitigar e conter tais riscos através de uma resiliência
operacional.

DOMÍNIO 3 //
QUESTÕES LEGAIS: CONTRATOS E MAPEAMENTO ELETRÔNICO DE
INFORMAÇÕES
Este Domínio destaca alguns aspectos legais de computação em nuvem. Provê embasamento geral para questões
legais que podem surgir ao migrarmos dados para a nuvem, questões relativas a acordos de prestação de serviço
que devem ser consideradas e também questões específicas relativas ao mapeamento eletrônico de informações
quando sob ação judicial norte-americana.
Este domínio provê apenas uma visão geral dos assuntos mencionados e não deve ser utilizado como
aconselhamento jurídico.
Overview. Este domínio abordará os seguintes tópicos:
 Elenco de questões legais específicas ao migrar dados para a nuvem

 Questões relativas a acordos de prestação de serviço em nuvem
 Questões especificas relativas ao processo de “e-discovery”
3.1 Questões legais
Em muitos países, inúmeras leis, regulamentações e outros instrumentos compulsórios requerem que
organizações públicas e privadas protejam a privacidade de dados pessoais e, a segurança da informação e de
sistemas computacionais. Por exemplo, na região asiática, Japão, Austrália, Nova Zelândia e outros países
adotaram leis de proteção de dados que requerem que o controlador destes dados adote medidas razoáveis
tanto de caráter técnico, físico e administrativo, para proteger informações pessoais contra perda, uso indevido
ou alteração, baseados no guia de boas práticas para privacidade e segurança da Organização para a Cooperação
e Desenvolvimento Económico (OECD) 17 e, o framework da Cooperação Econômica da Ásia e do Pacífico (APEC)18.
Na Europa, os estados membros da Área Econômica Europeia (EEA)19 estabeleceram leis de proteção de dados
alinhados com a diretiva de proteção de dados20 posta em 1995 pelas Nações Unidas (EU) e a diretiva de
privacidade de 2002 (ePrivacy Directive) atualizada em 2009. Essas leis incluem obrigações de provisão de
segurança adequada que deve ser repassada a subcontratantes. Outros países que renegaram o compromisso
com tais leis da EEA como Marrocos e Tunísia na África e, Israel e Dubai no Oriente Médio, adotaram leis similares
seguindo os mesmos princípios.
Países das Américas do Norte, Central e do Sul também estão adotando leis de proteção de dados rapidamente.
Cada uma dessas leis inclui requisitos de segurança e responsabilização do custodiante dos dados quanto à
garantia de proteção e segurança de dados pessoais independentemente da localização da mesma e, em especial
quando transferida para terceiros. Por exemplo, além das leis de proteção de dados existentes há anos no
17
OECD - Organization for Economic Cooperation and Development
18
APEC - Asia Pacific Economic Cooperation
19
EEA - European Economic Area
20
EU Directive 95/46/EC

Canadá, Argentina e Colômbia, também recentemente o México, Uruguai e Peru aprovaram leis inspiradas no
modelo europeu e também possivelmente referenciadas ao framework APEC.
No Japão, o ato jurídico de proteção de informação pessoal requer que setores privados protejam informação
pessoal e dados de forma segura. No setor de saúde, leis de conduta professional específica como o ato jurídico
de prática médica, o ato jurídico de enfermagem na saúde pública, parteiras e enfermeiras e, o ato jurídico
farmacêutico, requerem que hajam profissionais de saúde registrados para lidar com informações confidenciais
de paciente.
Organizações com negócios nos Estados Unidos podem estar sujeitas a uma ou mais leis de proteção de dados.
Essas leis responsabilizam as organizações por ações realizadas por seus subcontratados. Por exemplo, as regras
de segurança e privacidade sob o ato jurídico Gramm-Leach-Bliley (GLBA)21 ou o Ato Jurídico de Portabilidade e
Cobrança de Seguros de Saúde (HIPAA), de 1996, requerem que organizações sujeitem subcontratantes a
utilizarem medidas razoáveis de segurança e proverem recursos para privacidade, contratualmente. Agências do
governo, como a Comissão do Livre Comércio (FTC) ou a Advocacia Geral da União têm considerado responsáveis
organizações pela atividade exercida por seus subcontratados. As Normas de Segurança de Dados (do inglês, Data
Security Standards, DSS) do Setor de Cartões de Crédito (do inglês, Payment Card Industry, PCI) que são aplicáveis
a dados de cartão de crédito internacionalmente, incluindo dados processados por subcontratados, possui
requisitos similares.
As demais seções mostram exemplos de questões legais que podem surgir ao transferirmos dados pessoais para a
nuvem ou o processamento desses dados na nuvem.
Tabela 1 — Obrigatoriedades adjuntas
DOCUMENTO DESCRIÇÃO
Várias leis federais e suas regulamentações relacionadas, como GLBA, HIPAA, Ato
Jurídico de Proteção Online da Privacidade de Crianças (“COPPA”) de 1998, juntamente
Leis federais dos Estados
com outros emitidos pela FTC, obrigam organizações a adotarem medidas de proteção
Unidos da América
de segurança e privacidade para o processamento de dados, a requererem precauções
similares em seus contratos com provedores de serviço terceirizado.
Várias leis estaduais obrigam empresas a proverem segurança adequada para dados
pessoais e a requererem que seus provedores de serviço também o façam. Leis estaduais
Leis estaduais dos Estados que regem questões de segurança da informação geralmente requerem que no mínimo
Unidos da América as empresas tenham contratos firmados com provedores de serviços, incluindo medidas
razoáveis de segurança. Veja por exemplo os extensos requisitos sob Regulação de
Segurança no estado de Massachusetts.
Normas como PCI DSS ou ISO 27001 também criam um efeito dominó como os das leis
federais e estaduais. Empresas regidas por requisitos PCI DSS ou ISO 27001 além de
Normas
mostrarem-se aderentes às mesmas também precisam obrigar seus subcontratados a
fazerem o mesmo.
Regulamentações Muitos países têm adotado leis de proteção de dados que seguem o modelo europeu
Internacionais OECD ou APEC. O controlador dos dados, regido por essas leis (tipicamente a entidade
21
GLBA - Gramm-Leach-Billey Act

que se relaciona com o indivíduo) permanece responsável pela coleta e processamento

de dados pessoais, mesmo quando o processamento de fato ocorrer por intermédio de
terceiros. O controlador de dados é solicitado a garantir que essas entidades terceiras
processando dados sob sua solicitação implementem medidas de segurança técnica e
organizacional para proteção dos dados.
Mesmo se uma atividade específica não for regulamentada, empresas podem ter
obrigações contratuais de proteção de informações pessoais de seus clientes, contatos
ou colaboradores, garantindo que os dados não possam ser utilizados para outros fins e
não são expostos a terceiros. Esta obrigação pode se referir por exemplo aos Termos e
Condições e, Declaração de Privacidade exibidos nos sites de Internet da empresa.
Alternativamente, a empresa pode ter se comprometido por meio de contratos com
seus clientes (como por exemplo acordos de serviço) a proteger dados (pessoais ou
corporativos), limitar seu uso, garantir a segurança dos mesmos, usar criptografia, etc.
A organização precisa garantir que quando os dados e sua custódia estejam na nuvem,
Obrigações Contratuais
eles possuam a capacidade de atender continuamente as promessas e compromissos
assumidos em informes de privacidade e outros contratos.
Por exemplo, a empresa pode ter acordado em fazer uso específico de um conjunto de
dados. Esses dados quando na nuvem devem ser utilizados apenas e tão somente para
aqueles propósitos acordados.
Caso o informativo de privacidade dos dados permitir a indivíduos terem acesso a seus
dados pessoais, modificá-los ou deletá-los, o provedor de serviços em nuvem deve
também permitir que esses direitos sejam executados da mesma forma que seriam se
em um ambiente tradicional (fora da nuvem).
Muitas leis no mundo todo proíbem ou restringem transferência de informação para fora
do país. Em muitos casos, essa transferência quando permitida, requer que o país que
recebe os dados transferidos ofereça proteção adequada para os dados pessoais e
também mantenha o direito à privacidade. O propósito destes requisitos de adequação é
garantir que informações de um indivíduo que seja transferida para outro país possa
gozar de proteções e direito de privacidade similares e não inferiores daqueles aplicados
Proibição de ao local original da informação.
transferências cruzando
Assim, é importante que usuários de serviços em nuvem saibam onde estão sendo
fronteiras
armazenados os dados pessoais de seus colaboradores, clientes e outros, para
especificarem restrições específicas compatíveis com o país no qual está sendo feito o
armazenamento destes dados.
Dependendo do país, os requisitos para garantir essa proteção adequada podem ser
complexos e rigorosos. Em alguns casos pode ser necessária a obtenção prévia de
permissão do responsável local.
3.2 Considerações contratuais
Quando os dados são transferidos para a nuvem, a responsabilidade pela proteção e segurança dos mesmos é
tipicamente de quem a coletou ou mantém sua custódia, ainda que em alguns casos essa responsabilidade possa

ser compartilhada com outros. Quando repassado o processamento ou a guarda de dados para terceiros, o
custodiante dos dados permanece responsável por qualquer perda, extravio ou uso inadequado dos mesmos. É
considerado prudente e pode ser requerido legalmente, que os custodiantes dos dados e o provedor de serviços
em nuvem firmem um acordo formal que claramente defina os papéis e obrigações entre as partes e estabeleça
entre eles as várias responsabilidades que os dados em questão possam merecer.
As leis, regulações, normas e melhores práticas discutidas acima também requerem que os custodiantes
garantam que essas obrigações sejam cumpridas, por meio de verificações proativas (antes da execução do
contrato) ou auditorias de segurança (durante a execução do contrato).
3.2.1 Verificações proativas (Due Dilligence)
Antes de ingressar em um acordo com o provedor de serviços em nuvem, a empresa deve avaliar suas próprias
práticas, necessidades e restrições, para identificar as barreiras legais e aderências aos requisitos associados com
a proposta de transição para a nuvem. Por exemplo, deve-se determinar se o modelo de negócio da empresa
propicia o uso de serviços em nuvem. A natureza do negócio pode ser de tal tipo que requeira que o controle dos
dados obedeça a leis específicas, criando sérias preocupações de segurança.
Além disso, a empresa deve (e em alguns casos é obrigada legalmente a fazê-lo) realizar verificações proativas nos
provedores de serviços em nuvem, para verificar se a oferta irá permitir que a empresa cumpra com as
obrigações de proteção de seus ativos.
3.2.2 Contrato
As partes devem formalizar um contrato. Dependendo da natureza dos serviços, o contrato pode ser padrão (pré-
definido) ou permitir a negociação entre as partes de um documento mais complexo customizado para uma
situação específica. Se o documento padrão é o único disponível, o cliente deve avaliar os riscos de prosseguir
com a negociação em termos de benefícios, economia financeira e facilidades prometidas pelo provedor. Caso as
partes consigam negociar um contrato com interesses comuns, eles devem assegurar-se de que o mesmo contém
cláusulas condizentes com suas necessidades e obrigações durante a duração do mesmo e também em caso de
término. Necessidades específicas e riscos provenientes da operação em ambiente de computação em nuvem
devem ser negociados.
Caso um contrato não cubra tais questões, o cliente de serviços de computação em nuvem deve verificar formas
alternativas de atingir seus objetivos, um provedor alternativo ou mesmo não enviando seus dados para a nuvem.
Por exemplo, caso um cliente deseje enviar informações cobertas pela HIPPA para a nuvem, ele deve procurar um
provedor que assine um acordo de negócios específico (HIPPA) ou caso contrário não enviar seus dados para a
nuvem.
Abaixo, há uma breve descrição de algumas questões específicas relacionadas à computação em nuvem. Além
disso, uma lista anexa (não completa) contendo questões que devem ser avaliadas quando verificando contratos
de serviços de computação em nuvem pode ser vista.
3.2.3 Monitoramento, Testes e Atualizações

O ambiente de computação em nuvem não é estático. Ele evolui e os usuários e fornecedores precisam adaptar-
se. Monitoração periódica, testes e avaliação dos serviços são recomendados para assegurar-se de quais medidas
de segurança e privacidade estão sendo utilizadas e quais processos e políticas estão sendo seguidos.
Além disso, o cenário legal técnico e regulatório está sujeito a mudanças em curto espaço de tempo. Novas
ameaças de segurança, novas leis e novos requisitos a seguir precisam ser imediatamente adotados. As partes
precisam estar alinhadas com requisitos legais e outros para garantir que as operações permanecem aderentes a
leis aplicáveis e que medidas de segurança aplicadas evoluam na mesma medida que novas tecnologias e
legislações vão surgindo.
Auditoria de Computação em Nuvem (Cloud Audit) e Protocolo de Confiança em Nuvem (Cloud Trust Protocol) são
dois mecanismos utilizados para automatizar a monitoração e o teste da cadeia de fornecimento de computação
em nuvem. Além disso, o ITU-T trabalha atualmente em uma especificação para auditoria de computação em
nuvem conhecida como CYBEX (X.1500 Cloud Auditing).
3.3 Questões especiais relacionadas a mapeamento eletrônico de informações (E-

Discovery)
Esta seção trata de requisitos de litígio exclusivos da legislação dos Estados Unidos. Litigantes estadunidenses
confiam piamente em documentos quando arguindo seus casos em corte. Uma das peculiaridades do sistema
jurídico estadunidense, em contraste com o de muitos países, é que um litigante estadunidense deve prover ao(s)
seu(s) adversário(s) todo o conjunto documental pertencente ao caso em questão (inclusive os documentos que
não sejam favoráveis a ele na disputa da causa).
Recentemente, vários casos escandalosos deram conta de que litigantes foram acusados de deliberadamente
deletar, perder ou modificar documentos de evidências importantes com o objetivo de beneficiar-se em uma
causa em disputa. Por isso, regras e procedimentos foram modificados para clarificar obrigações entre as partes,
especialmente em casos que envolvam informações guardadas eletronicamente (ESI).
Como a nuvem irá se tornar o repositório da maioria das informações guardadas eletronicamente pertinentes a
ações de litígio ou investigações, provedores de computação em nuvem e seus clientes devem planejar
cuidadosamente como identificarão todos os documentos pertinentes ao caso, atendendo os requisitos impostos
pelo código civil federal e leis estaduais equivalentes relacionadas ao mapeamento de informações eletrônicas (E-
Discovery).
Sobre este ponto, provedores e clientes de serviços de computação em nuvem precisam considerar os aspectos
abaixo citados em ocasiões em que o cliente é alvo de uma solicitação de mapeamento de informação eletrônica
e dados relativos existirem em um dado provedor de serviços.
3.3.1 Posse, custódia e controle
Na maioria das jurisdições estadunidenses, as obrigações de uma parte em produzir informação relevante ao caso
são restritas aos dados em sua posse, custódia ou controle. Dados armazenados em terceiros, até mesmo
provedores de computação em nuvem, não desobrigam a parte de fornecer tais informações já que pode haver
solicitação legal de acesso ou obtenção das mesmas. No entanto, nem todos os dados armazenados em um
provedor de computação em nuvem podem estar sob controle do cliente (por exemplo: sistemas de recuperação
de desastres ou, certas informações de metadados mantidas pelo provedor para operar o ambiente). Distinguir
que tipo de dados está ou não disponível para o cliente pode ser de interesse tanto do cliente quanto do

provedor. As obrigações pertinentes ao provedor de serviços de computação em nuvem no que diz respeito a
disponibilização de informações referentes a um processo jurídico fica a cargo de cada jurisdição resolver.
3.3.2 Aplicações e ambientes relevantes de computação em nuvem
Em certos casos de litígio e investigação as aplicações e ambientes computacionais utilizados na computação em

nuvem podem ser relevantes na resolução de causas em disputa. Nestas circunstâncias tanto as aplicações
quanto os ambientes estão normalmente fora do controle do cliente e requerem mandato judicial para obtenção
dos dados referentes junto ao provedor.
3.3.3 Ferramentas de procura e mapeamento de informações
Devido a limitações do ambiente de computação em nuvem, direito de acesso ou outro motivo, um cliente pode
não poder utilizar ferramentas de procura e mapeamento de informações como se estivesse em seu próprio
ambiente local. Por exemplo, um dado cliente pode conseguir listar e acessar diretamente informações de várias
contas de e-mails contidas em seu servidor local, mas essa capacidade pode ser restrita para as informações
equivalentes quando o serviço estiver sendo disponibilizado por um provedor de computação em nuvem. Por
isso, clientes precisam planejar-se para demora adicional na obtenção de informações referentes a um caso
devido a essa limitação de acesso.
3.3.4 Preservação
Em geral, nos Estados Unidos, existem obrigações relativas a uma parte no sentido de tomar devidas precauções
para evitar a destruição ou, a modificação de dados ou informações sob sua posse, custódia ou controle caso ela
presumidamente saiba tratar-se de parte de um processo litigioso ou investigação corrente. Dependendo do tipo
de serviço ou modelo de computação em nuvem utilizada pelo cliente, esta preservação pode dar-se de forma
similar a infraestruturas de TI convencionais ou significativamente mais complexas.
Na União Europeia, a preservação da informação é regida pela diretiva 2006/24/EC do parlamento europeu e
legislação de março de 2006. Japão, Coreia do Sul e Singapura têm iniciativas de proteção aos dados similares. Na
América Latina, Brasil e Argentina possuem a Lei de Crimes Cibernéticos de Eduardo Azeredo (12.735/2012) e a
Lei de Retenção de Dados (25.873) de 6 de fevereiro de 2004, respectivamente.
3.3.4.1 Custos e armazenamento
Preservação de dados requer que grandes volumes de dados sejam armazenados por longos períodos de tempo.
Quais são as ramificações disso em um SLA? O que acontece se os requisitos de preservação superarem os
contidos no SLA? Se o cliente preservar os dados no local de armazenamento, quem arca com o custo e qual o
preço disso? O cliente possui capacidade de armazenamento garantida por seu SLA? O cliente pode realizar
download de seus dados armazenados sem que os mesmos sejam afetados em suas características de estado
(para fins de uso forense por exemplo)?
3.3.4.2 Escopo da preservação
Salvo em casos especiais, requisições para obtenção de dados armazenados em computação em nuvem são
realizadas apenas para os dados relativos a esta parte e não a todos os dados contidos na nuvem ou em uma
aplicação. Contudo, caso o cliente não possua recursos para preservar seus dados de maneira granular pode ser

necessário a guarda de dados de maneira geral preservando a capacidade de atender a solicitações de

investigação ou litígios.
3.3.4.3 Armazenamento compartilhado e dinâmico
As dificuldades de preservação de dados em computação em nuvem podem ser relativamente modestas caso o
cliente detenha espaço suficiente para armazená-la, já que os dados são relativamente estáticos e o número de
pessoas com acesso às mesmas é limitado. No entanto, em ambientes que programaticamente modificam e
removem dados ou mesmo em um ambiente em que os dados são compartilhados com pessoas que não têm a
clara noção de necessidade de preservação das mesmas, temos um cenário mais difícil. Depois da definição do
cliente de qual dado é relevante e deve ser preservado, ele pode precisar trabalhar em conjunto com o provedor
para determinar maneiras adequadas para que a preservação ocorra.
3.3.5 Coleta
Devido à potencial falta de administração e controle do cliente sobre seus dados na computação em nuvem, a
coleta dos mesmos pode tornar-se mais difícil, mais demorada e complexa se comparada com a que ocorre em
seu ambiente computacional local. Por exemplo, um cliente pode não ter o mesmo nível de visibilidade dos dados
no ambiente de computação em nuvem e, portanto, não conseguir determinar com exatidão se um processo de
exportação ocorreu com sucesso e de forma correta.
3.3.5.1 Acesso e Banda
Na maioria dos casos o acesso de um cliente aos seus dados é determinado por seu SLA. Isso pode limitar a coleta
de grandes volumes de dados de forma rápida e de maneira a respeitar as características forenses dos dados.
Clientes e provedores devem considerar esse cenário e estabelecer protocolos e custos associados para acesso
sem tais limitações em caso de necessidade imposta por investigações ou litígios, permitindo a coleta dos dados.
Caso esse acordo não seja possível, os clientes devem estar cientes do tempo e custo adicional relacionado à
tarefa de coleta de dados nesta situação.
3.3.5.2 Funcionalidade
Está relacionado a acesso e banda, mas é diferente. O direito de acesso de um cliente pode proporcionar que ele
acesse todos os seus dados mas, ainda assim, não prover recursos funcionais que vão auxiliá-lo em uma dada
situação. Como exemplo, um cliente pode ter acesso a 3 anos de dados relativos a vendas mas possuir limitação
de download de dados em intervalos de duas semanas apenas devido a limitações funcionais. O cliente pode
ainda não possuir visibilidade sobre os metadados existentes, mas apenas uma parcela limitada dos mesmos.
3.3.5.3 Análise Forense
Uma imagem “bit a bit” de dados oriundos de computação em nuvem é difícil ou impossível. Por razões de
segurança, provedores são relutantes em prover acesso aos seus equipamentos físicos, particularmente em
ambientes compartilhados onde um cliente poderia obter acesso a dados de outros clientes. Mesmo em um
ambiente de computação em nuvem privado, a análise forense pode ser extremamente difícil e clientes podem
precisar notificar cortes dessa limitação. Felizmente, a análise forense é raramente solicitada em computação em
nuvem, não pelo fato de ser computação em nuvem mas pelo fato de ser geralmente composta de uma estrutura
de dados hierárquica ou virtualização que não se presta à análise forense.

3.3.5.4 Integridade razoável
Um cliente requisitado a fornecer mapeamento de informações deve, de forma razoável, realizar procedimentos
que garantam que a coleta de informações ocorra de forma completa e correta, especialmente onde
procedimentos comuns para obtenção da informação não estão disponíveis, restando apenas as medidas
específicas de litígio para tanto. Este passo é uma parte separada do processo de verificação de que os dados em
computação em nuvem são guardados de forma correta, autêntica e admissível.
3.3.5.5 Dados não acessíveis
Devido a diferenças em como os dados do cliente são armazenados e os privilégios e direitos de acesso do cliente
aos dados, nem todo o dado do cliente pode ser considerado igualmente acessível. O cliente e o provedor devem
analisar as requisições por informação e a pertinente estrutura de dados para relevância, materialidade,
proporcionalidade e acessibilidade.
3.3.6 Acesso Direto
Fora do ambiente da nuvem, o acesso direto de uma parte requerente ao ambiente de TI de uma parte acusada
não é favorecido. Em ambientes de computação em nuvem, essa solicitação de acesso direto é ainda menos
favorecido e pode vir a ser impossível pelas mesmas razões relatadas em questões forenses. Um cliente pode não
ter a capacidade de conceder um acesso direto requisitado porque as instalações e hardwares envolvidos estão
fora de sua posse, custódia ou controle e, o solicitante pode vir a precisar negociar diretamente com o provedor
mediante posse de uma intimação judicial.
3.3.7 Produção Proprietária
Provedores de serviço em computação em nuvem frequentemente guardam dados em sistemas e aplicações

proprietárias, os quais os clientes não controlam. Produção de dados nesse formato nativo podem ser inúteis
para partes requisitantes pois não serão capazes de interpretar as informações. Nestas circunstâncias, pode ser
benéfico a todos que o processo de exportação de informação utilize formatos padronizados abertos existentes.
3.3.8 Autenticação
Autenticação nesse contexto refere-se à habilidade forense de autenticar que os dados são admissíveis como
evidência. Não deve ser confundido com autenticação de usuário em processos de gerência de identidade.
Armazenar dados na computação em nuvem não afeta a capacidade de análise de autenticação dos dados para
admissão como evidência. A questão é se o documento é o que deveria ser. Um e-mail não é mais ou menos
autêntico por que foi armazenado localmente ou em ambiente de computação em nuvem. A questão é se foi ou
não armazenado de forma íntegra e a corte pode confiar que não foi alterado desde o momento em que foi
enviado ou recebido.
3.3.9 Admissibilidade e Credibilidade
Exceto outra evidência, tal como falsificações ou adulterações, documentos não devem ser considerados mais ou
menos admissíveis ou terem mais ou menos credibilidade somente por terem sido criados ou armazenados em
ambientes de computação em nuvem.

3.3.10 Cooperação entre cliente e provedor em processos de mapeamento de informações (e-

Discovery)
É do interesse tanto do cliente quanto do provedor considerar possíveis complicações causadas por processos de
mapeamento de informações (e-discovery) desde o início de seu relacionamento comercial e determinação de
SLA. Provedores podem considerar a criação de serviços específicos para esse fim para atrair clientes. Em todo
caso, clientes e provedores devem considerar cláusulas de cooperação em acordos e contratos firmados
prevendo situações em que solicitações de mapeamento de informações ocorram tanto para um quanto para
outro.
3.3.11 Resposta a mandatos de busca e intimações
Um provedor de serviços poderá receber de terceiros solicitações de informações na forma de intimações ou

mandatos de busca nos quais acesso aos dados de clientes são solicitados. O cliente, por sua vez, pode querer
exercer seu direito de contestação mantendo a privacidade, confidencialidade ou segredo de seus dados. Para
isso, acordos e contratos devem possuir cláusulas requerendo que o provedor notifique o cliente do recebimento
de tais solicitações judiciais dando-lhe tempo para resposta.
O provedor de serviços de computação em nuvem pode tender a responder prontamente a tais solicitações
abrindo suas instalações para verificações e entregando todas as informações relativas à solicitação. Antes de
fazê-lo, no entanto, o provedor deve assegurar-se de que a solicitação é verdadeira e foi obtida legalmente,
analisando a requisição atentamente antes de disponibilizar informações sob sua custódia.
Leis complexas são aplicáveis dependendo da origem e natureza da informação, sua localização etc. Por exemplo,
diferentes regras aplicam-se a requisições de acesso a conteúdo de e-mail, dependendo se o e-mail foi ou não
aberto e quanto tempo encontra-se armazenado. Diferentes regras são aplicáveis caso a informação requerida for
o conteúdo do e-mail ou apenas informações transacionais como data de envio, destinatário, etc.

REFERÊNCIAS
Tratados e acordos internacionais
[1] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (1980).
[2] OECD Guidelines for the Security of Information Systems and Networks (2002).
[3] OECD Recommendation on Cross-border Cooperation in the Enforcement of Laws Protecting Privacy.
Publicações
[4] GILBERT, Francoise. © 2009-2011. Global Privacy & Security. Aspen Publishing / Wolters Kluwer (2 volumes).
[5] GILBERT, Francoise. 2011. Cloud Service Providers Can Be Both Data Processors and Data Controllers (BNA
Privacy & Security Law Report 10 PVLR 266 (2011). Journal of Internet Law, Volume 15, Number 2, page 3.
[6] POWER, Michael E. AND TROPE, Roland L. 2005. Sailing in Dangerous Waters: A Director’s Guide to Data
Governance. American Bar Association.
[7] SMEDINGHOFF, Thomas. 2008 Information Security Law: Emerging Standard for Corporate Compliance (ITGP).
Sites na Internet
[8] Modelos de negócio e definições de computação em nuvem:

http://p2pfoundation.net/Cloud_ComputingDefinition (aspectos técnicos, modelos de negócio)
[9] Base de dados de incidentes em Cloud Computing

http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database (Registros e monitoramentos
verificáveis, eventos relevantes que impactam provedores de computação em nuvem, como interrupções,
incidentes de segurança e invasões)

DOMÍNIO 4 //
GERENCIAMENTO DE CONFORMIDADE E AUDITORIA
As organizações enfrentam novos desafios à medida que migram de centros de dados tradicionais para a nuvem.
Um dos maiores desafios é entregar, medir e comunicar a conformidade com uma infinidade de regulamentações
em várias jurisdições. Os clientes e provedores precisam entender de forma semelhante e reconhecer as
diferenças e as implicações sobre os padrões existentes de conformidade e auditoria, de processos e de práticas.
A natureza distribuída e virtual da nuvem requer um importante ajuste estrutural das abordagens baseadas em
instâncias concretas e físicas das informações e dos processos.
A nuvem tem o potencial de melhorar a transparência e a segurança, através de suas plataformas de

gerenciamento mais centralizadas e consolidadas. Além disso, as soluções terceirizadas dos provedores de nuvem
reduzem gradualmente a dependência de conformidade. Com provedores aptos a entregar soluções de
conformidade desde o início, as novas organizações (com e sem fins lucrativos) poderiam ingressar nos mercados
e tomar medidas que, em uma época pré-nuvem, tinham um custo proibitivo. Os governos e outras organizações
anteriormente relutantes em terceirizar as operações de TI, devido a questões de segurança e de conformidade,
podem estar mais dispostos a adotar um modelo de nuvem, onde a conformidade pode ser parcialmente
resolvida mediante a delegação contratual.
Além dos provedores e clientes, os reguladores e auditores também estão se adaptando ao novo mundo da
computação em nuvem. As poucas regulamentações existentes foram escritas para explicar ambientes virtuais ou
implantações em nuvem. Um consumidor em nuvem pode ser desafiado a mostrar aos auditores que a
organização está em conformidade. Entender a interação da computação em nuvem e o ambiente regulatório é
um componente chave de qualquer estratégia em nuvem. Os clientes em nuvem devem considerar e
compreender o seguinte:
 As implicações regulatórias para utilizar um determinado serviço em nuvem ou provedores, dando

especial atenção a eventuais problemas fronteiriços ou de múltiplas jurisdições, quando aplicável
 A atribuição de responsabilidades de conformidade entre o provedor e o cliente, incluindo os provedores
indiretos (ou seja, o provedor de nuvem de seu provedor de nuvem)
 Os recursos do provedor para demonstrar em tempo hábil a conformidade, incluindo a geração de
documentos, produção de comprovantes e conformidade dos processos
 As relações entre os clientes, os prestadores e os auditores (tanto do cliente como do provedor) para
garantir o necessário (e apropriadamente restrito) acesso e o alinhamento com os requisitos de
governança
Visão geral. Este domínio tratará dos seguintes tópicos:
 Conformidade
 Auditoria

4.1 Conformidade
Figura 1 - Ecossistema de valores de GRC
 Governança corporativa: o equilíbrio do controle entre as partes interessadas, diretores e gerentes de

uma organização em fornecer gerenciamento consistente, aplicação coesa de políticas, orientações e
controles, possibilitando uma eficaz tomada de decisão
 Gerenciamento de risco empresarial: métodos e processos (framework) utilizados pelas organizações

para equilibrar a tomada de decisões, baseada na identificação de determinados eventos ou
circunstâncias relevantes para os objetivos da organização (riscos e oportunidades), avaliando-os em
termos de probabilidade e magnitude do impacto, determinando uma estratégia de resposta e,
monitorando o progresso para proteger e criar valor para suas partes interessadas
 Garantia de conformidade e auditoria: conscientização e adesão às obrigações empresariais (por

exemplo, responsabilidade social corporativa, ética, legislações aplicáveis, regulamentações, contratos,
estratégias e políticas), pela avaliação do grau de conformidade, dos riscos e custos potenciais de não
conformidade comparados aos custos para alcançar a conformidade e, portanto, priorizar, provisionar e
iniciar as ações corretivas consideradas necessárias
A tecnologia da informação em nuvem está cada vez mais sujeita a uma infinidade de políticas e
regulamentações. Todas as partes interessadas esperam que as organizações atendam proativamente as
diretrizes e requisitos regulatórios nas várias jurisdições. A governança de TI é uma necessidade para entregar
estes requisitos e todas as organizações precisam de uma estratégia para entregar.
A governança inclui os processos e políticas que possibilitam a boa execução dos objetivos organizacionais dentro
das limitações do ambiente externo. A governança requer atividades de conformidade para garantir que as
operações estejam totalmente alinhadas com os processos e políticas. Neste sentido, enquanto a conformidade
concentra-se no alinhamento com os requisitos externos (por exemplo, leis, regulamentações, normas setoriais),

a governança concentra-se no alinhamento com os requisitos internos (por exemplo, decisões do conselho,
política corporativa).
A conformidade pode ser definida como a consciência e a adesão às obrigações (por exemplo, responsabilidade
social corporativa, legislação, diretrizes éticas), incluindo a avaliação e priorização de ações corretivas
consideradas necessárias e adequadas. Em alguns ambientes, especialmente aqueles altamente regulamentados,
o aspecto da transparência pode até ser dominante, com requisitos de informação cada vez mais evidentes que a
própria conformidade. Na melhor das situações, a adesão não é um inibidor da eficácia organizacional, mas um
complemento às políticas determinadas internamente.
As regulamentações normalmente têm fortes implicações para a tecnologia da informação e para a sua
governança, especialmente em termos de monitoramento, gerenciamento, proteção e divulgação. A governança
de TI é um elemento de apoio da governança global corporativa, da gestão de riscos corporativos, da
conformidade e da auditoria/garantia.
A nuvem pode ser uma tecnologia capacitadora para governança e conformidade, centralizando o controle e a
transparência através das suas plataformas de gerenciamento, especialmente para nuvem interna de
gerenciamento. Ao alavancar os serviços em nuvem, as organizações de menor dimensão podem atingir o mesmo
nível de conformidade que entidades com recursos extremos e muito maiores. Os serviços de segurança e de
garantia são uma maneira de terceiros poderem desempenhar seu papel na avaliação da conformidade e da
comunicação.
Qualquer abordagem de conformidade deverá incluir a participação de toda a organização, incluindo a TI. O papel
dos provedores externos precisa ser cuidadosamente considerado e, a responsabilidade de incluí-los na
governança, direta ou indiretamente, deve ser atribuída explicitamente dentro da organização do cliente.
Adicionalmente, apresentamos a seguir uma série de normas de segurança em nuvem que estão em
desenvolvimento dentro da ISO/IEC e da ITU-T:
 ISO/IEC 27017: Segurança da Computação em Nuvem e Controles de Gerenciamento da Privacidade do

Sistema de Segurança (do inglês Cloud Computing Security and Privacy Management System-Security
Controls)
 ISO/IEC 27036-x: Padrão com múltiplas partes para a segurança da informação de gestão de
relacionamento com fornecedores que está planejada para incluir uma parte relevante à cadeia de
fornecimento de nuvem
 ITU-T X.ccsec: Diretrizes de segurança para a computação em nuvem na área de telecomunicações
 ITU-T X.srfcts: Os requisitos de segurança e framework do ambiente de serviço de telecomunicações

baseados em nuvem (X.srfcts)
 ITU-T X.sfcse: Requisitos funcionais de segurança do ambiente de aplicação para o Software como um
Serviço (SaaS)
4.2 Auditoria
Uma governança organizacional adequada inclui naturalmente auditoria e gartantia. A auditoria deve ser
conduzida de forma independente e vistosamente elaborada para refletir a melhor prática, os recursos
apropriados e os protocolos e padrões testados.

Tanto os controles como as auditorias interna e externa têm um papel legítimo a desempenhar na nuvem, seja
para o cliente ou para o provedor. Uma maior transparência pode ser melhor durante as fases iniciais de
introdução na nuvem para aumentar os níveis de conforto das partes interessadas. Uma auditoria é um método
para garantir que as atividades de gerenciamento de risco operacional sejam exaustivamente testadas e
revisadas.
Um plano de auditoria deverá ser adotado e apoiado pelos mais altos elementos de governança da organização
(por exemplo, o conselho de administração e gerenciamento). Auditorias regulares e independentes dos controles
e dos sistemas críticos, incluindo o acompanhamento do rastreamento da auditoria (do inglês audit trail) e da
documentação, apoiarão melhorias na eficiência e na confiabilidade.
Muitas organizações utilizam um modelo de maturidade em capacitação (por exemplo, do inglês o Capability
Maturity Model - CMM ou o Path To Quality Model - PTQM) como framework para analisar a eficiência do
processo. Em alguns casos, é adotada uma abordagem mais estatística para a gestão de riscos (por exemplo, os
acordos da Basileia e de Solvência relativos aos serviços financeiros) e, à medida que o campo amadurece com
modelos mais especializados para o risco, pode ser adotado como adequado para a função ou ramo de negócio.
Essas práticas terão de ser revistas e melhoradas para a nuvem. Assim como acontece com os modelos anteriores
de tecnologia da informação, a auditoria terá que aproveitar o potencial da nuvem e, também aumentar o escopo
e a dimensão para gerenciar seus aspectos inovadores.
4.3 Recomendações
Quando for contratar um provedor, envolva o departamento jurídico dentro da organização do cliente para
elaborar adequadamente o contrato. As condições gerais de serviços podem não atender às necessidades de
conformidade e terão que ser negociadas.
Quando se usa um serviço em nuvem, devem ser considerados os requisitos de conformidade especializados para
os setores altamente regulamentados (por exemplo, financeiro, de saúde). As organizações que compreendem os
seus atuais requisitos devem considerar o impacto de um modelo de TI distribuído, incluindo o impacto de
provedores de nuvem que operam em diversas localizações geográficas e diferentes jurisdições legais.
Determine como os requisitos de conformidade existentes serão impactados pelo uso dos serviços em nuvem,
para cada carga de trabalho (ou seja, conjunto de aplicações e dados), em especial no que diz respeito à
segurança da informação. Como acontece com qualquer solução terceirizada, as organizações precisam entender
que os seus parceiros de nuvem são e devem estar processando informações regulamentadas. Incluem-se como
exemplos de políticas e procedimentos afetados os relatórios de atividades, o registro de retenção de dados, a
resposta a incidentes, os controles de testes e as políticas de privacidade.
Entenda as responsabilidades contratuais de cada parte. As expectativas iniciais variam conforme o modelo de
implantação, com o cliente tendo mais controle e responsabilidade em um modelo de IaaS e, o provedor tendo o
papel dominante nas soluções de SaaS. É particularmente importante ter entrelaçados os requisitos e as
obrigações - não apenas do cliente para o seu provedor de nuvem direto, mas entre o cliente final e o provedor
de nuvem do provedor.
A conformidade com a legislação e com a regulamentação do setor e seus requisitos (sejam legais, técnicos,
jurídicos, de conformidade, de risco ou de segurança) é fundamental e deve ser abordada durante a fase de
identificação dos requisitos. Qualquer informação processada, transmitida, armazenada ou visualizada que é

identificada como Informação Pessoal Identificável (do inglês Personal Identifiable Information - PII)22 ou
informação particular, enfrenta uma infinidade de regulamentações de conformidade no mundo todo, que
podem variar conforme o país ou o estado. Uma vez que a nuvem é projetada para ser geograficamente diversa e
dimensionável, os dados da solução podem ser armazenados, processados, transmitidos ou recuperados a partir
de vários locais ou de múltiplos centros de dados do Provedor de Serviço em Nuvem (do inglês Cloud Service
Provider - CSP). Alguns requisitos regulatórios especificam controles que são difíceis ou impossíveis de atingir em
certos tipos de serviços em nuvem (por exemplo, os requisitos geográficos podem ser inconsistentes com a
distribuição do armazenamento). Os clientes e os provedores devem concordar como coletar, armazenar e
compartilhar evidências de conformidade (ou seja, os registros de auditoria, os relatórios de atividades e as
configurações do sistema).
o Prefira auditores que são "cientes em nuvem" que estarão familiarizados com os desafios de garantia (e
vantagens) de virtualização e nuvem.
o Requisite o relatório SSAE 16 SOC2 ou o ISAE 3402 Tipo 2 do provedor de nuvem. Ele fornecerá um ponto
de partida de referência identificável para os auditores e avaliadores.
o Os contratos devem prever a revisão das métricas do SLA e de conformidade por terceiros (por exemplo,
por um mediador mutuamente selecionado).
4.3 Requisitos
 Uma cláusula de direito de auditar possibilita aos clientes auditarem o provedor de nuvem e, suporta o
rastreamento e a transparência nos ambientes que frequentemente envolvem a computação em nuvem e
a regulamentação. Utilize uma especificação normativa no direito de auditar, para garantir o mútuo
entendimento das expectativas. Com o tempo, esse direito deve ser suplantado por certificações de
terceiros (por exemplo, regido pela ISO/IEC 27001/27017).
 Uma cláusula de direito de transparência com direitos específicos de acesso pode oferecer as informações
necessárias aos clientes em setores altamente regulamentados (incluindo aqueles em que a não
conformidade pode ser motivo para uma ação penal). O acordo deve distinguir o acesso à informação
entre automatizado/direto (por exemplo, registros, relatórios) e informação "requisitada" (por exemplo,
arquiteturas de sistemas, relatórios de auditoria).
 Os provedores devem revisar, atualizar e publicar regularmente (ou, quando for preciso) seus documentos
de segurança da informação e processos de GRC. Estes devem incluir a análise da vulnerabilidade e, as
decisões e as atividades de remediação relacionadas.
 Os auditores de terceiros devem ser mutuamente revelados ou selecionados com antecedência, em

conjunto pelo provedor e pelo cliente.
 Todas as partes devem concordar em utilizar um framework de garantia de certificação comum (por
exemplo, conforme a ISO, COBIT) para que a TI controle a governança e a segurança.
22
PII - Informação pessoal identificável

DOMÍNIO 5 //
GERENCIAMENTO DA INFORMAÇÃO E SEGURANÇA DE DADOS
O principal objetivo da segurança da informação é proteger os dados fundamentais que alimentam os nossos
sistemas e aplicações. À medida que as empresas migram para a computação em nuvem, os métodos tradicionais
de segurança de dados são confrontados por arquiteturas baseadas em nuvem. A elasticidade, o multilocatário,
as novas arquiteturas físicas e lógicas e os controles abstraídos exigem novas estratégias de segurança de dados.
Em muitas implantações em nuvem, os usuários mesmo transferem dados para ambientes externos, ou mesmo
públicos de forma que há poucos anos seriam inimagináveis.
A gestão da informação na era da computação em nuvem é um grande desafio que afeta todas as organizações;
mesmo aqueles que aparentemente não estão ativamente engajados em projetos baseados em nuvem. Ela
começa com o gerenciamento dos dados em nuvem e com as migrações internas e, estende-se para proteger as
informações em aplicações e serviços dispersos entre as organizações. O gerenciamento da informação e a
segurança de dados na era da nuvem demandam tanto novas estratégias como arquiteturas técnicas. Felizmente,
não só os usuários têm as ferramentas e técnicas necessárias, como também a transição em nuvem ainda cria
oportunidades para proteger melhor os dados em nossa infraestrutura tradicional.
Os autores recomendam utilizar um Ciclo de Vida de Segurança de Dados (do inglês Data Security Lifecycle) que
segue abaixo em detalhes, para avaliar e definir a estratégia de segurança de dados em nuvem. Ele deve ser
acomodado com políticas claras de governança de informações e aplicadas com as tecnologias chave, tais como a
criptografia e as ferramentas especializadas de monitoramento.
Visão geral. Este domínio é composto de três seções:
 A 1ª seção fornece os elementos de referência de arquiteturas de informação em nuvem

(armazenamento).
 A 2ª seção inclui as melhores práticas para o gerenciamento da informação, inclusive o Ciclo de Vida de
Segurança de Dados.
 A 3ª seção detalha os controles específicos de segurança de dados e quando utilizá-los.
5.1 Arquiteturas de Informação em Nuvem
As arquiteturas de informação em nuvem são tão diversas quanto as próprias arquiteturas em nuvem. Embora
esta seção não possa abranger todas as transições possíveis, existem certas arquiteturas consistentes dentro da
maioria dos serviços em nuvem.
5.1.1 Infraestrutura como um Serviço
Na nuvem pública ou privada, a IaaS geralmente inclui as seguintes opções de armazenamento:

 Armazenamento bruto. Inclui o meio físico onde o dado é armazenado. Pode ser mapeado por acesso
direto em certas configurações de nuvem privada.
 Armazenamento de volumes. Inclui volumes anexados a instâncias de IaaS, tipicamente como um disco
rígido virtual. Volumes costumam usar a dispersão de dados para apoiar a resiliência e a segurança.
 Armazenamento de objetos. O armazenamento de objetos às vezes se refere ao armazenamento de

arquivos. Em lugar de um disco rígido virtual, o armazenamento de objetos é mais como um
compartilhamento de arquivos acessados via interface de programação de aplicações (APIs)23 ou interface
da Web.
 Rede de entrega de conteúdo. O conteúdo é acondicionado no armazenamento de objeto, que é então

distribuído para múltiplos nós geograficamente distribuídos para melhorar as velocidades de consumo da
Internet.
5.1.2 Plataforma como um Serviço
A PaaS tanto supre como conta com uma vasta gama de opções de armazenamento.
A PaaS pode suprir:
 Banco de Dados como um Serviço (Database as a Service). Uma arquitetura de banco de dados
multilocatário que é diretamente consumível como um serviço. Dependendo da proposta, os usuários
consomem o banco de dados através de APIs ou diretamente nas chamadas Linguagens de Consulta
Estruturada SQL24. Os dados de cada cliente são segregados e isolados dos outros locatários. Os bancos de
dados podem ser relacionais, planos, ou com qualquer outra estrutura comum.
 Hadoop/MapReduce/Big Data as a Service. Big Data é um dado cuja larga escala, a ampla distribuição, a
heterogeneidade e a predominância/oportunidade requerem o uso de novas arquiteturas técnicas e
analíticas. O Hadoop e demais aplicações Big Data podem ser ofertados como uma plataforma em nuvem.
Os dados são normalmente acondicionados no armazenamento de objetos ou em outro sistema de
arquivos distribuídos. Normalmente os dados precisam estar perto do ambiente de processamento e
podem, se necessário, ser temporariamente movidos para processamento.
 Armazenamento de aplicação. O armazenamento de aplicações inclui todas as opções de

armazenamento construídas em uma plataforma de aplicações PaaS e consumível via APIs, que não se
enquadram em outras categorias de armazenamento.
A PaaS pode consumir:
 Banco de dados. As informações e o conteúdo podem ser armazenados diretamente no banco de dados
(como texto ou objetos binários) ou como arquivos referenciados pelo banco de dados. O banco de dados
em si pode ser uma coleção de instâncias de IaaS que compartilham o armazenamento comum de
retaguarda (do inglês back-end).
 Armazenamento de objetos/arquivos. Os arquivos e os dados são acondicionados no armazenamento de

objetos, mas somente acessados através da API da PaaS.
23
API - Interface de programação de aplicativo
24
SQL - Linguagem de consulta estrutural que é a linguagem de programação projetada para gerenciar dados

 Armazenamento de volumes. Os dados podem ser armazenados em volumes da IaaS anexados às

instâncias dedicadas para fornecer o serviço de PaaS.
 Outros. Estes são os modelos de armazenamento mais comuns, mas esta é uma área dinâmica e, outras
opções podem estar disponíveis.
5.1.3 Software como um Serviço
Assim como a PaaS, o SaaS utiliza uma gama muito ampla de modelos de armazenamento e de consumo. O
armazenamento do SaaS é sempre acessado através de uma interface de usuário baseada na web ou de uma
aplicação cliente/servidor. Se o armazenamento é acessível via API, então, ele é considerado uma PaaS. Muitos
provedores de SaaS também oferecem estas APIs de PaaS.
O SaaS pode suprir:
 Armazenamento e gerenciamento da informação. Os dados são inseridos no sistema por meio da

interface da Web e armazenados dentro da aplicação do SaaS (geralmente, um banco de dados de
retaguarda (back-end)). Alguns serviços de SaaS oferecem opções de carga (upload) de conjuntos de
dados ou APIs de PaaS.
 Armazenamento de conteúdo/arquivos. O conteúdo baseado em arquivos é armazenado dentro da

aplicação do SaaS (por exemplo, relatórios, arquivos de imagem, documentos) e acessível através da
interface do usuário baseada na Web.
O SaaS pode consumir:
 Banco de dados. Como a PaaS, um grande número de serviços de SaaS conta com banco de dados de
retaguarda (back-ends), mesmo para armazenamento de arquivos.
 Armazenamento de objetos/arquivos. Os arquivos ou os demais dados são acondicionados no

armazenamento de objetos, mas somente acessados através da aplicação do SaaS.
 Armazenamento de volumes. Os dados podem ser armazenados em volumes da IaaS anexados às

instâncias dedicadas para fornecer o serviço de SaaS.
5.2 Dispersão de dados (informações)
A dispersão de dados (informações) é uma técnica que é comumente utilizada para melhorar a segurança dos
dados mas, sem a utilização de mecanismos de criptografia. Esses tipos de algoritmos de detecção de intrusão
(abreviadamente em inglês IDA25) são capazes de suprir alta disponibilidade e garantia para os dados
armazenados na nuvem por meio de fragmentação de dados e, são comuns em muitas plataformas em nuvem.
Em um esquema de fragmentação, um arquivo f é dividido em n fragmentos; todos estes são assinados e
distribuídos para n servidores remotos. O usuário pode então reconstruir f ao acessar arbitrariamente m
fragmentos escolhidos. O mecanismo de fragmentação também pode ser utilizado para armazenar dados de
longa duração na nuvem com alta garantia.
25
IDA - Algoritmo de detecção de intrusão

A segurança de dados é reforçada quando a fragmentação é utilizada em conjunto com a criptografia: um

adversário tem que comprometer os m nós da nuvem, para recuperar os m fragmentos do arquivo f e, depois,
quebrar o mecanismo de criptografia que está sendo utilizado.
5.3 Gerenciamento da Informação
Antes de podermos discutir os controles específicos de segurança de dados, precisamos de um modelo para
compreender e gerir a nossa informação. O gerenciamento da informação inclui os processos e políticas tanto
para a compreensão de como as suas informações são utilizadas, como o que rege essa utilização. Na seção de
segurança de dados, são discutidos os controles e as recomendações técnicas específicas para monitorar e fazer
cumprir esta governança.
5.4 O Ciclo de Vida da Segurança de Dados
Embora o Gerenciamento do Ciclo de Vida da Informação (do inglês Information Lifecycle Management) seja um
campo bastante maduro, ele não mapeia bem as necessidades dos profissionais de segurança. O ciclo de vida da
segurança de dados é diferente do gerenciamento do ciclo de vida da informação, refletindo as diferentes
necessidades de segurança do público. Isto é um resumo do ciclo de vida. Uma versão completa está disponível
no site http://www.securosis.com/blog/data-security-lifecycle-2.0
O ciclo de vida é constituído por seis fases, desde a criação até a destruição. Embora se mostre como uma
progressão linear, uma vez criados, os dados podem saltar entre as fases sem restrições e, podem não passar por
todas as fases (por exemplo, nem todos os dados são eventualmente destruídos).
1. Criar. A criação é a geração de novos conteúdos

digitais ou, a alteração/atualização/modificação
do conteúdo existente.
2. Armazenar. O armazenamento é o ato de

alocar os dados digitais para algum tipo de
repositório de armazenamento e normalmente
ocorre quase que simultaneamente com a
criação.
3. Utilizar. Os dados são visualizados, processados

ou utilizados em algum tipo de atividade, não
incluindo a modificação.
4. Compartilhar. A informação é disponibilizada

entre usuários, clientes ou parceiros. Figura 1 - Ciclo de Vida dos Dados
5. Arquivar. Os dados deixam o armazenamento de uso ativo e são inseridos no armazenamento de longo
prazo.
6. Destruir. Os dados são permanentemente destruídos através de meios físicos ou digitais (por exemplo, a
fragmentação criptográfica, do inglês crypto-shredding).

5.4.1 Localização e acesso
O ciclo de vida representa as fases pelas quais a informação passa, mas não trata da sua localização ou como ela é
acessada.
Localização
Isto pode ser ilustrado ao pensar no ciclo de

vida não como uma única operação linear,
mas como uma série de ciclos de vida
menores funcionando em diferentes
ambientes operacionais. Em quase todas as
fases, os dados podem ser movidos para, a
partir de e, entre estes ambientes.
Devido a todos os problemas em potencial

de competências regulatórias, contratuais e
outras, é extremamente importante
compreender os locais lógicos e físicos dos
dados.
Acesso
Quando os usuários sabem onde os dados Figura 2 - Dispositivos de acesso à nuvem

residem e como se movem, eles precisam
saber quem os está acessando e como. Há dois fatores aqui:
1. Quem acessa os dados?
2. Como eles podem acessá-los (dispositivo e canal)?
Atualmente, os dados são acessados através de uma variedade de dispositivos diferentes. Estes dispositivos têm
diferentes características de segurança e podem utilizar diferentes aplicações ou clientes.
5.4.2 Funções, atores e controles
O passo seguinte identifica as funções que podem

ser executadas com os dados, por um dado agente
(pessoa ou do sistema) e em uma determinada
localização.
Funções
Há três coisas que podemos fazer com um

determinado dado:
 Acessar. Visualizar/acessar os dados,

incluindo a criação, cópia, transferência de
arquivos, difusão e outras trocas de
informações.
Figura 3 - Funções versus Controles

 Processar. Realizar uma transação no dado: atualizá-lo; usá-lo em uma transação de processamento de
negócios, etc.
 Armazenar. Manter os dados (em um arquivo, banco de dados, etc.).
A tabela abaixo mostra quais funções mapeiam quais fases do ciclo de vida:
Tabela 1 - Fases do Ciclo de Vida da Informação
Criar Armazenar Utilizar Compartilhar Arquivar Destruir

Acessar X X X X X X
Processar X X
Armazenar X X
Um ator (pessoa, aplicação ou sistema/processo, ao contrário do dispositivo de acesso) executa cada função em
uma localização.
Controles
Um controle restringe uma lista de ações possíveis para ações permitidas. A tabela abaixo mostra uma maneira de
listar as possibilidades que, depois, o usuário mapeia para os controles.
Tabela 2 - Controles Possíveis e Permitidos
Função Ator Local

Possível Permitido Possível Permitido Possível Permitido
5.5 Governança da Informação
A governança da informação inclui as políticas e procedimentos para gerenciar do uso da informação. Ela inclui as
seguintes características principais:
 Classificação da informação. Descrições de alto nível de importantes categorias de informação. Ao

contrário da classificação de dados, o objetivo é não rotular cada parte dos dados na organização, mas
sim definir as categorias de alto nível como "regulamentadas" e de "sigilo comercial" para determinar em
quais aplicar os controles de segurança.
 Políticas de gerenciamento da informação As políticas para definir quais atividades são permitidas para
os diferentes tipos de informações.
 Políticas de localização e jurisdição. Onde os dados podem ser localizados geograficamente que tem
também importantes implicações legais e regulatórias.
 Autorizações. Definir quais os tipos de funcionários/usuários têm permissão para acessar determinados
tipos de informações.
 Propriedade. Quem é o responsável final pela informação.

 Tutela. Quem, atestado pelo proprietário, é responsável pela gestão da informação.
5.6 Segurança de Dados
A segurança de dados compreende os controles e tecnologias específicas utilizadas para reforçar a governança da
informação. Ela foi dividida em três seções que abrangem a detecção (e prevenção) da migração dos dados para a
nuvem, a proteção dos dados em trânsito para a nuvem e entre os diferentes provedores/ambientes e, a
proteção dos dados quando já estiverem dentro da nuvem.
5.6.1 Detecção e prevenção da migração dos dados para a nuvem
Gerenciar dados é um desafio comum que as organizações enfrentam com a nuvem. Muitas organizações relatam
que as pessoas ou as unidades de negócios normalmente movem dados confidenciais para os serviços em nuvem
sem a autorização ou mesmo a notificação à TI ou à segurança.
Além de controles tradicionais de segurança de dados (como os controles de acesso ou a criptografia), existem
duas outras etapas para evitar que dados não autorizados sejam movidos para os serviços em nuvem:
1. O monitoramento para grandes migrações de dados internos com o Monitoramento da Atividade do

Banco de Dados (do inglês Database Activity Monitoring - DAM26) e o Monitoramento da Atividade de
Arquivo (do inglês File Activity Monitoring - FAM27)
2. O monitoramento para mover dados para a nuvem com filtros de URL e prevenção de perda de dados (do
inglês Data Loss Prevention - DLP).
Migrações de dados internos
Antes que os dados possam ser movidos para a nuvem é preciso que eles sejam retirados de seu repositório
existente. O Monitoramento da Atividade do Banco de Dados pode detectar quando um administrador ou algum
usuário extrai um grande conjunto de dados ou replica um banco de dados, o que poderia indicar uma migração.
O Monitoramento da Atividade de Arquivo fornece proteção similar para repositórios de arquivos, como
compartilhamentos de arquivos.
Movimento para a nuvem
Uma combinação de filtragem de URL (gateways de segurança de conteúdo da Web) e de Prevenção de Perda de
Dados (DLP) pode detectar o deslocamento de dados da empresa para a nuvem.
A filtragem de URL permite que você monitore (e previna) os usuários que se conectam aos serviços em nuvem.
Uma vez que as interfaces administrativas para esses serviços normalmente utilizam endereços diferentes do lado
do consumo, o usuário pode distinguir entre alguém que acessa um console administrativo versus um usuário que
acessa uma aplicação já hospedada com o provedor.
Procure uma ferramenta que ofereça uma lista de serviços em nuvem e se mantenha atualizada, ao contrário de
uma que requeira criar uma categoria personalizada e que o usuário tenha que gerenciar os endereços de
destino.
26
DAM - Monitoramento da Atividade do Banco de Dados (Database Activity Monitoring)
27
FAM - Monitoramento da Atividade de Arquivo (File Activity Monitoring)

Para maior especificidade, utilize a Prevenção de Perda de Dados. As ferramentas de DLP focam nos
dados/conteúdo real que estão sendo transmitidos e não apenas no destino. Assim, o usuário pode gerar alertas
(ou bloqueios) baseados na classificação dos dados. Por exemplo, o usuário pode permitir que dados corporativos
privados sejam movidos para um serviço em nuvem autorizado, mas bloquear a migração do mesmo conteúdo
para um serviço não autorizado.
O ponto de inserção da solução de DLP pode determinar com que êxito a perda de dados pode ser detectada. Por
exemplo, a disponibilidade de soluções em nuvem para vários usuários (por exemplo, funcionários, fornecedores,
clientes) fora do ambiente da rede corporativa evita ou anula quaisquer soluções de DLP se eles estão inseridos
no perímetro corporativo.
5.6.2 Proteção dos dados em movimento para (e dentro da) a Nuvem
Tanto nas implantações em nuvem públicas como privadas e, durante todos os diferentes modelos de serviços, é
importante proteger os dados em trânsito. Isso compreende:
 A movimentação dos dados da infraestrutura tradicional para a nuvem, incluindo os provedores

públicos/privados, internos/externos e outras transições.
 A movimentação dos dados entre os provedores de nuvem.
 A movimentação dos dados entre as instâncias (ou de outros componentes) dentro de uma determinada
nuvem.
Há três opções (ou ordem de preferência):
1. Criptografia de Cliente/Aplicação. Os dados são criptografados no terminal ou no servidor antes de

serem enviados pela rede ou já estão armazenadas em um formato criptografado adequado. Isso inclui a
criptografia do cliente local (baseada no agente) (por exemplo, para arquivos armazenados) ou a
criptografia integrada nas aplicações.
2. Criptografia de link/rede. Técnicas de criptografia de rede padrão, incluindo a SSL, VPNs e a SSH. Pode ser
de hardware ou de software. É preferível ser de ponta a ponta, mas isso pode não ser viável em todas as
arquiteturas.
3. Criptografia baseada no Proxy Os dados são transmitidos a um dispositivo ou servidor Proxy, que codifica
antes de encaminhar na rede. É uma opção muitas vezes preferida para integrar em aplicações legadas,
mas geralmente não é recomendada.
5.6.3 Proteção dos dados na nuvem
Com ampla gama de opções e tecnologias disponíveis na computação em nuvem, não há nenhuma maneira de
abranger todas as opções possíveis de segurança. A seguir, estão algumas das tecnologias mais úteis e as
melhores práticas para proteger os dados dentro dos vários modelos de nuvem.
5.6.3.1 Descoberta de conteúdo
A descoberta de conteúdo abrange as ferramentas e processos para identificar as informações confidenciais no

armazenamento. Ele possibilita à organização definir políticas baseadas no tipo de informações, estrutura ou

classificação e, em seguida, verifica os dados armazenados utilizando técnicas avançadas de análise de conteúdo,
para identificar os locais e violações de políticas.
A descoberta de conteúdo é normalmente um recurso das ferramentas de Prevenção de Perda de Dados; para
bancos de dados, às vezes, é disponível em produtos de Monitoramento da Atividade de Banco de Dados. A busca
pode ser via acesso ao compartilhamento de arquivos ou por um agente de execução local em um sistema
operacional. A ferramenta deve ser "preparada para a nuvem" e poder trabalhar dentro do seu ambiente de
nuvem (por exemplo, poder examinar o armazenamento de objetos). A descoberta de conteúdo pode também
estar disponível como um serviço gerenciado.
5.6.3.2 Criptografia da IaaS
5.6.3.2.1 Criptografia de armazenamento de volumes
A criptografia de volumes protege contra os seguintes riscos:
 Protege os volumes de instantâneos de clonagem/exposição
 Protege os volumes de serem explorados pelo provedor de nuvem (e de administradores de nuvem

privada)
 Protege os volumes de serem expostos pela perda física de unidades (mais para a conformidade do que
por uma questão de segurança do mundo real)
Os volumes de IaaS podem ser criptografados utilizando-se três métodos:
 Criptografia gerenciada na instância. O mecanismo de criptografia funciona dentro da instância e a chave

é armazenada no volume mas, protegida por uma senha ou um par de chaves.
 Criptografia gerenciada externamente. O mecanismo de criptografia é executado na instância mas, as

chaves são gerenciadas externamente e emitidas para a instância, sob pedido.
 Criptografia em Proxy. Neste modelo, você conecta o volume a uma instância especial ou
dispositivo/software e, depois, conecta a instância para a instância de criptografia. O Proxy controla todas
as operações de criptografia e pode manter as chaves integradas ou externamente.
5.6.3.2.2 Criptografia de armazenamento de objeto
A criptografia de armazenamento de objeto protege contra muitos dos mesmos riscos que o armazenamento de
volumes. Dado que o armazenamento de objeto é mais exposto com frequência às redes públicas, ele também
possibilita que o usuário implante o Armazenamento Virtual Privado (do inglês Virtual Private Storage). Como
uma VPN, um VPS28 permite a utilização de uma infraestrutura pública compartilhada, ao mesmo tempo em que
protege os dados, já que somente aqueles que têm as chaves de criptografia podem ler os dados, mesmo que
estejam expostos de outra forma.
 Criptografia de arquivo/pasta e Gerenciamento de Direitos Digitais Empresariais (do inglês Enterprise

Digital Rights Management - EDRM). Utilize as ferramentas padrão de criptografia de arquivos/pastas ou
o EDRM para criptografar os dados antes de colocá-los no armazenamento de objetos.
28
VPS - Armazenamento virtual privado

 Criptografia de aplicação/cliente. Quando o armazenamento de objetos for utilizado como retaguarda

(back-end) de uma aplicação (incluindo aplicações para dispositivos móveis), criptografe os dados
utilizando um motor de criptografia incorporado na aplicação ou no cliente.
 Criptografia em Proxy. Os dados passam por uma criptografia em Proxy antes de serem enviados para o
armazenamento de objetos.
5.6.3.3 Criptografia da PaaS
Dado que a PaaS é tão diversa, a seguinte lista pode não abranger todas as possíveis opções:
 Criptografia de aplicação/cliente. Os dados são criptografados na aplicação da PaaS ou o cliente acessa a

plataforma.
 Criptografia do banco de dados. Os dados são criptografados no banco de dados utilizando a criptografia
construída e suportada pela plataforma do banco de dados.
 Criptografia em Proxy. Os dados passam por uma criptografia em Proxy antes de serem enviados para a
plataforma.
 Outros. Opções adicionais podem incluir APIs construídas na plataforma, serviços de criptografia externos
e demais variações.
5.6.3.4 Criptografia do SaaS
Os provedores de SaaS podem utilizar qualquer uma das opções discutidas anteriormente. Quando for possível,
recomenda-se utilizar chaves por cliente para impor um melhor isolamento multilocatário. As seguintes opções
são para os consumidores de SaaS:
 Criptografia gerenciada no provedor. Os dados são criptografados no aplicação do SaaS e normalmente

são gerenciados pelo provedor.
 Criptografia em Proxy. Os dados passam por uma criptografia em Proxy antes de serem enviados para a
aplicação do SaaS.
As operações de criptografia devem utilizar qualquer método de criptografia que seja o mais adequado, os quais
podem incluir chaves compartilhadas ou pares de chaves públicas/privadas e uma extensa estrutura de
Infraestrutura de Chave Pública/Operacionais (do inglês Public Key Infrastructure/Operations - PKI/PKO 29).
Consulte o Domínio 11 para obter mais informações sobre criptografia e gerenciamento de chaves.
5.6.4 Prevenção de Perda de Dados
A Prevenção de Perda de Dados (DLP) é definida como:
Produtos que, baseados nas políticas centrais, identificam, monitoram e protegem os dados em repouso, em
movimento e em uso, através de uma profunda análise de conteúdo.
A DLP pode fornecer opções de como devem ser tratados os dados encontrados de violação das políticas. Os
dados podem ser bloqueados (interromper um fluxo de trabalho) ou liberados para prosseguir após o reparo por
criptografia, utilizando métodos como o DRM, o ZIP ou o OpenPGP.
29
PKI/PKO - Infraestrutura de chave pública/operacionais

O DLP é utilizado normalmente para a descoberta de conteúdo e monitoramento de dados em movimento

utilizando as seguintes opções:
 Appliance/servidor dedicado. O hardware padrão colocado no ponto de interconexão de uma rede entre
o ambiente de nuvem e o resto da rede/Internet ou dentro de diferentes segmentos da nuvem.
 Virtual appliance
 Agente de endpoint
 Hypervisor. O agente de DLP é incorporado ou acessado no nível do hypervisor, ao invés de executado na

instância.
 DLP no SaaS. A DLP é integrada a um serviço em nuvem (por exemplo, e-mail hospedado) ou oferecida
como um serviço autônomo (normalmente de descoberta de conteúdo).
5.6.5 Monitoramento da Atividade do Banco de Dados e de Arquivo
O Monitoramento da Atividade do Banco de Dados (DAM) é definido como:
O Monitoramento da Atividade do Banco de Dados captura e registra, no mínimo, todas as atividades das
linguagens de consulta estruturada (SQL) em tempo real ou quase, incluindo a atividade do administrador do
banco de dados, através de múltiplas plataformas de banco de dados, e; pode gerar alertas sobre as violações de
políticas.
O DAM apoia quase que em tempo real o monitoramento da atividade do banco de dados e os alertas baseados
nas violações de políticas, tais como ataques de SQL injection ou um administrador replicando o banco de dados
sem autorização. As ferramentas de DAM para ambientes em nuvem que são normalmente baseadas em agentes,
conectam-se a um servidor central de coleta (que normalmente é virtual). Ele é utilizado com as instâncias de
banco de dados dedicados para um único cliente, apesar de no futuro poder estar disponível para a PaaS.
O Monitoramento da Atividade de Arquivos (FAM) é definido como:
Produtos que monitoram e registram todas as atividades dentro de repositórios de arquivos atribuídos no nível do
usuário e geram alertas sobre as violações de políticas.
O FAM para nuvem requer a utilização de um agente de ponta ou a colocação de um dispositivo físico entre o
armazenamento em nuvem e os consumidores em nuvem.
5.6.6 Segurança de aplicações
Um grande percentual de exposições de dados resulta de ataques na camada de aplicações, especialmente de

aplicações da Web. Consulte o Domínio 10 para obter mais informações de segurança de aplicações.
5.6.7 Armazenamento para preservar a privacidade
Quase todos os sistemas de armazenamento baseados em nuvem requerem alguma autenticação dos
participantes (usuário de nuvem e/ou CSP) para estabelecer relações de confiança, seja apenas em uma ponta de
comunicação ou em ambas. Embora os certificados de criptografia possam oferecer segurança suficiente para

muitos desses propósitos, eles não costumam atender a privacidade, pois são vinculados à identidade de uma
pessoa real (usuário de nuvem). Qualquer uso de tal certificado expõe a identidade do titular ao solicitante da
autenticação. Há muitos cenários (por exemplo, o armazenamento dos Registros Eletrônicos de Saúde), onde o
uso de tais certificados desnecessariamente revela a identidade do seu titular.
Nos últimos 10-15 anos, tecnologias têm sido desenvolvidas para construir sistemas de uma maneira que eles
possam ser confiáveis como os certificados de criptografia normais, enquanto, ao mesmo tempo, protegem a
privacidade do seu titular (ou seja, ocultando a verdadeira identidade do titular). Tais credenciais baseadas em
atributos são emitidas apenas como credenciais criptográficas comuns (por exemplo, credenciais X.509) usando
uma chave (secreta) de assinatura digital. No entanto, as credenciais baseadas em atributos (ou ABCs, do inglês
attribute-based credentials) permitem que seu titular as transforme em uma nova credencial que contém apenas
um subconjunto dos atributos contidos na credencial original. Ainda assim, essas credenciais transformadas
podem ser verificadas como credenciais criptográficas ordinárias (utilizando a chave de verificação pública do
emissor) e oferecem a mesma segurança forte.
5.6.8 Gerenciamento de Direitos Digitais (DRM)
Basicamente, o Gerenciamento de Direitos Digitais criptografa o conteúdo e, em seguida, aplica uma série de
direitos. Os direitos podem ser bem simples, como evitar cópia, ou bem complexos, como especificar restrições
de grupo ou à base de usuários em atividades como recortar e colar, enviar e-mail, alterar o conteúdo, etc.
Qualquer aplicação ou sistema que trabalhe com dados protegidos pelo DRM deve poder interpretar e implantar
os direitos que, normalmente, também significam integrar-se com o sistema de gerenciamento de chaves.
Existem duas grandes categorias de Gerenciamento de Direitos Digitais:
 O DRM do Consumidor é utilizado para proteger o conteúdo amplamente distribuído, como áudio, vídeo
e livros eletrônicos destinados a um grande público. Há uma variedade de diferentes tecnologias e
padrões e, a ênfase está na distribuição unidirecional.
 O DRM Empresarial é utilizado para proteger o conteúdo de uma organização internamente e com os
parceiros de negócios. A ênfase é sobre os direitos mais complexos, as políticas e a integração em
ambientes empresariais e, particularmente, com o serviço de diretório corporativo.
O DRM Empresarial pode proteger bem o conteúdo armazenado na nuvem, mas também requer uma profunda
integração de infraestrutura. É mais útil para documentos baseados em gerenciamento e distribuição de
conteúdo. O DRM do Consumidor oferece uma boa proteção para a distribuição de conteúdo para os clientes,
mas não tem um bom histórico com a maioria das tecnologias que estão sendo quebradas em algum ponto.
5.7 Recomendações
o Compreenda a arquitetura de armazenamento em nuvem em uso, o que o ajudará a determinar os riscos

de segurança e os potenciais controles.
o Quando disponível, escolha o armazenamento com dispersão dos dados.
o Utilize a segurança do ciclo de vida dos dados para identificar exposições de segurança e determinar os
controles mais adequados.

o Monitore os bancos de dados internos e repositórios de arquivos chaves com o DAM e o FAM para
identificar grandes migrações de dados, o que poderia indicar dados migrando para a nuvem.
o Monitore o acesso à Internet dos funcionários com filtragem de URL e/ou ferramentas de DLP para
identificar dados confidenciais sendo movidos para a nuvem. Selecione ferramentas que incluem
categorias predefinidas para serviços em nuvem. Considere utilizar a filtragem para bloquear a atividade
não autorizada.
o Criptografe todos os dados confidenciais que se movem para ou dentro da nuvem na camada de rede, ou
em nós antes da transmissão de rede. Isso inclui todos os modelos de serviços e implantações.
o Ao utilizar qualquer criptografia de dados, preste especial atenção ao gerenciamento de chaves (consulte
o Domínio 11).
o Utilize a descoberta de conteúdo para fazer a varredura do armazenamento em nuvem e identificar a

exposição de dados confidenciais.
o Criptografe os volumes confidenciais na IaaS para limitar a exposição devido a instantâneos, ou o acesso
não autorizado do administrador. A técnica específica vai variar conforme as necessidades operacionais.
o Criptografe os dados confidenciais em armazenamento de objetos, geralmente com arquivos/pastas ou

de criptografia do cliente/agente.
o Criptografe os dados confidenciais de aplicações e de armazenamento na PaaS. A criptografia em nível de

aplicação é muitas vezes a melhor opção, especialmente porque alguns bancos de dados em nuvem
oferecem suporte à criptografia nativa.
o Ao utilizar criptografia de aplicação, as chaves devem ser, sempre que possível, armazenadas
externamente à aplicação.
o Se a criptografia é necessária para o SaaS, tente identificar um provedor que ofereça a criptografia nativa.
Utilize a criptografia em Proxy, caso esta não tenha uma disponível e/ou os níveis de confiança devam ser
assegurados.
o Utilize a DLP para identificar os vazamentos de dados confidenciais de implantações em nuvem.

Normalmente, só está disponível para a IaaS e, pode não ser viável para todos os provedores de nuvem
pública.
o Monitore os bancos de dados confidenciais com o DAM e gere alertas sobre as violações das políticas de
segurança. Utilize uma ferramenta preparada para nuvem (cloud-aware).
o Considere o armazenamento para preservar a privacidade ao propor infraestrutura ou aplicações onde o

acesso normal poderia revelar informações confidenciais do usuário.
o Lembre-se que a maioria das grandes falhas de segurança de dados resulta da aplicação de segurança
precária.
o Os provedores de nuvem não devem apenas seguir estas práticas, mas também expor as ferramentas e as
opções de segurança de dados para seus clientes.
o A remoção de dados de um fornecedor de nuvem, quer devido à expiração do contrato ou por qualquer
outro motivo, deverá ser abordada em detalhes durante a configuração do SLA. Ela deve abranger a

exclusão de contas de usuários, a migração ou a exclusão de dados de armazenamento

primário/redundante, a transferência de chaves, etc.
5.8 Requisitos
 Utilize a segurança do ciclo de vida dos dados para identificar exposições de segurança e determinar os
controles mais adequados.
 Devido a todos os problemas em potencial de competências regulatórias, contratuais e outras, é

extremamente importante compreender os locais lógicos e físicos dos dados.
 Monitore o acesso à Internet dos funcionários com filtragem de URL e/ou ferramentas de DLP para
identificar dados confidenciais que são movidos para a nuvem.
 Criptografe todos os dados confidenciais que são movidos para ou dentro da nuvem na camada de rede,
ou em nós antes de transmissão de rede.
 Criptografe volumes confidenciais na IaaS para limitar a exposição devido a instantâneos, ou o acesso não
autorizado do administrador.
 Criptografe os dados confidenciais de aplicações e de armazenamento na PaaS.

REFERÊNCIAS
[1] RABIN, M. O. 1989. Efﬁcient Dispersal of Information for Security, Load Balancing, and Fault Tolerance. J.
ACM, 36(2), 335–348.
[2] SECUROSIS. 2011. The Data Security Lifecycle. http://www.securosis.com/blog/data-security-lifecycle-2.0
[3] SECUROSIS. 2011. Understanding and Selecting a Data Loss Prevention Solution.
http://www.securosis.com/research/publication/report-data-loss-prevention-whitepaper
[4] SECUROSIS. 2008. Understanding and Selecting a Database Activity Monitoring solution.
http://www.securosis.com/research/publication/report-selecting-a-database-activity-monitoring-solution/
[5] CHAUM, D. L. Feb. 1981. Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms.
Communications of the ACM, 24 (2), 84-90.

DOMÍNIO 6 //
INTEROPERABILIDADE E PORTABILIDADE
O advento da computação em nuvem oferece uma capacitação administrativa e dimensionamento sem

precedentes para o processamento de TI de uma organização, incomparáveis àqueles disponíveis nas
infraestruturas internas "tradicionais". É possível acrescentar, mover ou remover uma capacidade adicional para
atender as dinâmicas alterações das necessidades de processamento, quase que instantaneamente. É possível
iniciar um novo sistema de suporte de aplicações para atender o aumento da demanda em questão de horas em
lugar de semanas. Caso a demanda seja reduzida, a capacidade adicional pode ser desligada com a mesma
rapidez, sem que nenhum hardware excedente fique ocioso. Colher os benefícios deste ambiente mais flexível
requer que a interoperabilidade e a portabilidade sejam os objetivos do projeto de qualquer sistema implantado
em nuvem, pela IaaS através do SaaS.
Em uma extremidade da escala, a interoperabilidade e a portabilidade permitem dimensionar um serviço por

meio de múltiplos provedores distintos em uma escala geral e ter esse sistema funcionando e aparentando ser
um único sistema. Na outra extremidade, a interoperabilidade e a portabilidade permitem a fácil movimentação
de dados e aplicações de uma plataforma para outra, ou de um provedor de serviço a outro.
A portabilidade e a interoperabilidade não são considerações exclusivas para ambientes em nuvem e, os aspectos
relacionados à sua segurança não são novos conceitos trazidos pela computação em nuvem. No entanto, os
ambientes de processamento abertos e frequentemente compartilhados que existem dentro da nuvem, trazem
uma necessidade de precauções ainda maiores do que as que são requeridas para o processamento de modelos
tradicionais. O multilocatário significa que os dados e as aplicações residem com dados e aplicações de outras
empresas e que o acesso aos dados confidenciais (intencional ou não) é possível através de plataformas,
armazenamento e redes compartilhadas.
Esta seção define a reflexão crítica que deve ser levada em consideração ao projetar para a portabilidade e
interoperabilidade.
Visão geral. As seções seguintes definem a interoperabilidade e a portabilidade:
 Uma introdução à interoperabilidade
 Recomendações para garantir a interoperabilidade
 Uma introdução à portabilidade
 Recomendações para a portabilidade
6.1 Uma introdução à interoperabilidade
Interoperabilidade é o requisito para que os componentes de um ecossistema em nuvem trabalhem em conjunto

para alcançar seu resultado pretendido. Em um ecossistema de computação em nuvem, os componentes podem

vir de diferentes fontes, tanto da nuvem como de implantações em nuvem tradicionais, públicas e privadas
(conhecido como nuvem híbrida). A interoperabilidade manda que esses componentes sejam substituídos por
componentes novos ou diferentes de distintos provedores e continuem a funcionar, assim como o intercâmbio de
dados entre os sistemas.
Ao longo do tempo, as empresas tomarão decisões que levam ao desejo de mudar de provedor. As razões para
esta desejada mudança incluem:
 Um aumento inaceitável dos custos no momento da renovação do contrato
 A capacidade de obter o mesmo serviço por um preço mais barato
 Um provedor cessa as operações de negócios
 Um provedor de repente fecha um serviço ou mais que está sendo utilizado sem planos de migração
aceitáveis
 Uma diminuição inaceitável na qualidade do serviço, como uma falha no cumprimento dos principais
requisitos de desempenho ou de atendimento aos contratos de nível de serviço (SLAs)30
 Uma disputa comercial entre o cliente e o provedor de nuvem
A falta da interoperabilidade (e também da portabilidade), pode levar ao bloqueio de um determinado provedor

de serviço de nuvem.
O grau que a interoperabilidade pode alcançar ou manter quando se considera um projeto de nuvem, muitas
vezes depende do grau que um provedor de nuvem utiliza arquiteturas abertas ou divulgadas e, protocolos e
APIs31 padrões. Embora muitos fornecedores que disponibilizam nuvem "aberta" e "padronizada" forneçam
ganchos de propriedade e extensões (por exemplo, a Eucalyptus) e melhorias que podem impedir a
interoperabilidade e portabilidade.
6.2 Uma introdução à portabilidade
A portabilidade define a fácil capacidade que os componentes de aplicações são movidos e reutilizados para outro
lugar, independentemente do provedor, plataforma, sistema operacional, infraestrutura, localização,
armazenamento, formato dos dados ou APIs.
A portabilidade e a interoperabilidade devem ser consideradas se a migração para a nuvem for a solução de
implantação em nuvem pública, privada ou híbrida. Eles são elementos importantes a serem considerados para a
seleção de modelo de serviço, independentemente da estratégia de migração ser de Software como um Serviço
(SaaS), Plataforma como Serviço (PaaS), ou Infraestrutura como Serviço (IaaS).
A portabilidade é um aspecto fundamental a se considerar ao selecionar os provedores de nuvem, já que tanto

pode ajudar a prevenir a dependência de um fornecedor como proporcionar benefícios nos negócios ao permitir
implantações em nuvem idênticas às que ocorrem em diferentes soluções de provedores de nuvem, seja para fins
de recuperação de desastres ou para a implantação global de uma solução única distribuída.
30
SLA - Contrato de nível de serviço
31

Conseguir a portabilidade para um serviço de nuvem depende geralmente dos dois serviços que operam no
mesmo oitante arquitetônico do Cloud Cube, conforme definido no primeiro domínio. Quando os serviços
operam em diferentes oitantes e depois portam um serviço, geralmente significa migrar de volta o serviço
"internamente" antes de terceirizá-lo de volta para um serviço em nuvem alternativa.
O fracasso na tratativa adequada da portabilidade e da interoperabilidade em uma migração para a nuvem pode
resultar na não obtenção dos benefícios desejados de se mudar para a nuvem e em problemas onerosos ou
atrasos no projeto, devido a fatores que devem ser evitados, tais como:
 Dependência de um aplicativo, fornecedor ou provedor - a escolha de uma determinada solução de

nuvem pode restringir a capacidade de mover-se para outra proposta de nuvem ou para outro fornecedor
 A incompatibilidade de processamento e conflitos que causam interrupção do serviço - o provedor, a

plataforma ou as diferenças de aplicação podem expor incompatibilidades que causam mau
funcionamento de aplicações dentro de uma infraestrutura em nuvem distinta
 A reengenharia inesperada de aplicação ou as alterações dos processos de negócios - a mudança para um

novo provedor de nuvem pode apresentar uma necessidade de reformular como um processo funciona
ou requerer alterações de codificação para manter os comportamentos originais
 A onerosa migração de dados ou a conversão de dados - a falta de formatos interoperáveis e portáveis

pode levar a alterações não planejadas de dados ao se mover para um novo provedor
 A reciclagem ou remodelagem de novo aplicação ou software de gerenciamento
 A perda de dados ou a segurança de aplicações - uma diferente política de segurança ou de controle, o

gerenciamento de chaves ou a proteção de dados entre os provedores pode abrir brechas de segurança
encobertas ao mover-se para um novo provedor ou plataforma
Os serviços de mudança para a nuvem são uma forma de terceirização; a regra de ouro da terceirização é
"compreender com antecedência e planejar como rescindir o contrato". Análogo à interoperabilidade, a
portabilidade deve ser, portanto, um critério fundamental de qualquer estratégia das organizações para mudar
para os serviços em nuvem, permitindo que uma estratégia de saída viável seja desenvolvida.
6.3 Recomendações
6.3.1 Recomendações de interoperabilidade
Hardware - hardware físico do computador
O hardware inevitavelmente varia ou muda ao longo do tempo e de provedor para provedor, deixando brechas
de interoperabilidade inevitáveis se o acesso direto ao hardware for necessário.
o Sempre que possível, utilize a virtualização para remover muitas preocupações em nível de hardware,
lembrando que a virtualização não necessariamente elimina todos os problemas de hardware,
especialmente nos sistemas atuais.
o Se o hardware precisar ser diretamente operado, é importante assegurar que existam os mesmos ou
melhores controles de segurança físicos e administrativos ao mudar de um provedor para outro.

Dispositivos físicos de rede
Os dispositivos de rede, incluindo os dispositivos de segurança, serão diferentes de um para outro provedor de
serviços, juntamente com sua API e seu processo de configuração.
o Para manter a interoperabilidade, o hardware físico da Rede e a abstração da rede e da segurança devem
estar em domínio virtual. Na medida do possível, as APIs devem ter a mesma funcionalidade.
Virtualização
Embora a virtualização possa ajudar a eliminar as preocupações sobre o hardware físico, existem diferenças
distintas entre hypervisors comuns (como o ZEN, o VMware e outros).
o Utilize formatos abertos de virtualização como o OVF para ajudar a garantir a interoperabilidade.
o Documente e entenda quais ganchos de virtualização específicos são utilizados, independente do seu
formato. Ele ainda pode não funcionar em outro hypervisor.
Estruturas
Provedores de plataformas diferentes oferecem diferentes estruturas de aplicações em nuvem e não existem
diferenças entre eles que afetem a interoperabilidade.
o Investigue as APIs para determinar onde se encontram as diferenças e planeje as mudanças necessárias
que possam ser requeridas para o processamento de aplicações ao mudar para um novo provedor.
o Utilize APIs abertas e divulgadas para garantir o mais amplo suporte para interoperabilidade entre os
componentes e facilitar a migração de aplicações e de dados, caso seja necessário alterar um provedor de
serviços.
o As aplicações na nuvem frequentemente interagem através da Internet e é possível prever que possam
ocorrer interrupções. Determine como uma falha em um componente (ou uma resposta lenta) impactará
os demais e evitará dependências dinâmicas que possam arriscar a integridade dos dados do sistema
quando um componente remoto falhar.
Armazenamento
Os requisitos de armazenamento variam para os diversos tipos de dados. Na maioria das vezes, os dados
estruturados necessitam de um sistema de banco de dados, ou requerem determinados formatos de aplicativo.
Os dados não estruturados normalmente seguem qualquer um de uma série de formatos comuns de aplicações
utilizados por processadores de texto, planilhas e gerenciadores de apresentações. A preocupação aqui deve ser a
de mover sem problemas os dados armazenados de um serviço para outro.
o Armazene os dados não estruturados em um determinado formato portável.
o Avalie a necessidade de criptografia para os dados em trânsito.
o Verifique a existência de sistemas de banco de dados compatíveis e, caso necessário, avalie os requisitos
de conversão.

Segurança
Os dados e as aplicações na nuvem residem em sistemas que o usuário não possui e provavelmente têm apenas
um controle limitado. Uma série de itens importantes a serem considerados para a segurança interoperável inclui:
o Utilizar a SAML (Security Assertion Markup Language) ou as especificações WS-Security (Web Service
Security) para autenticação para que os controles possam ser interoperáveis pelos demais sistemas
normatizados. Consulte o domínio 12 para obter mais detalhes.
o Antes de serem colocados na nuvem, a criptografia garantirá que os dados não possam ser acessados
inadequadamente dentro de ambientes em nuvem. Consulte o domínio 11 para obter mais detalhes
sobre a criptografia.
o Quando as chaves de criptografia estiverem em uso, investigue como e onde elas estão armazenadas para
garantir que o acesso aos dados criptografados existentes será mantido. Consulte o domínio 11 para
obter mais detalhes sobre o gerenciamento de chaves.
o Compreenda as suas responsabilidades e obrigações em caso de ocorrer um comprometimento nos

métodos de proteção oferecidos pelo seu provedor de serviços devido às "brechas" imprevistas.
o O registro de informações do arquivo deve ser manuseado com o mesmo nível de segurança de todos os
demais dados que se movem para a nuvem. Certifique-se de que os arquivos de registros sejam
interoperáveis, para garantir a continuidade da análise do registro de pré e pós-movimento, bem como a
compatibilidade com qualquer sistema de gerenciamento de registro que estiver sendo utilizado.
o Quando concluir uma transição, garanta que todos os dados, registros e demais informações sejam
excluídas do sistema original.
6.3.2 Recomendações de portabilidade
Existem inúmeras questões colocadas no decorrer da transição para a nuvem. As considerações e recomendações
de portabilidade que impactam a transição para a nuvem compreendem;
o O nível de serviço. Os SLAs serão diferentes entre provedores e, é preciso compreender como isso pode
afetar a sua capacidade de trocar de provedor.
o Arquiteturas distintas. Os sistemas na nuvem podem residir em arquiteturas de plataformas diferentes. É

importante estar ciente de como elas limitarão a portabilidade através da compreensão das
dependências de serviço e de plataforma, que podem incluir APIs, hypervisors, a lógica de aplicações e
demais restrições.
o Integração de segurança. Os sistemas de nuvem apresentam preocupações específicas de portabilidade

para manter a segurança, incluindo:
o Os mecanismos de autenticação e identificação para o acesso do usuário ou do processo aos sistemas

devem funcionar agora em todos os componentes de um sistema em nuvem. Utilizar padrões abertos
para a Identificação como o SAML ajudará a garantir a portabilidade. Desenvolver o sistema interno IAM
para suportar as assertivas da SAML e o sistema interno para aceitar a SAML ajudará a futura
portabilidade do sistema para a nuvem.
o As chaves de criptografia devem ser caucionadas localmente e, quando possível, mantidas localmente

o Os metadados são um aspecto da informação digital que frequentemente e facilmente são esquecidos,
uma vez que (normalmente) os metadados não são diretamente visíveis quando se trabalha com arquivos
e documentos. Os metadados tornam-se uma importante consideração na nuvem, pois se movem com o
documento. Ao mover os arquivos e seus metadados para novos ambientes de nuvem, garanta que as
cópias dos metadados dos arquivos foram seguramente removidas, para impedir que essas informações
tenham ficado para trás e abram uma possível oportunidade de comprometimento.
6.3.3 Recomendações para diferentes modelos de nuvem
Há certo número de riscos e recomendações comuns a todos os modelos genéricos de nuvem.
o Ao substituir provedores de nuvem, é normal esperar resistência do provedor de nuvem legada. Isso deve
ser planejado no processo contratual, conforme descrito no domínio 3, no seu Programa de Continuidade
de Negócios, conforme descrito no Domínio 7 e, como parte da sua governança geral no Domínio 2.
o Entenda a dimensão dos conjuntos de dados hospedados em um provedor de nuvem. A mera dimensão
dos dados pode causar uma interrupção do serviço durante a transição, ou um período de transição mais
longo que o previsto. Muitos clientes descobriram que o envio de unidades de disco rígido através de um
mensageiro é mais rápido do que a transmissão eletrônica para grandes conjuntos de dados.
o Documente a arquitetura de segurança e a configuração dos controles individuais de segurança dos

componentes, de modo que possam ser utilizados para apoiar as auditorias internas, bem como para
facilitar a migração para novos prestadores e ajudar a validação do novo ambiente.
Infraestrutura como um Serviço (IaaS)
Quando a responsabilidade do provedor de nuvem é fornecer as utilidades básicas de computação, tais como o
armazenamento, a capacidade computacional, etc., o cliente em nuvem é responsável pela maioria de tarefas de
design de aplicações relacionadas à interoperabilidade. O provedor de nuvem deve fornecer recursos de
hardware e de computação padronizados que possam interagir com os diferentes sistemas com mínimo esforço.
O provedor de nuvem deve aderir estritamente aos padrões da indústria para manter a interoperabilidade. O
provedor deve poder dar suporte a cenários complexos, tais como o agenciamento em nuvem, explosão da
nuvem, nuvens híbridas, federação multinuvem, etc.
o Entenda como imagens de máquinas virtuais podem ser capturadas e portadas para novos provedores de
nuvem e quem pode utilizar diferentes tecnologias de virtualização. Exemplo: O formato de virtualização
aberta (do inglês Open Virtualization Format (OVF)) da força-tarefa de gerenciamento distribuído (do
inglês Distributed Management Task Force (DMTF)).
o Identifique e elimine (ou pelo menos documente) todas as extensões específicas do provedor para o
ambiente de máquina virtual.
o Entenda quais práticas estão no local para se certificar do desprovimento adequado de imagens de VM
que ocorrem depois que uma aplicação é transferida pelo provedor de nuvem.
o Entenda as práticas utilizadas para a desativação dos discos e dos dispositivos de armazenamento.
o Entenda as dependências baseadas em hardware/plataforma que precisam ser identificadas antes da

migração das aplicações/dados.

o Solicite o acesso aos registros do sistema, rastreamentos e acessos e registros de bilhetagem do provedor
da nuvem legada.
o Identifique as opções para retomar ou estender parcial ou totalmente o serviço com o provedor da
nuvem legada, caso o novo serviço se revele como inferior.
o Determine se existem quaisquer funções de nível gerencial, interfaces ou APIs que estejam sendo
utilizadas que sejam incompatíveis ou ainda não implantadas pelo novo provedor.
o Entenda os custos envolvidos para mover os dados de e para um provedor de nuvem
o Determine quais são os meios suportados para mover os dados para a nuvem, de forma tão eficiente
quanto possível, através da utilização de recursos padrão, como a compressão de dados.
o Entenda qual é a segurança fornecida e quem mantém o acesso às chaves de criptografia.
Plataforma como um Serviço (PaaS)
O provedor de nuvem é responsável por fornecer uma plataforma para que os consumidores possam estabelecer
seus sistemas. Eles fornecem um ambiente de tempo de execução e uma pilha de aplicações integradas. Isso
permite aos desenvolvedores estabelecer e implantar rapidamente aplicações personalizadas nas plataformas
oferecidas, sem a necessidade de construir a infraestrutura. O provedor de nuvem fornece toda a infraestrutura e
manutenção para os seus consumidores.
o Sempre que possível, utilize os componentes da plataforma com uma sintaxe padrão, APIs e padrões
abertos, como, por exemplo, a Interface de Computação de Nuvem Aberta (do inglês Open Cloud
Computing Interface (OCCI)32
o Entenda quais ferramentas estão disponíveis para a transferência segura dos dados, backup e
restauração.
o Entenda e documente os componentes das aplicações e os módulos específicos para o provedor da PaaS e
desenvolva a arquitetura de aplicações com camadas de abstração para minimizar o acesso direto aos
módulos proprietários.
o Entenda como os serviços de base, como o monitoramento, o registro e a auditoria seriam transferidos
para um novo fornecedor.
o Entenda quais proteções são fornecidas para os dados colocados na nuvem e para os dados gerados e
mantidos na nuvem.
o Entenda as funções de controle fornecidas pelo provedor da nuvem legada e, como eles pretendem
traduzir para o novo provedor.
o Ao migrar para uma nova plataforma, compreenda os impactos sobre o desempenho e a disponibilidade
do aplicativo e, como esses impactos serão medidos.
o Entenda como o teste será concluído antes e depois da migração para verificar se os serviços ou
aplicações estão funcionando corretamente. Certifique-se de que as responsabilidades pelos testes sejam
bem conhecidas e documentadas, tanto pelos provedores como pelos usuários.
32
OCCI - Interface de computação de nuvem aberta

Software como um Serviço (SaaS)
O provedor de nuvem fornece recursos de aplicações na nuvem e o cliente apenas gerencia suas operações e
informações que fluem para dentro e para fora do sistema. O cliente precisa de um navegador e, em todos os
níveis, a maioria da administração é do provedor.
o Realize extrações de dados regulares e backups para um formato que pode ser utilizado sem o provedor
de SaaS.
o Entenda se os metadados podem ser preservados e migrados.
o Utilize os serviços de custódia de dados caso seja necessário.
o Entenda que quaisquer ferramentas personalizadas terão de ser reconstruídas, ou o novo fornecedor
deve fornecer essas ferramentas, ou comprometer-se a portar (e dar suporte a) essas ferramentas.
o Verifique e audite para assegurar a consistência da eficiência do controle pelos provedores novos ou
anteriores.
o Certifique-se de fazer backup e outras cópias dos registros e acessos, bem como de qualquer outra
informação pertinente, que possam ser requeridos por razões legais e de conformidade para que possam
ser migrados.
o Entenda o gerenciamento, o monitoramento, os relatórios e as interfaces e sua integração entre os

ambientes.
o Teste e avalie todos as aplicações antes da migração e, se exequíveis, execute-os em duplicidade antes
entrar em operação.
Nuvem Privada
A nuvem é privada quando o consumidor executa um ambiente de nuvem/serviço dentro de sua empresa ou
utiliza uma proposta de nuvem privada dos provedores de nuvem (geralmente estendendo a rede interna em um
centro de provedores de serviços de hospedagem).
o Garanta que a interoperabilidade exista entre os hypervisors comuns, como KVM, VMware, Xen.
o Certifique-se de que sejam utilizadas APIs padrão para as funções de gerenciamento, tais como usuários e
seu gerenciamento de privilégios, gerenciamento de imagem de VM, gerenciamento de Máquinas
Virtuais, gerenciamento de Redes Virtuais, gerenciamento de Serviços, gerenciamento de
Armazenamento, gerenciamento de Infraestrutura, gerenciamento da Informação, etc.
Nuvem Pública
A interoperabilidade em nuvem pública significa expor a maioria das interfaces de nuvens comuns. Elas podem
ser específicas de fornecedores ou com especificações e interfaces abertas como a OCCI, Libcloud, etc.
o Garanta que os provedores de nuvem exponham interfaces comuns e/ou abertas para acessar todas as
funções da nuvem em sua proposta de serviços.
Nuvem Híbrida

Neste cenário, a infraestrutura privada local do consumidor deve poder trabalhar com provedores de nuvem
externos. Um cenário comum é a "explosão da nuvem", quando uma empresa compartilha a carga com os
provedores de nuvem externas para atender as demandas de pico.
o Garanta que os provedores de nuvem exponham interfaces comuns e/ou abertas para acessar todas as
funções da nuvem em sua proposta de serviços.
o Assegure a capacidade de coligar diferentes provedores de nuvem para permitir maiores níveis de
dimensionamento.

REFERÊNCIAS
[1] http://msdn.microsoft.com/en-us/library/cc836393.aspx
[2] http://blogs.msdn.com/b/eugeniop/archive/2010/01/12/adfs-wif-on-amazon-ec2.aspx
[3] http://download.microsoft.com/download/6/C/2/6C2DBA25-C4D3-474B-8977-E7D296FBFE71/EC2-
Windows%20SSO%20v1%200--Chappell.pdf
[4] http://www.zimbio.com/SC+Magazine/articles/6P3njtcIjmR/Federation+2+0+identity+ecosystem
[5] http://www.datacenterknowledge.com/archives/2009/07/27/cloud-brokers-the-next-big-opportunity/
[6] http://blogs.oracle.com/identity/entry/cloud_computing_identity_and_access
[7] http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf
[8] http://www.burtongroup.com
[9] http://www.pkware.com/appnote
[10] http://www.apps.ietf.org/rfc/rfc4880.html

SEÇÃO III //
OPERANDO NA
NUVEM

DOMÍNIO 7 //
SEGURANÇA TRADICIONAL, CONTINUIDADE DOS NEGÓCIOS E
RECUPERAÇÃO DE DESASTRES
Com o surgimento da computação em nuvem como uma tecnologia preferida para as operações de terceirização
de TI, as questões de segurança característicos do modelo de hospedagem têm assumido maior importância e
criticabilidade. Os riscos associados são inerentes ao conceito de computação em nuvem ao confiar os dados
confidenciais e restritos a terceiros ou a Provedores de Serviços em Nuvem (do inglês Cloud Service Providers -
CSP)33 totalmente dedicados (do inglês pure-play).
A evolução dos serviços em nuvem possibilitou que entidades empresariais fizessem mais com menos: menos
recursos e melhor eficiência operacional. Isso tem muitos benefícios tangíveis para os negócios, mas ainda há
riscos de segurança inerentes que precisam ser avaliados, tratados e resolvidos antes que as empresas tenham
confiança na segurança da terceirização de seus requisitos de TI para os provedores de serviços de nuvem.
Um dos objetivos deste domínio é auxiliar os usuários de serviços de Esta seção mapeia para as normas IS-
nuvem a compartilhar um entendimento comum de segurança 01 e IS-02 dos Domínios da Matriz de
tradicional (segurança física), com serviço de nuvem. A segurança Controle de Nuvem (do inglês “Cloud
tradicional pode ser definida como as medidas tomadas para Control Matrix Domains”), bem como
garantir a segurança e a existência material de dados e de pessoal para a norma ISO/IEC 27002 Cláusula 9.
contra roubo, espionagem, sabotagem ou danos. No contexto da
segurança da informação em nuvem, trata-se de informações, produtos e pessoas.
Uma adequada segurança da informação implanta muitas camadas diferentes para atingir o seu objetivo. Isto é
referido como “segurança em camadas” ou “defesa em profundidade”. Ao implantar medidas de segurança, os
gestores devem reconhecer que nenhuma medida é cem por cento segura. A segurança da informação utiliza a
profundidade de suas camadas para atingir um nível combinado de segurança. A debilidade de qualquer uma
dessas camadas pode causar a quebra da segurança. A proteção física é o primeiro passo para uma abordagem
em camadas para a segurança da informação em nuvem. As melhores medidas lógicas de segurança não
compensarão a falha de segurança física e a segurança geral pode falhar caso elas sejam inexistentes,
implantadas incorretamente, brandas, executadas de forma inconsistente, tratadas como um projeto (dispare e
esqueça) ou indevidamente verificadas e atualizadas.
Um programa de segurança tradicional eficaz emana de uma série bem desenvolvida de avaliação de riscos, de
análise de vulnerabilidade, de políticas de BCP/DR, de processos e procedimentos que são revisados e testados
regularmente. Programas bem desenvolvidos de segurança física resultarão em segurança física, que é
dimensionável com o negócio, repetível em toda a organização, mensurável e sustentável, defensável, melhorado
continuamente e continuamente de baixo custo.
33
CSP - Provedor de serviço em nuvem

Visão geral: Alguns dos riscos de segurança associados com a computação em nuvem são únicos e, é neste
contexto que a continuidade de negócios, a recuperação de desastres e os ambientes de segurança tradicional de
um provedor de serviços em nuvem precisam ser avaliados cuidadosamente (por exemplo, utilizando as diretrizes
padrão do setor, como o Grupo para a Estrutura da Arquitetura Aberta TOGAF34, a Arquitetura Aplicada em
Segurança Empresarial de Sherwood SABSA35, a Biblioteca da Infraestrutura da Tecnologia de Informação ITIL36, o
Comitê das Organizações de Patrocinadores COSO37 ou os Objetivos de Controle da Informação e das Tecnologias
Relacionadas COBIT38). Este domínio trata de:
 Estabelecer uma função de segurança física

Esta seção mapeia para as normas FS-
 Segurança física dos recursos humanos 01, FS-02, FS-03, and FS-04 dos
Domínios da Matriz de Controle de
 Continuidade dos negócios Nuvem (do inglês “Cloud Control
Matrix Domains”), bem como para a
 Recuperação de desastres
norma ISO/IEC 27002 Cláusula 9.
7.1 Estabelecer uma função de segurança tradicional
A segurança desatualizada dos equipamentos de TI, da tecnologia de rede e das telecomunicações muitas vezes é
esquecida em muitas organizações. Isso resultou na instalação de equipamentos de informática, redes e gateways
em edifícios que não possuem instalações físicas adequadas, destinadas a assegurar os ativos ou manter sua
disponibilidade.
Para estabelecer a segurança física adequada aos equipamentos de informática, à tecnologia de rede e aos ativos
de telecomunicações em um ambiente de nuvem, é importante que as responsabilidades sejam atribuídas ao
pessoal que seja adequadamente alocado na organização de um provedor de nuvem. Uma pessoa em uma
posição de gerência dentro de um provedor de nuvem é responsável pelo planejamento de gestão, implantação e
manutenção dos planos e procedimentos relevantes. O pessoal responsável pela segurança física precisa ser
treinado e ter seu desempenho avaliado. Ao estabelecer uma função de segurança física em um ambiente de
nuvem, é preciso considerar o seguinte:
 As necessidades de segurança para os equipamentos e serviços que estão sendo protegidos
 Os recursos humanos que estão no local para a segurança física
 De que maneira os esforços de segurança física legados foram geridos e equipados antes da transição
para a nuvem
 Os recursos financeiros disponíveis para estes esforços
A segurança física pode ser tão simples quanto acrescentar uma porta trancada ou tão elaborada quanto a
implantação de múltiplas camadas de barreiras e guardas de seguranças armados. Uma segurança física
adequada utiliza o conceito de combinações apropriadas de defesa em camadas para gerenciar o risco ao impedir
e retardar ameaças de segurança física. As ameaças físicas à infraestrutura, ao pessoal e aos sistemas não estão
34
TOGAF - O grupo para a estrutura da arquitetura aberta
35
SABSA - Aplicada em segurança empresarial de Sherwood
36
ITIL - Biblioteca da infraestrutura da tecnologia de informação
37
COSO - Comitê das organizações de patrocinadores
38
COBIT - Objetivos de controle da informação e das tecnologias relacionadas

limitadas a intrusões. Para minimizar esses riscos, são implantadas combinações de barreiras tanto ativas quanto
passivas, que contemplam medidas como:
 Obstáculos para impedir e retardar eventos, incidentes e ataques
 Sistemas de detecção para monitorar as condições ambientais e de segurança
 Resposta de segurança concebida para repelir, apreender ou desencorajar os atacantes
A segurança física leva geralmente a uma das muitas formas no projeto e na implantação:
 Projeto ambiental
 Controles mecânicos, eletrônicos e processuais
 Procedimentos de detecção, atendimento e recuperação
 Identificação pessoal, autenticação, autorização e controle de acesso
 Políticas e procedimentos, incluindo o treinamento de pessoal
7.1.1 Avaliação da segurança física tradicional
Ao avaliar a segurança tradicional de um CSP, os consumidores consideram os aspectos da infraestrutura como

um serviço/presença física na base do provedor do centro de dados. Estes incluem a localização física das
instalações e a documentação de fatores críticos de risco e de recuperação.
7.1.1.1 Localização física das instalações do CSP
Os consumidores devem realizar uma avaliação crítica da localização física do centro de dados. Se eles são
dependentes de uma cadeia de suprimentos de nuvem, é importante entender a infraestrutura de nuvem de que
dependem.
Seguem algumas sugestões para avaliar a localização física da instalação:
 Verifique se o local da instalação é abrangido por alguma zona sísmica ativa e os riscos de atividades
sísmicas
 As instalações não devem estar localizadas em uma região geográfica propensa a inundações,
deslizamentos de terra ou outros desastres naturais
 A instalação não deve estar em uma área com alto índice de criminalidade, política ou agitação social
 Verifique a acessibilidade do local da instalação (e a frequência da inacessibilidade)
7.1.1.2 Verificação da documentação
As operações de apoio à recuperação da documentação são fundamentais para avaliar a prontidão da empresa de
hospedagem para se recuperar de um evento catastrófico. O seguinte conjunto de documentação deve ser
inspecionado antes da contratação de um provedor de centro de dados físico:
 Análises de risco
 Avaliações de risco

 Avaliações de vulnerabilidade
 Planos de continuidade de negócios
 Planos de recuperação de desastres
 Políticas de segurança física e ambiental
 Procedimentos de encerramento de conta de usuário
 Planos de contingência, incluindo os protocolos de testes
 Planos de incidentes e de atendimento, incluindo os protocolos de teste
 Plano de atendimento de emergência
 Disposição das instalações - saídas de emergência, posicionamento de câmeras de CFTV, pontos de

entrada seguros
 Mapa da rota de fuga em caso de incêndio e instruções em caso de incêndio
 Plano de evacuação de emergência e procedimentos
 Procedimentos de comunicação de crises
 Números dos contatos de emergência
 Acesso do usuário às instalações para verificação/auditoria dos registros
 Documentação de treinamento de conscientização de segurança, apresentação, folhetos, etc.
 Registros do atendimento de conscientização de segurança
 Planejamento de sucessão para os principais executivos
 Documentação técnica - diagramas de fiação elétrica, sistema de automação do edifício (do inglês
Buildings Management System - BMS), fonte de alimentação ininterrupta (do inglês Uninterruptible
Power Supply - UPS), detalhes do sistema de ar condicionado (do inglês Air Handling Units - AHU)
 Programa de manutenção elétrica, do gerador e de CFTV
 Contratos de fornecedores de combustível de emergência
 Relação do pessoal autorizado a entrar no interior das instalações
 Perfis do pessoal da segurança - informações biomédicas e de antecedentes
 Relatórios de verificação de antecedentes do pessoal da segurança (deve ser realizada todos os anos)
 Contratos de manutenção anual para os equipamentos e principais dispositivos (com foco nos SLAs39 para
o tempo de inatividade e de restauração dos equipamentos/dispositivos)
39

Ao inspecionar os documentos, há áreas de foco crítico nas quais o comprador de serviços em nuvem deve se
concentrar para garantir que o seu risco está minimizado. As seguintes recomendações podem se mostrar críticas
na obtenção de interesse comercial de um consumidor de nuvem ao transitar para a nuvem:
 Verifique se todos os documentos estão em dia e atualizados. Estes documentos devem ser verificados
pelo CSP, pelo menos uma vez por ano. As datas de revisão e as assinaturas da administração devem ser
inclusas e validadas como comprovantes de que eles foram revistos internamente.
 Além disso, as políticas e os documentos de procedimentos (que são apropriados para a visualização pelo
funcionário) devem ser disponibilizados através de um site em comum na Intranet, onde os funcionários
autorizados do CSP podem acessá-los a qualquer momento para referência. Devem ser tomados cuidados
adequados pela equipe de segurança para garantir que os documentos enviados são as últimas versões
devidamente aprovadas pela administração.
 Todas as políticas e procedimentos só serão efetivas quando os funcionários tiverem conhecimento delas.
Para isso, verifique se o CSP dispõe no local de um programa de conscientização de segurança. No
mínimo, o CSP deve garantir que os funcionários recebam pelo menos uma vez por ano o treinamento
adequado de conscientização de segurança e, assinem confirmando terem recebido. Além disso, os novos
funcionários devem ser submetidos a uma sessão de orientação de segurança como parte do programa
de integração, onde as políticas e os procedimentos fundamentais devem ser preservados com uma lista
de presença formalmente assinada e mantida disponível para verificação a qualquer momento. Para
tornar o programa efetivo, os funcionários mais experientes da equipe de segurança devem conduzir a
sessão.
7.1.1.3 Conformidade com as normas de segurança internacionais/setoriais
Certifique-se de que o CSP está em conformidade com as normas de segurança internacionais, como a ISO 27001
ISMS ou outras normas setoriais como as TOGAF, Sabsa, ITIL, COSO ou COBIT. Essas atividades comprovarão ser
inestimáveis para avaliar o nível de segurança e a maturidade do seu CSP.
 Verifique o certificado de conformidade e a sua validade.
 Procure evidências que comprovem a alocação de recursos, tais como orçamentos e mão de obra para
sustentar o programa de conformidade.
 Verifique os relatórios de auditoria interna e evidências de ações corretivas para as descobertas.
7.1.1.4 Inspeção visual através de visita às instalações do CSP
Proteção da área
A segurança no perímetro do centro de dados precisa ser avaliada quando estiver determinando quais áreas
requerem proteção física. As áreas de alto risco que devem ser protegidas são:
 As áreas administrativas
 A recepção
 O estacionamento
 O estoque

 As saídas de emergência
 O centro de comando de CFTV
 A sala do sistema de ar condicionado (AHU)
 A sala do cofre
 A sala da fonte de alimentação ininterrupta (UPS)
 A sala do gerador
 Os tanques de armazenamento de combustível
Sinalização
Procure as seguintes sinalizações que devem estar bem visíveis nos locais adequados para a instalação:
 Mapas de rotas de fuga em caso de incêndio e saídas de emergência
 Instruções em caso de incêndio
 Sinalização de segurança contra incêndios
 Cartazes e instruções de segurança
 Cartazes de utilização não autorizada
 Informações relativas à temperatura/umidade
 Sinalização de advertência e instrucional
 Números dos contatos de emergência
 Quadro de escalas
7.1.2 Infraestrutura de segurança
O perímetro de segurança é importante, pois serve como a primeira barreira de proteção contra intrusos e
visitantes indesejados. Os princípios da segurança de perímetro sofreram uma mudança radical com os avanços
tecnológicos. Deter, Detectar, Delongar e Desautorizar são as fases dos Quatro “Dês” do Perímetro de Segurança
para os invasores que querem acessar as instalações.
As qualidades a seguir são preferenciais na escolha de um provedor de infraestrutura física. Dependendo do

design e da função do provedor de serviços em nuvem, a lista abaixo deve ser rigorosamente cumprida no
processo de seleção. É preciso tomar o devido cuidado para garantir que a infraestrutura física seja adequada
para o tamanho do estabelecimento e para a natureza e escala de operações. Os controles de segurança devem
ser estrategicamente posicionados e estar em conformidade com os padrões de qualidade aceitáveis,
consistentes com as normas prevalecentes e melhores práticas.
 Pontos seguros de entrada - sistemas de controle de acesso (cartões de proximidade/acesso biométrico)
 Sistema de Controle de Acesso interligado ao painel de controle de incêndio para liberação de emergência

 Alarmes com sensor de movimento, dispositivos de monitoramento térmico, detecção de quebra de vidro
 Equipamentos de segurança contra incêndio - estação de bombeamento com reservatório interno,

hidrantes, mangueiras, detectores de fumaça e rede de chuveiros automáticos de água (sprinklers)
 Extintores de incêndio
 Saídas de emergência (não devem estar bloqueadas ou travadas)
 Barras antipânico nas portas de saída de emergência
 Sirenes e iluminação de emergência
 Sistema de CFTV com câmeras e servidor com DVR (incluindo o backup ininterrupto)
 Fechamento de portas e alarmes de porta temporizados
 Supressores de incêndio a gás no interior dos centros de dados
 Fragmentadoras de papéis próximas às impressoras
 Desmagnetizadores ou fragmentadoras de discos
 Kit de Equipe de Atendimento de Emergência (do inglês Emergency Response Team Kit (ERT Kit))
 Rádios intercomunicadores (walkie-talkie) para os funcionários da segurança
 Alarmes de segurança sob a mesa para casos de coação e em pontos de observação (escondidos)
 Detectores de metal na entrada e detectores de metal portáteis (caso seja necessário)
 Cofre à prova de fogo para a guarda de documentos/mídias importantes
7.2 Segurança física dos recursos humanos
A finalidade do controle físico dos recursos humanos é minimizar o risco do Esta seção mapeia para as normas IS-
pessoal mais próximo dos dados interromper as operações e comprometer 15, FS-05, FS-06, FS-07 e FS-08 dos
a nuvem. Uma pessoa experiente com acesso físico a um console pode Domínios da Matriz de Controle de
ignorar as medidas de proteção mais lógicas simplesmente reiniciando o Nuvem (do inglês “Cloud Control
sistema ou acessando um sistema já ligado com acesso à raiz ou de Matrix Domains”), bem como para a
administrador. Um armário de cabos pode fornecer o acesso oculto a uma norma ISO/IEC 27002 Cláusula 9.
rede ou um meio de sabotar redes existentes. Considere as seguintes
medidas:
 Funções e responsabilidades (por exemplo, através de uma matriz de responsabilidades no estilo RACI
(Responsável, Encarregado, Consultado, Informado, do inglês Responsible, Accountable, Consulted,
Informed)
 Verificação de antecedentes e contratos de rastreamento
 Contrato de trabalho (por exemplo, um contrato de confidencialidade (do inglês Non-Disclosure

Agreement - NDA)

 Rescisão trabalhista
 Conscientização e treinamento sobre as políticas da empresa (ou seja, o código ou a conduta empresarial)
As funções e responsabilidades são parte de um ambiente em nuvem em que as pessoas e os processos,

juntamente com a tecnologia, são integrados para sustentar a segurança do locatário de forma consistente. A
divisão de funções requer pelo menos duas pessoas com responsabilidades de trabalho separadas para concluir
uma transação ou um processo de ponta a ponta. Prevenir os conflitos de interesses é fundamental para a
proteção dos consumidores em nuvem e é preciso implantar medidas para controlar ou evitar este risco. Os
benefícios da divisão de funções de origem contábil e gestão financeira se estendem a outras necessidades de
minimização de riscos, tais como segurança física, disponibilidade e proteção do sistema. A divisão de funções é
implantada eliminando-se combinações de funções de alto risco, por exemplo, não ter a mesma pessoa para
aprovar um pedido de compra e que também possa facilitar o pagamento. O princípio é aplicado à divisão de
função de desenvolvimento da nuvem e de operações, bem como em um ciclo de vida de desenvolvimento de
software. Um exemplo comum de desenvolvimento de software em nuvem seria a separação das pessoas que
desenvolvem aplicações da equipe dos que operam esses sistemas. Verifique se não há acessos não autorizados
remanescentes da entrega do produto final. Certifique-se de que um pessoal diferente gerencie diferentes
componentes críticos de infraestrutura. Além disso, o número de funcionários que concede o mínimo de
privilégio de acesso requerido para que eles desempenhem suas funções continuará sendo reduzido, mas não
eliminará o risco. A divisão de funções e menos privilégios/acesso são princípios que contribuem com a meta de
um provedor de nuvem para proteger e aumentar os ativos de informação da organização. Um programa de
gerenciamento de segurança em nuvem requer a designação das responsabilidades e funções-chave que possam
ser realizadas individualmente ou em grupos. Essas funções e responsabilidades devem ser formalmente
definidas na estrutura da política de segurança da informação da organização e formalmente revisadas e
aprovadas pela administração, alinhadas com os deveres e responsabilidades da sua Governança de Riscos e
Conformidade (do inglês Governance Risk and Compliance - GRC) fiduciária.
Além disso, o desenvolvimento efetivo da segurança do RH deve incluir os contratos de trabalho e de

confidencialidade, a verificação de antecedentes (quando legalmente permitido) e a contratação nos termos
jurídicos e nas práticas rescisórias. As medidas adicionais a serem consideradas, caso sejam aplicadas em todas as
áreas da organização, incluem as descrições formais de cargos, a formação adequada, as habilitações de
segurança, a rotatividade de tarefas e as férias obrigatórias para os funcionários em cargos de confiança ou de
alto risco.
7.3 Avaliação da segurança do CSP
Alguns dos riscos de segurança associados com a computação em nuvem são únicos, em parte devido à custódia
de uma cadeia de dados estendidos centralizada e, estão neste contexto, a continuidade de negócios, a
recuperação de desastres e, os ambientes de segurança tradicional de um provedor de serviços em nuvem e,
precisam ser avaliados detalhadamente e em relação aos padrões do setor.
A segurança tradicional ou física das instalações do provedor dos serviços de computação em nuvem é
importante e precisa ser cuidadosamente avaliada a partir de diversos parâmetros. Esta é uma área de maior
similaridade - os requisitos de segurança de um centro de dados em nuvem e de um não em nuvem são bastante
semelhantes.

Uma visão holística e a compreensão do modelo ou da filosofia das "pessoas, processos, tecnologia" do CSP
ajudaria imensamente a avaliar a maturidade do CSP e levantaria questões em aberto no tocante à segurança que
precisam ser resolvidas, aprovadas e fechadas antes de dar continuidade.
A maturidade e a experiência organizacional contribuem muito para o tratamento efetivo dos programas de
segurança física e eventuais contingências que possam surgir. Invariavelmente, há um forte elemento humano
envolvido na administração efetiva de programas de segurança física. O nível de apoio ao gerenciamento e o
poder da liderança em segurança são fatores significativos para proteger os ativos da companhia, sendo crucial o
suporte do gerenciamento.
A segurança física é geralmente a primeira barreira contra o acesso não autorizado, bem como ao autorizado aos
ativos físicos de uma organização, ao roubo físico de registros, aos segredos comerciais, à espionagem industrial e
à fraude.
7.3.1 Procedimentos
Os provedores de serviços em nuvem devem garantir que os seguintes documentos estejam disponíveis para
consulta a pedido dos clientes:
 Verificação de antecedentes (uma vez por ano) por fornecedores terceirizados
 Acordos de não divulgação
 Implantar "é preciso saber" e "é preciso ter" políticas para o compartilhamento de informações
 Divisão de funções
 Administração de acesso do usuário
 Definição das descrições de cargos (funções e responsabilidades)
 Sistema de controle de acesso funcional
 Verificações de acesso do usuário
7.3.2 Guardas de segurança
Sempre que forem necessários o monitoramento e a intervenção humana, o pessoal de segurança física
composto por guardas, supervisores e diretores devem ser alocados nas instalações do CSP durante 24 horas por
dia.
Entre outras coisas, o local e o posto devem obedecer às seguintes instruções:
 Verificar os funcionários, os agentes contratados, as credenciais de visitantes e utilização do registro de

login
 Emitir e resgatar os crachás dos visitantes
 Limitar a utilização não autorizada pelos funcionários
 Lidar com os visitantes e o movimento dentro da instalação

 Atender chamadas telefônicas relevantes à segurança
 Monitorar as intrusões, os sistemas de detecção de incêndios e enviar pessoal para atender aos alarmes
 Controlar a movimentação dos materiais dentro e fora do edifício e fazer cumprir os regulamentos de
invasão de propriedade
 Fazer cumprir as regras e os regulamentos estabelecidos para o edifício
 Patrulhar internamente as instalações
 Monitorar o sistema de CFTV
 Gerenciar e controlar as chaves
 Executar os procedimentos de atendimentos de emergência
 Apontar os problemas relacionados à segurança para o gerente de segurança
 Recepcionar e expedir a correspondência
 Acompanhar dentro do escritório os visitantes da empresa que estiverem desacompanhados
7.3.4 Segurança ambiental
As instalações do CSP devem proteger tanto o pessoal como os ativos, implantando controles de proteção do
meio ambiente contra os riscos ambientais. Estes controles podem incluir, mas não estão limitados a, os
controladores de temperatura e umidade, os detectores de fumaça e o sistema de extinção e combate a incêndio.
7.3.4.1 Controladores ambientais
 O centro de dados deve estar munido com equipamentos de suporte ambiental específicos, conforme
publicado pelas normas internas e a legislação ou regulamentação local e/ou regional, incluindo uma
fonte de alimentação ininterrupta de emergência.
 Os equipamentos/dispositivos necessários para os controles ambientais devem estar protegidos para

reduzir os perigos e os riscos de ameaças ambientais e para reduzir o risco de acesso não autorizado à
informação.
7.3.4.2 Proteção e localização dos equipamentos
Os seguintes controles devem ser considerados para os sistemas classificados como contendo informações
restritas ou confidenciais:
 O equipamento deve estar localizado em um local fisicamente seguro para minimizar o acesso
desnecessário.
 Monitorar as condições ambientais que podem afetar negativamente o funcionamento dos sistemas de
computador, como por exemplo, a umidade.
 A equipe de segurança deve considerar o impacto potencial de um desastre ocorrer em locais próximos,
por exemplo, um incêndio em um prédio vizinho, um vazamento de água no telhado ou em pisos abaixo
do nível do solo ou uma explosão na rua.

 Os métodos para destruir completamente e eliminar a mídia descartada (por exemplo, unidades de disco)
7.3.4.3 Manutenção dos equipamentos
Para garantir a disponibilidade e integridade contínua dos equipamentos, é realizada sua manutenção adequada
com base nos controles de manutenção do equipamento, que compreendem:
 Realizar a manutenção do equipamento de acordo com os intervalos recomendados pelo fornecedor e

especificações
 Permitir que apenas o pessoal autorizado da manutenção execute os reparos e serviços nos
equipamentos
 Manter registros de falhas suspeitas ou reais e de toda a manutenção preventiva e corretiva.
 Utilizar os controles apropriados ao enviar equipamentos para manutenção fora das instalações. Embalar
e a vedar os recipientes, armazenar em lugares seguros e protegidos e fornecer instruções de envio e
rastreamento claras e completas são exemplos de controles adequados.
 Uma adequada manutenção de políticas e procedimentos de controle de ativos que incluam a

conservação dos registros de todo o hardware, firmware e software, engloba o rastreamento, a
responsabilidade e a propriedade
Uma revisão completa das instalações do CSP permite que o cliente em prospecção compreenda e avalie a
maturidade e a experiência do programa de segurança. Com o foco na segurança de TI, a segurança física
geralmente recebe uma atenção limitada. No entanto, devido à variedade de cenários de ameaça que hoje
prevalece, é imperativo que a segurança física receba a devida atenção, especialmente em um ambiente onde os
dados de determinados clientes podem ser corresidentes com uma série de outros clientes (incluindo
concorrentes) e, assuma uma maior importância. A segurança física é uma das muitas interligadas linhas de
defesa contra intrusos e sabotadores corporativos que queiram acessar as instalações de um CSP para fins
nefastos.
7.4 Continuidade dos negócios
Tradicionalmente, os três princípios da segurança da informação são a confidencialidade, a integridade e a

disponibilidade. A continuidade dos negócios trata o componente de continuidade desses três requisitos. A
transição para um provedor de serviços de nuvem inclui uma avaliação do tempo de atividade que o provedor
assume contratualmente. No entanto, este Contrato de Nível de Serviço (SLA) pode não ser suficiente para
satisfazer o cliente. Deve ser feita consideração para o potencial impacto caso ocorra uma queda significativa.
Baseado em recentes interrupções de serviço de alto nível nos serviços de terceiros provisionados, os autores
sugerem que manter a continuidade do serviço é uma dependência crítica para manter as operações nos
negócios.
As seguintes diretrizes devem ser consideradas no tocante à manutenção da continuidade de um determinado

serviço. Embora muitas dessas orientações provavelmente se apliquem aos serviços provisionados internamente,
como fazem para os serviços provisionados de terceiros (por exemplo, em nuvem), elas são escritas com o
pretexto de que a responsabilidade recaia sobre o terceiro.

7.5 Recuperação de desastres
Um dos aspectos mais interessantes do armazenamento em nuvem para o TI é como ele pode ser aproveitado
para backup e recuperação de desastres (do inglês Disaster Recovery - DR). O backup da nuvem e os serviços de
DR são direcionados para reduzir o custo da infraestrutura, das aplicações e processos de negócios em geral. O
backup da nuvem e a DR devem focar em tornar a proteção dos dados confiável, acessível e fácil de gerenciar. Os
desafios para o armazenamento em nuvem, o backup em nuvem e a DR em particular, envolvem a mobilidade, a
transferência de informações de e para a nuvem e, a disponibilidade garantindo a continuidade dos negócios de
forma ideal, escalável e com pagamento por medição. As soluções de recuperação de desastres em nuvem são
edificadas sobre o alicerce de três fundamentos: uma infraestrutura de armazenamento totalmente virtual, um
sistema de arquivos escalável e uma aplicação de autosserviço de recuperação de desastres convincente e que
atenda aos requisitos urgentes de negócios dos clientes. As operações de recuperação de desastres dos clientes
em transição para a nuvem devem verificar a existência das seguintes organizações ou equipes dentro do
programa de recuperação de desastres do provedor de serviços:
 Equipe de atendimento de emergência (do inglês Emergency Response Team (ERT))
 Equipe de gerenciamento de crises
 Equipe de resposta a incidentes
A composição das equipes acima deve ser analisada em detalhes, juntamente com o procedimento de
comunicação de crises.
7.5.1 Prioridades de restauração
Verifique o plano de restauração documentado dos provedores de serviços: Este plano deve incluir os detalhes
sobre as prioridades relativas à sequência de restauração. Ele deve estar correlacionado diretamente com o SLA,
como contratualmente comprometido, com relação aos serviços adquiridos pelo cliente e à criticidade do serviço.
O plano de recuperação deve incorporar e quantificar o Objetivo do Ponto de Recuperação RPO40 (do inglês
Recovery Point Objective) e o Objetivo do Tempo de Restauração RTO41 (do inglês Recovery Time Objective) para
os serviços.
Detalhe os controles de segurança da informação que são considerados e implantados durante o processo de
restauração que devem contemplar por exemplo:
 As folgas dos funcionários envolvidos durante o processo de restauração
 Os controles de segurança física implantados em um local alternativo
 Dependências relevantes especificadas para o processo de restauração (fornecedores e parceiros

terceirizados)
 Distância mínima da localização do local secundário, se o local principal ficar indisponível
40
RPO - Objetivo do ponto de recuperação
41
RTO - Objetivo do tempo de recuperação

7.6 Permissões
 Garanta um projeto de instalações adequado.
 Adote sistemas de segurança física e lógica integrados que reforcem um ao outro.
 Estabeleça contratos de nível de serviço que requeiram a sucessão das obrigações de segurança de
trabalho e responsabilidades por níveis recentes da cadeia de suprimentos.
7.7 Recomendações
7.7.1 Recomendações de políticas
o Os provedores de nuvem devem considerar a adoção de uma linha de base de segurança para atender
aos mais rigorosos requisitos de qualquer cliente, de modo que os sistemas, as instalações e os
procedimentos estejam em um alto nível do sistema. À medida que essas práticas de segurança não
impactem negativamente na experiência do cliente, as rigorosas práticas de segurança devem ser
comprovadamente rentáveis e poder ser quantificadas pela redução do risco para o pessoal, a receita, a
reputação e para os valores aos acionistas.
o Alternativamente, os provedores podem abranger um conjunto de usuários com requisitos de segurança

mais baixos, ou oferecer um nível de base para todos os clientes com potencial de vendas adicionais e
implantar medidas adicionais àqueles que os valorizam. Neste último caso, é preciso reconhecer que
alguns clientes só estarão interessados nos provedores que entregam uma segurança elevada e uniforme.
Este balanceamento inclui sistemas, instalações e procedimentos documentados.
o Os profissionais devem ter uma vigorosa compartimentalização das funções do trabalho, realizar as
verificações de antecedentes, exigir e fazer cumprir os acordos de confidencialidade pelos funcionários e,
restringir o conhecimento dos funcionários a um privilégio mínimo do que precisam saber dos clientes.
7.7.2 Recomendações de transparência
o Deve ser requerida uma postura transparente do CSP em relação à segurança. A visita no local da
instalação ou do centro de dados do CSP ajudará a realizar uma avaliação imediata e ter uma
compreensão clara das diversas medidas de segurança que foram postas em prática. Entretanto, em
função dos aspectos sob demanda do provisionamento e de multilocatário da computação em nuvem, as
formas tradicionais de auditoria e avaliação poderão estar indisponíveis ou precisarão ser modificadas
(por exemplo, o acesso a uma inspeção de terceiros compartilhada).
o Para melhorar a eficácia da avaliação no local, a visita à instalação ou ao centro de dados do CSP deve ser
realizada sem aviso prévio (ou caso seja necessário informar o CSP, passe uma ampla e aberta
programação ao invés de horários específicos). Isto possibilitará ter uma avaliação real em um dia normal
de trabalho no local e, não dará oportunidade ao CSP de "manter as aparências" durante uma visita do
cliente ou de terceiros.
o Quando for realizar a inspeção direta, devem participar da equipe de avaliação dois ou mais especialistas
dos setores de TI, Segurança da Informação, Continuidade de Negócios, Segurança Física e de
Gerenciamento (por exemplo, chefes de departamento ou proprietários de dados).

o Os clientes devem solicitar e adquirir, antes da visita, a documentação de planejamento da continuidade

de negócios e de recuperação de desastres, incluindo as certificações relevantes (por exemplo, conforme
as normas ISO, ITIL42) e os relatórios de auditoria e protocolos de teste.
7.7.3 Recomendações dos recursos humanos
o Os consumidores devem verificar se o CSP implanta pessoal de segurança com competência para as suas
funções de segurança física. É altamente recomendado ter um dedicado gerente de segurança para
proporcionar a liderança necessária e até dirigir o programa de segurança física. As principais certificações
do setor, como o Certificado de Sistemas de Informação de Auditoria (do inglês Certified Information
Security Auditor - CISA43) , o Certificado de Sistemas de Informação do Profissional de Segurança (do
inglês Certified Information Security Security Professional - CISSP44) , o Certificado de Sistemas de
Informação do Gerente (do inglês Certified Information Security Manager - CISM45) , ITIL, ou o Certificado
de Privacidade Profissional (do inglês Certified Privacy Professional CPP46) da Sociedade Americana de
Segurança Industrial (do inglês American Society for Industrial Security - ASIS47) seriam úteis para
validação do histórico de conhecimentos e habilidades do operador na segurança física.
o Os consumidores devem requerer uma verificação minuciosa da estrutura apresentada pelo gerente de
segurança. Isso ajudará a determinar se a posição que lhe foi dada está relacionada à importância e as
responsabilidades. O gerente de segurança deve se reportar a um superior e, se houver, ao Comitê de
GRC. Ele não deve informar aos facilitadores ou ao setor de TI. Seria melhor se essa posição se reportasse
ao presidente (do inglês Chief Executive Office - CEO) ou através de outra hierarquia (por exemplo, pelo
diretor de reestruturação (do inglês Chief Restructuring Officer - CRO) ou pelo presidente do conselho) em
termos de independência e objetividade da posição.
7.7.4 Recomendações de continuidade dos negócios
o O cliente deve verificar o contrato de compromissos de terceiros para manter a continuidade do serviço
provisionado. Porém, o cliente deve considerar veementemente fazer uma análise mais aprofundada.
Normalmente o cliente age como o controlador de dados e, onde a informação pessoal é mantida é
improvável que sejam os requisitos regulatórios específicos para assegurar que os controles adequados
sejam empregados. Esses requisitos se aplicam mesmo no caso de ser utilizado um processador de dados
terceirizado.
o O cliente deve verificar o processo de Continuidade de Negócios do terceiro e qualquer tipo de

certificação específica. Por exemplo, o CSP pode adotar e obter a certificação pela BS 25999, que é a
norma inglesa para o Gerenciamento da Continuidade de Negócios (do inglês British Standard for Business
Continuity Management - BCM). O cliente pode querer verificar o escopo da certificação e os detalhes
documentados da avaliação.
o O cliente deve realizar uma avaliação no local da instalação do CSP para confirmar e verificar a utilização
dos controles mencionados para manter a continuidade do serviço. Pode não ser totalmente necessário
42
ITIL - Biblioteca da infraestrutura da tecnologia de informação
43
CISA - Certificado de sistemas de informação de auditoria
44
CISSP - Certificado de sistemas de informação do profissional de segurança
45
CISM - Certificado de sistemas de informação do gerente
46
CPP - Certificado de privacidade profissional
47
ASIS - Sociedade americana de segurança industrial

realizar sem prévio aviso essa avaliação da instalação do CSP com o único propósito de verificar os
controles BCP específicos, já que normalmente esses controles só são ativados caso venha a ocorrer
algum desastre/evento.
o O cliente deve certificar-se de receber a confirmação de todos os testes de BCP/DR realizados pelo CSP.
Embora muitas das recomendações já mencionadas focassem nas assertivas documentadas de que o
serviço manterá a continuidade, o verdadeiro teste destes é em um incidente significativo. Sem esperar
que ocorra um desastre real, o cliente deverá insistir na importância de obter a confirmação formal dos
testes de BCP/DR e, de saber se os testes satisfazem os compromissos constantes nos SLAs.
7.7.5 Recomendações de recuperação de desastres
o Os clientes de nuvem não devem depender de um provedor único de serviços e devem ter um plano de
recuperação de desastres no local que facilite a migração ou um “substituto de falha” (do inglês failover)
caso um provedor falhe.
o Os provedores de IaaS devem ter acordos contratuais com provedores de múltiplas plataformas e dispor
de ferramentas no local para restabelecer rapidamente os sistemas em caso de perda.
o A validação de dados deve ser um protocolo de validação automatizado ou iniciado pelo usuário que
permite ao cliente verificar os seus dados a qualquer momento para garantir a integridade dos dados.
o Em intervalos definidos pelo usuário para cada sistema, os backups incrementais devem atualizar
frequentemente uma réplica de todos os sistemas protegidos ou instantâneos e, então, o consumidor
determinará as configurações de acordo com o ponto de recuperação objetivo.
o Todo o local, o sistema, o disco e os arquivos de recuperação devem estar acessíveis através de um portal
de autosserviço orientado ao usuário, que lhe permitirá a flexibilidade de escolher qual disco do arquivo
ou do sistema deseja recuperar.
o O provedor de nuvem deve implantar uma rápida recuperação de dados baseado no SLA.
o O SLA deve ser negociado previamente e, o cliente deve pagar o necessário pelo SLA para garantir que
não haja conflito de interesses. Nenhum dado, arquivo ou disco de sistema, deve demorar mais de 30
minutos para ser recuperado.
o A otimização da WAN entre o cliente e o local físico devem estar em um lugar em que a nuvem permita a
mobilidade completa dos dados na largura de banda reduzida, a utilização do armazenamento e o
custeio.
7.8 Requisitos
 Todas as partes devem garantir um projeto estrutural adequado para a segurança física.
 Todos os participantes da cadeia de suprimentos devem respeitar a interdependência de soluções de

impedimentos, detecção e autenticação.
 Os consumidores finais devem inspecionar, responder por e, corrigir os riscos de pessoal, herdados de
outros membros da cadeia de suprimentos em nuvem. Eles também devem elaborar e implantar medidas

ativas para minimizar e conter os riscos com o pessoal através de uma adequada separação de deveres e
um privilégio de acesso mínimo.

DOMÍNIO 8 //
OPERAÇÃO DE CENTROS DE PROCESSAMENTO DE DADOS
Para haver uma evolução da computação em nuvem os provedores devem fazer os centros de processamento de
dados progredirem para além do simples uso da virtualização para o gerenciamento de ativos. Para permitir a
agilidade nos negócios, a tecnologia denominada verde, a abertura dos provedores, o surgimento de ideias cada
vez mais originais para a geração de energia e para a construção a e gestão de centros de processamento de
dados, tais centros precisam obter sucesso no longo prazo.
O "Centro de Processamento de Dados de Nova Geração", um termo que vem sendo usado há vários anos, tem
crescido nas operações de centros de processamento de dados que incluem a acomodação de soluções de
Business Intelligence, levando em conta que as aplicações em execução e a exigência de hospedagem de grandes
aglomerados analíticos também estão evoluindo.
Visão Geral. Esse domínio trata dos seguintes tópicos:
 Considerações sobre segurança física, como relacionadas na Considerações sobre a CCM e como
Cloud Control Matrix (CCM) novas ideias em termos de centros de
 Mapeamento de casos de uso de centros de processamento de processamento de dados de
dados automatizados computação em nuvem afetam uns
 O novo centro de processamento de dados? A computação em aos outros
nuvem em casa
 A disseminação da infraestrutura de computação em nuvem e o centro de processamento de dados
8.1 Operação de Centros de Processamento de Dados
Novos conceitos nessa seção:
 Missão da aplicação na computação em nuvem. É a missão do negócio ou do aplicação alojado no centro

de processamento de dados como, por exemplo, a missão de uma aplicação da área de saúde ou de
comércio eletrônico
 Disseminação dos centros de processamento de dados. Infraestruturas de computação em nuvem que
operam juntas, mas estão em locais separados fisicamente
A automação baseada em serviços e a análise preditiva para permitir esse tipo de automação têm sido
representados há muito tempo pelo Information Technology Service Management 48 (ITSM), utilizando os padrões
do Information Technology Infrastructure Library49 (ITIL) para a evolução dos centros de processamento de dados.
Aplicações de diferentes tipos alojadas nos centros de processamento de dados necessitam de automação e
aquelas usadas para a operação dos mesmos trazem muitos benefícios ao terem habilidades para a compreensão
de tudo que está sendo executado e como tais centros, como um todo, precisam responder às variações de uso.
A matriz de controle da Cloud Security Alliance tem uma série de requisitos em termos de segurança física que
são baseados em diferentes padrões e requisitos regulatórios. O domínio relacionado com a segurança física
nesta versão do guia, bem como a matriz de controles devem ser lidos pelos profissionais dos centros de
48
ITSM – Information Technology Service Management
49
ITIL – Information Technology Infrastructure Library

processamento de dados para a obtenção de uma compreensão das necessidades internas e externas de tais
centros. Para referência, a tabela a seguir ilustra controles necessários em centros de processamento de dados
em função da missão das aplicações alojadas nos mesmos. A tabela não é exaustiva, mas fornece alguns exemplos
que referenciam, de forma cruzada, a matriz de controle e especificações para um tipo de aplicação ou uma
missão.
Tabela 1 – Missão da Aplicação em Função do Controle
MISSÃO DE APLICAÇÃO CONTROLE ESPECIFICAÇÃO

Políticas e procedimentos devem ser
Instalações de Segurança – estabelecidos para manterem um ambiente de
Assistência Médica (HIPAA50)
Política de Segurança trabalho seguro em escritórios, salas, instalações
e áreas seguras.
Processamento de O acesso físico a ativos e funções informacionais
Instalações de Segurança –
Cartão/Pagamentos por usuários e pessoal de apoio deve ser
Acesso do Usuário
(PCI51) restringido.
Perímetros de segurança física (cercas, muros,
barreiras, guardas, portões, vigilância eletrônica,
Instalações de Segurança –
Geração de Energia (NERC mecanismos de autenticação física, portarias e
Pontos Controlados de
CIP52) patrulhas de segurança) devem ser implantados
Acesso
para proteger os dados sensíveis e os sistemas de
informação.
A lista acima não pretende ser exaustiva e o leitor pode verificar a matriz para constatar quais normas ou
regulamentos a organização deseja seguir.
Uma aplicação em execução no centro de processamento de dados que contenha informações regulatórias
(regido sob um padrão de segurança da informação ou de segurança de aplicações) será auditado. O resultado de
auditorias físicas realizadas pelos operadores de centro de processamento de dados pode ser publicado para os
clientes ou incluído em uma infraestrutura de consulta, como previsto pela Cloud Audit.
Em versões anteriores do guia o leitor foi instruído a realizar suas próprias auditorias, mas para muitos
operadores de centros de processamento de dados ou provedores de serviços de computação em nuvem tal
prática pode não ser fisicamente possível. Em ambientes com múltiplos clientes o operador ou prestador de
serviços, normalmente, não pode acomodar as visitas de cada cliente para a realização de uma auditoria e, nesse
caso, o cliente deve exigir o fornecimento de resultados de auditorias independentes.
Essa ideia vem da automação de serviços e automatizar relatórios, registros de log e a publicação de resultados
de auditorias feitas pelos operadores dos centros de processamento de dados pode fornecer aos clientes
evidências de que, com base na missão de aplicação, os controles específicos de tais centros são adequados e
satisfatórios. A Cloud Audit, o Cloud Trust Protocol e, o CYBEX (X.1500) podem automatizar a publicação dos
resultados da auditoria através de uma interface comum.
Uma automação mais significativa dos centros de processamento de dados baseia-se na biblioteca que contém os
ativos sendo alojados. Ao entender como os ativos dessa biblioteca usam os recursos de tais centros, o
gerenciamento das operações pode prever quais clientes estão usando recursos. Se os centros de processamento
50
HIPAA – Healthcare Information Portability and Protection Act
51
PCI – Payment Card Industry. Specifically PCI DSS, which is Data Security Standard
52
NERC CIP – North American Electric Reliability Corporation Critical Infrastructure Protection

de dados usam conceitos como PoD53 e centros virtuais de processamento de dados VMDC54, então os mesmos
são o mais ágil possível no fornecimento de computação em nuvem ou de virtualização.
8.1.1 Modelos Novos e Emergentes
Recentemente (no segundo semestre de 2011) houve mais notícias sobre ambientes próprios de computação em
nuvem. Nesses tipos de ambientes, formulados após o projeto SETI@home55, um ecossistema de computação em
nuvem é baseado nos ativos de computação de voluntários que cedem os computadores das próprias
casas/escritórios para suportarem aplicações. Os centros de processamento de dados, nesses casos, são as casas
de cada um dos voluntários e esses ambientes de computação em nuvem funcionam muito bem como
ecossistemas comunitários de hospedagem de aplicações, mas não como ambientes regulados onde padrões
devem ser usados para auditorias. Se um ambiente desse tipo está hospedado em 100.000 computadores
domésticos, por exemplo, não há maneira de auditar um centro de processamento de dados que está
fragmentado em 100.000 pedaços espalhados por uma grande área geográfica. Uma infraestrutura desse tipo é
adequada para hospedar um conjunto de aplicações de caráter comunitário, com base nos interesses dos
participantes (clube do livro, por exemplo) ou um site doméstico.
A computação em nuvem está, cada vez mais, sendo vista como commodity. Há esforços da indústria para criar a
“Segurança como um Serviço” ou criar agentes de infraestruturas para identidade, interoperabilidade e
continuidade de negócios, entre outras. O aplicação está sendo separado e colocado em ambientes físicos
especializados, que focam em necessidades específicas de uma organização ou das aplicações que executam.
A disseminação de centros de processamento de dados leva o aplicação e o coloca em muitos centros

especializados de processamento de dados que abrigam e gerenciam necessidades específicas. Difundir o
aplicação além das próprias fronteiras físicas é mais simples na computação em nuvem, porém mais difícil de
controlar e de gerenciar.
8.2 Permissões
 Disseminação da colaboração entre centros de processamento de dados. A automação, tendo que se

estender por vários centros de processamento de dados não relacionados fisicamente, demandará
software para orquestrar o que tais centros necessitarão para o registro e a geração de relatórios durante
as auditorias
 Ambientes próprios de computação em nuvem onde o centro de processamento de dados é pessoal. As
auditorias normativas e de conformidade são quase impossíveis nesses casos. Ambientes regulados e
baseados em padrões enfrentarão dificuldades com ambientes particulares ou pessoais, em função dos
controles necessários porque pode haver situações ou casos onde alguma parte de uma aplicação possa
ser disseminada para a infraestrutura de ambientes dessas naturezas
8.3 Recomendações
o As organizações que estão construindo centros de processamento de dados para a computação em

nuvem devem incorporar processos de gestão, práticas e softwares para serem capazes de
compreenderem e reagirem à tecnologia em uso
53
PoD – Point of Delivery (Ponto de Entrega). Um conjunto composto por unidades intercambiáveis de energia, computação,
acesso, armazenamento e componentes de rede
54
VMDC – Virtual Multi-tenant Data Center (Centro de Processamento de Dados Virtual para Múltiplos Clientes). Um
conceito que usa componentes modulares facilmente intercambiáveis para a expansão rápida de um centro de
processamento de dados, tais como PoDs
55
SETI@home – http://setiathome.berkeley.edu

o As organizações compradoras dos serviços de computação em nuvem devem garantir que o prestador de
serviços adotou processos e práticas de gerenciamento de serviços nos centros de processamento de
dados e, também, que adotou soluções para assegurar a alta disponibilidade e a agilidade na alocação de
recursos dentro de tais centros
o Entenda a missão daquilo que está sendo colocado no centro de processamento de dados. Levando em
conta os controles na Cloud Control Matrix, os centros de processamento de dados que estiverem sendo
construídos ou adquiridos devem atender os requisitos de segurança física e dos ativos
o A localização dos centros de processamento de dados são importantes. Se os componentes de tecnologia
e aplicação estão espalhados entre os mesmos, haverá latência
o As organizações compradoras de serviços de computação em nuvem devem entender e documentar
quem é responsável pelo atendimento de requisitos de conformidade, bem como os papéis que elas
mesmas e os provedores de serviços de computação em nuvem exercem quando o assunto é a avaliação
de conformidade
8.4 Requisitos
A Cloud Security Alliance tem muitas fontes de informação para ajudar na construção ou na remodelação de
centros de processamento de dados para a computação em nuvem e a matriz de controles destaca requisitos de
um conjunto muito amplo de normas e de regulamentos de segurança. O Cloud Audit e outros projetos da CSA
também podem ajudar na construção e na gestão de centros de processamento de dados, bem como da
tecnologia em funcionamento dentro deles.
 Compreenda plenamente os requisitos da Control Matrix, baseando-se no que vai ser executado no
centro de processamento de dados e use um denominador comum que satisfaça a maioria das missões
das aplicações
 Utilize técnicas de gerenciamento de serviços de TI para garantir a disponibilidade, a segurança e a gestão

de ativos e de entregas
 Caso o centro de processamento de dados seja de propriedade de um provedor, audite-o usando modelos
regulatórios e de segurança padronizados e publique os resultados para os clientes

DOMÍNIO 9 //
RESPOSTA A INCIDENTES
A resposta a incidentes (do inglês Incident Response - IR) é um dos pilares do gerenciamento de segurança da
informação. Mesmo com o planejamento mais diligente, a implantação e a execução dos controles de segurança
preventivos não podem eliminar completamente a possibilidade de um ataque aos ativos de informação. Uma
das questões principais para as organizações que se mudam para a nuvem deve ser: o que deve ser feito para
possibilitar uma gestão eficiente e efetiva dos incidentes de segurança que envolvem os recursos em nuvem?
A computação em nuvem não requer uma nova estrutura conceitual para a resposta a incidentes, mas requer que
a organização mapeie adequadamente os seus programas de IR existentes, os processos e as ferramentas para o
ambiente operacional específico que ela adota. Isto é consistente com a orientação que é encontrada ao longo
deste documento; de forma similar, deve ser realizada uma análise das brechas de controles que abrangem a
função de IR das organizações.
Este domínio visa identificar essas brechas pertinentes ao IR, que são criadas pelas características únicas da
computação em nuvem. Os profissionais de segurança podem utilizá-lo como uma referência no desenvolvimento
de planos de atendimento e realização de outras atividades durante a fase de preparação do ciclo de vida do IR.
Para compreender os desafios que a computação em nuvem representa para o tratamento de incidentes,
devemos examinar quais são os desafios que as características especiais da computação em nuvem e os diversos
modelos de implantação e de serviços apresentam para o tratamento de incidentes.
Este domínio está organizado de acordo com o Ciclo de Vida da Resposta a Incidentes (do inglês Incident
Response Lifecycle) aceito normalmente, conforme descrito no Guia de Tratamento de Incidentes de Segurança
da Computação do Instituto Nacional de Padrões e de Tecnologia (do inglês National Institute of Standards and
Technology Computer Security Incident Handling Guide) (NIST 800-61) [1]. Depois de estabelecer as características
da computação em nuvem que impactam no IR mais diretamente, cada seção subsequente aborda uma fase do
ciclo de vida e explora as considerações possíveis para os atendentes.
Visão geral. Este domínio tratará dos seguintes tópicos:
 O impacto da resposta a incidentes na computação em nuvem
 O ciclo de vida da resposta a incidentes
 A responsabilidade jurídica

9.1 As características do impacto da resposta a incidentes na computação em nuvem
Embora a computação em nuvem cause alterações em muitos níveis, determinadas características [2] da
computação em nuvem enfrentam desafios mais diretos às atividades de IR do que outras [3].
Em primeiro lugar, um cliente em nuvem pode achar que é difícil ou mesmo impossível receber do seu provedor
de serviços de nuvem (CSP)56 a cooperação exigida ao lidar com um incidente de segurança, pela natureza do
autosserviço ser sob demanda nos ambientes da computação em nuvem. A interação com a função do IR pelo
CSP irá variar dependendo do serviço e dos modelos implantados utilizados. De fato, o quanto em capacidades de
detecção, análises, contenção e recuperação de incidentes de segurança são projetados para oferecer os serviços,
são questões fundamentais para o provedor e o cliente resolverem.
Em segundo lugar, a conjunção dos recursos praticados pelos serviços em nuvem, além da rápida flexibilidade
oferecida pelas infraestruturas em nuvem, pode complicar dramaticamente o processo de IR, especialmente às
atividades periciais conduzidas como parte da análise do incidente. A perícia tem que ser conduzida em um
ambiente altamente dinâmico, que desafia as necessidades periciais básicas [4], de modo a estabelecer o escopo
de um incidente, coletar e atribuir os dados, preservar a integridade semântica desses dados e manter a
estabilidade das provas como um todo. Estes problemas são agravados quando os clientes em nuvem tentam
conduzir as atividades periciais, por conta de operarem em um ambiente que não é transparente (o que reitera a
necessidade de apoio por parte do provedor de nuvem, como acima mencionado).
Em terceiro lugar, a conjunção dos recursos praticada por serviços em nuvem causa preocupações quanto à
privacidade dos multilocatários em relação a coletar e analisar a telemetria e os objetos associados a um
incidente (por exemplo, registros de dados, dados do NetFlow, memória, imagens de máquinas, armazenamento
etc.), sem comprometer a privacidade dos multilocatários. Este é um desafio técnico que deve ser tratado
fundamentalmente pelo provedor. Cabe aos clientes em nuvem garantir que o seu provedor de serviços de
nuvem disponha de medidas adequadas de coleta e separação de dados e que possa fornecer o apoio necessário
à resposta a incidentes.
Em quarto lugar, apesar de não estar descrita como uma característica essencial da nuvem, a computação em
nuvem pode conduzir a dados que cruzam fronteiras geográficas ou de jurisdições, sem o conhecimento explícito
desse fato pelo cliente na nuvem. As implicações legais e regulatórias subsequentes podem afetar negativamente
o processo da resposta a incidentes, colocando limitações sobre o que pode ou não ser feito e/ou prescrever o
que deve ou não deve ser feito durante um incidente em todas as fases do ciclo de vida [5]. É aconselhável que
uma organização inclua representantes de seu departamento jurídico à equipe de resposta a incidentes, para
orientar sobre estas questões.
A computação em nuvem apresenta também oportunidades para atendentes de incidentes. Os sistemas de

monitoramento contínuo em nuvem podem reduzir o tempo que leva para conduzir a resposta a incidentes ou
entregar um atendimento melhorado para um incidente. As tecnologias de virtualização e a flexibilidade
inerentes às plataformas de computação em nuvem, possibilitam uma contenção e uma recuperação mais
eficiente e efetiva, com menos interrupção do serviço, do que normalmente ocorrem com as tecnologias mais
tradicionais dos centros de dados. Além disso, a investigação de incidentes será mais fácil sob alguns aspectos, já
que as máquinas virtuais podem ser facilmente movidas para ambientes de laboratório, para realizar a análise de
tempo de execução e coletar e analisar as imagens periciais.
56
CSP - Provedor de serviços em nuvem

9.2 O modelo de arquitetura da segurança em nuvem como uma referência
Na sua maioria, os modelos de implantação e de serviços ditam a divisão do trabalho quando se trata de IR no
ecossistema de nuvem. Utilizar os controles para análises da estrutura arquitetônica e de segurança preconizados
no Domínio 1 (vide o Modelo de referência em nuvem da Figura 1.5.2a) pode ser valioso para identificar quais
componentes técnicos e de processos são de propriedade de qual organização e em qual nível da "pilha".
Os modelos de serviços em nuvem (IaaS, PaaS, SaaS) diferem consideravelmente no quanto de visibilidade e
controle um cliente tem, dos sistemas de TI subjacentes e de outras infraestruturas que proporcionam o
ambiente de computação. Isto tem implicações em todas as fases da resposta a incidentes assim como todos os
outros domínios deste guia.
Por exemplo, em uma solução de SaaS as atividades de atendimento provavelmente ficam quase que totalmente
a cargo do CSP, enquanto que na IaaS, um maior grau de responsabilidade e capacidade para detectar e atender a
incidentes de segurança podem ficar a cargo do cliente. Porém, mesmo na IaaS existem significativas
dependências do CSP. Os dados dos hosts físicos, dispositivos de rede, serviços compartilhados, dispositivos de
segurança tipo firewalls e quaisquer sistemas de gerenciamento de "backplanes” devem ser fornecidos pelo CSP.
Alguns provedores já estão se capacitando para fornecer esta telemetria para os seus clientes e, os provedores de
serviços de segurança gerenciados estão anunciando soluções baseadas em nuvem para receber e processar estes
dados.
Dado à complexidade, o modelo de controle de segurança descrito no Domínio 1 (na Figura 1.5.1c) e, as
atividades que uma organização realiza para mapear os controles de segurança para a sua implantação em uma
determinada nuvem, devem informar o planejamento de IR e vice-versa. Tradicionalmente, os controles de IR
têm se preocupado mais estreitamente com os requisitos organizacionais de alto nível; porém, para serem
verdadeiramente efetivos, os profissionais de segurança devem ter uma visão mais holística. Os responsáveis pelo
IR devem estar totalmente integrados na seleção, aquisição e implantação de qualquer controle técnico de
segurança que ainda possam, direta ou indiretamente afetar o atendimento. No mínimo, este processo pode
ajudar no mapeamento de funções/responsabilidades durante cada fase do ciclo de vida do IR.
Os modelos de implantação em nuvem (pública, privada, híbridos, comunitários) também são considerações a
serem feitas ao verificar as capacidades de IR em uma implantação em nuvem; a facilidade de acesso aos dados
de IR varia para cada modelo de implantação. Deve ser evidente que aqui também exista a mesma continuidade
de controle/responsabilidade. Neste domínio, a principal preocupação é quanto ao término de uma continuidade
mais pública. Os autores assumem que quanto mais privada a nuvem, mais controle o usuário terá para
desenvolver os controles de segurança apropriados, ou que estes controles sejam fornecidos por um provedor
para a satisfação do usuário.
9.3 O exame do ciclo de vida da resposta a incidentes
O NIST 800-61 [1] descreve as seguintes fases principais do ciclo de vida do IR: preparação; detecção e análise;
contenção, erradicação e recuperação. Esta seção examina os desafios específicos da computação em nuvem
para estas fases e fornece as recomendações de como vencer estes desafios.

9.3.1 Preparação
A preparação pode ser a fase mais importante do ciclo de vida de resposta a incidentes quando as informações de
ativos são implantadas em nuvem. Identificar os desafios (e as oportunidades) para o IR deve ser um projeto
formal empreendido por profissionais de segurança da informação dentro da organização do cliente em nuvem
antes da migração para a nuvem. Devem ser consultados especialistas externos caso o nível de especialistas em IR
dentro da organização seja considerado insuficiente. Este exercício deve ser realizado durante cada atualização
do plano de resposta a incidentes da empresa.
As questões levantadas e as sugestões apresentadas em cada fase do ciclo de vida discutido a seguir podem servir
para informar o processo de planejamento do cliente. Integrar os conceitos discutidos em um plano formalmente
documentado servirá para direcionar as atividades certas para corrigir eventuais brechas e tirar proveito de todas
as oportunidades.
A preparação começa com um entendimento claro e completo de onde os dados do cliente residem, em
movimento e em repouso. Dado que os ativos de informação do cliente podem atravessar as fronteiras
organizacionais e, provavelmente, as fronteiras geográficas, é necessário modelar as ameaças tanto no plano
físico como no lógico. Os diagramas de fluxo de dados que mapeiam os ativos físicos e o mapa organizacional, a
rede e os limites de jurisdição podem servir para realçar as dependências que podem surgir durante um
atendimento.
Uma vez que várias organizações estão envolvidas, os acordos de nível de serviço (SLA57) e, os contratos entre as
partes se tornaram agora o principal meio de comunicação e de pressão às expectativas de responsabilidades em
cada fase do ciclo de vida do IR. É aconselhável compartilhar os planos de IR com outras partes envolvidas para
definir e esclarecer com precisão a terminologia compartilhada ou pouco clara. Sempre que possível, quaisquer
ambiguidades devem ser esclarecidas antes de um incidente.
Não é razoável esperar que os CSPs criem planos de IR separados para cada cliente. Porém, a existência de alguns
(ou todos) dos seguintes pontos de um contrato/SLA deve dar à organização do cliente alguma confiança, que o
seu provedor tenha feito algum planejamento avançado para a resposta a incidentes:
 Pontos de contato, canais de comunicação e disponibilidade de equipes de RI para cada parte;
 Definições e critérios de notificação de incidentes, tanto do fornecedor para o cliente, como para
quaisquer entidades externas;
 O suporte do CSP ao cliente para detecção de incidentes (por exemplo, dados de eventos disponíveis,
notificação sobre eventos suspeitos etc.);
 Definição de funções e responsabilidades durante um incidente de segurança, especificando

explicitamente o suporte para a resposta a incidentes fornecido pelo CSP (por exemplo, apoio pericial via
coleta de dados de incidentes/objetos, participação/suporte na análise de incidentes etc.);
 Especificação de testes regulares de IR realizado pelas partes no contrato e se os resultados serão

compartilhados;
 O espoco das atividades post-mortem (por exemplo, análise de raiz do problema, relatório de IR,
integração das lições aprendidas no gerenciamento de segurança etc.);
57
SLA – Acordo de Nível de Serviço (Service Level Agreements)

 A identificação clara de responsabilidades em torno do IR entre o provedor e o consumidor como parte

do SLA.
Uma vez determinadas as funções e as responsabilidades, o cliente agora pode fornecer recursos, treinar e
equipar adequadamente os seus atendentes de incidentes para que lidem com as tarefas de sua direta
responsabilidade. Por exemplo, se uma aplicação controlada pelo cliente reside em um modelo PaaS e o provedor
de nuvem concordou em fornecer (ou permitir a obtenção de) o registro específico da plataforma; é uma
necessidade óbvia ter as tecnologias/ferramentas e o pessoal disponível para receber, processar e analisar esses
tipos de registros. Para a IaaS e a PaaS, a capacitação com a virtualização e os meios para realizar perícias e outras
investigações em máquinas virtuais será parte integrante de qualquer esforço de atendimento. Decidir se um
determinado conhecimento exigido é organizacional para a empresa do cliente ou é terceirizado para um terceiro
é algo a ser determinado durante a fase de preparação. Observe que a terceirização demanda então o
gerenciamento de outro conjunto de contratos/contratos de confidencialidade (NDAs)58.
Os canais de comunicação devem ser preparados entre todas as partes envolvidas. As partes devem considerar os
meios pelos quais as informações restritas são transmitidas entre as partes, para garantir que os canais fora de
banda (do inglês out-of-band) estejam disponíveis e que os sistemas de criptografia sejam utilizados para garantir
a integridade e a autenticidade da informação. A comunicação durante o IR pode ser facilitada com a utilização
das normas existentes com a finalidade de compartilhar indicadores de compromisso ou de envolver ativamente
outra parte em uma investigação. Por exemplo, a norma do formato de substituição da descrição do objeto
incidente (do inglês Incident Object Description Exchange Format) (IODEF)59 [6], bem como a norma associada da
defesa em tempo real na Internet (do inglês Real-time Inter-network Defense) (RID)60 [7,8] que foi desenvolvida
na força-tarefa de engenharia da Internet (do inglês Internet Engineering Task Force) (IETF)61 e são também
incorporadas no projeto da Substituição da Segurança Cibernética (do inglês Cybersecurity Exchange) (CYBEX)62 da
União Internacional de Telecomunicações (do inglês International Telecommunication Union) (ITU)63. O IODEF
fornece um esquema XML padrão utilizado para descrever um incidente, a RID descreve um método padrão para
comunicar a informação de incidentes entre as entidades, que inclui pelo menos um CSP e um locatário.
A parte mais importante da preparação para um incidente é testar o plano. Os testes devem ser minuciosos e
mobilizar todas as partes que provavelmente estarão envolvidas durante um incidente real. É improvável que o
CSP tenha recursos para participar de testes com cada um dos seus clientes; portanto, o cliente deve considerar
fazer uma simulação, como forma de identificar quais tarefas ou pedidos de informação tendem a ser dirigidos ao
CSP. Esta informação deve ser utilizada para informar futuras discussões com o provedor durante a fase de
preparação. Outra possibilidade é a do cliente se voluntariar para participar de qualquer teste que o CSP possa ter
planejado.
9.3.2 Detecção e análises
A detecção oportuna de incidentes de segurança e o sucesso na análise subsequente ao incidente (o que

aconteceu, como aconteceu, quais os recursos estão afetados etc.) dependem da disponibilidade de dados
relevantes e da capacidade de interpretar corretamente os dados. Como acima mencionado, a computação em
nuvem oferece desafios em ambos os casos. Em primeiro lugar, a disponibilidade de dados depende em grande
58
NDA - Contrato de não divulgação
59
IODEF - Formato de substituição da descrição do objeto incidente
60
RID - Defesa em tempo real na Internet
61
IETF - Força-tarefa de engenharia da Internet
62
CYBEX - Substituição da segurança cibernética
63
ITU - União internacional de telecomunicações

parte do que o provedor de nuvem fornece ao cliente e pode ser limitada pela natureza altamente dinâmica da
computação em nuvem. Em segundo lugar, é complicado analisar, pelo fato de que a análise, pelo menos
parcialmente, diz respeito a uma infraestrutura não transparente de propriedade do cliente, que ele geralmente
tem pouco conhecimento e, de novo, pela natureza dinâmica da computação em nuvem, por meio da qual a
interpretação dos dados torna-se difícil e, às vezes até impossível.
Deixando de lado por um momento os desafios técnicos de análise de incidentes, a questão de como uma
investigação digital em nuvem deve ser conduzida, para maximizar o valor comprobatório (ou seja, a
credibilidade) da prova no momento da escrita, permanece em grande parte sem resposta. Assim, até que os
processos judiciais que envolvem incidentes em nuvem tornem-se lugar mais comum e existam orientações
amplamente aceitas como de melhores práticas, os resultados da análise de incidentes de segurança na nuvem
correm o risco de não pararem no tribunal.
Até as normas, os métodos e as ferramentas para a detecção e a análise de incidentes de segurança têm
apanhado com as evoluções técnicas introduzidas pela computação em nuvem e, a detecção de incidentes e as
análises permanecerão especialmente desafiadoras para os ambientes em nuvem. Os clientes em nuvem devem
enfrentar este desafio, garantindo que eles tenham acesso (1) às fontes de dados e às informações que são
relevantes para a detecção de incidentes/análises, bem como (2) o apoio pericial adequado para a análise de
incidentes no(s) ambiente(s) em nuvem eles estão utilizando.
9.3.3 Fontes de dados
Como em qualquer integração de serviços de TI hospedados, a equipe de IR deverá determinar o registro

adequado requerido para detectar apropriadamente eventos anômalos e identificar atividades maliciosas que
afetariam seus ativos. É imperativo para a organização do cliente, realizar uma avaliação de quais registros (e
demais dados) estão disponíveis, como são coletadas e processados e, finalmente, como e quando eles podem
ser entregues pelo CSP.
A principal fonte de dados para a detecção e subsequente análise de incidentes do lado cliente, é registrar as
informações. As seguintes questões relacionadas com o registro de informações devem ser consideradas:
 Quais informações devem ser registradas? Exemplos de tipos de registro que podem ser relevantes são
os registros de auditoria (por exemplo, de rede, de sistema, de funções de aplicações e de administração
de nuvem e de acessos, de backup e de restauração de atividades, de acesso à manutenção e de alteração
da atividade de gestão), os registros de erros (por exemplo, as mensagens do núcleo de hypervisors, dos
sistemas operacionais, das aplicações etc.), os registros específicos de segurança (por exemplo, os
registros de IDS, os registros do firewall etc.) e, os registros de desempenho etc. Fontes adicionais de
registros têm de ser negociados/acrescentados quando a informação de registro existente não for
suficiente.
 A informação registrada é consistente e completa? Um bom exemplo de informação de fonte de registro
inconsistente é a impossibilidade de sincronizar os relógios de fontes de registros. Similarmente, as
informações incompletas sobre o fuso horário em que a data e hora são gravadas em registros, torna
impossível interpretar corretamente os dados coletados durante a análise.
 A natureza dinâmica da nuvem está adequadamente refletida nas informações registradas? O
comportamento dinâmico de ambientes de nuvem também é uma razão frequente de registros
inconsistentes e/ou incompletos. Por exemplo, à medida que novos recursos de nuvem (VMs etc.) são
colocados on-line para atender a demanda, as informações de registro produzidas pela nova instância do
recurso terão de ser adicionadas ao fluxo de dados de registro. Outro problema provável é a

impossibilidade de fazer mudanças dinâmicas no ambiente, explícitas nas informações de registro. Por
exemplo, considere o caso de serem registrados requisitos de serviços da Web para um determinado
componente da PaaS, mas que possam ser atendidos dinamicamente por uma das diversas instâncias
desse serviço. As informações incompletas sobre a questão de qual instância serviu quais requisitos, pode
então dificultar uma análise adequada ou impossível, por exemplo, se a raiz do problema de um incidente
é uma única instância comprometida.
 Os requisitos legais em geral conferem? As questões de privacidade em relação a multilocatários, a
regulamentação referente aos dados de registro de informações gerais e em especial, de identificação
pessoal etc., podem apresentar limitações de coleta, de armazenamento e de utilização dos dados de
registro coletados. Estas questões regulatórias devem ser compreendidas e tratadas em cada jurisdição
onde os dados da empresa são processados ou armazenados.
 Quais padrões de registros de retenção são requeridos? Requisitos legais e de conformidade
direcionarão os padrões de registros de retenção específicos. Os clientes em nuvem devem compreender
e definir quaisquer padrões estendidos de registros de retenção para atender as suas necessidades ao
longo do tempo para apoiar seus requisitos de análises de incidentes/periciais.
 Os registros são invioláveis? Garantir a inviolabilidade dos registros armazenados é fundamental para a
precisão das análises jurídica e pericial. Considere a utilização de dispositivos de gravação única, a
separação de servidores utilizados para armazenar os registros dos servidores de aplicações e de
controles de acesso para os servidores de armazenamento de registros, como aspectos críticos deste
requisito.
 Em que formato as informações de registro são comunicadas? A normatização dos dados de registros é
um desafio considerável. O uso de formatos abertos (como o surgimento do CEE [9]) pode facilitar o
processamento do lado cliente.
O provedor de nuvem pode detectar apenas alguns incidentes que ocorrem dentro da infraestrutura de
propriedade dele. É importante observar que os SLAs devem ser acordados de modo que o provedor de nuvem
informe os clientes em nuvem em tempo hábil e de maneira confiável que permita executar o IR. Para outros
incidentes (talvez até detectáveis pelo cliente), o provedor de nuvem pode estar em uma posição melhor para a
detecção. Os clientes em nuvem devem selecionar os provedores de nuvem que melhor os auxiliem na detecção
de incidentes, correlacionando e filtrando os dados de registro disponíveis.
A quantidade de dados produzidos a partir da implantação em nuvem pode ser considerável. Pode ser necessário
investigar as opções do provedor de nuvem em relação às opções de filtragem de registro de dentro do serviço
em nuvem, antes de ser enviado para o cliente, para reduzir os impactos de processamento interno da rede e dos
clientes. Considerações adicionais incluem o nível de análises ou a correlação realizada pelo CSP e o locatário em
nuvem para identificar possíveis incidentes antes da perícia. Se a análise é realizada no CSP, o escalonamento e os
pontos de transição (do inglês hand-off points) para a investigação do incidente devem ser determinados.
9.3.4 Suporte pericial e outros investigativos para análise de incidentes
Embora ainda imaturo, já estão em andamento dentro da comunidade de peritos, os esforços para desenvolver as
ferramentas e os protocolos para recolher e examinar os objetos periciais derivados, especialmente de ambientes
virtuais; o suporte pericial exigido para os ambientes de PaaS e de SaaS também é assunto para o curso das
investigações.
É importante que o cliente entenda os requisitos periciais para a realização das análises de incidentes, investigue
até que ponto o CSP atende a esses requisitos, escolha um CSP em conformidade e aborde as brechas

remanescentes. A quantidade de potenciais evidências disponíveis para um cliente em nuvem diverge

consideravelmente entre os diferentes modelos de serviços em nuvem e de implantação.
Para os serviços de IaaS, os clientes podem executar investigações periciais das suas próprias instâncias virtuais,
mas não poderão investigar os componentes de rede controlados pelo CSP. Além disso, as atividades periciais
padrões, tais como a investigação do tráfego de rede em geral, o acesso aos instantâneos de memória, ou a
criação de uma imagem do disco rígido requerem o suporte investigativo a ser fornecido pelo CSP. As técnicas
periciais avançadas também habilitadas pela virtualização, como a geração de instantâneos de estados de
máquina virtual ou a introspecção de VM sobre os sistemas vivos, necessitam de suportes periciais pelo CSP.
Com os incidentes de segurança na PaaS e no SaaS que têm a raiz do problema na sua infraestrutura básica, o
cliente em nuvem é quase totalmente dependente do suporte de análise do CSP e, como mencionado
anteriormente, as funções e as responsabilidades do IR devem ser acordados nos SLAs. Na PaaS, a organização do
cliente será responsável por quaisquer códigos da camada de aplicação que são implantados para a nuvem. Basta
o registro do aplicação que é requerido para a análise de incidentes em cenários onde a raiz do problema
encontra-se dentro do aplicação (por exemplo, uma falha no código do aplicativo). Neste caso, o apoio do CSP
poderia ser na forma de facilitar a geração do registro do aplicativo, o armazenamento e o acesso seguro através
de uma API do tipo somente leitura [10]. Os provedores do SaaS que geram extensos registros de aplicações
específicos do cliente e fornecem o armazenamento seguro, bem como as instalações de análises, aliviarão a
carga do IR sobre o cliente. Isto pode reduzir consideravelmente os níveis de incidentes em aplicações.
Os provedores que utilizam seu gerenciamento de “backplanes”/sistemas para acessar um incidente e identificar
as partes de um sistema que tem estado ou estão sob ataque e fornecer os dados para o cliente em nuvem, irá
melhorar o atendimento em todos os modelos de serviço.
Para se preparar para as análises de incidentes em um determinado ambiente em nuvem, a equipe de IR do

cliente deve se familiarizar com ferramentas de informação que o fornecedor de nuvem fornece para auxiliar as
operações e os processos de IR dos seus clientes. Artigos da base de dados de conhecimento, perguntas e
respostas frequentes (FAQs), matrizes de diagnóstico de incidentes etc., podem ajudar a preencher a lacuna de
experiência que um cliente em nuvem terá no que diz respeito à infraestrutura de nuvem e suas normas de
funcionamento. Esta informação pode, por exemplo, ajudar a equipe de IR diferenciar as questões operacionais
efetivas e incidentes dos eventos de segurança.
9.3.5 Contenção, erradicação e recuperação
Tal como acontece com as outras fases da resposta a incidentes, a estreita coordenação com todas as partes
interessadas é requerida para garantir que as estratégias desenvolvidas para conter, erradicar e recuperar um
incidente sejam eficazes, eficientes e levar em consideração todas as implicações legais e de privacidade. As
estratégias devem também ser consistentes com os objetivos dos negócios e procurar minimizar a interrupção do
serviço. Isto é consideravelmente mais difícil quando múltiplas organizações estão envolvidas no atendimento,
como é o caso da computação em nuvem.
As opções para esta fase serão diferentes, dependendo do modelo de implantação e do serviço e também da
camada da pilha em que o ataque foi deflagrado. Pode haver múltiplas estratégias que podem ser empregadas,
possivelmente por diferentes entidades, equipadas com diferentes soluções tecnológicas. Se for possível, pense
realizar simulações na fase de preparação, para antecipar esses cenários e um processo de resolução de conflitos
identificados. Os clientes também devem considerar como o seu provedor lidará com incidentes que afetam ele

próprio ou outros locatários, em uma plataforma compartilhada, além de incidentes que estejam diretamente
direcionados à sua própria organização.
Os consumidores de IaaS são os principais responsáveis pela contenção, erradicação e recuperação de incidentes.
As implantações em nuvem podem aqui, ter alguns benefícios. Por exemplo, isolam imagens impactadas sem
destruir evidências que possam ser obtidas pela pausa destas imagens. Como discutido na introdução, a relativa
facilidade com que os nós podem ser encerrados e, novas instâncias podem ser criadas, pode ajudar a minimizar a
interrupção do serviço quando uma correção de código precisar ser implantada. Se houver problemas com uma
determinada IaaS em nuvem, o cliente pode então ter a opção de mudar o serviço para outra nuvem,
especialmente se eles têm implantado uma das soluções de gerenciamento de metanuvem.
A situação é mais complicada para implantações de SaaS e PaaS. Os consumidores podem ter pouca capacidade
técnica para conter um incidente no software ou na plataforma como um serviço, a não ser fechando o acesso do
usuário e a inspeção/limpeza de seus dados hospedados dentro do serviço antes de uma reabertura posterior.
Mas especialmente para o SaaS, mesmo essas atividades básicas podem ser difíceis ou impossíveis sem o suporte
adequado do CSP, tais como os mecanismos de controle de acesso de bloqueio refinado e acesso direto aos dados
dos clientes (e não via interface da Web).
Em todos os modelos de serviços, os provedores podem ajudar com certas categorias de ataque, como uma
recusa de serviço (do inglês Denial of Service) (DoS)64. Por exemplo, as pequenas empresas podem se beneficiar
de economias de escala, o que permite tecnologias de minimização mais caras, como a proteção de DoS, a ser
estendida para os seus sites. Assim como nas fases anteriores, deve ser identificado na fase de preparação a que
ponto e quais instalações do provedor serão colocadas à disposição do cliente para ajudar a atender um ataque.
Além disso, as condições que o fornecedor é obrigado a dar assistência para atender a um ataque devem ser
definidas contratualmente.
O SLA e o plano de IR devem ser flexíveis o suficiente para acomodar uma atividade de "Lições Aprendidas" após a
recuperação. Deve ser redigido e compartilhado um relatório detalhado do incidente, baseado nas atividades de
IR com partes afetadas, ou seja, entre o cliente em nuvem, o CSP e outras organizações envolvidas/afetadas. O
relatório de incidentes deve incluir a linha do tempo do incidente, a análise da raiz do problema ou da
vulnerabilidade, as medidas tomadas para minimizar os problemas e restaurar o serviço e as recomendações para
ações corretivas de longo prazo.
As ações corretivas são como uma mescla do suporte específico do cliente e do provedor e a equipe de resposta a
incidentes do provedor deve fornecer uma seção com a sua perspectiva sobre o incidente e a resolução proposta.
Após uma análise inicial do relatório do incidente pelo cliente e pelo CSP, devem ser realizadas discussões
conjuntas para desenvolver e aprovar um plano de reparação.
9.4 Recomendações
o Os clientes em nuvem devem entender como o CSP define eventos de interesse versus incidentes de
segurança e quais eventos/incidentes o provedor de serviços de nuvem informa para o cliente em nuvem
e de que maneira. As informações sobre o evento que são fornecidas através de um padrão aberto
podem facilitar o processamento destes relatórios no lado cliente.
o Os clientes em nuvem devem criar vias de comunicação adequadas com o CSP que possam ser utilizadas
em caso de um incidente. Os padrões abertos existentes podem facilitar a comunicação de incidentes.
64
DoS - Recusa de serviço

o Os clientes em nuvem devem compreender o apoio do CSP para as análises de incidentes, especialmente
a natureza (conteúdo e formato) dos dados que o CSP fornecerá para fins de análise e o nível de interação
com a equipe de resposta a incidentes do CSP. Em especial, deve-se avaliar se os dados disponíveis para a
análise do incidente satisfazem os requisitos legais em investigações periciais que possam ser relevantes
para o cliente em nuvem.
o Especialmente no caso de IaaS, os clientes em nuvem devem favorecer o CSP no aproveitamento das
oportunidades que a virtualização oferece para a análise pericial e a recuperação de incidentes, tais como
o acesso/reversão de instantâneos de ambientes virtuais, introspecção de máquina virtual etc.
o Os clientes em nuvem devem favorecer os CSPs no aproveitamento do hardware de virtualização assistida

e dos hypervisors calejados com capacidades analíticas periciais.
o Para cada serviço em nuvem, os clientes em nuvem devem identificar as classes de incidentes mais
relevantes e preparar estratégias para a contenção, erradicação e recuperação de incidentes; deve-se
assegurar que cada provedor de nuvem possa fornecer a assistência necessária para executar essas
estratégias.
o Os clientes em nuvem devem obter e verificar o histórico de resposta a incidentes de um CSP. Um CSP
pode fornecer recomendações do setor sobre o seu IRP de clientes já existentes.
9.5 Requisitos
 Para cada provedor de serviço de nuvem que é utilizado, a abordagem para a detecção e o tratamento de
incidentes envolvendo os recursos hospedados naquele provedor deve ser planejado e descrito no plano
de resposta a incidentes da empresa.
 O SLA que é utilizado por cada provedor de nuvem de serviço deve garantir o suporte ao tratamento de
incidentes requerido para a execução eficaz do plano de resposta a incidentes da empresa para cada
etapa do processo de tratamento de incidentes: detecção, análise, contenção, erradicação e recuperação.
 Os testes serão conduzidos pelo menos anualmente. Na medida do possível, os clientes devem procurar
integrar seus procedimentos de testes com os do seu provedor (e de outros parceiros). O ideal é que uma
equipe (que inclui o cliente e os membros do CSP) deve realizar vários testes de controle para um plano
de resposta a incidentes e em sequência, as sugestões devem ser implantadas em uma nova versão do
plano de resposta a incidentes.

REFERÊNCIAS
[1] GRANCE, T., KENT, K. e, KIM, B. Computer Security Incident Handling Guide. NIST Special Publication 800-61.
[2] MELL, P. and GRANCE, T. The NIST Definition of Cloud Computing, NIST Special Publication 800-145.
[3] GROBAUER, B. and SCHRECK, T. October 2010. Towards Incident Handling in the Cloud: Challenges and
Approaches. In Proceedings of the Third ACM Cloud Computing Security Workshop (CCSW), Chicago, Illinois.
[4] WOLTHUSEN, S. 2009. Overcast: Forensic Discovery in Cloud Environments. In Proceedings of the Fifth
International Conference on IT Security Incident Management and IT Forensics.
[5] REED, J. 2011. Following Incidents into the Cloud. SANS Reading Room
[6] DANYLIW, R., et al. 2007. The Incident Object Description Exchange Format, IETF Internet Draft RFC 5070.
[7] MORIARTY, K. 2010. Real-time Inter-network Defense, IETF Internet Draft RFC 6045.
[8] MORIARTY, K., and TRAMMELL, B. 2010. Transport of Real-time Inter-network Defense (RID) Messages, IETF
Internet Draft RFC 6046.
[9] FITZGERALD, E., et al. 2010. Common Event Expression (CEE) Overview. Report of the CEE Editorial Board.
[10] BIRK, D. and WEGENER, C. 2011. Technical Issues of Forensic Investigations in Cloud Computing Environments
In Proceedings of 6th International Workshop on Systematic Approaches to Digital Forensic Engineering
(IEEE/SADFE), Oakland, CA, USA.

DOMÍNIO 10 //
SEGURANÇA DE APLICAÇÕES
Os ambientes em nuvem, ambientes em nuvem pública em particular, em virtude da sua flexibilidade e abertura,
desafiam muitas suposições fundamentais sobre a segurança de aplicações. Algumas dessas suposições são bem
compreendidas, apesar de muitas não o serem. Esta seção tem como objetivo fornecer orientações sobre como a
computação em nuvem influencia a segurança durante o tempo de vida de um aplicativo, desde o projeto até a
sua desativação completa. Esta orientação é para todos os interessados (incluindo designers de aplicações,
profissionais de segurança, pessoal operacional e de gerenciamento técnico) quanto a melhor forma de minimizar
os riscos e gerenciar garantias ao projetar aplicações para a computação em nuvem.
A computação em nuvem é um desafio considerável para aplicações em camadas de software como um serviço
(SaaS), plataforma como um serviço (PaaS) e infraestrutura como um serviço (IaaS). As aplicações baseados em
nuvem exigem um rigor de design semelhante ao de uma aplicação que conecta à Internet, - a segurança deve ser
fornecida pelo aplicação sem quaisquer suposições que estão sendo feitas sobre o ambiente externo. Porém, as
ameaças às quais as aplicações estarão expostos em um ambiente em nuvem serão mais numerosas do que
aquelas experimentadas em um centro de dados tradicional. Isso cria a necessidade de serem seguidas práticas
rigorosas durante o desenvolvimento ou a migração de aplicações para a nuvem.
Visão geral. Este domínio sobre a segurança de aplicações foi organizado nas seguintes áreas de atuação:
 Um seguro SDLC65 (práticas gerais para o ciclo de vida de desenvolvimento de software seguro e nuances
específicas para a nuvem)
 Autenticação, autorização, conformidade, - a arquitetura da segurança de aplicações na nuvem
 A identidade e o consumo de identidade que está relacionado com a segurança de aplicações em nuvem
 Processos de titularidade e de gerenciamento de acesso em função do risco relacionados à criptografia

em nuvem de aplicações baseados em nuvem
 Gerenciamento de autorização de aplicações (política de autorização/atualização, cumprimento)
 Teste de invasão de aplicações na nuvem (práticas gerais e nuances específicas para aplicações baseadas
em nuvem)
 Monitoramento de aplicações na nuvem
 A autenticação de aplicações, a conformidade e o gerenciamento de riscos e as repercussões de

multilocatários e da infraestrutura compartilhada
 A diferença entre evitar software malicioso e fornecer segurança de aplicações
65
SDLC - Ciclo de vida de desenvolvimento de software

10.1 Um SDLC seguro (ciclo de vida de desenvolvimento de software)
Um ciclo de vida de desenvolvimento de software seguro (SSDLC) (também referido por alguns como o ciclo de
vida de desenvolvimento seguro (SDLC)) tem ganhado uma crescente importância na migração e na implantação
de aplicações na nuvem. As organizações devem garantir que as melhores práticas de segurança de aplicações, de
gerenciamento de identidade, de gerenciamento de dados e de privacidade sejam parte integrante dos seus
programas de desenvolvimento e durante todo o ciclo de vida do aplicativo.
Desenvolver para um ambiente em nuvem é diferente que desenvolver para os ambientes de hospedagem
tradicionais, nas seguintes situações:
 O controle sobre a segurança física é substancialmente reduzido em cenários de nuvem pública.
 A potencial incompatibilidade entre os fornecedores quando os serviços, como por exemplo o

armazenamento, migram de um fornecedor para outro.
 A proteção de dados deve ser considerada através do ciclo de vida. Isso inclui o transporte, o
processamento e o armazenamento.
 As combinações de serviços da Web no ambiente em nuvem têm o potencial de causar a presença de

vulnerabilidades de segurança.
 A possibilidade de acessar registros, especialmente em uma nuvem pública compartilhada, é mais difícil e
deve ser especificada como parte do contrato de nível de serviço.
 O “substituto de falha” (fail-over) para os dados e a segurança dos dados em nuvem tem de ser mais
detalhado e disposto em mais camadas do que os ambientes tradicionais.
 Geralmente é mais difícil assegurar (e demonstrar evidências para) a conformidade às relevantes

regulamentações do setor e governamentais em um ambiente em nuvem.
Ao implantar uma SSDLC, as organizações devem adotar as melhores práticas para o desenvolvimento, seja por
uma boa mescla de processos, ferramentas e tecnologias próprias ou através de um dos modelos de maturidade
como estes:
 Modelo de maturidade para construir segurança (do inglês Building Security In Maturity Model - BSIMM2)
 Modelo de maturidade de segurança de software (do inglês Software Assurance Maturity Model - SAMM)
 Modelo de maturidade de segurança de sistemas de capacidade de engenharia (do inglês Systems

Security Engineering Capability Maturity Model - SSE-CMM)
10.1.1 Programa de garantia de segurança de aplicações
As organizações devem ter um programa de garantia de segurança de aplicações que garanta às aplicações que
estão sendo migrados e/ou desenvolvidos e mantidos em um ambiente de nuvem, o seguinte:
 Que as metas e as métricas sejam definidas, implantadas e monitoradas com o suporte executivo
adequado;

 Que uma segurança e uma política de privacidade para as aplicações na nuvem que foram estabelecidas
para atender os requisitos legais e regulatórios de conformidade estejam alinhados com as necessidades
de negócios e as obrigações regulatórias da organização;
 Que a capacidade adequada e a capacidade para garantir a segurança estejam disponíveis dentro da
organização para arquitetar, projetar, desenvolver, testar e implantar aplicações seguras, pela formação
adequada de recursos integrados em tempo hábil;
 Que as avaliações de riscos de segurança e privacidade sejam realizadas para todas as aplicações, para
garantir que os requisitos estejam corretamente definidos;
 Que os processos para garantir os requisitos de segurança e privacidade para o processo de

desenvolvimento e manutenção na nuvem sejam definidos e implantados;
 Que a configuração e o gerenciamento de mudanças sejam controláveis e verificáveis;
 Que sejam realizadas as avaliações de risco de segurança física para o aplicação e para os dados e, que o
acesso a todos os componentes da infraestrutura em nuvem seja adequado para atender essas
exigências;
 Que sejam seguidas durante a fase de desenvolvimento as melhores práticas da codificação formal,
considerando-se os pontos fortes e fracos da linguagem utilizada;
 Que as medidas de segurança e privacidade sejam controláveis e verificáveis.
10.1.2 Verificação e validação
10.1.2.1 Verificação do projeto
Algumas funções de segurança são mais sensíveis que outras, podendo não ser candidatas viáveis para execução
em nuvem e devem ser consideradas quando forem especificados os projetos de aplicações específicos e os
requisitos.
Os seguintes princípios devem ser seguidos para desenvolver um projeto seguro para o aplicativo. Quando estes
princípios não puderem ser atendidos por uma arquitetura de nuvem, eles devem ser reparados por controles
técnicos e/ou por compensação apropriados. A viabilidade de uma implantação em nuvem será questionada caso
isso não seja feito.
 Privilégios mínimos. Este princípio sustenta que devam ser dados os privilégios e os recursos mínimos a
um indivíduo, processo ou outro tipo de entidade, para o mínimo período de tempo necessário para
concluir uma tarefa. Em muitos casos, os privilégios mínimos só podem ser implantados de forma eficaz
utilizando um refinado gerenciamento de autorização de aplicativo, contextual com mecanismos de
automação de políticas de segurança66.
 Divisão de funções. Esta é uma política de controle segundo a qual, a ninguém deve ser atribuída a
responsabilidade ou o acesso a mais de uma função relacionada.
 Defesa em profundidade. Este é a aplicação de múltiplas camadas de proteção no qual uma camada
subsequente oferece proteção caso a camada anterior seja violada.
66
www.policyautomation.org

 À prova de falhas. Se um sistema de nuvem falhar ele deve falhar de uma maneira na qual a segurança do
sistema e de seus dados não seja comprometida. Por exemplo, assegurar os padrões do sistema para um
estado tal, que seja negado o acesso ao sistema a um usuário ou processo.
 Economia de mecanismo. Isso promove o projeto e a implantação de simples e compreensíveis
mecanismos de proteção, para que os caminhos de acesso não intencional não existam ou possam ser
facilmente identificados e eliminados.
 Mediação completa. Este é onde todas as solicitações de acesso a um objeto em um sistema de
computador por uma entidade67 devem ser autorizadas.
 Projeto aberto. Este é um projeto de sistema em nuvem de acesso aberto que tem sido avaliado e
analisado por uma comunidade de especialistas, resultando em um projeto mais seguro.
 Mecanismo mínimo comum. Isto estabelece que um número mínimo de mecanismos (especialmente os
mecanismos de proteção) deve ser comum em várias aplicações, minimizando a capacidade de uma
aplicação corromper ou subverter outro aplicativo.
 O elo mais fraco. É importante identificar os mecanismos mais fracos da cadeia de segurança e das
camadas de defesa e fortalecê-los de modo que os riscos para o sistema sejam reduzidos a um nível
aceitável.
10.1.3 Construção
10.1.3.1 Verificação do código
É recomendado definir e acompanhar o desenvolvimento de software seguro ao nível da organização. As

diretrizes mencionadas nas práticas fundamentais para o desenvolvimento de software seguro poderiam ser
seguidas pelas normas SAFECode68, CERT (SEI)69 ou ISO.
A análise dinâmica do código examina como o código é executado em uma aplicação em nuvem em execução,
com um testador rastreando as interfaces externas no código fonte para as interações correspondentes no código
em execução, de modo que qualquer vulnerabilidade ou anomalias que surgem nas interfaces de execução, que
se encontrem simultaneamente no código-fonte, possam ser corrigidas.
Ao contrário da análise estática, a análise dinâmica permite que o testador exercite o software para expor
vulnerabilidades introduzidas pela interação com os usuários e as alterações na configuração ou
comportamentais dos componentes do ambiente.
Algumas das melhores práticas para escrever um código de segurança e verificá-lo estão listadas abaixo:
 As informações mínimas necessárias devem ser incluídas no código do servidor em nuvem. Os

comentários devem ser retirados do código operacional e, os nomes e outras informações pessoais
devem ser evitados;
 Utilize ferramentas de análise de código fonte para verificar se há erros típicos de programação, como
estouros de buffer, ataques a cadeias de caracteres de formato, as condições de corrida etc.;
67
Uma entidade poderia ser um usuário, um código, um dispositivo, uma organização ou um agente
68
http://www.safecode.org/
69
https://www.cert.org/secure-coding/

 Verifique e valide todas as entradas, usuários, computadores e intersistemas. A injeção de conteúdo e de

muitos outros ataques é possível quando a infraestrutura em nuvem pega qualquer entrada e aplica o
conteúdo daquela entrada nos comandos ou nas instruções SQL;
 Ao utilizar um código de objeto (binários), por exemplo, onde as bibliotecas terceirizadas estão sendo
utilizadas, utilize um serviço de teste capaz de testar a vulnerabilidade estática no código de objeto.
10.1.3.2 Testar a segurança
O teste de invasão é uma metodologia de teste de segurança que dá ao testador uma noção da força da
segurança da rede alvo, pela simulação de um ataque de uma fonte maliciosa. O processo envolve uma análise
ativa do sistema de nuvem para qualquer vulnerabilidade possível que possa resultar de uma configuração fraca
ou imprópria do sistema, de falhas de hardware ou software conhecidas e/ou desconhecidos, ou de deficiências
operacionais de contramedidas técnicas ou de processo. Esta análise é conduzida a partir da posição de um
possível invasor e pode envolver a exploração ativa de vulnerabilidades de segurança.
O tipo de modelo de nuvem tem um enorme impacto sobre os testes de invasão ou em decidir se o teste de
invasão é possível. Geralmente, a plataforma como um serviço (PaaS) e a infraestrutura como um serviço (IaaS)
em nuvem são susceptíveis em permitir os testes de invasão. No entanto, os provedores de software como um
serviço (SaaS) não são susceptíveis em permitir que os clientes testem invasões em suas aplicações e
infraestrutura, com a exceção de terceiros que realizam os próprios testes de invasão de provedores de nuvem,
para as melhores práticas de conformidade ou de segurança.
Os testes de invasão são conduzidos tipicamente dentro de um cenário de "caixa preta", ou seja, sem o
conhecimento prévio da infraestrutura a ser testada. O teste de invasão envolve três fases no seu nível mais
simples:
1. Preparação. Nesta, é onde é executado um contrato formal com cláusulas de confidencialidade dos dados
do cliente e de proteção legal para o testador. No mínimo ela lista os endereços de IP a serem testados.
2. Execução. Nesta fase, o teste de invasão é executado com o testador à procura de possíveis
vulnerabilidades.
3. Entrega. Os resultados da avaliação são comunicados para o contato do testador na organização quando
então, são informadas as medidas corretivas.
Após o relatório e a obtenção dos resultados, as técnicas para reduzir o risco de comprometimento a um nível
aceitável ou tolerável devem ser aplicadas, quer seja o teste de invasão um teste de conhecimento completo
(caixa branca), um teste de conhecimento parcial (caixa cinza) ou um teste de conhecimentos zero (caixa preta). O
escopo do teste deve ser o mais amplo possível para solucionar vulnerabilidades e os riscos correspondentes a
áreas como as aplicações, os sistemas de acesso remoto e os outros ativos de TI relacionados.
10.1.3.3 Testes de interoperabilidade
O teste de interoperabilidade avalia se uma aplicação em nuvem pode trocar dados (interoperar) com outros
componentes ou aplicações. Os testes das atividades de interoperabilidade determinam a capacidade das
aplicações trocarem dados através de um conjunto comum de formatos de troca, para ler e editar os mesmos
formatos de arquivo e, para se comunicar utilizando os mesmos protocolos.
Um dos principais objetivos dos testes de interoperabilidade é detectar problemas de interoperabilidade entre
aplicações de software em nuvem antes que essas aplicações sejam colocadas em operação. O teste de
interoperabilidade requer a finalização da maioria das aplicações antes que ele possa ser feito.

Além de testar a interoperabilidade, os testes devem confirmar que todas as trocas de dados, os protocolos e as
interfaces utilizadas estão utilizando transferências seguras de informações.
O teste de interoperabilidade utiliza normalmente uma das três seguintes abordagens:
1. Testar todos os pares. Isso é realizado com frequência por um grupo independente terceirizado de
testadores que têm conhecimento das características da interoperabilidade entre produtos de software e
fornecedores de software.
2. Testar algumas das combinações. Estes envolvem testar apenas uma parte das combinações e assumir
que as combinações não testadas também interoperam.
3. Testar em relação a uma implantação referencial. Essa estabelece uma implantação referencial, isto é,
utiliza o padrão aceito e, testa todos os produtos em relação a essa referência.
10.1.4 Melhoria quantitativa
10.1.4.1 Métricas
Qualquer programa de garantia de segurança de aplicação deve coletar métricas que possam ser analisadas e
utilizadas para informar periodicamente o status do desenvolvimento seguro. A coleta e as informações das
métricas podem ser reforçadas à medida que qualquer programa de segurança de aplicações atinja mais
maturidade.
Algumas das métricas recomendadas são as seguintes:
 O percentual de ativos de aplicações e dados na nuvem avaliados para a classificação de risco no

trimestre e/ou no último ano;
 Os custos do programa de garantia de segurança de aplicações em um trimestre e/ou em um ano em um

projeto/programa para aplicações baseadas em nuvem;
 As estimativas de perdas passadas devido a questões de segurança, se houver alguma, nas aplicações que
estão sendo desenvolvidos e/ou implantados na nuvem.
10.1.4.2 A utilização de ferramentas e recursos de tecnologia de segurança automatizada SDLC
As atividades do SDLC centradas nas pessoas (processar, treinar e testar) são necessárias, mas nem sempre são
suficientes ou viáveis para uma boa segurança de aplicações. Onde forem viáveis, as ferramentas automatizadas
devem ser utilizadas para construir aplicações seguras e construir automaticamente a segurança em aplicações.
Tais ferramentas que geram automaticamente características técnicas de segurança estão frequentemente
vinculadas às ferramentas de desenvolvimento e integração/preparação. Por exemplo, as regras da política de
autorização de técnicas podem ser geradas automaticamente (no desenvolvimento/integração/na hora de
mesclar) a partir das especificações de requisitos de segurança pelas ferramentas que analisam as aplicações e
suas interações70.
Similarmente, alguns testes automatizados podem ser feitos na fase de desenvolvimento/integração e gerar
evidências de garantia da informação.
70
Este campo científico é chamado de “model-driven security”, consulte o site www.modeldrivensecurity.org

Isso pode ser feito na nuvem, na finalização pelo assinante durante o desenvolvimento ou durante a mescla
(especialmente para a IaaS), ou o provedor de nuvem pode fornecer a tecnologia (se necessário, o assinante pode
configurar), especialmente na plataforma de aplicações em nuvem da PaaS.
É provável que no SaaS, a maior parte da automação de segurança seja integrada, configurada e operada pelo
provedor de nuvem.
10.2 Autenticação, autorização, conformidade - arquitetura de segurança de aplicação

na nuvem
10.2.1 Desenvolvimento de serviços/aplicações em nuvem e desafios de negócios
Há novos riscos potenciais associados ao acesso aos dados confidenciais e aos sistemas. Uma compreensão clara
dos seguintes riscos de segurança dentro do ambiente de aplicação e de negócios é fundamental para abordar o
escopo completo das questões de segurança e de privacidade, relativos aos serviços e aplicações em nuvem:
 A falta de controle. Isto é quando os assinantes de nuvem normalmente não têm controle sobre as
políticas e controles de segurança em nuvem.
 A falta de visibilidade. Isto é quando os assinantes de nuvem normalmente não têm visibilidade sobre a
aplicação de políticas de segurança e controles de efetividade em nuvem.
 A falta de capacidade de gerenciamento. Isto é quando os assinantes de nuvem frequentemente não são
suficientemente capazes de gerenciar a segurança de aplicações em nuvem, especialmente as políticas de
acesso e de auditoria.
 Perda de governança. Isto é quando a organização pode não ter controle direto da infraestrutura e,
confia no provedor (às vezes uma confiança ingênua) e sua própria capacidade de fornecer a segurança
adequada, que é primordial.
 Risco de conformidade. Isto é quando o provedor de nuvem impacta na capacidade da organização de

cumprir as regulamentações, as expectativas de privacidade e as normas setoriais, porque podem existir
dados e sistemas fora do controle direto da organização.
 Falha de isolamento. Isso é quando o multilocatário e o compartilhamento de recursos são características

que definem a nuvem. Assim, é totalmente provável que empresas concorrentes utilizem os mesmos
serviços em nuvem e, consequentemente executem lado a lado seus trabalhos. É essencial manter a
memória, o armazenamento e o acesso à rede isolada.
 Proteção dos dados. Isto é quando a organização abandona o controle direto sobre os dados; ela
depende do provedor manter os dados seguros e, quando excluídos, o provedor deve garantir (ou poder
comprovar) que foram permanentemente destruídos.
 Interfaces de gerenciamento e configuração de acesso. As aplicações em nuvem são acessadas e

gerenciadas pela Internet e potencialmente envolvem complexos requisitos e controle. Portanto, o risco
associado a uma violação de segurança é maior e, a autorização de acesso adequada deve ser
cuidadosamente considerada.

10.2.2 Riscos técnicos e soluções
A maioria dos provedores de serviços em nuvem inclui no projeto do serviço de nuvem alguma forma de
identidade, titularidade e, gerenciamento de acesso (do inglês Identity, Entitlement, and Access Management -
IdEA)71. A autenticação e a autorização são frequentemente delegadas ao sistema de gerenciamento de usuários
do cliente utilizando uma norma da federação.
O suporte à identidade, à titularidade e ao gerenciamento de acesso impacta no cliente, em que a integração é

limitada pelo mecanismo de encaminhamento de credenciais. A infraestrutura, tais como a cobrança e as
medições, que dependem do gerenciamento de identidade, também apresenta integração e riscos de redução.
O suporte ao gerenciamento de identidade, titularidade e acesso tem implicações de integração para o cliente.
Estas implicações incluem o encaminhamento seguro de credenciais e atributos, o provisionamento de usuários
adicionais etc. As operações comerciais dentro do provedor de serviços em nuvem também são afetadas, essas
operações incluem a utilizações dos recursos de cobrança e de contabilidade. Como resultado, é importante
considerar a integração da identidade, da titularidade e do gerenciamento de acesso como uma parte essencial
do projeto.
As capacidades de IdEA do aplicação (ou a falta delas), como a capacidade de uma aplicação aceitar uma asserção
na SAML72, impactarão na governança dos serviços em nuvem, na integração e na experiência do usuário,
entendendo assim que os requisitos de IdEA de determinado aplicação em nuvem são uma parte crítica da
definição dos requisitos.
Os requisitos de IdEA típicos em um projeto de aplicação em nuvem incluem:
 Entender como o aplicação em nuvem fornecerá as contas para usuários, usuários avançados e,
administradores, - os gatilhos para isso poderiam ser links para os sistemas internos de RH ou para as
plataformas de RH baseadas em nuvem.
 O provisionamento de serviços em nuvem para a integração serviço a serviço, isto é, aplicações internas
para serviços baseados em nuvem;
 A capacidade de aceitar declarações e asserções (identificadores e atributos) de uma variedade de fontes

e entidades com base nas normas da federação (por exemplo, SAML, WS FED etc.);
 A capacidade de tomar decisões com base no risco de titularidade sobre o acesso para o aplicação em
nuvem, com base na identidade e nos atributos de todas as entidades (usuários, dispositivos, código,
organização, agentes) na cadeia;
 A rica linguagem de titularidade baseada em risco que conduz ao gerenciamento de acesso (de
autoria/distribuição/atualização etc.) para os recursos protegidos (ou seja, o que é permitido para cada
recurso);
 O suporte para os requisitos de conformidade de segurança interna e de política reguladora, como a

autenticação baseada em declarações ou em um controle de acesso mínimo baseado na função;
71
IdEA - Identidade, titularidade e, gerenciamento de acesso
72
SAML - Linguagem de marcação de asserção de segurança, um OASIS de padrão aberto de base XML, para troca de dados
de autenticação e autorização entre domínios de segurança

 O monitoramento de atividade de usuários, o registro e os relatórios ditados por políticas internas e de

conformidade regulatórias, como com a SOX, a PCI e a HIPAA.
Uma variedade de provedores de identidade ou de serviços podem gerar tokens para o cache da sessão, como os
tokens SAML, OpenID73, ou OAuth74, permitindo que uma capacidade passe para fazer login. As aplicações a
serem implantados em nuvem devem ter a capacidade de se integrar com estes serviços de
declarações/asserções e as aplicações/serviços devem ser projetados para suportar os padrões abertos para a
federação, ou seja, para a SAML, a OAuth, ou a OpenID.
O processo de gerenciamento da titularidade exigirá a capacidade para definir, gerenciar e acessar as regras de
controle de acesso às aplicações baseados em nuvem através de uma interface centralizada. Tal interface ou
serviço em si, poderia ser hospedado em nuvem ou internamente e pode aproveitar uma extensão de linguagem
de marcação padrão como a XACML75. Aqui, o principal desafio é a capacidade de gerenciamento: Com o
aumento da política de segurança e da complexidade de conformidade, a complexidade e a agilidade de TI, a
tarefa de traduzir as políticas de segurança para a implantação de segurança fica mais demorada, repetitiva,
onerosa e propensa a erros e pode elevar facilmente o grosso dos custos de segurança para as organizações dos
usuários finais. Assim, os usuários tradicionais são gerenciados dentro e fora das listas de controle de acesso para
o controle de acesso baseado em função, enquanto não forem violados os dispendiosos mecanismos que
processam estas listas para garantir a divisão das funções. Em vez disso, definir um conjunto de regras em uma
camada de titularidade, alimentadas pelas declarações, (asserções) e, atributos das entidades na transação,
simplifica e melhora significativamente o controle que uma organização tem sobre os suas aplicações, para levar
ao assinante final das organizações (e provedores de nuvem), reduzindo seus custos e melhorando a precisão na
implantação de políticas.
Tabela 1 - Matriz de Direito de Acesso Simples de uma Aplicação em Nuvem do RH
Acesso aos gerentes Acesso ao usuário Acesso de casa aos gerentes Acesso de casa pelo
Declaração/Atributo de RH corporativos corporativo de RH corporativos (laptop usuário (dispositivo
corporativo) próprio)
ID: Id da Organização Válido Válido Válido Não
ID: Identificação do usuário Válido Válido Válido Válido
ID: Dispositivo Válido Válido Válido Não
Atributo: O dispositivo está vazio Válido Válido Válido Desconhecido
Atributo: O dispositivo está atualizado Válido Válido Válido Desconhecido
Atributo: IP do dispositivo (está na rede Válido Válido Não Não

corporativa?)
Atributo: O usuário é gerente de RH Válido Não Válido Não
Acesso para ler/editar Acesso para Acesso para ler/editar apenas Acesso só para ler
para todas as contas ler/editar apenas para usuários das contas do apenas para usuários
Resultado de acesso
do RH para usuários das RH das contas do RH
contas do RH
73
OpenID - um padrão aberto para permitir que os usuários sejam autenticados de forma descentralizada
74
OAuth - Autorização aberta, um padrão aberto para autorização, permitindo que os usuários compartilhem seus recursos
privados com tokens em vez de credenciais
75
XACML- Linguagem de marcação de controle de acesso extensível, um padrão OASIS

Para integrar os controles de segurança de aplicações, a segurança de dados e a proteção de privacidade, os

serviços devem utilizar as normas do setor auditáveis, por exemplo, a ISAE 3402/SSAE 16 (que substitui a SAS 70),
a PCI, a HIPAA e a ISO 27002. Cada uma vem com controles em uma variedade de categorias que regem a
operação dos centros de dados de um provedor de nuvem, bem como as aplicações que podem ser hospedados
em um ambiente como esse.
É importante avaliar as diferentes declarações de segurança e tomar uma boa decisão sobre quais normas se
aplicam às aplicações e serviços que estão sendo hospedados em um ambiente de nuvem. Deve ser feita uma
análise detalhada com base nos requisitos, para identificar os objetivos de nível de serviço iniciais, para evitar
maiores alterações no código para o código de aplicativo, para a implantação e para as ferramentas de apoio,
tanto nos clientes, como nas organizações provedoras de nuvem.
10.2.3 Blocos de construção de conformidade
Independentemente de quais normas são utilizadas, obter a conformidade para executar uma aplicação em uma
nuvem requer alguns blocos básicos de construção e as bases de todas as normas que são fornecidas pela
infraestrutura física do provedor de nuvem. Os controles da infraestrutura compreendem coisas como proteger a
instalação de desastres naturais, garantindo energia elétrica confiável em caso de interrupções e fazer backup dos
dados em caso de uma falha de hardware. Eles também incluem os controles que regem os processos e políticas
do provedor de nuvem, como o sistema de auditoria administrativa, o acesso e a autorização de acesso ao centro
de dados e os métodos utilizados para as avaliações de segurança interna e como elas são realizadas e relatadas.
A próxima camada acima dos controles de infraestrutura é um conjunto de controles de aplicações. São
requeridos múltiplos níveis de segurança, como uma segura camada de transporte; os dados devem ser
criptografados com chaves de criptografia sob controle da empresa quando deixam o centro de dados. Algumas
aplicações podem precisar de segurança de camada de mensagem, assinatura digital e outros recursos de
segurança adicionados, para estar em conformidade com algumas normas para armazenar ou transmitir
informações de identificação pessoal, a fim de atender aos requisitos de privacidade. Todos esses controles de
aplicações para o serviço/aplicação a serem movidos para a nuvem devem ser identificados durante a fase de
projeto, para que possam ser devidamente integrados ao projeto de arquitetura e desenvolvidos conforme as
necessidades. As normas notáveis são a PCI –DSS, a SOX, a ISAE 3402/SSAE 16, a HIPAA e, outras normas de
privacidade.
10.3 A identidade, a titularidade e o gerenciamento de acesso para a segurança de

aplicações em nuvem
As aplicações empresariais tradicionais internas podem ser protegidos com controles de segurança de perímetro
tradicionais, como um firewall, proxy etc. Isso pode muito bem atender aos requisitos de segurança e aos níveis
de risco da empresa, já que as aplicações são executadas em redes confiáveis, em hardware confiável etc. A
empresa também poderia aproveitar a sua infraestrutura de diretório para autenticar seus usuários para essas
aplicações e manter todas as decisões de acesso dentro das aplicações. Neste caso, o perímetro para a empresa é
bem definido.
Todos esses controles tradicionais já não são eficazes o suficiente para proteger quando o usuário move essas
aplicações para a nuvem, uma vez que essas aplicações são executados em redes não confiáveis (perda de
parametrização). As aplicações podem ser residentes com outros multilocatários do mesmo provedor de serviços
(conjunção de recursos) e podem ser acessados de qualquer lugar através de qualquer tipo de dispositivo. Isso

muda as muitas naturezas dos requisitos de segurança para as aplicações em nuvem. Conforme o site
www.rationalsurvivability.com a estrutura da nuvem é referida como segue:
Figura 1 - Estrutura da Nuvem
Agora, o usuário pode adicionar na estrutura acima referida os caminhos para acessar essas aplicações. Essa
estrutura pode ser visualizada como:
Figura 2 - Componentes de Entrega de Nuvem
Pela estrutura acima, é possível ver claramente que o seu aplicação é uma janela lateral e, o novo perímetro é o
conteúdo (dados) e o contexto pelo qual o usuário tenta acessar esses dados. Isso torna crítica a aplicação dos
controles de segurança do aplicação para as aplicações em nuvem. O contexto de acessar os dados torna-se
muito importante e necessita de uma rica coleção de identificadores e atributos com os quais se tomará as
decisões de acesso. Com a consumerização de TI, as empresas estão agora frente à realidade de "traga seu
próprio dispositivo" (do inglês Bring Your Own Device - BYOD). Assim, a identificação do dispositivo e dos
atributos desse dispositivo também se torna um fator importante para determinar o controle de acesso.
A identidade não deve apenas ser vista como uma referência para a autenticação de uma entidade, mas também
reúne mais informações sobre o usuário, para a tomada de decisões de acesso. A identidade também inclui as
identidades dos dispositivos que as aplicações são executados (identidade da imagem da VM), dos usuários
privilegiados que gerenciam a imagem de VM (podem ser tanto de usuários corporativos, como de usuários de

provedores de serviços), das identidades de outras aplicações e serviços que o aplicação precisa interagir, das
identidades de usuários administrativos para gerenciar o aplicação e das identidades externas fora da empresa
que necessitam de acesso ao aplicação como o B2B, o B2C etc. Observe também que as decisões de acesso serão
baseadas em atributos que não estão relacionados com a identidade e nas ferramentas de políticas de
autoria/gerenciamento necessárias para suportar tais atributos anônimos (consulte abaixo o "gerenciamento de
autorização e políticas de automação").
Nesta seção, examinaremos o modo como a identidade, a titularidade e o gerenciamento de acesso afetam a
segurança das aplicações em nuvem. O IdEA pode ser dividido genericamente em cinco componentes principais:
1. Autenticação
2. Autorização
3. Administração
4. Auditoria e conformidade
5. Política
10.3.1 Autenticação
A autenticação refere-se a estabelecer/assertar a identidade para o aplicativo. Isso é feito normalmente em duas
fases. A primeira fase é a eliminação de ambiguidades de identidade e a segunda fase é validar a credencial já
fornecida para o usuário. Alguns dos principais mecanismos para autenticação de aplicações em nuvem são: a
independência do dispositivo, a comum e simples interface de usuário (do inglês User Interface - UI) e o protocolo
único universal em todos os dispositivos. Além disso, muitos provedores de serviços expõem seus serviços em
forma de APIs76 e, essas APIs são projetadas para aceitar tokens em vez de senhas.
Em uma aplicação empresarial normal, a autenticação é feita no armazenamento dos usuários da empresa (no
diretório ativo (do inglês Active Directory) ou no LDAP) e, a credencial de autenticação normalmente é o ID do
usuário e a senha. Fica mais complicado autenticar utilizando as credenciais da empresa em uma aplicação
baseada em nuvem. Algumas empresas estabelecem o túnel VPN a partir do provedor de serviços para a rede da
empresa de modo que eles possam autenticar no diretório dos usuários da empresa. Mesmo que esta solução
possa funcionar, a empresa deve considerar os problemas de latência, de conectividade e o planejamento BCP/DR
etc. e, esta solução não deve ser utilizada ou concebida para novas aplicações em nuvem. As empresas devem
planejar a utilização de padrões abertos como o SAML e o WS-Federation.
Existe também o aumento na utilização de aplicações corporativas por parceiros e clientes da empresa. Isso vale
também para aplicações em nuvem. Esses usuários raramente querem manter identidades separadas para o
acesso de terceiros (mas atualmente frequentemente eles não têm escolha). E então, as empresas devem se
planejar para "traga sua própria identidade" (do inglês Bring Your Own Identity - BYOI) e, o aplicação em nuvem
precisa ser projetado para consumir a identidade e os atributos de várias organizações.
Uma vez que as aplicações em nuvem são amplamente acessíveis através de vários dispositivos, deve ser
preterida como uma solução, autenticar com um simples ID de usuário e senha. As empresas devem planejar
utilizar autenticações fortes. Os consumidores devem considerar uma autenticação forte para a confirmação de
identidade original e determinar o tipo de credencial que atenda os seus requisitos de risco (token RSA, OTP por
76

SMS ou telefone, cartão inteligente/PKI, biometria etc.). Então, isso permitirá identificadores e atributos com um
forte nível de autenticação a serem encaminhados para as aplicações em nuvem e melhores decisões de risco a
serem tomadas sobre o gerenciamento de acesso pela camada de titularidade.
As empresas devem planejar a utilização da autenticação baseada em riscos para suas aplicações em nuvem. Esse
tipo de autenticação é baseado no identificador do dispositivo, na localização geográfica, no ISP, na informação
heurística etc. O aplicação em nuvem não deve apenas realizar a autenticação durante a conexão inicial, mas
também na autenticação baseada em riscos, conforme as transações que estão sendo executadas dentro do
aplicativo.
As aplicações em nuvem também devem aproveitar a convergência das normas, onde aplicáveis, como a SAML e
a OAuth. Como mencionado anteriormente nesta seção, as APIs de serviços em nuvem são projetadas para
aceitar tokens e não senhas, de modo que se um usuário tentar acessar os serviços em nuvem pelo seu
dispositivo móvel, tem que autenticar primeiro no provedor de identidade (que hoje em dia, provavelmente se
encontram nas suas empresas) e, uma asserção de SAML é gerada e encaminhada para o provedor de serviços em
nuvem. Depois da validação da asserção da SAML, é gerado um token OAuth e encaminhado para o dispositivo
móvel. Em seguida, o dispositivo móvel encaminha esses tokens para acessar os serviços em nuvem, que
representam a transferência de estado (do inglês REpresentational State Transfer - REST)77 baseado nas APIs.
10.3.2 Controle de acesso e autorização
A autorização em termos mais amplos refere-se à aplicação das regras pelas quais o acesso é concedido aos
recursos. O processo de titularidade utiliza políticas de negócios que por sua vez, se traduzem em acessar os
recursos da empresa. Para aplicações baseadas em nuvem, a autorização deve não só ser realizada com base no
conteúdo, mas também pelo contexto.
Para o modelo de autorização centrada no usuário, o usuário é a política do ponto de decisão (do inglês Policy
Decision Point - PDP)78. O usuário determina o acesso aos seus recursos e, o provedor do serviço atua como a
política do ponto de aplicação (do inglês Policy Enforcement Point - PEP)79. A OAuth é amplamente utilizada para
este modelo e, o acesso do usuário gerenciado (do inglês User Managed Access - UMA) também é um padrão
emergente neste contexto.Para um modelo de autorização centrado na empresa, a empresa é a PDP ou a política
do ponto de acesso (do inglês Policy Access Point - PAP)80 e, o prestador do serviço funciona como a PEP. Em
alguns casos, as empresas implantam gateways de segurança em nuvem para a PEP. O cliente empresa deve
considerar utilizar a XACML e a política de gerenciamento centralizado.
As aplicações em nuvem poderiam aproveitar múltiplos tipos de serviços. Alguns serviços podem ser aplicações
legadas expostas como serviços da Web utilizando middleware, ou os serviços da Web poderiam ser serviços em
nuvem nativos da Web. Embora tenha sido abstraída pela interface de serviço da Web, a diversidade de entrega
da cadeia de suprimentos pode complicar o processo de governança. A governança do tempo de projeto inclui
definir, desenvolver e, registrar os serviços e, implantar um requisito de política de acesso a esses serviços. A
governança do tempo de execução inclui descobrir os serviços, implantar restrições de segurança para chamar os
serviços, impor restrições de segurança para acessar o serviço e auditar todos os acessos. Utilize padrões abertos
77
REST - Transferência de estado representativa, um estilo de arquitetura de software para sistemas de hipermídia
distribuídos
78
PDP - Política de ponto de decisão
79
PEP - Política de ponto de aplicação
80
PAP - Política de ponto de acesso

como o W3C WS81-policy para definir assertivas de políticas de segurança e de gerenciamento, o WS-Security para
impor restrições de acesso e, o WS-Trust para implantar serviços seguros de token (do inglês Secure Token Service
- STS)82 para validar e emitir tokens e formatos simbólicos de trocas etc. Existem diferentes tipos de modelos de
autorização de controle de acesso, designadamente baseado em função, baseado em regras, baseadas em
atributos, baseado em declarações e baseado em autorizações (como o ZBAC)83. As empresas que já possuem
uma solução própria de Gerenciamento de Acesso à Web (do inglês Web Access Management - WAM)84 devem
aproveitar essas soluções para também proteger plenamente as aplicações em nuvem. A maioria dos produtos de
WAM suportam os controles de acesso baseados em regras e em funções.
Os arquitetos e designers de aplicações devem planejar migrar para o controle de acesso baseado em regras
utilizando as declarações e os atributos como fonte para essas regras, através do processo de titularidade descrito
acima e menosprezar outras soluções legadas.
Ao utilizar o controle de acesso baseado em atributos, o provedor de identidade (do inglês Identity Provider -
IdP)85 encaminha os atributos para o provedor de serviços de nuvem para ser executado. Os provedores de
identidade devem garantir que:
 Os atributos ligados à identidade não precisem estritamente se referir a identidade do usuário, como o
nome, sobrenome, endereço de e-mail etc. Poderia incluir também o endereço de IP, as informações de
localização, o grupo de filiação, o número de telefone etc.;
 Sejam tomados cuidados no compartilhamento de atributos que identifiquem diretamente o usuário, já

que levantam questões de privacidade;
 As empresas devem também planejar a complexidade dos atributos para a tomada de decisões de
controle de acesso. Eles devem saber qual atributo do provedor contata um determinado atributo
baseado na credibilidade. Existem agregadores de atributos que a empresa possa aproveitar. Isto poderia
complicar ou simplificar a confiança. As empresas devem levar em conta as complexidades de resolução
de conflitos, lidar com dados incompletos etc.;
 As empresas devem também levar em conta a extensibilidade dos atributos como validação (a
propriedade de verificar), os termos de uso, a data etc.;
 As empresas devem levar em consideração a privacidade, as políticas de liberação de atributos e

consentimentos. Os exemplos incluem as diretivas de privacidade da comunidade europeia, as leis
estaduais e locais etc. A localização do IdP, do CSP e do usuário (por questões de jurisdição) também
devem ser levadas em conta nessa decisão;
 Apenas o mínimo de informação necessária para o controle de acesso seja liberada;
 As empresas deverão garantir que os atributos que não estejam centrados na identidade também sejam
suportados;
 As empresas devem garantir que as políticas de acesso e de titularidade sejam gerenciáveis, além de
serem tecnicamente exequíveis. Potenciais soluções incluem o uso de políticas de tecnologias de
automação (talvez vinculadas às ferramentas das mesclas de aplicações da PaaS).
81
WS - Serviço da Web
82
STS - Serviços seguros de token
83
Descrito nas publicações por Alan Kark dos laboratórios da HP
84
WAM - Gerenciamento de acesso da Web
85
IdP - Provedor de identidade

O principal objetivo do controle de acesso baseado em declarações é controlar o compartilhamento das

informações. As declarações são baseadas no contexto da transação. Ao planejar a utilização da autorização
baseada em declarações, uma empresa deve considerar:
 A utilização de declarações significativas (endereço de e-mail verificado, ao invés de apenas endereço de

e-mail);
 O tipo, a garantia, a validade e a qualidade de declaração (se a declaração estiver armazenada em cache
fora do provedor de declarações, ela perde a validade);
 A autoridade condizente com as declarações baseadas no contexto, por exemplo, uma empresa de
telecomunicações que tem autoridade para verificar o seu número de telefone, um provedor de e-mail
que tem autoridade para verificar o seu endereço de e-mail etc.;
 A utilização de declaração de agentes sempre que possível, pois poderão ser utilizadas para a abstração
de vários provedores de declarações, ou seja, eles poderiam criar um pacote de declarações em níveis de
confiança desejados e criar um ponto central para a permissão do usuário;
 Mínima liberação da declaração conforme requerido pela transação;
O aplicação em nuvem pode ser também uma mescla de outras aplicações em nuvem sendo executados na
mesma ou em diferentes provedores de serviços. A empresa deve planejar como os usuários são autenticados
plenamente em todos essas aplicações em nuvem e como os perfis dos usuários, tais como a associação de grupo,
as titularidades, as funções etc., são compartilhados entre essas aplicações em nuvem para controles de acesso
detalhados. A utilização de padrões abertos é recomendada às empresas para este caso de uso (SAML, OAuth,
XACML etc.).
10.3.3 Administração/gerenciamento
O gerenciamento de identidade (do inglês Identity Management - IDM)86 dentro da empresa está voltado
principalmente para gerenciar usuários (provisionar) e para políticas para gerenciar o acesso (para aplicações
empresariais). O IDM é um componente muito importante da IdEA não só para um acesso oportuno aos usuários,
mas também à oportuna revogação do acesso quando o usuário sai, ou ao gerenciamento oportuno do acesso
quando o usuário se move para uma função diferente. Dentro da empresa, o gerenciamento de identidade
geralmente é bem integrado e está diretamente conectado aos armazenamentos de dados (dos usuários, das
políticas etc.); na maioria das implantações, isso também é fortemente personalizado. Devido à natureza
distribuída das aplicações em nuvem, aplicar o mesmo princípio que não os inicie, faz com que o IDM possa não
ter o acesso direto aos armazenamentos de dados do provedor de serviços. Além disso, não há quaisquer APIs de
provisionamento. Muitos fornecedores de serviços não têm adotado o protocolo de linguagem de marcação de
aprovisionamento de serviço (do inglês Service Provisioning Mark-up Language - SPML)87. No contexto da
computação em nuvem o IDM não deve apenas gerenciar as identidades de usuários. Deve estender isso para
gerenciar identidades de aplicações/serviços em nuvem, políticas de controle de acesso para estes
aplicações/serviços em nuvem, identidades privilegiadas para as aplicações/serviços etc.
O atual provisionamento federado é implantado com APIs proprietárias expostas pelo provedor de serviços. O
modelo de ENVIO, que é seguido pelo IDM da empresa não funcionará com as aplicações em nuvem, já que pode
sobrecarregar os provedores de serviços.
86
IDM - Gerenciamento de identidade
87
SPML - Linguagem de marcação de aprovisionamento de serviço

O novo padrão emergente é o gerenciamento simples de identidade em nuvem (do inglês Simple Cloud Identity
Management - SCIM)88, sendo que o principal objetivo deste padrão é tornar o gerenciamento de identidades
mais barato com uma implantação mais fácil e mais rápida. O objetivo secundário é o de facilitar a migração de
identidades de usuários para dentro e para fora da nuvem. O SCIM é simples porque utiliza um esquema de
núcleo amigável e bem definido em nuvem, uma API RESTful que é suportada por muitos provedores de serviços
de nuvem, suporta o gerenciamento de identidade e funciona com os protocolos existentes, tais como SAML,
OpenID connect etc. Baseado nisso (na hora de editar), o SCIM pode ter adotado como um padrão do setor para o
provisionamento de identidade.
Alguns dos desafios que as empresas consideram para a gestão da identidade são:
 Como sincronizar as mudanças nas identidades/acesso entre empresa -> nuvem, nuvem -> nuvem, nuvem
-> empresa,
 Como o desprover as identidades e o acesso em toda a empresa e em nuvem,
 Como autorizar/atualizar/gerenciar as políticas de acesso em uma forma gerenciável, expansível, de baixa

manutenção e de baixo custo.
A solução atual para muitas empresas é a adoção de uma solução de IDM híbrida que abrange tanto a empresa
como a nuvem.
O gerenciamento de políticas de acesso é um dos principais desafios da segurança de aplicações e muitas vezes
requer uma automação máxima da segurança como solução: A política de automação da segurança é
particularmente importante para a computação em nuvem, pois os usuários em nuvem demandarão o suporte
para regulamentar a política de gerenciamento de conformidade dos provedores de nuvem, mas ao mesmo
tempo julgarão o retorno sobre o investimento (ROI) financeiro nas mesmas medidas que eles fazem para a
computação em nuvem em geral, ou seja, em quanto ele corta suas despesas de investimento inicial e seus custos
internos de manutenção manual.
10.3.4 Auditoria/Conformidade
As empresas que utilizam os serviços em nuvem devem responder a três perguntas fundamentais:
1. Quais recursos de nuvem que um usuário tem acesso?
2. Quais recursos de nuvem que um usuário acessa atualmente?
3. Que política de regras de acesso foi utilizada como base para uma decisão?
Com as atuais implantações em nuvem, os clientes corporativos têm uma visibilidade muito limitada dentro dos
provedores de serviços de nuvem para uma auditoria dos dados. Uma empresa precisa ter acesso a esses dados,
não só para atender a conformidade direcionada dos negócios, mas também para atender as regulamentações do
setor e também lidar com litígios de fraude.
Atualmente, o mercado de IDM está se direcionando para a governança de identidade e acesso (do inglês Identity
and Access Governance - IAG)89. As empresas devem considerar também a utilização de ferramentas de
incidentes de segurança e de gerenciamento de eventos (do inglês Security Incident & Event Management - SIEM)
88
SCIM - Gerenciamento simples de identidade em nuvem
89
IAG - Governança de identidade e acesso

para correlacionar os dados de registro de acesso de aplicações em nuvem e sua política de dados, para gerar
relatórios de políticas de conformidade, bem como a utilização das normas auditáveis do setor como a ISAE
3402/SSAE 16, a HIPPA, a DSS PCI, a ISO 27002 etc.
As considerações gerais de IdEA para a segurança de aplicações em nuvem são:
 A identidade, a titularidade, o gerenciamento de acesso não deve ter uma reflexão tardia; em vez disso,
deve ser integrado no SDLC de um aplicativo, iniciando com o levantamento de requisitos.
 Durante a fase de projeto considere como controlar o acesso ao aplicativo, utilizando sempre que possível
um acesso baseado em declarações.
 Durante a fase de projeto considere como controlar o acesso ao aplicação utilizando sempre que possível
um acesso baseado em declarações;
 Considere utilizar ferramentas como o gerenciamento de senhas em contas compartilhadas (do inglês
Shared Account Password Management - SAPM) para gerenciar contas altamente privilegiadas dentro do
aplicativo. Isto possibilita a divisão de funções e o mínimo privilégio;
 Se a empresa já dispõe de ferramentas de gerenciamento de acesso via Web, garanta que essas
ferramentas sejam estendidas para um ambiente em nuvem, ou seja, adicione uma capacidade de SAML;
 As aplicações em nuvem precisam aproveitar os serviços oferecidos pelos provedores de serviços, tais
como o registro, a conectividade de banco de dados etc. A maioria dos provedores de serviços os expõem
como serviços da Web ou uma API. O acesso a estes serviços pode ser controlado por tokens de OAuth.
Assim, as aplicações em nuvem devem levar em consideração o suporte a diversos tipos de token como a
OAuth, as chaves de API etc.;
 Garanta seguir um processo de desenvolvimento ágil e que o aplicação seja criado com componentes
modulares. Isso possibilita que o aplicação aproveite no futuro os novos padrões emergentes como o
BrowserID do Mozilla, o U-Prove da Microsoft e o acesso gerenciado do usuário (do inglês User Managed
Access - UMA) da Kantara Initiative.
Tenha ciência das ameaças para as aplicações em nuvem, que incluem:
 Falsificação. Assumir a identidade de outro usuário
 Adulteração. Modificar os dados em trânsito
 Repúdio. Negar a origem da transação (pedido ou resposta)
 Vazamento de informações. Divulgação desautorizada de dados
 Negação de serviço. Afetar a disponibilidade
 Elevação de privilégio. Assumir a função ou a titularidade
Essas ameaças podem ser resolvidas pela IdEA da seguinte forma:
 Falsificação. Autenticação (autenticação forte)
 Adulteração. Assinatura digital ou espalhamento (do inglês Hash) (que é utilizada na asserção SAML)

 Repúdio. Assinatura digital (que é utilizada na asserção SAML), registro de auditoria
 Vazamento de informações. SSL, criptografia (não estritamente específica de IdEA)
 Negação de serviço. Gateways de segurança (gateways de segurança de serviços na Web)
 Elevação de privilégio. Autorização (OAuth)
10.3.5 Política de gerenciamento
A política de gerenciamento de acesso (normalmente denominada como "gerenciamento de autorização",

quando centrada na titularidade) é o processo de especificação e manutenção de políticas de acesso para os
recursos nas políticas de acesso baseada em atributos, incluindo as identidades relacionadas com o chamador e
os atributos relacionados (por exemplo, a autenticação do chamador), os atributos de contexto (por exemplo,
relacionados ao ambiente/negócio/TI) e os atributos relacionados ao destino (por exemplo, as políticas de
limitação de acesso ou QoS de acesso)90.
O gerenciamento de titularidade faz parte do gerenciamento de autorização e acesso, que adicionalmente inclui
as políticas de autoria e de manutenção para os atributos que não estão relacionadas com a identidade, mas que
são necessários (além de identidade e seus atributos) para tomar uma decisão de um acesso significativo.
A titularidade/autorização também leva em consideração os atributos que não estão relacionados a uma
identidade, por exemplo:
 A situação geral do ambiente de TI, os negócios/processos de negócios, a interconexão dos sistemas de TI

ou dos processos de negócios, ou o ambiente etc. (por exemplo, nível de crise, situação de emergência);
 As outras decisões tomadas por outras entidades (por exemplo, as aprovações, as decisões anteriores);
 Os atributos relacionados com o recurso de destino protegido (por exemplo, a QoS e as políticas de
limitação)
Normalmente, o gerenciamento de autorização, o processo decisório e o processo de aplicação são realizados em

um dos três seguintes locais:
1. Utilizando um ponto central/externo da política de aplicação/política de servidor/Política como um

Serviço;
2. Incorporado como parte do aplicação em nuvem;
3. Utilizar uma Identidade como um Serviço ou um Indivíduo como um Serviço (uma entidade Indivíduo é a
sua identidade com os atributos selecionados).
10.3.5.1 Questões da nuvem versus política de gerenciamento
O gerenciamento de autorização/titularidade em nuvem enfrenta vários problemas91.
Em primeiro lugar, o gerenciamento de titularidade em nuvem tem a questão específica que os assinantes de
nuvem normalmente não têm, um suficiente controle sobre as técnicas da política de acesso da tomada de
90
Lang, U. “Access Policies for Middleware”, tese de PhD pela University of Cambridge Computer Laboratory de 2003
91
Detalhes: O gerenciamento de autorização/titularidade em nuvem enfrenta vários problemas91.

decisão e aplicação na infraestrutura de nuvem. Atualmente, a maioria dos provedores de nuvem não oferece
políticas para pontos de inscrição configurável em aplicações (por exemplo, com base na norma XACML da OASIS)
e os provedores de nuvem, naturalmente, não podem pré-configurar as políticas específicas de inscrição para os
assinantes (porque eles são específicos do assinante).
Em segundo lugar, uma complexidade de gerenciamento de titularidade para nuvens interconectadas (mesclas) é
que o acesso precisa ser controlado nas mesclas da nuvem interconectada e não apenas em cada nó individual da
nuvem. Isso significa que as políticas precisam ser mentalmente idealizadas nas cadeias de serviços e nas
delegações em toda a mescla da nuvem interconectada.
10.3.5.2 Melhores práticas de gerenciamento de autorização
 Definir se uma perspectiva voltada para a titularidade/identidade é a melhor maneira de criar e manter
políticas de acesso para a sua organização. Em muitos casos, uma perspectiva voltada para a proteção de
recursos pode ser mais fácil para criar e manter, porque muitas vezes o objetivo é proteger os recursos e,
as políticas normalmente são distribuídas para sistemas finais protegidos pela aplicação automática de
políticas (por exemplo, de titularidade/sistemas de gerenciamento de autorização). Nesses casos, a
identidade é apenas um atributo em uma política de acesso que é escrita idealizada com o objetivo de
aplicação ao sistema final protegido.
 Certifique-se de que as políticas sejam especificadas de uma forma exequível. Isso inclui a especificação
de políticas que sejam genéricas e especificadas em um nível suficientemente elevado de abstração e,
que expressem bem a compreensão da importância da organização/empresa/pessoas. Os mecanismos e
as ferramentas estão disponíveis para gerar regras tecnicamente detalhadas de política de acesso, de tal
forma gerenciáveis (por exemplo, usando automação na política de segurança orientada a modelos).
10.3.5.3 Arquiteturas para fazer a interface com provedores de políticas de acesso
As políticas de pontos de decisão/aplicação (PEPs/PDPs) que utilizam protocolos padrão (por exemplo, a XACML)
ou protocolos proprietários (por exemplo, serviço direto da Web, ou outras chamadas de middleware) podem
acessar políticas de servidores (que contêm as regras para mesclas de uma nuvem interconectada).
Normalmente, a arquitetura é do tipo um (servidor) para muitos (PDPs/PEPs), se a política engloba um domínio
único confiável (por exemplo, uma empresa na Internet). Entretanto, em implantações em maior escala, pode
haver muitos servidores de política federada que fornecem serviços diferentes de PDP/PEP. Atualmente, vários
produtos de gerenciamento de acesso suportam regras de gerenciamento de autorização (por exemplo, na
XACML) que podem ser utilizados para expressar titularidades de identidades. Além disso, muitos produtos de
gerenciamento de autorização que estão disponíveis podem ser utilizados para criar políticas de autorização a
partir de uma perspectiva mais voltada para o destino do recurso.
10.3.5.4 Provisionar políticas de acesso
Além do provisionamento de identidade + atributos, é preciso provisionar as políticas de acesso (conforme o item
“10.3.5.3 Arquiteturas para fazer a interface com provedores de políticas de acesso” acima). Além do mais, é
preciso provisionar os atributos anônimos, por exemplo, a partir de serviços de diretório ou de outras fontes de
atributos. Ambos precisam ser provisionados para os PDPs/PEPs e, a prontidão e a exatidão desempenham um
papel fundamental.

10.3.5.5 Gerenciar políticas de acesso em nuvem
Criar e manter políticas de acesso gerenciáveis é um enorme desafio; simplesmente há regras demais para as
técnicas de linguagem e de atributos utilizados para gerenciar políticas, que não correspondem ao entendimento
dos administradores humanos e, também as regras técnicas precisam ser atualizadas com frequência para
permanecerem corretas após cada mudança de tempo dos sistemas (por exemplo, para as ágeis mesclas de
nuvem) e, mais, é difícil estabelecer o nível de confiança/garantia da aplicação das técnicas às políticas que
correspondam à intenção do administrador humano. Consequentemente, é crucial planejar cuidadosamente as
ferramentas e processos para tornar este processo de criar/atualizar as políticas de acesso gerenciáveis pela
automação.
As soluções atuais incluem abordagens automatizadas para transformar as políticas de segurança de nível
superior em regras técnicas de acesso (de nível inferior), que incluem:
 Na segurança orientada pelo modelo92, o processo é suportado pela ferramenta de modelagem dos
requisitos de segurança em um nível superior de abstração e utiliza outras fontes de informação
disponíveis sobre o sistema (produzido por outras partes interessadas). Estas entradas, que são expressas
em linguagens de domínio específico (do inglês Domain Specific Languages - DSL) são então
transformadas em regras de segurança aplicáveis com o mínimo possível de intervenção humana. Elas
incluem também o gerenciamento de segurança em tempo de execução (por exemplo, de
titularidades/autorizações), ou seja, a aplicação da política do tempo de execução nos sistemas
protegidos de TI, nas atualizações de políticas dinâmicas e no monitoramento da política de violações;
 Agrupar as regras das técnicas de acesso em grupos similares para reduzir a complexidade;
 Visualizar tentativas para fazer políticas técnicas mais fáceis de entender
10.3.5.6 Melhores práticas de autorização na nuvem
 Considere cuidadosamente se uma perspectiva voltada para a proteção de recursos na criação de

políticas de acesso pode ser mais adequada para o seu ambiente que uma perspectiva voltada para a
identidade.
 Garanta o gerenciamento de políticas de acesso, especialmente para alterar dinamicamente mesclas em

nuvem. Isso inclui consistência para criar política, distribuir política, aplicar e atualizar. Considere utilizar
ferramentas e abordagens automatizadas (por exemplo, segurança orientada pelo modelo) para gerar as
regras das técnicas de acesso necessárias para a aplicação da política.
 Designar responsabilidades claras para a política de gerenciamento e a política de auditoria.
 Verifique se o seu provedor de nuvem oferece o gerenciamento de autorização dos PEPs/PDPs que
possam ser configurados com a política de autorização específica do assinante e que a política do seu
servidor possa interagir corretamente com a política selecionada.
 Considere utilizar a "política como um serviço" como a política do servidor, caso precise de uma política
de servidor central para uma mescla em nuvem.
Atualmente, as melhores práticas para selecionar serviços de autorização são:
92
NIST IR 7628

 A característica mais importante dos serviços de gerenciamento de autorização é a capacidade de

gerenciamento da política do assinante de nuvem, porque o gerenciamento das políticas de acesso é o
maior desafio em torno da autorização;
 Os serviços devem possibilitar, do modo mais automático possível, gerar as técnicas de políticas (e
atualizá-las!), para os requisitos de política de segurança genéricos a partir da intuição humana;
 Se for politicamente viável para a sua organização e, estiver disponível para você, a "política como um
serviço" deve ser considerada como uma opção de terceirizar a criação e a atualização das políticas.
Muito provavelmente, isto será aceitável dentro da comunidade em nuvens onde a "política como um
serviço" é oferecida para uma comunidade fechada.
 Garanta que os serviços disponham de uma função de exportar/importar dentro das normas, como a
XACML da OASIS;
 Certifique-se de que os serviços possam interagir com os PEPs/PDPs instalados na infraestrutura de

nuvem e com a política de pontos de monitoramento para monitorar/auditar incidentes.
10.4 Testes de invasão de aplicações para a nuvem
Um teste de invasão abrange o processo de avaliação das vulnerabilidades residuais presentes na camada do
aplicação ou do sistema, que podem ser potencialmente exploradas com intenção maliciosa por um hacker
externo ou interno. Em geral, o teste abrange a análise ativa das superfícies do aplicação ou sistema como uma
"caixa preta" e tenta identificar vulnerabilidades típicas que podem ser predominantes, decorrentes de má
programação ou de práticas de enrijecimento.
O guia de testes OWASP Testing Guide V3.0 do projeto de segurança de aplicação aberto da Web (do inglês Open
Web Application Security Project - OWASP)93 recomenda nove tipos de categorias de testes de segurança ativa
(do inglês Active Security Testing) como segue:
1. Teste de gerenciamento de configuração;
2. Teste de lógica de negócios;
3. Teste de autenticação;
4. Teste de autorização;
5. Teste de gerenciamento de sessão;
6. Teste de validação de dados;
7. Teste de negação de serviço;
8. Teste de serviços da Web;
9. Teste Ajax (teste de segurança de aplicações avançados da Internet (do inglês Rich Internet Applications -
RIA).
93
OWASP - Projeto de segurança de aplicação aberto da Web, www.owasp.org

As categorias acima dos testes de segurança serão igualmente aplicáveis em uma aplicação que será implantada
em nuvem, em que a natureza das vulnerabilidades do aplicação não mudará sob o ponto de vista técnico.
Porém, conforme o tipo de nuvem, ameaças de vetores adicionais podem ser induzidas na implantação do
modelo (que não teriam entrado na equação para uma implantação que não em nuvem).
Um exemplo de tal vetor de ameaça em uma implantação de SaaS seria o induzido pelo multilocatário, quando o
mesmo tempo de execução do aplicação estiver sendo utilizado para atender vários locatários e seus dados
separadamente.
Figura 3 - Vetor de Ameaça Herdado
Precisarão ser desenvolvidas e incluídas classes de testes adicionais para enfrentar as ameaças que surgem como
resultado do modelo de implantação do aplicação em nuvem. Na tabela abaixo é dada uma ilustração do mesmo.
Tabela 2 - Vetor de Ameaça Herdado
TESTE DE SEGURANÇA
MODELO EM NUVEM DO INDUTORES
EXEMPLOS DE TRADICIONAL EM CATEGORIAS DE
APLICAÇÃO QUE ESTÁ DE AMEAÇAS
AMEAÇAS CATEGORIAS AINDA TESTES ADICIONAIS
SENDO IMPLANTADO ADICIONAIS
RELEVANTES
Multilocatário Um locatário  Teste de  Teste de

em um nível diferente gerenciamento de multilocatário
de aplicativo utilizando a configuração (um
escalonamento
mesma  Teste de lógica de
de privilégio)
infraestrutura do negócios
SaaS ganha acesso  Teste de autenticação
SaaS aos dados de
 Teste de autorização
outros locatários
 Teste de
através de
gerenciamento de
vulnerabilidades
sessão
de camadas da
 Teste de validação de
Web (um
dados
escalonamento de
privilégio)  Teste de negação de

serviço.
 Teste de serviços da
Web
 Teste Ajax (teste de
segurança de
aplicações avançadas
da Internet (do inglês
Rich Internet
Applications - RIA)
Multilocatário O mesmo que O mesmo que acima O mesmo que acima

PaaS em um nível acima
de plataforma
Multilocatário As deficiências na  Avaliação da  Intersegurança

em um nível segurança de vulnerabilidade da de VM/teste de
de virtualização infraestrutura vulnerabilidade
tradicional (é preciso
infraestrutura (aplicação
“definir” isso)
indevida de
IaaS zoneamento de
VM, a separação
conduz a
interataques de
VM em múltiplos
locatários da IaaS)
10.5 Monitoramento de aplicações na nuvem
Assim como acontece com outros aspectos da segurança em nuvem, o que e, como um sistema baseado em
nuvem é monitorado, varia com o tipo de nuvem que está sendo considerado. O que isso significa para monitorar
aplicações na nuvem e como monitorar diferentes tipos de aplicações em nuvem é explicado abaixo em detalhes.
10.5.1 Monitoramento de aplicações na nuvem: dar e pegar
Neste documento limitaremos “monitorar” para focar no monitoramento da segurança de aplicações.

Particularmente, as seguintes categorias de métricas serão abordadas:
1. Monitorar o registro. Para fins de conformidade, não basta apenas arquivar os registros. Entenda as saídas
em potencial que poderiam ser enviados para esses registros e monitore os eventos acionáveis. Um registro
de erros de aplicação é inútil, a menos que exista um processo para detectar e responder a esses erros.
2. Monitorar o desempenho. Este, exerce um grande fator na computação compartilhada. Uma mudança
significativa no desempenho de uma aplicação pode ser o sintoma de que outro cliente está utilizando uma
parcela maior de um recurso limitado (por exemplo, CPU, memória, armazenamento SAN) ou pode ser o

sintoma de uma atividade maliciosa, seja com o aplicação que está sendo monitorado, ou com outro
aplicação na infraestrutura compartilhada.
3. Monitorar o uso malicioso. Isso é uma mescla de auditar e monitorar requerida para ser bem sucedida. A
empresa precisa entender o que acontece quando um usuário malicioso tenta ganhar o acesso ou utilizar
permissões que ele não tem. Os registros de auditoria devem registrar a falha (ou o êxito) da tentativa de
fazer login. As funções de validação de dados registraram alguma coisa? É criado um alerta em algum lugar
caso uma aplicação tenha um acréscimo significativo em volume de tráfego?
4. Monitorar o comprometimento. Aqui, a chave é o quão rápido e eficiente uma organização corresponde
ao comprometimento. Dependendo da complexidade do aplicativo, determinar o comprometimento pode ser
relativamente fácil (por exemplo, o usuário “A” registrado em duplicidade) ou requerer mais esforço (por
exemplo, desenvolver algoritmos heurísticos para monitorar o uso de dados). Esse é um bom exemplo de um
item que, quando abordado previamente no SDLC, pode ser mais fácil de gerenciar.
5. Monitorar violações de políticas (especialmente de controle de acesso). É importante monitorar e auditar

a forma como uma política de ponto de decisão chegou a uma decisão, ou seja, quais regras de políticas
foram aplicadas para tomar a decisão sobre um determinado acesso. Isto está de acordo com uma
abordagem geral de monitoramento orientado por políticas que evita os problemas típicos de
monitoramento de falsos positivos e sobrecarga de incidentes.
Estes são alguns dos principais conceitos por trás de monitoramento de registros, - o lado de "pegar" da equação.
Igualmente importante, o desenvolvedor de uma aplicação é responsável pelo lado de "dar": Seu aplicação deve
fornecer um rígido subsistema de registro para permitir que o sistema de monitoramento faça o seu trabalho de
forma eficiente:
1. Facilmente analisável. Os registros devem ser escritos em um formato que possam ser facilmente
analisados por um sistema separado. Um bom exemplo seria utilizar um formato bastante conhecido e aceito
como o XML. Um exemplo ruim seria escrever entradas de registro de resultados não delineados e saídas em
múltiplas linhas de texto.
2. Facilmente legível. Uma entrada de registro deve ser compreensível por uma pessoa com formação
técnica, familiarizada com o aplicativo, já que escrever os registros em um formato binário, sem dúvida,
nunca será lido diretamente por um ser humano.
3. Bem documentado. Não é suficiente apenas escrever registros para um arquivo. Os códigos de erro
precisam ser documentados e devem ser exclusivos. Se um determinado registro tem como ser resolvido,
documente a resolução ou forneça uma referência para ela.
10.5.2 Monitorar aplicações em diferentes tipos de nuvem
Monitorar uma aplicação baseada em uma IaaS é quase "normal", comparado a monitorar aplicações "legadas",
implantadas em ambientes não compartilhados. O cliente precisa monitorar problemas com a infraestrutura
compartilhada ou com tentativas de acesso não autorizado a uma aplicação por um locatário malicioso.
Monitorar aplicações implantadas em plataformas em nuvem requer um trabalho adicional. A menos que o
provedor da plataforma forneça uma solução de monitoramento que possa monitorar aplicações implantadas, o
cliente tem duas escolhas: Ou escrever a lógica do aplicação adicional para desempenhar tarefas de

monitoramento dentro da plataforma, ou enviar os registros para um sistema de monitoramento remoto, quer
para o sistema interno de monitoramento do cliente, quer para um serviço de terceiros.
Como as aplicações baseadas em SaaS oferecem o mínimo de flexibilidade, não chega a ser uma surpresa que o
monitoramento da segurança desse tipo de aplicações é o mais difícil. Antes de utilizar um produto de SaaS, os
clientes devem ter uma compreensão completa de:
 Como o provedor monitora as suas aplicações?
 Quais tipos de informações de auditoria, registro ou alertas o provedor enviará ao cliente? O cliente tem a
possibilidade de selecionar quais informações receberá?
 Como o provedor transmitirá estas informações ao cliente? (pelo Twitter? E-mail? API personalizada?)
Um último ponto a considerar para o monitoramento da segurança de aplicações na nuvem: Enquanto os

provedores (ou os serviços de monitoramento em nuvem terceirizados) podem ter construído um sistema de
monitoramento para monitorar as aplicações do cliente, os sistemas de monitoramento estão monitorando
centenas ou até milhares de clientes. O provedor, como um negócio, precisa que esse sistema de monitoramento
funcione “suficientemente bem”. Se o cliente dispõe de recursos para executar um sistema próprio de
monitoramento para monitorar as suas aplicações, este será quase sempre mais responsivo e mais informativo
que aquele do provedor de nuvem.
10.6 Recomendações
10.6.1 Recomendações de garantia da segurança
o A segurança funcional e regulatória e os requisitos de privacidade são definidos para atender as

necessidades do desenvolvimento e/ou implantação em nuvem;
o Ter inclusa uma avaliação detalhada dos vetores de ataque e dos riscos no ambiente de nuvem e ter as
estratégias de minimização integradas aos requisitos;
o Realizar uma avaliação de impacto para todos os riscos e vetores de ataque e documentá-la juntamente
com o potencial de perda ou de dano a partir de cada cenário;
o Priorizar os requisitos de segurança e de privacidade e os esforços por probabilidade e impacto.
10.6.2 Recomendações de análises de risco
o Realizar análises de risco das aplicações de segurança e privacidade (confidencialidade, integridade e

disponibilidade) e construir e manter os modelos de ameaças;
o Analisar os riscos a partir da perspectiva de desenvolvimento e implantação na nuvem e manter os

modelos de ameaças relacionadas;
o Catalogar os vetores de ataque e análise de impacto específico para arquiteturas em nuvem e, mantê-los;
o Manter a rastreabilidade entre as características de garantia de segurança e todos os riscos/ameaças

identificadas.

10.6.3 Recomendações de arquitetura
o Desenvolver e manter as estruturas de arquitetura de software seguro.
o Utilizar os padrões de arquitetura da computação em nuvem que minimizem explicitamente as ameaças

(por exemplo, da "Open Security Architecture”94 or TOGAF/SABSA95);
o Estão disponíveis blocos de construção reutilizáveis na arquitetura de aplicações, para minimizar as

situações mais conhecidas de violações de segurança;
o As arquiteturas específicas de segurança de dados de nuvem devem ser utilizadas para melhorar a
estrutura de arquitetura de segurança escolhida, que abordará as questões e as ameaças específicas da
nuvem, tais como:
 O monitoramento dos servidores dos bancos de dados dinâmicos;
 Compreender onde está exatamente hospedado o banco de dados em qualquer instante;
 Registrar centralizadamente toda a atividade, através de sistemas díspares (potencialmente globais)

para proporcionar uma visão holística das aplicações e sinalizar os eventos suspeitos;
 Definir onde utilizar a criptografia (consulte o domínio 12);
 Fornecer uma adequada divisão de funções dentro do sistema, dos dados e de todas as atividades
privilegiadas por terceiros, que possam ser monitoradas por funcionários da organização, que
possuam os dados.
10.6.3 Recomendações de teste de invasão de aplicações em nuvem
o Realize regularmente o teste de invasão de aplicações da Web para verificar as 10 maiores

vulnerabilidades do OWASP;
o Categorize as vulnerabilidades baseadas na criticidade/impacto e disponha de um processo de reparo;
o Realize testes manuais do ponto de vista do multilocatário para confirmar que os privilégios não possam
ser escalonados ou que os dados possam ser isolados pela falta de aplicação da sessão;
o Deve ser realizada uma avaliação da segurança nas aplicações que estão sendo migrados para um
ambiente de IaaS ou de PaaS, para garantir que os controles subjacentes de segurança, como o
zoneamento e o isolamento da VM, a segurança de virtualização etc. foram efetivamente postos em
prática e não representam um risco para o ecossistema de aplicações.
94
www.opensecurityarchitecture.org
95
www.opengroup.org

REFERÊNCIAS
1] The Building Security In Maturity Model. http://bsimm.com/
[2] OpenSAMM – Software Assurance Maturity Model. http://www.opensamm.org/
[3] DAVIS, NOOPUR. Secure Software Development Life Cycle Processes. Software Engineering Institute
[4] SP-011: Cloud Computing Pattern.

http://www.opensecurityarchitecture.org/cms/en/library/patternlandscape/251-pattern-cloud-computing
[5] KRUTZ, RONALD L. and VINES, RUSSEL DEAN. 2010. Cloud Security- A Comprehensive Guide to Secure Cloud
Computing. Wiley Publishing, Inc., Indianapolis, IN.
[6] SARNA, DAVID E.Y. 2010. Implementing and Developing Cloud Computing Applications. Auerbach
Publications.
[7] BELK, MARK, COLES, MATT, et al. 2011. Fundamental Practices for Secure Software Development: A Guide to
the Most Effective Secure Development Practices in Use Today, 2nd EDITION. Software Assurance Forum for
Excellence in Code. http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf
[8] RITTINGHOUSE, JOHN W. and RANSOME, JAMES F. 2009. “Cloud Security Challenges” in Cloud Computing:
Implementation, Management, and Security. Auerbach Publications.
http://www.infosectoday.com/Articles/Cloud_Security_Challenges.htm
[9] Guidelines on Security and Privacy in Public Cloud Computing. Computer Security Division Information
Technology Laboratory. 2011. National Institute of Standards and Technology - Gaithersburg, MD 20899-8930
http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf
[10] Homomorphic Encryption. Making Cloud Computing More Secure.

http://www.technologyreview.in/computing/37197/
[11] Cloud Data Protection. Best Practices. http://www.ciphercloud.com/blog/?cat=10

DOMÍNIO 11 //
CRIPTOGRAFIA E GERENCIAMENTO DE CHAVES
É óbvio para um profissional de segurança de que se uma organização precisa armazenar dados e não confia
naqueles que podem acessar ou utilizá-los, eles devem ser criptografados. Dentro de um centro de dados em suas
dependências (on-premise) onde a organização controla todos os ativos, dados são criptografados pois algumas
regulamentações ditam que os dados devem ser criptografados (por exemplo, o PCI DSS).
Parece óbvio que na nuvem, muito mais dados precisem ser criptografados, onde há vários locatários e
administradores trabalhando para alguém. Se for esse o caso, como é que funcionam esses processos e como a
organização gerencia suas chaves? Criptografar tudo aumenta a complexidade. Por outro lado, é mesmo
necessário codificar este volume de dados, já que isso causa complexidades nos processos de negócios, entre
outros assuntos? Existe outra maneira de reduzir a necessidade de criptografar os dados e subsequentemente
gerenciar as chaves? Este capítulo aborda essas questões.
Visão geral. Este domínio abordará os seguintes tópicos:
 Introdução à criptografia
Criptografar ou não criptografar? Eis
 Abordagens alternativas à criptografia a questão. Se sim, como gerenciar as
chaves? Se não, os riscos são muito
 A criptografia em implantações em nuvem
altos?
 A criptografia em bancos de dados em nuvem
 Gerenciamento de chaves na nuvem
 Armazenamento e salvaguarda de chaves
11. 1 Introdução à criptografia
Os dados classificados como confidenciais por razões de conformidade regulatória ou sigilo corporativo precisam
ser protegidos. À medida que as informações confidenciais, que atualmente são gerenciadas nos sistemas
internos se deslocam cada vez mais para a nuvem, elas devem ser protegidas com a mesma diligência. O
deslocamento para a nuvem não remove quaisquer requisitos de confidencialidade e proteções de dados. A
perda do controle de dados fora do perímetro seguro da empresa (deperimetrização) aumenta a complexidade da
proteção de dados e aumenta os riscos de comprometimento.
Existe um número de fatores a considerar com relação à criptografia em nuvem, que incluem:
 Proteger os dados através da criptografia à medida que são deslocados para a nuvem requer mais do que
apenas garantir que seja utilizado um canal de transferência seguro (ou seja, TLS). Criptografar a

transferência de dados para a nuvem não garante que os dados estejam protegidos na nuvem. Assim que
os dados chegarem à nuvem, devem continuar protegidos, estando em uso ou em repouso.
 Utilize a criptografia centrada em dados para os arquivos não estruturados que precisam ser protegidos
quando armazenados ou compartilhados na nuvem ou a criptografia incorporada no formato do arquivo,
que sempre é prática para aplicar a proteção diretamente aos arquivos.
 Entenda como todas as chaves de criptografia/decodificação gerenciarão todo o ciclo de vida dos dados.
Sempre que possível evite quaisquer dependências de provedores de nuvem para proteger e utilizar
adequadamente as chaves que protegem as suas informações essenciais.
 Evite oportunidades para lapsos nas garantias empregadas de terceiros, ou de legislações regionais que
possam fornecer acessos indesejados, mas obrigatórios para os seus arquivos criptografados. Somente
você pode acessar os seus arquivos, caso só você possua as chaves.
 Não se esqueça de proteger os arquivos que são frequentemente negligenciados, mas que normalmente
contém informações confidenciais. Os registros de arquivos e metadados podem ser vias de vazamento
de dados.
 Criptografe utilizando criptografias fortes e duradouras o suficiente (como a AES-256) que cumpram os
mesmos mandatos regulatórios e empresariais utilizados para criptografar arquivos gerenciados
internamente. Utilize formatos abertos e validados e sempre que possível evite formatos de criptografia
proprietárias.
11.2 Abordagens alternativas à criptografia
Existem boas razões para buscar alternativas que abordem a criptografia de dados na nuvem. Para muitas
organizações, o envio de dados para a nuvem é equivalente a transferir uma relação de custódia.
Para as organizações que têm problemas com o envio inseguro de dados para fora da sua organização existem
alternativas:
 Geração de tokens. É aqui que o serviço de nuvem pública pode ser integrada/pareada com uma nuvem
privada que armazena dados confidenciais. Os dados enviados para a nuvem pública são alterados e
deverão conter uma referência para os dados que residem na nuvem privada.
 Anonimato dos dados. É aqui por exemplo, que as informações pessoais identificáveis (do inglês
Personally Identifiable Information - PII)96 e as informações pessoais confidenciais (do inglês Sensitive
Personal Information - SPI)97 são removidas antes do processamento.
 Utilize os controles do banco de dados em nuvem. É aqui que os controles de acesso incorporados no
banco de dados são considerados para fornecer os níveis adequados de segregação.
Como regra geral, as boas práticas de gerenciamento de dados são essenciais antes de mover os dados para a
nuvem, para entender se todos ou apenas alguns dados precisam ser criptografados, protegidos por um método
alternativo ou não serem protegidos como um todo.
96
97
SPI - Informação confidencial identificável

Ao avaliar o que proteger através de criptografia de outros métodos alternativos, existem riscos de
compartilhamento de dados98 que podem ser divididos em duas categorias principais: a divulgação e a utilização
indevida, nas seguintes áreas:
 A divulgação pública acidental. Tornar as informações ou os dados prontamente disponíveis ao público

em geral através da publicação ou da postagem na Web.
 A divulgação maliciosa ou acidental. O ato de tornar as informações ou os dados disponíveis a terceiros,

como consequência de proteção inadequada dos dados.
 Divulgação forçada para terceiros. As obrigações de ter de responder às intimações que solicitem a
divulgação dos dados em processos judiciais.
 Divulgações governamentais. A divulgação de dados para entidades governamentais, seja por força da lei
ou por ordem judicial (como o “Patriot Act”).
 Uso indevido de perfis de usuários ou da rede. A capacidade de analisar e minar os dados para derivar
informações confidenciais a partir do tráfego de dados aparentemente benigno e assim revelar o
comportamento dos usuários, associações, preferências ou interesses.
 Uso indevido conclusivo. Poder sintetizar identificadores em primeira ou segunda instância para tirar
conclusões sobre o comportamento ou sobre a identidade de uma pessoa.
 Reidentificação e uso indevido de anonimato. Ter acesso a informações "anônimas" suficientes para
poder inferir o assunto original.
11.3 A criptografia em implantações em nuvem
Existem dois conceitos complementares utilizados na seção de criptografia, que são:
 Criptografia com conhecimento do conteúdo. Utilizado na prevenção de perda de dados, software com
conhecimento de conteúdo entende o tipo ou formato de dados e os criptografa baseado na política de
configurações. Por exemplo um número de cartão de crédito é criptografado em um e-mail que está
sendo enviado por força da lei.
 Criptografia preservando o formato. A criptografia que preserva o formato é o resultado de criptografar

uma mensagem que fica igual a uma mensagem de entrada. Por exemplo, um número de cartão de
crédito com 16 dígitos continua tendo 16 dígitos após ser criptografado ou um número de telefone se
parecerá com um número de telefone e uma palavra em português se parecerá com uma palavra em
português.
A capacidade de criptografar da empresa para a nuvem sem a intervenção do usuário, é a maneira preferida de
tornar os dados seguros. O software com conhecimento de conteúdo pode ser aproveitado para a criptografia em
nuvem pública se o software também puder ser configurado para ser orientado a protocolo e criptografar campos
em uma transação de REST em HTTP para uma aplicação em nuvem pública. A prevenção de perda de dados
(DLP)99 é utilizada atualmente para atender produtos que possam aplicar a proteção de dados que estão saindo
da empresa, geralmente por e-mail e criptografar os dados antes da transação deixar a empresa. Este princípio
98
http://www.caida.org/data/sharing/
99
Os produtos têm um modo de aplicação na prevenção de perda de dados (DLP) que detecta e criptografa os dados que
estão saindo de um dispositivo protegido ou da empresa.

pode ser utilizado na proteção de dados em nuvem; entretanto, o produto do DLP pode gerar alertas. Um serviço
de conhecimento de conteúdo precisará detectar, criptografar e registrar, mas não alertar.
A criptografia de preservação de formato leva a um passo adiante o conhecimento do conteúdo sendo sensível
aos dados que necessitam de criptografia e mantendo o tipo e o formato dos dados. Por exemplo, com a
criptografia convencional, ao ser criptografado, um cartão de crédito se tornaria um texto cifrado100 e que não
seria mais um número de 16 dígitos. A criptografia de preservação do formato geraria um valor de texto cifrado
que é de 16 dígitos além de ser criptografado.
Por também preservar o tipo e o formato dos dados o serviço que fornece a criptografia pode então facilmente
alterar os valores alinhados sobre uma ampla variedade de protocolos. O desafio principal para a criptografia
preservando o formato está em criptografar grandes valores em texto simples, como um e-mail armazenado na
nuvem. A criptografia de escala em massa normalmente é o quanto em valores de texto está criptografado
utilizando cifras101 em blocos. No caso de preservação de formato, cada palavra seria codificada em uma
sequência de caracteres do mesmo tamanho, o que leva tempo. O resultado, no entanto, seria que os valores de
dados de textos cifrados podem ser armazenados em campos de mesmo tipo de dados que o texto original sem
formatação.
A criptografia em aplicações em nuvem apresenta algumas questões para as aplicações de negócios que a
arquitetura da aplicação precisa resolver. Quais são:
 Se os dados forem necessários para procurar registros ou objetos no aplicativo, então uma chave
primária102 criptografada tornaria isso bem difícil.
 Se o conjunto de aplicações em nuvem contém trabalhos em lotes ou outros tipos de processos que
trabalham com dados confidenciais, principalmente dados de PII e SPI e, esses processos são movidos
para a nuvem, essa situação complicará o gerenciamento de chaves.
Uma aplicação que precise encontrar registros ou objetos em um banco de dados pode optar por desenvolver
outra maneira de armazenar um valor único, como a geração de tokens. Os tokens são utilizados com frequência
em ambientes de cartão de crédito para garantir que o número do cartão de crédito seja muito pouco acessado
nas aplicações. Um único token gerado a partir do valor pode ser utilizado para desenvolver uma nova chave
primária que a aplicação possa utilizar, sem expor os dados confidenciais em uma nuvem pública.
Como será abordado na seção 11.4 abaixo, sempre que possível, as chaves não devem ser armazenadas na nuvem
e devem ser mantidas pela empresa ou por um provedor de serviços de gerenciamento de chaves confiável.
Os processos que precisam operar com dados de texto simples e serem executados na nuvem com outras
aplicações de negócios e dados, devem ter acesso às chaves ou a um serviço, para desempenhar as suas funções.
Consulte a seção 11.4 para mais detalhes sobre o gerenciamento de chaves na nuvem.
100
Texto cifrado - O resultado de uma operação de criptografia. A entrada é conhecida como texto simples.
101
Cifras - Software/hardware baseado em algoritmos que desempenham criptografia/decodificação e
assinatura/verificação.
102
Chave primária - Uma coluna/campo/atributo do banco de dados que é utilizado para identificar registros em um banco
de dados.

11.3.1 A criptografia em bancos de dados em nuvem
A primeira coisa a considerar é a necessidade de criptografar os dados. Todos os bancos de dados oferecem a
possibilidade de restringir o acesso aos dados. Pode ser suficiente proteger a confidencialidade caso esteja
adequadamente implantada.
Outros motivos que podem requerer a criptografia para proteger os dados armazenados no banco de dados são:
 Para ocultá-lo de quem tem acesso privilegiado ao banco de dados (por exemplo, dos administradores de
banco de dados (do inglês Database Administrators - DBAs)103)
 Para cumprir com os estatutos legais (tal como a lei SB1386, da Califórnia)
 Para armazená-lo em um esquema no qual o proprietário dos dados não possa controlar as credenciais da
conta ao acessar os dados (utilizando contas compartilhadas, por exemplo)
Quando utilizar um banco de dados em nuvem e particularmente uma solução de SaaS empregando um banco de
dados, a capacidade do banco de dados funcionar corretamente pode ser comprometida, a menos que ele possa
operar sobre os dados criptografados, sendo necessário que o banco de dados ou a aplicação em nuvem tenha
acesso às chaves.
A criptografia de dados impõe os custos da complexidade e do desempenho e, há alternativas eficazes para a

criptografia:
 Utilize a segurança do objeto. Utilize declarações SQL de concessão e revogação de para restringir quais
contas podem acessar os dados. As contas às quais você concede acesso devem ser controladas para
garantir que você está permitindo o acesso aos usuários autorizados.
 Armazene um hash seguro. Em vez de armazenar os dados diretamente, armazene um hash de dados.
Isso permitirá que seu programa comprove que o detentor dispõe do valor correto sem realmente
armazená-lo.
11.4 Gerenciamento de chaves
Um dos mais difíceis processos da computação em nuvem pública é o gerenciamento de chaves. O modelo
multilocatário de soluções de nuvem pública causa problemas de gerenciamento de chaves para os processos que
estão lá em execução.
Os casos de uso mais simples são aqueles que têm aplicações sendo executadas em nuvem pública e as chaves
que criptografam os dados que vão da empresa para a nuvem pública são utilizadas apenas dentro da empresa.
Conforme descrito na seção um, existem mecanismos de criptografia que podem criptografar os dados na saída e
decodificá-los no seu retorno. Uma aplicação que utiliza chaves criptográficas se torna complicada quando outros
processos, como os processos em lote, precisam acessar as chaves para decodificar os dados e esses processos
residem na nuvem pública.
Os usuários corporativos de criptografia precisam ter suas próprias chaves de modo que uma única chave
compartilhada não seja utilizada em toda a empresa. A maneira mais fácil de conseguir essas chaves específicas é
103
DBA - Administrador do banco de dados

um mecanismo criptográfico para que cada usuário ou entidade104 tenha chaves atribuídas (e gerenciadas)
baseadas na identidade das entidades. Deste modo, qualquer coisa que é criptografada especificamente para
uma entidade, é mantida por essa entidade. Se uma entidade precisa compartilhar o acesso aos dados em um
grupo de definições, então, as chaves de nível de grupo podem ser associadas à aplicação que mantém o acesso
do grupo e as entidades desse grupo podem compartilhar as chaves. As chaves devem ser mantidas dentro da
empresa, como abordado anteriormente nesta seção.
Quando os dados são armazenados em um ambiente de nuvem pública, existem problemas ao sair desse
ambiente, em poder comprovar que todos os dados (especialmente dados PII ou SPI, ou dados sujeitos a regimes
de garantia regulatória) foram excluídos do ambiente de nuvem pública, inclusive de todos os outros meios de
comunicação, tais como fitas de backup. A manutenção do gerenciamento de chaves local permite tal garantia,
revogando (ou apenas excluindo/descartando) a chave do sistema de gerenciamento de chaves, garantindo assim
que todos os dados restantes na nuvem pública não possam ser decodificados.
11.4.1 Armazenamento e salvaguarda das chaves
A criptografia de dados tem pouco valor se tanto os provedores como os usuários de serviços de nuvem não
reforçarem vigorosamente os processos em torno de gerenciamento de chaves.
No lado do fornecedor, a falta de segregação de funções (do inglês Segregation of Duties - SOD105), no entorno do
acesso à chave dos servidores e servidores com dados criptografados, deve ser um motivo de preocupação, bem
como os DBAs terem acesso às chaves individuais dos bancos de dados ou a arquitetura do serviço do banco de
dados ser dependente de uma única chave.
Os controles para proteger as chaves em torno de si mesmos, utilizando a chaves de criptografia de chave (do
inglês Key Encrypting Keys - KEK106), a geração de chaves de criptografia na memória e apenas armazenar a chave
criptografada dos servidores principais, são todas soluções arquitetônicas válidas que devem ser consideradas ao
arquitetar qualquer solução.
No lado do cliente, as chaves gerenciadas que protegem as chaves em dispositivos que não sejam seguros por si
próprios (como dispositivos móveis) ou em dispositivos que não têm o mesmo nível de controle, como o sistema
de criptografia em si, devem ser um motivo de preocupação.
Recomendações gerais
o Utilize as melhores práticas de gerenciamento de chaves quando utilizar qualquer forma de produto de
criptografia/decodificação.
o Utilize tecnologias de prateleira para obter as melhores práticas de uma fonte confiável, onde for
possível.
o Utilize as melhores práticas de gerenciamento de chaves e consiga a tecnologia e os produtos para

criptografia, decodificação, assinatura e verificação de fontes confiáveis.
104
Entidade - Para o propósito de identidade, pode ser um usuário, um código, um dispositivo, uma organização ou um
agente.
105
SOD - Divisão de funções
106
KEK - Chaves de criptografia de chave

o É altamente recomendável que as organizações mantenham suas próprias chaves ou utilizem um serviço
de criptografia de confiança de uma fonte que mantém atualmente um serviço como esse.
o Se uma organização precisa executar análises ou outros processos utilizando os dados armazenados na
nuvem, a empresa deverá desenvolver sobre uma plataforma, como o Hadoop e, ter esses dados
derivados da nuvem. Essas plataformas de desenvolvimento, incluindo o Hadoop, têm seu próprio
conjunto de problemas de segurança, mas esses estão fora do escopo deste capítulo.
o O escopo de chave deve poder ser mantido em nível individual ou em grupo.
o O acesso do grupo deve poder ser gerenciado com tecnologia de prateleira, como os sistemas de DRM e
outros softwares que executam no desktop/laptop, que criptografa discos, pastas e mensagens de e-mail.
Recomendações - criptografia em bancos de dados
o Utilize algoritmos padrões. Não invente/utilize técnicas de codificação proprietárias. Algoritmos

proprietários de criptografia não são comprovados e são facilmente quebrados.
o Evite padrões de criptografia inseguros e ultrapassados, tais como Data Encryption Standard (DES)107.
o Utilize a segurança de objeto. Continue a utilizar a segurança básica de objeto (declarações SQL de
concessão e revogação) para impedir o acesso até mesmo para os dados criptografados.
o Não criptografe chaves primárias ou colunas indexadas. Se criptografar uma chave primária, terá de
criptografar todas as chaves estrangeiras de referência. Se criptografar uma coluna indexada, poderá
acabar tendo consultas lentas ao tentar usar o valor criptografado.
o Utilize uma abordagem de criptografia por colunas (pois sistemas big data utilizam essa abordagem).
11.6 Requisitos
 A fim de manter as melhores práticas e passar por auditorias, a organização deve gerenciar as chaves sob
a custódia da sua própria empresa ou de um serviço confiável de um provedor de serviços de criptografia.
 As chaves utilizadas na tecnologia de criptografia existente como o DRM e os produtos de criptografia de

disco deverão ser geridos pela tecnologia de armazenamento de chave central e interna da empresa. Os
módulos de segurança de hardware (do inglês Hardware Security Modules - HSM) devem ser utilizados
para armazenar chaves, assim como operações de processos criptográficos, como a
criptografia/decodificação, assinatura e verificação.
 Os usuários corporativos devem passar por um processo de registro para permitir operações de
criptografia e outros processos na empresa, como os sistemas de conhecimento de conteúdo ou de
preservação de formato e poder acessar as chaves de criptografia/decodificação, conforme necessário.
 Implante tecnologia integrada em sistemas corporativos baseados na identidade de todos os

componentes da cadeia de processamento para tomar decisões de titularidade.
 Gerencie as chaves utilizadas pelos processos criptográficos utilizando operações criptográficas

vinculativas.
107
DES - Padrão de criptografia de dados

 Utilize sistemas existentes, tais como o gerenciamento de direitos digitais da empresa (do inglês
Enterprise Digital Rights Management E-DRM108) ou DLP, se possível.
 Vincule as operações de criptografia e de gerenciamento de chaves aos sistemas de identidade

corporativa, para prover uma integração mais flexível à organização e utilize a tecnologia que a
organização já conhece, que funciona e que já foi auditada e/ou verificada.
108
E-DRM - Gerenciamento de direitos digitais da empresa. Um processo que protege o conteúdo, tais como as
comunicações internas da empresa ou materiais com direitos autorais.

DOMÍNIO 12 //
GERENCIAMENTO DE IDENTIDADE, TITULARIDADE E ACESSO
Os conceitos por trás de gerenciamento de identidade, titularidade e acesso utilizados na computação tradicional
requerem mudanças fundamentais na maneira de pensar sobre a implantação de um ambiente em nuvem,
especialmente ao segmentá-lo especificamente em três funções distintas, gerenciamento de identidade,
titularidade e autorização/acesso (IdEA).
Para a maioria das organizações, a implantação de uma aplicação tradicional, significa implantar um servidor,
possivelmente em uma DMZ109, na maioria dos casos vinculado a um serviço de diretório (do inglês Directory
Service - DS)110 (como o Active Directory da Microsoft, o eDirectory da Novell ou o Open LDAP) para a
autenticação do usuário. Em alguns casos, isso significa implantar uma aplicação ou utilizar um serviço que a Web
entrega, utilizando o seu próprio sistema autônomo de autenticação, muito perturbador aos usuários, que têm de
lembrar os conjuntos de credenciais (ou pior, reutilizar as credenciais de outros domínios talvez mais confiáveis).
Em contrapartida, um serviço em nuvem ou uma aplicação de identidade bem implantada deve ser utilizada em
conjunto por uma série de fontes externas, juntamente com os atributos associados (lembrando que uma
identidade se aplica não só aos usuários111, mas também aos dispositivos, aos códigos112, às organizações e aos
agentes, que são todos que têm identidade e atributos). Aproveitar todas as múltiplas identidades e atributos
envolvidos em uma transação no sistema em nuvem permite tomar melhores decisões holísticas baseadas em
riscos (definidas pelo processo de titularidade113 e implantadas pelos componentes de gerenciamento de
autorização e acesso) sobre o acesso granular ao sistema, processos e dados dentro do/da sistema de
nuvem/aplicação.
Este processo de utilizar múltiplas fontes de Identidade e seus atributos relacionados é fundamental, quando é
provável que uma aplicação em nuvem esteja voltada para a Internet e também que seja um dos principais
obstáculos para as organizações que esperam utilizar os "verdadeiros" serviços em nuvem ao invés de optar por
implantar as tecnologias de virtualização em sua própria DMZ conectados a seus próprios DS internos.
Esta abordagem de deperimetrização114 ao gerenciamento de identidade, titularidade e acesso fornece uma

abordagem mais flexível e segura, mas também pode ser igualmente bem implantada dentro do limite
corporativo (ou perímetro).
109
DMZ - DeMilitarized Zone (Zona desmilitarizada)
110
DS ou "Directory Service" é utilizado nesta seção como uma abreviação para um serviço de diretório corporativo genérico
e, é utilizado para o nome de usuário e senha de login.
111
Normalmente humanos; para uma definição mais ampla e extensa refira-se ao
www.opengroup.org/jericho/Jericho%20Forum%20Identity%20Commandments%20v1.0.pdf
112
O código compreende todas as formas de código, incluindo até aplicações e dados de autoproteção.
113
"Titularidade" é o processo de mapeamento de privilégios (por exemplo, o acesso a uma aplicação ou aos seus dados) para
as identidades e os atributos relacionados.
114
Deperimetrização é um termo inventado pelo Jericho Forum® (www.jerichoforum.org)

Visão geral. As seções a seguir abordam os principais aspectos do gerenciamento de identidade, titularidade e
acesso em um ambiente em nuvem:
 Introdução à identidade em um ambiente em nuvem;
 Arquitetura de identidade para a nuvem;
 Identidade da federação;
 Provisionamento e governança de identidade e atributos;
 Gerenciamento de autorização e acesso;
 Arquiteturas para interface com provedores de identidade e de atributos;
 Nível de confiança com identidade e atributos;
 Provisionamento de contas em sistemas em nuvem;
 Projeto da aplicação para identidade;
 Proteção de dados e de identidade
12.1 Terminologia utilizada neste documento
A linguagem utilizada no tema da identidade é confusa, com alguns termos com significados diametralmente
opostos para diferentes pessoas. Para evitar más interpretações durante a leitura deste domínio, alguns termos
de identidade utilizados neste domínio são definidos a seguir:
 Identidade. É como uma entidade pode de forma consistente e abrangente ser identificada como única.
 Identificador. É como uma identidade pode ser criptograficamente declarada, geralmente utilizando a
tecnologia de chave pública.
 Entidade. Os distintos tipos que terão identidade, que são os usuários, dispositivos, códigos, organizações
e agentes.
 Titularidade. O processo de mapeamento de privilégios (por exemplo, o acesso a uma aplicação ou aos
seus dados) para as identidades e os atributos relacionados.
 Reduced Sign-on (RSO). A utilização de uma ferramenta de sincronização de conta e/ou de credencial
para minimizar o número de credenciais (normalmente o nome do usuário e a senha) que um usuário tem
de se lembrar; a maioria destas soluções resulta em alguma forma de comprometimento da segurança.
 Single Sign On (SSO). A capacidade de passar a identidade e os atributos a um serviço em nuvem, de

forma segura, utilizando padrões de segurança como a SAML115 e a OAuth116.
115
SAML - Security Assertion Markup Language, um padrão aberto OASIS baseado em XML, para troca de dados de
autenticação e autorização entre domínios de segurança.

 Federação. A conexão de um repositório de identidade com outro.
 Persona. A identidade e seus atributos específicos que fornecem contexto ao ambiente em que a
entidade está operando. Uma persona pode ser um agrupamento de uma identidade individual com uma
identidade organizacional e os atributos da organização (por exemplo, uma persona corporativa, Fred
Smith presidente da ACME Corp., ou um computador pessoal pertencente a ACME Corp.).
 Atributos. Aspectos de uma identidade.
12.2 Introdução à identidade em um ambiente em nuvem
Um ecossistema de identidade enfrenta problemas de dimensionamento (imagine a mudança de uma pequena

aldeia onde todos se conhecem para uma grande cidade ou uma metrópole). À medida que o setor se expande de
sistemas de identidade de computadores individuais para empresas globais e então para modelos de implantação
de nuvem, a capacidade de identificar todas as entidades envolvidas em uma transação se torna
significativamente mais difícil.
Porém, com a nuvem, a utilização da identidade para todas as entidades na cadeia de valor da transação e mudar
para decisões baseadas em riscos, não só pode minimizar os riscos, mas pode também melhorar potencialmente
a segurança.
Os seguintes pontos principais devem ser considerados na implantação de uma solução baseada em nuvem que
precisa utilizar informações de identidade:
 A força com que uma identidade pode ser declarada contribuirá para o cálculo do risco ao interagir com
essa identidade (como exemplos, incluem-se os anônimos; a autodeclaração; a validação por uma
organização respeitável conhecida com uma forte indicação organizacional da identidade).
 Os atributos de uma persona, como a identidade, terão uma força com a qual se pode declarar que
contribuem para o cálculo do risco ao interagir com esta persona. A força da declaração vai de
autodeclaração para validação por uma organização respeitável conhecida (com uma forte declaração da
identidade organizacional).
 A identidade e os atributos terão de ser consumidos a partir de múltiplas fontes e assim, as

soluções/arquiteturas em nuvem terão a capacidade de consumir múltiplas fontes diferentes de
identidade e atributos.
 Haverá instâncias em que uma identidade transitória é suficiente (informação suficiente sobre uma
entidade para considerá-la única).
 Existirão instâncias onde o pseudoanonimato é desejável (tal como votar).
12.3 Arquitetura de identidade para a nuvem
A mudança a partir de uma arquitetura tradicional com aplicações tradicionais de servidores baseados em
centrais internas de computadores oferece pouca flexibilidade para uma organização com perímetros definidos.
116
OAuth - Open Authorization, um padrão aberto para autorização, permitindo que os usuários compartilhem seus recursos
privados por meio de tokens em vez de credenciais.

A mudança para arquiteturas baseadas em nuvem permite uma maior flexibilidade, caso sejam implantadas
internamente dentro das fronteiras organizacionais (em uma nuvem privada) ou em nuvens públicas externas
(SaaS, PaaS ou IaaS).
A tabela a seguir mostra como a identidade precisa variar entre a implantação tradicional e a implantação em
nuvem, dependendo do tipo de arquitetura de nuvem implantada.
Tabela 1 - Asserções de Arquitetura de Identidade
TIPO DE ARQUITETURA ARQUITETURA TRADICIONAL ARQUITETURA EM NUVEM
Conectado ao DS interno Capacidade de aceitar múltiplas fontes de

as identidades devem ser identidade e atributos
mantidas dentro do DS para
Interna/perimetrizada
serem utilizadas pela aplicação,
potencialmente utilizando
soluções dereduced sing-on.
Necessário para controlar Usa declarações para fornecer identidade e

rigidamente e se conectar aos atributos para acessar os serviços em nuvem.
serviços organizacionais,
Interna/deperimetrizada
utilizando túneis VPN no back-
end. Uma arquitetura não
recomendada.
A hospedagem externa significa Usa declarações para fornecer identidade e

estender o perímetro para o atributos para acessar os serviços em nuvem.
provedor do servidor. A
identidade é estendida em um
Externa/perimetrizada ambiente que o consumidor
não gerencia, muitas vezes
colocando uma réplica do DS
para desempenhar naquele
ambiente.
A hospedagem externa significa Usa declarações para fornecer identidade e

estender a identidade interna atributos para acessar os serviços em nuvem.
em um ambiente estranho, mas
em uma linha dedicada de back-
Externa/deperimetrizada end ou uma VPN. A identidade é
estendida em um ambiente que
o consumidor não possui ou
gerencia e muitas vezes replica
o DS por desempenho .

Enquanto que em uma arquitetura tradicional o gerenciamento de identidade e acesso (do inglês Identity and
Access Management - “IAM”)117 de todos os componentes normalmente são independentes como parte de um
único servidor, uma arquitetura em nuvem é potencialmente mais complexa ao obter identidades e atributos de
uma série de fontes e ao tomar decisões de gerenciamento de autorização/acesso através de um conjunto regras
de titularidade definidas pelo processo de titularidade.
Na Figura 1 abaixo, a identidade e os atributos são provenientes (potencialmente) de múltiplas fontes e

contribuem em uma camada de gerenciamento de autorização/acesso que transpõe as regras de titularidade
para o acesso.
Gerenciamento de acesso
Fonte de identidade nº 1
Acesso ao aplicativo
Acesso ao processo
Acesso ao sistema
Acesso aos dados

Fonte de identidade nº 2
Acesso à rede
Autorização
Fonte de atributo nº 1
Fonte de identidade e atributo nº 1 Regras de titularidade
Processo de titularidade
Figure 1: Sistema de Gerenciamento de Identidade, Titularidade e Acesso Genérico
Dependendo dos requisitos de negócios/segurança, do tipo de modelo de nuvem, da IaaS, da PaaS ou do SaaS
que estão sendo implantados, o gerenciamento de acesso deve reger o acesso à:
 Camada de rede. Nem sempre é possível "ver" o sistema em nuvem (ou seja, pingar ou rotear) sem
cumprir as regras de titularidade. As regras de titularidade também podem direcionar o acesso a
interfaces específicas.
 Camada de sistema. As regras de titularidade podem definir os protocolos que têm permissão para
acessar e modificar os sistemas, tais como o servidor de terminal versus a Web.
 Camada de aplicação. As regras de titularidade podem mapear uma identidade e/ou atributos para a
funcionalidade fornecida por uma determinada aplicação que está sendo apresentada com um conjunto
reduzido de menus ou de opções.
 Camada de processo. As regras de titularidade podem ser utilizadas para definir os processos (ou
funções) que podem ser executadas dentro de uma aplicação. A titularidade também pode definir que
funções avançadas (como a transferência de dinheiro para fora do ecossistema) precisem de verificação
adicional (que pode ser obtida diretamente ou derivada em segundo plano).
 Camada de dados. As regras de titularidade podem limitar o acesso às áreas da estrutura de dados e de
arquivo ou até mesmo de arquivos individuais ou de campos dentro de arquivos (por exemplo, de um
banco de dados). Em um nível mais avançado, a titularidade pode ser utilizada para autoeditar
documentos, de tal forma que dois usuários que acessam documentos idênticos exibiriam conteúdo
diferente (por exemplo, construir uma determinada visualização dinâmica de uma tabela de banco de
dados).
117
IAM - Identity and Access Management

O processo de titularidade tem início quando o cliente transforma os requisitos de negócio e os requisitos de
segurança em um conjunto de regras de titularidade. Este processo definirá as identidades e os atributos
requeridos para poder avaliar as regras. Essas regras por sua vez direcionam o sistema de autorização/acesso.
12.4 Identidade da federação
Conceitualmente falando, a federação é a interligação dos diferentes serviços de diretórios. Algumas organizações
optam por um gateway da federação, (uma “ponte” ou o “hub da federação”) a fim de exteriorizar a sua
implantação da federação, onde a federação e as regras pelas quais a identidade é gerenciada dentro dessa
"ponte" são regidas por um conjunto de regras, geralmente por um contrato legal, permitindo assim outros
parceiros nesta ponte um nível definido de confiança nas identidades não diretamente emitidas por eles mesmos.
Tecnologicamente falando, a federação é a utilização de SAML para oferecer portabilidade para diferentes e
independentes domínios de segurança a algumas organizações que estendem seu ambiente de DS, através de um
produto de gateway que irá tratar as declarações SAML. Outras organizações consumirão as declarações SAML
nativas a partir de um serviço de identidade.
Em ambos os tipos de arquiteturas de federação, é essencial compreender a origem da identidade e dos atributos
que estão sendo afirmados.
Os padrões da federação são amplamente utilizados nos modelos de implantação de SaaS, tanto para a federação
de identidades como para controle de acesso. Não existem padrões similares para modelos de implantação de
PaaS ou de IaaS. Os consumidores em nuvem que aproveitam os modelos de implantação em IaaS devem
considerar como gerenciar o ciclo de vida de identidades (as contas compartilhadas, as contas nomeadas, as
contas privilegiadas etc.). As empresas que aproveitam as ferramentas de gerenciamento de identidade
privilegiada (do inglês Privileged Identity Management - PIM) para o gerenciamento de superusuário (do inglês
Super User Management - SUPM) e para o gerenciamento de senhas de contas compartilhadas (do inglês Shared
Account Password Management - SAPM) devem investigar estender essas ferramentas para suportar
implantações em nuvem. A empresa ou os consumidores em nuvem devem ter uma política bem definida para o
acesso altamente privilegiado (do inglês Highly Privileged Access - HPA).
12.5 Provisionamento e governança de identidade e atributos
Quando nos referimos a provisionamento, geralmente pensamos sobre o provisionamento de usuários, mas para
tomar decisões valiosas e baseadas em riscos, o sistema/aplicação em nuvem precisa da identidade e dos
atributos de todas as entidades envolvidas na transação e potencialmente outros atributos de outros
sistemas/processos.
Seguem alguns exemplos de identidade e atributos (não é uma lista exaustiva):
 Declarações do usuário: Identificador do usuário (a parte pública de um par de chaves público/privado);
 Nome do usuário (o nome do usuário deve ser apenas outro atributo de identidade);
 Credencial forte/confiável;
 Localização de declarações; endereço de IP, localização geográfica, GPS, serviço de localização de celular;

 Identidade da organização (identificador - criptografado) e declarações da organização;
 Identidade do dispositivo (identificador - criptografado) e declarações de dispositivo, funcionalidade

requerida, funcionalidade proposta, capacidade de área restrita, contêiner seguro, limpeza de dispositivo;
 Identidade do código (identificador - criptografado) e declarações do código;
 Registro/conformidade de treinamento etc.
A fonte principal da identidade e dos atributos de uma identidade (que pode ser de uma fonte diferente) precisa
ser identificada no projeto do processo de titularidade.
Como regra geral, o serviço em nuvem ou a aplicação em si deve evitar ser a fonte principal para a identidade (um
serviço de RH baseado em nuvem ou uma oferta de Identidade como um Serviço em nuvem, podem ser
exceções). No entanto, durante a transição para serviços em nuvem (não são melhores práticas), o
serviço/aplicação em nuvem pode precisar manter as identidades ou operar um modelo de modo misto.
Todos os atributos devem estar interligados a uma identidade, pois sem o identificador estar associado e com seu
nível de confiança, os atributos não têm procedência. Embora à primeira vista isso possa ser contraditório, a força
do processo de titularidade consiste em definir aqueles atributos necessários para fazer com que as regras
funcionem conforme a empresa requer e, depois, identificar a fonte autorizada (ou o mais próximo possível) para
fornecer esses atributos (com o respectivo identificador da entidade). Alguns exemplos incluem:
 Nível de ameaça de segurança: Identidade organizacional, governamental ou do provedor terceirizado;

 Aprovações ou decisões anteriores feitas por outras entidades: Identidade da entidade;
 QoS ou as políticas de limitação relacionadas a um recurso de destino protegido; identidade do sistema.
12.6 O processo de titularidade
O processo de titularidade inicia quando o cliente transforma os requisitos de negócio e os requisitos de

segurança em um conjunto de regras que irão reger a autorização e o acesso aos vários aspectos do sistema em
nuvem. Este processo definirá então as identidades e atributos que são necessários para avaliar corretamente as
regras de titularidade. O processo de titularidade e as regras decorrentes não só devem conduzir o
gerenciamento de autorização e acesso em um sistema em nuvem, mas também podem especificar um grau de
negociação/titularidade a todas as camadas da infraestrutura em nuvem, por exemplo, para permitir protocolos e
interfaces na rede e/ou na camada do sistema.
O processo de titularidade deve ser incorporado em qualquer documento de requisitos de negócios e também no
documento de requisitos técnicos; deve figurar também, como parte integrante do processo de provisionamento/
“cliente embarcado" do fornecedor de nuvem.
O processo de titularidade não para uma vez que o serviço de nuvem esteja instalado e em execução, mas as
regras de titularidade e as regras subsequentes que levam à autorização e ao acesso devem ser objeto de uma
verificação regular. Então, o processo de titularidade deve ser auditado pelo "sistema proprietário" da empresa
em relação aos requisitos do negócio. Qualquer auditoria deve incluir uma avaliação de risco e ameaça e
quaisquer requisitos regulatórios.
As soluções atuais incluem abordagens automatizadas para transformar as políticas de segurança de nível
superior em regras técnicas de acesso (de nível inferior), que incluem:

 Na segurança orientada a modelo118, o processo é suportado pela ferramenta de modelagem dos

requisitos de segurança em um nível superior de abstração e, utiliza outras fontes de informação
disponíveis sobre o sistema (produzido por outras partes interessadas);
 Agrupar as regras das técnicas de acesso em grupos similares para reduzir a complexidade;
 Visualizar tentativas para fazer políticas técnicas mais fáceis de entender.
O processo de titularidade deve definir essas entidades, identidades e atributos que são necessários para tomar
decisões de autorização e acesso significativos. Ele também deve definir aqueles atributos estabelecidos dentro
do processo ou aqueles que têm deles um aspecto temporal (de mudança ao longo do tempo) e, portanto,
forçará a revalidação, tanto no intervalo de tempo em que devem ser revalidados, como no gatilho dentro do
processo.
Onde a identidade e os atributos que são definidos no processo de titularidade precisem ser provenientes de fora
do controle da empresa, a identidade organizacional (identificador) daquele provedor (entidade) deve ser
embarcada e, em algum momento, portanto, desembarcada.
Normalmente as regras de titularidade são interpretadas em um dos três seguintes locais:
1. Utilizando um ponto de aplicação da política central/externo /servidor de política /Política como um

Serviço;
2. Incorporado como parte do aplicação em nuvem;
3. Utilizando uma Identidade como um Serviço (do inglês Identity-as-a-Service - IDaaS).
12.7 Gerenciamento de autorização e acesso
O gerenciamento de autorização e acesso é o processo pelo qual as regras de titularidade são transpostas
(através da camada de autorização) para as regras de gerenciamento de acesso.
Na maioria dos sistemas baseados em nuvem, a camada de autorização é provavelmente um “ponto de decisão
da política” (do inglês Policy Decision Point - PDP)119, ou seja, o ponto que avalia e decide as questões de
autorizações e, a camada de gerenciamento de acesso é o “ponto de aplicação da política” (do inglês Policy
Enforcement Point - PEP)120, ou seja, o ponto que aplica a decisão das PDPs.
O PDP e o PEP serão parte de um ecossistema de autorização que utiliza uma linguagem de marcação de controle
de acesso extensível (do inglês eXtensible Access Control Markup Language - XACML121) como uma linguagem
declarativa de política de controle de acesso implantada em XML.
Uma PEP pode ser tão simples quanto uma declaração “IF” (condicional) na aplicação em nuvem, ou tão avançada
quanto um agente executando em um servidor de aplicações ou um filtro em um gateway XML que intercepta as
solicitações de acesso e coleta os dados necessários (atributos), para poder avaliar as regras de titularidade e
depois tomar e implementar essas decisões.
118
www.modeldrivensecurity.org
119
PDP - Política de ponto de decisão
120
PEP - Política de ponto de aplicação
121
XACML - Linguagem de marcação de controle de acesso extensível

Isto não é obrigatório à utilização da XACML, das PDPs e das PEPs em um ambiente de nuvem, já que a
funcionalidade pode ser potencialmente implantada de outras formas (provavelmente em um ecossistema
fechado ou proprietário). Provedores de identidade/atributos
As PDPs podem ser implantadas fora do ambiente em nuvem,

possivelmente dentro do ambiente do cliente. Isto pode
potencialmente ter um número de vantagens, tais como uma
Agente central
interface com um DS interno e/ou a capacidade de integrar
registros sobre a decisão feita diretamente em um sistema de
registro interno.
12.8 Arquiteturas para interface com provedores

Provedores de Serviço
de identidade e de atributos Figura 2 - Modelo “Hub & Spoke”
Existem três arquiteturas básicas para a interface da identidade e dos atributos nos provedores:
1. Um modelo de “distribuição radial” (do inglês hub and spoke) no qual a identidade e os atributos são
centralmente gerenciados (por coordenadas) pelo hub, que então interagem com o(s) serviço(s) ou o(s)
aplicativo(s) em nuvem.
2. Um modelo de forma livre, onde o serviço em nuvem e/ou a aplicação pode ser configurada para aceitar
identidades e atributos de várias fontes.
3. Uma solução híbrida, em que os componentes são distribuídos, utilizando potencialmente outros serviços
em nuvem.
Cada modelo tem seus méritos e, a escolha será baseada no número de fatores, incluindo:
 Onde os clientes do serviço têm a sua identidade;
 A capacidade do serviço escolhido em nuvem;
 A capacidade da empresa fornecer a identidade e os atributos baseados em declarações.
12.8.1 Modelo de distribuição radial (hub and spoke)
A abordagem da distribuição radial (hub and spoke) normalmente possibilita que o serviço em nuvem interaja
diretamente com a organização e com as informações de seus atributos e identidade, preferencialmente sob a
forma de protocolos baseados em padrões de declarações, como a OAuth e SAML.
Os sistemas internos da organização são responsáveis por manter o controle de usuários, de outras entidades e
atributos. Esse é mais como um sistema tradicional de IAM e, provavelmente, o mais fácil de fazer a transição
para soluções em nuvem a serem implantadas pelas organizações, já que a maioria dos DS ou dos sistemas LDAP
podem ter uma capacidade de SAML "travada".

É como se neste modelo, o processo de titularidade também pudesse ser tratado dentro da organização através
da utilização de uma política de ponto de aplicação e política de servidor e, comunicada através da XACML
(embora a XACML ainda não seja amplamente utilizada para isso). A figura 2 ilustra a abordagem da distribuição
radial (hub and spoke).
Uma vantagem dessa abordagem é que a manutenção de uma política de ponto de aplicação dentro da
organização permite que a integração dos registros de auditoria seja mantida dentro da organização e ainda seja
correlacionada com outros registros distintos de auditoria (fora do ambiente em nuvem ou de outros ambientes
em nuvem), para obter a imagem completa requerida. Exemplos disso incluem as análises da divisão de funções e
o cumprimento dos requisitos regulatórios.
A abordagem de distribuição radial (hub and spoke) é suscetível de ser utilizada quando um alto grau de controle
é necessário sobre todos os "usuários" em um processo de inscrição central. Isto é mais provável em organizações
que estão sujeitas a uma pesada regulamentação. A distribuição radial (hub and spoke) deve também diminuir a
dependência em relação aos provedores de identidade/atributos, já que os atributos são normalmente
armazenados (em duplicidade) dentro do hub central.
Este também é o modelo utilizado quando uma organização se inscreve em uma ponte ou um "hub de
identidade".
12.8.2 Modelo de forma livre
No modelo de “forma livre”, o serviço/aplicação em nuvem é responsável por manter as fontes da identidade e
dos atributos. Esta solução é mais indicada para uma solução disponibilizada publicamente ou uma solução com
um grande número de parceiros diferentes.
A abordagem de forma livre tem a vantagem de ser mais fácil de configurar, pelo menos nos protocolos atuais da
federação (como a SAML), mas depende de uma boa implantação do modelo de titularidade para permitir que
seja dimensionado a uma grande quantidade de "usuários".
Uma forma de abordagem é a configuração ponto a ponto de uma relação de confiança federada (utilizando os
protocolos, como a SAML e a OAuth), entre o serviço e os provedores de atributos/identidade, mas esta
abordagem precisa de um processo eficiente para embarcar e desembarcar esses provedores.
O modelo de forma livre apresenta desafios de provisionamento de "usuários", pois, o ambiente de novas
entidades conectando-se é provavelmente mais ad-hoc. Novamente, um projeto cuidadoso do processo de
titularidade ajudará a aliviar este problema. A figura 3 acima
ilustra a abordagem ponto a ponto. Provedores de identidade/atributos
12.8.3 Modelo híbrido
O modelo híbrido é por definição, uma mistura dos modelos de

distribuição radial (hub and spoke) e de forma livre. Por exemplo,
as regras de titularidade podem ser realizadas dentro da
organização e pressionarem para uma PDP, que em si é um serviço
em nuvem e depois, essas decisões serem entregues aos múltiplos Provedores de Serviço
PEPs distintos, que fazem parte dos serviços em nuvem separados. Figura 3 - Modelo de Forma Livre
Em implantações de maior escala, pode haver uma série de

servidores de política federada de muitos serviços de diferentes PDPs/PEPs. O modelo híbrido será encontrado
também em organizações que misturam a computação tradicional e/ou legada em um ambiente (público e/ou
privado) em nuvem.
O modelo híbrido pode oferecer uma utilização eficiente dos recursos distribuídos, mas com o escopo de
atendimento, corre o risco de tornar-se complexo para que falhas de segurança se arrastem para dentro. Ele
também se torna mais problemático à manutenção em longo prazo (o raciocínio por trás de simples regras é
facilmente compreensível quando quem os implantou já está bem longe).
O modelo híbrido também terá problemas para decidir registrar e atuar frente à possível necessidade de retornar
todos os registros em um formato comum e em um único lugar, para ter uma visão global.
A potencial complexidade do modelo híbrido reitera a necessidade de poder utilizar as ferramentas de

visualização para desenvolver, manter e auditar a transposição das regras de titularidade dentro do verdadeiro
controle de acesso.
12.9 Nível de confiança com identidade e atributos
A identidade e os atributos vêm com muitos níveis de confiança, tanto nas diversas identidades que estão sendo
utilizadas em uma transação, como nos atributos ligados a essas identidades. Tradicionalmente, esta falta de
confiança levou as organizações a precisarem manter as identidades para os que precisam acessar seus sistemas,
que podem ser (em alguns casos) centenas de milhares de pessoas que não são funcionários ou diretamente
contratados.
Algumas organizações (militares/ aeroespaciais, farmacêuticas etc.) que precisam colaborar com um nível pré-
acordado de confidencialidade utilizam uma "ponte" ou um "hub da federação" (consulte a seção 12.4), onde as
identidades confiáveis também têm atributos confiáveis associados.
Durante o processo de titularidade é essencial compreender não só os atributos necessários, mas também a fonte
desses atributos, a organização que os proporcionará e, a força (nível de confiança) às quais se podem declarar.
Para aceitar os atributos de uma organização externa com qualquer nível de confiança definido será preciso um
processo embarcado para aquela organização e de identidade (identificador) da organização, que irá declarar
esses atributos.
Como regra geral, a meta deve ser a fonte de identidade e de atributos a partir da fonte principal/autoritária
desses atributos com todos os atributos que tenham uma identidade conhecida os declare, de modo que o nível
de confiança que pode ser colocado no atributo não exceda o nível de confiança que pode ser colocado na
identidade que declara o atributo.
À medida que os atributos estão sendo gerados exclusivamente dentro do próprio sistema em nuvem, um
processo de governança deve estar posicionado, para garantir que todos os atributos são exatos e tenham um
gerenciamento do ciclo de vida apropriado.
12.10 Provisionamento de contas em sistemas em nuvem
Sempre que for necessário provisionar uma "conta" em sistemas em nuvem (normalmente para um usuário, mas
poderia ser para qualquer tipo de entidade), existem desafios ao provisionar (e remover o provisionamento) essas

contas, já que o modelo normal de "empurrar" (do inglês “push”) utilizado dentro das organizações, geralmente
não é uma solução viável para a implantação de nuvem.
No momento de escrever, não há padrões ou vias de fato amplamente utilizados para o provisionamento; a
linguagem de marcação de serviço de provisionamento (do inglês Service Provisioning Markup Language -
SPML122) não tem sido amplamente adotada pelos provedores de nuvem e o gerenciamento simples de
identidade em nuvem (do inglês Simple Cloud Identity Management - SCIM123) está apenas começando a surgir
como um padrão em potencial.
A chave para provisionar entidades em um sistema em nuvem é compreender o gerenciamento do ciclo de vida
completo de uma conta, desde a criação, do gerenciamento e eventualmente a sua exoneração (incluindo a
exclusão e/ou o arquivamento) em todos os sistemas que ambos fornecem e consomem a identidade e os
atributos.
Há algumas questões cruciais que precisam ser abordadas com fontes de identidade e atributos quando se trata
de provisionamento:
 A ligação com o setor de recursos humanos (ou a fonte oficial de informações do usuário) é problemática,
pois normalmente o RH é apenas a fonte principal da folha de pagamento para a equipe.
 Normalmente não há fontes de informação autorizadas para as informações dos parceiros e seus
dispositivos.
 A capacidade de provisionar outras entidades (particularmente as organizações e dispositivos) não existe

na maioria das organizações.
 Os serviços de identidade pública em geral, apenas fornecem a identidade autodeclarada e apenas sobre
as pessoas; eles não se estendem a outros tipos de entidades.
 A revogação do provisionamento precisa se estender a todas as entidades, pois quando o contrato expirar
a maioria das organizações não terá capacidade para desembarcar outra organização ou revogar o código
de operação nos sistemas quando estiver defeituoso ou obsoleto.
Estas questões e a imaturidade dos padrões de provisionamento reforçam a necessidade de um bom

planejamento e uma abordagem global de como a identidade, os atributos, as contas e o gerenciamento do ciclo
de vida de todos os tipos de entidade operam no ecossistema em nuvem que está em desenvolvimento.
12.11 Identidade como um Serviço
A Identidade como um Serviço (do inglês Identity as a Service - IDaaS)124 é um termo amplo que abrange o
gerenciamento de qualquer parte do gerenciamento de Identidade, Direito e Autorização/Acesso no serviço em
nuvem.
Isso engloba o serviço para o software, para a plataforma, ou para os serviços de infraestrutura e, para as nuvens
tanto públicas como privadas. Nos casos em que as identidades ainda possam ser gerenciadas internamente
dentro da organização as soluções híbridas também são possíveis, enquanto que outros componentes, como a
122
SPML - Linguagem de marcação de serviço de provisionamento
123
SCIM - Gerenciamento simples de identidade em nuvem
124
IDaaS - Identidade como um Serviço

autenticação, são colocados externamente em uma arquitetura orientada a serviços (do inglês Service Oriented
Architecture - SOA)125). Isso cria efetivamente uma camada na Plataforma como um Serviço (PaaS) para facilitar
uma solução do IAM baseado em nuvem.
Para obter mais informações, consulte a seção que abrange a Identidade como um Serviço no Domínio 14 -
“Segurança como um Serviço”.
12.12 Conformidade e auditoria
O resultado das regras de titularidade precisa estar bem registrado, juntamente com as decisões tomadas pelo
processo das regras de titularidade/autorização, por questões de conformidade ou de segurança. A conformidade
e a auditoria estão intimamente ligadas à identidade. Sem o gerenciamento adequado da identidade não há como
assegurar a conformidade regulamentada. Para auditar também é preciso um adequado gerenciamento da
identidade e utilizar arquivos de registro sem ter um sistema de identidade que funcione, agrega quase nada.
12.13 Projeto da aplicação para identidade
Esta seção se aplica apenas para o projeto da aplicação e sua aplicabilidade à identidade e deve ser lida em
conjunto com o domínio 10 - Segurança de aplicações.
Projetar sistemas ou aplicações baseados em nuvem exige uma mudança de mentalidade quando se trata da
identidade, já que as informações de identidade e de atributos que serão consumidos pelo serviço em nuvem ou
pela aplicação precisam ser mantidas pelo menos pela duração da transação. Provavelmente, algumas facetas
precisem ser mantidas durante mais tempo, pois o ambiente em nuvem pode provavelmente não ser parte da
jurisdição física ou lógica de uma organização e até pode ter uma jurisdição legal diferente. O projeto dos serviços
e das aplicações pode precisar ser substancialmente diferente das práticas de projeto utilizadas no tradicional
cliente/servidor em uma DMZ própria e gerenciada pela organização.
O objetivo do projeto precisa minimizar a necessidade de identidade e atributos. Quando possível, inicie com a
premissa de que a identificação não é necessária até o limite onde será preciso mudar o provisionamento da
conta básica criada na hora (“on-the-fly”) para uma conta de usuário "identificada". Os exemplos incluem:
 Podem ser estabelecidas sessões exclusivas utilizando outros atributos, por exemplo, o endereço de IP do
dispositivo de conexão (considerando que os endereços de IP podem ser falsos) ou um cookie de sessão
única.
 Em muitos casos, só o atributo baseado na titularidade será adequado, sem a necessidade de informações
do usuário ou de uma identidade real; não presuma que seja preciso uma Persona para vincular a uma
sessão ou até mesmo a uma conta.
 Ao encontrar uma nova entidade pela primeira vez (digamos para autenticar com uma declaração SAML),
crie uma conta básica na hora (“on-the-fly”). [Observe que esta abordagem requer uma reflexão sobre a
revogação do provisionamento.]
125
SOA - Arquitetura orientada a serviços

 Sempre que possível, utilize um derivado do atributo (por exemplo, não peça a data de nascimento,ao
invés disso vez questione "se é maior de 18 anos" [se a data de nascimento (do inglês Date of Birthday -
DoB) > (atualmente - 18 anos)].
Ao gerar quaisquer contas exclusivas, decida se o sistema consumirá um único identificador externo da entidade
ou se o sistema terá que gerar seu próprio identificador exclusivo (como um número de referência do cliente).
É preciso refletir cuidadosamente para colocar dentro de sistemas em nuvem o que é mantido nas contas de
usuários. É preciso ter um projeto cuidadosamente pensado de como as contas de usuários em nuvem serão
sincronizadas com as contas de usuários existentes em outros sistemas (internos ou em outros sistemas em
nuvem), particularmente em torno da integração com um processo de "entradas e saídas" e das mudanças no
acesso necessárias quando as pessoas se deslocam internamente. Projete um sistema em nuvem que para
expandir (pense em 100.000 usuários com um nome de usuário desconectados e/ou senha não sincronizadas)
requer a necessidade de evitar forçar um processo normal de suporte técnico (do inglês help desk), que inclua os
scripts de sincronização manual ou semiautomática, os processos de validação de senha forte, os processos de
redefinição de senha , as redefinições de senha após um comprometimento etc., tudo decorrente da falta de
visão sobre o consumo de identidades externas no projeto inicial.
Evite tentar expandir um DS interno para o serviço em nuvem e/ou replicar o DS da organização pela Internet
(normalmente muito insegura) ou através de um canal alternativo (linha dedicada ou VPN), pois isso expõe todo o
DS de uma organização dentro de um ambiente que a organização não controla. É preciso ter cuidado também
com a promessa de produtos de RSO (de fazer login reduzido), já que o RSO geralmente funciona com o
comprometimento em fazer login de segurança interna, ainda mais quando se tenta estender o RSO para um
ambiente em nuvem.
Como regra geral, os serviços em nuvem e, portanto, as aplicações em nuvem, devem aceitar os formatos
padrões de federação SSO, como a SAML e OAuth (ou mesmo a menos aceita amplamente WS-Federation).
Ao projetar uma aplicação para consumir identidade e atributos, lembre-se que a identidade engloba todas as
entidades e, que a segurança da aplicação deve, sempre que possível, ser parte de uma abordagem global, que
inclui todas as camadas; a camada de rede; a camada do sistema; a camada do aplicativo; a camada dos processos
e a camada de dados (como detalhado na secção 12.3). Uma aplicação pode oferecer (por exemplo) dois métodos
de conexão: uma conexão plena e rica utilizando a Web/AJAX/Java ou uma conexão de "captura de tela" (do
inglês screen-scrape) no estilo Citrix com o tipo de conexão permitida, determinada pelas regras de titularidade
(definidas no processo de titularidade).
12.14 Proteção de dados e de identidade
Um problema para todas as organizações é manter os aspectos de uma identidade que contém informações
pessoais identificáveis (do inglês Personal Identifiable Information - PII)126 e, especificamente as informações
classificadas como informações pessoais confidenciais (do inglês Sensitive Personal Information - SPI)127. Os
serviços em nuvem gerenciados ou localizados fora da organização precisarão de consultoria especializada para
garantir que todas as leis e regulamentações aplicáveis estão sendo cumpridas.
A seguinte lista (que não é exaustiva) deve ser pensada ao considerar quais leis ou jurisdições podem ser
aplicadas:
126
PII - Informações pessoais identificáveis
127
SPI - Informações pessoais confidenciais

 Todos os países dos titulares dos dados

 O país em que a organização opera
 Os países nos quais a organização tem entidades jurídicas
 Os países em que a organização negocia na bolsa de valores ou emite ações
 O país ou países em que os serviços em nuvem estão fisicamente localizados
 A legislação pertinente, regulamentações e também pseudorregulamentações (como o PCI-DSS)
12.15 A consumerização e o desafio da identidade
Interagir com os consumidores e/ou dispositivos de consumo traz uma série de desafios e oportunidades em
serviços e aplicações baseados em nuvem. A capacidade dos consumidores e dos dispositivos de consumo fazer a
interface diretamente de um serviço em nuvem voltado para a Internet remove uma camada de complexidade da
rede, mas introduz uma série de desafios de segurança que podem, potencialmente, ser mitigados através da
identidade.
No entanto, no campo do consumidor, os padrões do dispositivo e a identidade do usuário estão fragmentados e

(por definição) raramente têm o mesmo nível de conformidade e padronização que podem ser alcançados em um
ambiente corporativo.
Infelizmente, a maioria dos dispositivos de consumo e os próprios consumidores não têm nenhuma maneira fácil
ou padrão para inscrever seus dispositivos ou a si mesmos em um sistema de autenticação que forneça uma forte
autenticação e, assim, fica difícil uma autorização sem uma forte identidade. Mesmo quando os usuários têm um
método de autenticação forte existente para uma conta (por exemplo, do seu banco), esse quase nunca pode ser
reutilizado com outra conta/provedor. Isso resultou em uma situação onde a identidade para o consumidor já
ultrapassou os limites de extensibilidade. Mais de 61 por cento das pessoas utilizam sempre que podem a mesma
senha128; isso faz com que cada registro ou autenticação adicional cause a perda de clientes em potencial.
Resolver este problema com um acesso direto a aplicações facilitaria os negócios e a clara separação entre a
identidade e a autorização facilitaria utilizações adicionais, por exemplo, permitindo que um indivíduo delegue a
utilização da sua persona associada a um cartão de crédito específico em nome das transações de outro.
12.16 Provedores de serviço de identidade
Consumir informações sobre a identidade de um serviço externo acarreta seus próprios problemas. Os níveis de
confiança na organização provedora e na validação de atributos são apenas dois exemplos. A maioria das
propostas atuais ou as ofertas reais para estruturas de identidade abrangentes e consistentes são extrapolações
das necessidades de players individuais ou em grupo, por aqueles com pouca ou nenhuma compreensão das
necessidades de outras comunidades.
Quase todos os serviços de identidade abertos/públicos consumíveis lidam apenas com a verificação do usuário.
Aqueles que oferecem informações pessoais (atributos, bem como identidade) o fazem utilizando atributos que
são ou autodeclarados, ou de fontes não autorizadas.
Alguns exemplos de fontes de identidade e atributos são os seguintes:
 Governo federal
128
http://www.guardian.co.uk/technology/2008/jan/17/security.banks

o Estados Unidos, NSTIC - apenas estratégia e aspiração
o “EID card” na Alemanha, “Citizen Card” na Áustria, “ID Card” na Estônia, “Citizen Certificate” na
Finlândia, “Smart ID Card” em Hong Kong, “MyCad” na Malásia
 Pública - integração via APIs
o Facebook
o Amazon
o Google
o Microsoft Passport (Windows Live ID)
o Provedores de OpenID (diversos)
o Twitter
 Pontes129 ou “Hubs”
o Ponte Pesquisa/ Educativa (REBCA130), que atende o setor do ensino superior dos Estados Unidos
o Arquitetura de PKI federal (ponte federal) que atende todas as agências federais dos Estados Unidos
o CertiPath/programa global de colaboração de segurança (do inglês Transglobal Secure Collaboration

Program)131, que atende às indústrias aeroespaciais e de defesa
o SAFE-BioPharma Association132, que atende à indústria biofarmacêutica e de saúde
 Serviços que oferecem identidade
o Verifica/valida o meu código de endereçamento postal e o meu endereço (diversos)
o Experian/Equifax
o Verificação 3D card (Visa/MasterCard)
o eBay/PayPal/X.Commerce
12.17.1 Recomendações sobre federação
o Os consumidores, os responsáveis pelas implantações e os provedores devem chegar a um acordo sobre o

contexto e a definição da "federação" que está sendo utilizada.
o Os responsáveis pelas implantações devem compreender qual relação de confiança e confianças

transitórias existem e a necessidade de relações de confiança bidirecionais.
129
www.the4bf.com
130
www.hebca.org
131
www.certipath.com / www.tscp.org/
132
www.safe-biopharma.org/

o Os responsáveis pelas implantações devem, sempre que possível, utilizar a federação baseada em
padrões abertos, como a SAML e a OAuth.
o Se utilizar uma "ponte" ou um "hub da federação", os responsáveis pelas implantações devem então
compreender a natureza e a relação de confiança que existe entre os diferentes membros do clube.
Entender o que isso pode significar para as suas regras de titularidade, caso outro membro não tenha
feito login na nuvem ou na federação em outra ponte.
o Os responsáveis pelas implantações devem entender que os provedores de identidade pública, tais como
o Facebook, o Yahoo ou o Google fornecem uma fonte de identidade (de baixo teor, normalmente
autodeclarada) sem garantias de que eles não irão federar a outros provedores futuramente.
o Os responsáveis pelas implantações devem preterir exemplos de soluções ruins de soluções de projeto
para obter a identidade de um DS vinculado ao sistema de gerenciamento de acesso de uma solução em
nuvem. Tais exemplos incluem as VPNs em banda e as linhas dedicadas fora de banda.
12.17.2 Recomendações de provisionamento e governança
o Todos os atributos devem ser provenientes da fonte de autoridade/principal o mais próximo quanto
possível.
o Como regra geral, o serviço em nuvem ou a aplicação em si deve evitar ser a fonte principal da
identidade.
o O serviço em nuvem ou a própria aplicação só deve ser a fonte principal para os atributos que eles
controlam diretamente.
o Todos os atributos consumidos devem ter um nível de confiança conhecido.
o Todos os atributos consumidos devem estar vinculados a uma identidade.
o O identificador de uma entidade definida deve assinar todos os atributos consumidos.
o Cada atributo deve ter um ciclo de vida que enquadre à finalidade.
o Cada identidade (e seu respectivo identificador) deve ter um ciclo de vida adequado à finalidade.
12.17.3 Recomendações de titularidade
o Todas as partes no processo de titularidade (por definição) devem ser claramente identificadas.
o Deve haver claras responsabilidades designadas para aprovar e desconectar a regra de titularidade.
o Deve ser claramente definido um processo para gerenciar alterações às regras de titularidade.
o Deve ser claramente definida a frequência (ou o gatilho) para auditar as regras de titularidade.
o O processo de titularidade deve focar em produzir regras de titularidade simples e minimalistas e ser
projetado utilizando o princípio do menor privilégio.

o O processo de titularidade deve focar em produzir regras de titularidade que minimizem a exposição da
identidade ou evitem a necessidade de consumir a identidade completamente.
o Os atributos temporais (como a localização geográfica) precisam verificar os atributos em tempo real
através do tempo de vida de uma transação para revalidar as regras de titularidade.
o As regras de titularidade devem ser desencadeadas por um processo (ou pela tentativa de iniciar um
processo, assim como a transferência de dinheiro para fora do ambiente). Em alguns ambientes, a melhor
prática seria que as regras de titularidade desativassem tais funções. Em outros, a melhor prática seria
exigir a identidade ou os atributos adicionais no ponto de execução, para garantir que a entidade tenha
autoridade para realizar o processo.
o Os responsáveis pelas implantações devem garantir a confiança bidirecional para garantir o

relacionamento seguro ideal para a transação. O processo de titularidade deve definir isso.
o O projeto das regras de titularidade deve incluir a delegação de acesso133 por uma entidade secundária
para alguns, mas não necessariamente para todos, da informação que a entidade primária pode acessar.
o O projeto de titularidade deverá incluir a apreensão do acesso (incluindo a apreensão legal), embora o
projetista das regras de titularidade tenha que considerar a jurisdição do sistema, a organização e as
entidades envolvidas. Deve ser obtida uma assessoria jurídica antes de implantar qualquer apreensão de
acesso.
o Onde praticável, as interfaces de gerenciamento, as ferramentas ou outras tecnologias de visualização

devem ser utilizadas para ajudar no gerenciamento de titularidade e ajudar a garantir que a interpretação
atenda os negócios e/ou os requisitos regulatórios (como por exemplo, a norma SOX para divisão de
funções).
12.17.4 Recomendações de autorização e acesso
o Os responsáveis pelas implantações devem garantir que os serviços disponham de uma função de
exportar/importar dentro das normas, como a XACML da OASIS.
o Ao utilizar uma PDP em um ambiente em nuvem, os responsáveis pelas implantações devem entender
como o registro da decisão de autorização seria extraído e/ou integrado dentro de um registro da
organização para uma visão holística do acesso.
o Os responsáveis pelas implantações devem garantir que os serviços existentes (legados) possam interagir
com as PEPs/PDPs.
o Os responsáveis pelas implantações devem garantir que qualquer PDP é adequada para traduzir
corretamente as regras de autorização definidas no processo de titularidade.
o Os responsáveis pelas implantações devem considerar utilizar "política como um serviço" como a política
do servidor, caso precise de uma política de servidor central, por exemplo, para uma mescla em nuvem.
12.17.5 Recomendações de arquitetura
133
A delegação é recém-suportada em XACML 3.0.

o Os responsáveis pelas implantações devem garantir que qualquer provedor de nuvem ofereça as
PEPs/PDPs de gerenciamento de autorização que possam ser configuradas com as regras de titularidade.
o Os responsáveis pelas implantações devem garantir que todos os componentes de gerenciamento de

identidade, titularidade e autorização/acesso (IdEA) funcionem corretamente em conjunto.
o Os responsáveis pelas implantações devem garantir que as políticas de pontos de decisão/aplicação

(PEPs/PDPs) utilizem protocolos padrões (por exemplo, a XACML) e evitem (ou depreciem) protocolos
proprietários (por exemplo, webservice direto ou outras chamadas de middleware).
o Os responsáveis pelas implantações devem assegurar que qualquer serviço de autenticação forte esteja
em conformidade com a arquitetura de referência de autenticação aberta (do inglês Open Authentication
Reference Architecture - OATH134). Com uma solução em conformidade com a OATH, as organizações
podem evitar o bloqueio a um fornecedor de credenciais de autenticação.
o Os serviços e as aplicações em nuvem devem suportar a capacidade de consumir autenticação de fontes

autorizadas utilizando a SAML.
o Os responsáveis pelas implantações devem garantir que os serviços disponham de uma função de
exportar/importar dentro das normas, como a XACML da OASIS.
o Os responsáveis pelas implantações devem garantir que os serviços possam interagir com os PEPs/PDPs
instalados na infraestrutura de nuvem e com a política de pontos de monitoramento para
monitorar/auditar incidentes.
o Os responsáveis pelas implantações devem garantir que o registro da decisão de autorização e acesso
efetivamente concedidos possam ser registrados em um formato comum, utilizando protocolos padrões
de segurança.
12.17.6 Recomendações de titularidade
o Os responsáveis pelas implantações devem garantir que cada identidade e atributos definidos no
processo de titularidade correspondam ao nível de confiança que é necessário (ou é aceitável), tanto para
a identidade/atributos em si como também coincide com a fonte que o fornece.
o Os responsáveis pelas implantações devem garantir que todas as fontes de identidade/atributos forneçam
identidade organizacional.
o Os responsáveis pelas implantações devem garantir que os atributos sejam validados na fonte/principal,
sempre que possível ou o mais próximo possível.
o Os responsáveis pelas implantações devem garantir que a utilização correta dos atributos conduza à
conclusão certa. (Seu contexto pode ser diferente para o autor do atributo).
o Os responsáveis pelas implantações devem garantir que a fonte de identidade/atributos tenha tanto os
padrões de qualidade de dados, como um mecanismo de governança que atenda às suas necessidades.
o Os consumidores devem estar cientes que a confiança na reputação possa ser uma importante fonte de
confiança. Através da definição de titularidade, os consumidores devem estar cientes que as transições de
134
OATH- Arquitetura de referência de autenticação aberta, http://www.openauthentication.org/

pequeno valor levam a um aumento da confiança transacional, que pode ser fraudado em uma grande
transação subsequente.
12.17.7 Recomendações de provisionamento
o Os provedores devem compreender se a SPML ou o SCIM poderia ser uma opção viável para o
provisionamento.
o Os responsáveis pelas implantações devem seguir a regra do menor privilégio ao provisionar uma conta.
No caso de entidades, como os dispositivos de computação, é desejável um link para os registros dos
recursos organizacionais.
o A maioria dos sistemas e aplicações tem uma relação um para um entre o usuário e o acesso e, nenhum
conceito de delegação.
o Os responsáveis pelas implantações devem assegurar que o provisionamento e a revogação do

provisionamento não se limitam à identidade de usuários. As arquiteturas devem incluir a autorização
para todos os tipos de entidade.
o Os responsáveis pelas implantações devem garantir que o provisionamento e a revogação do

provisionamento sejam feitos em tempo real.
o Os provedores devem garantir que a manutenção da identidade e dos atributos seja essencial se a
titularidade é para ser precisa.
12.17.8 Recomendações de conformidade e auditoria de identidade
o Os responsáveis pelas implantações devem garantir que os registros aplicáveis pelo processo de regras de
titularidade/autorização possam ser disponibilizados.
o Os responsáveis pelas implantações devem garantir que os registros precisam estar integrados em um
sistema mais amplo (possivelmente remoto) (por exemplo, para uma maior detecção de fraudes ou
análises de divisão de funções) para garantir que a disponibilidade, pontualidade, formato e segurança de
transmissão dos registros sejam adequadas.
o Ao registrar as decisões de acesso, os responsáveis pelas implantações devem agrupar os atributos,

juntamente com a lógica de titularidade utilizada no momento da decisão e registrar o resultado.
o Todos os participantes da nuvem devem se lembrar de que os atributos com um componente temporal
podem precisar ser revalidados e, portanto, registrados mais uma vez durante o tempo de vida da sessão.
o Sempre que possível, ao registrar as PII ou o SPI, os responsáveis pelas implantações devem utilizar as
derivações dos atributos para minimizar a exposição das PII ou do SPI nos registros.
o Os consumidores devem estar cientes que os registros contendo as PII ou o SPI estarão sujeitos à
legislação de proteção de dados.
12.17.9 Recomendações de projeto de aplicações

o Os responsáveis pelas implantações devem utilizar a definição de camadas da ITU X.805/ definição em 3
camadas de Usuário, Sistema e Gerenciamento para garantir a segregação.
o Os responsáveis pelas implantações devem minimizar a necessidade de identidade e atributos em um

projeto de aplicativo.
o Quando possível, projete sistemas em nuvem para consumir identidade e atributos de fontes externas.
o Os responsáveis pelas implantações devem garantir que o sistema em nuvem suporta formatos da
federação de padrão SSO, como a SAML e a OAuth.
o Os responsáveis pelas implantações devem ter uma abordagem global para a segurança, utilizando a
identidade e os atributos em todas as camadas do sistema.
o Os responsáveis pelas implantações devem se lembrar de que a autenticação mútua é fundamental em

todos os níveis e ainda mais importante em ambientes em nuvem, pois o ambiente em nuvem precisa de
entidades e outros sistemas para autenticar quem são eles, de modo que o sistema em nuvem esteja apto
a autenticar de volta.
12.17.10 Recomendações de proteção de dados
o Os responsáveis pelas implantações devem minimizar o uso e o armazenamento de PII ou SPI. Isto deve
ser feito na fase de projeto do processo de titularidade para garantir que apenas identidades e atributos
essenciais ao processo sejam utilizados.
o Os responsáveis pelas implantações devem considerar as seguintes tecnologias para minimizar a

exposição de PII ou SPI:
 Criptografia
 Geração de tokens
 Criptografia Homomórfica (do inglês Homomorphic Encryption135)
Para obter mais informações consulte o Domínio 11 “Criptografia e Gerenciamento de Chaves".
o Os responsáveis pelas implantações devem considerar a utilização das melhores práticas de abordagens
para proteger a SPI, como utilizar uma abordagem de chave dupla, onde uma é mantida pelo sujeito (ou
digitada ao fazer login) e a outra pelo sistema, para utilização com o processamento.
o Os responsáveis pelas implantações devem saber como o acesso do administrador às PII e SPI pode ser
limitado ou suspenso.
o Os responsáveis pelas implantações devem saber como uma solicitação de acesso do objeto (do inglês
“Subject Access Request136”) pode ser tratada dentro do prazo legal de mandato, especialmente quando
os dados podem ser mantidos em um sistema em nuvem não proprietários/gerenciados pela organização
que recebeu a solicitação.
135
Na época da liberação, a criptografia homomórfica se encontra em fase inicial de implantação de produto.
136
Uma “solicitação de acesso ao objeto” é o direito legal em alguns países de solicitar quaisquer PII ou SPI mantidas por si
mesmas.

o Se for necessário compartilhar a PII ou a SPI, os consumidores devem saber como a aprovação do objeto
da PII/SPI será obtida.
o Os responsáveis pelas implantações devem reduzir a PII/SPI que está sendo armazenada, especialmente
quando não for a fonte oficial e apenas referenciar os atribuídos a partir da fonte autorizada, em vez de
armazená-los (e mantê-los).
o Os responsáveis pelas implantações devem compreender os processos pelos quais a manutenção da

PII/SPI (seja de identidade ou atributos) será tratada em tempo hábil.
12.17.11 Recomendações de implantação de identidade
o Os responsáveis pelas implantações devem partir do princípio de reutilização da identidade em vez da

inscrição única de novos usuários e/ou dispositivos.
o O consumidor deve compreender de onde as fontes existentes de identidade podem fornecer níveis
suficientes de confiança e que possa ser reutilizada.
o Os provedores devem compreender quais atributos sobre o usuário e dispositivos podem ser declarados
em um suficiente nível de confiança para a transação ser realizada.
o Quando apropriado, os consumidores devem permitir que ocorram operações de baixo risco, utilizando
um baixo nível de autenticação. Convoque a identidade necessária apenas quando aumentar o valor/risco
da transação.
o Os provedores devem fornecer uma avaliação crítica da identidade e dos atributos que estão sendo
requeridos durante o processo de titularidade quando considerarem os consumidores e os dispositivos de
consumo.
o Os provedores devem compreender que as tecnologias podem ser utilizadas com dispositivos de consumo
para aumentar os níveis de garantia, especialmente as tecnologias que podem ser utilizadas na base.
o Os consumidores devem compreender onde o gerenciamento de dispositivos de consumo não será

realizado e o nível de garantia que isso proporciona; isto pode variar de nenhuma garantia para uma boa
garantia.
o Os consumidores devem compreender onde um nível de garantia e de responsabilidade legal atua caso
surja um problema com uma transação a partir de um dispositivo de consumo.
12.18 Requisitos
 Os responsáveis pelas implantações devem projetar as camadas de serviços comuns para atuarem de
forma independente, para permitir a remoção de armazenamentos de aplicações sem sacrificar as
políticas e os procedimentos existentes de segurança da informação.
 Todos os participantes da nuvem devem respeitar a integridade da cadeia de suprimento e respeitar as

práticas locais existentes de IAM. Devem ser respeitados os elementos como a privacidade, a integridade
e capacidade de auditoria. A integridade da identidade e a auditoria devem ser preservadas quando

mover dados para fora e/ou desacoplar os fundamentos da solução dentro da arquitetura de serviços na
Web.

DOMÍNIO 13 //
VIRTUALIZAÇÃO
A virtualização é um dos elementos-chave das ofertas de computação em nuvem no modelo de Infraestrutura

como Serviço (IaaS na sigla em Inglês) e das propostas privadas de computação em nuvens. É, também, cada vez
mais usada nas partes que compõem a retaguarda das ofertas de Plataforma como Serviço (PaaS) e Software
como Serviço (SaaS) oferecidas pelos prestadores e é uma tecnologia-chave para o uso de computadores pessoais
virtuais, que podem ser entregues a partir de serviços públicos ou privados de computação em nuvem.
Os benefícios da virtualização são bem conhecidos, incluindo o suporte a múltiplos clientes, a melhor utilização
dos servidores e a consolidação dos centros de processamento de dados. Os provedores de serviços de
computação em nuvem podem alcançar maior densidade computacional que se traduz em melhores margens e
as empresas podem utilizar a virtualização para reduzirem despesas de capital em hardware de servidores, bem
como aumentarem a eficiência operacional.
No entanto, a virtualização traz consigo todas as preocupações de segurança do sistema operacional virtualizado,
juntamente com novas preocupações de segurança sobre o gerenciador das máquinas virtuais (hypervisor), bem
como novas ameaças oriundas de formas específicas de virtualização, ataques denominados “inter-VM” (inter
Virtual Machine) e pontos cegos, preocupações quanto ao desempenho derivadas do uso da CPU e da memória
para o tratamento de questões de segurança e da complexidade operacional a partir do que se denomina
"expansão de VMs" como um inibidor de segurança. Novos problemas como as lacunas relacionadas com a
inicialização automática, com a mistura de dados, a dificuldade de criptografar imagens de máquinas virtuais e a
destruição de dados residuais estão entrando em foco.
Visão Geral. Embora existam várias formas de virtualização, a mais comum é virtualização de sistemas
operacionais e ela é o foco desse domínio, que cobre as seguintes questões relacionadas com a segurança da
virtualização:
 Fortalecimento das máquinas virtuais

A virtualização traz consigo todas as
 Segurança do gerenciador das máquinas virtuais (hypervisor) preocupações de segurança do
 Ataques “inter-VM” e pontos cegos sistema operacional virtualizado,
 Preocupações com o desempenho juntamente com novas ameaças
específicas relacionadas com a
 Complexidade operacional de expansão das máquinas virtuais
virtualização.
 Lacunas relacionadas com a inicialização automática
 Criptografia da máquina virtual
 Mistura de dados
 Destruição de dados das máquinas virtuais
 Adulteração de imagens de máquinas virtuais
 Movimentação de máquinas virtuais

13.1 Preocupações com a Arquitetura do Gerenciador das Máquinas Virtuais

(Hypervisor)
13.1.1 Fortalecimento das Máquinas Virtuais
A proteção e o fortalecimento adequados de uma instância de uma máquina virtual, incluindo o firewall
(entrada/saída), o Host Intrusion Prevention System (HIPS), a proteção de aplicações web, o antivírus, o
monitoramento de integridade de arquivos e o monitoramento de logs podem ser entregues através de um
software em cada máquina virtual ou usando-se outra máquina virtual combinada com API’s137 do gerenciador
das máquinas virtuais (hypervisor).
13.1.2 Segurança do Gerenciador das Máquinas Virtuais (Hypervisor)
O gerenciador das máquinas virtuais (hypervisor) precisa ser fortalecido e bloqueado utilizando-se as melhores
práticas. As principais preocupações das empresas e dos usuários da virtualização devem ser o correto
gerenciamento da configuração e da operação do servidor que hospeda tal gerenciador, bem como a segurança
física do mesmo.
13.1.3 Ataques Inter-VM e Pontos Cegos
A virtualização tem grande impacto sobre a segurança da rede porque as máquinas virtuais podem se comunicar
umas com as outras através do hardware dos próprios servidores, ao invés de uma rede e como resultado, os
controles padrões de segurança baseados em rede tornam-se cegos para esse tipo de tráfego, não podendo
realizar o monitoramento ou o bloqueio do mesmo. Os dispositivos virtuais ajudam na resolução desse problema
e outra abordagem possível é a da virtualização assistida por hardware, que exige integração no nível de API com
os gerenciadores das máquinas virtuais (hypervisors) e com as estruturas de gestão de virtualização. A migração
de máquinas virtuais também é uma preocupação porque um cenário de ataque poderia ser a migração de uma
máquina virtual comprometida em uma zona confiável, onde os controles de segurança de redes tradicionais não
seriam capazes de detectar os comportamentos anormais da mesma e a instalação de um conjunto completo de
ferramentas de segurança em cada máquina virtual é outra abordagem para adicionar uma camada extra de
proteção.
13.1.4 Preocupações com o Desempenho
A instalação de softwares de segurança projetados para servidores físicos em um servidor virtualizado pode
degradar severamente o desempenho, já que algumas tarefas de segurança como a varredura feita pelos
antivírus, por exemplo, são intensivas no uso da CPU e o ambiente compartilhado em servidores virtualizados leva
a contenção de recursos. Especialmente com desktops virtuais ou ambientes de alta densidade, os softwares de
segurança precisam ser capazes de perceber o uso da virtualização ou os mesmos precisam desempenhar funções
de segurança em uma única máquina virtual para poderem ser úteis às outras máquinas virtuais.
13.1.5 Complexidade Operacional de Expansão das Máquinas Virtuais
A facilidade com que as máquinas virtuais podem ser disponibilizadas levou a um aumento no número de pedidos
das mesmas nas empresas e esse fato cria uma superfície de ataque maior, bem como aumenta a probabilidade
de um erro de configuração ou de um erro do operador que pode abrir uma brecha na segurança. Para lidar com
137
API – Application Program Interface

esse tipo de cenário, o gerenciamento baseado em políticas e a utilização de uma estrutura de gerenciamento da
virtualização são fundamentais.
13.1.6 Lacunas Relacionadas com a Inicialização Automática
A facilidade com que uma máquina virtual pode ser parada ou iniciada, combinada com a velocidade com que as
ameaças mudam, cria uma situação onde as máquinas virtuais podem ser configuradas de forma segura quando
estão desligadas, mas tornam-se vulneráveis em função da evolução sofrida pelas ameaças durante a inicialização
ou reinicialização. Para cenários desse tipo, as melhores práticas incluem a segurança baseada em rede e a
aplicação de correções nas próprias maquinas virtuais para inspecionarem o tráfego em busca de ataques
conhecidos antes que eles possam chegar a uma máquina virtual recém-disponibilizada ou recém-iniciada.
Também é possível reforçar os recursos semelhantes ao do NAC138 para isolar máquinas virtuais defasadas em
termos de segurança até que as regras e arquivos padrões sejam atualizados e uma varredura tenha sido
executada.
13.1.7 Criptografia da Máquina Virtual
Imagens de máquinas virtuais são vulneráveis a roubo ou modificação quando estão em estado de dormência ou
de execução e a solução para esse problema é criptografar tais imagens em todas as situações possíveis, mas
sempre observando as considerações relacionadas ao desempenho. Para ambientes de alta segurança ou
altamente regulados, o sacrifício de desempenho vale a pena e a criptografia deve ser combinada com os
controles administrativos, com a DLP e com as trilhas de auditoria para evitar que um snapshot de uma máquina
virtual em execução "fuja para a vida selvagem" e dê ao atacante acesso aos dados da mesma.
13.1.8 Mistura de Dados
Há a preocupação de que diferentes classes de dados (ou máquinas virtuais hospedando diferentes classes de
dados) possam ser misturadas na mesma máquina física e nos termos do PCI139, isso é definido como uma
implantação de modo misto. Recomenda-se o uso de uma combinação de VLANs, firewalls e IDS/IPS140 para
assegurar o isolamento das máquinas virtuais, como um mecanismo para apoiar as implantações nesse tipo de
modo. Também é recomendado o uso da categorização dos dados e o gerenciamento governado por políticas
(como a DLP, por exemplo) para evitar problemas desse tipo porque em ambientes de computação em nuvem
todos os clientes podem, potencialmente, compartilhar o menor denominador comum de segurança que foi
aplicado.
13.1.9 Destruição de Dados das Máquinas Virtuais
Quando uma máquina virtual é movida de um servidor físico para outro, as empresas precisam de garantias de
que nenhuma informação recuperável por outro usuário ou no momento em que o disco tem seu
provisionamento removido permaneça disponível. Limpar a memória/discos ou criptografar todos os dados é
uma solução para esse problema e no caso de chaves de criptografia, deve-se armazená-las em um servidor de
chaves criptográficas governado por políticas e que esteja fora do ambiente virtual. Além disso, se uma máquina
virtual é migrada enquanto estiver em execução, ela pode ser colocada em risco se durante tal migração a
criptografia ou a limpeza adequada dos dados não for usada.
138
NAC – Network Access Control
139
PCI – Payment Card Industry
140
IDS – Intrusion Detection Systems; IPS – Intrusion Prevention Systems

13.1.10 Adulteração de Imagens de Máquinas Virtuais
Os dispositivos virtuais pré-configurados e as imagens de máquinas pode estar mal configurados ou podem ter
sido adulterados antes da inicialização.
13.1.11 Movimentação de Máquinas Virtuais
A capacidade de mover máquinas virtuais de um servidor físico para outro cria uma complexidade para as
auditorias e para o monitoramento de segurança. Em muitos casos, as máquinas virtuais podem ser realocadas
em outro servidor físico (independentemente da localização geográfica) sem criar um alerta ou uma trilha de
auditoria que possa ser rastreada.
o Os clientes devem identificar quais tipos de virtualização o provedor de serviços de computação de

nuvem usa, caso ele use algum.
o Os implementadores devem considerar uma abordagem de segmentação entre ambientes de produção e
ambientes de teste/desenvolvimento e de dados ou cargas de trabalho altamente sensíveis.
o Os implementadores devem levar em consideração as questões de desempenho ao testarem e instalarem
ferramentas de segurança em máquinas virtuais porque pode haver grande variação no rendimento e é
importante considerar ferramentas de segurança de rede e servidores que sejam capazes de tratar a
virtualização adequadamente.
o Em ambientes virtualizados o cliente deve avaliar, negociar e aperfeiçoar os acordos de licenciamento
com os principais fornecedores.
o Implementadores devem garantir cada sistema operacional virtualizado usando o software de
fortalecimento em cada instância ou devem usar uma máquina virtual combinada com API’s141 do
gerenciador das máquinas virtuais (hypervisor).
o Sistemas operacionais virtualizados devem ser complementados de medidas de segurança internas, de
forma que as tecnologias de segurança de terceiros forneçam controles de segurança em camadas e haja
uma redução da dependência de um único fornecedor de plataformas.
o Implementadores devem assegurar que configurações padrões de segurança sigam ou excedam os
patamares mínimos do setor.
o Implementadores devem criptografar imagens de máquinas virtuais quando elas não estiverem em uso.
o Implementadores devem explorar a eficácia e a viabilidade da segregação de máquinas virtuais e criar
zonas de segurança por tipo de uso (por exemplo, computadores pessoais versus servidores), por fase de
produção (por exemplo, desenvolvimento, testes e produção) e por nível de sensibilidade dos dados em
diferentes componentes de hardware, tais como servidores, armazenamento, etc.
o Implementadores devem se certificar de que as ferramentas ou serviços de avaliação de vulnerabilidade
de segurança abranjam as tecnologias de virtualização utilizadas.
o Implementadores devem considerar a implantação de soluções automatizadas de descoberta e de
classificação de dados (como a DLP, por exemplo) em toda a organização para ampliarem a classificação
de dados e o controle entre máquinas virtuais e ambientes.
o Implementadores devem considerar a aplicação de correções nas próprias máquinas virtuais em repouso
ou devem proteger as máquinas virtuais recém-criadas até que elas possam ser corrigidas.
141
API – Application Program Interface

o Implementadores devem entender quais controles de segurança foram implantados externamente às

máquinas virtuais para protegerem as interfaces administrativas (baseada na web, API, etc.) que são
expostas para os clientes.
13.3 Requisitos
 Mecanismos específicos de segurança das máquinas virtuais, incorporados na API do gerenciador das
mesmas (hypervisor), devem ser utilizados para fornecerem monitoramento granular do tráfego que
passa pelo hardware do próprio servidor e será obscuro aos controles tradicionais de segurança de rede.
 Os implementadores devem atualizar a política de segurança para que ela reflita os novos desafios de
segurança provenientes da virtualização.
 Os implementadores devem criptografar os dados acessados por máquinas virtuais usando servidores de
chaves criptográficas governados por políticas, de modo que tais chaves não sejam armazenadas junto
com as máquinas virtuais ou com os dados.
 Os clientes devem estar cientes de situações onde pode haver compartilhamento de máquinas virtuais e
as questões regulatórias podem justificar algum tipo de segregação.
 Os usuários devem validar a origem e a integridade de qualquer imagem ou modelo padrão de máquina
virtual proveniente de terceiros ou, como melhor prática, podem criar as próprias instâncias de máquinas
virtuais.
 Sistemas operacionais virtualizados devem incluir firewall (entrada/saída), Host Intrusion Prevention
System (HIPS142), Network Intrusion Prevention System (NIPS)143, proteção de aplicações web, antivírus,
monitoramento de integridade de arquivos, monitoramento de logs, etc. e as contramedidas de
segurança podem ser entregues através de softwares em cada instância da máquina virtual ou usando-se
outra máquina virtual combinada com API’s do gerenciador das máquinas virtuais (hypervisor).
 Os provedores devem eliminar qualquer backup e sistemas de redundância quando estiverem excluindo e
limpando as imagens das máquinas virtuais.
 Os provedores devem possuir um mecanismo de comunicação que forneça evidências de isolamento e
emita alertas se houver uma violação do mesmo.
142
HIPS – Host Intrusion Prevention System
143
NIPS – Network Intrusion Prevention System

DOMÍNIO 14 //
SEGURANÇA COMO UM SERVIÇO
A computação em nuvem representa uma das mudanças mais significativas que a indústria está vivenciando na
tecnologia da informação. Há um enorme potencial que promete inovações expansivas quando a computação
chegar ao ponto de funcionar como um utilitário. Uma dessas inovações é a centralização dos recursos de
segurança. O setor de segurança tem reconhecido os benefícios de uma estrutura de segurança padronizada
tanto para os provedores como para os consumidores. No contexto do contrato de nível de serviço em nuvem
entre provedores e consumidores, uma estrutura de segurança padronizada toma a forma de um documento que
especifica quais os serviços de segurança são fornecidos, como e onde. Com a maturação de propostas de
segurança baseadas em estruturas padrões, os consumidores em nuvem têm reconhecido a necessidade de
centralizar os recursos da computação para os provedores e consumidores. A adoção da Segurança como um
Serviço (SecaaS) em escala global e o reconhecimento de como a segurança pode ser aprimorada é um dos
marcos de maturidade da nuvem como uma plataforma para as operações de negócios. A implantação em nível
mundial da segurança como uma mercadoria terceirizada reduzirá ao mínimo as distintas variações e os vazios de
segurança.
A SecaaS significa tratar a segurança da empresa a partir da nuvem, - isto é o que a diferencia da maioria dos
outros trabalhos/pesquisas sobre segurança em nuvem. As discussões sobre a segurança em nuvem têm se
concentrado predominantemente sobre como migrar para a nuvem e garantir que a confidencialidade, a
integridade, a disponibilidade e a localização sejam mantidas quando utilizar a nuvem. Por outro lado, a SecaaS
procura proteger os sistemas e os dados em nuvem, assim como as redes empresariais híbridas e tradicionais
através dos serviços baseados em nuvem. Estes sistemas podem estar em nuvem ou mais tradicionalmente,
hospedados dentro das instalações do cliente. Um exemplo disso pode ser a filtragem do AV e de spam
hospedada.
Visão geral. Este domínio abordará os seguintes tópicos:
 A onipresença da Segurança como um Serviço no mercado Este documento corresponde à

publicação da Segurança como um
 As preocupações ao implantar a Segurança como um Serviço
Serviço, bem como a matriz de
 As vantagens de implantar a Segurança como um Serviço controle em nuvem da CSA.
 A diversidade de serviços que podem ser categorizados como da

Segurança como um Serviço
14.1 A onipresença da Segurança como um Serviço
Os clientes estão tanto empolgados quanto nervosos com as perspectivas da computação em nuvem.
Empolgados com as oportunidades de redução dos custos de ativos e por uma chance de abdicar do
gerenciamento da infraestrutura e focar nas competências essenciais. Acima de tudo, estão empolgados com a
agilidade proposta de provisionamento de recursos de computação sob demanda e a capacidade de alinhar a

tecnologia da informação às estratégias de negócios e necessidades mais prementes. No entanto, os clientes

também estão muito preocupados com os riscos da segurança da computação em nuvem e da perda de controle
direto sobre a segurança dos sistemas pelos quais são responsáveis. Os fornecedores têm tentado satisfazer essa
demanda por segurança, oferecendo os serviços de segurança em uma plataforma em nuvem. Mas por terem
muitas formas e a falta de transparência em relação aos controles de segurança implantados, esses serviços
causaram uma confusão no mercado e complicaram o processo de seleção. Até então, isso levou à adoção
limitada de serviços de segurança baseados em nuvem. A Segurança como um Serviço está tendo um crescimento
exponencial e, a Gartner está prevendo que a utilização do serviço de segurança baseado em nuvem em muitos
segmentos mais que triplicará em 2013.
Atualmente, diversos fornecedores de segurança estão aproveitando os modelos baseados em nuvem para
oferecer soluções de segurança. Esta mudança ocorreu por uma série de razões, incluindo as maiores economias
de escala e os mecanismos racionalizados de entrega. Os consumidores estão se voltando cada vez mais para
avaliar as soluções de segurança que não são executadas localmente. Os consumidores precisam conhecer a
natureza única, diversa e abrangente das soluções de segurança em nuvem entregues, para que estejam em
posição de avaliar as propostas e entender se elas satisfarão as suas necessidades.
14.2 As preocupações ao implantar a Segurança como um Serviço
Apesar da impressionante gama de benefícios proporcionados pelos serviços de segurança em nuvem, tais como
a extensibilidade dinâmica, os recursos praticamente ilimitados e as maiores economias de escala existentes com
o menor ou nenhum custo proprietário, existem preocupações sobre a segurança no ambiente de nuvem. Alguns
problemas de segurança são relativos ao cumprimento, ao multilocatário e à dependência a um fornecedor.
Enquanto estes estão sendo citados como inibidores para a migração da segurança para dentro da nuvem, essas
mesmas preocupações existem com centros de dados tradicionais.
A segurança no ambiente em nuvem muitas vezes é baseada na preocupação de que pela falta de visibilidade dos
controles de segurança implantados, os sistemas não sejam bloqueados, bem como eles que estejam em centros
de dados tradicionais e que o pessoal não possua as credenciais adequadas e nem a verificação de antecedentes.
Os provedores de Segurança como um Serviço reconhecem a fragilidade do relacionamento e muitas vezes
chegam a extremos, para assegurar que o seu ambiente está o mais bloqueado possível. Muitas vezes, eles
executam verificações de antecedentes sobre o seu pessoal, que até se equiparam com as mais rígidas
verificações de antecedentes governamentais e, eles as executam com frequência. A segurança física e pessoal é
uma das mais altas prioridades de um provedor de Segurança como um Serviço.
Dado o ambiente regulatório global, a conformidade foi levantada como uma preocupação. Os provedores de
Segurança como um Serviço também reconheceram isso e têm feito grandes esforços para demonstrar a sua
capacidade de não apenas cumprir, mas exceder estes requisitos ou garantir que ela esteja integrada na rede de
um cliente. Os provedores de Segurança como um Serviço devem estar cientes das regulamentações geográficas
e regionais que afetam os serviços e seus consumidores e isso pode ser estabelecido nas propostas e nas
implantações de serviços. Os mais prudentes provedores de Segurança como um Serviço, muitas vezes recorrem
à mediação e aos serviços jurídicos para resolver preventivamente as necessidades de regulamentação do
consumidor, com os requisitos regulamentares regionais de uma jurisdição. Ao implantar uma Segurança como
um Serviço em um setor ou em um ambiente altamente regulamentado, o contrato sobre as métricas que
definem o nível de serviço requerido para alcançar objetivos regulatórios deve ser negociado em paralelo aos
documentos do SLA que definem o serviço.

Como acontece com qualquer serviço de nuvem, o multilocatário apresenta preocupações de perda de dados
entre as instâncias virtuais. Enquanto os clientes estão preocupados com isso, os provedores de Segurança como
um Serviço também estão muito preocupados com a natureza litigiosa da empresa moderna. Como resultado,
uma proposta madura pode incluir precauções importantes para garantir que os dados sejam altamente
compartimentados e quaisquer dados que sejam compartilhados sejam colocados como anônimos para proteger
a identidade e sua origem. Isto se aplica igualmente aos dados que estão sendo monitorados pelo provedor de
SecaaS e aos dados que são por eles mantidos, como o registro e os dados de auditoria que eles monitoram dos
sistemas do cliente (tanto em nuvem como não em nuvem).
Outra abordagem para a natureza litigiosa de ambientes de multilocatários é a elevada análise associada ao
processamento semântico. Os descritores de recursos e a “jurimetria” aplicada, um processo através do qual o
raciocínio jurídico é interpretado como conceito de alto nível e expresso em um formato legível por máquina,
podem ser empregados de forma proativa para resolver qualquer ambiguidade jurídica a respeito de um recurso
compartilhado aplicado.
Quando se utiliza um fornecedor de Segurança como um Serviço, uma empresa coloca alguns, muitos ou todos os
registros de segurança, de conformidade e os relatórios, sob a custódia de um provedor, que algumas vezes pode
ter as próprias normas. No caso da empresa buscar um novo provedor, eles devem se preocupar com uma
transição ordenada e, de alguma forma, encontrar uma maneira para que os dados existentes e os arquivos de
registros sejam traduzidos corretamente e de forma jurídica.
É importante observar que, exceto no multilocatário, cada uma dessas preocupações não é "exclusiva da nuvem"
e sim, são questões enfrentadas tanto pelos modelos internos como pelos modelos terceirizados. Por esta razão,
os controles de segurança não proprietários unificados, tais como os propostos pela matriz de controle em nuvem
(do inglês Cloud Control Matrix) da Cloud Security Alliance, são necessários para ajudar as empresas e os
fornecedores a se beneficiarem do ambiente da Segurança como um Serviço.
14.3 As vantagens de implantar a Segurança como um Serviço
Os potenciais benefícios estratégicos de aproveitar os serviços de segurança centralizados são bem

compreendidos pelos técnicos especialistas que testemunham as eficiências diárias obtidas. Da mesma forma que
a computação em nuvem oferece muitas vantagens tanto para os provedores como para os consumidores, a
Segurança como um Serviço em nuvem oferece muitas vantagens significativas devido a uma série de fatores,
incluindo a agregação de conhecimento, a ampla inteligência acionável e dispor de todo um aparato de
profissionais de segurança à disposição em qualquer instante, para citar alguns. As empresas que estão
ativamente envolvidas na centralização e na padronização das melhores práticas de segurança, normalmente
conseguem economias significativas de custo em médio e em longo prazo, como também vantagens competitivas
sobre seus concorrentes no mercado, em razão das eficiências obtidas. A entrega da Segurança como um Serviço
permite que os usuários de serviços de segurança meçam cada fornecedor através de um padrão de segurança
singular. Assim, é melhor compreender o que eles estão conseguindo.
14.3.1 Vantagens competitivas
As empresas que contratam provedores de serviços de segurança terceirizados obtém uma vantagem competitiva
sobre seus pares devido ao acesso antecipado a informações úteis para a compreensão da proposição de risco de
uma determinada estratégia de TI. Além disso, através da utilização de uma infraestrutura de segurança
centralizada, os consumidores estão mais aptos a conter a inserção de conteúdo indesejável. As empresas que

fazem uso de um terceiro para informar sobre o cumprimento regulatório e medir predicados, ou seja, as
obrigações legais e contratuais hereditárias ligadas a identidades e aos dados, podem colher resultados de
prevenção de litígios onerosos e de multas às quais seus concorrentes sejam vulneráveis. Uma vez que os serviços
de segurança global sejam adotados e aplicados, os provedores colhem os benefícios competitivos de poder
garantir a seus clientes que eles satisfazem as melhores práticas de segurança. Os clientes que utilizam estes
serviços têm a vantagem de poder apontar aos provedores de segurança, como parte da sua estrutura de
conformidade e aos provedores de garantia terceirizados, para comprovar a realização das obrigações do
contrato em nível de serviço.
14.3.2 Melhoria do relacionamento entre o cliente e o fornecedor
Existem vantagens muito claras da segurança como um serviço. A transparência fornecida pela garantia do serviço
terceirizado possibilita aos clientes compreenderem exatamente o que estão recebendo, o que permite a fácil
comparação dos serviços de fornecedores e mantém os fornecedores esclarecidos e de acordo com as normas. Os
serviços de migração permitem a migração de dados e serviços de um fornecedor a outro. Ao aproveitar os
serviços de migração, os consumidores e os provedores estão mais bem capacitados para exercer as pressões de
mercado sobre os seus fornecedores terceirizados, aumentando o valor para as empresas que consomem os
serviços e garantindo a cadeia de suprimentos.
14.4 A diversidade de propostas existentes de segurança como um serviço
A Segurança como um Serviço é mais que um modelo terceirizado de gerenciamento de segurança, ela é um
componente essencial na resiliência e na continuidade da segurança dos negócios. Como controle da resiliência
dos negócios, a Segurança como um Serviço oferece uma série de benefícios. Devido ao modelo flexível dos
serviços entregues via nuvem, os clientes só precisam pagar pela quantidade que necessitam, tais como o número
de estações de trabalho a serem protegidas e não para a infraestrutura e o suporte pessoal para os vários serviços
de segurança. Um provedor de segurança focado proporciona uma expertise maior em segurança que a
normalmente disponível dentro de uma organização. Por fim, a terceirização de tarefas administrativas, como o
gerenciamento de registro, pode economizar tempo e dinheiro, permitindo que uma organização dedique mais
recursos às suas competências primordiais.
A Gartner prevê que os controles de segurança baseados em nuvem para aplicações de mensagens, como
programas antimalware e antisspam gerarão 60 por cento da receita das empresas nesse setor em 2013.
As áreas de Segurança como um Serviço em nuvem que provavelmente interessarão os consumidores e os

profissionais de segurança são:
 Os serviços de identidade e de gerenciamento de acesso
 A prevenção de perda de dados (DLP)
 A segurança na Web
 A segurança de e-mail
 As avaliações de segurança
 O gerenciamento de invasão, detecção e prevenção (IDS/IPS)

 O gerenciamento de eventos e de segurança da informação (SIEM)
 A criptografia
 A continuidade de negócios e recuperação de desastres
 A segurança da rede
14.4.1 Serviços de identidade, titularidade e gerenciamento de acesso
A Identidade como um Serviço é um termo genérico que cobre um ou muitos dos serviços que podem
compreender um ecossistema de identidade, tais como a política de pontos de aplicação (PEP como um Serviço),
a política de pontos de decisão (PDP como um Serviço), a política de pontos de acesso (PAP como um Serviço), os
serviços que fornecem entidades com identidade, os serviços que oferecem atributos e os serviços que fornecem
a reputação.
Todos estes serviços de identidade podem ser fornecidos como um único serviço autônomo, como um serviço do
tipo misturar e combinar múltiplos provedores ou atualmente e, muito provavelmente, uma solução híbrida
pública e privada, de IAM tradicional e de serviços em nuvem.
Estes serviços de identidade devem fornecer controles para identidades, acesso e gerenciamento de privilégios.
Os serviços de identidade precisam incluir as pessoas, os processos e os sistemas que são utilizados para
gerenciar o acesso aos recursos da empresa, assegurando que a identidade de uma entidade seja verificada e
depois conceda o nível correto de acesso com base nessa identidade assegurada. Os registros de auditoria de
atividades, tais como a autenticação e as tentativas de acesso bem sucedidas e fracassadas devem ser
gerenciados pelo aplicativo/solução ou pelo serviço de SIEM. Os serviços de identidade, de titularidade e de
gerenciamento de acesso são um controle técnico de proteção e prevenção.
14.4.2 Prevenção de perda de dados
Ao monitorar, proteger e demonstrar proteção de dados em repouso, em movimento e em uso, tanto na nuvem
como local, os serviços de prevenção de perda de dados (DLP) proporcionam a proteção dos dados que
normalmente são executados por um cliente no desktop ou no servidor e aplicam as políticas nas ações
autorizadas para o determinado conteúdo de dados. Onde estes diferem de amplas regras como ‘não permitir
FTP’ ou ‘não permitir fazer upload para sites’ é no nível que eles reconhecem os dados, por exemplo, o usuário
não pode especificar nenhum documento com números que se parecem com cartões de crédito e que possam ser
enviados por email; qualquer coisa salva para o armazenamento USB é automaticamente criptografada e só pode
ser decodificada em outra máquina de um escritório de propriedade do cliente com a DLP instalada
corretamente; e apenas os clientes com o software DLP funcionando podem abrir os arquivos do servidor de
arquivos. Dentro da nuvem, os serviços de DLP podem ser oferecidos como algo que seja parte da compilação, de
tal forma que todos os servidores estabeleçam para que esse cliente obtenha o software DLP instalado com um
conjunto acordado de regras implantadas. Além disso, o DLP pode aproveitar o ID central ou agentes de nuvem
para aplicar os perfis de utilização. A capacidade de aproveitar um serviço para monitorar e controlar o fluxo de
dados de uma empresa para os diversos níveis na cadeia de suprimentos de serviços em nuvem pode ser utilizado
como um controle preventivo para o transporte entre limites de perímetro e consequente perda dos dados
regulamentados, como das PII144. Essa oferta da DLP é um controle técnico preventivo.
144

14.4.3 Segurança na Web
A segurança da Web é a proteção em tempo real oferecida tanto localmente através da instalação de
software/dispositivo ou através de um Proxy em nuvem ou redirecionando o tráfego da web para o provedor de
nuvem. Isso fornece uma camada adicional de proteção no topo de outra proteção, tais como softwares
antimalware para evitar que o malware entre na empresa através de atividades como a de navegação na Web. As
regras de política em torno dos tipos de acesso à Web e os prazos em que isso é permitido também podem ser
aplicadas através dessas tecnologias. O gerenciamento de autorização de aplicações pode ser utilizado para
fornecer um nível extra de aplicação de segurança granular e contextual para aplicações da Web. A segurança da
Web é um controle técnico protetor, de detecção e reativo.
14.4.4 Segurança de e-mail
A segurança de e-mail deve fornecer o controle sobre o e-mail de entrada e saída, protegendo a organização de
phishing, anexos maliciosos, impondo políticas corporativas, como o uso aceitável e a prevenção de spam e
fornecendo opções de continuidade de negócios. Além disso, a solução deve permitir a criptografia baseada em
políticas de e-mails, bem como a integração com várias soluções de servidores de e-mail. As assinaturas digitais
permitem a identificação e a não rejeição são também características de muitas soluções de segurança de e-mail.
A segurança de e-mail proporciona um controle técnico protetor, de detecção e reativo.
14.4.5 Avaliação de segurança
As avaliações de segurança são terceirizadas ou são auditorias orientadas para o cliente de serviços em nuvem ou
avaliações de sistemas locais através de soluções em nuvem fornecidas com base em padrões do setor.
Avaliações de segurança tradicionais de infraestrutura, aplicações e auditorias de conformidade são bem
definidas e apoiadas por várias normas, como a NIST, a ISO e o CIS145. Existe um conjunto de ferramentas
relativamente maduro e uma série de ferramentas foi implantada utilizando o modelo de entrega de SecaaS. No
modelo de entrega de SecaaS, os assinantes recebem os benefícios típicos desta variante de computação em
nuvem, ou seja, a flexibilidade, o tempo de configuração insignificante, a baixa sobrecarga administrativa e o
pagamento pela utilização, com baixos custos de investimento iniciais.
Embora não seja o foco deste esforço, os desafios adicionais surgem quando essas ferramentas são utilizadas
para auditar ambientes de nuvem. Diversas organizações, incluindo o CSA têm trabalhado com as diretrizes para
ajudar as organizações compreenderem os desafios adicionais:
 Adequação da ferramenta à virtualização, muitas vezes necessária para a auditoria da plataforma da IaaS
 Suporte para estruturas da Web comuns em aplicações de PaaS
 Os controles de conformidade para as plataformas de Iaas, PaaS e, de Saas
 Ferramentas automatizadas de notificação de incidentes e violações para a manutenção da integridade da

cadeia de suprimento em nuvem
 Questionários padronizados para ambientes XaaS, que ajudam a solucionar:
145
CIS-Centro de segurança da Internet

- O que deve ser testado em um ambiente em nuvem?
- Como garantir o isolamento de dados em um ambiente multilocatário?
- O que deve constar em um relatório típico de vulnerabilidade da infraestrutura?
- A utilização de resultados fornecidos pelo provedor de nuvem é aceitável?
14.4.6 Detecção/prevenção de intrusão (IDS/IPS)
Sistemas de detecção e prevenção de intrusão monitoram padrões de comportamento utilizando modelos

baseados em regras, em heurística, ou comportamentais para detectar anomalias na atividade que apresenta
riscos para a empresa. As redes IDS/IPS tornaram-se amplamente utilizadas ao longo da última década por causa
da capacidade de fornecer uma visão granular do que está acontecendo dentro de uma rede corporativa. O
IDS/IPS monitora o tráfego da rede e compara a atividade a uma linha de base através de um mecanismo baseado
em regras ou em análise estatística. O IDS normalmente é implantado em um modo passivo para monitorar
passivamente segmentos confidenciais da rede de um cliente enquanto que o IPS está configurado para
desempenhar um papel ativo na defesa da rede de clientes. Em uma infraestrutura tradicional, isto poderia incluir
zonas desmilitarizadas (DMZs)146 segmentadas por firewalls ou roteadores onde os servidores corporativos da
Web estão localizados ou monitorar conexões para um banco de dados interno. Dentro da nuvem, os sistemas
IDS muitas vezes concentram-se em infraestrutura virtual e atividade de hypervisor cruzado, onde ataques
coordenados podem atrapalhar vários locatários e criar um caos no sistema. Os sistemas de detecção de intrusão
são controles técnicos de detecção e, os sistemas de prevenção de intrusão são controles técnicos de detecção,
proteção e reativos.
14.4.7 Gerenciamento de eventos e de segurança da informação (SIEM)
Os sistemas de gerenciamento de eventos e de segurança da informação (SIEM) agregam (via mecanismos

empurrar ou puxar) registros e eventos de dados de redes virtuais e reais, de aplicações e de sistemas. Esta
informação é então correlacionada e analisada para fornecer relatórios em tempo real e alertas sobre as
informações ou eventos que podem requerer intervenção ou outros tipos de respostas. Os registros normalmente
são coletados e arquivados de uma forma que impede a adulteração, para permitir a sua utilização como
comprovação em quaisquer investigações ou relatórios de históricos. A Segurança como uma Serviço que o SIEM
oferece é um controle técnico de detecção, mas pode ser configurado para ser um controle técnico de proteção e
reativo.
14.4.8 Criptografia
A criptografia é o processo de ofuscar/codificar os dados utilizando algoritmos criptográficos, cujo produto são
dados criptografados (conhecido como texto cifrado). Somente o destinatário ou o sistema que está em posse da
chave correta pode decodificar (remover a criptografia) o texto cifrado. A criptografia para ofuscar os sistemas
geralmente consiste em um ou mais algoritmos de uma ou mais chaves que são computacionalmente difíceis (ou
inviáveis) de quebrar e os sistemas, os processos e os procedimentos gerenciam a criptografia, a decodificação e
as chaves. Cada parte é efetivamente inútil sem a outra, por exemplo, o melhor algoritmo é fácil de "quebrar" se
um invasor puder acessar as chaves por conta de processos fracos.
146
DMZ - DeMilitarized Zone (Zona desmilitarizada)

No caso de funções criptográficas de uma via, uma compilação ou um espalhamento (hash) é criado no lugar.
Funções criptográficas de uma via incluem o espalhamento (hashing), a assinatura digital, a geração de
certificados e renovação e, as trocas de chaves. Geralmente estes sistemas consistem de um ou mais algoritmos
que são facilmente replicados, mas muito resistentes à falsificação, juntamente com os processos e os
procedimentos para administrá-los. A criptografia é classificada como um controle técnico de proteção e
detecção quando é terceirizada para um provedor de Segurança como um Serviço.
14.4.9 Continuidade de negócios e recuperação de desastres
A continuidade dos negócios e a recuperação de desastres são medidas concebidas e aplicadas para garantir a
resiliência operacional em caso de eventuais interrupções de serviço. Elas fornecem soluções flexíveis e confiáveis
de transferências (failover) e recuperação de desastres (DR) para os serviços requeridos em caso de interrupção
do serviço, natural ou manual. Por exemplo, no caso de um cenário de catástrofe local, máquinas em diferentes
locais podem proteger as aplicações naquela localização. Esta Segurança como uma Serviço é um controle técnico
reativo, de proteção e de detecção.
14.4.10 Segurança da rede
A segurança da rede consiste em serviços de segurança que restringem ou alocam o acesso e, que distribuem,
monitoram, registram e protegem os serviços de recursos subjacentes.
Arquitetonicamente, a segurança de rede fornece serviços que tratam os controles de segurança na rede como
um todo, ou aqueles controles que especificamente são abordados na rede individual de cada recurso subjacente.
Em ambientes em nuvem/virtuais e em ambientes híbridos, a segurança da rede é suscetível de ser fornecida
através de dispositivos virtuais em paralelo aos dispositivos físicos tradicionais. É fundamental uma forte
integração com o hypervisor, para garantir a plena visibilidade de todo o tráfego na camada da rede virtual. Esses
fornecimentos de segurança da rede incluem controles técnicos de detecção, proteção e reativos.
14.5 Permissões
 Os responsáveis pelas implantações podem empregar o reconhecimento de padrões das atividades dos
usuários.
 Os responsáveis pelas implantações podem empregar a mediação jurídica segura de métricas de

segurança para o gerenciamento de expectativas do SLA147.
 Os responsáveis pelas implantações podem proporcionar canais confiáveis para os testes de invasão.
o Os responsáveis pelas implantações devem garantir canais de comunicação seguros entre o locatário e o
consumidor.
o Os provedores devem fornecer notificação segura e contínua automatizada ao longo da cadeia de

suprimentos baseada na necessidade do conhecimento.
147

o Os provedores devem fornecer registro seguro das operações internas para o cumprimento do contrato
de nível de serviço.
o Os consumidores devem solicitar a adição de auditoria terceirizada e os serviços de mediação do SLA.
o Todas as partes devem ativar o monitoramento contínuo de todas as interfaces através de interfaces de
segurança padronizadas, como as SCAP (NIST), CYBEX (ITU-T) ou, a RID e a IODEF (IETF).
14.7 Requisitos
14.7.1 Requisitos da Identidade como um Serviço
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o provisionamento/revogação do

provisionamento de contas (tanto para os recursos e aplicações em nuvem como locais).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem a autenticação (de múltiplas formas e
fatores).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o gerenciamento do ciclo de vida da
identidade.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem os serviços de diretório.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem a sincronização de diretório

(multilateral conforme solicitado).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o SSO federado.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o SSO da Web (a aplicação do acesso
granular e o gerenciamento de sessão, - diferente do SSO federado).
 Os provedores de IaaS devem proporcionar aos clientes o monitoramento da seção privilegiada.
 Os provedores de IaaS devem proporcionar aos clientes o gerenciamento do acesso granular.
 Os provedores de IaaS devem proporcionar o armazenamento inviolável dos registros de auditoria

(incluindo a opção de não rejeição).
 Os provedores de IaaS devem proporcionar o gerenciamento de políticas (incluindo as de gerenciamentos

de autorização, função e conformidade).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem a autorização (tanto dos usuários
como de aplicações/sistemas).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o provisionamento e o gerenciamento

de autorização de tokens.

 Os provedores de IaaS devem proporcionar aos clientes em nuvem o gerenciamento de perfis e

titularidade (tanto dos usuários como de aplicações/sistemas).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o suporte para monitorar e/ou relatar
políticas e regulamentações de conformidade.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o provisionamento federado de

aplicações em nuvem.
 Os provedores de IaaS devem proporcionar o gerenciamento de usuários e senhas privilegiadas (incluindo

as contas administrativas, compartilhadas, de sistemas e de aplicações).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o controle de acesso baseado na
função (do inglês Role-Based Access Control - RBAC) (onde for suportado pelo sistema/serviço
subjacente).
 Os provedores de IaaS devem proporcionar aos clientes em nuvem opcionalmente o suporte à integração
da DLP.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem opcionalmente o suporte à atividade
granular de auditoria discriminada individualmente.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem a divisão de funções baseada na
titularidade da identidade.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem os relatórios centrados na

conformidade.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o gerenciamento centrado em

políticas.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem as interfaces utilizáveis de

gerenciamento.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem o controle de acesso unificado e a
auditoria.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem a interoperabilidade e a

heterogeneidade entre os diversos provedores.
 Os provedores de IaaS devem proporcionar aos clientes em nuvem a extensibilidade.
14.7.2 Requisitos da DLP SecaaS

 Os provedores de DLP devem proporcionar aos clientes em nuvem a rotulagem e a classificação dos
dados.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a identificação dos dados
confidenciais.
 Os provedores de DLP devem proporcionar aos clientes em nuvem as políticas pré-definidas para as
principais regulamentações estatutárias.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a heurística de detecção contextual.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a correlação de dados estruturados
(dados em repouso).
 Os provedores de DLP devem proporcionar aos clientes em nuvem a detecção de expressões regulares de
SQL.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a detecção abrangente do tráfego
(dados em movimento).
 Os provedores de DLP devem proporcionar aos clientes em nuvem o conhecimento do usuário em tempo
real.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a atribuição do nível de segurança.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a consulta aos atributos
personalizados.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a resposta a incidentes automatizada.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a assinatura de dados.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a proteção criptográfica dos dados e o
controle de acesso.
 Os provedores de DLP devem proporcionar aos clientes em nuvem a política de linguagem legível por
máquina.
14.7.3 Requisitos de webservices de SecaaS
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem o monitoramento e

a filtragem da Web
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem analisar e bloquear
malwares, spywares e botnets.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem bloquear sites de
phishing.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem fazer a varredura
em aplicações de mensagens instantâneas.

 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem a segurança de e-

mail.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem o gerenciamento de

largura de banda/controle de tráfego.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem a prevenção de

perda de dados.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem a prevenção de

fraudes.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem o controle de

acesso à Web.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem o backup.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem a SSL

(decodificação/transferência (do inglês decryption/hand off).
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem a aplicação das
políticas de utilização.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem o gerenciamento de

vulnerabilidade.
 Os provedores de webservices de SecaaS devem proporcionar aos clientes em nuvem os relatórios de

inteligência da Web.
14.7.4 Requisitos de e-mail SecaaS
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem uma filtragem
precisa para bloquear spam e phishing.
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem uma
aprofundada proteção contra vírus e spywares antes que eles entrem no perímetro da empresa.
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem políticas
flexíveis para definir um fluxo e uma criptografia granular de correio.
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem ricos e
interativos relatórios e correlacioná-los em tempo real.
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem varreduras
aprofundadas de conteúdo para aplicação das políticas.
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem a opção de
criptografar com base na política de alguns/todos os e-mails.
 Os provedores de segurança de e-mail SecaaS devem proporcionar aos clientes em nuvem a capacidade
de integrar diversas soluções de servidores de e-mail.

14.7.5 Requisitos de avaliação de segurança SecaaS
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem os

processos e as métricas detalhadas de governança (os responsáveis pelas implantações devem definir e
documentar o processo pelo qual as políticas são definidas e a tomada de decisão é executada).
 As avaliações de segurança e governança que os provedores proporcionam devem implantar uma solução
automatizada para notificar os membros diretos da sua cadeia de suprimentos em caso de quebra ou
incidente de segurança.
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem o

gerenciamento adequado do risco (os responsáveis pelas implantações devem definir e documentar o
processo para assegurar que os comportamentos e os processos importantes de negócios permaneçam
dentro dos limites associados a essas políticas e decisões).
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem os detalhes
da conformidade (Os responsáveis pelas implantações devem definir e documentar o processo de adesão
às políticas e decisões)
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem as políticas
que podem ser decorrentes de diretivas internas, procedimentos, requisitos ou legislação externa,
regulamentações, normas e contratos.
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem as

auditorias de conformidade técnica (auditoria automatizada das definições de configuração em
dispositivos, sistemas operacionais, bancos de dados e aplicações).
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem avaliações
de segurança de aplicações (auditoria automatizada de aplicações personalizadas).
 Os serviços de avaliação e governança que os provedores oferecem devem proporcionar aos clientes em
nuvem avaliações de vulnerabilidade, - sondagem automatizada de dispositivos da rede, computadores e
aplicações para vulnerabilidades conhecidas e problemas de configuração.
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem os testes de
invasão (exploração de vulnerabilidades e problemas de configuração para ter acesso a um ambiente,
rede ou computador, que normalmente requer assistência manual).
 Os provedores de avaliação de segurança SecaaS devem proporcionar aos clientes em nuvem uma
classificação da segurança.
14.7.6 Requisitos de detecção de intrusão SecaaS
 Os provedores de detecção de intrusão SecaaS devem proporcionar aos clientes em nuvem a

identificação de instrusões e de violações de políticas.
 Os provedores de detecção de intrusão SecaaS devem proporcionar aos clientes em nuvem ações
corretivas automáticas ou manuais.

 Os provedores de detecção de intrusão SecaaS devem proporcionar aos clientes em nuvem dar cobertura
para as cargas de trabalho, a camada de virtualização (VMM/Hypervisor) e o plano de gerenciamento.
 Os provedores de detecção de intrusão SecaaS devem proporcionar aos clientes em nuvem uma inspeção
aprofundada de pacotes utilizando uma ou mais das seguintes técnicas: estatística, comportamental, de
assinatura e heurística.
 Os provedores de detecção de intrusão SecaaS devem proporcionar aos clientes em nuvem o

monitoramento de chamadas ao sistema.
 Os provedores de detecção de intrusão SecaaS devem proporcionar aos clientes em nuvem a inspeção do
registro do sistema/aplicativo.

monitoramento da integridade do sistema operacional (arquivos, registros, portas, processos, software
instalado etc.)

monitoramento da integridade de VMM/Hypervisor.

monitoramento do repositório de imagem da VM.
14.7.7 Requisitos do SIEM SecaaS
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem o registro/evento coletado
em tempo real, a deduplicação, a normatização, a agregação e a visualização.
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem o suporte jurídico.
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem o suporte e os relatórios de
conformidade.
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem o suporte de resposta a
incidentes (IR).
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem a detecção de anomalias não
se limitando ao e-mail.
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem relatórios detalhados.
 Os provedores do SIEM SecaaS devem proporcionar aos clientes em nuvem períodos de retenção de
dados flexíveis e o gerenciamento flexível de políticas.
14.7.8 Requisitos de criptografia SecaaS

 Os provedores de criptografia SecaaS devem proporcionar aos clientes em nuvem a proteção dos dados
em trânsito.
em repouso.
 Os provedores de criptografia SecaaS devem proporcionar aos clientes em nuvem o gerenciamento de

chaves e políticas.
em cache.
14.4.9 Requisitos de continuidade de negócios e de recuperação de desastres
 Os provedores de continuidade de negócios e de recuperação de desastres SecaaS devem proporcionar

aos clientes em nuvem uma infraestrutura flexível.

aos clientes em nuvem um backup seguro.

aos clientes em nuvem operações monitoradas.

aos clientes em nuvem a conectividade de serviços terceirizados.

aos clientes em nuvem os componentes de infraestrutura replicada.

aos clientes em nuvem os dados replicados (dos sistemas principal/crítico).

aos clientes em nuvem a recuperação de dados e/ou aplicações.

aos clientes em nuvem sites alternativos de operação.

aos clientes em nuvem processos e operações testadas e medidas para garantir a resiliência operacional.

aos clientes em nuvem centros de dados e infraestrutura geograficamente distribuída.

aos clientes em nuvem a sobrevivência da rede.
14.7.10 Requisitos de segurança da rede SecaaS

 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem os detalhes das
ameaças aos dados.
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem os detalhes das
ameaças ao controle de acesso.
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem os controles de
acesso e autenticação.
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem os gateways de
segurança (firewalls, WAF, SOA/API).
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem os produtos de
segurança (IDS / IPS, firewall de camada do servidor, monitoramento de integridade de arquivos, DLP,
antivírus, antisspam).
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem o

monitoramento e a resposta a incidentes.
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem a

proteção/mitigação de DoS.
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem “serviços de
base” seguros como os DNSSEC, NTP, OAuth, SNMP, a segmentação do gerenciamento de rede e a
segurança.
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem o

monitoramento do tráfego/fluxo de dados (NetFlow).
 Os provedores de segurança da rede SecaaS devem proporcionar aos clientes em nuvem a integração
com a camada do hypervisor.

REFERÊNCIAS
[1] Security and Economic Benefits of Standardization for Security as a Service. September 2011 Proceedings.
United Nations ITU-T.
[2] Gartner. Gartner Says Security Delivered as a Cloud-Based Service Will More Than Triple in Many Segments by
2013. July 15, 2008. http://www.gartner.com/it/page.jsp?id=722307
[3] Cloud Security Alliance. Defined Categories of Service 2011. https://cloudsecurityalliance.org/wp-

content/uploads/2011/09/SecaaS_V1_0.pdf

Guia Csa V 3.0.1 PT BR Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guia Csa V 3.0.1 PT BR Final

Uploaded by

Copyright:

Available Formats

GUIA DE SEGURANÇA PARA ÁREAS CRÍTICAS

FOCADO EM COMPUTAÇÃO EM NUVEM V3.0

©2011 CLOUD SECURITY ALLIANCE | 0

http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf (este guia na versão em inglês)

http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (a 2ª versão do guia)

http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf (a 1ª versão do guia)

© 2011 Cloud Security Alliance.

©2011 CLOUD SECURITY ALLIANCE | 1

Carta dos Editores ..................................................................................................................................................................7

Uma Observação Editorial Sobre Risco .................................................................................................................................9

Seção I. Arquitetura em Nuvem ...........................................................................................................................................12

Domínio 1: Framework da Arquitetura da Computação em Nuvem ....................................................................................13

Seção II. Governança na Nuvem .............................................................................................................................. 31

Domínio 2: Governança e Gerenciamento de Risco Empresarial..........................................................................................32

Domínio 3: Questões Legais: Contratos e Mapeamento Eletrônico de Informações ...........................................................38

Domínio 4: Gerenciamento de Conformidade e Auditoria ..................................................................................................48

Domínio 5: Gerenciamento da Informação e Segurança de Dados .....................................................................................53

Domínio 6: Interoperabilidade e Portabilidade .....................................................................................................................68

Seção III. Operando na Nuvem ................................................................................................................................. 78

Domínio 7: Segurança Tradicional, Continuidade de Negócios e Recuperação de Desastres .............................................79

Domínio 8: Operações de Centro de Processamento de Dados ...........................................................................................95

Domínio 9: Resposta a Incidentes .........................................................................................................................................99

Domínio 10: Segurança de Aplicação .................................................................................................................................110

Domínio 11: Criptografia e Gerenciamento de Chaves ......................................................................................................137

Domínio 12: Identidade, Titularidade e Gerenciamento de Acesso ...................................................................................145

Domínio 13: Virtualização ...................................................................................................................................................168

Domínio 14: Segurança como um Serviço........................................................... ...............................................................173

©2011 CLOUD SECURITY ALLIANCE | 2

Jerry Archer Dave Cullinane Nils Puhlmann

Alan Boehme Paul Kurtz Jim Reavis

Diretoria da Cloud Security Alliance

©2011 CLOUD SECURITY ALLIANCE | 3

Domínio 1: Chris Hoff, Paul Simmonds

Domínio 2: Marlin Pohlman, Becky Swain, Laura Posey, Bhavesh Bhagat

Domínio 4: Marlin Pohlman, Said Tabet

Domínio 5: Rich Mogull, Jesus Luna

Domínio 7: Randolph Barr, Ram Kumar, Michael Machado, Marlin Pohlman

Domínio 8: Liam Lynch

Domínio 11: Liam Lynch

Domínio 14: Jens Laundrup, Marlin Pohlman, Kevin Fielder

Chris Rezek: Domínios 2, 4, 5, 7, 13, 14

Paul Simmonds: Domínios 1, 6, 10, 11, 12

©2011 CLOUD SECURITY ALLIANCE | 4

Redator/Editor Técnico: Amy L. Van Antwerp

Designer Gráfico: Kendall Scoboria

Diretor de Pesquisa: J.R. Santos

©2011 CLOUD SECURITY ALLIANCE | 5

AGRADECIMENTOS DA VERSÃO BRASILEIRA

Diretoria Cloud Security Alliance – Brazilian Chapter

Luiz Felipe Ferreira

Trend Micro Brasil

©2011 CLOUD SECURITY ALLIANCE | 6

CARTA DOS EDITORES

©2011 CLOUD SECURITY ALLIANCE | 7

Paul Simmonds Chris Rezek Archie Reed

Editores do Guia de Segurança v3.0

©2011 CLOUD SECURITY ALLIANCE | 8

UMA OBSERVAÇÃO EDITORIAL SOBRE RISCO

Identificar o Ativo para a implantação em nuvem

Ou estamos movendo informações para a nuvem, ou realizando transações/processamentos (de todas as

©2011 CLOUD SECURITY ALLIANCE | 9

Questione o seguinte para cada ativo:

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