Guia de Segurança para
Áreas Críticas Focado em
Computação em Nuvem V2.1
Preparado por
Cloud Security Alliance Dezembro 2009 Traduzido por
Cloud Security Alliance – Brazilian Chapter Junho 2010
Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem V2.1
Introdução O guia aqui fornecido é a segunda versão do documento da Cloud Security Alliance, “Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem” (“Security Guidance for Critical Areas of Focus in Cloud Computing”), o qual foi originalmente lançado em Abril de 2009. Os locais de armazenamento para estes documentos são: http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (Versão em inglês deste documento) http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf (Versão 1) Partindo da primeira versão do nosso guia, foi tomada a decisão de separar o guia básico dos domínios principais de pesquisa. Cada domínio de pesquisa está sendo lançado em seu próprio white paper. Estes white papers e uas agendasde lançamento estão hospedadas em: http://www.cloudsecurityalliance.org/guidance/domains/ Em outra mudança da nossa primeira versão, o Domínio 3: Legislação e o Domínio 4: Eletronic Discovery foram combinados em um único. Adicionalmente, o Domínio 6: Gerenciamento do Ciclo de Vida da Informação e o Domínio 14: Armazenamento foram combinados em um único domínio, renomeado para Gerenciamento do Ciclo de Vida de Dados. Isto causou uma reordenação de domínios (13 na nova versão). © 2009 Cloud Security Alliance. Todos os direitos reservados. Você pode baixar, armazenar, exibir no seu computador, visualizar, imprimir e referenciar ao Guia da Cloud Security Alliance em www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf desde que: (a) o guia seja usado exclusivamente para fim pessoal e não comercial; (b) o guia não seja modificado ou alterado de qualquer maneira; (c) o guia não seja redistribuído; e (d) a marca registrada, copyright ou outros avisos não sejam removidos. Você pode citar partes do guia conforme permitido pela Fair Use provisions of the United States Copyright Act, desde que você atribua ao Guia da Cloud Security Alliance Versão 2.1 (2009).
Copyright © 2009 Cloud Security Alliance
3
Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem V2.1
Sumário Introdução ..................................................................................................................... 3 Prefácio .......................................................................................................................... 5 Carta dos Editores ......................................................................................................... 9 Nota Editorial Sobre Risco: Decidindo O Que, Quando e Como Mover Para a Nuvem .......................................................................................................................... 11 Seção I. Arquitetura da Nuvem .................................................................................. 14 Domínio 1: Framework da Arquitetura de Computação em Nuvem ........................... 15 Seção II. Governança na Nuvem................................................................................. 33 Domínio 2: Governança e Gestão de Risco Corporativo............................................. 34 Domínio 3: Aspectos Legais e Electronic Discovery .................................................. 39 Domínio 4: Conformidade e Auditoria ....................................................................... 41 Domínio 5: Gerenciamento do Ciclo de Vida das Informações .................................. 44 Domínio 6: Portabilidade e Interoperabilidade ........................................................... 50 Seção III. Operando na Nuvem................................................................................... 53 Domínio 7: Segurança Tradicional, Continuidade de Negócios e Recuperação de Desastres ................................................................................................................... 54 Domínio 8: Operações e Data center ......................................................................... 56 Domínio 9: Resposta a Incidente, Notificação e Remediação ..................................... 59 Domínio 10: Segurança de Aplicações ....................................................................... 62 Domínio 11: Criptografia e Gerenciamento de Chaves............................................... 65 Domínio 12: Gerenciamento de Identidade e Acesso. ................................................ 68 Domínio 13 - Virtualização ....................................................................................... 73 Referencias .................................................................................................................. 75
Copyright © 2009 Cloud Security Alliance
4
Prefácio
Bem vindo à segunda versão do “Guia de Segurança para Áreas Critícas Focado em Computação em Nuvem” da Cloud Security Alliance. Como a marcha da Cloud Security Alliance continua, temos novas oportunidades e novos desafios de segurança. Nós humildemente esperamos fornecer a vocês instruções e inspiração para suportar as necessidades do seu negócio enquanto gerenciam novos riscos. Embora a Cloud Security Alliance seja mais conhecida por este guia, ao longo dos próximos meses você verá uma ampla variedade de atividades, incluíndo capítulos internacionais, parcerias, novas pesquisas e atividades orientadas a promover nossa missão. Você pode acompanhar nossas atividades em www.cloudsecurityalliance.org. O caminho para proteger a Computação em Nuvem é de fato longo e exige a participação de um amplo conjunto de interessados e uma base global. Entretanto, devemos orgulhosamente reconhecer o progresso que estamos vendo: novas soluções de segurança na nuvem estão aparecendo regularmente, organizações estão utilizando nosso guia para contratar provedores de serviços de nuvem e uma discussão saudável sobre conformidade e questões de confiança surgiu pelo mundo. A vitória mais importante que conquistamos é que profissionais de segurança estão vigorosamente engajados em proteger o futuro, mais do que simplesmente proteger o presente. Por favor, continue engajado neste assunto, trabalhando conosco para completarmos essa importante missão.
Atenciosamente,
Jerry Archer Alan Boehme Dave Cullinane Paul Kurtz Nils Puhlmann Jim Reavis
Diretoria Cloud Security Alliance
Agradecimentos Editores Glenn Brunette
Rich Mogull
Colaboradores Adrian Seccombe Alex Hutton Alexander Meisel Alexander Windel Anish Mohammed Anthony Licciardi Anton Chuvakin Aradhna Chetal Arthur J. Hedge III Beau Monday Beth Cohen Bikram Barman Brian O’Higgins Carlo Espiritu Christofer Hoff Colin Watson David Jackson David Lingenfelter David Mortman David Sherry David Tyson Dennis Hurst Don Blumenthal Dov Yoran Erick Dahan Erik Peterson Ernie Hayden Francoise Gilbert Geir Arild Engh-Hellesvik Georg Hess Gerhard Eschelbeck Girish Bhat Glenn Brunette Greg Kane Greg Tipps Hadass Harel James Tiller Jean Pawluk Jeff Reich Jeff Spivey
Jeffrey Ritter Jens Laundrup Jesus Luna Garcia Jim Arlen Jim Hietala Joe Cupano Joe McDonald Joe Stein Joe Wallace Joel Weise John Arnold Jon Callas Joseph Stein Justin Foster Kathleen Lossau Karen Worstell Lee Newcombe Luis Morales M S Prasad Michael Johnson Michael Reiter Michael Sutton Mike Kavis Nadeem Bukhari Pam Fusco Patrick Sullivan Peter Gregory Peter McLaughlin Philip Cox Ralph Broom Randolph Barr Rich Mogull Richard Austin Richard Zhao Sarabjeet Chugh Scott Giordano Scott Matsumoto Scott Morrison Sean Catlett Sergio Loureiro
Copyright © 2009 Cloud Security Alliance
6
Shail Khiyara Shawn Chaput Sitaraman Lakshminarayanan Srijith K. Nair Subra Kumaraswamy Tajeshwar Singh Tanya Forsheit
Copyright © 2009 Cloud Security Alliance
Vern Williams Warren Axelrod Wayne Pauley Werner Streitberger Wing Ko Yvonne Wilson
7
Agradecimentos da versão Brasileira Diretoria Cloud Security Alliance – Brazilian Chapter Leonardo Goldim Jordan M. Bonagura Anchises Moraes Olympio Rennó Ribeiro Jr Jaime Orts Y Lugo Editores Hernan Armbruster Thiago Bordini Colaboradores Alessandro Trombini Alexandre Pupo Anchises Moraes Denyson Machado Dino Amaral Eder Alvares Pereira de Souza Filipe Villar Gabriel Negreira Barbosa Gilberto Sudré Guilherme Bitencourt Guilherme Ostrock Hernan Armbruster Jaime Orts Y Lugo Jimmy Cury Jordan M. Bonagura Julio Graziano Pontes
Leonardo Goldim Luís Felipe Féres Santos Marcelo Carvalho Marcelo Pinheiro Masaishi Yoshikawa Miguel Macedo Milton Ferreira Nelson Novaes Neto Olympio Rennó Ribeiro Jr Rafael B. Brinhosa Raphael Sanches Reginaldo Sarraf Ricardo Makino Roney Médice Uélinton Santos
Carta dos Editores É difícil de acreditar que há curtos sete meses, nós juntamos um grupo diversificado de profissionais de todos os cantos do setor de tecnologia para publicar o primeiro “Guia de Segurança para Áreas Críticas em Computação em Nuvem”. Desde seu lançamento, essa publicação tem excedido nossas expectativas continuamente ao ajudar organizações ao redor do mundo na tomada de decisão quanto a se, quando e como elas devem adotar os serviços e a tecnologia de Computação em Nuvem. Mas ao longo destes sete meses nosso conhecimento e a tecnologia de Computação em Nuvem têm evoluído em um grau surpreendente. Essa segunda versão tem o objetivo de fornecer novos conhecimentos e uma maior profundidade para apoiar essas decisões desafiadoras. Adotar Computação em Nuvem é uma decisão complexa envolvendo inúmeros fatores. Nossa expectativa é que o guia contido neste trabalho ajude você a entender melhor quais perguntas fazer, as melhores práticas recomendadas e as armadilhas a serem evitadas. Através do nosso foco nas questões centrais da segurança em Computação em Nuvem, nós tentamos trazer uma maior transparência para um panorama complicado, que é frequentemente preenchido com informações incompletas. Nosso foco nos 15 domínios originais (agora consolidados em 13) serve para especificar e contextualizar a discussão sobre segurança em Computação em Nuvem: habilitandonos a ir além das generalizações brutas e entregar recomendações mais objetivas e perspicazes. Em nossa jornada, temos sido procurados por uma crescente lista de organizações do setor, corporações e profissionais que acreditam na nossa missão de desenvolver e promover as melhores práticas para garantir a segurança na Computação em Nuvem. Suas perspectivas e conhecimentos tem sido essenciais na criação de um trabalho sensato e imparcial que continua servindo como uma excelente base sobre a qual podemos continuar trabalhando. Computação em Nuvem é ainda um panorama em rápida evolução, que nos obriga a permanecer atualizados ou ficamos para trás. Nesta publicação da segunda versão do nosso guia, nós partimos da experiência e especialização coletiva da nossa grande e diversificada comunidade de voluntários para criar um trabalho mais completo com maiores detalhes e precisão. Ainda assim, nós não devemos estar satisfeitos. Como profissionais de segurança tem feito por anos, nós devemos continuar a evoluir nossos processos, métodos e técnicas à luz das oportunidades que a Computação em Nuvem trás para nosso setor. Essa evolução é essencial para nosso sucesso a longo prazo conforme encontramos novos modos para aperfeiçoar a eficácia e eficiência da nossa capacidade de execução de monitoramento de segurança. Computação em nuvem não é necessariamente mais ou menos segura que o seu ambiente atual. Assim como qualquer nova tecnologia, ela cria novos riscos e novas oportunidades. Em alguns casos, migrar para nuvem prevê uma oportunidade de reestruturas aplicações antigas e infraestrutura para adequar ou exceder requisitos modernos de segurança. Às vezes o risco de mover dados confidenciais e aplicações para uma infraestrutura emergente pode estar além da sua tolerância. Nosso objetivo neste guia não é dizer exatamente o que, onde ou como você deve migrar para nuvem, mas fornecer a você recomendações práticas e questões básicas para fazer uma migração mais segura possível, em seus termos. Finalmente, em nome da Cloud Security Alliance e do Editorial Working Group, nós gostaríamos de agradecer a cada voluntário por todo seu tempo e esforço que foi colocado no desenvolvimento deste novo documento. Estávamos sempre insipirados pela dedicação das equipes em ampliar e aperfeiçoar suas respectivas áreas e acreditamos que seus esforços
Copyright © 2009 Cloud Security Alliance
9
adicionaram um valor significativo a este trabalho. Este documento não seria o que é sem suas contribuições. Como sempre, estamos ansiosos para ouvir seu feedback sobre essa atualização do guia. Se você achou este guia útil ou gostaria de ver ele melhorado, por favor, considere associar-se a Cloud Security Alliance como um membro ou colaborador.
Glenn Brunette Rich Mogull Editores
Copyright © 2009 Cloud Security Alliance
10
Nota Editorial Sobre Risco: Decidindo O Que, Quando e Como Mover Para a Nuvem Ao longo deste guia nós fazemos extensas recomendações na redução do risco quando você adota Computação em Nuvem, mas nem todas as recomendações são necessárias ou realistas para todos os cenários. Como compilamos informações de diferentes grupos de trabalhos durante o processo de edição, rapidamente percebemos que simplesmente não havia espaço suficiente para fornecer recomendações completamente diferenciadas em todos os cenários possíveis de risco. Assim como uma aplicação crítica pode ser tão importante para migrar para um provedor de nuvem pública, pode ter pouca ou nenhuma razão para aplicar controles de segurança ao se migrar dados de baixo valor para um armazenamento baseado na nuvem. Com tantas opções diferentes de implantação de nuvem – incluindo o modelo de serviço SPI (Software as a Service, Platform as a Service ou Infrastructure as a Service, explicados com maiores detalhes no Domínio 1), implantações públicas vs privadas, hospedagem interna vs externa e várias permutações híbridas – nenhuma lista de controles de segurança pode cobrir todas as cirscunstâncias. Como em qualquer área da segurança, organizações devem adotar uma abordagem baseada em riscos para migrar para nuvem e selecionar as opções de segurança. A seguir está um framework simples para ajudar a avaliar inicialmente os riscos e informar as decisões de segurança. Este processo não é um framework completo de avaliação de riscos, nem uma metodologia para determinar todos os requisitos de segurança. É um método rápido para avaliar sua tolerância em mover um ativo para vários modelos de Computação em Nuvem.
Identificar o Ativo Para Implantação na Nuvem Simplesmente, os ativos suportados pela nuvem se dividem em duas categorias: 1. 2.
Dados Aplicações/Funções/Processamento
Estamos movendo informações para nuvem ou operações/processamento (de funções parciais ou até aplicações completas). Com a Computação em Nuvem nossos dados e aplicações não precisam estar no mesmo local e podemos até mudar apenas partes de funções para a nuvem. Por exemplo, podemos hospedar nossa aplicação e dados no nosso próprio data center, enquanto ainda terceirizamos uma parte de sua funcionalidade para a nuvem através do modelo Platform as a Service. O primeiro passo ao avaliar um risco na nuvem é determinar exatamente que dado ou função está sendo considerado mover para a nuvem. Isto deve incluir potenciais utilizações do ativo uma vez que este seja migrado para a nuvem para considerar o aumento do escopo. Volumes de dados e de transações são frequentemente maiores que o esperado.
Avalie o Ativo O próximo passo é determinar qual importância do dado ou função para a organização. Você não precisa realizar uma avaliação detalhada a menos que sua organização possua um processo para
Copyright © 2009 Cloud Security Alliance
11
isso, mas você precisa de, pelo menos, uma avaliação do quão sensível o ativo é e do quão importante a aplicação/função/processo é. Para cada ativo, faça as perguntas abaixo: 1. Como poderíamos ser prejudicados se o ativo se tornou amplamente público e distribuído? 2. Como poderíamos ser prejudicados se um funcionário do provedor de serviço de nuvem acessou o ativo? 3. Como poderíamos ser prejudicados se o processo ou função foi manipulado por terceiros? 4. Como poderíamos ser prejudicados se o processo ou função falhar ao fornecer os resultados esperados? 5. Como poderíamos ser prejudicados se a informação/dado for alterada inesperadamente? 6. Como poderíamos ser prejudicados se o ativo estiver indisponível por um período de tempo? Essecialmente estamos analisando os requisitos de confidencialidade, integridade e disponibilidade para o ativo e como estes são afetados se manuseados na nuvem. É muito similar a analisar um projeto de terceirização, exceto que com Computação em Nuvem temos uma gama maior de opções de implantação, incluíndo modelos internos.
Mapear o Ativo ao Modelo de Implantação em Potencial Agora nós devemos entender a importância do ativo. Nosso próximo passo é determinar qual modelo de implantação será mais confortável adotar. Antes de começarmos a buscar por potenciais provedores, nós devemos saber se nós podemos aceitar os riscos implícitos aos vários modelos (privado, público, comunitário ou hibrido) e aos modos de hospedagem (interno, externo ou combinado). Para cada ativo, determine se você está disposto a aceitar as seguintes opções: 1. Público. 2. Privado, interno/dentro da organização. 3. Privado, externo (incluindo infraestrutura dedicada ou compartilhada). 4. Comunitário, levando em conta o local da hospedagem, provedor de serviço em potencial e identificar outros membros da comunidade. 5. Hibrido. Para avaliar efetivamente o potencial de implantação hibrida, você deve ter em mente pelo menos uma estrutura aproximada de onde os componentes, funções e dados serão hospedados. Neste estágio você deve ter uma boa idéia do seu nível de conforto na transição para a nuvem e qual modelo e local de implantação adequados para seus requisitos de segurança e riscos.
Avalie Potenciais Modelos de Serviços na Nuvem e Provedores Neste passo o foco é no grau de controle que você terá em cada camada de SPI para implementar qualquer gerenciamento de riscos necessário. Se você estiver avaliando uma oferta específica, neste ponto você pode mudar para uma avaliação de riscos completa. Seu foco será no nível de controle que você tem que implementar para mitigar os riscos nas diferentes camadas de SPI. Se você já possui requisitos especificos (ex.: para manipulação de dados regulamentados) você pode incluir nesta avaliação.
Copyright © 2009 Cloud Security Alliance
12
Esboçar o Potencial Fluxo de Dados Se você está analisando uma opção específica de implementação, mapeie o fluxo de dados entre sua organização, o serviço de nuvem e qualquer cliente/outros pontos de acesso. Enquanto a maioria destes passos for de alto nível, antes de tomar a decisão final é absolutamente necessário entender se e como os dados podem se mover para dentro e fora da nuvem. Se você ainda tem que decidir em uma oferta em especial, você vai querer esboçar um rascunho do fluxo de dados para qualquer opção da sua lista de aceitação. Isto é para garantir que quando você tomar sua decisão final, você será capaz de identificar pontos de exposição aos riscos.
Conclusões Agora você deve entender a importância do que você está considerando mover para a nuvem, sua tolerância ao risco (pelo menos em alto nível) e que combinações de modelos de implantações e serviços são aceitáveis. Você também terá uma idéia aproximada dos potenciais pontos de exposição das informações e operações sensíveis. Este conjunto deve dar a você contexto suficiente para avaliar qualquer outro controle de segurança neste guia. Para ativos menos valiosos você não precisa ter o mesmo nível de controles de segurança e pode pular muitas das recomendações – como inspeções locais, facilidade de descoberta e esquemas complexos de criptografia. Um ativo valioso e regulamentado implicará em requisitos de auditoria e retenção de dados. Para outros ativos valiosos e não sujeitos a restrições de regulamentações, você pode focar mais em controles técnicos de segurança. Devido ao nosso espaço limitado, bem como a profundidade a quantidade de material para cobrir, este documento contém listas extensivas de recomendações de segurança. Nem todas as implantações de nuvem precisam de todos os controles de risco e segurança possíveis. Empregando um pouco de tempo antecipadamente em uma avaliação da sua tolerância ao risco e potenciais exposições proporcionará o contexto que você precisa para escolher a melhor opção para sua organização e implementação. Colaboradores da Versão Brasileira: Alexandre Pupo, Leonardo Goldim
Copyright © 2009 Cloud Security Alliance
13
Seção I. Arquitetura da Nuvem
Copyright © 2009 Cloud Security Alliance
14
Domínio 1: Framework da Arquitetura de Computação em Nuvem Este domínio, o Framework da Arquitetura de Computação em Nuvem, descreve um framework conceitual para o resto do guia da Cloud Security Alliance. O conteúdo deste domínio foca na descrição de Computação em Nuvem, que é especificamente adaptada para a perspectiva única dos profissionais de segurança e de redes. As próximas três seções definem esta perspectiva em termos de:
A terminologia usada por todo o guia, para fornecer um vocabulário consistente. Os requisitos de arquitetura e desafios para proteger as aplicações e serviços em nuvem. Um modelo referencial que descreve a taxonomia dos serviços e arquiteturas em nuvem.
A seção final deste domínio fornece uma introdução resumida para cada um dos demais domínios do guia. Entender o framework arquitetônico descrito neste domínio é um primeiro passo importante na compreensão do restante do guia da Cloud Security Alliance. O framework define muito dos conceitos e termos usados por todos os outros domínios.
O que é Computação em Nuvem? Computação em nuvem (“Nuvem”) é um termo em evolução que descreve o desenvolvimento de muitas das tecnologias e abordagens existentes em computação para algo distinto. A nuvem separa as aplicações e os recursos de informação de sua infraestrutura básica, e os mecanismos utilizados para entregá-los. A nuvem realça a colaboração, agilidade, escalabilidade e disponibilidade, e oferece o potencial para redução de custos através de computação eficiente e otimizada. Mais especificamente, a nuvem descreve o uso de uma coleção de serviços, aplicações, informação e infraestrutura composta por pools de recursos computacionais, de rede, de informação e de armazenamento. Estes componentes podem ser rapidamente organizados, provisionados, implementados, desativados, e escalados para cima ou para baixo, provendo um modelo de alocação e consumo baseado na demanda de recursos. Sob a perspectiva da arquitetura, há muita confusão em torno de como a nuvem é tanto similar e diferente dos modelos computacionais existentes, e como estas similaridades e diferenças impactam nas abordagens organizacionais, operacionais, e tecnológicas para as práticas de segurança da informação e de redes. Existem muitas definições atualmente que tentam endereçar a nuvem da perspectiva de acadêmicos, arquitetos, engenheiros, desenvolvedores, gerentes e consumidores. Este documento foca na definição que é especificamente desenhada para a perspectiva única dos profissionais de segurança de TI (Tecnologia da Infomação) e redes. As chaves para entender como a arquitetura da nuvem impacta a arquitetura de segurança são baseados em uma nomenclatura comum e concisa, associada com uma taxonomia consistente de ofertas de como os serviços e arquiteturas de serviços na nuvem podem ser interpretadas, mapeadas para um modelo de controles compensatórios de segurança e operacionais, frameworks de análise e gerenciamento de risco, e de acordo com padrões de conformidade.
Copyright © 2009 Cloud Security Alliance
15
O que compreende a Computação em Nuvem? A versão anterior do guia da Cloud Security Alliance utilizava definições que foram escritas antes da publicação de trabalho dos cientistas do U.S. National Institute of Standards and Technology (NIST) e seus esforços em definir Computação em Nuvem. A publicação do NIST é geralmente bem aceita, e nós a escolhemos para estarmos alinhados com a definição de trabalho do NIST para Computação em Nuvem (versão 15 no momento em que este texto foi criado) trazendo assim coerência e consenso no uso de uma linguagem comum, de forma que podemos focar em casos de uso e não em aspectos semânticos. É importante notar que este guia tem a intenção de ser usado amplamente e aplicável para organizações globalmente. Enquanto o NIST é uma entidade governamental americana, a seleção deste modelo de referência não deveria ser interpretada de forma a sugerir a exclusão de outros pontos de vista ou de outras regiões geográficas. O NIST define Computação em Nuvem descrevendo cinco características essenciais, três modelos de serviço e quatro modelos de implementação. Eles estão sumarizados visualmente na figura 1 e explicados em detalhes a seguir.
Figura 1 – Modelo Visual de Definição de Computação em Nuvem do NIST
Copyright © 2009 Cloud Security Alliance
16
Características Essenciais de Computação em Nuvem Os serviços na nuvem apresentam cinco características essenciais que demonstram suas relações e diferenças das abordagens tradicionais de computação:
Auto-atendimento sob demanda. Um consumidor pode unilateralmente provisionar capacidades computacionais como tempo de servidor e armazenamento de rede automaticamente conforme necessário, sem requerer interação humana com o provedor de serviços.
Amplo acesso a rede. Capacidades estão disponíveis na rede e acessadas através de mecanismos padrões que promovem o uso por plataformas heterogêneas de clientes leves (thin clients) ou não (por exemplo, telefones celulares, laptops, e PDAs) assim como outros serviços de software tradicionais ou baseados em nuvem.
Pool de Recursos. Os recursos de computação do provedor estão reunidos para servir a múltiplos consumidores usando um modelo multilocação, com diferenças físicas e recursos virtuais dinamicamente atribuídos e retribuídos de acordo com a demanda do consumidor. Existe um grau de independência de localização nisto que o consumidor geralmente não tem controle ou conhecimento sobre a localização exata dos recursos providos, mas pode ser capaz de especificar a localização em um nível mais alto de abstração (por exemplo, país, estado ou Data Center). Exemplos de recursos incluem armazenamento, processamento, memória, largura de banda, e máquinas virtuais. Até nuvens privadas tendem a reunir recursos entre diferentes partes da mesma organização.
Elasticidade Rápida. Capacidades podem ser rapidamente e elasticamente provisionadas – em alguns casos automaticamente – para rapidamente escalar, disponibilizar e escalar de volta. Para o consumidor, as capacidades disponíveis para o provisionamento geralmente parecem ser ilimitadas e podem ser contratadas em qualquer quantidade e a qualquer hora.
Serviços mensuráveis. Sistemas em Nuvem automaticamente controlam e otimizam o uso de recursos alavancando a capacidade de mensurar em algum nível de abstração apropriado para o tipo de serviço (por exemplo. armazenamento, processamento, largura de banda ou contas de usuário ativas). O uso de recursos pode ser monitorado, controlado e relatado – provendo transparência para ambos o provedor e o consumidor do serviço.
É importante reconhecer que os serviços em nuvem são geralmente, mas nem sempre, utilizados em conjunto com, e habilitado por tecnologias de virtualização. Não existe requisito, no entanto, que relaciona a abstração de recursos com as tecnologias de virtualização e no caso de muitas ofertas, a virtualização por ambientes de sistemas operacionais ou hypervisors não são utilizadas. Além do mais, deveria ser notado que a característica de multilocatário não é considerada essencial pelo NIST, mas é geralmente discutido como se fosse. Favor se referir à seção sobre “multilocatário” abaixo, apresentada após a descrição de implantação do modelo em nuvem, para maiores detalhes.
Copyright © 2009 Cloud Security Alliance
17
Modelos de Serviços de Nuvem A entrega de serviços de nuvem é dividida entre três modelos de arquitetura e várias combinações derivadas. As três classificações fundamentais são geralmente referidas como “Modelo SPI”, onde “SPI” significa Software, Plataforma e Infraestrutura (como um Serviço), respectivamente – definidos, portanto como:
Software em Nuvem como um Serviço (SaaS). A capacidade oferecida ao consumidor consiste em utilizar as aplicações do provedor rodando em uma infraestrutura em nuvem. As aplicações são acessíveis por vários dispositivos através de uma interface simples de cliente como um browser web (exemplo: webmail). O consumidor não gerencia ou controla a infraestrutura adjacente na nuvem, incluindo rede, servidores, sistemas operacionais, armazenamento, ou nem mesmo as capacidades individuais da aplicação, com a possível exceção de parâmetros limitados de configuração da aplicação específicos para os usuários.
Plataforma em Nuvem como um Serviço (PaaS). A capacidade oferecida ao consumidor é para implementar na infraestrutura em nuvem criada para o usuário ou em aplicações adquiridas usando linguagens de programação e ferramentas suportadas pelo provedor. O consumidor não gerencia ou controla a infraestrutura adjacente na nuvem, incluindo rede, servidores, sistemas operacionais, ou armazenamento, mas tem controle sobre as aplicações implementadas e possivelmente configurações da aplicação referentes ao ambiente do servidor.
Infraestrutura em Nuvem como um Serviço (IaaS). A capacidade oferecida ao consumidor é de provisionar processamento, armazenamento, redes e outros recursos computacionais fundamentais onde o consumidor está apto a implementar e rodar os softwares que desejar, o que pode incluir sistemas operacionais e aplicações. O consumidor não gerencia ou controla as camadas adjacentes da infraestrutura na nuvem, mas tem controle sobre o sistema operacional, armazenamento, aplicações implementadas e possivelmente controle limitado de componentes específicos de rede (exemplo: firewalls no servidor).
O modelo NIST e este documento não endereçam diretamente as definições de modelos de serviços emergentes associados com os agentes de serviço na nuvem, estes provedores que oferecem intermediação, monitoração, transformação/portabilidade, governança, provisionamento e serviços de integração e negociam o relacionamento entre vários provedores de nuvem e os consumidores. No curto prazo, como a inovação estimula o desenvolvimento de soluções rápidas, consumidores e provedores de serviços de nuvem terão a sua disposição vários métodos de interação com serviços de nuvem na forma de APIs de desenvolvimento e interfaces e então os agentes de serviços de nuvem irão surgir como um importante componente em todo o ecossistema na nuvem. Agentes de serviços de nuvem irão abstrair os possíveis recursos incompatíveis e as interfaces no lugar dos consumidores, para prover intermediação antes do surgimento de normas em comum, abertas e de métodos padronizados para solucionar o problema a longo prazo através de capacidades semânticas que darão fluidez e agilidade ao consumidor, estando este habilitado a obter vantagem do modelo que melhor se adéqua às suas necessidades em particular.
Copyright © 2009 Cloud Security Alliance
18
É também importante notar o surgimento de muitos esforços centralizados ao redor do desenvolvimento de APIs ao mesmo tempo abertas e proprietárias que busquem permitir recursos como o gerenciamento, segurança e interoperabilidade para a nuvem. Alguns desses esforços incluem o grupo de trabalho “Open Cloud Computing Interface Working Group”, a API da Amazon EC2, a API vCloud da Vmware, submetida ao DMTF (Distributed Management Task Force), a API Open Cloud da Sun, a API da Rackspace e a API da GoGrid, para citar apenas algumas. APIs abertas e padronizadas vão ter um papel fundamental na portabilidade e interoperabilidade da nuvem, assim como formatos genéricos em comum como o “Open Virtualization Format” (OVF) da DMTF. Enquanto há muitos grupos de trabalho, rascunhos e especificações publicadas sob consideração neste momento é natural que a consolidação terá efeito assim que as forças de mercado, as necessidades dos consumidores e a economia direcionarem o cenário para um conjunto mais gerenciável e interoperável de fornecedores.
Modelos de Implantação de Nuvem Independente do modelo de serviço utilizado (SaaS, PaaS ou IaaS) existem quatro modelos de implantação de serviços de nuvem, com variações para atender a requisitos específicos:
Nuvem Pública. A infraestrutura de nuvem é disponibilizada ao público em geral ou a um grande grupo industrial e é controlada por uma organização que vende os serviços de nuvem.
Nuvem Privada. A infraestrutura da nuvem é operada exclusivamente por uma única organização. Ela pode ser gerida pela organização ou por terceiros, e pode existir no local ou fora do ambiente da empresa.
Nuvem Comunitária. A infraestrutura da nuvem é compartilhada por diversas organizações e suporta uma determinada comunidade que partilha interesses (por exemplo, a missão, os requisitos de segurança, política ou considerações de conformidade). Ela pode ser administrada pelas organizações ou por um terceiro e pode existir no local ou fora do ambiente da empresa.
Nuvem Híbrida. A infraestrutura da nuvem é uma composição de duas ou mais nuvens (privada, comunitária ou pública) que permanecem como entidades únicas, mas estão unidas pela tecnologia padronizada ou proprietária que permite a portabilidade de dados e aplicativos (por exemplo, “cloud bursting” para balanceamento de carga entre as nuvens).
É importante observar que existem modelos derivados de implementação de uma nuvem surgindo, devido ao amadurecimento das ofertas de mercado e da demanda dos clientes. Um exemplo típico são as nuvens virtuais privadas (virtual private clouds) – é uma maneira de utilizar a infraestrutura de nuvem pública de forma privada ou semiprivada e interligar estes recursos aos recursos internos do data center do consumidor, é feita geralmente através de conectividade via redes privadas virtuais (virtual private network ou VPN). As características da arquitetura utilizada ao desenhar as soluções terão implicação clara na futura flexibilidade, segurança e mobilidade da solução final, assim como da sua capacidade de colaboração. Como regra geral, as soluções que estabelecem perímetros são menos eficazes do
Copyright © 2009 Cloud Security Alliance
19
que as soluções sem perímetros definidos em cada um dos quatro modelos. Também deve ser feita uma cuidadosa consideração à escolha entre as soluções proprietárias ou abertas pelos mesmos motivos.
Multilocatário Embora esta não seja uma característica essencial da Computação em Nuvem no modelo do NIST, a CSA identificou a multilocação como um elemento importante da nuvem. A multilocação de serviços de nuvem implica na necessidade de forçar a aplicação de políticas, segmentação, isolamento, governança, níveis de serviço e modelos de cobrança retroativa/faturamento aplicados a diferentes grupos de consumidores. Os consumidores poderão utilizar serviços oferecidos por fornecedores de serviços de nuvem pública ou na verdade fazerem parte da mesma organização, como no caso de unidades de negócios diferentes, em vez de diferentes entidades organizacionais, mas ainda assim iriam compartilhar a infraestrutura.
Figura 2 - Multilocatário
Do ponto de vista de um provedor, a multilocação sugere uma abordagem de design e arquitetura que permita economia de escala, disponibilidade, gestão, segmentação, isolamento e eficiência operacional, aproveitando o compartilhamento da infraestrutura, dos dados, metadados, serviços e das aplicações através de muitos consumidores diferentes. A multilocação também pode ter definições diferentes, dependendo do modelo de serviço de nuvem do provedor, na medida em que pode implicar na viabilidade das capacidades descritas acima nos níveis da infraestrutura, do banco de dados, ou da aplicação. Um exemplo seria a diferença entre a implantação de uma aplicação multilocação em SaaS e IaaS. Modelos de implantação de nuvem têm importância diferenciada em multilocação. No entanto, mesmo no caso de uma nuvem privada, uma única organização pode ter um grande número de consultores e contratados terceirizados, bem como um desejo de um elevado grau de separação lógica entre as unidades de negócio. Assim, as preocupações da multilocação devem ser sempre consideradas.
Copyright © 2009 Cloud Security Alliance
20
Modelos de Referência de Nuvem Entender as relações e dependências entre os modelos de Computação em Nuvem é fundamental para compreender os riscos de segurança. IaaS é o fundamento de todos os serviços de nuvem, com o PaaS sendo construído com base na IaaS, e SaaS por sua vez, sendo construído baseado no PaaS, como descrito no diagrama do Modelo de Referência de Nuvem. Desta forma, assim como as capacidades são herdadas, também são herdadas as questões de segurança da informação e o risco. É importante notar que provedores comerciais de nuvem podem não se encaixar perfeitamente nos modelos de serviços em camadas. No entanto, o modelo de referência é importante para estabelecer uma relação entre os serviços do mundo real e o framework arquitetônico, bem como a compreensão dos recursos e serviços que exigem análise de segurança.
Figura 3 – Modelo de Referência de Nuvem
A IaaS inclui todos os recursos da pilha de infraestrutura desde as instalações até as plataformas de hardware que nela residem. Ela incorpora a capacidade de abstrair os recursos (ou não), bem como oferecer conectividade física e lógica a esses recursos. Finalmente, a IaaS fornece um conjunto de APIs que permitem a gestão e outras formas de interação com a infraestrutura por parte dos consumidores.
A PaaS trabalha em cima da IaaS e acrescenta uma camada adicional de integração com frameworks de desenvolvimento de aplicativos, recursos de middleware e funções como banco de dados, mensagens e filas, o que permite aos desenvolvedores criarem aplicativos para a plataforma cujas linguagens de programação e ferramentas são suportadas pela pilha. O SaaS por sua vez, é construído sobre as pilhas IaaS e PaaS logo abaixo, e fornece um ambiente operacional autocontido usado para entregar todos os recursos do usuário, incluindo o conteúdo, a sua apresentação, a(s) aplicação(ções) e as capacidades de gestão. Consequentemente deve ficar claro que existem importantes compensações de cada modelo em termos das funcionalidades integradas, complexidade versus abertura (extensibilidade), e segurança. As compensações entre os três modelos de implantação da nuvem incluem:
Geralmente, o SaaS oferece a funcionalidade mais integrada, construída diretamente baseada na oferta, com a menor extensibilidade do consumidor, e um nível relativamente elevado de segurança integrada (pelo menos o fornecedor assume a responsabilidade pela segurança).
Copyright © 2009 Cloud Security Alliance
21
A PaaS visa permitir que os desenvolvedores criem seus próprios aplicativos em cima da plataforma. Como resultado, ela tende a ser mais extensível que o SaaS, às custas de funcionalidades previamente disponibilizadas aos clientes. Esta troca se estende às características e capacidades de segurança, onde as capacidades embutidas são menos completas, mas há maior flexibilidade para adicionar uma a camada de segurança extra.
A IaaS oferece pouca ou nenhuma característica típica de aplicações, mas enorme extensibilidade. Isso geralmente significa menos recursos e funcionalidades integradas de segurança além de proteger a própria infraestrutura. Este modelo requer que os sistemas operacionais, aplicativos e o conteúdo possam ser gerenciados e protegidos pelo consumidor da nuvem.
Uma conclusão fundamental sobre a arquitetura de segurança é que quanto mais baixo na pilha o prestador de serviços de nuvem parar, mais recursos de segurança e gestão os consumidores terão a responsabilidade de implementar e gerenciar por si próprios. No caso do SaaS, isso significa que os níveis de serviço, segurança, governança, conformidade, e as expectativas de responsabilidade do prestador de serviço estão estipuladas, gerenciadas e exigidas contratualmente. No caso de PaaS ou IaaS é de responsabilidade dos administradores de sistema do cliente gerenciar eficazmente o mesmo, com alguma compensação esperada pelo fornecedor ao proteger a plataforma e componentes de infraestrutura subjacentes que garantam o básico em termos de disponibilidade e segurança dos serviços. Deve ficar claro em qualquer caso que se pode atribuir / transferir a responsabilidade, mas não necessariamente a responsabilidade final. Estreitando o escopo ou capacidades específicas bem como funcionalidades dentro de cada um dos modelos de ofertas de nuvem, ou empregando o agrupamento funcional dos serviços e recursos entre eles, podemos produzir classificações derivadas. Por exemplo, o “armazenamento como um serviço” (“Storage as a Service”) é uma sub-oferta específica dentro da “família” do IaaS. Apesar de uma ampla revisão do crescente conjunto de soluções de Computação em Nuvem estar fora do escopo deste documento, a taxotomia do OpenCrowd Cloud Solutions na figura abaixo fornece um excelente ponto de partida. A taxonomia OpenCrowd demonstra os crescentes grupos de soluções disponíveis hoje em cada um dos modelos previamente definidos. Note que o CSA não endossa especificamente nenhuma das soluções ou as empresas exibidas abaixo, mas fornece o diagrama para demonstrar a diversidade de ofertas disponíveis hoje.
Copyright © 2009 Cloud Security Alliance
22
Figura 4 - Taxonomia OpenCrowd
Para uma excelente visão geral dos muitos casos de uso da Computação em Nuvem, o Cloud Computing Use Case Group elaborou um trabalho colaborativo para descrever e definir os casos comuns e demonstrar os benefícios da nuvem, com o objetivo de “... reunir consumidores de nuvem e fornecedores de nuvem para definir os casos de uso frequentes para a Computação em Nuvem... e destacar os recursos e as necessidades que precisam ser padronizados em um ambiente de nuvem para garantir a interoperabilidade, facilidade de integração e portabilidade.”
Modelo de Referência de Segurança em Nuvem O modelo de referência de segurança em nuvem aborda as relações entre essas classes e as coloca no contexto das preocupações e controles de segurança relevantes. Para organizações e indivíduos que terão contato com a Computação em Nuvem pela primeira vez, é importante observar os pontos abaixo para evitar potenciais armadilhas e confusões: 1. A forma como os serviços de nuvem são implantados é frequentemente usada de maneira alternada com a idéia de onde eles são fornecidos e isso pode levar a confusões. Ambientes públicos ou privados de Computação em Nuvem, por exemplo, podem ser descritos como nuvens externas ou internas e isso pode não ser correto em todos os casos. 2. A maneira como os serviços de nuvem são consumidos é frequentemente descrita em relação ao perímetro de gestão ou de segurança de uma organização (geralmente definido pela presença de um firewall). Embora seja importante entender onde as fronteiras de
Copyright © 2009 Cloud Security Alliance
23
segurança deixam de existir em termos de Computação em Nuvem , a ideia de um perímetro bem demarcado é um conceito anacrônico. 3. A reperimetrização e a erosão de fronteiras de confiança que já estão acontecendo nas corporações são amplificadas e aceleradas pela Computação em Nuvem. Conectividade onipresente, a natureza amorfa das trocas de informações e a ineficácia dos controles estáticos de segurança que não conseguem tratar da natureza dinâmica dos serviços de nuvem, todos requerem novas formas de pensamento quando se considera a Computação em Nuvem. O fórum de Jericho produziu uma quantidade considerável de material sobre a reperimetrização das redes corporativas, incluindo muitos estudos de casos. As modalidades de implantação e consumo de nuvem devem ser pensadas não só no contexto do ‘interno’ versus ‘externo’, como em relação à localização física dos ativos, recursos e informações, mas também no contexto de quem são os seus consumidores e de quem é o responsável pela sua governança, segurança e conformidade com políticas e padrões. Isto não é sugerir que a localização dentro ou fora da empresa de um ativo, um recurso ou uma informação não afete a condição de segurança e de risco de uma organização porque elas são afetadas – mas para ressaltar que esse risco também depende de:
Os tipos de ativos, recursos e informações sendo gerenciados Quem as gerencia e como as gerencia Quais controles estão selecionados e como eles estão integrados Questões de conformidade
Um ambiente LAMP implantado no AWS EC2 da Amazon, por exemplo, seria classificado como uma solução pública, fora do ambiente da empresa (off-premise) e IaaS gerenciada por terceiros, mesmo se as instâncias, aplicações e dados contidos dentro dela fossem gerenciados pelo consumidor ou por um terceirizado. Um ambiente de aplicação personalizado servindo múltiplas unidades de negócio, implantado no Eucalyptus sob o controle, o gerenciamento e o domínio da corporação poderia ser descrito como uma solução SaaS privada, dentro da empresa (on-premise) e autogerenciada. Ambos os exemplos utilizam as capacidades de dimensionamento elástico e de autoatendimento da nuvem.
Copyright © 2009 Cloud Security Alliance
24
A tabela a seguir sumariza esses pontos:
Tabela – Modelos de Implantação da Nuvem
Outra maneira de se visualizar as combinações dos modelos de serviços de Computação em Nuvem, modelos de implantação, de localização física dos recursos e as atribuições de propriedade e gerenciamento, é através do modelo “Cloud Cube Model” criado pelo Fórum Jericho (www.jerichoforum.org), mostrado na figura abaixo:
Figura 5 – Modelo “Cloud Cube” do Jericho
Copyright © 2009 Cloud Security Alliance
25
O Cloud Cube Model mostra as inúmeras permutações possíveis nas ofertas de nuvem disponíveis atualmente e apresenta quatro critérios/dimensões a fim de separar as ‘formas’ de nuvem uma das outras e a maneira como são fornecidas, visando entender como a Computação em Nuvem afeta a forma de abordar a questão da segurança. O Cloud Cube Model também destaca os desafios em entender e mapear os modelos de nuvem para frameworks e padrões de controle como a ISO/IEC 27002, que fornece “…uma série de orientações e princípios gerais para a iniciar, implementar, manter e melhorar o gerenciamento da segurança da informação dentro de uma organização.” A seção 6.2 da ISO/IEC 27002, sobre objetivos de controle para “Parceiros Externos,” declara: “…a segurança das informações e das instalações de processamento de informações da organização não deve ser reduzida em função da introdução de produtos ou serviços de parceiros externos...” Da mesma forma, as diferenças nos métodos e na responsabilidade por proteger os três modelos de serviço de nuvem significam que os clientes dos mesmos são confrontados com um esforço desafiador. A menos que os provedores de nuvem possam divulgar facilmente seus controles de segurança e o alcance da implementação dos mesmos para o cliente, e o cliente saiba quais controles são necessários para manter a segurança de suas informações, existe um enorme potencial para decisões equivocadas e resultados negativos. Isto é crítico. Primeiro classifica-se um serviço de nuvem em comparação ao modelo de arquitetura de Computação em Nuvem. A partir disso, torna-se possível mapear sua arquitetura de segurança, bem como os requisitos de negócios, de regulamentações e outros requisitos de conformidade, como em um exercício de análise de gap (gap-analysis). O resultado determina o estado geral de segurança de um serviço e como ele se relaciona com a garantia dos ativos e os requisitos de proteção. A figura abaixo mostra um exemplo de como o mapeamento de serviço de Computação em Nuvem pode ser comparado com um catalogo de controles de compensação para determinar quais controles existem e quais não existem – como os fornecidos pelo cliente, por um provedor de serviços de nuvem, ou um terceiro. Isto pode, por sua vez, ser comparado com um framework de conformidade ou um conjunto de requisitos como o PCI DSS, conforme mostrado nesse exemplo.
Copyright © 2009 Cloud Security Alliance
26
Figura 6 – Mapeando o Modelo de Nuvem para o Modelo de Controles de Segurança & Conformidade
Uma vez que a análise de gap esteja completa, baseada nos requisitos de qualquer regulamentação ou pela exigência de conformidade, torna-se muito mais fácil determinar o que precisa ser feito para que ela sirva de base para um framework de avaliação de riscos; isto, por sua vez, ajuda a determinar como os gaps e, em última análise, os riscos devem ser tratados: aceitando-os, transferindo-os ou mitigando-os. É importante notar que o uso de Computação em Nuvem como um modelo operacional não prevê e nem previne a obtenção de conformidade automaticamente. A habilidade para atender qualquer requisito é um resultado direto dos modelos de serviço e de implantação utilizados e do desenho, da implantação e do gerenciamento dos recursos definidos no escopo. Para uma excelente visão geral dos frameworks de controle que fornecem bons exemplos do framework genérico de controle mencionado acima, veja o conjunto de documentos sobre padrões de arquitetura de segurança do Open Security Architecture Group, ou a versão 3 do catálogo de controles de segurança recomendados número 800-53 (Recommended Security Controls for Federal Information Systems and Organizations) do NIST, que é sempre útil e foi atualizado recentemente.
O que é Segurança para Computação em Nuvem? Para a maioria, controles de segurança de Computação em Nuvem não são diferentes dos controles de segurança para qualquer ambiente de TI. No entanto, em função dos modelos de
Copyright © 2009 Cloud Security Alliance
27
serviço de nuvem que são empregados, os modelos operacionais e as tecnologias usadas para habilitar tais serviços, a Computação em Nuvem pode apresentar riscos diferentes para uma organização quando comparada com as soluções tradicionais de TI. A Computação em Nuvem envolve a lenta perda de controle ao mesmo tempo em que mantemos a responsabilidade, mesmo se a responsabilidade operacional recair sobre um ou mais terceiros. Uma postura de segurança da organização é caracterizada pela maturidade, eficácia e a plenitude dos controles de segurança implementados ajustados aos riscos. Esses controles são aplicados em uma ou mais camadas que vão desde as instalações (segurança física), à infraestrutura de rede (segurança da rede), até os sistemas de TI (segurança de sistemas), até a informação e as aplicações (segurança de aplicações). Além disso, os controles são aplicados nos níveis das pessoas e dos processos, tal como a separação de funções e de gestão de mudanças, respectivamente. Conforme descrito anteriormente neste documento, as responsabilidades de segurança do provedor e do consumidor diferem muito entre os modelos de serviços de nuvem. A oferta de infraestrutura como serviço da Amazon, AWS EC2, por exemplo, inclui a responsabilidade do fornecedor pela segurança até o hypervisor, o que significa que pode incidir apenas sobre os controles de segurança como a segurança física, segurança ambiental e segurança da virtualização. O consumidor, por sua vez, é responsável pelos controles de segurança que se relacionam com o sistema de TI (a instância), incluindo o sistema operacional, aplicativos e dados. O contrário é verdadeiro para a oferta SaaS de gestão de recursos de clientes (customer resource management, ou CRM) da Salesforce.com. Como toda a “pilha” é fornecida pela Salesforce.com, o provedor não é apenas responsável pelos controles de segurança física e ambiental, mas também deve abordar os controles de segurança na infraestrutura, nas aplicações e nos dados. Isso alivia muito da responsabilidade direta do consumidor pela operação. Uma das atrações da Computação em Nuvem é a eficiência de custos proporcionada pelas economias de escala, reutilização e padronização. Para viabilizar estas eficiências, os provedores de serviço de nuvem têm que prestar serviços que sejam flexíveis o suficiente para atender a maior base de clientes possível, maximizando o seu mercado-alvo. Infelizmente, integrar segurança nestas soluções é frequentemente percebido como torná-las mais rígidas. Essa rigidez se manifesta muitas vezes na incapacidade de ganhar a paridade na implantação de controles de segurança em ambientes de nuvem em comparação a TI tradicional. Isso decorre principalmente devido à abstração da infraestrutura e à falta de visibilidade e capacidade para integrar muitos controles familiares de segurança, especialmente na camada de rede. A figura abaixo ilustra estas questões: em ambientes SaaS, os controles de segurança e de seus escopos são negociados em contratos de serviços: os níveis de serviço, privacidade e conformidade são todos assuntos a serem tratados legalmente em contratos. Em uma oferta IaaS, enquanto a responsabilidade de proteger a infraestrutura básica e camadas de abstração pertence ao provedor, o restante da pilha é de responsabilidade do consumidor. PaaS oferece um equilíbrio em algum lugar no meio, onde garantir a própria plataforma cai sobre o provedor, mas a segurança das aplicações desenvolvidas para a plataforma e a tarefa de desenvolvê-las de forma segura pertencem ambas ao consumidor.
Copyright © 2009 Cloud Security Alliance
28
Figura 7 – Como a Segurança é Integrada
Entender o impacto dessas diferenças entre os modelos de serviço e como eles são implementados é fundamental para a gestão do posicionamento de uma organização frente ao risco.
Além da Arquitetura: As Áreas de Atenção Crítica Os outros doze domínios, que incluem as demais áreas de preocupação para a Computação em Nuvem destacadas pelo guia da CSA são ajustados para abordar tanto os pontos estratégicos e táticos críticos de segurança dentro de um ambiente em nuvem e, podem ser aplicados a qualquer combinação de serviços e de modelos de implantação da nuvem. Os domínios são divididos em duas grandes categorias: governança e operações. Os domínios da governança são amplos e endereçam questões estratégicas e de política dentro de um ambiente de Computação em Nuvem, enquanto os domínios operacionais focam mais nas preocupações táticas de segurança e sua implementação dentro da arquitetura. Domínios de Governança Domínio
O Guia trata de…
Governança e Gestão de Riscos Corporativos
A capacidade de uma organização para governar e medir o risco empresarial introduzido pela Computação em Nuvem. Ítens como a precedência legal em caso de violação de acordo, a capacidade de organizações usuárias para avaliar adequadamente o risco de um provedor de nuvem, a responsabilidade para proteger dados sensíveis quando o usuário e o
Copyright © 2009 Cloud Security Alliance
29
provedor podem falhar e, como as fronteiras internacionais podem afetar estas questões, são alguns dos itens discutidos.
Aspectos Legais e Electronic Discovery
Problemas legais em potencial quando se utiliza Computação em Nuvem. Os assuntos abordados nesta seção incluem os requisitos de proteção da informação e de sistemas informáticos, leis de divulgação de violações de segurança, os requisitos regulatórios, requisitos de privacidade, as leis internacionais, etc.
Conformidade e Auditoria
Manutenção e comprovação de conformidade quando se faz uso da Computação em Nuvem. Questões relativas à avaliação da forma como a Computação em Nuvem afeta o cumprimento das políticas de segurança interna, bem como diversos requisitos de conformidade (regulatórios, legislativos e outros) são discutidos aqui. Este domínio inclui algumas orientações de como provar a conformidade durante uma auditoria.
Gestão do Ciclo de Vida da Informação
Gerenciamento de dados que são colocados na nuvem. Ítens em torno da identificação e controle de dados na nuvem, bem como controles compensatórios que podem ser usados para lidar com a perda de controle físico ao mover dados para a nuvem são discutidos aqui. Outros ítens, como quem é responsável pela confidencialidade, integridade e disponibilidade dos dados são mencionados.
Portabilidade e Interoperabilidade
A habilidade de mover dados / serviços de um provedor para outro, ou levá-lo totalmente de volta para a empresa. Problemas de interoperabilidade entre os fornecedores também são discutidos.
Domínios Operacionais Como a Computação em Nuvem afeta os processos e procedimentos operacionais atualmente usados para implementar a segurança, continuidade de negócios e recuperação de desastres. O foco é discutir e Segurança Tradicional, Continuidade de analisar os possíveis riscos da Computação em Negócios e Recuperação de Desastres Nuvem, na esperança de aumentar o diálogo e debate sobre a grande procura de melhores modelos de gestão de riscos corporativos. Além disso, a seção aborda sobre como ajudar as pessoas a identificar onde a Computação em Nuvem pode ajudar a diminuir certos riscos de
Copyright © 2009 Cloud Security Alliance
30
segurança, ou implica em aumento dos riscos em outras áreas.
Operação do Data Center
Como avaliar a arquitetura e a operação de um fornecedor de data center. Este capítulo é principalmente focado em ajudar os usuários a identificar características comuns de data centers que podem ser prejudiciais para os serviços em andamento, bem como características que são fundamentais para a estabilidade a longo prazo.
Resposta a Incidentes, Notificação e Correção
A correta e adequada detecção de incidentes, a resposta, notificação e correção. Pretende-se abordar itens que devem estar presentes tanto no nível dos prestadores e dos usuários para permitir bom tratamento de incidentes e forenses computacional. Este domínio vai ajudá-lo a compreender as complexidades que a nuvem traz para seu atual programa de gestão de incidentes.
Segurança de Aplicação
Protegendo o software aplicativo que está sendo executado ou sendo desenvolvido na nuvem. Isto inclui ítens tais como, se é apropriado migrar ou projetar um aplicativo para ser executado na nuvem, e em caso afirmativo, que tipo de plataforma em nuvem é mais adequada (SaaS, PaaS ou IaaS). Algumas questões de segurança específicas relacionadas com a nuvem também são discutidas.
Gestão de Criptografia e de Chaves
Identificar o uso de criptografia e gestão de chaves escalável. Esta seção não é prescritiva, mas é mais informativa em discutir por que eles são necessários e identificar as questões que surgem na utilização, tanto para proteger o acesso aos recursos, bem como para proteger os dados.
Gestão da Identidade e do Acesso
Gerenciamento de identidades e alavancando os serviços de diretório para fornecer controle de acesso. O foco está em questões encontradas quando se estende a identidade de uma organização para a nuvem. Esta seção fornece insights para avaliar a prontidão da organização para realizar a gestão da identidade e acesso (Identity and Access Management, ou IAM) baseados na nuvem.
Virtualização
O uso da tecnologia de virtualização em Computação em Nuvem. O domínio aborda ítens tais como os riscos associados com
Copyright © 2009 Cloud Security Alliance
31
multilocação, o isolamento de VMs, a corresidência de VMs, vulnerabilidades no hypervisor, etc. Este domínio foca nas questões da segurança em torno do sistema / hardware de virtualização, ao invés de um levantamento mais geral de todas as formas de virtualização.
Resumo A chave para compreender como a arquitetura da nuvem impacta na arquitetura de segurança é um vocabulário comum e conciso, acompanhado de uma taxonomia consistente das ofertas através dos quais os serviços em nuvem e as arquiteturas podem ser desconstruídos, mapeados para um modelo de controles de segurança e operacionais de compensação, frameworks de avaliação de risco e de gestão e, em seguida, para padrões de conformidade. Entender como a arquitetura, tecnologia, processo e as necessidades de capital humano alteram ou permanecem os mesmos durante a implantação de serviços de Computação em Nuvem é fundamental. Sem uma compreensão clara e de alto nível das implicações na arquitetura, é impossível abordar racionalmente as questões mais detalhadas. Esta visão geral da arquitetura, juntamente com as doze outras áreas de foco crítico, vai proporcionar ao leitor uma base sólida para a avaliação, operacionalização, gerenciamento e governança da segurança em ambientes de Computação em Nuvem. Colaboradores da Versão Original: Glenn Brunette, Phil Cox, Carlo Espiritu, Christofer Hoff, Mike Kavis, Sitaraman Lakshminarayanan, Kathleen Lossau, Erik Peterson, Scott Matsumoto, Adrian Seccombe, Vern Williams, Richard Zhou Colaboradores da Versão Brasileira: Alessandro Trombini, Alexandre Pupo, Anchises Moraes, Denylson Machado, Jaime Orts Y. Lugo, Luís Felipe Féres Santos, Milton Ferreira, Olympio Rennó Ribeiro Jr
Copyright © 2009 Cloud Security Alliance
32
Seção II. Governança na Nuvem
Copyright © 2009 Cloud Security Alliance
33
Domínio 2: Governança e Gestão de Risco Corporativo A governança e o gerenciamento de risco corporativo eficazes em ambientes de Computação em Nuvem vêm dos processos de governança de segurança da informação bem definidos, como parte das determinações gerais de governança corporativa da organizaçãosobre os cuidados específicos necessários com os ativos. . Os processos de governança bem definidos devem resultar em programas de gerenciamento de segurança da informação que sejam escalonávies com o negócio, aplicáveis em toda a organização, mensuráveis, sustentáveis, defensáveis, continuamente melhorados e com orçamentos justificáveis. As questões fundamentais da governança e da gestão de riscos corporativo em Computação em Nuvem referem-se à identificação e implementação das estruturas organizacionais adequadas, processos e controles para manter a efetiva governança da segurança da informação, gestão de riscos e conformidade. As organizações também devem garantir a um nível razoável de segurança das informações em toda a cadeia de fornecimento da informação, envolvendo fornecedores e clientes de serviços de Computação em Nuvem e seus prestadores de serviço, em qualquer modelo de implantação de nuvem.
Recomendações de Governança
Uma parte da redução de custos decorrente da adoção de Computação em Nuvem deve ser direcionada para o aumento dos controles dos recursos de segurança do provedor, aplicação de controles de segurança e avaliações e auditorias detalhadas, para garantir que as exigências de proteção de dados estão sendo continuamente verificadas..
Tanto os clientes quanto os fornecedores de serviços de Computação em Nuvem devem desenvolver uma governança de segurança da informação robusta, independentemente do serviço ou modelo de implantação adotado. A governança de segurança da informação deve ser uma colaboração entre clientes e fornecedores para alcançar os objetivos acordados, que apoiam a missão da empresa e programas de segurança da informação. O modelo de negócio pode ajustar os papéis e responsabilidades colaborativamente na governança de segurança da informação e no gerenciamento de riscos (com base no respectivo âmbito de controle para o usuário e prestador de serviços), enquanto o modelo de implantação pode definir as responsabilidades e expectativas (com base na avaliação de risco).
As organizações clientes devem incluir a revisão de determinados processos e estruturas de governança de segurança da informação, bem como de controles de segurança específicos, como parte de seus cuidados na seleção de provedores de serviço de nuvem. Os processos de governança de segurança e as atividades dos fornecedores devem ser avaliados sob sua capacidade de suportar os processos do cliente, bem como sua maturidade e coerência com os processos de gestão de segurança de informações. Os controles de segurança dos provedores de nuvem devem ser comprovadamente baseados no risco e claramente suportar estes processos de gestão.
A estrutura e processos de governança colaborativa entre clientes e fornecedores devem ser identificadas como necessárias, tanto no âmbito da concepção e desenvolvimento de prestação de serviços, como avaliação de risco e de serviços e protocolos de gestão de risco e, em seguida incorporado nos acordos de serviço.
Copyright © 2009 Cloud Security Alliance
34
Departamentos de segurança devem ser envolvidos durante o estabelecimento de Acordos de Nível de Serviço (SLA) e obrigações contratuais, para assegurar que os requisitos de segurança são contratualmente aplicáveis.
Métricas e padrões para medir o desempenho e eficácia do gerenciamento de segurança da informação devem ser estabelecidos previamente à mudança para a Nuvem. Ao menos, as organizações devem entender e documentar suas métricas atuais e como elas mudam quando operações são movidas para a Nuvem, onde um provedor pode usar diferentes (e potencialmente incompatíveis) métricas.
Sempre que possível, métricas e padrões de segurança (particularmente aquelas relacionadas a requisitos legais e de conformidade) devem ser incluídas em qualquer Acordo de Nível de Serviço (SLA) e contratos. Estas métricas e padrões devem ser documentadas e ser demonstráveis (auditáveis).
Recomendações para gerenciamento de riscos corporativos Assim como em qualquer novo processo de negócios, é importante seguir as melhores práticas de gerenciamento de riscos. As práticas devem ser proporcionais às especificações dos serviços em nuvem, que podem variar de processamento inócuo de dados e tráfego de rede até processos de negócios de missão crítica lidando com informação altamente sensível. Uma discussão completa do gerenciamento de riscos corporativos e gerenciamento de risco da informação está além do escopo deste guia, mas aqui há algumas recomendações específicas da Nuvem que você pode incorporar em seus processos de gerenciamento de riscos existentes.
Devido à falta de controle físico sobre a infraestrutura em muitas implantações de Computação em Nuvem; SLAs, requisitos de contratos e documentação dos provedores têm um papel em gerenciamento de riscos maior do que quando lidamos com a tradicional infraestrturua própria das empresas..
Devido ao provisionamento sob demanda e aos aspectos “multilocatário” de Computação em Nuvem, formas tradicionais de auditoria e avaliação podem não estar disponíveis ou podem ser modificadas. Por exemplo, alguns provedores restringem avaliações de vulnerabilidades ou testes de invasão, enquanto outros limitam disponibilidade de logs de auditoria e monitoramento de atividades. Se estes forem exigidos por suas políticas internas, você pode precisar procurar opções alternativas de avaliação, exceções contratuais específicas ou um provedor alternativo melhor alinhado com seus requisitos de gerenciamento de riscos.
Com relação ao uso de serviços de Nuvem para funções críticas da organização, a abordagem de gerenciamento de riscos deve incluir a identificação e avaliação de ativos, identificação e análise de ameaças e vulnerabilidades e seu potencial impacto nos ativos (cenários de riscos e incidentes), análise de probabilidade de eventos/cenários, níveis e critérios de aceitação de gerenciamento de riscos aprovado e o desenvolvimento de planos de tratamento de riscos com múltiplas opções (controle, prevenção, transferência, aceitação). Os resultados dos planos de tratamento de riscos devem ser incorporados aos acordos de serviço.
Abordagens de avaliação de riscos entre provedores e usuários devem ser consistentes, com consistência em critérios de análises de impacto e definição de probabilidades. O
Copyright © 2009 Cloud Security Alliance
35
usuário e o provedor juntos devem desenvolver cenários de risco para os serviços em nuvem; isto deve ser intrínseco ao projeto do serviço prestado ao usuário e para a avaliação do usuário do risco de serviços em nuvem.
Inventario de ativos deve considerar os serviços de suporte de ativos na nuvem e sob controle do provedor. Classificação de ativo e esquemas de avaliação deverem ser coerentes entre usuário e provedor.
O serviço, e não somente o fornecedor deve ser o alvo de uma avaliação de risco. O uso de serviços na nuvem, os serviços especificos e modelos de desenvolvimento para serem utilizados devem ser coerentes com os objetivos de gerenciamento de riscos da organização assim como também com os objetivos do negócio.
Quando o provedor não se demonstrar compreensivo e efetivo no processo de gerenciamento de riscos em associação com estes serviços, clientes devem avaliar com cuidado as habilidades tanto de fornecedores quanto dos próprios usuários no sentido de compensar a brechas potenciais indicadas pelo gerenciamento de riscos.
Clientes de serviços na nuvem devem questionar se seu sua gestão definiu a níveis de tolerância a riscos com relação aos serviços na nuvem e aceita qualquer risco residual inerente à utilização de serviços em nuvem.
Recomendação de Gerenciamento de Riscos da Informação Gerenciamento de Riscos da Informação é o ato de alinhar a exposição ao risco e a capacidade de gerenciá-lo, com a tolerancia ao risco do proprietário das informações. Desta forma, o gerenciamento de risco é o principal meio de apoio às decisões para desenvolver ferramentas de tecnologia da informação para proteger a confidencialidade, integridade e disponibilidade dos ativos da informação.
Adote um modelo de framework de gerenciamento de riscos para avaliar seu GRI (Gerenciamento de Riscos da Informação) e um modelo de maturidade para avaliar a efetividade do seu modelo de GRI.
Estabeleça requisitos contratuais apropriados e controles tecnológicos para coletar dados necessários para informar as decisões sobre os riscos à informação (ex. uso da informação, controle de acesso, controles de segurança, localização, etc.).
Adote um processo para determinar a exposição ao risco antes de elencar requisitos para um projeto de Computação em Nuvem. Embora as categorias de informação necessárias para entender a exposição e gestão sejam genéricas, as métricas atuais de coleta de evidências são especificas para a natureza do modelo SPI (SaaS, PaaS e IaaS) de Computação em Nuvem e que podem ser facilmente coletadas nas especificações do serviço prestado.
Quando utilizado SaaS (Software como serviço), a maior parte da informação deve ser fornecida pelo provedor do serviço. Organizações devem estruturar processos de coleta de informações analiticas nas obrigações contratuais do serviço SaaS.
Copyright © 2009 Cloud Security Alliance
36
Quando utilizando o modelo PaaS (Plataforma como um Serviço), defina a coleta de informações como definido no modelo SaaS acima, mas sempre que for possivel, considere a capacidade de implantar e coletar informações de controles, bem como a criação de itens contratuais para testar a efetividade destes controles.
Quando utilizado um provedor de serviços sob o modelo IaaS (Infraestrutura como um serviço), defina a transparência das informações em nível contratual para que possam ser tratadas pela análise de riscos.
Os provedores de serviço em nuvem devem incluir métricas e controles para auxiliar os clientes na implementação dos seus requisitos de Gestão de Risco da Informação.
Recomendações para o Gerenciamento de Serviços Terceirizados
Os clientes devem considerar os serviços e a segurança em nuvem como questões de segurança da cadeia de suprimento (Supply Chain). Isso significa examinar e avaliar, na medida do possível, a cadeia de suprimentos do fornecedor (relacionamentos dos prestadores de serviço e seus terceirizados). Isso também significa examinar o gerenciamento de serviços terceirizados pelo próprio fornecedor.
A avaliação dos fornecedores de serviços terceirizados deve concentrar-se especificamente no gerenciamento do fornecedor, nas políticas de recuperação de desastres e continuidade de negócio, e em processos e procedimentos; deve, igualmente, incluir o exame das instalações de back-up e co-location de suas instalações físicas. Deve incluir também a revisão das avaliações internas do fornecedor destinadas a cumprir as exigências de políticas e procedimentos próprios, e a avaliação das métricas usadas pelo fornecedor para fornecer informações razoáveis sobre o desempenho e a efetividade dos seus controles nessas áreas.
O plano de recuperação de desastres e continuidade de negócios do usuário deve incluir cenários de perda dos serviços prestados pelo fornecedor e de perda pelo fornecedor de serviços terceirizados e de capacidades dependentes de terceiros. A realização dos testes dessa parte do plano deve ser coordenada com o provedor de serviços de nuvem.
A regulamentação da governança de segurança de informações, a gestão de riscos e as estruturas e os processos do fornecedor devem ser amplamente avaliados: o Solicite uma documentação clara sobre como as instalações e os serviços do fornecedor são avaliados quanto aos riscos e auditados sob controles de vulnerabilidades, a frequência de tais avaliações, e como as deficiências de controles são devidamente mitigadas. o Solicite uma definição do que o fornecedor considera fatores de sucesso de segurança da informação e serviços críticos, indicadores chave de desempenho, e como tais aspectos são mensurados relativamente à Gestão de Segurança de Informações e Serviços de TI. o Examine a abrangência dos processos de comunicação, avaliação e domínio dos requisitos legais, regulatórios, industriais e contratuais do fornecedor. o Implemente detalhados contratos para determinar papéis, funções e responsabilidades. Assegure que será feito uma validação legal, incluindo uma
Copyright © 2009 Cloud Security Alliance
37
avaliação do cumprimento das normas contratuais e leis em jurisdições estrangeiras ou fora do estado. o Determinar se os requisitos contratuais compreendem todos os aspectos materiais das relações dos provedores de serviço de nuvem, tais como a situação financeira, a reputação (por exemplo, verificações de referências), controles, pessoal estratégico, planos e testes de recuperação de desastres, seguros, capacidades de comunicações e uso de terceirizados do provedor.
Colaboradores da Versão Original: Jim Arlen, Don Blumenthal, Nadeem Bukhari, Alex Hutton, Michael Johnson, M S Prasad, Patrick Sullivan Colaboradores da Versão Brasileira: Alessandro Trombini, Filipe Villar, Marcelo Pinheiro, Masaishi Yoshikawa, Nelson Novaes Neto
Copyright © 2009 Cloud Security Alliance
38
Domínio 3: Aspectos Legais e Electronic Discovery Computação em Nuvem cria uma nova dinâmica no relacionamento entre a organização e suas informações, envolvendo a presença de um terceiro: o provedor de nuvem. Isto cria novos desafios relacionados ao entendimento de como as leis se aplicam para uma ampla variedade de cenários de gerenciamento da informação. É preciso considerar as dimensões funcional, jurisdicional e contratual para realizar uma completa análise das questões legais relacionadas à Computação em Nuvem.
A dimensão funcional compreende a determinação de quais funções e serviços de Computação em Nuvem têm implicações legais para os participantes e stakeholders.
A dimensão jurisdicional compreende a maneira pelo qual os governos administram leis e regulamentos que afetam os serviços de Computação em Nuvem, os stakeholders e os ativos de dados envolvidos.
A dimensão contratual compreende as estruturas, os termos e as condições de contrato, e os mecanismos de cumprimento através dos quais as partes interessadas em ambientes de Computação em Nuvem podem tratar e gerenciar as questões legais e de segurança.
Computação em Nuvem no geral pode se distinguir do outsourcing tradicional de três formas: o tempo de serviço (sob demanda e intermitente), o anonimato da identidade do(s) prestador(es) de serviço e o anonimato da localização do(s) servidor(es) envolvido(s). Considerando-se especificamente IaaS e PaaS, uma grande quantidade de orquestração, configuração e desenvolvimento de software é realizada pelo cliente — tal responsabilidade não pode ser transferida para o provedor de serviço de nuvem. Conformidade com as recentes exigências legislativas e administrativas em todo o mundo tem obrigado uma maior colaboração entre advogados e profissionais do setor de tecnologia. Isto é especialmente verdadeiro na Computação em Nuvem, devido ao potencial de novas áreas de risco legal criado pela natureza distribuída da nuvem se comparado à tradicional infraestrutura interna ou terceirizada. Diversas leis e regulamentos de conformidade nos Estados Unidos e da União Européia imputam responsabilidade a subcontratados ou exigem que as entidades empresariais sejam contratualmente responsáveis por eles. Os tribunais já estão percebendo que os serviços de gestão de segurança da informação são fundamentais para a tomada de decisão sobre a aceitação da informação digital como evidência. Embora se trate de uma questão para infraestrutura tradicional de TI, é especialmente relativa na Computação em Nuvem, devido à ausência de fundamentação legal da nuvem.
Recomendações
Clientes e provedores da nuvem devem estar mutuamente cientes dos respectivos papéis e responsabilidades relacionados à Eletronic Discovery, incluindo atividades como litígio, investigações, prover o testemunho de perito, etc.
Copyright © 2009 Cloud Security Alliance
39
Provedores de nuvem são aconselhados a garantir que seus sistemas de segurança da informação atendam às necessidades do cliente para preservar os dados como autênticos e confiáveis, incluindo informações primárias e secundárias, tais como metadados e arquivos de logs.
Dados sob a custódia dos provedores de serviços de nuvem devem receber proteção equivalente a que teriam se estivessem nas mãos de seu proprietário original ou custodiante.
Elaboração de um plano para o término esperado ou inesperado da relação contratual e para um retorno adequado ou descarte seguro dos ativos.
Due diligence (auditoria) pré-contratual, negociação dos termos do contrato, monitoramento pós-contrato e rescisão contratual e a transição da custódia dos dados são itens de cuidado obrigatório de um cliente de serviços de nuvem.
Saber onde o provedor de serviços de nuvem irá hospedar os dados é um pré-requisito para implementar as medidas necessárias para garantir conformidade com as leis locais que restringem o fluxo de dados além das fronteiras.
Como custodiante dos dados pessoais de seus funcionários ou clientes, bem como de outros ativos de propriedade intelectual da instituição, uma empresa que utiliza serviços de Computação em Nuvem deve assegurar que ele mantém a posse de seus dados em seu formato original e autêntico.
Diversas questões de segurança, tais como suspeitas de violação de dados, devem ser abordadas através de disposições específicas do contrato de prestação de serviço, que esclarecem as respectivas obrigações do provedor de serviços de nuvem e do cliente.
O provedor de serviços de nuvem e o cliente devem adotar um processo unificado para responder às intimações, citações e outros requisitos legais.
O contrato de serviços de nuvem deve permitir que o cliente ou terceiro designado monitore o desempenho do provedor de serviços e teste as vulnerabilidades no sistema.
As partes em um contrato de serviços de nuvem devem assegurar que o acordo preveja a ocorrência de problemas relativos à recuperação dos dados do cliente após o término da relação contratual.
Colaboradores da Versão Original: Tanya Forsheit, Scott Giordano, Francoise Gilbert, David Jackson, Peter McLaughlin, Jean Pawluk, Jeffrey Ritter
Colaboradores da Versão Brasileira: Nelson Novaes Neto, Reginaldo Sarraf P. Rodrigues
Copyright © 2009 Cloud Security Alliance
40
Domínio 4: Conformidade e Auditoria Com o desenvolvimento da Computação em Nuvem como um meio viável e rentável para a terceirização de sistemas, ou mesmo de processos de negócio inteiros, torna-se difícil alcançar e até mais difícil demonstrar para auditores e avaliadores a aderência a conformidades, com a política de segurança e com os vários regulamentos e requisitos legislatórios aos quais sua organização está sujeita. Dos diversos regulamentos que tangem à tecnologia da informação e que as organizações devem cumprir, poucos foram escritos levando a Computação em Nuvem em consideração. Auditores e avaliadores podem não estar familiarizados com a mesma ou com um determinado serviço de nuvem em particular. Sendo esse o caso, cabe ao cliente de Computação em Nuvem entender:
A aplicabilidade regulatória para o uso do serviço de nuvem em questão; A divisão das responsabilidades pela conformidade entre o provedor do serviço e o cliente de nuvem; A capacidade do provedor de serviço de nuvem em produzir as evidências necessárias para a conformidade Papel do cliente em fazer a ponte entre o provedor do serviço de nuvem e o auditor/avaliador
Recomendações
Envolva os Departamentos Jurídicos e de Contratos. As cláusulas padrão de serviço do provedor de Computação em Nuvem podem não atender suas necessidades de conformidade e, por isso, é vantajoso ter pessoas das áreas jurídicas e de contratos envolvidas desde o início para garantir que o contrato de prestação de serviços seja adequado para atender as obrigações de conformidade e auditoria.
Cláusula Sobre o Direito de Auditar. Os clientes, frequentemente, terão a necessidade da capacidade de auditar o provedor de serviços de Computação em Nuvem, dada a natureza dinâmica dos ambientes regulatório e de Computação em Nuvem. Uma cláusula sobre o direito de auditar deve ser obtida sempre que possível, particularmente quando se usa um provedor para um serviço onde o cliente tenha que regulamentar o cumprimento das responsabilidades. Ao longo do tempo, a necessidade deste direito deve ser reduzida e em muitos casos substituída por certificações do provedor, relacionadas com as nossas recomendações para o escopo da ISO/IEC 27001 que serão apresentadas posteriormente.
Analisar o Escopo de Conformidade. Determinar se os regulamentos de conformidade aos quais a organização está sujeita serão impactados pelo uso dos serviços de Computação em Nuvem para um dado conjunto de aplicações e dados.
Analisar o Impacto dos Regulamentos Sobre a Segurança dos Dados. Potenciais usuários finais dos serviços de Computação em Nuvem devem ponderar quais aplicações e dados estão sendo considerados para serem movidos para serviços de Computação em Nuvem e em que medida eles estão sujeitos aos regulamentos de conformidade.
Copyright © 2009 Cloud Security Alliance
41
Revisar Parceiros e Provedores de Serviços Importantes. Esta é a recomendação geral para assegurar que relacionamentos com provedores de serviços não afetem negativamente a conformidade. Avaliar quais provedores estão processando os dados sujeitos aos regulamentos de conformidade e então avaliar os controles de segurança oferecidos pelos mesmos é fundamental. Muitas normas de conformidade têm linguagens específicas na avaliação e na gestão de riscos de terceiros. Tal como acontece com serviços de Tecnologia da Informação e com negócios não ligados à Computação em Nuvem, organizações têm necessidade de entender quais de seus parceiros de negócios estão processando dados relacionados à normas de conformidade.
Entender as Responsabilidades Contratuais Sobre a Proteção de Dados e os Contratos Relacionados. O modelo de serviços de Computação em Nuvem determina, de uma certa forma, se o cliente ou o provedor de serviços é responsável pela implantação de controles de segurança. Em um cenário de implantação de IaaS, o cliente tem um alto grau de controle e uma maior responsabilidade do que em um cenário de implantação de SaaS. Do ponto de vista do controle de segurança, isto significa que clientes IaaS terão que implantar muitos dos controles para a conformidade regulatório. Em um cenário SaaS, o provedor de serviços de Computação em Nuvem deve fornecer os controles necessários. De uma perspectiva contratual é importante entender os requisitos específicos e garantir que o contrato de serviços, bem como os acordos de nível de serviço, sejam tratados adequadamente.
Analisar o Impacto das Regulamentações na Infraestrutura do Provedor. Na área de infraestrutura, mover-se para serviços de Computação em Nuvem também requer uma análise cuidadosa. Alguns requisitos regulatórios especificam controles que são difíceis ou impossíveis de se atingir em certos tipos de serviços de nuvem.
Analisar o Impacto de Regulamentações em Políticas e Procedimentos. Mover dados e aplicações para serviços de Computação em Nuvem provavelmente causará um impacto em políticas e procedimentos. Os clientes devem avaliar quais políticas e procedimentos relacionados com regulamentações terão de ser alterados. Exemplos de políticas e procedimentos impactados incluem relatórios de atividades, logs, retenção de dados, resposta a incidentes, controles de testes e políticas de privacidade.
Preparar Evidências de como cada Exigência Está Sendo Cumprida. Coletar evidências de conformidade através da multiplicidade de regulamentos e de requisitos é um desafio. Clientes dos serviços de Computação em Nuvem devem desenvolver processos para coletar e armazenar evidências de conformidade, incluindo logs de auditoria e relatórios de atividades, cópias das configurações dos sistemas, relatórios de gestão de mudanças e resultados de outros procedimentos de teste. Dependendo do modelo de serviço o provedor pode precisar fornecer muitas dessas informações.
Seleção e Qualificação de Auditores. Em muitos casos a organização não tem nenhuma influência na seleção de auditores ou avaliadores de segurança. Se uma organização participa da seleção, é altamente recomendável escolher um auditor que conheça Computação em Nuvem, uma vez que muitos podem não estar familiarizados com os desafios da virtualização e da Computação em Nuvem.
Copyright © 2009 Cloud Security Alliance
42
Questionar sua familiaridade com as nomenclaturas IaaS, PaaS e SaaS é um bom ponto de partida.
Provedores de Computação em Nuvem da Categoria SAS 70 Tipo II. Os provedores devem ter, no mínimo, esta homologação, pois ela proporcionará um ponto de referência reconhecido para auditores e avaliadores. Uma vez que auditorias SAS 70 Tipo II garantem apenas que os controles estão implementados como foram documentados, é igualmente importante entender o escopo da auditoria SAS 70 e se esses controles estão adequados aos seus requisitos.
Roteiro de Certificação ISO/IEC 27001/27002 dos Provedores de Computação em Nuvem. Provedores que buscam o fornecimento de serviços de missão crítica devem adotar os padrões da ISO/IEC 27001 para sistemas de gerenciamento de segurança da informação. Se o provedor não tiver alcançado a certificação ISO/IEC 27001, ele deve demonstrar alinhamento com as práticas da ISO 27002.
Escopo da ISO/IEC 27001/27002. A Cloud Security Alliance está emitindo uma chamada na industria para alinhar provedores de Computação em Nuvem com a certificação ISO/IEC 27001, para garantir que o escopo não omita critérios críticos da certificação.
Colaboradores da Versão Original: Nadeem Bukhari, Anton Chuvakin, Peter Gregory, Jim Hietala, Greg Kane, Patrick Sullivan Colaboradores da Versão Brasileira: Alexandre Pupo, Ricardo Makino
Copyright © 2009 Cloud Security Alliance
43
Domínio 5: Gerenciamento do Ciclo de Vida das Informações Um dos principais objetivos da segurança da informação é proteger os dados fundamentais que suportam nossos sistemas e aplicações. Durante a transição para Computação em Nuvem, nossos métodos tradicionais de proteção à informação são desafiados por arquiteturas baseadas na nuvem. Elasticidade, multilocação, novas arquiteturas físicas e lógicas e controles abstratos exigem novas estratégias de segurança de dados. Com muitas implementações de Computação em Nuvem, nós estamos transferindo dados para ambientes externos – ou mesmo públicos - o que seria impensado há poucos anos atrás.
Gerenciamento do Ciclo de Vida das Informações O Ciclo de Vida da Segurança de Dados é diferente do Gerenciamento do Ciclo de Vida das Informações, refletindo as diferentes necessidades do público de segurança. O Ciclo de Vida da Segurança de Dados consiste de seis fases:
Figura 8 – Ciclo de vida da segurança de dados
Os desafios-chave relativos ao ciclo de vida da segurança de dados na nuvem incluem os seguintes: Segurança de dados. Confidencialidade, Integridade, Autorização, Autenticação e Irretratabilidade (não-repúdio).
Disponibilidade,
Autenticidade,
Localização dos dados. Deve-se ter certeza que os dados, incluindo todas as suas cópias e backups, estejam armazenados somente em localizações geográficas permitidas por contrato, SLA e/ou regulação. Por exemplo, uso de armazenamento tal como exigido pela União Europeia para
Copyright © 2009 Cloud Security Alliance
44
armazenamento eletrônico de registros de saúde pode ser um desafio adicional para o proprietário dos dados e provedores de serviço de nuvem. Remanescência ou persistência de dados. Dados devem ser efetivamente e completamente removidos para serem considerados “destruídos”. Portanto, técnicas para localizar completamente e efetivamente dados que estejam na nuvem, apagar/destruir dados e assegurar que tenham sido completamente removidos ou tornados irrecuperáveis devem estar disponíveis e ser usadas quando exigido. Mescla de dados com outros clientes da nuvem. Dados – especialmente dados classificados /sensíveis – não devem ser mesclados com dados de outros clientes sem controles de compensação enquanto em uso, armazenados ou em trânsito. A mistura ou mescla de dados será um desafio quando as preocupações quanto à segurança de dados e à geolocalização aumentam. Esquemas de backup e recuperação de dados para recuperação e restauração. Os dados devem estar disponíveis e esquemas de backup e recuperação para Computação em Nuvem devem estar ativos e efetivos, objetivando prevenir perda de dados, sobrescrita e destruição não intencional de dados. Não assuma que dados baseados em Computação em Nuvem estejam a salvo e sejam recuperáveis. Descoberta de dados. Como o sistema legal continua focando a descoberta eletrônica de dados, provedores de serviço de Computação em Nuvem e proprietários de dados necessitarão focar em descoberta de dados, assegurando às autoridades legais e regulatórias que todos os dados requisitados tenham sido obtidos. Em um ambiente de Computação em Nuvem esta questão é extremamente difícil de ser respondida e exigirá controles administrativos, técnicos e legais quando requerido. Agregação e inferência de dados. Com dados na nuvem, existem preocupações adicionais de inferência e agregação de dados que poderão resultar em violação de confidencialidade de informações sensíveis e confidenciais. Portanto, devem ser definidas práticas que garantam ao proprietário dos dados e às partes interessadas (stakeholders) que os dados ainda estejam protegidos de uma súbita “violação” quando estiverem sendo mesclados e/ou agregados para suportar outros sistemas que não o seu principal, revelando assim informação protegida (p. ex., dados médicos contendo nomes e informações médicas misturados com dados anônimos mas, contendo o mesmo “campo de correlação”).
Recomendações
Entenda como a integridade é mantida e como o comprometimento da integridade é detectado e informado aos clientes. A mesma recomendação aplica-se à confidencialidade quando apropriado.
O provedor de serviço de nuvem deverá assegurar ao proprietário dos dados que eles proveem divulgação de todas as suas informações (full disclosure) (também conhecida como “transparência”) relativas às práticas e procedimentos de segurança de acordo com o estabelecido em seus SLAs.
Garantir a identificação específica de todos os controles usados durante o ciclo de vida dos dados. Garanta as especificações de qual entidade é responsável por cada controle entre o proprietário dos dados e o provedor de serviços de nuvem.
Copyright © 2009 Cloud Security Alliance
45
Mantenha uma filosofia fundamentada no conhecimento de onde seus dados estão. Assegure sua habilidade de conhecimento sobre a localização geográfica de armazenamento. Estipule isto em seus SLAs e contratos. Garanta que controles apropriados relativos às restrições de cada país envolvido no serviço estejam definidos e reforçados.
Entenda as circunstâncias pelas quais o armazenamento possa ser apreendido por um terceiro ou entidade governamental. Verifique se seu SLA com o provedor de serviço de nuvem inclui processo de notificação prévia ao proprietário dos dados (se possível) que as informações do proprietário dos dados tenham sido ou serão apreendidas.
Em alguns casos, uma intimação ou citação de e-discovery pode ser interposta contra o provedor de serviços de Computação em Nuvem. Neste caso, quando o provedor possuir custódia dos dados do cliente, o provedor de serviços de Computação em Nuvem deverá ser forçado a informar ao proprietário dos dados que o provedor de serviços de Computação em Nuvem será obrigado a divulgar a informação do proprietário dos dados.
O sistema de penalidades de serviço deverá ser incluído no contrato entre o proprietário dos dados e o provedor de serviços de nuvem. Especificamente, dados que seriam objetos de infrações contra disposições legais estaduais e internacionais (por ex., California Senate Bill 1386 ou as novas regras de violação de dados HIPAA) deverão ser protegidas pelo provedor de serviços de nuvem.
Será do proprietário dos dados a responsabilidade de determinar quem deverá acessar os dados, quais serão seus direitos e privilégios e sob quais condições estes direitos de acesso serão providos. O proprietário dos dados deverá manter uma política de “Negar Tudo por Padrão” para ambos os funcionários do proprietário dos dados e os do provedor de serviços de nuvem.
Provedores de serviços de Computação em Nuvem deverão oferecer linguagem contratual que garanta a negação de acesso aos dados como uma filosofia fundamental (por ex., “Negar Tudo por Padrão”). Isto especificamente aplica-se aos funcionários de serviços de Computação em Nuvem e seus outros clientes, exceto os funcionários e pessoal autorizado pelo proprietário dos dados.
É responsabilidade do proprietário dos dados definir e identificar a classificação dos dados. É responsabilidade do provedor de serviços de Computação em Nuvem fazer valer os requisitos de acesso do proprietário dos dados, baseados na classificação dos dados. Tais responsabilidades deverão estar em contrato, reforçadas e auditadas para conformidade.
Quando um cliente é obrigado a divulgar informação, a contaminação de dados não deverá ocorrer. Não somente o proprietário dos dados precisará garantir que todos os dados requeridos por mandado de busca e apreensão, intimações, decisões de e-discovery, etc. estejam intactos e sejam divulgados apropriadamente; o proprietário dos dados deverá certificar-se que nenhum outro dado seja afetado.
Criptografia de dados no “Cripografia de dados armazenados e criptografia de dados em trânsito” (Domínio de Referência 11, Criptografia e Gerenciamento de Chaves.)
Identifique limites de confiança através da arquitetura de TI e camadas de abstração. Possibilite aos subsistemas somente transpor os limites de confiança quando necessário e
Copyright © 2009 Cloud Security Alliance
46
com apropriadas contramedidas para prevenir divulgação não autorizada, alteração ou destruição de dados.
Entenda quais técnicas de compartimentalização são aplicadas por um provedor para isolar seus clientes uns dos outros. Um provedor poderá utilizar uma variedade de métodos dependendo dos tipos e quantidade de serviços oferecidos.
Entenda as capacidades e limitações de busca de dados do provedor de serviço de nuvem quando tentar visualizar ‘dentro’ da série de dados para descoberta de dados.
Entenda como a criptografia é gerenciada em armazenamento de multilocação. Existe uma chave única para todos os proprietários de dados, uma chave por proprietário de dados ou múltiplas chaves por proprietário de dados? Há um sistema para prevenir diferentes proprietários de dados de possuir as mesmas chaves de criptografia?
Os proprietários de dados deverão exigir que os provedores de serviço de Computação em Nuvem garantam que seus dados de cópias de segurança não estejam misturados com os dados de outro cliente de serviço de nuvem.
Entenda o processo de descarte de dados armazenados pelo provedor de serviço de nuvem. Destruição de dados é extremamente difícil em um ambiente de multilocação e o provedor de serviço de nuvem deverá estar usando criptografia forte no armazenamento que resulte em dados não legíveis quando o armazenamento for reciclado, descartado ou acessado de qualquer maneira fora das aplicações, processos e entidades autorizadas.
Escalonamento de retenção e destruição de dados são responsabilidades do proprietário dos dados. É responsabilidade do provedor de serviço de Computação em Nuvem destruir os dados quando solicitado, com especial ênfase na destruição de todos os dados em todas as localizações, incluindo as “folgas” de armazenamento em estruturas de dados e em mídia. O proprietário da informação deverá reforçar e auditar esta prática se possível.
Entenda a segregação lógica de informação e os controles de proteção implementados.
Entenda as restrições de privacidade inerentes aos dados confiados a sua companhia; você poderá ter que designar seu provedor de serviço de nuvem como um tipo particular de parceiro antes de confiar-lhes esta informação.
Entenda as políticas e processos do provedor de serviço de nuvem para retenção e destruição de dados e como eles se comparam à sua política organizacional interna. Esteja ciente que garantir a retenção de dados pode ser mais fácil para o provedor de serviço de nuvem demonstrar, enquanto para destruição de dados pode ser muito difícil.
Negocie penalidades pagas pelo provedor de serviço de nuvem para violação de dados para garantir que isso seja levado a sério. Se viável, clientes deverão buscar ressarcimento de todos os custos por violações como parte de seus contratos com provedor. Se inviável, clientes deverão explorar outros meios de transferência de risco tais como seguro para recuperação de perdas por violação.
Execute testes regulares de backup e recuperação para assegurar que a segregação lógica e os controles são efetivos.
Copyright © 2009 Cloud Security Alliance
47
Garanta que o pessoal do provedor de serviço de nuvem esteja disponível para prover uma segregação lógica de funções.
Entenda como criptografia é gerenciada em armazenamento de multilocação. Há uma única chave para todos os clientes, uma chave por cliente, ou múltiplas chaves por cliente?
Recomendações de Segurança de Dados por fase de GCVI Algumas de nossas recomendações gerais, assim como outros controles específicos, são listadas dentro do contexto de cada fase do ciclo de vida. Por favor, tenha em mente que dependendo do modelo de serviço de Computação em Nuvem (SaaS, PaaS ou IaaS), algumas recomendações necessitarão ser implementadas pelo cliente e outras deverão ser implementadas pelo provedor de serviço de nuvem. Crie Identifique capacidades disponíveis de identificação e classificação de dados. Soluções de gestão de permissões empresariais pode ser uma solução. O uso de rótulos (tagging) de dados está se tornando comum em ambientes Web 2.0 e pode ser usado como modelo para ajudar a classificação da informação Armazene Identifique controles de acesso disponíveis nos ambientes de sistemas de arquivos, DBMS, sistemas de gestão de documentos, etc. Soluções de criptografia, como aplicadas em correios eletrônicos, redes, bancos de dados, arquivos e sistemas de arquivos. Ferramentas de proteção a conteúdos (como DLP, ou Data Loss Prevention) podem auxiliar identificando e auditando dados que necessitem de controles. Uso Monitoramento de sistemas e aplicações via correlação de logs e/ou ferramentas baseadas em agentes Lógica de aplicações Controles em níveis de objetos em soluções baseadas em DBMS Compartilhamento Monitoramento de sistemas e aplicações via correlação de logs e/ou ferramentas baseadas em agentes Lógica de aplicações Controles em níveis de objetos em soluções baseadas em DBMS Identifique controles de acesso disponíveis nos ambientes de sistemas de arquivos, DBMS, sistemas de gestão de documentos, etc.
Copyright © 2009 Cloud Security Alliance
48
Soluções de criptografia, como aplicadas em correios eletrônicos, redes, bancos de dados, arquivos e sistemas de arquivos. Ferramentas de proteção a conteúdos (como DLP, ou Data Loss Prevention) podem auxiliar identificando e auditando dados que necessitem de controles. Armazenamento Criptografia, como aplicada em fitas de backup e outros sistemas de armazenamento de alta capacidade. Gestão e monitoramento de ativos Descarte Crypto-shredding: Descarte de todos os dados principais relacionados à informações criptografadas Descarte seguro através de limpeza de discos e técnicas relacionadas Destruição física, como desmagnetização de mídias. Tentativa de identificação de conteúdo para assegurar o processo de descarte. Colaboradores da Versão Original: Richard Austin, Ernie Hayden, Geir Arild EnghHellesvik, Wing Ko, Sergio Loureiro, Jesus Luna Garcia, Rich Mogull, Jeff Reich Colaboradores da Versão Brasileira: Filipe Villar, Gilberto Sudré, Guilherme Bitencourt, Roney Médice, Uélinton Santos
Copyright © 2009 Cloud Security Alliance
49
Domínio 6: Portabilidade e Interoperabilidade As organizações devem considerar a adoção de uma nuvem compreendendo que talvez elas tenham que mudar seus provedores futuramente. Portabilidade e interoperabilidade devem ser consideradas desde o início como parte do gerenciamento de risco e da garantia da segurança de quaisquer programas de adoção de uma nuvem. Grandes provedores de Computação em Nuvem podem oferecer redundância geográfica na nuvem, na esperança de garantir alta disponibilidade com um único provedor. No entanto, é aconselhável que um plano básico de continuidade seja feito, para ajudar a minimizar os impactos em um cenário de desastre. Diversas empresas, no futuro, inesperadamente irão se deparar com a necessidade de trocar de provedor por várias razões, incluindo:
Um aumento inaceitável nos custos de renovação de contrato. Um provedor encerra suas operações de negócio. Um provedor cancela repentinamente um ou mais serviços que estão sendo utilizados, sem um plano de migração aceitável. Uma queda inaceitável na qualidade do serviço, como uma falha no cumprimento dos requisitos de desempenho ou para alcançar os acordos de níveis de serviço (SLAs). Uma disputa comercial entre o cliente e o provedor da nuvem.
Algumas considerações arquiteturais simples podem ajudar a minimizar os danos causados quando estes tipos de cenários ocorrerem. Entretanto, os meios para lidar com essas questões dependem do tipo de serviço na nuvem. Com o Software como um Serviço (SaaS), o cliente da nuvem, por definição, substitui os novos softwares pelos antigos. Portanto, o foco não está na portabilidade das aplicações, mas em preservar ou melhorar as funcionalidades de segurança providas pela aplicação legada e conseguir uma migração dos dados bem sucedida. Com a Plataforma como um Serviço (PaaS), a expectativa é que algum grau de modificação na aplicação seja necessário para atingir a portabilidade. O foco é minimizar a quantidade de recodificação da aplicação, enquanto os controles de segurança são mantidos ou melhorados, juntamente com uma migração dos dados bem sucedida. Com a Infraestrutura como um Serviço (IaaS), o foco e a expectativa é que ambas, aplicações e dados, sejam capazes de serem migrados e executados em um novo provedor de nuvem. Devido a uma falta de padrões de interoperabilidade e à falta de pressão suficiente do mercado para a criação desses padrões, a transição entre provedores de nuvem pode se transformar em um doloroso processo manual. A partir de uma perspectiva de segurança, nossa principal preocupação é manter a consistência dos controles de segurança enquanto mudamos o ambiente.
Recomendações Para Todas as Soluções de Computação em Nuvem:
A substituição do provedor de serviços de nuvem é, em praticamente todos os casos, uma transação de negócios negativa para pelo menos uma das partes, o que pode causar uma reação inesperada do antigo provedor da nuvem. Isto deve ser planejado no
Copyright © 2009 Cloud Security Alliance
50
processo de contratação, conforme descrito no Domínio 3, no seu plano de continuidade de negócios, descrito no Domínio 7 e como parte da sua governança global no Domínio 2.
Entender o tamanho dos conjuntos de dados hospedados em um provedor de nuvem. O tamanho dos dados pode causar uma interrupção do serviço durante a transição, ou um período de transição maior do que o previsto. Muitos clientes descobriram que transportar os discos rígidos pode ser mais rápido do que a transmissão eletrônica de grandes massas de dados.
Documentar a arquitetura de segurança e a configuração individual de cada componente de controle de segurança, de forma que eles possam ser utilizados para ajudar nas auditorias internas, bem como para facilitar a migração para novos provedores.
Para Soluções em Nuvem IaaS:
Entender como imagens de máquinas virtuais podem ser capturadas e portadas para o novo provedor de nuvem que pode utilizar uma tecnologia diferente de virtualização.
Identificar e eliminar (ou pelo menos documentar) todas as extensões específicas do provedor no ambiente de máquina virtual.
Entender quais práticas são utilizadas para garantir uma desalocação apropriada das imagens depois que uma aplicação é portada de um provedor de nuvem.
Compreender as práticas utilizadas para o desmantelamento dos discos e dispositivos de armazenamento.
Identificar e entender as dependências baseadas em Hardware/Plataforma antes de migrar a aplicação/dados.
Solicitar acesso a logs do sistema, rastros e registros de acesso e de faturamento do provedor de nuvem antigo.
Identificar opções para continuar ou expandir o serviço com o provedor de nuvem legado, em parte ou no todo, caso o novo serviço demonstre ser inferior.
Determinar se existem quaisquer funções de nível gerencial, interfaces ou APIs utilizadas que são incompatíveis ou não implantadas no novo provedor.
Para Soluções em Nuvem PaaS:
Quando possível, utilize componentes de uma plataforma com sintaxes padronizadas, APIs abertas e normas abertas.
Entender quais ferramentas estão disponíveis para a transmissão segura dos dados, para backup e para restauração.
Copyright © 2009 Cloud Security Alliance
51
Entender e documentar os componentes da aplicação e módulos específicos para o provedor de PaaS e desenvolver a arquitetura de uma aplicação com camadas de abstração para minimizar o acesso direto aos módulos proprietários.
Compreender como serviços básicos como monitoramento, logs e auditoria podem ser transferidos para o novo provedor.
Entender as funções de controle fornecidas pelo provedor de nuvem antigo e como será feita a transferência para o novo provedor.
Quando migrar para uma nova plataforma, conheça os impactos no desempenho e na disponibilidade da aplicação e como estes impactos são calculados.
Entender como testes são completados antes e depois da migração, para verificar se os serviços ou aplicações estão operando corretamente. Garantir que a responsabilidade de testar, de ambos, provedor e usuário, são bem conhecidas e documentadas.
Para Soluções em Nuvem SaaS:
Executar extrações de dados e backups regulares para formatos que possam ser utilizados fora do provedor de SaaS.
Entender se os metadados podem ser preservados e migrados.
Compreender que todas as ferramentas personalizadas terão que ser recodificadas ou, o novo provedor deve fornecer novas ferramentas.
Assegurar consistência eficaz dos controles entre o antigo e o novo provedor.
Assegurar a possibilidade de migração de backups e outras cópias de logs, registros de acesso e qualquer outra informação pertinente que possa ser necessária por razões legais e conformidade.
Entender o gerenciamento, o monitoramento e as interfaces de relatórios e suas integrações entre os ambientes.
Há uma disposição do novo provedor de testar e avaliar a aplicação antes da migração?
Colaboradores da Versão Original: Warren Axelrod, Aradhna Chetal, Arthur Hedge, Dennis Hurst, Sam Johnston, Scott Morrison, Adam Munter, Michael Sutton, Joe Wallace Colaboradores da Versão Brasileira: Alexandre Pupo, Guilherme Ostrock, Ricardo
Makino
Copyright © 2009 Cloud Security Alliance
52
Seção III. Operando na Nuvem
Copyright © 2009 Cloud Security Alliance
53
Domínio 7: Segurança Tradicional, Continuidade de Negócios e Recuperação de Desastres O conjunto de conhecimentos acumulados no âmbito da segurança física tradicional, do planejamento de continuidade de negócios e da recuperação de desastres ainda é bastante relevante para a Computação em Nuvem. O ritmo acelerado das mudanças e a falta de transparência inerentes da Computação em Nuvem exigem que profissionais tradicionais de Segurança, Planejamento de Continuidade de Negócios e de Recuperação de Desastres estejam continuamente envolvidos no controle e monitoração dos seus provedores de nuvem escolhidos. Nosso desafio é colaborar na identificação de risco, reconhecer interdependências, integrar e alavancar os recursos de forma dinâmica e poderosa. A Computação em Nuvem e a infraestrutura que a acompanha ajudam a diminuir determinados problemas de segurança, mas podem aumentar outros e podem nunca eliminar a necessidade de segurança. Enquanto continuam a existir grandes mudanças nos negócios e na tecnologia, os princípios tradicionais de segurança permanecem os mesmos.
Recomendações
Tenha em mente que a centralização dos dados significa que o risco de fraude interna partindo de dentro do provedor de serviços de nuvem é uma preocupação significativa.
Provedores de serviço de nuvem devem considerar adotar como padrão de segurança os requisitos mais rigorosos dos clientes. Para que o alcance dessas práticas de segurança não impacte negativamente na experiência do cliente, as práticas de segurança mais rigorosas devem se mostrar economicamente eficazes no longo prazo em termos de redução do risco, bem como na avaliação das várias áreas de preocupação, baseada nas necessidades dos clientes.
Os provedores devem ter uma segregação robusta das responsabilidades das funções, verificar os antecedentes dos funcionários, exigir / aplicar acordos de não-divulgação de dados para os seus funcionários e limitar o acesso às informações dos clientes aos funcionários na medida do que for absolutamente necessário para a execução de suas funções.
Os clientes devem efetuar inspeções aos locais das instalações de seu provedor de nuvem sempre que possível.
Os clientes devem inspecionar os planos de recuperação de desastres e de continuidade de negócios de seus provedores de nuvem.
Os clientes devem identificar as interdependências físicas na infraestrutura do provedor.
Garantir que há um detalhamento formal estabelecido no contrato para definir claramente as obrigações contratuais relacionadas com segurança, recuperação e acesso aos dados.
Clientes devem solicitar a documentação dos controles de segurança internos e externos do provedor e a adesão aos padrões da indústria.
Copyright © 2009 Cloud Security Alliance
54
Assegurar que Objetivos de Tempo de Recuperação (Recovery Time Objectives, ou RTO) do cliente são totalmente compreendidos e definidos nas relações contratuais e baseados no processo de planejamento tecnológico. Certifique-se que roadmaps, políticas e capacidades operacionais satisfaçam estes requisitos.
Clientes precisam confirmar que o provedor tem uma política de Plano de Continuidade de Negócios aprovada pelo conselho de administração do provedor.
Clientes devem procurar evidências de apoio efetivo da gestão e revisão periódica do Programa de Continuidade de Negócios para garantir que este esteja ativo.
Clientes devem verificar se o Programa de Continuidade de Negócios é certificado e / ou mapeado com normas internacionalmente reconhecidas como a BS 25999.
Clientes devem verificar se o provedor tem algum recurso on-line dedicado à segurança e BCP, onde a visão geral do programa e as fichas técnicas estejam disponíveis para consulta.
Certifique-se que os provedores de serviço de nuvem sejam controlados através do Processo de Segurança de Fornecedores (Vendor Security Process - VSP) para que haja uma clara compreensão de quais dados devem ser compartilhados e quais controles devem ser utilizados. As determinações do VSP devem alimentar o processo de tomada de decisão e avaliação se o risco é aceitável ou não.
A natureza dinâmica da Computação em Nuvem e sua relativa juventude justificam ciclos mais frequentes de todas as atividades acima para a descoberta de mudanças não comunicadas aos clientes.
Colaboradores da Versão Original: Randolph Barr, Luis Morales, Jeff Spivey, David Tyson Colaboradores da Versão Brasileira: Anchises Moraes, Rafael B. Brinhosa
Copyright © 2009 Cloud Security Alliance
55
Domínio 8: Operações e Data center O número de provedores de Computação em Nuvem continua a aumentar à medida que empresas e consumidores de serviços de TI se movem para a nuvem. Houve um crescimento similar em data centers para atender à prestação de serviços de Computação em Nuvem. Provedores de nuvem de todos os tipos e tamanhos, inclusive líderes de tecnologia e milhares de iniciantes e empresas emergentes estão fazendo grandes investimentos nesta nova abordagem promissora para a prestação de serviços de TI. O compartilhamento de recursos de TI para criar eficiências e economias de escala não é um conceito novo. No entanto, o modelo de negócio na nuvem funciona melhor se os grandes investimentos, tradicionalmente, em operações de data centers são distribuídos a um número maior de consumidores. Historicamente, arquiteturas de data center foram deliberadamente superdimensionadas para superar picos de carga periódicos, o que significa que os recursos do Data center devem estar frequentemente sem utilização ou subutilizados, por longas extensões de tempo, durante os períodos de demanda baixa ou normal. Provedores de serviço de nuvem, por outro lado, procuram otimizar o uso de recursos, tanto humanos quanto tecnológicos, a fim de ganhar vantagem competitiva e maximizar as margens de lucro na operação. O desafio para consumidores de serviços de nuvem é descobrir o modo de avaliação das capacidades do provedor para executar serviços apropriados e de baixo custo, não deixando de proteger os próprios dados e interesses do cliente. Não presuma que o provedor tenha os melhores interesses de seus clientes como sua prioridade máxima. Com o modelo comum de operadora (carrier) para entrega de serviços, do qual a Computação em Nuvem é uma forma, o provedor de serviço normalmente tem pouco ou nenhum acesso aos dados e sistemas que se situam além do nível contratado de gerenciamento, tampouco tem controle sobre eles. Certamente essa é a abordagem correta a se ter, mas algumas arquiteturas em nuvem tomam liberdades com a integridade e a segurança dos dados dos clientes que os deixariam desconfortáveis se delas eles estivessem cientes. Os consumidores devem educar-se acerca dos serviços sobre os quais estão pensando em contratar para fazerem perguntas apropriadas e, se familiarizarem com as arquiteturas básicas e as áreas com potenciais de vulnerabilidade de segurança. Ao tomar a decisão de mover toda ou parte das operações de TI para a nuvem, é útil primeiramente entender como um provedor de nuvem implementou as “Cinco Principais Características da Computação em Nuvem” do Domínio 1 e como essa arquitetura e infraestrutura tecnológica afeta a sua habilidade de satisfazer os acordos de nível de serviço e de endereçar preocupações com a segurança. A tecnologia específica da arquitetura tecnológica do provedor pode ser uma combinação de produtos de TI e outros serviços de nuvem como, por exemplo, se aproveitar vantajosamente do serviço de armazenamento IaaS de outro provedor. A arquitetura e a infraestrutura tecnológica dos provedores de serviço de nuvem podem variar, mas para satisfazer requisitos de segurança, todos eles devem poder demonstrar compartimentalização abrangente dos sistemas, dados, redes, gerenciamento, fornecimento e pessoal. Os controles separando cada camada da infraestrutura devem ser propriamente integrados para que elas não interfiram umas com as outras. Por exemplo, investigue se a compartimentagem do armazenamento pode ser facilmente ignorada por ferramentas de gestão ou mau gerenciamento de chaves. Por último, compreenda como o provedor de nuvem lida com a democratização e dinamismo dos recursos para melhor prever os níveis apropriados de disponibilidade do sistema e de desempenho
Copyright © 2009 Cloud Security Alliance
56
durante as flutuações normais de negócio. Lembre-se, a teoria de Computação em Nuvem ainda excede, em alguma medida, a prática: muitos clientes fazem pressuposições incorretas sobre o nível de automação atualmente disponível. Na medida em que o recurso provisionado é consumido, o provedor é responsável por garantir que recursos adicionais são alocados imperceptivelmente para o cliente.
Recomendações É imperativo que uma organização, considerando a compra de serviços de nuvem, sejam eles de qualquer tipo, esteja totalmente ciente do tipo exato de serviços que serão contratados e do que não está incluso. Abaixo está um sumário de informações que precisam ser revisadas como parte do processo de seleção do vendedor e questões adicionais para ajudar a qualificar os provedores e comparar melhor os seus serviços com as necessidades da organização.
Quaisquer que sejam as certificações que os provedores de nuvem mantêm, é importante obter o compromisso e a permissão de conduzir auditorias feitas pelo cliente ou por terceiros.
Os clientes de serviços de nuvem devem compreender como os provedores implementam as “Cinco Principais Características da Computação em Nuvem” do Domínio 1.
Ainda que as arquiteturas tecnológicas dos provedores de nuvem variem, todos eles devem poder demonstrar divisão compreensiva de sistemas, redes, gerenciamento, provisão e pessoal.
Compreenda como a democratização de recursos ocorre dentro da nuvem de seu provedor para prever melhor a disponibilidade e desempenho do sistema durante suas flutuações de negócios. Se possível, descubra os outros clientes do provedor de nuvem para avaliar o impacto que as flutuações de negócios deles podem ter sobre a sua vivência como cliente do provedor de nuvem. No entanto, isso não substitui a garantia de que os acordos acerca do nível de serviço estejam claramente definidos, mensuráveis, executáveis e adequados para a sua necessidade.
Os clientes dos serviços de nuvem devem entender as políticas e procedimentos de correção do provedor e como eles podem influenciar os seus ambientes. Essa compreensão deve estar refletida no contrato.
A contínua melhoria é particularmente importante em um ambiente de nuvem, pois qualquer melhoria nas políticas, processos e procedimentos, ou ferramentas para um cliente determinado podem resultar em melhoria do serviço para todos os clientes. Procure por provedores de nuvem com processos padrão de melhoria contínua.
Suporte técnico ou central de serviço são frequentemente uma janela pela qual o cliente pode ver as operações do provedor. Para obter uma experiência de suporte suave e uniforme para seus usuários finais, é essencial assegurar que os processos, procedimentos, ferramentas e horário de suporte do provedor são compatíveis com as suas.
Como no Domínio 7, reveja os planos de recuperação de desastres e de continuidade do negócio a partir da perspectiva de TI e perceba como eles se relacionam com pessoas e
Copyright © 2009 Cloud Security Alliance
57
processos. Uma arquitetura tecnológica do provedor de nuvem pode usar novos métodos, porém não testados para tolerância a falhas, por exemplo. A continuidade do próprio negócio do cliente deve também abranger os impactos e limitações da Computação em Nuvem. Colaboradores da Versão Original: John Arnold, Richard Austin, Ralph Broom, Beth Cohen, Wing Ko, Hadass Harel, David Lingenfelter, Beau Monday, Lee Newcombe, Jeff Reich, Tajeshwar Singh, Alexander Windel, Richard Zhao. Colaboradores da Versão Original: Eder Alvares Pereira de Souza, Olympio Rennó Ribeiro Jr, Raphael Sanches
Copyright © 2009 Cloud Security Alliance
58
Domínio 9: Resposta a Incidente, Notificação e Remediação O principio de Computação em Nuvem torna difícil determinar quem contatar em caso de incidente de segurança, vazamento de informação ou qualquer outro evento que necessite de investigação e resposta. Mecanismos padrão de resposta a incidentes de segurança podem ser adaptados para acomodar as mudanças requeridas pelas responsabilidades compartilhadas de notificação. Este domínio provê um guia de como tratar desses incidentes. O problema para o cliente de Computação em Nuvem é que aplicações disponíveis em provedores de Computação em Nuvem nem sempre são desenhadas com os princípios de segurança e integridade de dados em mente. Isso pode resultar em aplicações vulneráveis sendo implementadas em ambientes de nuvem, desencadeando incidentes de segurança. Adicionalmente, falhas na arquitetura de infraestrutura, erros cometidos durante procedimentos de “hardening” e simples descuidos representam riscos significativos para operações em nuvem. Obviamente, vulnerabilidades semelhantes também põem sob risco operações tradicionais de data center. Experiência técnica obviamente é necessária na resposta a incidentes, porém, privacidade e questões legais têm muito a contribuir para segurança em nuvem. Ela também tem um papel importante na resposta a incidente referente à notificação, remediação e possível subsequente ação legal. Uma organização que cogita usar os serviços de Computação em Nuvem precisa revisar quais mecanismos foram implementados em relação ao acesso a dados de empregados que não são regidos por contratos de usuário e políticas de privacidade. Dados de aplicação que não são gerenciados por uma aplicação do próprio provedor de nuvem, tais como IaaS e arquiteturas PaaS, geralmente têm controles diferentes daqueles gerenciados pela aplicação de um provedor de SaaS. As complexidades de grandes provedores de Computação em Nuvem oferecendo SaaS, PaaS e IaaS criam problemas significativos de resposta a incidente, os quais devem ser analisados por potenciais clientes para um nível aceitável de serviço. Ao avaliar provedores de nuvem, é importante ter consciência de que o provedor pode estar hospedando centenas de milhares de instancias de aplicações. Do ponto de vista de monitoração de resposta a incidente, quaisquer aplicações externas aumentam a responsabilidade do centro de operações de segurança (do inglês SOC). Normalmente um SOC monitora os alertas e outros indicadores de incidente, tais como aqueles produzidos por sistemas de detecção de intrusão e firewalls. Porém, o número de fontes de informação a serem monitoradas e o volume de notificações pode crescer exponencialmente num ambiente de “open cloud”, pois o SOC teria que monitorar a atividade entre clientes, assim como incidentes externos. Uma organização precisará entender a estratégia de resposta a incidente do provedor escolhido. Esta estratégia deve endereçar identificação e notificação, assim como oferecer opções para remedição de acesso não autorizado a dados de aplicação. Para tornar ainda mais complexa, a gestão de dados de aplicações e acessos têm significados e requisitos regulatórios diferentes conforme a localização física dos dados. Por exemplo, um incidente pode ocorrer envolvendo dados armazenados na Alemanha. Se os mesmos dados estivessem sendo armazenados nos Estados Unidos, esse mesmo evento poderia não ser considerado um incidente. Essa complicação torna a identificação de incidentes particularmente desafiadora.
Copyright © 2009 Cloud Security Alliance
59
Recomendações
Clientes de Computação em Nuvem precisam definir claramente e comunicar aos provedores o que eles consideram incidentes (tais como roubo de dados) versus meros eventos (tais como alertas de suspeita de intrusão) antes de implementar o serviço.
Clientes de Computação em Nuvem podem vir a ter um envolvimento limitado com as atividades de resposta a incidente do provedor. Portanto, é crucial para os clientes entender os canais de comunicação predefinidos para contatar a equipe de resposta a incidentes.
Clientes de Computação em Nuvem devem investigar quais ferramentas de detecção e analise de incidentes o provedor utiliza para garantir que eles sejam compatíveis com seus próprios sistemas. Um formato de log proprietário ou incomum poderia ser um grande problema em investigações conjuntas, particularmente aqueles que envolvam questões legais ou intervenção governamental.
Sistemas e aplicações desenvolvidas com baixo nível de segurança podem facilmente sobrecarregar qualquer capacidade de resposta a incidente. A condução de uma avaliação de riscos adequada nos sistemas e a utilização da prática de segurança em camadas são essenciais para reduzir as chances de um incidente de segurança.
Centros de Operações de Segurança (do inglês SOC) normalmente assumem um modelo único de governança relacionado à resposta a incidente, o qual não é apropriado para provedores multilocatários de nuvem. Um processo robusto e bem gerenciado de “Gestão de Eventos e Informações de Segurança - SIEM”, que identifica as fontes disponíveis de informação (logs de aplicação, logs de firewall, logs de IDS, etc.) e as combina com uma plataforma comum de analise e notificação, pode ajudar consideravelmente o SOC na detecção de incidentes dentro da plataforma de Computação em Nuvem.
Para facilitar a analise detalhada de informação “off-line”, procure por provedores de Computação em Nuvem que tenham a habilidade de fornecer “fotografias” do ambiente virtual do cliente – firewalls, redes (switches), sistemas, aplicações e dados.
Contenção é uma corrida entre o controle de danos e coleta de evidência. Estratégias de contenção que foquem na tríade confidencialidade-integridade-disponibilidade podem ser eficazes.
Remediação destaca a importância de poder restaurar um sistema para um estado anterior e até mesmo retornar 6 a 12 meses atrás em uma configuração tida como confiável. Mantendo em mente as possibilidades e requerimentos legais, a remediação pode também vir a suportar registros forenses de dados de incidentes.
Qualquer dado classificado como privado para efeito regulatório em relação a roubo de informações deve ser sempre criptografado para reduzir as consequências de um incidente de roubo de dado. Clientes devem estipular os requisitos de criptografia contratualmente, conforme Domínio 11.
Copyright © 2009 Cloud Security Alliance
60
Alguns provedores de Computação em Nuvem podem hospedar um número significativo de clientes com aplicações únicas. Esses provedores de Computação em Nuvem devem considerar estruturas de registros (logging frameworks) de camada de aplicação com o intuito de rastrear incidentes a um cliente em especifico. Esses provedores de Computação em Nuvem devem também criar um registro de proprietários das aplicações por interface de aplicação (URL, serviços de SOA, etc.)
Firewalls de aplicação, proxies e outras ferramentas de log são capacidades básicas atualmente disponíveis para suportar a resposta a incidentes em um ambiente multilocatário.
Colaboradores da Versão Original: John Arnold, Richard Austin, Ralph Broom, Beth Cohen, Wing Ko, Hadass Harel, David Lingenfelter, Beau Monday, Lee Newcombe, Jeff Reich, Tajeshwar Singh, Alexander Windel, Richard Zhao Colaboradores da Versão Brasileira: Filipe Villar, Marcelo Carvalho
Copyright © 2009 Cloud Security Alliance
61
Domínio 10: Segurança de Aplicações Ambientes de nuvem – em virtude de sua flexibilidade, receptividade e frequente disponibilidade pública - desafiam muitas suposições fundamentais sobre segurança de aplicações. Algumas destas suposições já são bem compreendidas; no entanto, muitas ainda não são. Esta seção visa documentar como a Computação em Nuvem influencia a segurança através do tempo de vida de uma aplicação – desde o design até as operações de desativação. Este guia é para todos os stakeholders – incluindo desenvolvedores de aplicações, profissionais de segurança, pessoal de operação e gerenciamento técnico – tratando sobre a melhor forma de mitigar os riscos e gerenciar garantias em aplicações de Computação em Nuvem. Computação em Nuvem é um desafio particular para aplicações através das camadas de Software como um Serviço (SaaS), Platforma como um Serviço (PaaS) e Infraestrutura como um Serviço(IaaS). Aplicações de software baseadas em nuvem requerem um rigor de design semelhante a aplicações que residem em uma DMZ clássica. Isto inclui uma profunda análise inicial cobrindo todos os tradicionais aspectos de confidencialidade, integridade e disponibilidade do gerenciamento da informação. Aplicações em ambientes de nuvem irão tanto impactar como serem impactadas pelos seguintes aspectos principais:
Arquitetura de Segurança da Aplicação – Considerações devem ser dadas à realidade de que a maioria das aplicações possui dependências em diversos outros sistemas. Com Computação em Nuvem, as dependências de aplicações podem ser altamente dinâmicas, até mesmo ao ponto onde cada dependência represente uma discreta parte de um provedor de serviço. As características de nuvem fazem o gerenciamento de configuração e o provisionamento contínuo significativamente mais complexos do que no desenvolvimento de aplicações tradicionais. O ambiente leva às necessidades de modificações arquiteturais para garantir segurança de aplicação.
Ciclo de Vida de Desenvolvimento de Software (SDLC) – A Computação em Nuvem afeta todos os aspectos do SDLC, abrangendo arquiteturas de aplicativos, projeto, desenvolvimento, garantia de qualidade, documentação, implantação, gerenciamento, manutenção e desativação.
Conformidade – Conformidade claramente afeta os dados, mas também influencia aplicações (por exemplo, regulando como um programa implementa uma função criptográfica em particular), plataformas (talvez pela prescrição dos controles e configurações de sistema operacional) e processos (tais como reportar requisitos para incidentes de segurança).
Ferramentas e Serviços – A Computação em Nuvem introduz uma série de novos desafios ao redor das ferramentas e serviços requeridos para construir e manter as aplicações em execução. Estes desafios incluem ferramentas de desenvolvimento e teste, utilitários de gerenciamento de aplicações, o acoplamento com serviços externos e dependências nas bibliotecas e serviços do sistema operacional, que podem ser originados de provedores de nuvem. Compreender as ramificações de que provê, detém, opera e assume a responsabilidade por cada um destes itens é fundamental.
Copyright © 2009 Cloud Security Alliance
62
Vulnerabilidades – Estas incluem não somente as bem documentadas – e continuamente em evolução – vulnerabilidades associadas com aplicações web, mas também vulnerabilidades associadas com aplicações SOA máquina-a-máquina, que estão sendo implantadas de modo crescente na nuvem.
Recomendações
A segurança no ciclo de vida de desenvolvimento de software (SDLC) é importante e deve abordar em alto nível estas três principais áreas de diferenciação com desenvolvimento baseado em nuvem: 1) ameaças atualizadas e modelos de confiança, 2) ferramentas de avaliação de aplicações para ambientes de nuvem e 3) processos de SDLC e checkpoints de qualidade para contabilizar mudanças arquiteturais de segurança para aplicações.
IaaS, PaaS e SaaS criam diferentes limites de confiança para o ciclo de vida de desenvolvimento de software; que devem ser contabilizados durante o desenvolvimento, testes e implantação de aplicações em produção.
Para IaaS, um fator chave de sucesso é a presença de imagens de máquinas virtuais confiáveis. A melhor alternativa é a capacidade de fornecer sua própria imagem de máquina virtual em conformidade com as políticas internas.
As melhores práticas disponíveis para fortificar sistemas host dentro de DMZs devem ser aplicadas para máquinas virtuais. Limitar os serviços disponíveis somente aqueles necessários para suportar a pilha da aplicação é apropriado.
Proteger a comunicação inter-host deve ser uma regra; não pode haver nenhuma suposição de um canal seguro entre hosts, quer esteja em um data center comum ou ainda em um mesmo dispositivo de hardware.
Gerenciar e proteger credenciais e materiais chave de aplicações são pontos críticos.
Cuidado adicional deve ser realizado no gerenciamento de arquivos usados para os registros (logs) e depuração (debugging) das aplicações, bem como a localização destes arquivos podem ser remotos ou desconhecidos e a informação confidencial.
Consideração para administração externa e multilocatários nos modelos de ameaça da aplicação.
Aplicações suficientemente complexas para influenciar um Enterprise Service Bus (ESB) precisam proteger diretamente o ESB, influenciando um protocolo, como o WS-Security. A capacidade de segmentar ESBs não está disponível em ambientes PaaS.
Métricas precisam ser aplicadas para avaliar a eficácia de programas de segurança de aplicação. Entre as métricas diretas específicas de segurança disponíveis estão escores de vulnerabilidade e cobertura de correções. Essas métricas podem indicar a qualidade da codificação de aplicação. Métricas de manipulação indireta de dados tais como o
Copyright © 2009 Cloud Security Alliance
63
percentual de dados cifrados, podem indicar que decisões responsáveis estão sendo tomadas a partir de uma perspectiva de arquitetura da aplicação.
Provedores de nuvem devem suportar ferramentas de segurança de análise dinâmica para aplicações web às aplicações hospedadas em seus ambientes.
Atenção deve ser dada para como os atores maliciosos irão reagir às novas arquiteturas de aplicações de nuvem, que obscurecem componentes de aplicações de seus exames minuciosos. Hackers tendem a atacar códigos visíveis, incluindo, mas não limitado ao código que está rodando no contexto do usuário. Eles são suscetíveis a atacar infraestruturas e realizar extensos testes em caixa-preta.
Clientes devem obter permissão contratual para realizar avaliações de vulnerabilidades remotas, incluindo a tradicional (rede/host) e avaliações de vulnerabilidades de aplicações. Muitos provedores de nuvem restringem avaliações de vulnerabilidades devido à incapacidade do provedor de distinguir tais testes de ataques reais e para evitar potenciais impactos sobre outros clientes.
Colaboradores da Versão Original: John Arnold, Warren Axelrod, Aradhna Chetal, Justin Foster, Arthur J. Hedge III, Georg Hess, Dennis Hurst, Jesus Luna Garcia, Scott Matsumoto, Alexander Meisel, Anish Mohammed, Scott Morrison, Joe Stein, Michael Sutton, James Tiller, Joe Wallace, Colin Watson Colaboradores da Versão Brasileira: Gabriel Negreira Barbosa, Jordan M. Bonagura, Luís Felipe Féres Santos
Copyright © 2009 Cloud Security Alliance
64
Domínio 11: Criptografia e Gerenciamento de Chaves Clientes e provedores de nuvem precisam precaver-se contra perda e roubo de dados. Hoje em dia, a criptografia de dados pessoais e empresariais é altamente recomendada e, em alguns casos, exigida por leis e regulamentações ao redor do mundo. Os clientes de nuvem querem que seus provedores cifrem seus dados para assegurar que os mesmos estejam protegidos não importando onde estejam localizados fisicamente. Da mesma forma, o provedor de nuvem precisa proteger os dados sensíveis de seus clientes. Criptografia forte com gerenciamento de chaves é um dos mecanismos fundamentais que os sistemas de Computação em Nuvem devem utilizar para proteger dados. Embora a cifragem, por si só, não necessariamente impeça a perda de dados, as disposições legais e regulamentações tratam dados cifrados perdidos como se os mesmos não tivessem sido perdidos. A cifragem fornece proteção de recursos enquanto o gerenciamento de chaves permite o acesso a recursos protegidos. Criptografia para Confidencialidade e Integridade Ambientes de nuvem são compartilhados com muitos locatários e provedores de serviços têm acesso privilegiado aos dados que estão nesses ambientes. Portanto, os dados confidenciais hospedados em uma nuvem devem ser protegidos através de uma combinação de controles de acesso (ver Domínio 12), responsabilidade contratual (ver Domínios 2, 3 e 4) e criptografia, que descrevemos nesta seção. Destes três pontos, a criptografia oferece os benefícios da mínima confiança no provedor de serviços de nuvem e da independência em casos de detecção de falhas operacionais.
Criptografar dados em trânsito através de redes. Existe a extrema necessidade de criptografar credenciais multiuso em trânsito através da Internet, tais como números de cartão de crédito, senhas e chaves privadas. Embora as redes de provedores de nuvem possam ser mais seguras que a Internet aberta, elas são, pela sua própria arquitetura, compostas de muitos elementos diferentes e diferentes organizações compartilham a nuvem. Por isso, é importante proteger essas informações sensíveis e regulamentadas em trânsito até mesmo dentro da rede dos provedores de nuvem. Normalmente, isso pode ser implementado com a mesma facilidade em ambientes SaaS, PaaS e IaaS. Criptografar dados em repouso. Criptografar dados em disco ou em um banco de dados de produção ativo possui valor, visto que isto pode proteger contra um provedor de serviços de nuvem malicioso ou um colocatário mal-intencionado, bem como contra alguns tipos de abuso de aplicações. Para o armazenamento de arquivos a longo prazo, alguns clientes criptografam seus próprios dados e então os enviam como texto cifrado para um fornecedor de armazenamento de dados em nuvem. O cliente, então, controla e detém as chaves criptográficas e, se necessário, decifra os dados em seu próprio ambiente. Criptografar dados em repouso é comum dentro de ambientes IaaS utilizando uma variedade de ferramentas de terceiros e provedores. Criptografar dados em repouso dentro de ambientes PaaS é, geralmente, mais complexo, necessitando instrumentação de ofertas do provedor ou customização especial. Criptografar dados em repouso dentro de ambientes SaaS é um recurso que clientes de nuvem não podem implementar diretamente e precisam solicitar a seus provedores.
Copyright © 2009 Cloud Security Alliance
65
Criptografar dados em mídias de backup. Isto pode proteger contra mau uso de uma mídia perdida ou roubada. Idealmente, o provedor de serviço de nuvem implementa tal mecanismo de forma transparente. Entretanto, como cliente e provedor de dados, é sua responsabilidade verificar que tal criptografia é utilizada. Uma consideração para a infraestrutura de criptografia é lidar com a longevidade dos dados. Além desses usos comuns de criptografia, a possiblidade de ataques exóticos contra provedores de nuvem também justifica uma maior exploração de meios para criptografar dados dinâmicos, incluindo dados residentes em memória. Gerenciamento de Chaves Provedores de serviço de nuvem existentes podem prover esquemas básicos de chaves de criptografia para proteger o desenvolvimento de aplicações e serviços de nuvem, ou podem delegar todas essas medidas de proteção para seus clientes. Enquanto provedores de serviço de nuvem estão progredindo para suportar esquemas robustos de gerenciamento de chaves, mais trabalho é necessário para superar barreiras para adoção. Padrões emergentes podem solucionar este problema em um futuro próximo, mas o trabalho ainda está em desenvolvimento. Existem muitos problemas e desafios de gerenciamento de chaves dentro da Computação em Nuvem: Repositórios seguros de chaves. Repositórios de chaves devem ser protegidos assim como qualquer outro dado sensível. Eles devem ser protegidos no armazenamento, no trânsito e nos backups. O armazenamento impróprio de chaves pode levar ao comprometimento de todos os dados cifrados. Acesso aos repositórios de chaves. O acesso a repositórios de chaves deve ser limitado às entidades que necessitem especificamente de chaves individuais. Devem existir ainda políticas que utilizem separação de papeis regendo os repositórios de chaves, para auxiliar o controle de acessos; uma entidade que utiliza uma dada chave não deve ser a mesma entidade que a armazena. Backup e recuperação de chaves. Perda de chaves inevitavelmente significa perda dos dados que as mesmas protegem. Enquanto isso é uma forma efetiva para destruir dados, a perda acidental de chaves que protegem dados críticos fundamentais de organizações seria devastadora para um negócio; então, soluções seguras de backup e recuperação devem ser implementadas. Existem vários padrões e diretrizes aplicáveis ao gerenciamento de chaves na nuvem. O Key Management Interoperability Protocol (KMIP), da OASIS, é um padrão emergente para um gerenciamento de chaves interoperável na nuvem. Os padrões IEEE 1619.3 cobrem criptografia de armazenamento e gerenciamento de chaves, especialmente no que diz respeito a armazenamento IaaS.
Recomendações
Utilizar criptografia para separar posse de dados de uso de dados.
Segregar o gerenciamento de chaves do provedor de nuvem que hospeda os dados, criando uma cadeia de separação. Isso protege tanto o provedor quanto o cliente
Copyright © 2009 Cloud Security Alliance
66
de nuvem de conflitos quando houver obrigação de fornecer dados devido a um mandato legal. Quando estipular a criptografia em linguagem de contrato, assegurar que a criptografia adira a padrões existentes de indústria e governo, como for aplicável. Tomar conhecimento de como, as instalações do provedor de nuvem provêm gerenciamento de papéis e separação de funções. Nos casos onde o provedor de nuvem deve efetuar o gerenciamento de chaves, se inteirar se o provedor possui processos definidos para um ciclo de vida do gerenciamento de chaves: como as chaves são geradas, utilizadas, armazenadas, submetidas a backup, recuperadas, rotacionadas e apagadas. Além disso, tomar conhecimento se a mesma chave é utilizada para todos os clientes ou se cada cliente tem seu próprio conjunto de chaves. Assegurar que dados regulamentados e/ou sensíveis de clientes sejam criptografados quando estiverem em trânsito através da rede interna do provedor de nuvem, além de serem criptografados quando estiverem em repouso. A responsabilidade de implementar tal recomendação é do cliente de nuvem em ambientes IaaS, de ambos (provedor e cliente) em ambientes PaaS e do provedor de nuvem em ambientes PaaS. Em ambientes IaaS, se inteirar como informações sensíveis e materiais chave quando não protegidos por criptografia tradicional podem ser expostos durante o uso. Por exemplo, arquivos de swap de máquinas virtuais e outros locais temporários de armazenamento de dados podem também necessitar ser criptografados.
Colaboradores da Versão Original: John Arnold, Girish Bhat, Jon Callas, Sergio Loureiro, Jean Pawluk, Michael Reiter, Joel Weise Colaboradores da Versão Brasileira: Dino Amaral, Eder Alvares Pereira de Souza, Gabriel Negreira Barbosa, Jimmy Cury, Jordan M. Bonagura, Julio Graziano Pontes, Raphael Sanches
Copyright © 2009 Cloud Security Alliance
67
Domínio 12: Gerenciamento de Identidade e Acesso. O gerenciamento de identidades e controle de acesso para aplicações corporativas permanece um dos maiores desafios enfrentados atualmente por TI. Mesmo que uma empresa possa viabilizar vários serviços de Computação em Nuvem sem uma boa estratégia de gerenciamento de identidade e acesso, em longo prazo, estender os serviços de identidade da empresa à nuvem será um requisito necessário para o uso de serviços de computação sob demanda. Suportar a atual adoção agressiva de um ecossistema reconhecidamente imaturo de nuvem requer uma sincera avaliação de quão preparada está a empresa para conduzir o Gerenciamento de Identidade e Acesso GIA (Identity and Access Management - IAM) baseado na nuvem, assim como entender as capacidades de seus provedores de serviço de nuvem. Discutiremos as principais funções do IAM essenciais para o gerenciamento efetivo e bem sucedido de identidades na nuvem:
Provisionamento / desaprovisionamento de identidade Autenticação Federação Autorização & gerenciamento de perfil de usuários
Conformidade é uma consideração chave em todos os pontos. Provisionamento de Identidade: Um dos maiores desafios para a adoção de serviços de Computação em Nuvem pelas empresas é o gerenciamento seguro e ágil da concessão (provisionamento) e revogação (desaprovisionamento) de usuários na nuvem. Além disso, as organizações que investem em processos de gerenciamento de usuários dentro da empresa buscarão estender esses processos e práticas aos serviços de nuvem. Autenticação: Quando as organizações começam a utilizar os serviços de nuvem, autenticar usuários de uma forma confiável e gerenciável é uma exigência vital. As organizações devem resolver os desafios relacionados à autenticação, como o gerenciamento de credenciais, autenticação forte (tipicamente definida como autenticação multifator), delegação de autenticação e gerenciamento de confiança para todos os tipos de serviços de nuvem. Federação: Em um ambiente de Computação em Nuvem, o Gerenciamento de Identidades Federadas tem um papel fundamental ao permitir que as organizações autentiquem seus usuários de serviços de nuvem usando o provedor de identidade por ela escolhido (PId). Nesse contexto, trocar atributos de identidade entre o provedor de serviços (PS) e o PId de uma forma segura é também uma exigência importante. As organizações que consideram o gerenciamento de identidades federadas na nuvem precisam entender os vários desafios e possíveis soluções com respeito ao gerenciamento do ciclo de vida da identidade, métodos de autenticação disponíveis para proteger a confidencialidade e a integridade; ao mesmo tempo em que suportam o nãorepúdio. Autorização & gerenciamento de perfil de usuários: As exigências para a política de controle de acesso e perfis dos usuários variam conforme o usuário está agindo em nome próprio (como um consumidor) ou como um membro de uma organização (como um funcionário, universidade, hospital ou outra empresa). As exigências de controle de acesso em ambientes de SPI incluem estabelecer o perfil de usuário confiável e a informação da política, usando-os para controlar o acesso ao serviço de nuvem, executando isto de uma forma auditável.
Copyright © 2009 Cloud Security Alliance
68
Provisionamento de Identidade – Recomendações
As capacidades oferecidas pelos provedores de nuvem atualmente não são adequadas às exigências das empresas. Os clientes devem evitar soluções proprietárias assim como criar conectores personalizados unicamente para os provedores de nuvem, já que isto aumenta a complexidade do gerenciamento.
Os clientes devem usar conectores padrão fornecidos pelos provedores de nuvem como uma medida prática, preferencialmente construídos no esquema SPML. Se seu provedor de nuvem não oferece SPML, você deverá solicitá-lo.
Os clientes de nuvem devem modificar ou estender seus repositórios autoritativos de identidade de tal forma que englobem as aplicações e processos na nuvem.
Autenticação – Recomendações Ambos, provedor de serviços de nuvem e empresas clientes, devem considerar os desafios associados ao gerenciamento de credenciais e autenticação forte e implementar soluções de baixo custo que reduzam apropriadamente o risco. Provedores de SaaS e PaaS fornecem tipicamente duas opções: serviços próprios de autenticação para suas aplicações ou plataformas, ou delegar a autenticação às empresas. Os clientes têm as seguintes opções: √ Autenticação para empresas. As empresas devem considerar autenticar os usuários através de seus Provedores de Identidade (PId) e estabelecer confiança com o fornecedor de SaaS através da federação. √ Autenticação para usuários individuais agindo por conta própria. As empresas devem considerar usar autenticação centrada em usuário como do Google, Yahoo, OpenID, Live ID, etc., para permitir o uso de um conjunto único de credenciais válido para múltiplos sites. √ Qualquer provedor de SaaS que requeira métodos proprietários para delegar a autenticação (ex. manipulação de confiança por meio de um cookie criptografado compartilhado ou outros meios) deve ser cuidadosamente avaliado com uma análise de segurança adequada, antes de continuar. A preferência geral deve ser para o uso de padrões abertos. Para IaaS, estratégias de autenticação podem usar as capacidades existentes da empresa. √ Para o pessoal de TI, estabelecer uma VPN dedicada será uma opção melhor, já que se pode aproveitar sistemas e processos existentes. √ Algumas possíveis soluções incluem a criação de um túnel da VPN dedicado para a rede corporativa ou da federação. Um túnel da VPN dedicado funciona melhor quando a aplicação usa
Copyright © 2009 Cloud Security Alliance
69
os sistemas existentes de gerenciamento de identidade (como uma solução de autenticação baseada em SSO ou LDAP que fornece uma fonte autorizada de dados de identidade). √ Em casos onde um túnel VPN dedicado não é factível, as aplicações devem ser desenhadas para aceitar os pedidos de autenticação em vários formatos (SAML, Federação-WS, etc), combinadas com criptografia padrão de rede como SSL. Esta abordagem permite às organizações implantar SSO federados não apenas dentro da empresa, mas também para aplicações na nuvem. √ OpenID é outra opção quando a aplicação é direcionada para além dos usuários corporativos. Contudo, pelo fato do controle das credenciais do OpenID estar fora da empresa, os privilégios de acesso fornecido a estes usuários deve ser limitado. √ Qualquer serviço local de autenticação implementado pelo provedor de serviços de nuvem deve estar em conformidade com o OATH. Com uma solução com suporte a OATH, as empresas podem evitar ficar presas a credenciais de autenticação fornecidas por um fabricante. √ Para permitir a autenticação forte (independente da tecnologia), as aplicações de nuvem devem suportar a característica de delegar a autenticação para a empresa que está consumindo os serviços, como através de SAML. √ Os provedores de nuvem devem considerar o suporte a várias opções de autenticação forte, tais como senhas de um único uso (OTP), biometria, certificados digitais e Kerberos. Isto oferecerá outra opção às empresas de usar sua infraestrutura existente. Recomendações de Federação Em um ambiente de Computação em Nuvem, a federação de identidade é chave para permitir a empresas aliadas se autenticar, prover Single-Sign-On (SSO)ou Reduced-Sign-On e trocar atributos de identidade entre o provedor de serviços (PS) e o provedor de Identidade (PId). As organizações, ao considerar o gerenciamento de identidades federadas na nuvem devem entender os vários desafios e possíveis soluções relacionadas ao gerenciamento do ciclo de vida da identidade, métodos de autenticação, formatos de token e não-repúdio. √ As empresas que buscam por um provedor de nuvem devem verificar se o provedor suporta ao menos um dos padrões proeminentes (SAML e Federação-WS). SAML está despontando como um padrão de federação amplamente suportado e é utilizado pelos principais provedores de SaaS e PaaS. Suporte a múltiplos padrões permite um alto grau de flexibilidade. √ Os provedores de nuvem devem ter flexibilidade para aceitar os formatos padrão de federação de diferentes provedores de identidade. Contudo, as maiorias dos provedores de serviços de nuvem, na época deste documento, só suportavam um único padrão, ex. SAML 1.1 ou SAML 2.0. Os provedores de serviços de nuvem que desejam suportar múltiplos formatos de token de federação devem considerar a implementação de algum tipo de gateway de federação. √ As organizações podem avaliar SSO Público Federado versus SSO Privado Federado. SSO Público Federado é baseado em padrões como SAML e Federação-WS com o provedor de serviços
Copyright © 2009 Cloud Security Alliance
70
de nuvem, enquanto Federado Privado utiliza a arquitetura existente sobre VPN. A longo prazo, o SSO Público Federado seria o ideal, enttretanto, em empresas com uma arquitetura madura de SSO e com um número limitado de implementações em nuvem, pode-se ganhar benefícios de custo de curto prazo com o SSO Privado Federado. √ As organizações podem optar por gateways de federação para externalizar sua implementação, de forma a gerenciar a emissão e verificação de tokens. Usando este método, as organizações delegam a emissão de vários tipos de token para o gateway da federação, que então manipula a tradução de tokens de um formato para outro. Recomendações de Controle de Acesso Ao selecionar ou revisar a adequação das soluções de controle de acesso para serviços de nuvem existem muitos aspectos que implicam considerar o seguinte: √ Revisar a adequação do modelo de controle de acesso para o tipo de serviço ou dados. √ Identificar as fontes autoritativas de política e informações de perfil do usuário. √ Avaliar o suporte às políticas de privacidade necessárias para os dados. √ Selecionar um formato no qual especificará a política e a informação do usuário. √ Determinar o mecanismo para transmitir a política de um Ponto de Administração da Política (PAP) para um Ponto de Decisão da Política (PDP). √ Determinar o mecanismo para transmitir a informação do usuário de um Ponto de Informação da Política (PIP) para um Ponto de Decisão da Política (PDP). √ Solicitar uma decisão de política de um Ponto de Decisão de Política (PDP). √ Aplicar a decisão de política no Ponto de Cumprimento de Política (PCP). √ Registrar a informação necessária para auditorias. Recomendação de IDaaS Identity as a Service (IDaaS) deve seguir as mesmas boas práticas que uma implementação interna que o IAM utiliza, além de considerações adicionais para privacidade, integridade e auditoria. √ Para os usuários corporativos internos, tutores devem revisar as opções dos provedores de serviço de nuvem para oferecer acesso seguro, seja através de uma VPN direta ou através de um padrão da indústria como o SAML e autenticação forte. A redução de custos advinda do uso da nuvem necessita ser balanceada contra as medidas de mitigação dos riscos para endereçar as
Copyright © 2009 Cloud Security Alliance
71
considerações de privacidade inerentes ao fato de se ter as informações dos colaboradores armazenadas externamente. √ Para os usuários externos como parceiros, os donos da informação necessitam incorporar as interações com os provedores de IAM dentro de seu SDLC, assim como em suas análises de ameaças. Segurança da aplicação – as interações entre os vários componentes e as vulnerabilidades criadas por essa situação (tal como SQL Injection e Cross Site Scripting, dentre muitas outras) – devem ser também consideradas e protegidas. √ Os clientes de PaaS devem pesquisar a dimensão em que os fornecedores de IDaaS suportam os padrões da indústria para provisionamento, autenticação, comunicação de políticas de controle de acesso e informação de auditoria. √ Soluções proprietárias apresentam um risco significativo para os componentes de um ambiente de IAM na nuvem, por causa da falta de transparência dos componentes proprietários. Protocolos de rede proprietários, algoritmos de encriptação e comunicação de dados são frequentemente menos seguros e menos interoperáveis. É importante usar normas abertas para os componentes do IAM que você utilizará externamente. √ Para os clientes de IaaS, imagens de terceiros usadas para iniciar os servidores virtuais precisam ser analisadas para verificar a autenticidade do usuário e da imagem. Uma revisão do suporte fornecido para o gerenciamento do ciclo de vida da imagem deve verificar os mesmos princípios do software instalado em sua rede interna. Colaboradores da Versão Original: Subra Kumaraswamy, Sitaraman Lakshminarayanan, Michael Reiter, JosephStein e Yvonne Wilson. Colaboradores da Versão Brasileira: Hernan Armbruster, Jordan M. Bonagura, Julio Graziano Pontes, Miguel Macedo
Copyright © 2009 Cloud Security Alliance
72
Domínio 13 - Virtualização A capacidade de prover serviços em nuvem multilocação no nível de infraestrutura, plataforma, ou aplicativo é frequentemente sustentada pela habilidade em prover alguma forma de virtualização para criar escala econômica. Contudo, o uso dessas tecnologias traz preocupações adicionais relacionadas à segurança. Este domínio relaciona-se a essas questões de segurança. Enquanto existem diversas formas de virtualização, de longe a mais comum está relacionada a sistemas operacionais virtualizados, e este é o foco nesta versão do nosso guia. Se a tecnologia de máquina virtual (VM) está sendo usada na infraestrutura de serviços de nuvem, então devemos nos preocupar com a compartimentalização e elevação do nível de segurança destes sistemas virtuais. A realidade das práticas atuais relacionadas ao gerenciamento de sistemas operacionais virtuais é que muitos dos processos que fornecem segurança por padrão estão ausentes e atenção especial deve ser dada para substituí-los. O núcleo da tecnologia de virtualização por si só introduz novas interfaces de ataque no hypervisor e outros componentes de gerenciamento, mas o mais importante são os vários impactos que tem a virtualização na segurança de rede. Máquinas virtuais agora se comunicam sobre um backplane de hardware, ao invés de rede. Como resultado, controles padrão de segurança de rede não enxergam esse tráfego e não podem realizar monitoramento ou bloqueio em linha. Esses controles precisam de uma nova forma para funcionar dentro do ambiente virtual. O agrupamento de dados em serviços centralizados e repositórios é outra preocupação. Uma base de dados centralizada e fornecida por um serviço de computação de nuvem deve teoricamente melhorar a segurança sobre os dados distribuídos sobre um vasto número e variedade de clientes finais. Contudo, isto também é uma centralização de risco, aumentando as consequências de uma falha na segurança. Outra preocupação é o agrupamento de máquinas virtuais que manipulam informações de diferentes níveis de sensibilidades e segurança. Em ambientes de Computação em Nuvem, o menor denominador comum de segurança será compartilhado por todos os clientes/usuários dentro do ambiente virtual a não ser que uma nova arquitetura de segurança possa ser alcançada de modo que não esteja amarrada a qualquer dependência de rede para proteção.
Recomendações
Identificar quais tipos de virtualização seu provedor de nuvem usa, se houver.
Sistemas operacionais virtualizados devem ser protegidos por tecnologia de terceiros para fornecer controles de segurança em camadas e reduzir a dependência unicamente sobre o provedor de plataforma.
Compreender quais controles de segurança estão implementados dentro das máquinas virtuais além do isolamento incorporado do hypervisor – tais como detecção de intrusões, antivírus, escaneamento de vulnerabilidades, etc. Configuração segura por padrão deve ser assegurada por seguir ou exceder os padrões definidos pelas melhores práticas da indústria.
Copyright © 2009 Cloud Security Alliance
73
Compreender quais controles de segurança estão implementados externamente às máquinas virtuais para proteger interfaces administrativas (baseadas na web, APIs, etc.) expostas para os clientes.
Validar a procedência e integridade de qualquer máquina virtual ou modelo originado do provedor de nuvem antes de utilizá-la.
Mecanismos de segurança específicos de máquinas virtuais embarcados dentro das APIs do hypervisor devem ser utilizados para prover monitoração granular do tráfego atravessando os backplanes das máquinas virtuais, os quais são opacos aos controles tradicionais de segurança de rede.
Acesso administrativo e controle de sistemas operacionais virtualizados são cruciais e devem incluir autenticação forte integrada ao gerenciamento de identidade corporativo, bem como mecanismo de registro à prova de falsificação e ferramentas de monitoramento de integridade.
Considerar a eficácia e viabilidade de segregar máquinas virtuais criando zonas de segurança por tipo de uso (estação x servidor), etapas de produção (desenvolvimento, produção, teste) e sensibilidade dos dados em componentes físicos de hardware separados como servidores, armazenamento, etc.
Ter um mecanismo de relatórios que forneça evidências de isolação e emita alertas caso ocorra uma violação.
Estar ciente em situações de multilocação envolvendo suas máquinas virtuais onde preocupações regulatórias podem requerer sua segregação.
Colaboradores da Versão Original: Bikram Barman, Girish Bhat, Sarabjeet Chugh, Philip Cox, Joe Cupano, Srijith K. Nair, Lee Newcombe, Brian O’Higgins. Colaboradores da Versão Brasileira: Alessandro Trombini, Jimmy Cury, Jordan M. Bonagura, Julio Graziano Pontes, Luís Felipe Féres Santos
Copyright © 2009 Cloud Security Alliance
74
Referencias A guide to security metrics. SANS Institute, June 2006. http://www.sans.org Amazon EC2 API - http://docs.amazonwebservices.com/AWSEC2/2006-10-01/DeveloperGuide/ Amazon Elastic Compute Cloud Developer Guide, http://docs.amazonwebservices.com/AWSEC2/2009-03-01/DeveloperGuide/ Amazon Simple Queue Service Developer Guide, http://docs.amazonwebservices.com/AWSSimpleQueueService/2008-0101/SQSDeveloperGuide/ Amazon Simple Storage Service Developer Guide, http://docs.amazonwebservices.com/AmazonS3/2006-03-01/ Amazon SimpleDB Developer Guide, http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/ Amazon web services blog: Introducing amazon virtual private cloud (vpc), Amazon, August 2009. http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-cloud-vpc.html Amazon Web Services: Overview of Security Processes, September 2008 An Innovative Policy-based Cross Certification methodology for Public Key Infrastructures. Casola V., Mazzeo A., Mazzocca N., Rak M. 2nd EuroPKI Workshop. Springer-Verlag LNCS 35. Editors: D. Chadwick, G. Zhao. 2005. Auditing the Cloud, Grid Gurus, http://gridgurus.typepad.com/grid_gurus/2008/10/auditing-thecl.html, October 20, 2008 Azure Services Platform, http://msdn.microsoft.com/en-us/library/dd163896.aspx Balanced Scorecard for Information Security Introduction”, Published: March 06, 2007, http://technet.microsoft.com/en-us/library/bb821240.aspx BITS Kalculator and BITS Financial Services Shared Assessments Program (third party provider assessment methodology) Building Security In Maturity Model, http://www.bsi-mm.com/ Business case for a comprehensive approach to identity and access management, May 2009 https://wiki.caudit.edu.au/confluence/display/CTSCIdMWG/Business+case Business Roundtable, Principles of Corporate Governance, 2005 Business Roundtable, Statement on Corporate Governance, 1997. Business Software Alliance, Information Security Governance: Towards a Framework for Action Centers for Medicare and Medicaid Services Information Security Risk Assessment Methodology
Copyright © 2009 Cloud Security Alliance
75
Cloud Computing and Compliance: Be Careful Up There, Wood, Lamont, ITWorld, January 30, 2009 Cloud computing definition, by P. Mell and T. Grance, NIST June 2009. http://csrc.nist.gov/groups/SNS/cloud-computing/index.html Cloud Computing is on the Up, but what are the Security Issues?, Mather, Tim, Secure Computing Magazine (UK), March 2, 2009. Cloud Computing Use Case Group Whitepaper -http://www.scribd.com/doc/17929394/CloudComputing-Use-Cases-Whitepaper Cloud computing use cases whitepaper, August 2009. http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper Cloud computing use cases whitepaper, August 2009. http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper Cloud computing vocabulary (cloud computing wiki) http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary Cloud Computing: Bill of Rights, http://wiki.cloudcomputing.org/wiki/CloudComputing:Bill_of_Rights Cloud Cube Model: Selecting Cloud Formations for Secure Collaboration, Jericho Forum, V 1.0, April 2009 Cloud Security and Privacy – An Enterprise perspective on Risks and Compliance from O’Reilly - http://oreilly.com/catalog/9780596802776/ Cloud Standards Organization - http://cloud-standards.org/ Cloud Storage Strategy, Steve Lesem, July 19, 2009, http://www.cloudstoragestrategy.com/2009/07/cloud-storage-and-the-innovators-dilemma.html Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration Vulnerabilities (DRAFT), 2009. http://csrc.nist.gov/publications/drafts/nistir-7502/DraftNISTIR-7502.pdf Contracting for Certified Information Security: Model Contract Terms and Analysis (published by the Internet Security Alliance and available at www.cqdiscovery.com) Contracting for Information Security: Model Contract Terms (published by the Internet Security Alliance and available at www.cqdiscovery.com) CPMC ClearPoint Metric Catalog, 2009 Online Available: http://www.clearpointmetrics.com/newdev_v3/catalog/MetricApplicationPackage.aspx CVSS A Complete Guide to the Common Vulnerability Scoring System, Version 2.0, 2007 Online Available: http://www.first.org/cvss/cvss-guide.html
Copyright © 2009 Cloud Security Alliance
76
Data Lifecycle Management Model Shows Risks and Integrated Data Flow, by Ernie Hayden, Information Security Magazine, July 2009 http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1321704_mem1,00.htm l Data Privacy Clarification Could Lead to Greater Confidence in Cloud Computing, Raywood, Dan, Secure Computing Magazine (UK), March 9, 2009. Defending Electronic Mail as Evidence—The Critical E-Discovery Questions, Jeffrey Ritter, (available at www.cqdiscovery.com) Does Every Cloud Have a Silver Compliance Lining?, Tom McHale, July 21, 2009 Online Available: http://blog.ca-grc.com/2009/07/does-every-cloud-have-a-silver-Compliance-lining/ Encryption of Data At-Rest: Step-by-step Checklist”, a whitepaper prepared by the Security Technical Working Group of the Storage Network Industry Association (SNIA). ENISA - http://www.enisa.europa.eu/ Fedora Infrastructure Metrics, 2008. http://fedoraproject.org/wiki/Infrastructure/Metrics Few Good Information Security Metrics, By Scott Berinato, July 2005 Online Available: http://www.csoonline.com/article/220462/A_Few_Good_Information_Security_Metrics Force.com Web Services API Developer’s Guide, http://www.salesforce.com/us/developer/docs/api/index.htm Global Privacy & Security, Francoise Gilbert, (Aspen Publishing 2009). GoGrid API - http://wiki.gogrid.com/wiki/index.php/API GSA to launch online storefront for cloud computing services, August 2009. http://www.nextgov.com/nextgov/ng_20090715_3532.php Guidelines for Media Sanitization,” NIST’s Special Publication 800-88 Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, T. Ristenpart, et al, http://blog.odysen.com/2009/06/security-and-identity-as-service-idaas.html http://blogs.forrester.com/srm/2007/08/two-faces-of-id.html http://blogs.intel.com/research/2008/10/httpseverywhere_encrypting_the.php http://code.google.com/apis/accounts/docs/AuthForWebApps.html http://code.google.com/apis/accounts/docs/OpenID.html http://csrc.nist.gov/groups/SNS/cloud-computing/index.html
Copyright © 2009 Cloud Security Alliance
77
http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf http://csrc.nist.gov/publications/PubsSPs.html http://en.wikipedia.org/wiki/Statement_on_Auditing_Standards_No._70:_Service_Organizations http://www.aspeninstitute.org/publications/identity-age-cloud-computing-next-generationinternets-impact-business-governance-socia http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml http://www.sas70.com https://siswg.net/index.php?option=com_docman&task=cat_view&gid=21&Itemid=99999999 Information Security Governance: A Call to Action, National Cyber Security Summit Task Force, Corporate Governance Task Force Report, April 2004. Information Security Law: Emerging Standard for Corporate Compliance, Thomas Smedinghoff, (ITGP 2008). ISACA, IT Governance Institute, Control Objectives for Information and related Technology (CobiT), 4.1 ISO/IEC 19011:2002 Guidelines for quality and/or environmental management systems auditing ISO/IEC 20000-1:2005 Information technology—service management—Part 1: Specification ISO/IEC 20000-1:2005 Information technology—service management—Part 2: Code of practice ISO/IEC 21827:2008 Information technology—Systems Security Engineering—Capability Maturity Model (SSE-CMM®) ISO/IEC 27000:2009 Information technology—Security techniques—Information security management systems—Overview and vocabulary ISO/IEC 27001:2005 Information technology—Security techniques—Information security management systems—Requirements. ISO/IEC 27002:2005 Information technology—Security techniques—Code of practice for information security management ISO/IEC 27005:2008 Information technology—Information security techniques—Information security risk management ISO/IEC 27006:2007 Information technology—Security techniques—Requirements for bodies providing audit and certification of information security management systems
Copyright © 2009 Cloud Security Alliance
78
ISO/IEC 28000:2007 Specification for security management systems for the Supply Chain ISO/IEC 38500:2008 Corporate governance of information technology IT Governance Institute, Board Briefing on Governance, 2nd Edition, 2003 IT Governance Institute, Information Security Governance: Guidance for Boards of Directors and Executive Management, 2nd Edition, 2006 ITGI Enterprise Risk: Identify Govern and Manage IT Risk—The Risk IT Framework, Exposure Draft version 0.1 February 2009. Jericho Forum - http://www.opengroup.org/jericho/ and the Jericho Cloud Cube model http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf Justify Identity Management Investment with Metrics, by Roberta J. Witty, Kris Brittain and Ant Allan, 23 Feb 2004. Gartner Research ID number TG-22-1617. Managing Assurance, Security and Trust for Services. Online. Available: http://www.masterfp7.eu/ National Association for Information Destruction Inc http://www.naidonline.org/forms/cert/cert_program_us.pdf NIST Guidelines for Media Sanitization (800-88) - http://csrc.nist.gov/publications/nistpubs/80088/NISTSP800-88_rev1.pdf NIST Recommended Security Controls for Federal Information Systems (SP800-53) NIST SP 800-30 Risk Management Guide for Information Technology Systems OATH- http://www.openauthentication.org OCEG, Foundation Guidelines Red Book, v1 10/27/2008 OCTAVE-S Implementation Guide, Christopher Alberts, Audrey Dorofee, James Stevens, Carol Woody, Version 1, 2005 OECD Guidelines for the Security of Information Systems and Networks: Towards a Culture of Security Open Cloud Computing Interface Working Group - http://www.occi-wg.org/doku.php Open Security Architecture Group - http://www.opensecurityarchitecture.org OpenCrowd - http://www.opencrowd.com/views/cloud.php OpenID – http://openid.net
Copyright © 2009 Cloud Security Alliance
79
OpenID attribute exchange http://openid.net/specs/openid-attribute-exchange-1_0.htmlOAuth (created by a small group of individuals) http://OAuth.net/ OpenSocial – sharing SOCial networking information http://www.opensocial.org/ ORCM Overcoming Risk And Compliance Myopia, August 2006 Online Available: http://logic.stanford.edu/POEM/externalpapers/grcdoc.pdf OSAG Security Landscape - http://www.opensecurityarchitecture.org/cms/foundations/osalandscape OWASP Top Ten Project, http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Princeton Startup Lawyer, “Company Formation-Fiduciary Duties (the basics)”, June 17, 2009, http://princetonstartuplawyer.wordpress.com/2009/06/17/company-formation-fiduciary-dutiesthe-basics/ Python Runtime Environment, http://code.google.com/appengine/docs/ Rackspace API - http://www.rackspacecloud.com/cloud_hosting_products/servers/api Sailing in Dangerous Waters: A Director’s Guide to Data Governance, E. Michael Power & Roland L. Trope, (American Bar Association, 2005). SAML- http://www.oasis-open.org/specs/index.php#saml Security Guidance for Critical Areas of Focus in Cloud Computing, Version 1, by Cloud Security Alliance, April 2009 Service Level Agreements: Managing Cost and Quality in Service Relationships, Hiles, A. (1993), London:Chapman & Hall SNIA Encryption of Data At Rest: A Step-by-Step Checklist http://www.snia.org/forums/ssif/knowledge_center/white_papers/forums/ssif/knowledge_center/ white_papers/Encryption-Steps-Checklist_v3.060830.pdf SNIA Introduction to Storage Security http://www.snia.org/forums/ssif/knowledge_center/white_papers/Storage-SecurityIntro1.051014.pdf SNIA Storage Security Best Current Practices http://www.snia.org/forums/ssif/forums/ssif/programs/best_practices/ Storage Security Best Current Practices (BCPs)” by the Security Technical Working Group of SNIA Sun Project Kenai API - http://kenai.com/projects/suncloudapis The Committee of Sponsoring Organizations of the Treadway Commission (COSO), Enterprise Risk Management—Integrated Framework (2004). The Darker Side of Cloud Computing, by Matthew D. Sarrel, PC Mag.com, February 1, 2009
Copyright © 2009 Cloud Security Alliance
80
The Force.com Workbook, http://wiki.developerforce.com/index.php/Forcedotcomworkbook The Institute of Internal Auditors, Critical Infrastructure Assurance Project, “Information Security Governance: What Directors Need to Know”, 2001 The International Grid Trust Federation (IGTF). http://www.igtf.net United States General Accounting Office, Information Security Risk Assessment Practices of Leading Organizations, 1999. United States Sentencing Commission, Guidelines Manual vCloud API - http://www.vmware.com/solutions/cloud-computing/vcloud-api.html Where We’re Headed: New Developments and Trends in the Law of Information Security, Thomas J. Smedinghoff, Privacy and Data Security Law Journal, January 2007, pps. 103-138 Windows Azure SDK, http://msdn.microsoft.com/en-us/library/dd179367.aspx Windows Cardspace - http://msdn.microsoft.com/en-us/library/aa480189.aspx WS-Federation : http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-specos.html
Copyright © 2009 Cloud Security Alliance
81
