guia de seguranÇa para Áreas crÍticas focado em computaÇÃo ... · com o amadurecimento da...

GUIA DE SEGURANÇA PARA ÁREAS CRÍTICAS

FOCADO EM COMPUTAÇÃO EM NUVEM V3.0

©2011 CLOUD SECURITY ALLIANCE | 0

GUIA DE SEGURANÇA

PARA ÁREAS CRÍTICAS

FOCADO EM COMPUTAÇÃO

EM NUVEM V3.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).

http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf



http://www.cloudsecurityalliance.org/guidance/





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

http://www.cloudsecurityalliance.org/




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,

segmentação, isolamento, governança, níveis de serviço e

modelos de ressarcimento/faturamento para diferentes públicos

consumidores.

Os consumidores podem optar por utilizar o serviço em nuvem

oferecido por um provedor público baseado em um usuário

individual ou, no caso de hospedagem em nuvem privada, uma

organização pode segmentar usuários como diferentes unidades

de negócios que compartilham uma infraestrutura comum.

Do ponto de vista de um provedor, o multilocatário sugere uma

abordagem de arquitetura e design para possibilitar economias de

escala, disponibilidade, gestão, segmentação, isolamento e

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.

Figura 2 - Multilocatário

Figure 2—Multi-Tenancy

A Infraestrutura como um Serviço

(IaaS), entrega uma infraestrutura de

computação (normalmente uma

plataforma em ambiente virtual) como

um serviço, juntamente com o

armazenamento e a rede em estado

bruto. Em vez de adquirir servidores,

software, espaço de centro de dados

ou equipamentos de rede, os clientes

compram esses recursos como um

serviço totalmente terceirizado.




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

dependendo do modelo de serviços em nuvem do provedor, à

medida que possa implicar em permitir os recursos acima descritos,

nos níveis de infraestrutura, banco de dados ou aplicações. Um

exemplo seria a diferença entre a implantação multilocatário de

uma Infraestrutura como um Serviço (IaaS)2, um Software como um

Serviço (SaaS)3 e uma Plataforma como um Serviço (PaaS)4

Os modelos de implantação em nuvem atribuem diferentes

importâncias ao multilocatário. Porém, mesmo no caso de uma

nuvem privada, uma única organização pode ter uma infinidade de

consultores terceirizados e contratados, bem como o desejo de um

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

O Software como um Serviço (SaaS),

algumas vezes referido como "software

sob demanda", é um modelo de

entrega de software no qual o software

e seus dados associados são

hospedados de modo centralizado

(tipicamente na (Internet) nuvem) e

normalmente são acessados por

usuários que utilizam um “thin client”,

normalmente usando um navegador da

Web através da Internet.




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

infraestruturas de desenvolvimento de aplicações, recursos de

“middleware” e funções, tais como banco de dados, mensagens e

enfileiramento. Estes serviços permitem aos desenvolvedores criarem

aplicações na plataforma com as linguagens de programação e

ferramentas que são suportadas pelas pilhas.

O SaaS por sua vez, é implantado sobre as pilhas subjacentes da IaaS e

da PaaS e fornece um ambiente operacional independente que é usado

para entregar toda a experiência do usuário, incluindo o conteúdo, sua

apresentação, a(s) aplicações(s) e, os recursos de gerenciamento.

Assim, deve ficar claro que existem importantes compensações para

cada modelo em termos de funcionalidades integradas, complexidade

versus abertura (extensibilidade) e segurança. Geralmente, o SaaS

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)

A Plataforma como um Serviço (PaaS),

é a entrega de uma plataforma de

computação e solução de pilha como

um serviço. As propostas de PaaS

facilitam a implantação de aplicações

sem o custo e a complexidade de

comprar e gerenciar o hardware e o

software de base e, o provisionamento

dos recursos de hospedagem. Isso

fornece todas as instalações

necessárias para atender o ciclo de

vida completo de estabelecer e

entregar aplicações e, serviços da Web

totalmente disponíveis na Internet.




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

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

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

http://en.wikipedia.org/wiki/Apache_HTTP_Server

http://en.wikipedia.org/wiki/MySQL

http://en.wikipedia.org/wiki/Database_software

http://en.wikipedia.org/wiki/Perl

http://en.wikipedia.org/wiki/PHP

http://en.wikipedia.org/wiki/Python_(programming_language)

http://en.wikipedia.org/wiki/Web_server




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

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

Figura 4 - Modelo Cloud Cube do Jericho

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.

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

Figura 5 - Mapeamento do Modelo de Nuvem para o Controles de Segurança e Conformidade

