COMPUTAÇÃO EM NUVEM: VULNERABILIDADES NA NUVEM

A forma como você define a arquitetura da sua infraestrutura de computação em nuvem pode ter um impacto direto sobre sua capacidade de resistir a falhas.
Nuvens públicas e privadas podem ser afetadas por ataques maliciosos e falhas de infra-estrutura como falta de energia. Tais eventos podem afetar servidores de nome de domínio Internet, impedir o acesso às nuvens ou afetam diretamente as operações da nuvem.

Por exemplo, um ataque na Akamai Technologies em 15 de junho de 2004, causou uma falha de nome de domínio e um grande apagão que afetou o Google Inc., Yahoo! Inc. e muitos outros sites. Em maio de 2009, o Google foi alvo de um ataque sério (DoS) de denial-of-service que derrubou serviços como Gmail e Google News por vários dias.

Um raio causou uma inatividade prolongada na Amazon.com Inc. em 29 e 30 de Junho 2012. A nuvem da Amazon Web Services (AWS) na região leste dos Estados Unidos, que consiste de 10 data centers em quatro zonas de disponibilidade, inicialmente foi incomodada por flutuações de energia utilitário provavelmente causadas por uma tempestade elétrica. Uma tempestade de 29 de junho de 2012, na costa leste tirou algumas instalações da Amazônia com base em Virgínia e afetou as empresas que utilizam sistemas exclusivamente nesta região. Instagram, um serviço de compartilhamento de fotos, declaradamente foi uma das vítimas desta paralisação.

Recuperação destes acontecimentos levou muito tempo e expostos a uma gama de problemas. Por exemplo, um dos 10 centros falhou para alternar para geradores reserva antes de esgotar a energia que poderia ser fornecida pela fonte de alimentação uninterruptible fornecer unidades (UPS). AWS utiliza “controlar aviões” para interruptor permitem que os usuários a recursos em uma região diferente, e este componente de software também falhou.

O processo de arranque estava com defeito e estendido o tempo necessário para reiniciar o Elastic Compute Cloud (EC2) e serviços de armazenamento de bloco elástico (EBS). Outro problema crítico foi um bug em elástico Load Balancing (ELB), que é usado para rotear o tráfego para servidores com capacidade disponível. Um inseto semelhante afetou o processo de recuperação de serviço do banco de dados relacional (RDS). Este evento trouxe a luz “ocultos” problemas que ocorrem apenas em circunstâncias especiais.

Pedaços de nuvem

Um provedor de aplicação de nuvem, um provedor de armazenamento de nuvem e um provedor de rede poderiam implementar políticas diferentes. As imprevisíveis interações entre o balanceamento de carga e outros mecanismos reativos podem provocar instabilidades dinâmicas. O acoplamento não intencional de controladores independentes que gerenciar a carga, consumo de energia e elementos da infra-estrutura pode levar a indesejável feedback e instabilidade similar aos experimentados pela política de roteamento na Internet Border Gateway Protocol (BGP).
Por exemplo, o balanceador de carga de um provedor de aplicativos poderia interagir com o otimizador de poder do provedor de infra-estrutura. Alguns destes acoplamentos só podem manifestar-se sob condições extremas e podem ser muito difícil de detectar sob condições operacionais normais. Quando o sistema tenta se recuperar de uma falha do disco, como no caso da paralisação AWS 2012 podem ter conseqüências desastrosas.

Recursos em data centers localizados em diferentes áreas geográficas de cluster é um dos meios utilizados para reduzir a probabilidade de falhas catastróficas. Esta dispersão geográfica dos recursos pode ter efeitos colaterais positivos adicionais. Pode reduzir os custos de energia e tráfego de comunicação despachando os cálculos para locais onde a energia elétrica é mais barata. Também pode melhorar o desempenho com uma estratégia de balanceamento de carga inteligente e eficiente.

No estabelecimento de uma infra-estrutura em nuvem, você tem que equilibrar cuidadosamente os objectivos do sistema tais como maximizar taxa de transferência, utilização de recursos e benefícios financeiros com as necessidades do usuário tais como baixo custo e tempo de resposta e disponibilidade máxima. O preço a pagar por qualquer otimização do sistema é o sistema de maior complexidade. Por exemplo, a latência de comunicação em uma rede de área ampla (WAN) é consideravelmente maior do que a mais de uma rede de área local (LAN) e requer o desenvolvimento de novos algoritmos para tomada de decisão global.

Desafios de nuvem

Cloud computing herda alguns dos desafios da paralela e computação distribuída. Também enfrenta muitos desafios principais do seus próprios. Os desafios específicos são diferentes para os modelos de entrega de três nuvens, mas em todos os casos as dificuldades são criadas pela própria natureza de utility computing, que é baseado no compartilhamento de recursos e virtualização de recursos e exige um modelo diferente de confiança que o modelo centrado no usuário onipresente que tem sido o padrão por um longo tempo.
O desafio mais importante é a segurança. Ganhar a confiança de uma base de usuários grande é fundamental para o futuro da nuvem de computação. É irrealista esperar que uma nuvem pública irá fornecer um ambiente adequado para todas as aplicações. Aplicações altamente sensíveis relacionados à gestão de infra-estruturas críticas, aplicações de saúde e outros mais provável serão presentados por nuvens privadas.

Muitas aplicações em tempo real provavelmente ainda vão ser confinadas para nuvens privadas. Alguns aplicativos podem ser melhor servidos por uma configuração de nuvem híbrida. Tais aplicações podem manter os dados confidenciais em uma nuvem privada e usar uma nuvem pública para alguns do processamento.

O modelo Software como serviço (SaaS) enfrenta desafios semelhantes como outros serviços on-line necessários para proteger as informações privadas, tais como financeira ou de serviços de saúde. Neste caso, um usuário interage com serviços de nuvem, através de uma interface bem definida. Em princípio, portanto, é menos desafiador para o provedor de serviços fechar alguns dos canais de ataque.

Ainda assim, tais serviços são vulneráveis a ataques DoS e insiders maliciosos. Dados no armazenamento são mais vulneráveis a ataques, então, dedicar atenção especial para proteger servidores de armazenamento. A replicação de dados necessária para assegurar a continuidade do serviço em caso de falha do sistema de armazenamento aumenta a vulnerabilidade. Criptografia de dados pode proteger os dados no armazenamento, mas eventualmente os dados devem ser descriptografados para processamento. Então ele é exposto para atacar.

A infra-estrutura como um serviço (IaaS) modelo é de longe o mais desafiador para defender contra ataques. De fato, um usuário de IaaS tem muito mais liberdade do que os outros modelos de entrega dois nuvem. Uma fonte adicional de preocupação é que os recursos da nuvem considerável podem ser usados para iniciar ataques contra a rede e a infra-estrutura de computação.

A virtualização é uma opção de projeto crítica para este modelo, mas ele expõe o sistema para novas fontes de ataque. O confiável computing base (TCB) de um ambiente virtual inclui não só o hardware e o hipervisor, mas também a gestão do sistema operacional. Você pode salvar todo o estado de uma máquina virtual (VM) para um arquivo para permitir a migração e recuperação, ambas as operações altamente desejáveis.

Ainda esta possibilidade desafia as estratégias para trazer os servidores pertencentes a uma organização para um estado estável e desejável. Com efeito, uma VM infectada pode ficar inativa, quando os sistemas são limpos. Então ele pode acordar mais tarde e infectar outros sistemas. Este é outro exemplo do profundo entrelaçamento dos efeitos desejáveis e indesejáveis de tecnologias de computação em nuvem básico.

O próximo grande desafio está relacionado ao gerenciamento de recursos em uma nuvem. Qualquer estratégia de gerenciamento de recurso sistemático (ao invés de ad-hoc) requer a existência de controladores encarregado de implementar várias classes de políticas: controle de admissão, a alocação de capacidade, carregar balanceamento, otimização energética e, por último mas não menos importante, garante o fornecimento de qualidade de serviço (QoS).

Para implementar estas políticas, os controladores precisam de informações precisas sobre o estado global do sistema. Determinando o estado de um sistema complexo com 106 servidores ou mais, distribuída sobre uma grande área geográfica, não é viável. Com efeito, o external carregar, bem como o estado dos recursos individuais, alterações muito rapidamente. Assim, os controladores devem ser capazes de funcionar com conhecimento incompleto ou aproximado do estado do sistema.

Parece razoável esperar que tal sistema complexo pode única função com base em princípios de autogestão. Mas, autogestão e auto-organização elevar a fasquia para a aplicação do log e auditoria de processos críticos para a segurança e a confiança em um provedor de serviços de computação em nuvem.

Sob autogestão torna-se quase impossível identificar as razões que uma determinada ação que resultou em uma falha de segurança foi tomada.

O último grande desafio que vou abordar está relacionado com a interoperabilidade e padronização. Vendor lock-in — provedor de serviços o fato de que um usuário está vinculado a uma determinada nuvem — é uma grande preocupação para os usuários da nuvem. Padronização apoiaria a interoperabilidade e, assim, aliviar os receios de que um serviço crítico para uma organização de grande porte pode não estar disponível por um período prolongado de tempo.

A imposição de normas cada vez quando ainda está em desenvolvimento uma tecnologia é desafiador, e pode ser contraproducente porque isso pode sufocar a inovação. É importante perceber a complexidade dos problemas colocados pela computação em nuvem e de compreender a ampla gama de problemas técnicos e sociais nuvem computação levanta. O esforço para migrar a atividades de ti para nuvens públicas e privadas terão um efeito duradouro.

FONTE : http://www.securityhacker.org