Segurança em cloud: empresas erram ao terceirizar cuidados


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 o funcionamento 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 eles 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 fornecedor é 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 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 futuros 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.

Por CIO/EUA

Anúncios
Esta entrada foi publicada em Cloud Computing, Security. ligação permanente.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s