Universidade Católica Portuguesa Faculdade de Engenharia. Segurança em Sistemas de Informação. Migração e segurança em plataformas cloud computing - PDF
Universidade Católica Portuguesa Faculdade de Engenharia. Segurança em Sistemas de Informação. Migração e segurança em plataformas cloud computing
Download "Universidade Católica Portuguesa Faculdade de Engenharia. Segurança em Sistemas de Informação. Migração e segurança em plataformas cloud computing"
Ana Clara Azenha Castel-Branco
1 Universidade Católica Portuguesa Faculdade de Engenharia Segurança em Sistemas de Informação Migração e segurança em plataformas cloud computing Roberto Carlos Gomes da Silva Dissertação para obtenção do Grau de Mestre em Segurança em Sistemas de Informação Júri Prof. Doutor Manuel José Martinho Barata Marques Prof. Doutor Rui Jorge Correia Mendes Alves Pires Prof. Doutor Tito Lívio dos Santos Silva Junho de 2014
3 Computation may someday be organized as a public utility. John McCarthy, 1960 ii
4 Agradecimentos A todos os que acreditaram que seria possível cumprir este objectivo e me ajudaram nesse sentido, muito especialmente à minha mulher, pela paciência e suporte demonstrados. Uma especial nota de agradecimento ao meu orientador Prof. Doutor Tito Lívio dos Santos Silva. iii
5 Resumo O paradigma cloud computing é cada vez mais uma tecnologia presente nas infraestruturas das organizações e vista por muitos como um marco no que respeita às tecnologias de informação. De facto, cloud computing representa mais uma mudança de paradigma na forma como os sistemas são implementados. Mas, de uma forma geral, cloud computing é também sinónimo de insegurança, que aos poucos se vai alterando. Ao migrar para um ambiente cloud, uma organização relega para o fornecedor do serviço o controlo sobre os seus dados e sistemas, fomentando um sentimento de insegurança pela perda de controlo inerente. As organizações têm que ter um nível muito elevado de confiança nos fornecedores cloud, antes de decidir confiar-lhes a sua informação confidencial ou regulada por normas ou leis. Neste trabalho propomos uma análise à segurança em ambientes cloud, riscos, vantagens e desvantagens, terminando com uma proposta de ferramenta de trabalho em migração para infraestruturas cloud computing, mantendo a segurança, privacidade e disponibilidade de sistemas, dados e informação. Palavras-chave: cloud computing, SaaS, PaaS, IaaS, segurança, riscos, confidencialidade, privacidade, disponibilidade iv
6 Abstract The cloud computing paradigm is becoming an existing technology at the organizations infrastructures and seen by many as a milestone in relation to Information Technology. In fact, cloud computing represents a paradigm shift in the way systems are implemented. But, in general, cloud computing is also synonymous with insecurity, which is gradually changing. When one organization migrate their data and systems to a cloud environment, it relegates to the service provider control over it, fostering a sense of insecurity for the loss of control inherent. Organizations have to have a very high level of trust in cloud providers before deciding to entrust them their confidential information or regulated by rules or laws. In this work we present a review of security in cloud environments, risks, advantages and disadvantages, ending with a proposal of a tool for migrating to an infrastructure of cloud computing, maintaining security, privacy and availability of systems, data and information. Keywords: cloud computing, SaaS, PaaS, IaaS, risks, security, confidentiality, privacy, availability v
7 Índice Resumo... iv Abstract... v Índice... vi Lista de Figuras... x Lista de Tabelas... xi Lista de Abreviaturas... xii 1. Introdução Objectivos Estrutura do Documento Cloud Computing Visão Histórica Conceitos Similares Características Principais da Cloud Outras Características da Cloud Modelos de Serviço Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) Modelos de Desenvolvimento Cloud Pública Cloud Privada Cloud Comunitária Cloud Híbrida Modelos de Desenvolvimento Alternativos O Modelo de Linthicum vi
8 Modelo de Desenvolvimento Jericho Cloud Cube Infraestrutura de Referência de Cloud Computing Actores do Modelo Cloud Computing Orquestração de Serviços Camada de Serviço Camada de Controlo e Abstracção de Recursos Camada de Recursos Físicos Serviços de Gestão na Cloud Suporte ao Negócio Aprovisionamento e Configuração Portabilidade e Interoperabilidade Diferença entre Arquitectura Cloud e Arquitectura Tradicional Análise à Arquitectura Cloud Computing Vantagens Cloud Computing Redução de Custos Escalabilidade Actualizações Automáticas Facilidade de Acesso Fiabilidade Rápido Desenvolvimento e Implementação Acesso a Melhores Recursos Tecnológicos Desvantagens da Cloud Computing Riscos de Segurança Responsabilidade em cada Modelo de Serviço Risco Avaliação do Risco Segurança em Ambientes Cloud vii
9 Processos de Governança, Gestão de Risco e Compliance Compliance Governança Gestão do Risco Auditar os Processos de Negócio e Operacionais Compreender o Ambiente Interno de um Fornecedor Cloud Acesso ao Processo de Auditoria Acesso a Ferramentas de Gestão e Controlo Gestão de Pessoas, Processos e Identidades Protecção de Dados e Informação Controlos de Segurança de Dados em Ambientes Cloud Aplicar Confidencialidade, Integridade e Disponibilidade Considerar Todas a Formas de Dados Catálogo de Activos Requisitos de Privacidade Controlo de Identidades e Gestão de Acessos Políticas de Privacidade Segurança nas Aplicações Cloud Segurança da Infraestrutura e Ligações de Rede Controlos Externos Controlos Internos Controlos de Segurança da Infraestrutura Gestão de Controlos de Segurança nos Contratos Revogar os Serviços com um Fornecedor Migração para Cloud Computing viii
10 4.1. Fase de Definição Identificação de Pessoas e Equipas Plano Estratégico de Migração Conhecimento e Formação Necessários Fase de Análise Aplicações e Sistemas Modelo de Desenvolvimento Modelos de Serviço Considerações de Migração para SaaS Considerações de Migração para PaaS Considerações de Migração para IaaS Avaliação e Selecção do Fornecedor Fase de Segurança Testes de Migração e Operação Implementar e Gerir SLA s Definir Políticas e Controlos de Segurança Política de segurança Controlos de segurança Fase de Operação Conclusão Trabalho futuro Bibliografia Anexo A Anexo B ix
11 Lista de Figuras Figura 1: Maturidade do conceito cloud computing (Portugal, 2012)... 2 Figura 2: Obstáculos à adopção de cloud computing (Portugal, 2012)... 3 Figura 3: Modelo Visual da definição da NIST... 7 Figura 4: Evolução tecnológica (Mather, et al., 2009)... 8 Figura 5: Modelos de Serviço Figura 6: Componentes e categorias de cloud computing (Linthicum, 2009) Figura 7: Representação Gráfica do Cubo da Cloud Fonte: Jericho Forum Figura 8: O modelo de referência conceptual (Liu, et al., 2011) Figura 9: Arquitecturas de virtualização Figura 10: Infraestrutura tradicional versus Cloud Computing Figura 11: Principais preocupações na cloud (Gens, 2009) Figura 12: Controle sobre a segurança em SaaS, PaaS e IaaS (Winkler, 2011) Figura 13: Componentes do Risco Figura 14: Framework de gestão do risco. Adaptado (Davis, et al., 2011) Figura 15: Ciclo de dados Figura 16: Redundância e disponibilidade (Winkler, 2011) Figura 17: Secure Software Development Life Cycle. Adaptado (ard3n7, 2013) Figura 18: Isolamento de tráfego de controlo e público (Winkler, 2011) Figura 19: Ciclo PDCA de Deming Figura 20: Ciclo de Migração para Cloud Computing Figura 21: Plano Estratégico Figura 22: Ciclo de um SLA x
12 Lista de Tabelas Tabela 1: Responsabilidades no Modelo SaaS Tabela 2: Responsabilidades no Modelo PaaS Tabela 3: Responsabilidades no Modelo IaaS Tabela 4: Análise de Risco. Adaptado de ISO/IEC 27005: Tabela 5: ISO/IEC 27001: Information technology Tabela 6: Responsabilidade sobre as aplicações nos modelos s cloud Tabela 7: Procedimentos de segurança em routers (Microsoft, 2003) Tabela 8: Procedimentos de segurança em switchs (Microsoft, 2003) Tabela 9: Procedimentos de segurança em outros equipamentos (Microsoft, 2003) Tabela 10: Identificação de Pessoas e Equipas por Área de actuação Tabela 11: Analise aos modelos cloud pública e cloud privada xi
13 Lista de Abreviaturas ACL Access Control List AES - Advanced Encription Standard API - Application Program Interface DOS - Denial-Of-Service DR - Disaster Recover IDE - Integrated Development Environment IDS - Intrusion Detection Systems IP - Internet Protocol IPD - Intrusion Prevention Detection LAN Large Area Network MAC - Media Access Protocol PII - Personal Identifiable Information QoS Quality of Service RIP - Routing Information Protocol SDLC - Software development lifecycle SLA - Service Level Agreements SOA - Service Oriented Architectures SPI - Software Platform Infrastructure SSL - Secure Sockets Layer TI - Tecnologias de Informação VM - Virtual Machine xii
15 1. Introdução À medida que as empresas procuram novas formas para melhoria da eficiência e redução de custos a cloud computing emerge como uma nova plataforma que oferece ganhos financeiros nas suas necessidades de tecnologias de informação. Embora a ideia de cloud computing seja uma tendência relativamente recente, as suas raízes remontam aos anos 60. Em 1961, John MaCarthy, Professor no MIT apresentou o conceito de computação fornecido como um bem de consumo, semelhante à electricidade. Mais tarde, em 1969, J. Licklider, pioneiro no projecto que desenvolveu as bases da ARPANET, precursor da Internet, apresentou a ideia de uma rede de escala: If such a network as I envisage nebulously could be brought into operation, we could have at least four large computers, perhaps six or eight small computers, and a great assortment of disc files and magnetic tape units not to mention remote consoles and teletype stations all churning away.. Estes dois conceitos, em conjunto com a ubiquidade da internet, estão na base do que mais tarde viria a evoluir para uma infraestrutura de cloud computing (Krutz & Vines, 2010). De facto, o conceito de cloud computing não é mais que a evolução de conceitos de computação suportados por novas tecnologias e algumas já existentes, representando mais uma mudança de paradigma na forma como os serviços computacionais são desenvolvidos e acedidos pelos utilizadores (Sosinsky, 2011). Entre essas tecnologias podemos destacar, por exemplo, a capacidade de processamento, virtualização de recursos, a capacidade de armazenamento, largura de banda disponível, descida nos preços de hardware, etc. Tudo combinado torna a cloud computing uma infraestrutura apelativa e competitiva. A inforworld num artigo de Junho de 2011 sobre os 10 piores apagões cloud (Raphael, 2011) vem salientar que os problemas de segurança existem, acontecendo mesmo onde menos se espera que ocorram, no fornecedor de serviços cloud. Mesmo fornecedores com elevada reputação como a Amazon, Google, Microsoft e Salesforce, para nomear apenas alguns dos citados no artigo, experimentaram distúrbios graves e prolongados no fornecimento dos seus serviços. Este facto vem salientar que os problemas de segurança em cloud são abrangentes e há que considerar todos os riscos e analisar as ameaças de todos os ângulos, num projecto de migração para a cloud. Apesar da percepção de risco que o modelo cloud levanta, as organizações, seja em território nacional seja a nível internacional, ponderam cada vez mais a migração de alguns dos seus 1
16 serviços para a cloud computing. A IDC 1, empresa líder mundial na área de market intelligence, realizou um estudo em 2012 sobre as tendências de adopção destas tecnologias no território nacional. Nesse estudo analisou o grau de utilização deste tipo de serviços, assim como as perspectivas de utilização a curto prazo. Nele se conclui que com as alterações substanciais da conjuntura económica nacional nos últimos anos, a redução de custos de funcionamento e a melhoria da eficiência aparecem como as prioridades de negócio para a maioria das organizações inquiridas. Assim, Apesar das condições adversas da economia, as prioridades tecnológicas das organizações nacionais contemplam a consolidação da infraestrutura, a virtualização e a adopção de serviços de cloud computing. De facto, mais de um terço das organizações nacionais inquiridas consideram os serviços de cloud computing e apenas 20% ainda não tinham considerado uma aproximação ao modelo cloud computing. Figura 1: Maturidade do conceito cloud computing (Portugal, 2012) À semelhança de outros inquéritos levados a cabo a nível internacional, quando considerado a adopção dos serviços em cloud computing, as preocupações com a segurança, a privacidade e a confidencialidade surgem logo em primeiro plano. Num segundo plano, surgem em evidência as 1 2
17 preocupações com contratos com os fornecedores, garantias e níveis de serviço dados pelos fornecedores e a dependência futura destes. Figura 2: Obstáculos à adopção de cloud computing (Portugal, 2012) Factores como garantias de desempenho do serviço, suportados através da existência de Service Level Agreements (SLA), do preço competitivo das soluções e a existência de serviços profissionais são os critérios apontados pelas organizações nacionais como determinantes para a escolha do fornecedor de serviços de cloud computing Objectivos Com este novo paradigma surgiram novas ameaças e receios que tornam a adopção de uma infraestrutura em cloud computing num projecto a ser pensado e analisado extensiva e cuidadosamente. Uma organização deve compreender os riscos e as vantagens, para uma decisão informada e consciente, mitigando os riscos e alavancando as vantagens do projecto. Assim, o objectivo principal desta dissertação é o de reunir informação sobre o conceito cloud computing, que permita uma decisão informada acerca da migração de sistemas para a cloud, com o foco na segurança e que permita a sua aplicação em casos de negócio Estrutura do Documento Esta dissertação é composta, para além deste, por mais 4 capítulos e 2 Anexos 3
18 Capítulo 2: É efectuada uma abordagem ao modelo cloud computing, com descrição das principais características, modelos de serviço e de desenvolvimento, actores principais e infraestrutura de referência, terminado com uma análise à diferença entre arquitecturas, cloud e tradicional. Capítulo 3: É analisada a arquitectura cloud de uma forma abrangente e pela óptica da segurança, são apontadas as suas vantagens, desvantagens e riscos antes de uma análise mais aprofundada sobre a segurança em ambientes cloud, com especial ênfase na cloud pública, que é a que mais preocupações de segurança levanta. Capítulo 4: De vertente prática, apresenta-se uma ferramenta de trabalho (framework), que descreve um ciclo de migração para cloud computing, que se divide em 4 fases: Fase de definição, em que se identifica pessoas e equipas que irão ter um papel relevante no processo de migração, definição de um plano estratégico de migração e levantamento de necessidades de formação. Fase de análise, que compreende um levantamento de aplicações e sistemas a migrar, selecção do modelo de desenvolvimento e do modelo de serviço que melhor se adaptam à empresa e finalmente, a selecção do fornecedor cloud. Fase de segurança, com a informação suficiente já reunida nas duas fases anteriores, em que se propõem testes de migração, de implementação e gestão de Service Level Agreements (SLA) e definição dos controlos de segurança, necessários a um ambiente de segurança. Fase de operação, que completa o ciclo com o acompanhamento da operação numa óptica de melhoria continua. Capítulo 5: Apresenta as conclusões do trabalho realizado e sugestões de trabalhos futuros. Anexo A: Para uma comparação efectiva de fornecedores, é proposto o preenchimento das tabelas do Anexo. Anexo B: Proposta de documento para caso de estudo de um projecto de migração para cloud computing. 4
19 2. Cloud Computing De um ponto de vista bastante simplificado, cloud computing fornece serviços de Tecnologias de Informação (TI) através da Internet de tal forma que o utilizador final não precisa de se preocupar com a localização da infraestrutura, formas de armazenamento dos dados, tecnologia de suporte, etc. O utilizador recebe o serviço sem se preocupar com qualquer um dos detalhes tecnológicos. O serviço é fornecido de uma forma em tudo similar aos serviços tradicionais de água, gás, electricidade e telefone (Buyya, et al., 2009) pagando apenas pelo consumo e permitindo às empresas reduzir os custos, não pagando por equipamento não utilizado ou subutilizado (ISACA, 2011). Para o utilizador não há custos com a aquisição de hardware, licenças de software, gestão de actualizações, pessoal técnico ou de espaço para um centro de dados, havendo apenas custos medidos segundo a utilização. Sendo um cliente cloud, este está a partilhar com outros utilizadores a infraestrutura de suporte que fornece o serviço, não estando esta dedicada a nenhuma empresa ou utilizador em particular. Existem muitas definições publicadas numa procura de melhor definir cloud computing. Roger Smith, na sua publicação de 2009 (Smith, 2009), oferece-nos um resumo de propostas para a sua definição, recorrendo a algumas instituições de renome das quais destacamos as seguintes: Berkeley University of California - "Ilusão de recursos infinitos de computação disponíveis a pedido, eliminando compromissos mais efectivos por parte dos utilizadores da cloud, possibilitando o pagamento pelo uso desses recursos de acordo com as necessidades de curto prazo." Gartner Group - Estilo de computação no qual recursos de TI, massivamente escaláveis são disponibilizados sob a forma de serviços, por meio da Internet, para múltiplos clientes cloud externos." Forrester Research - "Um conjunto de infraestruturas geridas, abstractas e altamente escaláveis, capazes de hospedar aplicações de clientes cloud finais, os quais pagam pelo consumo." International Business Machines (IBM) - "Plataforma que dinamicamente fornece, configura, reconfigura e liberta servidores de acordo com as necessidades, recorrendo a grandes centro de dados e potentes servidores, nos quais disponibiliza aplicações e serviços para serem utilizados via Internet." (Vaquero, et al., 2009) No seu estudo A Break in the Clouds: Towards a Cloud Definition onde analisa mais de vinte definições propõe como definição completa de cloud computing: Clouds 5
20 são uma larga gama de recursos virtualizados de fácil acesso e utilização (como hardware, plataformas de desenvolvimento e/ou serviços). Estes recursos podem ser reconfigurados dinamicamente para se ajustarem à carga de utilização (escala), permitindo também uma óptima utilização de recursos. Esta gama de recursos são tipicamente utilizados num modelo de pagamento por utilização, com garantias dadas pelo fornecedor da infraestrutura através de SLA s costumizados 2 Peter Mell e Timothy Grace, do National Institute of Standards and Technology (NIST) no documento intitulado The NIST Definition of Cloud Computing, definem Cloud Computing como (Mell, Peter; Grance, Timothy; NIST, 2011): um modelo que viabiliza o acesso oportuno e a pedido a um pacote partilhável de recursos computacionais configuráveis (por exemplo, redes, servidores, áreas para armazenagem, aplicativos e serviços) que podem ser rapidamente aprovisionados e libertados com um mínimo esforço de gestão ou de interacção com o prestador de serviços Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically re-configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs 3 Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. 6
21 Figura 3: Modelo Visual da definição da NIST Esta definição de Peter Mell e Timothy Grace, a mais aceite e a mais mencionada em todos os trabalhos e livros sobre o tema, aponta para a existência de três dimensões que caracterizam a cloud computing como um modelo e não uma tecnologia, baseado numa gama de serviços de rede, serviços de computação, capacidade de armazenamento e recursos aplicacionais (Williams, 2012). Essas dimensões são: Cinco características essenciais; Três modelos de serviço; Quatro modelos de desenvolvimento Visão Histórica Analisando o passado, cloud computing pode ser considerado uma evolução de tecnologias existentes. Os seus fundamentos têm origens na década de 50, quando organizações e institutos de educação deram prioridade à eficácia e optimização dos seus grandes computadores centrais, permitindo o acesso a múltiplos utilizadores através de terminais, partilhando as suas capacidades de processamento. Desde daí, podemos identificar seis fases de desenvolvimento, cada uma muito relevante no seu tempo (Berger, 2009): 7
22 Fase 1 Nas décadas de 50, 60 e 70, os utilizadores ligavam-se a computadores centrais através de terminais. Estes computadores com grandes capacidades eram responsáveis por todo o processamento, exibindo os resultados aos utilizadores nesses terminais, que não dispunham de capacidades de processamento; Fase 2 Já na década de 80, assistiu-se à democratização dos computadores pessoais. Estes ganharam capacidades de processamento e preços acessíveis, permitindo a sua expansão para o uso corrente dos utilizadores; Fase 3 Ligação destes computadores pessoais e servidores a redes de comunicação locais, Local Area Networks (LAN); Fase 4 Ligação destas redes locais entre si deu origem a uma rede global, a Internet, que permitiu a partilha de recursos entre computadores a nível global; Fase 5 Computação em grelha, partilha da capacidade de computação e armazenamento por sistemas distribuídos; Fase 6 Evolução da computação em grelha, melhora da partilha de recursos para uma forma mais simples e escalável, criando as condições necessárias para o início da cloud computing. Figura 4: Evolução tecnológica (Mather, et al., 2009) Daqui podemos concluir que desde a década de 60 se foi assistindo a um desenvolvimento tecnológico que viria a permitir a infraestrutura em cloud que temos actualmente. Com a Web 2.0 8
23 como a mais recente evolução. Alguns marcos históricos na evolução da cloud computing (Mohamed, 2009): 1999 Salesforce.com foi pioneira na entrega de aplicações empresariais via web, funcionado como ponto de partida, para empresas de software fornecerem aplicações através da internet; 2002 Amazon Web Services disponibilizam uma série de serviços cloud, que incluíam serviços de armazenamento, processamento e inteligência humana; 2006 A Amazon lança a sua aplicação comercial, Elastic Compute Cloud (EC2), para o aluguer de computadores virtuais, que permitem aos clientes executar as suas aplicações; 2009 Surge a Web 2.0, fomentando o aparecimento de outros intervenientes, como a Google com as suas aplicações empresariais via web, como as Google Apps Conceitos Similares Existem alguns conceitos simulares e tecnologias que desempenharam um papel fundamental no aparecimento da cloud computing. Alguns conceitos estão mesmo na sua génese, como ficou demonstrado no parágrafo anterior: Utility computing Recursos computacionais de processamento, de armazenamento e aplicações, disponibilizados aos clientes de uma forma similar a um serviço ou bem de consumo; Computação em grelha Com origem nos anos 90, refere-se a computadores ligados em rede, partilhando capacidade de processamento, habitualmente para a resolução de problemas complexos; Autonomic computing Funcionamento de um computador sem intervenção externa. Tem os seus fundamentos no funcionamento do sistema nervoso humano, que controla funções vitais em modo autónomo; Virtualização Partição lógica de recursos computacionais físicos. Esta tecnologia é fundamental à cloud computing, pelo que será abordada mais em detalhe no parágrafo , Camada de Controlo e Abstracção de Recursos; 9
24 2.2. Características Principais da Cloud De acordo com o NIST, as cinco características principais do modelo cloud computing são (Mell, Peter; Grance, Timothy; NIST, 2011): Self-service a pedido - Os clientes cloud podem, unilateralmente, provisionar capacidade computacional, à medida das necessidades e automaticamente, sem que seja necessária interacção humana com os fornecedores dos serviços; Ubiquidade As capacidades estão disponíveis na rede e são acedidas por meio de mecanismos padronizados que possibilitam o uso através de distintas plataformas de hardware; Pool de recursos Serviços acessíveis simultaneamente a múltiplos clientes cloud, com distintos recursos físicos e virtuais alocados e realocados dinamicamente de acordo com o solicitado, existindo um certo grau de independência e abstracção quanto à localização, na medida em que os clientes cloud não controlam ou têm conhecimento acerca dos locais exactos a partir dos quais acedem a esses recursos, mas ainda assim, podem especificar essa localização em alto nível (por exemplo, país, região ou até mesmo centro de dados); Rápida elasticidade Recursos adicionais devem ser, rápida e eficazmente aprovisionadas e libertados, em alguns casos até de forma automática, permitindo aumentar e reduzir dinamicamente as quantidades de serviços contratados. Para um cliente cloud, as capacidades disponíveis para aprovisionamento apresentam-se como praticamente ilimitadas e podem ser requisitadas em qualquer quantidade e a qualquer momento; Serviços mensuráveis - Sistemas em Cloud automaticamente controlam e optimizam o uso dos recursos, por meio de mecanismos de medida inseridos em níveis apropriados para cada tipo de serviço (Armazenamento, Processamento, largura de banda utilizada e contas activas). Assim, o uso dos recursos pode ser controlado e reportado com transparência para ambos, consumidor e fornecedor de serviços. A Cloud Security Alliance (CSA), na sua publicação de security guidance for critical areas of focus in cloud computing defende ainda a inclusão de mais uma característica essencial no modelo, multi-tenancy (CSA, 2011): 10
25 Multi-tenancy Na sua forma mais simples, implica o acesso por vários utilizadores a recursos ou aplicações de forma partilhada, podendo estes pertencer ou não à mesma organização, tornando fundamental o reforço de politicas de segurança, segmentação, isolamento, governança, níveis de serviço e facturação de custos para as diferentes organizações. Esta característica pode ter diferentes implicações dependendo do modelo de serviço a que se refere, sendo mais importante em modelos de desenvolvimento de cloud pública, embora em cloud privadas também se possa aplicar, caso uma organização deseje uma forma de segregação inter-departamental, por exemplo Outras Características da Cloud Para além das características principais do modelo de cloud computing existem outras que podem ser apontadas como essenciais ou relevantes, consoante o modelo de serviço e desenvolvimento escolhidos: Fiabilidade - Transversal a todos os modelos cloud, denota a capacidade de assegurar a operação constante de um sistema, sem interrupções e perda de informação. Tipicamente é conseguida recorrendo a recursos e sistemas redundantes (Lutz Schubert, s.d.); Interoperabilidade Capacidade dos sistemas para comunicarem, em que a informação enviada é perfeitamente entendida (Ahronovitz, et al., 2010) ; Cloud Bursting Técnica usada numa cloud híbrida para fornecer recursos adicionais a uma cloud privada conforme necessário. Caso uma cloud privada tenha recursos disponíveis para a carga em curso, a cloud pública não é usada. Quando os recursos atingem um pico na cloud privada, recursos adicionais da cloud publica são disponibilizados (Ahronovitz, et al., 2010); Manutenção e actualizações Manutenção e actualização de software estão muito facilitados pela centralização dos sistemas (Sosinsky, 2011). Posteriormente será feita uma análise mais exaustiva, mas numa primeira abordagem, estas características fomentam duas vantagens significativas na adopção do modelo cloud computing (Lutz Schubert, s.d.): 11
26 Redução de custos A capacidade de adicionar recursos dinamicamente, como computadores virtuais, espaço de armazenamento, equipamento de rede, entre outros, permitindo que os clientes cloud possam gerir as necessidades de recursos ou serviços com base em cargas de trabalho consideradas normais, em vez de apontar para picos de carga ocasionais, proporcionando redução de custos em hardware, equipamento de rede, software, consumo energético e com pessoal técnico. Mais capacidade de resposta O planeamento, aprovação e compra de novo equipamento ou software pode levar dias ou mesmo semanas em qualquer empresa. No modelo cloud computing, a aquisição e posterior libertação do recurso acontece de acordo com as necessidades do momento, podendo ainda dispensar qualquer intervenção humana no processo Modelos de Serviço Os serviços de cloud computing, também referidos como Software Platform Infrastructure (SPI) (CSA, 2011), dividem-se em três modelos universalmente aceites (Sosinsky, 2011) de acordo com o nível de abstracção das capacidades fornecidas e com o modelo de serviço dos fornecedores (Mell, Peter; Grance, Timothy; NIST, 2011) (Vaquero, et al., 2009): Software-as-a-service (SaaS); Platform-as-a-service (PaaS); Infrastructure-as-a-service (IaaS). Estes modelos podem ser vistos como uma arquitectura em camadas, onde os serviços de uma camada mais elevada incluem os serviços das camadas inferiores. Cada modelo de serviço disponibiliza uma funcionalidade única de acordo com o utilizador e com o controlo sobre o ambiente de trabalho aumentando à medida que descemos na infraestrutura, sendo menor no modelo Software-as-a-Service e maior no modelo Infrastructure-as-a-Service (CIO Council, s.d.). 12
27 SaaS PaaS IaaS Figura 5: Modelos de Serviço Software as a Service (SaaS). Software-as-a-Service é um modelo de distribuição de software e talvez o modelo de cloud mais comum e conhecido. O cliente não compra o software, aluga-o através de uma subscrição ou paga consoante a utilização (Mather, et al., 2009). Os serviços disponibilizados ao cliente cloud utilizam aplicações do fornecedor e são executados numa infraestrutura em cloud e acedidas através de dispositivos vários via um browser (thin client) ou o interface de um programa (heavy client). Os clientes cloud não gerem ou controlam a infraestrutura subjacente, sejam redes, servidores, sistemas operativos, áreas de armazenamento ou mesmo funcionalidades específicas dos aplicativos, com uma possível excepção na definição de determinados parâmetros de configuração (Mell, Peter; Grance, Timothy; NIST, 2011). Vantagens deste modelo (Mather, et al., 2009): Permite a uma organização transferir a gestão, a instalação e a manutenção de uma aplicação para terceiros, reduzindo custos de licenciamento, servidores e outra infraestrutura, assim como com pessoal necessário para a gerir, instalar e manter internamente; Permite controlar, limitar a utilização do software por parte do fornecedor, permitindo um apertado controlo sobre as versões instaladas. Esta forma de centralização facilita ainda a optimização de custos ao tornar desnecessário a instalação do software em todos os dispositivos cliente; 13
28 A distribuição de software neste modelo usa o modo one-to-many, com a internet como infraestrutura subjacente, permitindo ao utilizador final aceder à aplicação através de um browser. Alguns fornecedores recorrem a um interface próprio desenhado para dar suporte a algumas características únicas das suas aplicações; Uma aplicação típica deste modelo não requer um equipamento específico para ser executado, necessitando apenas de acesso através da infraestrutura existente com acesso à internet. Pede ser necessário proceder a alterações da firewall corporativa para que a aplicação seja executada sem problemas; Do ponto de vista do utilizador, a gestão da aplicação é suportada pelo fornecedor, podendo ser configurada recorrendo a uma API, mas, ainda assim, uma aplicação neste modelo não permite um elevado nível de customização Platform as a Service (PaaS). Este modelo pode ser descrito como um ambiente de trabalho para programadores de aplicações para a cloud (Youseff, et al., 2008), instalado na infraestrutura do fornecedor, tornando desnecessária qualquer instalação de software de desenvolvimento localmente (Mather, et al., 2009). Os serviços disponibilizados permitem executar numa infraestrutura em cloud aplicações desenvolvidas ou adquiridas pelos clientes cloud, usando linguagens de programação, ferramentas, livrarias e serviços suportadas pelo fornecedor. O cliente cloud não gere ou controla a infraestrutura subjacente, incluindo redes, servidores, sistemas operativos ou áreas de armazenamento, mas controla as aplicações desenvolvidas e eventualmente configurações do ambiente de trabalho do sistema de desenvolvimento (Mell, Peter; Grance, Timothy; NIST, 2011). Este modelo deve incluir as seguintes características (Mather, et al., 2009): Acesso via browser às ferramentas de programação; Providenciar um ambiente de elevada produtividade, Integrated Development Environment (IDE), a ser executado na mesma plataforma de produção a que se destina, facilitando cenários de testes e depuração; Fornecer integração com serviços web externos e base de dados; Capacidade de monitorização da aplicação e actividade do utilizador, permitindo aos programadores entender melhor as aplicações e efeitos das melhorias; 14
29 Escalabilidade, fiabilidade e segurança devem estar incluídas no modelo sem necessidade de desenvolvimentos adicionais, configuração ou custos acrescentados; Suporte, formalmente ou a pedido, de colaboração transversal a todo o ciclo de vida de software, desenvolvimento, teste, documentação e operação mantendo a segurança do código fonte e propriedade intelectual associada; Incluir suporte de custos consoante a utilização Infrastructure as a Service (IaaS). Disponibiliza ao cliente cloud recursos de infraestrutura e serviços como capacidade de processamento, áreas de armazenamento, redes e outros recursos computacionais de modo a possibilitar a execução de aplicações e sistemas operativos. Os clientes cloud não gerem a infraestrutura subjacente, mas podem controlar os sistemas operativos, áreas de armazenamento e aplicações desenvolvidas e possivelmente configurar componentes de rede, por exemplo, firewalls, routers, etc (Mell, Peter; Grance, Timothy; NIST, 2011). Assim, um cliente cloud tem privilégios de desligar e ligar os servidores e equipamentos de rede, adicionar discos virtuais, configurar permissões de acesso, etc (Buyya, et al., 2011). Os custos para o cliente cloud em relação aos sistemas TI tradicionais são bastante inferiores, uma vez que este não tem que adquirir servidores, equipamento de rede, custos com espaço de instalação, pessoal técnico de suporte, etc. Assim, o acesso a recursos de infraestrutura é feito por aluguer e pago consoante os recursos efectivamente consumidos. Os serviços disponibilizados neste modelo de desenvolvimento podem ser categorizados em (Youseff, et al., 2008): Recursos Computacionais O mais comum neste modelo é a disponibilização de computadores virtuais (virtual machines), proporcionando completa flexibilidade aos utilizadores com acesso total aos sistemas operativos; Armazenamento de dados Permite aos clientes cloud armazenar dados numa infraestrutura remota, acessíveis de qualquer lugar e a qualquer hora, facilitando o crescimento das aplicações cloud para além dos servidores onde estão instaladas; Comunicações Cloud computing elevou as necessidades de um serviço garantido de comunicações, tornando-se numa componente vital. Consequentemente, os 15
30 fornecedores cloud estão obrigados a providenciar comunicações que sejam, orientadas ao serviço, configuráveis, passíveis de agendamento, previsíveis e fiáveis Modelos de Desenvolvimento Embora o termo cloud computing tenha emergido principalmente do modelo público, mais conhecido como Public Cloud, existem outros modelos desenvolvimento, consoante a localização física da infraestrutura de suporte e modo de distribuição que sejam adoptados. O NIST (Mell, Peter; Grance, Timothy; NIST, 2011) propõe quatro modelos de desenvolvimento: Public cloud (Cloud Pública); Private cloud (Cloud Privada); Community cloud (Cloud Comunitária); Hibryid cloud (Cloud híbrida). Cloud pública e a cloud privada são subcategorias da internet que se definem pela sua relação com a empresa ou com o cliente cloud, podendo ainda ser referidas como internas ou externas, (Mather, et al., 2009) onde a diferenciação é baseada na relação da cloud com a empresa Cloud Pública A cloud pública é o modelo de desenvolvimento mais conhecido e que se encontra disponível a qualquer indivíduo ou organização, bastando para tal um acesso à internet, e pode ser acedida de forma quase imediata. O NIST (Mell, Peter; Grance, Timothy; NIST, 2011) define este modelo como uma infraestrutura localizada dentro da propriedade do fornecedor que é aprovisionada para uso aberto ao público em geral, podendo a propriedade, a gestão e a operação ser efectuada por organizações de âmbito empresarial, académico ou governamental. Neste modelo, a gestão da segurança e operações diárias são relegadas para o lado do fornecedor, que é responsável pela oferta do serviço, deixando pouco ou nenhum controlo ou conhecimento acerca da segurança física e lógica da infraestrutura subjacente aos clientes (Mather, et al., 2009). 16
31 Cloud Privada No modelo de cloud privada a infraestrutura subjacente é desenvolvida e gerida exclusivamente para um cliente cloud específico, podendo o fornecedor pertencer à mesma organização. Já a localização desta pode ser no seio da infraestrutura da organização ou hospedada exteriormente numa infraestrutura gerida por terceiros. Uma cloud privada oferece ao cliente cloud mais controlo sobre a infraestrutura, recursos computacionais e clientes cloud (Jansen & Grance, 2011) que o modelo anterior. O NIST (Mell, Peter; Grance, Timothy; NIST, 2011) define este modelo como uma infraestrutura em que a operação é direccionada apenas para um cliente cloud, com a gestão efectuada pelo próprio ou por uma terceira entidade, e que, normalmente, a infraestrutura de suporte se encontra dentro da propriedade do cliente. Uma vez que a organização tem que adquirir, instalar e gerir toda a infraestrutura, não beneficia da redução de custos de outros modelos, e mais vincadamente em comparação com o anterior, cloud publica. É ainda responsável pela gestão da segurança e operações diárias, podendo essas responsabilidades ser delegadas a uma terceira entidade por outsourcing reguladas por SLA s Cloud Comunitária Conceptualmente, este modelo situa-se entre o modelo de cloud pública e o modelo de cloud privada. Recorrendo mais uma vez à definição do NIST (Mell, Peter; Grance, Timothy; NIST, 2011) para este Modelo, uma cloud comunitária é uma infraestrutura partilhada por várias organizações, pertencendo a uma comunidade específica e partilhando objectivos comuns, como a missão, os requisitos de segurança e as políticas e considerações de conformidade. A gestão pode ser efectuada pelas organizações ou por terceiros e a sua localização ser interna ou externa Cloud Híbrida Uma cloud híbrida junta dois ou mais dos modelos referidos anteriormente. Esta abordagem pode trazer benefícios ao cliente cloud uma vez que permite o uso de cloud privada ou mesmo comunitária, para aplicações ou informação de características mais sensíveis e cloud pública, para aplicações ou informação de carácter não sensível para a organização. Permite ainda, quando necessário, recorrer ao cloud bursting, isto é, para fazer face a um pico de necessidade computacional, a organização requisita, temporariamente, a capacidade extra a um fornecedor de cloud, (Buyya, et al., 2011). O NIST (Mell, Peter; Grance, Timothy; NIST, 2011) define este modelo com uma 17
32 combinação de dois ou dos três modelos (Pública, Privada e Comunitária), os quais continuam a existir isoladamente, mas são integrados por meio de tecnologia proprietária ou aberta, que viabiliza a portabilidade e mobilidade da informação e aplicações Modelos de Desenvolvimento Alternativos Para além do Modelo proposto pelo NIST e globalmente aceite, existem dois modelos de desenvolvimento alternativos. O primeiro apresenta uma visão diferente de cloud computing e foi proposto pelo Jericho Forum 4, e outro que complementa o modelo do NIST, proposto por David Linthicum, no SYS-CON s Virtualization Journal 5 e posteriormente no seu livro, Cloud Computing and SOA Convergence in Your Enterprise, a Step-by-Step Approach O Modelo de Linthicum Numa tentativa de melhor descrever cloud computing, David Linthicum propõe uma pilha (stack), onde considera cada componente lógica da infraestrutura de cloud computing e como os seus componentes interagem, interligando SOA e cloud computing. Este modelo, ainda que possa parecer mais complexo, não é necessariamente assim. Na verdade e analisando para além disso, este modelo aporta um valor acrescentado, afirma. Assim propõe onze categorias para a tecnologia de cloud computing (Linthicum, 2009):
33 Figura 6: Componentes e categorias de cloud computing (Linthicum, 2009) Storage-as-a-service (Espaço de disco a pedido) - Capacidade de disponibilizar espaço físico de armazenamento num local remoto, mas tratado localmente para qualquer aplicação que dele necessite. Esta é a forma mais primitiva de cloud computing e é uma componente com influência em todas as restantes; Database-as-a-service (DaaS) Disponibiliza a capacidade de usar uma base de dados remota, partilhando-a com outros utilizadores e funcionando logicamente como localmente; Information-as-a-service Capacidade de consumir qualquer tipo de informação, localizada remotamente, recorrendo a um interface, por exemplo uma API; Process-as-a-service Recurso remoto com capacidade de vincular múltiplos recursos juntando-os, sejam serviços ou informação, localizados no mesmo recurso de cloud computing ou remoto, criando um processo de negócio; Application-as-a-service (AaaS) Também conhecido como Software-as-a-service (SaaS), é qualquer aplicação entregue via internet ao utilizador final, tipicamente recorrendo a uma aplicação browser. Comum ao modelo proposto pelo NIST, referido no parágrafo 2.4.1; Platform-as-a-service (PaaS) Trata-se de uma plataforma completa, incluindo ferramentas de desenvolvimento, armazenamento, teste, etc, entregues através de uma plataforma remota aos utilizadores. Baseia-se no modelo de partilha de recursos. Comum ao modelo proposto pelo NIST, referido no parágrafo 2.4.2; 19
34 Integration-as-a-service Capacidade de entrega de uma stack completa de integração da cloud, incluindo interface com as aplicações, mediação semântica, controlo de fluxo, desenho de integração, etc. Essencialmente, Integration-as-a- Service inclui a maioria das capacidades e funções encontradas numa tecnologia tradicional de Entreprise Application Integration (EIA), entregue como um serviço; Security-as-a-service capacidade de disponibilizar remotamente serviços de segurança através da internet; Management/governance-as-a-service (MaaS e GaaS) Qualquer serviço a pedido que forneça capacidades de gestão de um ou mais serviços de cloud. Tipicamente os serviços mais simples, como topologia, utilização de recursos, virtualização. Sistemas de governança também vão sendo disponibilizados, oferecendo, por exemplo, capacidade para aplicar políticas definidas para informação e serviços; Testing-as-a-service Capacidade de testar localmente ou sistemas entregues em plataforma cloud recorrendo a software de teste e serviços remotos. Infrastructure-as-a-service (IaaS) Também referido como data-center-as-a-service. Capacidade para remotamente aceder a recursos computacionais. Comum ao modelo proposto pelo NIST, referido no parágrafo Modelo de Desenvolvimento Jericho Cloud Cube O Jericho Forum, vinculado ao The Open Group 6, criado em 2004, composto por profissionais da área de segurança nas tecnologias de informação, governamentais, empresariais e académicas, propõe em Abril de 2009 no documento Jericho Forum Cloud Model um modelo estruturado a partir de quatro dimensões, ao qual denominam Cloud Cube Model (Jericho Forum, 2009). Este documento tem como finalidade (Krutz & Vines, 2010): Apontar que nem todos os serviços de informação funcionam melhor na cloud, sendo mesmo preferível mantê-los nos sistemas tradicionais; Explicar o seu entendimento dos modelos cloud computing propostos;
35 Descrever as características chave, riscos e benefícios de cada modelo; Disponibilizar uma framework para explorar com mais detalhe a natureza diferente de cada modelo, identificando problemas que necessitam respostas com o objectivo de os tornar mais seguros. Figura 7: Representação Gráfica do Cubo da Cloud Fonte: Jericho Forum As quatros dimensões propostas de forma resumida (Sosinsky, 2011): Localização física da informação: Determina as fronteiras de uma organização, Interna (I) ou Externa (E); Direito de Propriedade: Medida que não se aplica apenas ao direito de propriedade, mas também de interoperabilidade, facilidade de transferência da informação e grau de dependência aplicacional do fornecedor (vendor aplication lock-in), Proprietary (P) ou Open (O); Fronteiras de segurança: Unidade de medida aplicável para apurar se a operação se localiza dentro ou fora desta fronteira de segurança, Perimeterised (Per) / Deperimiterised (D-p); Origem: Insourced or Outsourced refere se o serviço é fornecido pelo cliente ou pelo fornecedor. Estas quatro dimensões correspondem a dois diferentes estados, nos oito modelos de cloud possíveis: Per (IP, IO, EP, EO) and D-p (IP, IO, EP, EO). A dimensão Origem 21
36 aponta a entrega do serviço. O Cloud Cube Model demonstra que a fronteira de segurança, habitualmente a firewall corporativa, não se aplica a cloud computing Infraestrutura de Referência de Cloud Computing Um modelo de referência de cloud computing é uma abstracção dos conceitos e relações que podem ser usados para auxiliar as organizações a criar normas e directivas para a sua aplicação. Estes modelos têm como atributos chave a abstracção, entidades, relações entre elas e desprovimento de factores tecnológicos, esclarecendo contextualmente os aspectos do modelo. Figura 8: O modelo de referência conceptual (Liu, et al., 2011) A infraestrutura de referência de cloud computing proposta pelo NIST é um modelo conceptual de alto nível que define os actores, actividades e funções usadas no processo de desenvolvimento de arquitecturas de cloud computing e é apresentado em duas partes (Hogan, et al., 2011): Uma primeira parte em que são definidos os actores ou entidades do modelo cloud computing, que participam em transacções ou processos o o Cliente cloud; Fornecedor cloud; 22
37 o Auditor cloud; o Intermediário cloud 7 ; o Fornecedor de serviços de internet cloud 8. Uma segunda parte, que inclui as mais importantes componentes da arquitectura cloud computing para a gestão e fornecimento de serviços: o o o o Orquestração de serviços, Gestão de serviços, Segurança Privacidade Actores do Modelo Cloud Computing Numa análise ao modelo e num primeiro nível, temos os actores principais da arquitectura. Assim, os cinco actores do modelo cloud computing podem ser caracterizados da seguinte forma (Liu, et al., 2011): Cliente Cloud Pessoa ou organização ou entidade que mantém uma relação comercial com um ou mais fornecedores de serviços cloud; Fornecedor Cloud Pessoa, organização ou entidade responsável por disponibilizar serviços cloud às partes interessadas, clientes e agregadores cloud; Auditor Cloud Pessoa, organização ou entidade responsável pelo exame cuidadoso e sistemático aos serviços, operações, execução e segurança em cloud computing; Intermediário Cloud Pessoa, organização ou entidade que faz a gestão do uso, execução e entrega de serviços cloud, funcionando como intermediário entre fornecedores e clientes; 7 Cloud Broker 8 Cloud Carrier 23
38 Fornecedor de serviços de internet Cloud Entidade ou organização que fornece serviços de comunicação a fornecedores e clientes cloud Orquestração de Serviços Orquestração de serviços é a organização dos componentes de serviço para suporte aos fornecedores de cloud computing na configuração, coordenação e gestão de recursos para o fornecimento de serviços aos clientes cloud (Liu, et al., 2011). Neste modelo são propostas três camadas de componentes que os fornecedores cloud necessitam para entregarem os seus serviços: Camada de serviço; Camada de controlo e abstracção de recursos; Camada de recursos físicos Camada de Serviço Nesta camada os fornecedores cloud definem os interfaces que permitem aos clientes cloud aceder aos serviços de cloud computing. O modelo de serviço SPI representa um aumento da abstracção da complexa infraestrutura subjacente (Winkler, 2011). Assim, cada modelo de desenvolvimento, SaaS, PaaS e IaaS, implicam diferentes riscos e benefícios, pelo que deve ser dada atenção às especificidades de cada modelo. A partilha de responsabilidades entre o cliente e o fornecedor difere de acordo com o modelo de cloud computing. Dum ponto de vista do fornecedor, as suas responsabilidades vão aumento à medida se sobe na infraestrutura, isto é, tem menos responsabilidade no modelo IaaS em que apenas controla a infraestrutura de suporte subjacente, até ao modelo SaaS, em que toda a parte de software de suporte e software aplicacional é da a sua responsabilidade. Verifica-se o inverso sob o ponto de vista do cliente em que a responsabilidade aumenta à medida que se desce na infraestrutura Camada de Controlo e Abstracção de Recursos Camada composta pelos componentes de abstracção, que permite aos fornecedores de cloud computing gerir e fornecer acesso às camadas físicas aos clientes. A gestão nesta camada recorre a componentes de software que são responsáveis por controlo de acessos, alocação de recursos e monitorização da utilização dos serviços contratados. Esses componentes de software são conhecidos como hypervisores (supervisores), máquinas virtuais, dispositivos de armazenamento e outros métodos de abstracção, separando a parte física da infraestrutura da parte computacional. 24
39 A virtualização é um elemento chave na tecnologia de cloud computing (Amies, et al., 2012) e permite que servidores, dispositivos de armazenamento e outros componentes de rede sejam tratadas como um conjunto de recursos, podendo ser alocadas quando solicitadas (CSA, 2011). Figura 9: Arquitecturas de virtualização Existem dois tipos de arquitecturas de virtualização. A virtualização do tipo I, em que o supervisor é instalado logo acima do hardware, sem qualquer outro sistema operativo ou software intermediário, e comunica directamente com o hardware. A virtualização de tipo II o supervisor é executado sobre o sistema operativo anfitrião e este é responsável pela comunicação com o hardware. O supervisor é a componente da máquina virtual que permite a partilha de recursos e o isolamento desta com o hardware do sistema anfitrião. Esta funcionalidade de isolamento do supervisor determina a capacidade de resistência e segurança da máquina virtual e a sua exposição ao risco. Outras formas de virtualização usadas em cloud computing são a para-virtualização, que permite que um único servidor seja utilizado como se de vários servidores se tratasse e o clustering, que permite que vários servidores sejam utilizados como apenas um. Os benefícios da virtualização incluem a multi-tenancy, isto é, a melhor utilização dos servidores e a consolidação dos centros de dados. Estes permitem aos fornecedores de serviços cloud alcançarem mais densidade de clientes cloud num mesmo servidor, que se 25
40 traduz em melhores taxas de utilização de hardware, aportando ganhos financeiros em despesas com equipamentos e eficiência operacional. Todavia, a virtualização também traz consigo preocupações de segurança, como sistemas operativos a serem executados no topo de outro sistema operativo e problemas de segurança ao nível do supervisor. A virtualização tem as seguintes características (Ghosh & Hughes, 2011): Isolamento Um equipamento virtual encontra-se isolado dos restantes e, dessa forma, problemas e falhas com um não tem efeito nos restantes; Independentes do hardware Máquinas virtuais que são independentes do hardware, o que permite a sua movimentação entre diferentes plataformas; Encapsulamento Máquinas virtuais são encapsuladas em formato de ficheiro. Esta característica permite que a sua movimentação entre servidores de suporte seja uma tarefa simples, tornando possível a rápida automatização e eficácia para a disponibilização de recursos adicionais, tarefa que seria muito demorada e de difícil implementação com instalações de raiz; Compatibilidade Os sistemas operativos e aplicações podem ser executados sem alterações em ambientes virtuais. Algumas formas de virtualização que podem ser apontadas: Virtualização de servidores; Virtualização de dispositivos de armazenamento; Virtualização de dispositivos de rede; Virtualização de serviços; Actualmente e de uma forma geral, a virtualização encontra-se em quase todas as infraestruturas, tradicionais ou de cloud. A razão para isso são os benefícios que os ambientes virtuais proporcionam e que podem ser resumidos (Josyula, et al., 2012) Acesso a pedido a recursos de rede, de armazenamento ou computacionais; Custos energéticos mais reduzidos, com os benefícios inerentes; Redução do espaço ocupado pela infraestrutura; 26
41 Redução de custos iniciais e operacionais em equipamento Camada de Recursos Físicos A terceira e última camada inclui recursos físicos de hardware, tais como computadores, routers, firewalls, switches, componentes de armazenamento e outras componentes da infraestrutura. Inclui ainda todo o equipamento de suporte, como equipamento de refrigeração e ventilação, equipamento redundante de energia, fontes de alimentação, comunicações e espaço físico. A Cloud Security Aliance define a segurança nesta camada de forma similar à segurança actualmente existente nas infrestruturas tradicionais (CSA, 2011). Assim a segurança pode ser vista de dois prismas (Krishnan, 2010): Segurança física Um centro de dados tem diversas camadas de segurança, acumulando controlos em cada perímetro. O acesso às zonas de gestão a partir das quais é feita a gestão, o acesso à informação e às aplicações dos clientes cloud, é restrito e apenas autorizado ao pessoal estritamente necessário. O acesso físico aos equipamentos de suporte da infraestrutura também deve ser controlado. Para impedir o acesso a possíveis atacantes que possam comprometer a informação e detectar possíveis intrusões, são usados controlos de segurança, como, por exemplo câmaras, leitores biométricos, leitores de cartões, detectores de movimento, etc. Devem ainda existir detectores para os riscos de fogo, inundação, calor extremo e controlo de níveis de humidade; Segurança de rede A segurança de rede é garantida recorrendo a uma variedade de dispositivos como balanceadores de rede, firewalls, sistemas de detecção de intrusão, etc. As aplicações e serviços são segmentados em áreas virtuais, garantindo que o tráfego de rede não passa para além do perímetro necessário ao funcionamento aplicacional. Com o objectivo de redução das vulnerabilidades para um nível tolerável e de minimizar os efeitos de um ataque, são utilizados diversos controlos de segurança que podem ser categorizados nas seguintes áreas (Krutz & Vines, 2010): Restritivos Visam reduzir a probabilidade de um ataque; Preventivos Proteger as possíveis vulnerabilidades tornando um ataque impossível ou reduzindo o seu impacto. Também desencorajam tentativas de violação das políticas de segurança; Correctivos Tem como objectivo reduzir os efeitos de um ataque; 27
42 Detectivos Detectar ataques e desencadear controlos preventivos ou correctivos. Estes controlos informam sobre violações ou tentativas de violação das políticas de segurança e incluem controlos como Intrusion Detection Systems (IDS), políticas organizacionais, câmaras e detectores de movimentos. Já na perspectiva dos clientes cloud computing, as preocupações de segurança centram-se no armazenamento e processamento de informação sensível em modelos de cloud públicas, híbridas e comunitárias, ainda que um pouco menos neste último modelo de desenvolvimento (Winkler, 2011). Estas preocupações focam-se em duas áreas: Perda de controlo sobre a informação quando a gestão desta passa a ser efectuada dentro do perímetro de rede informática do fornecedor de serviços cloud; Preocupações sobre a sua informação residir em sistemas partilhados, com os riscos daí inerentes para informação sensível Serviços de Gestão na Cloud Esta camada inclui todas as funções necessárias para a gestão e operação dos serviços requisitados pelos clientes de cloud computing (Liu, et al., 2011) e divide-se em três áreas: Suporte ao negócio; Aprovisionamento e configuração; Portabilidade e interoperabilidade Suporte ao Negócio Para o suporte ao negócio estão todos os processos que permitem ao cliente gerir os custos com a cloud, efectuar pagamentos e a troca de informação entre cliente e fornecedor acordada contratualmente, como por exemplo informação sobre incidentes, tentativas de intrusão, etc. Também deve ser permitido ao cliente cloud prever necessidades futuras para que, caso se mostre necessário, rever as condições contratuais com o fornecedor Aprovisionamento e Configuração Para o aprovisionamento e configuração os fornecedores devem disponibilizar aos seus clientes ferramentas que lhes permitam uma gestão automática e facilitada dos seus recursos. As API s são uma dessas ferramentas que actuam como facilitador e que permitem aos clientes o aprovisionamento de recursos adicionais e a pedido, com menor 28
43 ou maior capacidade disponível para a configuração desses mesmos recursos (Scruggs, et al., 2011). Estas API s permitem retirar dos ambientes cloud todas as suas capacidades e vantagens, mascarando a complexidade dos sistemas subjacentes da arquitectura. Um dos problemas actuais e que deve ser analisado com atenção é a proliferação de diferentes API s de cada fornecedor, dificultando a portabilidade e a interoperabilidade entre fornecedores e infraestruturas. A Unified Communications Interoperability Forum (UCI) 9, organização sem fins lucrativos, visa definir normas que facilitem a unificação e interoperabilidade entre sistemas de hardware, software, fornecedores de serviços cloud e consumidores cloud. Existem outras organizações que estudam este problema, que será abordado mais à frente Portabilidade e Interoperabilidade Os fornecedores devem disponibilizar aos seus clientes ferramentas que facilitem e permitam a fácil mobilidade da informação e comunicação entre os seus sistemas e os sistemas do cliente ou de outros fornecedores. A portabilidade a interoperabilidade são dos aspectos que levantam preocupações aos potenciais clientes do modelo de cloud computing. De facto, muitos fornecedores têm um modelo de infraestrutura de suporte e API s proprietárias que, após a migração das aplicações e informação de um cliente para a sua infraestrutura cloud, a sua portabilidade e interoperabilidade com outros sistemas, pode tornar-se difícil e complexa pelas diferenças entre o suporte aplicacional e de compatibilidade Diferença entre Arquitectura Cloud e Arquitectura Tradicional Numa primeira análise podemos encontrar semelhanças entre estas duas arquitecturas, a infraestrutura cloud e a infraestrutrura tradicional, porque normalmente ambas são compostas de três camadas. Na arquitectura tradicional a primeira camada, a infraestrutura, compreende todo o equipamento de rede, tais como servidores, switches, balanceadores, routers, equipamentos de protecção, rede física, etc, em tudo similar com à camada IaaS do modelo cloud. A segunda camada é composta pelo middleware, onde se encontram os sistemas operativos, as plataformas de desenvolvimento e o diverso
44 software de suporte à camada seguinte, que podemos mapear para PaaS no modelo cloud. Na camada de topo temos todo o software aplicacional em tudo idêntico ao SaaS no modelo cloud computing. Infraestrutura Tradicional Cloud Computing Aplicações SaaS - Software as a Service Máquinas Virtuais, Plataformas de desnvolvimento PaaS - Platform as a Service Infraestrutura, servidores fisícos, equipamentos de rede IaaS - infrastructure as a Service Figura 10: Infraestrutura tradicional versus Cloud Computing Apesar de existirem semelhanças entre as duas arquitecturas, cloud e tradicional, estas têm diferenças fundamentais (Ghosh & Hughes, 2011): Tempo de Implementação - Uma vez efectuadas as configurações iniciais na arquitectura cloud, o acesso é muito mais rápido que numa arquitectura tradicional, que necessita de tempo de instalação e configuração. Numa arquitectura cloud o tempo de implementação pode ser de minutos ou horas, já numa arquitectura tradicional esse tempo pode ascender a dias ou mesmo semanas; Custo de implementação - A arquitectura cloud reduz ou elimina os elevados custos iniciais na aquisição de equipamento, de software e na instalação que se verificam numa arquitectura tradicional em que esse valor é fixo e inicial. Numa arquitectura cloud, o custo é variável consoante os serviços contratados; Economia de escala - Uma das vantagens da arquitectura cloud é que as boas práticas de segurança que os fornecedores devem observar na configuração dos sistemas favorecem todos os clientes. Numa arquitectura tradicional essas configurações têm que ser implementadas em cada infraestrutura instalada e, dado o seu custo operacional, por vezes essas boas práticas de segurança apenas se encontram em empresas de maior dimensão e maior capacidade financeira; 30
45 Multi-tenacy Quando aplicado correctamente numa arquitectura cloud permite aos fornecedores terem vários clientes suportados pelos seus sistemas partilhados. Numa arquitectura tradicional apenas encontramos esta característica em certas aplicações de hosting; Escalabilidade Permite que os recursos numa arquitectura cloud possam ser aumentados ou reduzidos de forma automática e sem intervenção humana no processo. Já numa arquitectura tradicional essa intervenção é sempre necessária; Virtualização As arquitecturas cloud são habitualmente virtualizadas ao passo que nos sistemas tradicionais predominam os sistemas físicos, ainda que ocasionalmente possam existir sistemas virtualizados. 31
46 Out of intense complexities intense simplicities emerge. Winston Churchill 32
47 3. Análise à Arquitectura Cloud Computing O paradigma de cloud computing possui propriedades únicas que o tornam muito apetecido nos dias de hoje. Algumas dessas propriedades levantam preocupações, como por exemplo, de segurança, perda de controlo sobre a informação, de disponibilidade dos serviços migrados para a cloud, de performance no acesso aos serviços, de custos, etc. Um inquérito levado a cabo pela Internacional Data Corporation 10 (IDC), no 3º trimestre de 2009 a 263 executivos de tecnologias de informação, ao pedido para hieraquizar a preocupações do modelo cloud computing obteve como resultados que as três principais preocupações eram nas áreas de segurança, disponibilidade e performance. Figura 11: Principais preocupações na cloud (Gens, 2009) Os fornecedores de serviços cloud, tendo consciência dessas preocupações e receios desenvolveram técnicas e ferramentas de protecção para as minimizarem e tornarem a cloud computing segura (Sosinsky, 2011). Para que os sistemas em cloud computing possam atingir todo o potencial prometido pela tecnologia, devem oferecer aos seus clientes e utilizadores uma segurança, privacidade e desempenho efectivos. A grande concentração de informação e sistemas de vários fornecedores numa infraestrutura em cloud apresentam-se como alvos preferenciais a ataques informáticos, por outro lado, sistemas cloud podem apresentar defesas mais robustas, escaláveis e com um custo efectivo (Perilli, et al., 2009). A confiança na utilização da cloud depende dos mecanismos de segurança, controlo
48 efectivo de acessos, gestão robusta de identidades, meios seguros de comunicação e controlos de segurança devidamente implementados e auditados. De acordo com outros inquéritos levados a cabo por outras entidades, as seguintes preocupações parecem estar na mente de muitos clientes cloud computing (Josyula, et al., 2012): Como irá a cloud manter a informação segura e disponível; Como gerir os riscos de segurança e gestão de risco, actuais e futuros; Que tipos de serviços de segurança estão disponíveis através da cloud; Como efectuar auditorias externas e internas à segurança na cloud; Como automatizar o aprovisionamento de serviços de rede, computacionais e de armazenamento; Como fazer aprovisionamento a pedido e em tempo real recorrendo a um portal que suporte todos os dispositivos de infraestrutura necessários; Como promover a interacção de todas as novas ferramentas de cloud com as ferramentas actuais. Os responsáveis pela segurança de uma organização devem estar aptos a determinar os controlos preventivos e detectivos de segurança existentes, para que possam definir a postura de segurança da organização (Krutz & Vines, 2010). Para uma melhor análise e decisão de um processo de migração para cloud computing, um conhecimento aprofundado da sua infraestrutura, das suas vantagens e desvantagens e das questões de segurança, é necessário e pode marcar o sucesso ou insucesso na adopção de um modelo de cloud computing no seio de uma organização. Nos parágrafos seguintes analisaremos o modelo de cloud computing, tendo como base a infraestrutura de referência proposta pelo NIST e globalmente mais aceite, definindo claramente as fronteiras de responsabilidade do fornecedor e do cliente, vantagens e desvantagens, riscos e questões de segurança inerentes ao ambiente de cloud computing, assim como várias ferramentas de controlo e monitorização existentes. 34
49 3.1. Vantagens Cloud Computing Para além das cinco vantagens essenciais definidas pelo NIST e já abordadas no capítulo 2.2, self-service a pedido, ubiquidade, pool de recursos, rápida elasticidade e serviços mensuráveis, outras vantagens podem ser apontadas ao modelo cloud computing: Redução de custos; Escalabilidade; Actualizações automáticas; Facilidade de acesso; Fiabilidade; Rápido desenvolvimento e implementação; Acesso a melhores recursos tecnológicos Redução de Custos Os motivos mais importantes para a introdução de uma infraestrutura cloud numa organização são os factores financeiros. O ganho financeiro pode ser significativo, dependendo do modelo de desenvolvimento cloud seleccionado, sendo mais elevado num ambiente de cloud pública e mais reduzido ou nulo num modelo de cloud privada. De facto, a cloud pública não requer investimento em hardware, software ou equipamento de rede (Mather, et al., 2009). De uma forma geral, uma infraestrutura cloud computing reduz os custos de gestão, manutenção e instalação de um centro de dados próprio com melhorias de eficiência nas infraestruturas TI, minimizando os custos e melhorando de forma significativa a agilidade na instalação e disponibilização de novos serviços e recursos. Dependendo do modelo escolhido, por vezes é afirmado (SUN, 2011) que, para os utilizadores, o ambiente de cloud computing significa que não existem necessidades de aquisição de equipamento, gestão de licenças, gestão de software e actualizações, contratação de pessoal técnico ou consultores e a compra ou arrendamento do espaço necessário. Outro factor de grande relevância no modelo de cloud computing é a capacidade de gerir picos de utilização, eliminando a necessidade de ter recursos subutilizados apenas para provir essa procura ocasional. 35
50 Para que as razões económicas sejam consideradas, os modelos cloud computing devem ser facilitadores dos seguintes aspectos (Lutz Schubert, s.d.): Redução de custos É um dos primeiros objectivos para avançar para uma infraestrutura de cloud computing, adaptável às necessidades dos utilizadores e oferecendo redução de custos na sua manutenção e aquisição. As características da cloud que favorecem a redução de custos são a escalabilidade e pagamento por utilização (pay per use); Custo por utilização Uma característica fundamental do modelo cloud computing é relacionar os custos com a efectiva utilização dos recursos. O pagamento por utilização está intimamente relacionado com a qualidade do serviço suportado, onde os requisitos e as características solicitadas para o sistema com um determinado custo inerente, podem ser requisitados. Esta mudança estrutural no fornecimento de serviços é peça fundamental no interesse actual no paradigma da cloud computing, deslocalizando o investimento inicial para custos operacionais, beneficiando assim o desenvolvimento de pequenas empresas e negócios, pela facilidade na adopção de tecnologias e soluções inovadoras; Melhor time to market Característica essencial para pequenas empresas e negócios que desejam colocar os seus serviços e bens no mercado, sem necessidade de adquirir e instalar uma infraestrutura informática, melhorando assim a capacidade competitiva com empresas instaladas e de maior dimensão, que até são compelidas a disponibilizar os seus serviços de forma mais rápida para se manterem competitivas. Cloud computing, com a sua capacidade de fornecer fácil e rapidamente uma infraestrutura adaptada a cada negócio reduz o time to market; Retorno de Investimento (ROI) 11 Factor essencial para todos os investidores mesmo que nem sempre seja garantido. Um sistema de cloud computing deve permitir que os custos e esforço no seu investimento tenham retorno para ser comercialmente viável, directamente, trazendo mais clientes para o negócio, ou indirectamente, em benefícios por publicidade; 11 Return of Investiment 36
51 Alterar despesas de Capital (CAPEX) 12 em despesas operacionais (OPEX) 13 - Despesas de capital são sempre necessárias para instalar uma infraestrutura local. Com a deslocalização em regime de outsourcing dos recursos computacionais para cloud computing, uma organização está, actualmente, a ter despesas operacionais para garantir os recursos necessários, uma vez que os irá adquirir segundo as necessidades operacionais; Amigo de Ambiente 14 Relevante não apenas para reduzir os custos energéticos mas também a pegada ecológica. A emissão de carbono pelo hardware pode ser estimado e deve ser levado em conta e cloud computing permite a redução do consumo energético Escalabilidade O modelo cloud computing oferece aos seus clientes uma elevada escalabilidade, disponibilizando recursos em picos de utilização imprevistos, sejam temporários ou mais definitivos (Rountree & Castrillo, 2014), permitindo que a necessidade de capacidade adicional possa ser muito rapidamente respondida, em vez de terem que adquirir e configurar novo equipamento. Caso esses picos de utilização já não se verifiquem, esses recursos podem ser desligados da infraestrutura, não deixando para trás parque informático desnecessário. A escalabilidade permite ainda responder às necessidades de curto prazo ou projectos de curta duração. Um cliente cloud computing tem flexibilidade para a instalação de novos recursos sempre que tal se mostre necessário Actualizações Automáticas Os clientes de cloud computing têm sempre ao seu dispor a versão de software mais recente e actualizada, reduzindo o tempo necessário que os seus empregados TI dedicam a essa tarefa, 12 CAPEX - Capital expenditure, designa o montante de dinheiro dispendido na aquisição (ou introdução de melhorias) de bens de capital de uma determinada empresa, nomeadamente em equipamentos e instalações. 13 OPEX - Operacional expenditure, designa o montante de dinheiro utilizado para manter em operação os bens de capital de uma determinada empresa, nomeadamente em equipamentos e instalações. 14 Going green 37
52 libertando-os assim para outras mais importantes e focadas nas necessidades e objectivos da empresa (Scruggs, et al., 2011) Facilidade de Acesso Empregados, clientes e parceiros de negócio de uma empresa cliente do modelo cloud computing, podem com facilidade aceder à informação necessária, seja para consulta ou actualização. Esta facilidade de acesso proporciona uma melhoria na colaboração entre elementos de uma equipa geograficamente dispersa (Scruggs, et al., 2011). Outra razão na facilidade de acesso deve-se ao aumento dos dispositivos com capacidade de acesso a serviços cloud, permitindo a utilização de qualquer computador, pessoal ou empresarial, dispositivos móveis, tablets ou smart phones (Mather, et al., 2009). Desde que tenham acesso à internet são potenciais clientes de cloud computing, pois permitem um acesso ubíquo. Esta facilidade é um factor importante na tomada de decisão para clientes cloud computing Fiabilidade O fornecedor cloud, sendo este o seu negócio principal e face aos acordos assinados com os clientes e escala, têm as capacidades técnicas, pessoal especializado e sistemas para manter um serviço com qualidade e fiabilidade, seja a nível de equipamentos, de comunicações e de segurança, proporcionando boa fiabilidade dos serviços que disponibiliza aos seus clientes Rápido Desenvolvimento e Implementação Duas das cinco características principais de cloud computing que apontam para um rápido desenvolvimento e implementação são self-service a pedido e rápida elasticidade. Uma empresa em vez de adquirir instalar e configurar sistemas e computadores, despendendo todo o tempo necessário para essa tarefa, pode recorrer a um fornecedor cloud e ter ao seu dispor os sistemas necessários, instalados e configurados. Caso já tenha um contrato com um fornecedor e dependendo das suas cláusulas, o tempo necessário será de poucos minutos Acesso a Melhores Recursos Tecnológicos Algumas empresas, especialmente as de pequena dimensão, podem ter dificuldade no acesso a melhores recursos tecnológicos e na contratação de colaboradores com os conhecimentos necessários à sua implementação e manutenção. Movendo os seus serviços e informação para o modelo cloud, podem ter acesso aos mesmos recursos tecnológicos que uma empresa de maior dimensão ou com mais recursos financeiros (Scruggs, et al., 2011). Permite ainda 38
53 acesso uma a infraestrutura bem desenhada e dimensionada para as necessidades específicas uma vez que o negócio central de fornecedor de serviços cloud é em sistemas de tecnologias de informação (Ghosh & Hughes, 2011) 3.1. Desvantagens da Cloud Computing A cloud apresenta também algumas desvantagens, que são geralmente referidas como barreiras à adopção do modelo e a mais mencionada por todos é a segurança, que, dada a sua importância, será abordada mais à frente, no parágrafo 3.2. As desvantagens que podem ser apontadas ao modelo são: Maturidade Sendo uma tecnologia ainda recente, o mercado de fornecedores é emergente, com muitas e variadas ofertas, em que cada um reclama serem as mais inovadoras, quer em termos técnicos quer em termos financeiros. O que se verifica é que muitas dessas empresas emergentes são mais tarde adquiridas por empresas maiores e já estabelecidas (Ghosh & Hughes, 2011). Este aspecto levanta um sério problema aos clientes cloud porque a empresa adquirente passa a ser o fornecedor e pode não garantir o mesmo serviço acordado, assim como assegurar a interoperabilidade com os sistemas, dados e informação com a infraestrutura cloud desse fornecedor; SLA s A oferta de SLA s ainda é díspar entre fornecedores e alguns, de pequena dimensão, não dispondo mesmo desses acordos (Linthicum, 2009). Este problema dificulta a comparação entre fornecedores ou torna essa comparação mesmo impossível perante um leque de ofertas tão diferenciado. A normalização de SLA s que permite aos fornecedores a adaptação a um público-alvo mais alargado também é uma desvantagem, porque impede aos clientes de acederem a SLA s negociados ou se negociados o sejam a custos mais elevados; Definição dos componentes A definição das componentes cloud ainda não é clara, dificultando a selecção por comparação de um fornecedor cloud (Ghosh & Hughes, 2011); Monitorização Os fornecedores cloud nem sempre disponibilizam ferramentas de monitorização ou a sua funcionalidade é restricta (Sosinsky, 2011), limitando a visibilidade dos clientes cloud, no que respeita a incidentes ou tentativas de intrusão na infraestrutura do fornecedor; 39
54 Comunicações Se as comunicações não forem bem dimensionadas para picos de transferências, mover grandes quantidades de informação para a cloud pode originar paragens prolongadas para os utilizadores Riscos de Segurança Para uma migração para o modelo cloud torna-se imperativo um perfeito conhecimento dos riscos de segurança inerentes. Existe uma multiplicidade de formas de analisar os riscos de segurança do modelo cloud computing, mas estes podem ser divididos em três classes distintas (Chow, et al., 2009): Ameaças de segurança tradicionais referem-se aos riscos de qualquer sistema de informação ligado à internet acrescido de ameaças inerentes do modelo cloud. O impacto das ameaças tradicionais é claramente amplificado devido, quer aos múltiplos recursos passíveis de serem afectados, quer ao número de entidades que podem ser afectadas. A área nebulosa sobre as responsabilidades, entre clientes e fornecedores, para a identificação da causa de determinado incidente, acrescenta preocupações de segurança ao modelo. As ameaças tradicionais começam na infraestrutura do cliente, devendo este aplicar os meios de segurança necessários aos sistemas que o liguem aos serviços cloud, tarefa por vezes complicada quando parte da infraestrutura se encontra no exterior à sua firewall; Ameaças de segurança à disponibilidade dos sistemas Falhas de acesso a serviços e informação de forma grave e prolongada. Estas podem ocorrer por catástrofes naturais, falhas de sistemas, cortes de energia, falha de comunicações ou mesmo por ataques aos sistemas do fornecedor. Medidas de segurança que mitiguem estas ameaças devem existir e estarem implementadas pelo fornecedor. Ameaças de terceiros O controlo por terceiros de informação sensível ou confidencial levantam preocupações nos clientes. De facto existem várias ameaças dentro da própria infraestrutura do fornecedor, como a coexistência de vários clientes, que podem ser concorrentes de negócio potenciando o perigo de exposição ou fuga de informação. O acesso à informação e sistemas por funcionários da empresa fornecedora de serviços também levanta sérias preocupações de segurança aos clientes. 40
55 Para uma melhor avaliação do risco, devem ser efectuadas as seguintes análises (Sosinsky, 2011): Determinar claramente quais os recursos de dados, serviços ou aplicações a migrar para cloud computing; Determinar a exposição dos recursos ao risco; Determinar quais os riscos associados a um determinado modelo de serviço cloud; Avaliar o sistema do fornecedor ou fornecedores de serviços cloud escolhidos, compreender como a informação irá ser transferida, onde irá ser armazenada e avaliar as comunicações entre a organização e o fornecedor. Apesar de parte do controlo em modelos cloud passarem para a esfera do fornecedor de serviços, ainda assim, o cliente cloud deve ter em conta a sua responsabilidade pelo uso dos serviços, mantendo um conhecimento dos riscos envolvidos, ponderar alternativas, estabelecer prioridades e possíveis alterações ao nível da segurança e privacidade, na sua organização. Os riscos mais comuns associados à cloud computing a ter em consideração por qualquer organização que pretende adoptar o paradigma de cloud computing são (Perilli, et al., 2009): Perda de governança Ao optar por modelos cloud, o cliente necessariamente cede o controlo da sua informação, dados e sistemas ao fornecedor de serviços. Os SLA s entre ambas as partes podem não comprometer suficientemente o fornecedor a disponibilizar serviços ou controlos de segurança que reduzam ou eliminem as preocupações dos clientes, aumentado o seu sentimento de insegurança face ao modelo; Fornecedor Lock-In Dependência dos serviços proprietários de um determinado fornecedor de serviços cloud, origina a que um cliente tenha grande dificuldade na migração para outro fornecedor. Serviços que não suportem a portabilidade de informação e serviços para outro fornecedor, aumentam o risco de indisponibilidade. Fornecedor Lock-Out Similar ao abordado no ponto anterior, mas nesta situação o cliente é impedido de aceder à informação, seja por falência do fornecedor ou por outras causas. Este risco pode tornar a informação e recursos vitais para o negócio do cliente indisponíveis; 41
56 Compliance e riscos legais Investimentos feitos pelas empresas cliente para obter certificações podem ser postos em causa, caso o fornecedor de serviços cloud não possa fazer evidência que também as possui ou que não permita uma auditoria por parte do cliente à sua infraestrutura. É da responsabilidade do cliente certificar-se que o fornecedor detém as certificações necessárias e ainda, ter conhecimento da partilha de responsabilidades de segurança entre o fornecedor e o cliente; Vulnerabilidades na gestão dos interfaces Estes interfaces são normalmente utilizados pelo cliente com acesso através da internet e permitem acesso a mais informação e recursos que os fornecedores de recursos tradicionais, aumentado o risco, especialmente se usados em conjunto com acesso remoto e existam vulnerabilidades no browser ou nas comunicações utilizadas; Protecção de Informação Cloud computing coloca vários riscos a clientes e fornecedores. O mais relevante é a exposição ou fuga de informação sensível, mas também a sua perda ou indisponibilidade. Para o cliente pode ser difícil avaliar as práticas e políticas no tratamento e manuseamento da informação pelo fornecedor. Este problema aumenta quando se utilizam transferências de informação entre diversos modelos de cloud; Eliminação de informação de forma insegura ou incompleta Pedidos do cliente cloud ao fornecedor para eliminar recursos ou informação, por exemplo, no fim do contrato ou por mudança de fornecedor, pode não ser efectuada da forma mais apropriada para elimina-la de forma completa e eficaz. Em cloud computing, a eliminação da informação pode por vezes ser difícil pela redundância inerente ao modelo, ou porque os dispositivos onde essa informação reside também são usados por outros clientes, dificultando a efectiva eliminação da informação; Comportamento malicioso de funcionários Danos causados intencionalmente por funcionários do fornecedor, que podem ser extensos, pelas permissões de acesso e autorizações inerentes às suas funções. Este risco é abrangente ao modelo cloud computing, uma vez que tanto pode ocorrer dentro da organização do cliente, como na organização do fornecedor; Tratamento de incidentes A detecção, informação e subsequente gestão de falhas de segurança é uma preocupação para os clientes, que depositam a sua confiança nos fornecedores para o seu correcto tratamento; 42
57 Ambiguidade de responsabilidades Uma vez que os serviços de cloud computing abrangem ambas as organizações, cliente e fornecedor, a responsabilidade nas áreas de segurança também são transversais às duas, potenciando que áreas de defesa sejam deixadas sem supervisão caso não sejam claramente definidas as responsabilidades sobre todas a áreas. Esta partilha de responsabilidades é diferenciada consoante o modelo cloud adoptado; Falha de isolamento Multi-tenancy e partilha de recursos da cloud, são características mais abrangentes no modelo de desenvolvimento de cloud pública. Uma falha nos mecanismos de separação e isolamento de recursos e informação dos diversos clientes cloud 15 pode levar à perda de informação ou à sua exposição indevida; Indisponibilidade do serviço Esta indisponibilidade pode ser causada por uma multiplicidade de razões, deste a falha de equipamento, software ou comunicações entre o cliente e fornecedor, etc Responsabilidade em cada Modelo de Serviço As responsabilidades sobre os riscos e segurança em cloud computing, estão sempre intimamente ligados com o modelo de serviço escolhido, SaaS, PaaS ou IaaS, aumentando o grau de responsabilidades do cliente na gestão da segurança e riscos associados à medida que este se move do modelo SaaS para PaaS e deste para IaaS. 15 tenants 43
58 Figura 12: Controle sobre a segurança em SaaS, PaaS e IaaS (Winkler, 2011) As responsabilidades entre os fornecedores e clientes variam de acordo com o modelo serviço. Nas tabelas seguintes sumarizam-se as responsabilidades de cada em cada modelo. Tabela 1: Responsabilidades no Modelo SaaS Cliente Cloud Fornecedor Cloud Manutenção dos sistemas de gestão de identidades; Gestão dos sistemas de identidades; Gestão da plataforma de autenticação. Infraestrutura fisíca de suporte, desde as instalações aos equipamentos de suporte; Equipamentos da infraestrutura, servidores, equipamento de rede, etc.; Gestão das actualizações e procedimentos de segurança; Configuração dos sistemas de segurança; Sistemas de monitorização; Manutenção das plataformas de segurança; Registo de eventos e monitorização de segurança. 44
59 Tabela 2: Responsabilidades no Modelo PaaS Cliente Cloud Fornecedor Cloud Assegurar compliance na protecção de dados e informação, tratados e processados; Manutenção dos sistemas de gestão de identidades; Gestão dos sistemas de identidades; Gestão da plataforma de autenticação. Infraestrutura fisíca de suporte, desde as instalações aos equipamentos de suporte; Equipamentos da infraestrutura, servidores, equipamento de rede, etc.; Gestão das actualizações e procedimentos de segurança; Configuração dos sistemas de segurança; Sistemas de monitorização; Manutenção das plataformas de segurança; Registo de eventos e monitorização de segurança. Tabela 3: Responsabilidades no Modelo IaaS Cliente Cloud Fornecedor Cloud Manutenção dos sistemas de gestão de identidades; Gestão dos sistemas de identidades; Gestão da plataforma de autenticação; Gestão do SO virtual, actualizações e configurações de segurança; Configuração dos sistemas de segurança; Monitorização dos SO virtuais; Manutenção das plataformas de segurança; Registo de eventos e monitorização de segurança. Infraestrutura fisíca de suporte, desde as instalações aos equipamentos de suporte; Equipamentos da infraestrutura, servidores, equipamento de rede, etc.; Equipamentos de gestão 45
60 3.4. Risco Para uma análise de segurança, o conceito de risco surge em primeira linha. Numa definição muito redutora, risco 16 é a possibilidade de um acontecimento futuro e incerto; perigo. O risco alia-se à incerteza, que define o nosso conhecimento sobre eventos futuros e o seu desfecho (M.Talabis, et al., 2013). Por outro lado, risco pode ser definido pela quantificação ou medida da incerteza permitindo dessa forma classificar o risco, ou seja, fazer uma avaliação do risco. Para a definição de risco ser completa, o risco envolve as seguintes componentes: Evento - Acaso ou situação que é possível mas não é certa e que no contexto da avaliação de risco é sempre no futuro e ocorre por acção ou inacção. Em termos de segurança a sua ocorrência tem sempre uma conotação negativa. Activos São os alvos da ocorrência, directa ou indirecta; Resultado É o impacto do evento sobre os activos da organização; Probabilidade É a quantificação de determinado evento acontecer. Evento Activos Risco Resultado Probabilidade Figura 13: Componentes do Risco Avaliação do Risco A avaliação do risco é definido pela probabilidade da concretização de uma ameaça e determinando o resultado desse evento medindo o impacto negativo sobre os sistemas, dados ou informação. A Tabela 4 mostra como a correlação entre a probabilidade e o impacto pode ser efectuada
61 Tabela 4: Análise de Risco. Adaptado de ISO/IEC 27005:2008 Probabilidade Muito Baixa Baixa Média Elevada Muito Elevada Muito Baixo Baixo Impacto Médio Elevado Muito elevado A Avaliação do risco envolve a identificação e a quantificação dos riscos de perda de confidencialidade, de integridade e de disponibilidade (M.Talabis, et al., 2013) e deve ser efectuada para cada processo, informação e sistemas que se encontrem em consideração num projecto de migração para a cloud Segurança em Ambientes Cloud A segurança em ambientes cloud deve alinhar fornecedores e clientes com um objectivo comum, salientando a capacidades e requisitos para um padrão que assegure a interoperabilidade, a facilidade de integração e a portabilidade. A relação entre estes factores deve ser tratada de forma a criar controlos de segurança e minimizar as preocupações na utilização de serviços cloud. As organizações com pretensões na migração dos seus serviços e informação para a cloud devem ter, desde do início, noção dos seguintes conceitos (CSA, 2011): Completa noção de como os serviços cloud são desenvolvidos e de que são frequentemente disponibilizados de locais muito diferenciados, originando confusões sobre a localização da informação e serviços; A forma como os serviços cloud são acedidos é muitas vezes descrito em relação ao perímetro de segurança de uma organização, habitualmente bem definido por algum equipamento de segurança, como por exemplo uma firewall. Enquanto contínua a ser da maior importância compreender a localização das fronteiras de segurança em 47
62 cloud computing, esta noção não e por vezes bem compreendida ou tratada correctamente por muitas organizações; A deslocalização e erosão das fronteiras de segurança já ocorrem nos dias de hoje, mesmo sem uma infraestrutura cloud computing, no entanto, esta veio acentuar e acelerar esse problema. Os controlos de segurança anteriores usados não estão adequados com à ubiquidade no acesso à informação e serviços proporcionada pela infraestrutura cloud computing, tornando necessário aplicar novos controlos que se adequem ao conceito cloud; Os controlos de segurança em cloud computing não diferem muito dos controlos de segurança nas infraestruturas mais tradicionais, contudo, devido aos modelos de serviço, modelos operacionais e às tecnologias empregadas, este pode apresentar diferentes riscos para uma organização, quando comparado com os modelos tradicionais (CSA, 2011). Como referido anteriormente, a segurança é uma das principais preocupações das organizações e clientes quando ponderam o uso de modelos cloud. De facto, muitas análises e inquéritos de mercado revelam que a segurança é um dos maiores obstáculos à adopção do modelo (Anon., 2012) (Mather, et al., 2009), tornando-se imperativo ser correctamente tratado para criar um ambiente de confiança que facilite a migração para uma infraestrutura de cloud computing. À medida que novos clientes aderem ao paradigma e movem as suas aplicações e informação para um fornecedor de serviços cloud, o nível de percepção de segurança deve ser igual ou superior ao que tinham na arquitectura tradicional, mesmo quando a informação é acedida através de redes inseguras como internet e com reduzido controlo onde a mesma é guardada. A postura de segurança de uma organização é sempre caracterizada pela efectidade, pela maturidade e pela complitude dos riscos ajustados aos controlos de segurança e à sua implementação. Estes controlos devem abranger todas as camadas, desde a segurança fisica das instalações, à segurança da infraestrtura e dos sistemas passando pelas aplicações neles instaladas, assim como às pessoas e aos processos que com eles operam e interagem, com separação de responsabilidades, de acessos e de processos de autenticação. Os objectivos de segurança são factores chave na decisão para a migração de serviços e informação para uma plataforma cloud computing, pelo que as organizações devem proceder a uma análise de risco na avaliação às opções de segurança e privacidade disponibilizadas pelo fornecedor de serviços (Jansen & Grance, 2011). Para minimizar os custos e maximizar a efectividade, as organizações devem considerar a segurança e a privacidade durante todo a ciclo do processo, com início logo na fase de planeamento. Frameworks de controlo ainda não se encontram completamente adoptadas em 48
63 ambientes cloud, ainda que os existentes, como COBIT, ITIL e ISO e ISO sejam considerados sufucientes e um bom ponto de partida (Halpert, 2011). A ISO encontra-se actualmente a desenvlover novas normas, nomeadamente a norma ISO/IEC , para a protecção da Personal Identifiable Information (PII) em clouds públicas pelos fornecedores de serviços e a norma ISO/IEC , com recomendações para a segurança da informação e controlos de segurança em cloud computing. Existem ainda organizações que estudam e emitem relatórios com recomendações e programas de compliance e de segurança em cloud computing como a CSA, NIST, ISACA e ENISA. Com o objectivo de mitigar e reduzir o risco, os clientes devem avaliar e gerir a segurança e privacidade do ambiente cloud. Para o atingir devem recorrer à implementação de controlos em todos os serviços e a processos que assegurem a observância e cumprimento das boas regras e postura de segurança de todos os intevenientes. Assim as organizações na adopção do modelo devem observar os seguintes passos: Processos de governança, risco e compliance; Auditar os processos de negócio e operacionais; Gestão de pessoas, processos e identidades; Assegurar a protecção da informação; Aplicar políticas de privacidade; Avaliar as disposições de segurança para as aplicações em cloud; Assegurar que a infraestrutura e ligações de rede são seguras; Avaliar os controlos de segurança da infraestrutura e estrutura; Gerir controlos de segurança nos contratos com o fornecedor; Revogar os serviços com um fornecedor
64 Processos de Governança, Gestão de Risco e Compliance A maior parte das organizações têm establecidas políticas de segurança e compliance para a protecção do seu sistema de informação e dos dados nele armazenados, tratados e processados. Estas políticas e procedimentos são criados com base numa análise de risco efectuada na organização, após considerado o impacto no caso dos seus sistemas de informação serem comprometidos. Uma framework de controlos e procedimentos é criada e posta em prática servindo de referência à execução e validação da compliance existente numa organização. Estes princípios, políticas, plano de segurança e processos de melhoria contínua representam para uma organização a governança da segurança, gestão do risco e modelo de compliance. Para mitigar os desafios de segurança no modelo, para além do já referido, o cliente deve solicitar ao fornecedor de serviços provas de que estes também aderem aos controlos de segurança. Isso pode ser demonstrado através de certificações por entidades independentes. Existe um número de certificações que são úteis em serviços cloud computing, dependendo do modelo de serviço fornecido e da localização do fornecedor Compliance Compliance é a responsabilidade de uma organização em operar de acordo com as leis, regulamentos, especificações e padrões do meio onde se insere. Cada país tem as suas leis e regulamentos a nível de segurança e privacidade, tornando potencialmente difícil uma organização ser compliant dentro do seu espaço de acção quando opta por uma solução em cloud computing (Jansen & Grance, 2011). Quando uma organização migra os seus sistemas para a cloud há uma incerteza sobre a localização exacta onde a sua informação será armazenada ou onde os seus processos são efectivamente executados. Por outro lado, uma das características do modelo cloud é a redundância e assim replicando a informação por vários servidores e centro de dados onde os fornecedores operem. Esta informação nem sempre é disponibilizada aos clientes, devendo, no entanto, o fornecedor facultar toda a cooperação com o cliente sobre os requisitos deste acerca da localização da sua informação e sistemas (Krutz & Vines, 2010) Governança Governança é o controlo e fiscalização de uma organização sobre as politícas, procedimentos e normas para o desenvolvimento de aplicações e aquizição de serviços de sistemas de informação, assim como o desenho, implementação, teste, utilização e monitorização dos serviços contratados. Apesar de cloud computing simplificar a aquisição de novos serviços, 50
65 não significa obrigatoriamente menor necessidade de governança (Jansen & Grance, 2011). A facilidade de aquisição de novos serviços e sistemas em cloud computing pode fomentar que certas áreas de uma organização não observem as regras e politícas de segurança. Para mitigar este risco, devem ser disponibilizados mecanismos de auditoria e ferramentas de verificação para validar os serviços e reforçar a observância das políticas de segurança da organização. Existem muitos modelos de governança, no entanto todos eles obedecem a cinco princípios básicos (CSA, 2011): Auditar os fornecedores de serviços; Equipa responsável pela gestão de processos; Responsabilidade corporativa e compliance; Transparência financeira e divulgação de informação; Estrutura de propriedade da informação e controlo de acessos. A governança numa organização tem como objectivos principais (NIST, 2011): Estabelecer uma direcção estratégica; Assegurar que os objectivos organizacionais e de negócio são atingidos; Confirmar que os riscos são geridos apropriadamente; Verificar se os recursos são usados correctamente Gestão do Risco Até há alguns anos, firewalls e software de antivírus era tudo o que a esmagadora maioria das organizações necessitavam para mitigar o risco. Nos anos mais recentes, o panorama das ameaças mudou consideravelmente (Davis, et al., 2011). As ameaças, nos dias de hoje são bastante mais vastas. Desde ameaças internas numa organização, novos vírus e malware que surgem mais frequentemente, piratas informáticos com motivos politícos ou apenas para mostrarem as suas capacidades, passando por novas normas e legislação governamental. Tudo combinado torna imperativo a existência de uma framework de gestão de risco. Numa organização, a gestão do risco requer um conhecimento abrangente dos processos de negócio, das ameças potenciais e das vulnerabilidades que possam ser exploradas junto com 51
66 uma avaliação da probabilidade da ameaça e seu impacto, caso esta se concretize (Josyula, et al., 2012). Gestão de risco é um procedimento para identificar e avaliar o risco dos processos, dos activos e pessoas na sua interacção com os diversos sistemas operacionais, tomando as medidas necessárias para o reduzir para um valor aceitável. Uma framework de gestão de risco numa organização inclui os métodos e processos para gestão de riscos e aproveitamento de oportunidades, mantendo o foco no négocio. Em ambientes cloud computing a gestão escolhe uma resposta estratégica aos riscos identificados e analizados que podem passar por (CSA, 2011): Evitar Passa por abandonar as actividades sujeitas ao risco; Reduzir Tomar medidas que reduzam a probabilidade do risco ocorrer ou minimizar o seu impacto; Transferir ou segurar Transferência, total ou parcialmente do risco, assegurando compensações monetárias caso este aconteça; Aceitar Não são tomadas medidas e o risco é aceite mediante uma decisão de custo/benefício. Como na generalidade das metedologias, a gestão do risco, quando aplicada de forma apropriada, ganha caracteristicas de ciclo, proporcionando uma melhoria contínua e ajustável às alterações dos processos. A gestão de risco é composta por cinco fases (Davis, et al., 2011): 52
67 Fase 1 Identificar os activos dos sistemas de informação Fase 5 Gerir o risco residual Gestão do Risco Fase 2 Quantificar e qualificar as ameaças Fase 4 Corrigir falhas de controlo Fase 3 Avaliar as vulnerabilidades Figura 14: Framework de gestão do risco. Adaptado (Davis, et al., 2011) Cada fase é compreendida por: Fase 1 - Identificar os activos dos sistemas de informação: o o Criar uma base de controlo de risco; Reavaliar o risco. Fase 2 - Quantificar e qualificar as ameaças: o o o Definir valores de criticidade da informação; Identificar as funções de negócio; Mapear processos de informação; 53
68 o o Identificar activos do sistema de informação; Atribuir valores de criticidade aos activos. Fase 3 - Avaliar as vulnerabilidades: o o o o o Avaliar as ameaças ao negócio; Identificar ameaças técnicas físicas e administrativas; Quantificar a probabilidade de impacto da ameaça; Procurar fraquezas nos fluxos dos processos; Identificar ameaças nas componentes dos processos; Fase 4 - Corrigir falhas de controlo: o o o o o Identificar os controlos existentes em relação às ameaças; Determinar lacunas nas componentes do processo; Alterar as falhas dos controlos em processos e posteriormente em funções de negócio; Categorizar falhas nos controlos por severidade; Atribuir classificações de risco; Fase 5 - Gerir o risco residual: o o o o Selecção de controlos; Implementar Controlos; Validar novos controlos; Recalcular classificações de risco; 54
69 Auditar os Processos de Negócio e Operacionais As organizações compreendem a importância em auditar a conformidade dos seus sistemas e se estes se encontram alinhados com as políticas da organização, as leis, nacionais ou internacionais, regulamentos, especificações e padrões. Com os desafios colocados com a migração de serviços e informação para ambientes cloud computing, os clientes devem solicitar aos fornecedores relatórios de auditoria realizados por entidades independentes, que certifiquem que eles se encontram em compliace com essas directivas e regulamentos. Antes da escolha recair sobre determinado fornecedor, um cliente deve ter toda a informação sobre os centros de dados e práticas de segurança deste (Scruggs, et al., 2011). O acesso pleno à informação de auditoria é essencial para determinar os termos dos contratos e SLA s. Alinhamento com a segurança é um elemento significativo de qualquer compliance framework. Existem três áreas onde metedologias de segurança devem ser observadas em ambientes cloud e que são de particular interesse para clientes e auditores: Compreender o ambiente interno de controlo de um fornecedor, incluindo riscos, controlos de segurança e aspectos de governança, sempre que o ambiente do cliente interagir com serviços cloud; Acesso ao processo de auditoria, incluindo fluxo e autorização quando esse processo abrange os serviços cloud; Acesso a ferramentas de gestão e controlo dos serviços cloud, disponibilizados pelos fornecedores aos clientes e informação sobre a segurança das mesmas Compreender o Ambiente Interno de um Fornecedor Cloud A utilização de serviços em ambientes cloud levanta a necessidade de auditoria às actividades dos empregados do fornecedor, de forma a verificar que os controlos de segurança vão de encontro às necessidades do cliente. Devem ser aplicados controlos que permitam: Assegurar o isolamento das aplicações e informação do cliente nos ambientes partilhados entre múltiplos clientes; Promover a protecção dos activos de acesso não autorizado por pessoas da organização do fornecedor. 55
70 Acesso ao Processo de Auditoria Os clientes de serviços cloud têm a expectativa legítima de que os seus serviços e informação irão manter a integridade e serão devidamente protegidos (Winkler, 2011). Uma auditoria à segurança de um fornecedor de serviços é um aspecto essencial nas considerações de segurança do cliente quando pretende migrar serviços e informação para a infraestrutura do fornecedor. As auditorias devem ser afectuadas por pessoas ou entidades independentes e com conhecimento especializado. É da responsabilidade do cliente afectuar auditorias regulares, durante o período de vigência do acordo entre ambos e, dessa forma, certificar que os serviços continuam a ser prestados dentro dos parâmetros acordados (Scruggs, et al., 2011). As políticas de segurança de um fornecedor de serviços, certamente incluem a proibição de fornecer informação sobre certas áreas da sua infraestrutura, nomeadamente, detalhes técnicos de segurança, processos ou alguma informação que coloque em risco dados e privacidade dos seus clientes. Ainda assim, devem fornecer informação suficiente a um cliente que permita que estes tomem decisões informadas no processo de escolha de um fornecedor, ou para implementar medidas de segurança adicionais, caso se mostre necessário. Estas informações devem incluir (Winkler, 2011): Políticas de segurança Facultar detalhes suficientes das normas e políticas de segurança, que permitam aos clientes formar uma expectativa de segurança e adequar o seu comportamento na utilização dos serviços; Implementação de segurança e procedimentos Um fornecedor deve detalhar suficientemente as implementações de segurança e procedimentos, de modo a permitir ao cliente formar uma opinião de confiança sobre a segurança da sua informação e serviços prestados e processados na infraestrutura do fornecedor. Esta informação não deve ser de teor puramente técnico, mas sim tão abrangente que permita ao cliente aferir que o fornecedor compreende a necessidade de segurança, se está de facto implementada e se este possui a capacidade de a manter em todos os aspectos de operação; Comunicações de serviço Comunicações de segurança e disponibilidade de serviços devem ser fornecidas aos clientes para que estes tomem as medidas necessárias e elaborem planos de contingência. 56
71 Acesso a Ferramentas de Gestão e Controlo Para além dos controlos aplicáveis aos serviços cloud, os fornecedores devem também facultar aos clientes ferramentas de gestão e de monitorização das suas aplicações e informação. Essas ferramentas incluem: Catálogos de serviços; Serviços de subscrição; Processos de pagamento; Registos de eventos operacionais; Informação actualizada sobre utilização de serviços; Ferramentas de configuração de serviços e gestão de utilizadores Gestão de Pessoas, Processos e Identidades As organizações têm habitualmente que criar e gerir muitos colaboradores, cada um com a sua função que acedem a recursos, a serviços e a aplicações. Os fornecedores devem permitir aos seus clientes assignar e gerir níveis de acesso diferenciado, de acordo com as suas políticas de segurança. Estas funções e permissões de acesso são aplicadas a cada recurso, serviço ou aplicações. Os clientes, por seu lado, devem assegurar, que o fornecedor de serviços tem processos e funcionalidades de controlo de acesso às aplicações e informação residentes na sua infraestrutura. A gestão de identidades é um mecanismo fundamental no controlo de acessos em ambientes cloud, prevenindo o acesso não autorizado na manutenção das funções dos utilizadores. A implementação de um sistema de gestão de identidades deve incluir (Krutz & Vines, 2010): Estabelecer uma base de dados de identidades e credenciais; Gerir os direitos de acesso dos utilizadores; Cumprimento das políticas de segurança; Desenvolvimento da capacidade de criar, modificar e apagar contas de acesso; 57
72 Configurar e monitorizar os acessos aos recursos; Criar um procedimento para remover direitos de acesso; Dar acções de formação sobre a correcta utilização dos procedimentos. Este sistema de gestão de identidades deve permitir um acesso simples e robusto para serviços e utilizadores, proporcionando o aprovisionamento e gestão de identidades únicas para cada utilizador ou serviço. Um problema recorrente para as organizações que utilizem serviços cloud é a dificuldade em prolongar a identificação e autenticação da sua estrutura para a estrutura cloud do fornecedor. Em alternativa, a utilização de dois sistemas de identificação e autenticação, uma para os sistemas internos e outra para os sistemas cloud externos, é fonte de complicações e dificuldades de gestão no decurso do tempo. A Identity Federation (federação de identidade), popularizada com a introdução do Service Oriented Architectures (SOA), é uma solução (Jansen & Grance, 2011). Federação de identidade proporciona a uma organização cliente de serviços cloud e a uma organização fornecedora de serviços cloud, confiar e partilhar identidades e respectivos atributos transversalmente às duas infraestruturas. Um factor importante numa organização para efectivamente gerir identidades e controlo de acessos em ambientes cloud computing é a presença de um sistema de gestão de federação de identidades (Mather, et al., 2009). Esta capacidade é da maior importância para permitir a um cliente cloud recorrer ao single signon nos seus sistemas, internos e externos. Genéricamente os fornecedores cloud devem ainda suporte: Gestão de federação de identidade e gestão de identidades externa - Organizações que consumam recursos em ambientes cloud e que, na maioria dos casos, já dispõem de uma base de dados de utilizadores nos seus sistemas, que irão pretender utilizar sem necessidade de as recriar quando recorram a serviços de terceiros; Aprovisionamento de identidades e delegação Um fornecedor de serviços cloud, deve delegar aos seus clientes a gestão e administração de utilizadores; Single Sign-On e Single Sign-Off Um cliente cloud pode recorrer à federação de identidades para todas a aplicações, internas de externas, que permitam o single signon e single sign-off, assegurando que as sessões de utilizador terminem graciosa e apropriadamente; 58
73 Identidade e Auditoria de acessos Deve ser permitido aos clientes cloud auditarem os registos de acessos a serviços e aplicações, para sua segurança e compliance com políticas, leis, normas e regulamentos; Processos de autenticação robustos Para acesso a informação sensível, um fornecedor cloud deve suportar autenticação robusta, multi-factor ou mesmo biométrica; Funções, permissões de acesso e gestão de políticas Os clientes cloud devem descrever e fazer cumprir as suas políticas de segurança, funções de utilizadores, grupos e permissões de acesso às suas aplicações e informação, respeitando os requisitos legais, nacionais ou internacionais Protecção de Dados e Informação Para todas as organizações os dados são uma das priopridades do ponto de vista da segurança. Face ao modelo distribuido e redundante dos ambientes cloud computing e às responsabilidades partilhadas, entre cliente e fornecedor, esta realidade ganha ainda mais importância, para todos os modelos em cloud computing. A data life cycle (ciclo de dados), em ambientes cloud é composto por seis fases: Criar Guardar Utilizar Partilhar Arquivar Destruir Classificação Assignar direitos Controlos de Acesso Encriptação Gestão de direitos Monitorizar actividade Segurança de aplicações Controlos lógicos Encriptação Controlos lógicos Encriptação Gestão de Activos Destruição segura Figura 15: Ciclo de dados 59
74 Nos modelos de cloud computing existem essencialmente duas formas de dados (Scruggs, et al., 2011): Dados em repouso Dados gravados em qualquer meio de suporte magnético ou outro que se encontrem na infraestrutura do fornecedor de serviços; Dados em trânsito Dados manuseados ou transferidos entre dois pontos, dentro da infraestrutura do fornecedor ou entre este e a infraestrutura do cliente. Essencialmente, as questões relacionadas com o risco de dados ou informação, em ambientes cloud têm origem em: Risco de roubo ou divulgação de informação; Risco de alteração maliciosa de dados (tampering) ou acesso não autorizado à informação; Risco de perda ou indisponibilidade da informação A norma ISO/IEC 27001: Information technology - Security techniques - Information security management systems - Requirements, classifica a informação de acordo com categorias de importância e sensibilidade, conforme a tabela seguinte: Tabela 5: ISO/IEC 27001: Information technology Categoria dos dados Descrição Não classificados e públicos Os dados não são confidenciais e podem ser tornados públicos sem implicações para a empresa. Perda de disponibilidade por inacessibilidade dos sistemas é um risco aceitável. A integridade é importante mas não vital. Proprietária A informação é restrita a acessos internos sujeitos a aprovação e protegida de acessos externos. Acesso não autorizado comprometendo a eficácia operacional e causar perdas financeiras consideráveis, ganhos à entidades concorrênciais ou causar perda de confiança. A integridade dos dados é um factor fundamental. 60
75 Categoria dos dados Dados confidenciais de clientes Dados confidenciais da empresa Descrição A dados recebidos de clientes em qualquer suporte para processamento em produção pela empresa. A cópia original desses dados não pode ser alterada sem a expressa autorização do cliente. Níveis mais elevados de integridade, confidencialidade e o acesso restrito é fundamental. Dados recolhidos e utilizados pela empresa nos processos de negócio, para empregar colaboradores, para realizar pedidos de clientes e gerir todos os aspectos financeiros. O acesso a estes dados é muito restrito no seio da empresa. Níveis muito elevados de integridade, confidencialidade e acesso restrito Controlos de Segurança de Dados em Ambientes Cloud Como já referido anteriormente os controlos de segurança dependem sempre, do modelo de serviço a que se aplicam. Num modelo de serviço IaaS, a responsabilidade dos controlos de segurança estão mais no lado dos consumidores cloud por exemplo a responsabilidade da encriptação da informação, já num modelo de serviço SaaS, a responsabilidade está do lado do fornecedor cloud, uma vez que, quer os dados quer as aplicações não são visíveis ou controláveis pelo consumidor cloud Aplicar Confidencialidade, Integridade e Disponibilidade Os princípios da confidencialidade, integridadede e disponibilidade, são aplicáveis ao manuseamento de dados, através da aplicação de políticas e procedimentos que reflitam a classificação dos dados. Os dados confidenciais devem ser encriptados, seja quando em trânsito ou em repouso. A encriptação dos dados é aplicado em três áreas distintas ou estados (Davis, et al., 2011): Dados em trânsito através da rede, encriptados por protocolos seguros, por exemplo, Secure Sockets Layer (SSL); Dados em repouso, encriptados através de algoritmos, por exemplo, Advanced Encription Standard (AES); 61
76 Dados em utilização, que descreve o processamento dos dados pelas aplicações. Em ambientes cloud devem ser utilizadas formas seguras de programação das aplicações. A Open Security Architecture 19 (OSA), disponibiliza modelos de frameworks de programação segura. A integridade dos dados deve ser validada através do uso de digests ou algoritmos de secure hash, aliados à duplicação de dados, técnicas de redundância e cópias de segurança (Mell, Peter; Grance, Timothy; NIST, 2011). Figura 16: Redundância e disponibilidade (Winkler, 2011) Para providenciar disponibilidade da informação e sistemas, devem ser utilizadas cópias de segurança e sistemas redundantes e resilientes, assim como técnicas para mitigar formas de ataques informáticos, como, por exemplo Denial-Of-Service (DoS) Considerar Todas a Formas de Dados As empresas estão a aumentar a quantidade de dados não estruturados, isto é, dados heterogénios e variáveis sob os mais variados formatos, incluindo texto, documentos, imagem, video, etc (Intel Corporation, 2012). Esta informação pode ter um teor confidencial necessitando de tratamento específico, como como por exemplo mascarar assinaturas e informação pessoal. Para protecção da informação, os dados estruturados em ambientes cloud e que se encontrem armazenados em base de dados com informação classificada como confidencial, devem ser segmentados em tabelas separadas com os dados encriptados,
77 acesso controlado e restrito. As base de dados podem conter a informação mais sensível de uma empresa (Davis, et al., 2011) Catálogo de Activos Um aspecto chave na segurança da informação é a implementação de um catálogo de activos de dados que é utilizado para guardar informação acerca de todos os activos de dados e informação de uma empresa (DHS, 2010). Todos os activos de uma empresa devem ser identificados e classicados em termos de sensibiliade para o negócio, especificando o owner (dono) e responsável desses activos, assim como a localização, a sua utilização e finalidade. As relações existentes entre estes activos devem também ser documentadas Requisitos de Privacidade A privacidade está geralmente abrangida por leis e regulamentos relacionados com a recolha, guarda e utilização de informação pessoal, Personal Identifiable Information (PII), o que implica limitações de uso e acesso, com os requisitos associados de etiquetação, salvaguarda segura da informação e acesso apenas quando autorizado. Em ambientes cloud, devem ser estabelecidos controlos apropriados para protecção desta informação. A norma ISO/IEC Information technology - Security techniques - Code of Practice for PII Protection in Public Clouds Acting as PII Processors, providência aos fornecedores cloud orientação para os controlos de segurança necessários na protecção da privacidade da PII dos seus clientes Controlo de Identidades e Gestão de Acessos Para além do sistema de gestão de identidades, deve ser estabelecido um controlo de identidades e gestão de acessos que deve ser acompanhada com autorização apropriada para todos os utilizadores no acesso a informação confidencial. Juntamente com esta necessidade, surge a gravação de eventos relacionados com segurança e acessos a informação confidencial, permitindo posteriormente a investigação, caso ocorram acessos não autorizados ou para recolha de informação para apresentar quando requisitada nas auditorias ao sistema informático. 63
78 Políticas de Privacidade A privacidade tem vindo cada vez mais a ganhar relevância nos sistemas de TI. Como abordado anteriormente, a privacidade está abrangida por leis, regulamentos e normas, relacionados com a recolha, guarda e utilização de informação pessoal. A PII pode incluir dados como (McCallister, et al., 2010): Nome próprio, apelido e nome de familiares; Número do bilhete de identidade, da segurança social, do passaporte, de contribuinte, do cartão de crédito, etc; Características pessoais como a fotografia, impressões digitais, escrita ou outros dados biométricos; Informação de morada, , contactos telefónicos de emprego ou pessoais e quaisquer outros contactos; Informação sobre propriedade pessoal como terrenos, automóvel, habitação, etc; Informação sobre equipamentos como o Internet Protocol (IP), Media Access Protocol (MAC) ou outra informação específica sobre os equipamentos pessoais; Informação sobre uma pessoa que se encontre associada ou possa ser associada com qualquer uma das já referidas, data de nascimento, emprego, informação médica, dados financeiros, etc. Em muitos países as leis e regulamentos e outras normas legais obrigam a que as organizações, públicas ou privadas, protejam a privacidade da informação pessoal e a segurança dos sistemas informáticos usados no seu tratamento e armazenamento. Portugal encontra-se abrangido por lei comunitárias, como a directiva 95 / 46 / EC 20 do Parlamento Europeu e do Conselho de Outubro de 1995, na protecção de pessoas, na recolha e tratamento de PII e movimentação dessa informação. Esta directiva estabelece que (Parlamento Europeu e do Conselho, 1995):
79 Os Estados membros, de uma forma geral, devem proteger os direitos e liberdades fundamentais dos seus cidadãos, em particular garantir o seu direito à privacidade no que respeita ao processamento de informação pessoal; Os Estados Membros não devem restringir ou proibir a livre circulação de informação pessoal entre Estados Membros, por motivos ligados à protecção nos termos do ponto anterior. Esta directiva define a confidencialidade durante o processamento da informação por qualquer pessoa a actuar sob a autoridade do cliente 21 ou do fornecedor 22, incluíndo o próprio fornecedor, que tenha acesso a dados pessoais do cliente, não os devendo processar, exepto com instruções expressas do cliente ou quando requisitado por motivos legais. É da máxima importância que os dados críticos e PII sejam tratados adequadamente nos contratos entre fornecedores e clientes, assim como nos SLA s acordados entre ambos. As empresas são responsáveis por definir as políticas de segurança, criar uma consciência sobre a necessidade da segurança no seio da empresa e certificar-se que os fornecedores também aderem a esta necessidade. É da responsabilidade dos clientes auditar os fornecedores para garantir que as políticas de segurança são observadas. A privacidade é um aspecto importante de um negócio, focado em assegurar que os dados pessoais sejam protegidos, desde a recolha e utilização indevida até ao roubo e divulgação desta informação. De uma forma geral, a protecção de dados pessoais obedece aos seguintes pontos (Rittinghouse & Ransome, 2010): Recolha Deve existir uma razão válida de negócio para o desenvolvimento de um programa e implementação de um sistema de informação que recolha, processe e divulgue dados pessoais; Notificação O dono da informação deve ser notificado da intenção de recolha, qual a finalidade, tempo de retenção, divulgação e a protecção existente durante a retenção desses dados; 21 Data Controller, na terminologia Europeia 22 Processor usando a terminologia Europeia 65
80 Opção e consentimento O dono da informação deve expressamente e sem ambiguidade, consentir a recolha, definir a finalidade autorizada, tempo de retenção, sua divulgação e protecção; Utilização Uma vez recolhida a informação, esta deve apenas servir o propósito que levou à sua obtenção, incluindo divulgação a terceiros, de acordo com o estabelecido na notificação; Segurança Devem ser implementadas medidas de segurança apropriadas que assegurem a confidencialidade, a integridade e autenticidade dos dados durante a transferência, guarda e manuseamento; Acesso Deve existir um processo à disponibilidade do dono para revisão e actualização da informação. Esse processo deve garantir que o acesso aos dados pessoais deve ser restrito e apenas quando autorizado; Retenção Deve ser implementado um processo que assegure que a retenção da informação pessoal seja apenas pelo período de tempo necessário, para a finalidade que levou à sua recolha ou pelo tempo determinado pelos requisitos legais; Eliminação A informação pessoal deve ser eliminada de forma definitiva e segura Segurança nas Aplicações Cloud As organizações devem proteger as suas aplicações críticas para o negócio de ameaças externas e internas durante todo o ciclo, desde o desenho até à implementação em produção e garantir que estas cumpram as políticas de segurança em vigor na organização. Aplicações seguras, métodos de programação seguros, formação, ferramentas de programação e teste fazem parte de um processo de colaboração entre as equipas de segurança e de desenvolvimento (Rittinghouse & Ransome, 2010). As equipas de desenvolvimento têm o seu foco na camada aplicacional e na sua interacção com as camadas da infraestrutura. Para uma melhor resposta às ameaças, internas e externas, o processo de desenvolvimento deve respeitar a metedologia de Secure - Software Development Lifecycle (S-SDLC) e a segurança deve integrar um lugar central em todo o processo. As organizações devem aplicar as mesmas políticas de segurança no desenvolvimento de software que aplicam na protecção da sua infraestrutura. Uma aplicação comprometida pode ser uma porta de entrada e comprometer os restantes sistemas. 66
81 Requisitos Segurança Análise de risco Estabelecer fases Desenvolvimento Revisão configuração de servidor Revisão configuração de rede Desenho Identificar Identidades Requisitos de segurança Revisão Modelação de ameaças Testes Vulnerabilidades De utilização Codificação Seguir boas práticas Análises estatisticas Figura 17: Secure Software Development Life Cycle. Adaptado (ard3n7, 2013) Em ambientes cloud, o desenvolvimento de software deve considerar o modelo a que as aplicações se destinam. As considerações de segurança são diferenciadas para os três modelos, SaaS, PaaS e IasS, conforme resumido na Tabela 6. Tabela 6: Responsabilidade sobre as aplicações nos modelos s cloud Modelo Descrição Software-as-a-Service O consumidor apenas tem acesso a alterar alguns parâmetros da aplicação, pelo que as politícas de segurança encontram-se, sobretudo do lado do fornecedor e dependentes do acordado no contrato e respectivos SLA s. O consumidor deve ter conhecimento dos procedimentos sobre o acesso administrativo à informação pelo fornecedor. A informação acerca da sua localização, habitualmente não é disponibilizada ao consumidor. O consumidor deve conhecer as políticas de actualização de software e quando estas ocorrem, e os controlos existentes. 67
82 Modelo Descrição Platform-as-a-Service O consumidor é responsável pela camada aplicacional o seu desenvolvimento e instalação. É da sua responsabilidade as políticas de segurança, de controlo de acessos e gestão de identidades. O consumidor é responsável pelas camadas da infraestrutura, sistema operativo e qualquer software intermediário. Infrastructure-as-a-Service O consumidor é responsável por todo o software, desde o sistema operativo até à camada aplicacional, logo responsável por todas as políticas de segurança. O consumidor deve aplicar as mesmas políticas de segurança que aplica na infraestrutura interna da sua organização Segurança da Infraestrutura e Ligações de Rede Um fornecedor de serviços cloud deve garantir que a sua infraestrutura é segura, quer de ameaças externas, quer de ameaças internas. Relativamente às ameaças externas, a infraestrutura do fornecedor deve ter meios de protecção que permitam apenas as comunicações legitimas e impeçam todas as que sejam uma ameaça para os sistemas ou para a informação sob sua custódia. O mesmo se aplica às ameaças internas, sejam de colaboradores do fornecedor ou de ataques bem sucedidos em que o atacante se encontre já nos sistemas internos do cliente ou em sistemas de outros clientes. Outro factor da maior importância é a separação fisíca dos recursos da infraestrutura de gestão interna do fornecedor dos restantes recursos reservados aos clientes. Destes recursos fazem parte os switches e routers usados para ligar todos os restantes dispositivos, virtuais e físicos Controlos Externos O cliente cloud devem avaliar os controlos externos de segurança do fornecedor nas seguintes àreas: Análise ao trafego de entrada - Um atacante procura, primeiramente, por dispositivos de rede mal configurados para explorar e tentar a entrada nos sistemas. As vulnerabilidades mais comuns incluem configurações fracas de instalação, controlos de acesso totalmente abertos e dispositivos sem 68
83 actualizações. Existe também tráfego de rede destinado a portas bem conhecidas que o fornecedor deve bloquear. Tabela 7: Procedimentos de segurança em routers (Microsoft, 2003) Router Caracteristicas - Pacotes correctivos e actualizações O routers devem ter a última versão de software e instalados os patchs de correcção a vulnerabilidades; - Protocolos Bloquear protocolos não utilizados Implementar Filtragem Ingress and egress Tráfego ICMP é verificado (screened) da rede interna TTL expired messages with values 1 or 0 são bloqueadas Screened pacotes de Ping requests com grande dimensão Pacotes de Routing Information Protocol (RIP), se utilizado, deve ser bloqueado no router exterior - Acesso Administrativo Desabilitar portas de gestão não utilizadas nos routers Usar rotas estáticas Desabilitar administração suportada por web browser - Serviços Desabilitar serviços não utilizados - Auditar e registar eventos (logs) Manter registo de todo o tráfego não autorizado Os registos são revistos com frequência para permitir uma análise rápida Todos os equipamentos de rede estão sincronizados com uma fonte horária comum Os procedimentos de segurança dos routers, apresentados na Tabela 7, devem ser complementados com outros meios de análise tráfego de rede, sobre os quais o cliente deve obter informação sobre as suas funcionalidades: traffic screening O cliente deve solicitar ao fornecedor uma lista de bloqueios (block list) das firewals e certificar-se que vão ao encontro das suas necessidades de segurança e ainda fornecer informação sobre o tráfego permitido. Deve 69
84 certificar-se de estas podem impedir um ataque de Distributed Denial of Service (DDOS), tornando inacessível toda a sua informação e sistemas na cloud; Intrusão, prevenção e detecção Ainda que algum tráfego possa parecer legítimo, uma análise aprofundada descobre ataques conhecidos, virús ou malware. Para isso, o fornecedor deve ter instalado sistemas de Intrusion Detection Systems (IDS) e/ou Intrusion Prevention Systems (IPS). Enquanto os primeiros recolhem informação para posterior análise, os últimos tomam decisões com base em padrões, detectando actividade suspeita que possa denotar a existência de um ataque em progresso. Notificação - Ainda que o fornecedor não divulgue informação que possa comprometer a sua segurança, seja da infraestrutura de gestão ou de informação relativa a outros clientes, para que um cliente compreenda a efectividade da segurança, o fornecedor deve facultar informação sobre incidentes e ataques bloqueados, áreas atingidas na infraestrutura do cliente, assim como políticas de retenção de registos, estatisticas de ataques e polítcas de notificação Controlos Internos Os controlos internos de segurança diferem dos controlos externos de segurança. Se uma quebra de segurança acontecer a partir do interior, significa que o atacante já passou pelos dispositivos de segurança de rede externos ou porque teve acesso físico à infraestrutura interna, com ou sem autorização válida. Num ambiente com múltiplos utilizadores, como é uma infraestrutura cloud e mais vincadamente uma cloud pública, é da reponsabilidade do fornecedor a separação das infraestuturas de cada cliente, assim como a separação da sua infraestrutura de gestão dos demais. Os clientes devem solicitar os controlos de segurança da infraesturura interna ou certificação independente da sua conformidade com os regulamentos e normas e compliance. Algumas das tecnologias que podem ser utilizadas são: Local Area Network (LAN) dedicadas e Virtual LANs (VLAN) Em ambientes cloud, é frequente a utilização de VLANs, separação lógica de LANs no mesmo switch. As VLANs não foram inicialmente criadas com pensamento na segurança (McClure, et al., 2009), pelo que a sua utilização para fins de segurança na infraestrutura, coloca um risco acrescido para os clientes cloud. Um switch ou 70
85 VLAN não configurada correctamente representa um risco de segurança. Os clientes devem certificar-se que o fornecedor aplica os controlos adequados nos seus equipamentos de rede. Na Tabela 8 e Tabela 9 apresentamos algumas recomendações para os switchs e outros equipamentos de rede. Tabela 8: Procedimentos de segurança em switchs (Microsoft, 2003) Switch Características - Pacotes de correcções e actualizações Os Switchs devem ter a última versão de software e instalados os pacotes de correcção de vulnerabilidades; - VLANs Assegurar que as VLANs não estão sobre utilizadas ou com excesso de permissões - Configurações base Palavras passe de fábrica nos equipamentos alteradas Activar apenas as portas de gestão necessárias - Serviços Serviços não utilizados estão desactivados - Encriptação Encriptar tráfego switched Tabela 9: Procedimentos de segurança em outros equipamentos (Microsoft, 2003) Outros equipamentos Características - Sincronização de logs Sincronizar todos os relógios em dispositivos com capacidades de manter logs - Acesso Administrativo Usar autenticação segura em todos os acessos administrativos - Access control List (ACL) de rede ACL s devem ser configurados nos equipamentos e redes Isolamento da infraestrutura do fornecedor O tráfego das redes públicas deve ser segregado das redes de controlo e gestão internas da infraestrutura, para melhor isolamento (Winkler, 2011). 71
86 Figura 18: Isolamento de tráfego de controlo e público (Winkler, 2011) Controlos de Segurança da Infraestrutura Com a migração para um ambiente cloud, os consumidores perdem o controlo sobre a segurança física dos servidores e sistemas, dado que esses servidores se encontram em qualquer local onde o fornecedor tenha a suas operações (Rittinghouse & Ransome, 2010). Assim, a responsabilidade da segurança física sobre o centro de dados é então do fornecedor, cabendo ao cliente pedir comprovativos de que os processos e controlos de segurança existem, estão implementados e são cumpridos. Esses comprovativos podem ser obtidos através de uma certificação fornecida por uma entidade independente que demonstre que o fornecedor aplica os controlos de segurança que afirma ter. A norma ISO/IEC 27002: Information technology - Security techniques - Code of practice for information security controls, da International Organization for Standardization (ISO), contêm recomendações sobre as melhores práticas e objectivos de controlo que garantam a confidencialidade, a intergridade e a disponibilidade da informação e sistemas. No que respeita à segurança de um centro de dados, esta norma aborda a segurança das áreas circundantes, segurança de equipamentos e sistemas, mitigação de riscos ambientais ou de outra ordem às infraestruturas, controlo de pessoas que operem equipamentos e sistemas e visitas ocasionais às instalações (ISO, 2013): Manter um perímetro físico de segurança nas áreas adjacentes para prevenir acessos não autorizados, com controlos físicos que assegurem que apenas pessoas autorizadas acedem às áreas sensíveis da infraestrutura. A segurança física deve extender-se aos locais que suportem os serviços do centro de dados; 72