http://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

Gerenciamento de Governança e

Risco Empresarial

A capacidade de uma organização governar e medir os riscos empresariais

introduzidos pela computação em nuvem. Itens como precedentes legais para

violações de contrato, a capacidade das organizações de usuários para avaliar

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: Contratos e

Electronic Discovery

Questões legais potenciais ao utilizar a computação em nuvem. As questões

apresentadas nesta seção incluem os requisitos de proteção para os sistemas de

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.

Conformidade e Auditoria

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

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.

Gerenciamento da Informação e

Segurança de Dados

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

controles de compensação que podem ser utilizados para tratar a perda do

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.

Portabilidade e Interoperabilidade

A capacidade de mover dados/serviços de um provedor a outro ou, internalizar

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

Segurança Tradicional, Continuidade

de Negócios e Recuperação de

Desastres

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

possíveis riscos da computação em nuvem, na esperança de aumentar o diálogo

e o debate sobre a avassaladora demanda por melhores modelos de gestão de

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.

Operações de Centro de Dados

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

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.

Resposta aos Incidentes, Notificação

e Correção

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

níveis dos provedores como dos usuários, para permitir o tratamento forense e

adequado de incidentes. Este domínio ajudará a compreender as

complexidades que a nuvem traz para o seu programa atual de tratamento de

incidentes.

Segurança de Aplicações

Proteger o software de aplicação que está em execução ou em

desenvolvimento na nuvem. Isso inclui itens como se é apropriado migrar ou

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

Criptografia e Gerenciamento de

Chaves

Identificar o uso adequado e escalonado de criptografia e gerenciamento de

chaves. Esta seção não é prescritiva, mas é mais informativa para discutir por

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.

Gerenciamento de Identidade e

Acesso

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

percepção para avaliar o quanto uma organização está pronta para conduzir a

gestão baseada em nuvem de Identidades, Direitos e Acessos (do inglês (IdEA)

Identity, Entitlement, and Access Management).




Virtualização

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,

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.

Segurança como um Serviço (Security

as a Service)

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

governança da infraestrutura de segurança a um terceiro de confiança, com as

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

http://www.cloud-standards.org/





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

Gerenciamento de Risco Empresarial

2.1 Governança Corporativa

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

Essa seção faz referência à Matriz de Controles em Nuvem DG-01, IS-02 e ao uso do GRC-XML e CloudAudit para estabelecer resoluções.




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

métodos e processos usados pelas organizações para gerenciarem

riscos e para capturarem oportunidades relacionadas ao

atingimento dos objetivos da companhia. Em um ambiente de

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.

Essa seção faz referência à Matriz de Controles em Nuvem DG-08 e ao uso das diretrizes da ISO31000, ISF e ISACA para estabelecer resoluções.




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

Leis federais dos Estados Unidos da América

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

com outros emitidos pela FTC, obrigam organizações a adotarem medidas de proteção

de segurança e privacidade para o processamento de dados, a requererem precauções

similares em seus contratos com provedores de serviço terceirizado.

Leis estaduais dos Estados Unidos da América

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

que regem questões de segurança da informação geralmente requerem que no mínimo

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

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

mostrarem-se aderentes às mesmas também precisam obrigar seus subcontratados a

fazerem o mesmo.

Regulamentações Internacionais

Muitos países têm adotado leis de proteção de dados que seguem o modelo europeu

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.

Obrigações Contratuais

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,

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

Proibição de transferências cruzando

fronteiras

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

ao local original da informação.

Assim, é importante que usuários de serviços em nuvem saibam onde estão sendo

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)

http://p2pfoundation.net/Cloud_ComputingDefinition

http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database




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.

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

Figura 1 - Ciclo de Vida dos Dados

http://www.securosis.com/blog/data-security-lifecycle-2.0




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

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 2 - Dispositivos de acesso à nuvem

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

Possível Permitido Possível Permitido Possível Permitido

LocalFunção Ator

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. Efficient 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 API - Interface de programação de aplicativo




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

http://msdn.microsoft.com/en-us/library/cc836393.aspx

http://blogs.msdn.com/b/eugeniop/archive/2010/01/12/adfs-wif-on-amazon-ec2.aspx

http://download.microsoft.com/download/6/C/2/6C2DBA25-C4D3-474B-8977-E7D296FBFE71/EC2-Windows%20SSO%20v1%200--Chappell.pdf

http://download.microsoft.com/download/6/C/2/6C2DBA25-C4D3-474B-8977-E7D296FBFE71/EC2-Windows%20SSO%20v1%200--Chappell.pdf

http://www.zimbio.com/SC+Magazine/articles/6P3njtcIjmR/Federation+2+0+identity+ecosystem

http://www.datacenterknowledge.com/archives/2009/07/27/cloud-brokers-the-next-big-opportunity/

http://blogs.oracle.com/identity/entry/cloud_computing_identity_and_access


http://www.burtongroup.com/

http://www.pkware.com/appnote

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

nuvem a compartilhar um entendimento comum de segurança

tradicional (segurança física), com serviço de nuvem. A segurança

tradicional pode ser definida como as medidas tomadas para

garantir a segurança e a existência material de dados e de pessoal

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

Esta seção mapeia para as normas IS-

01 e IS-02 dos Domínios da Matriz de

Controle de Nuvem (do inglês “Cloud

Control Matrix Domains”), bem como

para a norma ISO/IEC 27002 Cláusula 9.




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

Segurança física dos recursos humanos

Continuidade dos negócios

Recuperação de desastres

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

Esta seção mapeia para as normas FS-

01, FS-02, FS-03, and FS-04 dos

Domínios da Matriz de Controle de

Nuvem (do inglês “Cloud Control

Matrix Domains”), bem como para a

norma ISO/IEC 27002 Cláusula 9.




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 SLA - Contrato de nível de serviço




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

pessoal mais próximo dos dados interromper as operações e comprometer

a nuvem. Uma pessoa experiente com acesso físico a um console pode

ignorar as medidas de proteção mais lógicas simplesmente reiniciando o

sistema ou acessando um sistema já ligado com acesso à raiz ou de

administrador. Um armário de cabos pode fornecer o acesso oculto a uma

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)

Esta seção mapeia para as normas IS-

15, FS-05, FS-06, FS-07 e FS-08 dos

Domínios da Matriz de Controle de

Nuvem (do inglês “Cloud Control

Matrix Domains”), bem como para a

norma ISO/IEC 27002 Cláusula 9.




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

Cloud Control Matrix (CCM)

Mapeamento de casos de uso de centros de processamento de dados automatizados

O novo centro de processamento de dados? A computação em 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 Management48 (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

Considerações sobre a CCM e como

novas ideias em termos de centros de

processamento de dados de

computação em nuvem afetam uns

aos outros




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

Assistência Médica (HIPAA50) Instalações de Segurança –

Política de Segurança

Políticas e procedimentos devem ser estabelecidos para manterem um ambiente de trabalho seguro em escritórios, salas, instalações e áreas seguras.

Processamento de Cartão/Pagamentos

(PCI51)

Instalações de Segurança – Acesso do Usuário

O acesso físico a ativos e funções informacionais por usuários e pessoal de apoio deve ser restringido.

Geração de Energia (NERC CIP52)

Instalações de Segurança – Pontos Controlados de

Acesso

Perímetros de segurança física (cercas, muros, barreiras, guardas, portões, vigilância eletrônica, mecanismos de autenticação física, portarias e patrulhas de segurança) devem ser implantados 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

http://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/

http://www.safecode.org/

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

http://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

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

Declaração/Atributo Acesso aos gerentes

de RH corporativos Acesso ao usuário

corporativo Acesso de casa aos gerentes

de RH corporativos (laptop

corporativo)

Acesso de casa pelo

usuário (dispositivo

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

corporativa?) Válido Válido Não Não

Atributo: O usuário é gerente de RH Válido Não Válido Não

Resultado de acesso

Acesso para ler/editar

para todas as contas

do RH

Acesso para

ler/editar apenas

para usuários das

contas do RH

Acesso para ler/editar apenas

para usuários das contas do

RH

Acesso só para ler

apenas para usuários

das contas do RH




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

http://www.rationalsurvivability.com/




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 API - Interface de programação de aplicativo




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

http://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

MODELO EM NUVEM DO

APLICAÇÃO QUE ESTÁ

SENDO IMPLANTADO

INDUTORES

DE AMEAÇAS

ADICIONAIS

EXEMPLOS DE

AMEAÇAS

TESTE DE SEGURANÇA

TRADICIONAL EM

CATEGORIAS AINDA

RELEVANTES

CATEGORIAS DE

TESTES ADICIONAIS

SaaS

Multilocatário

em um nível

de aplicativo

Um locatário

diferente

utilizando a

mesma

infraestrutura do

SaaS ganha acesso

aos dados de

outros locatários

através de

vulnerabilidades

de camadas da

Web (um

escalonamento de

privilégio)

Teste de gerenciamento de configuração

Teste de lógica de negócios

Teste de autenticação

Teste de autorização

Teste de gerenciamento de sessão

Teste de validação de dados

Teste de negação de

Teste de multilocatário (um escalonamento de privilégio)




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)

