Mostrando postagens com marcador risco. Mostrar todas as postagens
Mostrando postagens com marcador risco. Mostrar todas as postagens

sexta-feira, 20 de fevereiro de 2015

Cumulus Nimbus

5 riscos que não devemos ignorar quando o assunto é cloud computing

(http://computerworld.com.br/gestao/2015/02/20/5-riscos-que-nao-devemos-ignorar-quando-o-assunto-e-cloud-computing)
Por Roger A. Grimes, INFOWORLD/EUA
Publicada em 20 de fevereiro de 2015 - 08h20
Um dos maiores empecilhos para a adoção de computação em nuvem pública é o cálculo dos riscos conhecidos e desconhecidos
Estamos sendo constantemente confrontados com os três tipos de riscos: o que sabemos que sabemos, o que sabemos que não sabemos, e o que não sabemos que nãsabemos.
Um dos maiores empecilhos para a adoção de computação em nuvem pública é o cálculo dos riscos conhecidos e desconhecidos. Passei os últimos anos contemplando essas questões, tanto como provedor de nuvem pública e quanto como usuário.
Aqui está uma lista de cinco riscos que qualquer empresa enfrenta como cliente de um serviço de nuvem pública.
1:: Acesso compartilhado
Um dos princípios fundamentais da computação em nuvem pública é o modelo multitenancy, de uma única instância lógica compartilhada por centenas ou milhares de clientes. Em outras palavras, a típica arquitetura que permite a otimização de recursos de infraestrutura e software através de compartilhamento, mantendo os inquilinos, empresas/clientes, logicamente separados. É comum os clientes compartilharem os mesmos recursos de computação: CPU, armazenamento, espaço, memória, etc.
Pois bem, multitenancy é um desconhecido conhecido para a grande maioria de nós. Ou seja, algo que sabemos que não sabemos. Não só pelo risco de nossos dados privados vazando acidentalmente para outros inquilinos, mas também por conta dos riscos adicionais do compartilhamento de recursos. Vulnerabilidades multitenancy são muito preocupantes, porque uma falha pode permitir que outro inquilino ou atacante veja todos os outros dados ou assuma a identidade de outros clientes.
Várias novas classes de vulnerabilidades derivam da natureza comum da nuvem. Pesquisadores já foram capazes de recuperar dados de outros inquilinos no que era para ser um novo espaço de armazenamento. Outros pesquisadores já foram capazes de se intrometer na memória de outros inquilinos e em espaços de endereço IP. E alguns poucos foram capazes de assumir totalmente os recursos de outro inquilino simplesmente prevendo os endereços IP ou MAC que foram atribuídos a eles.
Questões de segurança multitenancy só agora estão se tornando importantes para a maioria de nós, com as  vulnerabilidades começando a ser exploradas.
Arrisco dizer que multitenancy será um grande problema de segurança no longo prazo.
2:: Vulnerabilidades virtuais
Cada provedor de serviços de cloud é um enorme usuário de virtualização.  E cada camada de virtualização representa uma importante plataforma na infraestrutura de TI, com vulnerabilidades embutidas que podem ser exploradas. Servidores virtuais estão sujeitos aos mesmos ataques que atingem os servidores físicos, assim como novas ameaças estão explorando falhas do hypervisor.
Na minha opinião, há quatro principais tipos de riscos de exploração virtuais: apenas no servidor, "guest to guest", "host to guest", e "guest to host". Todos eles desconhecidos e não calculados na maioria das estimativas de risco.
Quando converso com provedores de nuvem sobre esses risco virtuais, muitos arregalam os olhos. A maioria afirma que os riscos são exagerados. Eu costumo dizer-lhes para verificar a lista de patches de seus fornecedores de software. Não são bonitas.
3:: Autenticação, autorização e controle de acesso
Obviamente, os mecanismos de controle de autenticação, autorização e acesso do seu provedor de nuvem é fundamental. Quantas vezes ele procura e remove contas obsoletas? Quantas contas privilegiadas podem acessar seus sistemas - e seus dados? Que tipo de autenticação é necessária para os usuários privilegiados? A sua empresa compartilha um espaço comum com o vendedor e/ou com outros inquilinos?
Namespaces compartilhados e autenticação para criar experiências single-sign-on (SSO) podem aumentar a produtividade, mas também aumentam os riscos, substancialmente.
Certifique-se que os prestadores dos serviços de cloud computing limitam o acesso dos funcionários e as autorizações para o que seja estritamente necessário para a realização de sua tarefas.
Proteção de dados é outra grande preocupação. Se a criptografia de dados é usada e aplicada, as chaves privadas são compartilhadas entre os inquilinos? Quem e quantas pessoas na equipe do fornecedor de nuvem pode ver os seus dados? Onde os seus dados estão armazenados fisicamente? Como seu dado  é tratado quando deixa de ser necessário?
Não tenho certeza de quantos fornecedores de nuvem estariam dispostos a compartilhar respostas detalhadas a estas perguntas, mas você tem que pelo menos perguntar se quiser saber o que é conhecido e desconhecido.
4:: Disponibilidade
Quando você é um cliente de um provedor de nuvem pública, redundância e tolerância a falhas não estão sob seu controle. Geralmente o que é fornecido e como é feito, não são divulgados. São completamente opacos. Todo serviço de nuvem alega ter tolerância a falhas e disponibilidade fantásticas, ainda que, mês após mês, vejamos o maior e o melhor cair por terra, com interrupções de serviço por horas ou mesmo dias.
Uma preocupação ainda maior são os poucos casos em que os clientes perderam dados, devido a problema com o provedor de nuvem ou com ataques maliciosos. O fornecedor de nuvem geralmente afirma fazer backups dos dados dos clientes. Mas mesmo com os backups garantidos, clientes já perderam de dados - e de forma permanente. Se possível, a sua empresa deve sempre fazer o backup dos dados compartilhados na nuvem por conta própria. Ou se resguardar, em contrato, estabelecendo as responsabilidades do provedor por perdas  de dados.
Tem mais. Alguns provedores de cloud computing dependem de terceiros para prestar determinados serviços. Um potencial cliente precisa saber identificar as interdependências potencialmente problemáticas. Considere um modelo de governança em que um fornecedor detém a responsabilidade global para as interrupções e as falhas de segurança.
5:: Posse
Esse risco é quase sempre uma surpresa para os clientes de cloud, mas muitas vezes eles não são os únicos proprietários dos dados. Muitos provedores de nuvem pública, incluindo os maiores e mais conhecidos, possuem cláusulas em seus contratos que afirmam explicitamente que os dados armazenados pertencem a ele provedor - e não ao cliente.
Eu mesmo conheço alguns casos  nos quais o fornecedor de nuvem saiu do negócio e, em seguida, vendeu os dados confidenciais dos clientes como parte de seus ativos. É chocante. Certifique-se de que você tem esse risco previsto em seu contrato. Deixe claro quem é o dono dos seus dados e o que o fornecedor de cloud pode fazer com eles.
Visibilidade nuvem 
Mesmo quando os riscos de computação em nuvem são conhecidos, eles são difíceis de calcular com precisão real. Nós simplesmente não temos histórias e provas suficientes  para determinar a probabilidade de falhas de segurança ou disponibilidade, especialmente para um determinado fornecedor, ou se esses riscos vão levar a danos substanciais para os clientes. O melhor que você pode fazer é dar uma de Rumsfeld e pelo menos deixar sua gestão entre os itens  que você sabe que não sabe.
Para isso, primeiro, tente reduzir tudo o que você por ventura não sabe que nãsabe. As mesmas perguntas devem ser feitas repetidas vezes no estabelecimento de contratos de nuvem.
Estabeleça, o melhor que puder, as responsabilidade do fornecedor de Cloud. Só fazendo as perguntas difíceis você poderá começar a entender os riscos totais da computação em nuvem pública.
Embora possa soar como se eu estivesse desaconselhando o uso da computação em nuvem pública, na verdade sou realmente um grande fã dela. Acredito que a maioria dos fornecedores de nuvem pública faz um trabalho de proteção de dados  melhor do que muitos de seus clientes. Mas você precisa conhecer brechas de seu fornecedor de nuvem e as medidas que toma para mitigar os riscos.
É preciso analisar detalhadamente as opções para proteção de dados sensíveis oferecidas pelos provedores de serviços de cloud computing. O quanto fluem através da rede, o quanto residem em um servidor, ou na infraestrutura de armazenamento.
Para começar, peça aos fornecedores informações sobre o uso de VPNs, o gerenciamento de chaves, e as opções de criptografia. Antes de assinar um contrato, examine os termos relativos à privacidade de dados, como serão auditados, a confiabilidade do serviço, e contingências contra alterações.
Por fim, certifique-se de elaborar uma estratégia de mitigação de risco de modo que você seja capaz de migrar o seu trabalho para um novo provedor (ou voltar a mantê-lo in-house) com rapidez e facilidade em caso de uma eventualidade.

segunda-feira, 31 de março de 2014

Para não ter medo do imprevisto.

10 passos para montar um bom plano de contingência

(http://cio.com.br/opiniao/2014/03/26/10-passos-para-montar-um-bom-plano-de-contingencia)
Adriano Filadoro *
Publicada em 26 de março de 2014 às 09h19

Envolve mais do que um backup e armazenamento de informações num lugar fora do ambiente físico da empresa, pode ter certeza

A maioria dos negócios, hoje em dia, depende de Tecnologia da Informação e de sistemas automatizados. Para algumas empresas, ficar “fora do ar” por algumas horas pode significar perdas incomensuráveis. Tudo depende do perfil do negócio e do quanto suas atividades estão diretamente ligadas às propriedades web e aos serviços online. De todo modo, qualquer que seja o tempo de paralização, sempre há prejuízo financeiro em caso de desastres naturais, desastres provocados, ou fraudes. Daí a importância de poder contar com uma equipe que concretamente atue na prevenção desse tipo de crise e consiga detectar e resolver problemas no menor prazo possível.

A virtude mais importante, então, é ter expertise necessária para elaborar e colocar rapidamente em ação um plano que reduza os desdobramentos da interrupção de funções críticas e recupere essas operações.

Seguem 10 passos para montar um bom plano de contingência:

1. Conquistar a adesão da chefia. Gerentes, supervisores e diretores devem zelar para que todas as ações planejadas sejam colocadas em prática, determinando o que cada grupo deve fazer, em que prazo e a que custo. Esse envolvimento e comprometimento são fundamentais.

2. Montar uma equipe de gestão de crise. A formação do comitê deve levar em consideração características pessoais e profissionais necessárias para cada desafio. Entre as pessoas-chave estão o gerente operacional e o gerente de processamento de dados. Esse grupo deve estar apto a determinar as ações necessárias.

3. Desenvolver uma “análise de risco”. O comitê deve preparar uma análise de risco que inclui o impacto nos negócios em caso de desastres naturais, técnicos e humanos. Além dos desdobramentos para os negócios, essa análise também deve contemplar a segurança de registros vitais para a empresa, bem como documentos críticos. Trata-se de uma medida fundamental para reduzir prejuízos em face do inevitável.

4. Estabelecer prioridades. Tudo o que é crítico dentro de cada departamento deve ser cuidadosamente analisado e classificado como ‘essencial’, ‘importante’, ‘não essencial’. Principalmente o que diz respeito ao operacional, recursos humanos, sistemas de informação, serviço, documentação em geral (contratos, impostos etc.), registros vitais, além de políticas internas e procedimentos.

5. Determinar estratégias de recuperação. Alternativas fáceis de serem colocadas em prática devem ser avaliadas sob aspectos importantes: serviços, hardware, software, comunicação, pastas/dados, serviços on demand, sistemas e operações diversas. Essas alternativas dependem de uma criteriosa avaliação das funções do computador: site, hotsite, data centers, parque tecnológico, centro de serviços, ferramenta de vendas, arranjo de consórcio etc. É fundamental estabelecer um acordo que contemple: duração, testes, custos, procedimentos especiais de segurança, notificações de mudanças, horas destinadas à operação, equipamentos necessários, requisições profissionais, circunstâncias de emergência, possibilidade de prorrogação do contrato, garantia de compatibilidade, viabilidade, prioridades etc.

6. Avaliar o desempenho da coleta de dados. Isso inclui estar em dia com lista de backup, contatos telefônicos de pessoas-chave, registro de distribuição, inventário de comunicação, de documentação, de equipamentos, de contratos, de apólices de seguro, de hardware, dos fornecedores, dos clientes, do escritório, local de armazenamento externo, horários do serviço de backup, especificações do local temporário e outros materiais/documentos.

7. Preparar um documento descritivo. É importante preparar um documento que descreva em detalhes os procedimentos a serem tomados. Obviamente, a alta gerência deve revisar e aprovar o plano de contingência. Essa medida, embora simples, ajuda a organizar e conferir todos os procedimentos que devem ser tomados, identifica as principais etapas do processo, os procedimentos redundantes, e contribui com um ‘guia’ para o desenvolvimento dos procedimentos. Também é importante incluir a atualização do plano, a fim de contemplar qualquer mudança significativa interna, externa ou nos sistemas.

8. Desenvolver procedimentos-padrão para testes. É essencial que o plano de recuperação de desastres seja testado numa base realista ao menos uma vez por ano. O teste poderá comprovar para a alta direção que a empresa está segura ou, eventualmente, apontar quesitos que devem ser aperfeiçoados.

9. Fazer um checklist e testar cada item. Antes de concluir o plano de contingência, é necessário avaliar o papel de cada área numa cena de emergência, até a simulação de interrupção dos serviços.

10. Aprovar o plano. Uma vez que o plano foi elaborado e devidamente testado, é hora de aprová-lo junto à alta gerência – que deverá estabelecer políticas, procedimentos e responsabilidades de cada etapa do plano de contingência – além de atualizá-lo anualmente, fazendo todos os ajustes necessários.

Em resumo, o plano de recuperação de desastres envolve mais do que um backup e armazenamento de informações num lugar fora do ambiente físico da empresa.

O plano tem de incluir procedimentos testados e documentados que devem ser seguidos à risca e revisados periodicamente – ainda que nunca tenha sido necessário lançar mão dele. Nunca se sabe quando será necessário – somente quando a crise se instaura e somos pegos de surpresa.

Por isso, é preciso ter sempre em mente as claras vantagens proporcionadas por um bom plano de contingência, como redução de perdas em potencial, redução da exposição e de eventuais arranhões à imagem da marca/empresa, redução de interrupções, distribuição de responsabilidades, mais segurança e melhores resultados para os clientes, além de um corte drástico nos níveis de estresse em casos críticos.

(*) Adriano Filadoro é diretor de tecnologia da empresa Online Data Cloud