Y si lo tercerizo y me pasa esto?

El pasado 8 de Agosto parte del servicio de “Cloud Computing” de Amazon para Europa estuvo fuera de servicio como consecuencia del impacto de un rayo en uno de los transformadores de una de sus estaciones ubicada en Dublín.

El rayo provocó una explosión y un incendio impidiendo la correcta alimentación de sus sistemas a partir de generadores auxiliares y dando lugar a la caída de Amazon Elastic Compute Cloud (EC2) . Como consecuencia, multitud de servicios y páginas alojadas en sus servidores quedaron inoperativas afectando incluso a portales tan relevantes como Paypal, Filmin, Menéame, las tiendas de Amazon en Reino Unido y Alemania o servicios como CloudWatch o BPOS de Microsoft.

Tales hechos invitan a reflexionar de nuevo sobre “la nube” y el nivel de confianza que los usuarios depositan sobre los servicios de “Cloud Computing” de un tercero. Y es que con los servicios basados en cloud muchos componentes de los sistemas de información quedan fuera del control directo de la organización suscriptora.

Gestión de riesgos

Dejando de lado los aspectos legales y el cumplimiento normativo sobre la propiedad de la información, los cuales crean el primer marco de confianza con la empresa proveedora de dichos servicios, la gestión de riesgos representa otro de los aspectos vitales que conforman el nivel de confianza de los usuarios. Teniendo en cuenta que la gestión de riesgos es el proceso de identificar y valorar los riesgos realizando los pasos necesarios para reducirlos a un nivel asumible, los sistemas cloud requieren, al igual que los sistemas tradicionales, asegurar que todos los controles encargados de valorar y gestionar los riesgos de sus sistemas de cloud están implementados correctamente a lo largo de su ciclo de vida y cumplen con los requisitos de seguridad de la empresa.

Fallos temporales y disponibilidad

A pesar de utilizar infraestructuras orientadas para dar un alto nivel de servicio y una alta disponibilidad, los servicios cloud pueden experimentar descensos en el rendimiento o fallos. Algunos ejemplos de esto son:

• Febrero 2008: fallos de un servicio de almacenamiento en la nube por un periodo de tres horas que afectó a sus suscriptores, entre ellos Twitter y otras compañías.
• Febrero 2010: Gmail sufre una pérdida de acceso a 500.000 cuentas por una actualización de software; alguna de las cuentas se restauraron mediante copias de seguridad en cinta.

Los tiempos de recuperación en caso de fallo o pérdida de servicio deben estar recogidos por el proveedor en sus planes de contingencia y continuidad. Así mismo, deben disponer de infraestructuras de respaldo para poder prestar un servicio mientras se prolonga el periodo de recuperación. Otra opción es tener un acuerdo para que otro proveedor procese los datos mientras se realiza la restauración del servicio.

En el caso que acontece a Amazon, aunque sus generadores de emergencia entraron en funcionamiento, otro fallo en la refrigeración en los servidores generó la caida de sus sistemas. Otro error similar que afecto a la plataforma de Amazon Elastic Compute Cloud ocurría en Abril de este año también debido a deficiencias en el paso de energía de generadores de la misma compañia.

Por último, existe un denominador común a todos estos aspectos mencionados, se trata de los contratos de acuerdo de servicio. Con una fiabilidad del 99,95% se producirían unas 4,38 horas de caída en un año, excluyendo las paradas de mantenimiento, que no se recogen en estos acuerdos. Todas las recomendaciones en cuanto a este asunto indican que éstos deben de ser revisados y creados específicamente, detallando los controles, las normativas, las medidas de protección, los plazos de recuperación del servicio, etc.

Esto tipo de incidentes han vuelto a sacar a debate las medidas de seguridad existentes entorno a los servicios de “Cloud Computing”.

Fuente: Inteco