PaaS Multilocatário

em um nível

de plataforma

O mesmo que

acima

O mesmo que acima O mesmo que acima

IaaS

Multilocatário

em um nível

de

infraestrutura

As deficiências na

segurança de

virtualização

(aplicação

indevida de

zoneamento de

VM, a separação

conduz a

interataques de

VM em múltiplos

locatários da IaaS)

Avaliação da vulnerabilidade da infraestrutura tradicional (é preciso “definir” isso)

Intersegurança de VM/teste de vulnerabilidade

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

http://www.opensecurityarchitecture.org/

http://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

http://bsimm.com/

http://www.opensamm.org/

http://www.opensecurityarchitecture.org/cms/en/library/patternlandscape/251-pattern-cloud-computing

http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf

http://www.infosectoday.com/Articles/Cloud_Security_Challenges.htm

http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf

http://www.technologyreview.in/computing/37197/

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

Abordagens alternativas à criptografia

A criptografia em implantações em nuvem

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

Criptografar ou não criptografar? Eis

a questão. Se sim, como gerenciar as

chaves? Se não, os riscos são muito

altos?




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 PII - Informação pessoal identificável 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.

http://www.caida.org/data/sharing/




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)

http://www.opengroup.org/jericho/Jericho%20Forum%20Identity%20Commandments%20v1.0.pdf

http://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

Interna/perimetrizada

Conectado ao DS interno

as identidades devem ser

mantidas dentro do DS para

serem utilizadas pela aplicação,

potencialmente utilizando

soluções dereduced sing-on.

Capacidade de aceitar múltiplas fontes de

identidade e atributos

Interna/deperimetrizada

Necessário para controlar

rigidamente e se conectar aos

serviços organizacionais,

utilizando túneis VPN no back-

end. Uma arquitetura não

recomendada.

Usa declarações para fornecer identidade e

atributos para acessar os serviços em nuvem.

Externa/perimetrizada

A hospedagem externa significa

estender o perímetro para o

provedor do servidor. A

identidade é estendida em um

ambiente que o consumidor

não gerencia, muitas vezes

colocando uma réplica do DS

para desempenhar naquele

ambiente.



Externa/deperimetrizada

A hospedagem externa significa

estender a identidade interna

em um ambiente estranho, mas

em uma linha dedicada de back-

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.

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

Fonte de identidade nº 1

Fonte de identidade nº 2

Fonte de atributo nº 1

Fonte de identidade e atributo nº 1

Gerenciamento de acesso

Ace

sso à red

e

Ace

sso ao

sistem

a

Ace

sso ao

aplicativo

Ace

sso ao

pro

cesso

Ace

sso ao

s dad

os

Autorização

Regras de titularidade

Processo de titularidade

Figure 1: Sistema de Gerenciamento de Identidade, Titularidade e Acesso Genérico




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

http://www.modeldrivensecurity.org/




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

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

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

de identidade e de atributos

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

Figura 2 - Modelo “Hub & Spoke” Provedores de Serviço

Provedores de identidade/atributos

Agente central




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

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

PEPs distintos, que fazem parte dos serviços em nuvem separados.

Em implantações de maior escala, pode haver uma série de

Figura 3 - Modelo de Forma Livre

Provedores de Serviço

Provedores de identidade/atributos




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

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/

http://www.the4bf.com/

http://www.hebca.org/

http://www.certipath.com/

http://www.tscp.org/

http://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/

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

Segurança do gerenciador das máquinas virtuais (hypervisor)

Ataques “inter-VM” e pontos cegos

Preocupações com o desempenho

Complexidade operacional de expansão das máquinas virtuais

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

A virtualização traz consigo todas as

preocupações de segurança do

sistema operacional virtualizado,

juntamente com novas ameaças

específicas relacionadas com a

virtualização.




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

As preocupações ao implantar a Segurança como um Serviço

As vantagens de implantar a Segurança como um Serviço

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

Este documento corresponde à

publicação da Segurança como um

Serviço, bem como a matriz de

controle em nuvem da CSA.




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 PII - Informação pessoal identificável




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 SLA - Contrato de nível de serviço




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

http://www.gartner.com/it/page.jsp?id=722307

https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf

https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf

guia de seguranÇa para Áreas crÍticas focado em computaÇÃo ... · com o amadurecimento da...

Documents