Los peligros del modelo cloud computing

La idea de cloud computing (informática en nube) –inspirada en una arquitectura cuyo estado natural consiste en una pila de recursos fuera de la empresa, proporcionados por un proveedor externo, y soportados y compartidos a través de Internet- ha ido ganando ímpetu en los últimos meses. Sus promesas de reducción de costes y de mejora de la flexibilidad TI han conseguido despertar el interés de las empresas, aparte del de muchos consumidores. Pero el uso de modelos cloud computing también conlleva algunos riesgos, entre los que se incluyen peligros relacionados con la conformidad, la disponibilidad y la integridad de los datos corporativos.

Según los expertos, muchas compañías no reflexionan sobre estos riesgos con la suficiente seriedad. Por ejemplo, el tener en funcionamiento la tecnología apropiada de recuperación ante fallos constituye un componente importante para securizar lo que ha venido a denominarse la “cloud” (nube), un elemento que, no obstante, a menudo las empresas pasan por alto, según Josh Greenbaum, director de Enterprise Applications Consulting. Lo más paradójico es que la mayoría de esas mismas compañías se aseguran de contar con sistemas de recuperación ante fallos de servicios bien consolidados y probados, como la alimentación eléctrica. “Si cualquiera se acerca a las instalaciones de una gran organización, seguro que podrá ver en el exterior alguna construcción que albergue un sistema de potencia alternativo por si fallara el principal. Ninguna depende únicamente de la red pública”, explica Greenbaum, quien subraya que la situación en el caso de los servicios cloud computing no debería ser diferente.

En algunos casos, el riesgo de fallo resulta demasiado alto para depender de la cloud. Por tanto, si toman la decisión de colocar algunos servicios y aplicaciones sobre ella, antes de hacerlo, las empresas deberían preguntarse cuál sería la forma adecuada de gestionar los riesgos.

David Cearley, vicepresidente y analista de Gartner, cree que el establecimiento de límites al uso de tecnologías cloud resulta esencial y que, en consecuencia, las empresas deberían analizar con la máxima atención, midiendo siempre los riesgos frente a las eficiencias que la cloud computing pueda aportar en cada momento y lugar de aplicación. Quizá cediendo algún control sobre sus datos, las organizaciones pueden conseguir mejores economías de costes. Pero que este beneficio consigan compensar los riesgos dependerá de cada caso, y para averiguar si así es habrán de tenerse en cuenta tanto los ahorros y las eficiencias que se lograrán, como el nivel de sensibilidad de los datos afectados. Y, en cualquier caso, la decisión sobre si el riesgo merece la pena habrá de ser tomada conjuntamente por los responsables TI y ejecutivos. Según Cearley, cualquier recurso o servicio TI terminará con el tiempo estando disponible como un servicio sobre la cloud, pero en cada negocio particular habrá algunos que no convenga colocar en ella.

Existen diferentes motivos que hacen desaconsejable consumir determinados servicios TI de la cloud. Entre ellos, la incertidumbre respecto de la ubicación concreta de los datos. “En una pila compartida fuera de la empresa, ésta no tendrá ningún conocimiento o control sobre el lugar en que corre cada recurso. Por tanto, si existe alguna preocupación acerca de la localización de los datos, por ejemplo, tal preocupación podría representar un motivo para no utilizar la cloud en las aplicaciones y servicios relacionados con tal información”, explica Cearley.

La responsabilidad caerá sobre la empresa
Por otra parte, aunque existe una gran cantidad de estándares, incluidos servicios como SAS Interaction Management, aplicables para la seguridad y conformidad TI -y que gobiernan ya la mayoría de las interacciones de negocio en múltiples compañías-, y aunque con el tiempo tales estándares habrán de ser trasladados a la cloud, de momento aún no lo han sido, como señala Greenbaum. Los suministradores de servicios y aplicaciones TI “en nube”, entre los que cabe destacar como pure players a Salesforce.com y Netsuite, “no ofrecen la clase de gobernabilidad y gestión de riesgos y conformidad a que obligan las regulaciones existentes”. Y hasta que surjan modelos y estándares de seguridad para la arquitectura cloud computing, la mayor parte del riesgo, y la responsabilidad si algo va mal, pesará sobre los hombros de los responsables de TI, no en los de los proveedores de servicios cloud computing.

Kristin Lovejoy, directora de la división de gestión de seguridad, gobernabilidad y riesgos de IBM, coincide en que, en último término, es el consumidor de los servicios el responsable de mantener la confidencialidad, integridad y la disponibilidad de los datos. De ahí el peligro que supone dejarlos en manos de un proveedor de servicios externos sin las suficientes garantías.

Lovejoy cita a modo de ejemplo el hecho de que la regulación HIPAA (Health Insurance Portability And Accountability Act) no recoja detalles específicos relativos al outsourcing o al offshoring, lo que deja un cierto vacío normativo al respecto. Simplemente, en sus secciones 164.308 y 164.314, exige que cualquier compañía consiga garantías de que toda aquella empresa que maneje sus datos como tercera parte, los protegerá con el suficiente celo. Es decir, cabe deducir que será la compañía cliente la responsable de haber considerado suficientes las garantías en cuestión si finalmente no lo resultan.

Cómo elegir las aplicaciones a poner sobre la cloud sin peligro
Ante esta situación, hasta que el control de la información sobre la cloud avance, Lovejoy recomienda a las empresas seguir el principio “context versus core” (contexto frente a núcleo), de Geoffrey Moore, estratega de negocio y socio director de TCG Advisors.

Moore define las prácticas core -de núcleo de negocio o nucleares- como aquellas que proporcionan a la empresa una diferenciación competitiva. A diferencia de éstas, las prácticas de contexto –o contextuales- son generalmente de naturaleza interna. Entre estas últimas cabe citar los servicios de recursos humanos y de gestión de nóminas, por ejemplo. Las aplicaciones que soportan ambos tipos de prácticas, las de núcleo y las de contexto, pueden a su vez dividirse en aplicaciones de misión crítica y de misión no-crítica. “Si una aplicación de misión no-critica queda fuera