As políticas de segurança dos serviços em nuvem focam em diferentes aspectos da segurança em nuvem, dependendo do sistema de modelo de entrega ao qual se faz referência — SaaS, PaaS ou IaaS:

• A política do Software as a Service (SaaS) foca no gerenciamento do acesso a um aplicativo específico alugado para clientes, sendo eles usuários individuais, empresas ou órgãos governamentais. A política deve dirigir-se à redução de riscos de aplicativos SaaS vulneráveis a ataques de aplicativos malware, que distribuem recursos maliciosos no sistema. Por exemplo: as horas de expediente no escritório em que o aplicativo permite que auxiliares odontológicos autorizados façam o download de registros odontológicos podem ser alteradas maliciosamente para as primeiras horas da manhã para favorecer hackers.
  
  
• A política do Platform as a Service (PaaS) tem foco na proteção dos dados, assim como no gerenciamento do acesso aos aplicativos em um ciclo de vida de negócios completo criado e hospedado por fornecedores independentes de software, desenvolvedores ou unidades de grandes empresas. A política deve dirigir-se à redução de riscos de PaaS sendo usados como centros de Comando e Controle para direcionar operações de um botnet para o uso na instalação de aplicativos malware, ou seja, para estragar os relatórios odontológicos.
  
  
• A política do Infrastructure as a Service (IaaS) foca no gerenciamento de máquinas virtuais, assim como na proteção de dados e no gerenciamento do acesso à infraestrutura desses recursos tradicionais de informática subjacentes às máquinas virtuais no ambiente em nuvem. Essa política deve dirigir-se à estrutura governamental com respeito à redução de riscos nas máquinas virtuais. A IaaS vem sendo utilizada como centros de Comando e Controle para direcionar operações de um botnet para o uso em atualizações maliciosas da infraestrutura dentro e através das máquinas virtuais.

Este artigo cobre de maneira resumida aspectos importantes dos problemas da segurança em nuvem e escreve as reduções de riscos que fazem parte de um programa de avaliação de riscos.

Segurança do serviço em nuvem

A segurança do serviço em nuvem pode ser ameaçada por:

• Um hypervisor falho
• Carência de políticas de limitação
• Excesso no equilíbrio de carga
• Criptografia insegura

Vamos examinar cada uma mais detalhadamente.

Hypervisor falho

Todos os tipos de serviços em nuvem são executados em máquinas virtuais sobre um hypervisor subjacente, que permite que vários sistemas operacionais compartilhem um único host de hardware. Eles são acessados por grupos com diferentes níveis de confiança: usuários, inquilinos e administradores de nuvem. Por exemplo: um inquilino pode ter um contrato de licenciamento de 1000 usuários para acessar certos softwares e serviços.

Quando um hypervisor falha, todos os recursos de instâncias e filas de solicitações de dados também falham. Eles podem influenciar maliciosamente as políticas de limitação [leia mais] que são usadas para monitorar o consumo de recursos de instâncias e as filas de solicitações de dados durante picos na demanda por cargas de trabalho. Os controles em redes virtuais internas, que são usados para a comunicação entre as máquinas virtuais, não são visíveis o suficiente para reforçar as políticas de segurança. As responsabilidades para os controles de segurança e redes de máquinas virtuais podem não estar bem separadas.

Um hacker pode se tornar um usuário com altos privilégios e controles administrativos, sair de uma máquina virtual e, então, executar programas maliciosos no hypervisor. Por exemplo: ele pode acessar arquivos de diretório e redesignar maliciosamente recursos de instâncias para outra máquina virtual. Ele pode causar a falha dos mecanismos que separam armazenamento, memória, roteamento e reputação entre inquilinos na mesma máquina virtual.

O hacker pode roubar informações sensíveis de dados residuais, que não foram excluídas de recursos de instâncias redistribuídos em uma máquina virtual. O hacker pode usar um hypervisor falho para identificar vizinhos de uma máquina virtual saudável e monitorar a atividade deles. Ele pode entrar na máquina virtual de um vizinho e adicionar códigos maliciosos em aplicativos PaaS.

Carência de políticas de limitação

Um usuário final deve avaliar a política de segurança de um fornecedor de serviços antes de estabelecer uma relação entre os dois. É necessário comparar a postura de segurança da computação em nuvem com um ambiente local real e certificar-se de que as políticas da limitação de solicitações de dados, usuários e recursos de instâncias na nuvem estão presentes na política de segurança.

Uma política de limitação de recursos é útil para monitorar como os recursos de instâncias adicionais são consumidos durante picos na demanda de cargas de trabalho. Uma política de limitação de usuários verifica quantos usuários estão atualmente acessando e saindo de um serviço em nuvem e se eles estão se aproximando do número máximo de usuários conforme especificado na licença de uso.

Há riscos em não estabelecer essas políticas:

• Sem uma política de limitação de recursos, não é possível saber se recursos de instâncias atingiram maliciosamente a capacidade máxima, fazendo assim com que o seu fornecedor de serviços em nuvem desligue o serviço sem aviso prévio.
  
  
• Sem uma política de limitação de usuários, não é possível saber se o número de usuários atuais está chegando ao máximo e quantos usuários não saíram do sistema ao concluir seus serviços em nuvem. Os hackers podem então identificar esses usuários.
  
  
• Sem uma política de limitação de solicitações de dados, não é possível saber o tamanho da fila de solicitações de dados. Os hackers podem encher as filas com solicitações de dados maliciosas (como solicitações injetadas SQL), fazendo com que essas filas atinjam suas capacidades máximas.

Excesso no equilíbrio de carga

O equilíbrio de carga é usado para distribuir recursos de instâncias e solicitações de dados. Por exemplo: cada recurso de instância pode ser carregado até 50 de sua capacidade, de modo que se uma instância falha, as outras instâncias saudáveis assumem as transações de negócios da instância que falhou.

Cada fila deve ser carregada com solicitações de dados até 50 por cento de sua capacidade máxima, de modo que se uma fila falha, as outras filas saudáveis assumem as solicitações de dados originalmente destinadas à fila que falhou.

Quando o equilíbrio de carga dos recursos de instâncias é afetado de forma maliciosa por aplicativos malware em uma máquina virtual, ele pode causar o carregamento excessivo desses recursos com transações maliciosas, resultando no preenchimento de 100 por cento da capacidade de cada recurso.

É impossível mover transações de negócios das instâncias de recursos que falharam para as instâncias saudáveis. O excesso no equilíbrio de carga não pode ser usado para implementar mecanismos de failover, como redundância de compartilhamento de carregamento ou recursos de instâncias.

Criptografia insegura

É necessária alguma forma de criptografia para proteger a confidencialidade e a integridade dos dados. Mesmo que os dados são sejam sensíveis ou pessoais, eles devem ser protegidos por meio de criptografia ao serem transportados e manipulados na nuvem.

Os hackers podem tirar vantagem dos avanços da criptoanálise (análise da criptografia) ou de recursos de instâncias maliciosos para tornar algoritmos de criptografia inseguros. Eles podem procurar falhas em um algoritmo de criptografia antes de modificá-los maliciosamente, tornando assim uma criptografia forte em uma fraca.

Os hackers podem ir mais além, encontrando a última versão dos algoritmos de criptografia e, em suas próprias máquinas, efetuar um processo de engenharia reversa para aprender como o algoritmo funciona.

Voltar para parte superior

Reduzindo os ricos em serviços em nuvem

Com um bom custo-benefício, é possível reduzir os riscos aplicando controles de segurança, de modo que é possível diminuir a probabilidade de que a vulnerabilidade de ativos seja explorada e resulte em implementações de ameaças.

Antes de tentar reduzir os riscos, é necessário identificar os ativos que devem ser protegidos. A abordagem mais simples para a avaliação de riscos é:

1. Identificar os ativos
2. Analisar os riscos
3. aplicar medidas defensivas de segurança
4. Efetuar avaliações pós-execução ou evento

Um conceito essencial que se deve ter em mente é que é possível voltar para as etapas anteriores em qualquer estágio para incorporar variáveis, que foram adicionadas mais tarde ou a respeito das quais você não estava ciente.

Comece identificando os ativos — hardware, software, componentes de rede, pessoal, usuários, documentação, instalações e outros ativos que fazem parte diretamente de um tipo de serviço em nuvem. Quando você descobrir que excluiu certos ativos ao identificá-los e tentar reduzir os riscos, lembre-se de que sempre é possível retornar à etapa inicial para atualizar o inventário de ativos e então repetir a segunda etapa.

Caso, durante a terceira etapa da análise das medidas defensivas de segurança, você descobrir que certos riscos não foram abordados, é possível retornar para a segunda etapa para incluí-los e determinar o potencial de perda e a probabilidade de cada risco de que uma ameaça irá explorar vulnerabilidades. É possível retornar à primeira etapa a partir da terceira para atualizar um inventário de ativos que devem ser protegidos.

Na quarta etapa, você reavalia periodicamente o programa de avaliação de riscos de acordo com novos riscos, controles de segurança de bom custo-benefício, tecnologias de infraestrutura emergentes e novas legislações.

Vamos examinar cada etapa mais detalhadamente.

Etapa 1: identificar ativos

Tanto o cliente quanto o fornecedor da nuvem precisam identificar ativos de hardware e software e estimar o custo de reposição de cada ativo. Eles devem manter e periodicamente atualizar um inventário de ativos, que pode ser alterado como resultado da reestruturação da organização, tecnologias mais eficientes em termos de energia, melhores mecanismos de failover e novas legislações sobre exportações de privacidade de dados através de fronteiras de jurisdições.

O número de ativos de hardware e software que um cliente precisa identificar ao alugar serviços de um fornecedor SaaS é muito menor em relação a quando o cliente tem mais controle usando um modelo PaaS ou, ainda mais, usando um modelo IaaS.

Agora, vamos dar uma olhada em quais ativos precisam ser identificados em cada tipo de serviço em nuvem.

Ativos SaaS
Uma vez que o único controle que o cliente da nuvem tem é o acesso ao aplicativo a partir do seu desktop, laptop ou dispositivo portátil, os ativos que ele precisa identificar são sistemas operacionais de dispositivos portáteis, aplicativos e programas padrões. Por isso, é importante limitar seu inventário de ativos do dispositivo a programas e aplicativos que serão usados com o SaaS. Não é uma boa ideia juntar programas de uso pessoal (como jogos) com programas que você precisa para acessar o SaaS no mesmo dispositivo.

No mínimo, os seguintes ativos devem ser controlados por um fornecedor em nuvem:

• Sistemas operacionais
• Hardware
• Infraestrutura de rede
• Aplicativos de gerenciamento de acesso
• Recursos de instâncias
• Atualizações e correções de aplicativos SaaS

O cliente não é responsável por identificá-los.

Ativos PaaS
Os ativos que o cliente da nuvem precisa identificar são aqueles que ele pode controlar: todos os aplicativos em um ciclo de vida de negócios completo para a plataforma (por exemplo: planilhas, processadores de texto, backups, contabilidade, processamento de folha de pagamento e faturamento).

No mínimo, os seguintes ativos devem ser controlados por um fornecedor em nuvem em uma configuração PaaS:

• Operating system
• Hardware
• Infraestrutura de rede
• Recursos de instâncias

O cliente da nuvem não é responsável por identificar esses ativos.

Ativos IaaS
Os ativos que o cliente da nuvem precisa identificar são aqueles que ele pode controlar: os sistemas operacionais, o equipamento de rede e os aplicativos implantados no nível da máquina virtual. O cliente pode escalonar o número de recursos de instâncias e servidores virtuais ou blocos de área de armazenamento para cima ou para baixo.

O cliente da nuvem não pode controlar a infraestrutura e os componentes subjacentes. O fornecedor precisa identificar esses ativos.

Etapa 2: analisar riscos

Um risco consiste no potencial de perda ou na probabilidade de que uma ameaça irá tirar proveito das vulnerabilidades de um serviço em nuvem. Se medidas defensivas de bom custo-benefício não estão em vigor, o serviço em nuvem é passivo de vulnerabilidades que podem vir a ser atacadas, dando início a uma ameaça.

O potencial de perda dos riscos para os ativos depende do impacto do risco em cada ativo (isso quer dizer, de nenhum a zero para ativos de documentação, que estão sempre disponíveis para usuários e uma alta taxa de 0,96 para ativos de recursos de instâncias no ambiente em nuvem sem medidas defensivas adequadas). O potencial de perda dos riscos para os ativos também depende da frequência que a ameaça pode ocorrer dentro do período de um ano.

Como é possível tirar proveito das vulnerabilidades
Vamos dar uma olhada em um simples exemplo de como um hacker pode tirar proveito das seguintes vulnerabilidades para atacar os ativos de recursos de instâncias. As vulnerabilidades são:

• Carência de módulo de limitação no aplicativo
• Dados residuais nos recursos de instâncias
• Controles baseados em rede insuficientes em redes virtualizadas
• Monitoramento de usuários privilegiados inadequado

Um bom aplicativo é dividido em módulos, que interagem uns com os outros para efetuar uma tarefa ou uma sequência de tarefas. Isso faz com que seja mais fácil para um desenvolvedor adicionar um módulo ao aplicativo através da reutilização de módulos existentes ou da adição de novos módulos. Quando um aplicativo não conta com um módulo de limitação — definido abaixo da capacidade máxima de recursos de instâncias e em outro nível para solicitações de dados — o cliente e o fornecedor não têm como saber se recursos de instâncias ou solicitações de dados atingiram a capacidade máxima. Eles não têm como saber se o hacker criou a máquina virtual maliciosa no mesmo servidor físico que hospeda máquinas virtuais saudáveis até que seja tarde demais (por exemplo: até que um ataque de negação de serviço tenha ocorrido). O hacker consegue fazer isso inundando os vizinhos da máquina virtual maliciosa com recursos de instâncias e filas de solicitações de dados maliciosas. Ele atrai a vítima para aumentar o número de máquinas virtuais até que elas atinjam a capacidade máxima do servidor físico.

Os dados residuais ocorrem quando recursos de instâncias distribuídos anteriormente não são completamente limpos dos dados antes de serem redistribuídos para o mesmo ou para outro usuário. Recursos de instâncias incluem memória, cache, processo, sessões, limites e recursos de armazenamento. Um hacker procura nos recursos de instâncias para obter informações pessoais a respeito de sua vítima.

Controles baseados em rede insuficientes em redes virtualizadas ocorrem quando controles de segurança, que funcionam no nível de rede, podem não funcionar em uma infraestrutura de rede IaaS. Isso limita o acesso do administrador autorizado à infraestrutura. Um hacker aproveita o fato de que o administrador IaaS não pode aplicar controles padrões como zoneamento de rede baseado em IP em redes virtualizadas. Os fornecedores de IaaS podem não permitir a varredura de vulnerabilidade baseada em rede, pois eles não têm como distinguir varreduras de rede amigáveis de atividades de ataques. Também pode haver controles insuficientes para distinguir tráfego em redes reais de tráfego em redes virtualizadas (por exemplo: comunicações entre duas ou mais máquinas virtuais acima do hypervisor no mesmo servidor).

O monitoramento de usuários privilegiados inadequado ocorre quando o fornecedor monitora de modo inadequado atividades maliciosas de um hacker que obteve acesso a maquina virtuais do hypervisor se passando por um usuário privilegiado com controles de acesso administrativo. Como exemplo, um hacker com esse tipo de acesso pode criar recursos de instâncias e filas de solicitações de dados maliciosas sem que o fornecedor perceba o que ele esta fazendo. Outro exemplo é a redesignação maliciosa de recursos de instâncias de um recurso de instância saudável de uma máquina virtual como recursos de instância maliciosos para outra máquina virtual.

Uma possível classificação da gravidade dos ataques
É claro que é necessário desenvolver o seu próprio sistema ou classificação do potencial de perdas dos diferentes tipos de ataques, porém neste artigo eu classificarei o potencial de perda dos ataques na seguinte ordem de prioridade:

• Como um hacker pode obter acesso
• O que ele procura
• Que ferramentas ele tem em mãos

Por exemplo, um hacker pode entrar no sistema se passando por um usuário privilegiado com controles de acesso administrativo e efetuar atividades maliciosas, que um administrador de sistema legítimo a princípio não nota. O hacker também pode conseguir acesso enviando injeções SQL para encontrar nomes de arquivo e procurar dados residuais nesses arquivos.

Após entrar na máquina virtual, ele pode usar ferramentas hacker para iniciar atividades de ataques de varredura de rede como se elas fossem varreduras de rede amigáveis. A atividade de ataque pode incluir listagens de módulos dentro de cada aplicativo. Se o hacker descobre que o aplicativo não conta com módulos de limitação, ele pode usar ou criar uma ferramenta para criar recursos de instâncias até que eles atinjam a capacidade máxima.

Etapa 3: aplicar medidas defensivas de segurança

A próxima etapa na avaliação de riscos é relativamente fácil em conceito e, como muitas outras coisas na vida, um pouco mais complicada na prática — descobrir se as medidas defensivas para reduzir os riscos têm bom custo-benefício, ou seja, se os benefícios resultantes delas são maiores que os custos de implementação. Com isso, a probabilidade dos ricos de que ameaças tirarão proveito de vulnerabilidades diminuem e o retorno sobre os investimentos aumenta.

O próximo ponto é muito importante: se é verificado que uma medida defensiva não tem um bom custo-benefício, os riscos residuais permanecem e não podem ser reduzidos. Você precisa então aprender a viver e lidar com eles, e não gastar mais dinheiro com isso. Esse é um dos conceitos mais difíceis de compreender e admitir na redução/avaliação de riscos: a redução de certos riscos pode ser muito cara em relação aos benefícios que providencia.

Entretanto, se há muitos riscos residuais e poucas medidas defensivas com bom custo-benefício, você deve repetir as etapas da avaliação de riscos por diversos motivos:

• Se essa é uma das suas primeiras tentativas de redução/avaliação de riscos, recomenda-se repetir o processo algumas vezes para "afiar" suas habilidades de identificação de ativos, análise e compreensão dos riscos e determinação da amplitude e profundidade de potenciais medidas defensivas e as várias maneiras como elas podem ser aplicadas.
  
  
• Você também deve ficar de olho em novas medidas defensivas e tecnologias de infraestrutura em nuvem que tragam mais benefícios e custos mais baixos
  
  
• Como alternativa, você deve considerar a compra de seguros para transferir alguns riscos residuais caso isso seja mais barato que a implementação de medidas defensivas.

Alguns exemplos de medidas defensivas que eu mencionei neste artigo incluem:

• Certificar-se de que políticas de limitação de solicitações de dados, usuários e recursos estão em vigor.
• Limpar dados residuais de recursos de instâncias antes de eles serem redistribuídos.
• Implementar planos para mecanismos de failover, continuidade de negócios e recuperação de desastres.
• Monitorar usuários privilegiados; verificando as atividades de acesso e segundo planos desses usuários e a saúde de servidores de monitoramento físicos, redes e outros componentes da infraestrutura.
• Educar clientes e fornecedores sobre os benefícios de medidas defensivas e redução de riscos.

Etapa 4: efetuar pós-avaliações

Enquanto avaliações de riscos devem ser feitas periodicamente a cada três anos, pode ser necessário reavaliar os riscos com maior frequência se as seguintes condições ocorrerem:

• Novas tecnologias de serviços em nuvem surgirem, as quais podem influenciar ativos de rede, hardware e software.
• Novas vulnerabilidades e ameaças surgirem.
• Novas medidas defensivas forem disponibilizadas, que possam reduzir de modo eficiente riscos anteriormente categorizados como residuais.
• Novas abordagens para a redução de riscos forem concebidas.
• Impactos de grande porte resultantes de alterações organizacionais (como unificações) em ativos de todas as categorias.
• Grandes alterações em leis e regulamentações de conformidade em jurisdições.

De fato, se você é responsável pela avaliação e redução de riscos dos serviços em nuvem da sua organização, você deveria consultar o infostream para obter mais informações sobre essas condições ao menos uma vez por semana. Talvez seja uma boa ideia criar um feed de notícias a respeito das novas ameaças e vulnerabilidades.

Voltar para parte superior

Em conclusão

A redução de riscos em serviços em nuvens ao mesmo tempo que se mantém um alto tempo de disponibilidade requer um planejamento de riscos proativo para resolver os problemas de quais ativos identificar para cada tipo de nuvem, quais riscos analisar, quais medidas defensivas têm um bom custo-benefício e o que avaliar depois que os riscos forem reduzidos. Sua equipe de desenvolvedores, usuários e analistas de negócios precisa trabalhar em conjunto para reduzir os ricos residuais nos serviços em nuvem. A equipe descobrirá que resolver esses problemas torna o trabalho de redução de riscos nos serviços em nuvem muito mais fácil.

Recursos

Aprender

• A autora trata da política de limite nos artigos "Balancear Carga de Trabalho em um Ambiente de Nuvem: Usar políticas de limite para balancear dinamicamente demandas de carga de trabalho" e "Computação em nuvem versus computação em grade: tipos de serviço, similaridades e diferenças e outros aspectos a serem considerados."
  
  
• A autora discute maneiras proativas contra reativas de fazer alterações em aplicativos ao migrá-los para a nuvem no artigo "Altere o comportamento dos aplicativos: dos aplicativos internos para a nuvem."
  
  
• Nos recursos para desenvolvedores de nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão criando os seus projetos de implementação de nuvem.
  
  
• Mais recursos do developerWorks que correspondem a este artigo podem ser localizados em SOA e serviços da Web no developerWorks e segmentos de mercado no developerWorks.
  
  

Obter produtos e tecnologias

• Consulte as seções as imagens do produto available on the IBM Smart Business Development and Test on the IBM Cloud.
  
  

Discutir

• Participe de um grupo de computação em nuvem no developerWorks.
  
  
• Leia toda a excelentes blogs sobre nuvem no developerWorks.
  
  
• Participe dos developerWorks, uma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Segurança do serviço em nuvem
• Reduzindo os ricos em serviços em nuvem
• Em conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais