Segurança em cloud: empresas erram ao terceirizar cuidados

servicos_internet2

A virtualização e a computação em nuvem podem não ter degradado a segurança online da maioria das organizações, mas acabam contribuindo para situações nas quais os clientes acabam deixando pontos vulneráveis a ataques, por acreditar que o fornecedor de cloud computing é o responsável por tomar todos os cuidados.

De acordo com o analista da Technology Business Research, Ezra Gottheil, segurança e hospedagem na nuvem são duas coisas diferentes, “mas mesmo assim os clientes falham ao não analisar de quem é a responsabilidade por segurança”.

A definição, aliás, é tão mal resolvida no mercado que o Gartner resolveu elaborar relatórios detalhado sobre ofuncionamento dos serviços de nuvem, incluindo minúcias dos acordos de nível de serviço (SLAs) e de requisitos.

Em março, uma pesquisa da Cloud Security Alliance, organização que cuida de padrões da nuvem, mostrou um relatório apontando que os clientes não conhecem as práticas de segurança de cloud computing. Os provedores de serviço, por outro lado, não ajudam e se recusam a dar informação. A conclusão da organização é de que os projetos na nuvem e os riscos que ele trazem são agravados pelo fato de que a implementação dos mesmos têm como orientação benefícios hipotéticos.

E a natureza dos serviços corporativos de cloud faz com que os usuários não façam a menor ideia dos perigos aos quais estão expostos ao hospedar um site da web ou aplicação no hardware de um terceiro, diz o analista da consultoria norte-americana 451 Group.

O CEO do fornecedor de cloud FireHost, Chris Drake, confirma o que os analistas supõe: de fato os seus usuários estão presumindo que o fornecer é responsável pela manutenção da segurança, embora nem sempre seja o caso.

Desastre
A companhia norte-americana de serviços financeiros baseados em web LawLeaf quase teve de abandonar os negócios por conta de um desastre de segurança provocado por um fornecedor de cloud computing que nunca havia dado problema e que saía muito barato para a organização.

Em janeiro, o site LawLeaf.com foi afetado por um ataque de SQL injection que comprometeu o código PHP que gera as páginas. A infecção fez com que o site entrasse em colapso com frequência e, pior, forçava que usuários fizessem o download de malware. Em fevereiro, o site entrava em colapso duas vezes por semana. Em Março, era todo dia, conta o diretor geral da companhia, Tim Burke.

O problema ficou mais urgente quando o Google ameaçou banir o site do mecanismo de busca caso o problema não fosse resolvido. E como a maioria de leads de negócio vinham do site, os negócios foram diminuindo e a credibilidade foi afetada.

“Perdemos milhares de dólares por dia, mas o problema de reputação é pior. Para nosso negócio funcionar, os usuários devem enviar dados confidenciais. Se não houver confiança, não há negócios”, diz Burke. Por uma sorte do destino, tais dados acabaram não ficando vulneráveis com os ataques. Mas isso não refresca muito o ponto de vista dos usuários.

A indefinição sobre os procedimentos para evitar vulnerabilidades quase levou um serviço web a decretar falência.

A fornecedora, Bluehost, não ajudou muito. Em vez disso, notificava a companhia que o site estava fora do ar e fazia análises iniciais somente para ter a certeza de que o problema não contaminasse os servidores. “Mas eles nunca se esforçaram um pouco mais para acabar com o problema de vez. A gente tentava se livrar do malware, mas o site continuava colapsando”. Procurada pela reportagem, a Bluehost não quis se pronunciar.

A solução foi trocar de fornecedor e pagar um valor muito superior por um service que dava a garantia de trabalhar para evitar futures ataques do tipo e resolvê-los caso existissem. A companhia começou o trabalho tratando as páginas PHP da companhia para limpar totalmente os códigos. “Havia uma série de brechas para ataques SQL injection no banco de dados da companhia, embora a LawLeaf tenha feito um bom trabalho em limpar as páginas”, disse Drake, da FireHost, que foi o novo fornecedor contratado.

Burke, que chegou a oferecer mais dinheiro caso a BlueHost oferecesse um service melhor, ainda acredita que a companhia deveria ser a responsável pela segurança do site e pela resolução dos problemas com malware, num típico caso em que as responsabilidades não estão muito bem definidas. Segundo Gottheil, a responsabilidade, em tese, seria do cliente. “SQL injections acontecem por conta da formulação das páginas, o que não é responsabilidade do fornecedor”, afirma. “O caso ilustra como é importante deixar muito claro as responsabilidades de segurança de cada um”, completa.

Fonte: Desmonta&CIA

Anúncios

About Desmonta&CIA

Somos um blog que busca informar aos apaixonados por tecnologia tudo sobre o mundo de TI.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: