Existe por parte de algunas empresas una cierta reticencia a externalizar “en la nube” aplicaciones informáticas centrales para su negocio, por la pérdida de control que esto conlleva. Sin embargo, con una apropiada gestión de los riesgos y eligiendo un proveedor capaz de definir de manera conjunta con el cliente un marco de trabajo apropiado, esto es perfectamente posible. De hecho, el modelo de prestación de servicios en régimen de Cloud Computing conlleva ventajas inherentes que permiten, sobre todo a las empresas de menor tamaño y con menos recursos, beneficiarse de un nivel de seguridad y control mayores que con el hospedaje “en casa” de la aplicación.
En este artículo vamos a revisar las principales cuestiones a tener en cuenta para evaluar si una opción “en la nube” es la más apropiada para nuestras necesidades concretas. Además, analizaremos los principales riesgos que deben ser considerados y el modo de gestionarlos, cuando se aborda un proyecto para externalizar “en la nube” una aplicación de negocio relevante. Se trata de obtener el máximo beneficio del modelo de prestación de servicios en régimen de Cloud Computing y a la vez mantener el mismo grado de control sobre el negocio que se tiene con un hospedaje local del sistema.
Valoración de la criticidad desde el punto de vista de negocio
La primera cuestión que debe resolverse a la hora de plantearse un proyecto de externalización en la nube de una aplicación de negocio, es el grado de criticidad de dicha aplicación y de los datos que maneja. Ello determinará en gran medida la extensión de controles a implementar (y por tanto, el coste del servicio). De una manera sencilla, podríamos llegar a convenir en que una aplicación es crítica para el negocio si se cumple alguna de estas condiciones:
- La vida o la seguridad de personas podría verse afectada como consecuencia de la pérdida de confidencialidad de la información manejada Y/o de errores en la información y su procesamiento.
- El negocio desaparecería o sufriría importantes daños si los datos de la aplicación se perdiesen de manera irreversible.
- Que el daño reputacional y/o la cuantía de las multas, como consecuencia de que los datos de negocio se filtrasen a la competencia, a otras personas no autorizadas o a los medios, estén por encima del apetito de riesgo de la compañía.
- Que el daño reputacional y/o la cuantía de las pérdidas, como consecuencia de una baja disponibilidad y mala calidad de servicio de la aplicación, estén por encima del apetito de riesgo de la compañía.
- Que el daño reputacional y/o la cuantía de las pérdidas, como consecuencia de errores en la información manejada por la aplicación y su procesamiento, estén por encima del apetito de riesgo de la compañía.
¿Externalizar a la nube aplicaciones críticas?
Lo normal es que una compañía prefiera mantener un control lo más directo posible sobre sus aplicaciones críticas y que, por tanto, no se contemple en estos casos la opción de externalizar. Esto es especialmente cierto en casos donde los requisitos de seguridad sean muy elevados (por ejemplo, datos relacionados con la salud) y/o haya fuertes exigencias legales. En las empresas de mayor tamaño y que manejan mayores recursos, la externalización de aplicaciones críticas no suele ser la mejor opción.
Sin embargo, otras empresas de menor tamaño deben valorar adicionalmente si disponen de las infraestructuras, instalaciones y del personal técnico necesarios para dar soporte, administrar y garantizar la seguridad de aplicaciones de este tipo. Si no es así, es posible plantearse la externalización en la nube, aunque el modelo final de servicio requerido será más parecido al de la externalización tradicional de hosting y administración de sistemas, por los requisitos adicionales de control que habrá que negociar e implantar (ver apartado de análisis de riesgos, más adelante) y que obviamente influirán en el coste final.
Otras cuestiones importantes a considerar
Además de las consideraciones relacionadas con la criticidad de la aplicación, hay otros factores que deben ser tenidos en cuenta a la hora de valorar si la opción de externalizar en la nube es la más apropiada:
- ¿Requiere la empresa un alto grado de adaptación de la aplicación a sus necesidades particulares, o puede adaptarse a la funcionalidad ofrecida por una aplicación “estándar”?
- ¿Requiere la organización un ciclo de cambios (mantenimiento y mejoras) en la aplicación que implique mucha frecuencia y velocidad de implementación?
- Tiene la organización necesidad de integrar los datos y los procesos de la aplicación con otros sistemas de la compañía?
Si a todas o a alguna de estas preguntas la respuesta es afirmativa, lo más probable es que una solución estándar de aplicación en modo Software como Servicio (SaaS), no sea la opción más adecuada. Si aun así la opción de externalizar en la nube es considerada como interesante, la alternativa podría ser desarrollar nuestra propia aplicación y desplegarla en la nube en la modalidad de Plataforma como Servicio (PaaS); en cuyo caso la administración y operación de la aplicación correrá por nuestra cuenta, pero esto nos dará el grado de libertad requerido.
La siguiente cuestión es mucho más fácil de valorar:
- Teniendo en consideración el modo de facturación por uso y el número de usuarios, ¿sale rentable el uso en la nube?
Análisis y gestión de riesgos
En esta sección vamos a analizar los principales riesgos a tener en cuenta en casos de aplicaciones de negocio en la nube. La respuesta que se dé a las cuestiones aquí planteadas dependerá en gran medida de la criticidad de la aplicación. Dependiendo de las circunstancias concretas, algunos de los riesgos y controles planteados aplicarán y otros no; sin embargo, son cuestiones relevantes con independencia del modelo de despliegue de aplicación elegido (software como servicio, plataforma como servicio, etc…). La diferencia en estos casos radicará en quién será el responsable de poner en práctica el control, si el proveedor o nosotros. Es muy importante que el cliente cuente con el asesoramiento y soporte legal y de expertos técnicos y de seguridad de la información para la definición de los términos del contrato y procedimientos con el proveedor.
| Riesgo | Ejemplos/Comentario | Controles a Considerar |
| Problemas de disponibilidad de la aplicación impiden que se pueda trabajar de acuerdo al nivel de servicio requerido. | Ejemplos: la aplicación no es accesible desde Internet, los tiempos de respuesta son tan bajos que impiden que se pueda trabajar, las actividades o requisitos de otras empresas que también usan la aplicación afectan al servicio del resto de usuarios. | Definir un acuerdo de nivel de servicio (ANS) en el que se especifiquen todos los requisitos de disponibilidad y rendimiento de la aplicación, el modo de medirlos y las penalizaciones en caso de no cumplimiento. |
| Errores frecuentes en los procesos de la aplicación impiden que se pueda trabajar de acuerdo al nivel de servicio requerido. | Ejemplos: las funciones devuelven errores frecuentemente y no se puede trabajar, los procesos funcionan mal y los datos contienen errores. | Definir un acuerdo de nivel de servicio (ANS) en el que se especifiquen todos los requisitos de disponibilidad y rendimiento de la aplicación, el modo de medirlos y las penalizaciones en caso de no cumplimiento.Hacer referencia en el propio contrato a los estándares y procedimientos de control de calidad del software que se van a emplear. Poder auditar su cumplimiento por parte del proveedor.Realizar previamente a la contratación del servicio un piloto en el que se pueda evaluar la calidad del software. |
| Pérdida de confidencialidad de datos de la aplicación. | Ejemplos: Un empleado de una compañía que es usuaria de la aplicación puede acceder a los datos de otra empresa que también es cliente de la aplicación, una falla en la seguridad del proveedor de la aplicación tiene como resultado el robo de la base de datos. | Establecer un modelo de red privada, o al menos establecer una instancia de la aplicación y la base de datos dedicada en exclusiva y con restricciones de acceso especificadas en el contrato.Establecer cifrado de la base de datos o de los campos críticos de datos. Los mecanismos de cifrado y gestión de claves deben ser los estándares aceptados de la industria.Establecer una cláusula de responsabilidad en la que el proveedor se comprometa a resarcirnos en caso de incidente por negligencia. |
| Incumplimiento de la legislación de protección de datos al quedar los datos almacenados en países no compatibles con la legislación europea. | Ejemplo: El proveedor de la aplicación decide subcontratar un nuevo proveedor de Cloud sin caer en la cuenta de que los sistemas pueden ser reubicados en un país no compatible con nuestra legislación. | Establecer por contrato las ubicaciones físicas aceptables de la base de datos.Establecer limitaciones para que el proveedor deba informarnos y pedir autorización previa antes de subcontratar el servicio a otros terceros. |
| Pérdida irreversible de la base de datos de la aplicación. | Ejemplos: Una catástrofe o simple fallo de hardware / software en el proveedor causa la pérdida, actos de sabotaje en el proveedor. | Establecer por contrato los requisitos de copias de respaldo necesarios. Definir de manera detallada los procedimientos de realización de estas copias y los de recuperación de datos y periodo de retención.Asegurarse de que haya copias redundantes y protegidas de la información en diferentes ubicaciones físicas.Establecer por contrato unos requisitos de arquitectura técnica del servicio que permitan garantizar la redundancia del mismo (infraestructura, aplicaciones y base de datos), de modo que se puedan satisfacer los requisitos de disponibilidad, aún en caso de catástrofe en alguno de los centros de proceso de datos. |
| Quiebra del proveedor de servicios tiene como consecuencia el cese del servicio. | Realizar, previo a la contratación, una indagación sobre la solvencia del proveedor y su viabilidad.Realizar periódicamente copias de seguridad de los datos de la aplicación y almacenarlos de manera segura en las instalaciones del cliente por si fuera necesario acceder a ella. La periodicidad de estas copias de respaldo debe establecerse como consecuencia del análisis del máximo nivel de pérdida de información soportable.Requerir que por contrato se establezca el derecho de acceso y uso del código fuente de la aplicación en caso de cese de actividad (acuerdo de escrow). | |
| Dificultades añadidas para poder recuperar los datos y migrar el servicio a otro proveedor si así lo deseamos. | Ejemplos:Ante un mal servicio podríamos tener dificultades para migrar el servicio a otro proveedor, porque la tecnología usada es propietaria, porque el actual proveedor no proporciona el soporte necesario para realizar la tarea. Ello nos lleva a estar en cierta medida “cautivos” del actual proveedor. | Definir al amparo del contrato un procedimiento para articular la finalización del servicio. Dicho procedimiento debe contemplar las actividades de soporte del proveedor para facilitar la migración de los datos a otro proveedor.Realizar periódicamente copias de seguridad de los datos de la aplicación y almacenarlos de manera segura en las instalaciones del cliente por si fuera necesario acceder a ella. La periodicidad de estas copias de respaldo debe establecerse como consecuencia del análisis del máximo nivel de pérdida de información soportable.Tratar de seleccionar un proveedor que use tecnologías estándar y no propietarias. |
| Pérdidas económicas como consecuencia de una incapacidad para acometer cambios requeridos en la aplicación en el plazo de tiempo necesario. | Ejemplo: No ser capaz de atender la demanda de clientes por no poder adaptar la aplicación a tiempo. | Definir un acuerdo de nivel de servicio (ANS) en el que se especifiquen todos los requisitos del procedimiento de gestión de cambios, el modo de medirlos y las penalizaciones en caso de no cumplimiento.Hacer referencia en el propio contrato a los estándares y procedimientos de gestión de cambios del software que se van a emplear. Poder auditar su cumplimiento como parte del proveedor. |
| Peticiones de evidencias por parte de auditores, organismos públicos, investigadores forenses o autoridades judiciales no pueden ser atendidas como consecuencia de la no existencia de registros referentes a las actividades de usuarios en la aplicación, la base de datos o el sistema operativo. | Ejemplos: No poder justificar a los auditores el cumplimiento de procedimientos o legislación aplicable, no poder ejercer debidamente la defensa en un litigio al no poder aportar pruebas. | Establecer bajo contrato una relación de registros de auditoría necesarios, así como las necesidades de retención y acceso de los mismos. Definir en el contrato el formato admisible de cada registro del inventario.Establecer por contrato los procedimientos puestos a disposición del cliente para poder acceder bajo demanda a esta información. |
| Actividades no autorizadas en el sistema como consecuencia de controles débiles de gestión de acceso a la aplicación o la base de datos. | Ejemplos: Posibilidad de suplantar la identidad de un usuario autorizado de la aplicación por la debilidad de la contraseña usada, procedimiento inseguro de gestión de contraseñas permite que un usuario reciba la contraseña de otro, contraseñas no cifradas en la base de datos, etc… | De acuerdo con el nivel de criticidad de la aplicación / datos establecer en conjunción con el proveedor y con el soporte de expertos en la materia:A) Un modelo de red privada, o al menos establecer una instancia de la aplicación y la base de datos dedicada en exclusiva y con restricciones de acceso especificadas en el contrato.B) Mecanismos de autenticación fuerte para acceder a la aplicación (ej: doble factor de autenticación).C) Establecer cifrado de la base de datos o de los campos críticos de datos. Los mecanismos de cifrado y gestión de claves deben ser los estándares aceptados de la industria.
D) Asegurarse de que las contraseñas de aplicación incorporan las mejores prácticas en cuanto a gestión de las mismas (longitud, complejidad, cambio periódico, almacenamiento seguro, procedimiento de reinicio de la password y de gestión de usuarios).
|
| Vulnerabilidades en la infraestructura técnica del proveedor propician que se desarrollen actividades de hacking, afectando a la confidencialidad, integridad o disponibilidad de la aplicación y de los datos. | Ejemplos: Como consecuencia de vulnerabilidades en los sistemas, hackers externos al proveedor consiguen explotar estas vulnerabilidades y tomar el control de los servidores. Estas mismas vulnerabilidades pueden ser explotadas además por otros clientes del proveedor o por empleados o personal subcontratado del mismo. | Establecer un modelo de red privada, o al menos establecer una instancia de la aplicación y la base de datos dedicada en exclusiva y con restricciones de acceso especificadas en el contrato.Establecer mecanismos de autenticación fuerte para acceder a la aplicación (ej: doble factor de autenticación).Definir, con el soporte de personal técnico especializado, el régimen de actualizaciones y gestión de vulnerabilidades de los sistemas relevantes para la prestación del servicio, que el prestador de servicios deberá acometer. Establecer contractualmente estos requisitos y acordar con el proveedor un procedimiento para que a petición del cliente el proveedor proporcione informe detallado del estado de vulnerabilidad de los sistemas.Acordar con el proveedor que éste lleve a cabo regularmente, con ayuda de personal cualificado, auditorías de seguridad periódicas de las infraestructuras relevantes y de la aplicación y la base de datos. El alcance de estas auditorías debe ser acordado con el cliente y éste tendrá derecho a acceder a los informes de resultados de las mismas y a información detallada sobre las acciones correctoras llevadas a cabo por el proveedor.
El proveedor deberá tener montando un procedimiento de monitorización de seguridad de sus sistemas, de modo que maximize la probabilidad de detección por su parte de una intrusión en sus sistemas. Este procedimiento debe estar referido y acordado contractualmente. Además, el proveedor deberá definir por contrato un procedimiento de gestión y notificación de incidentes de seguridad. Establecer una cláusula de responsabilidad en la que el proveedor se comprometa a resarcirnos en caso de incidente por negligencia
|
| Desprotección de datos como consecuencia de procedimientos inexistentes o inadecuados de fin de la relación contractual | Acordar con el proveedor un procedimiento para el borrado seguro de la información a la finalización del servicio.Establecer cifrado de la base de datos o de los campos críticos de datos. Los mecanismos de cifrado y gestión de claves deben ser los estándares aceptados de la industria. | |
| Acceso ilegal a contraseñas de acceso a la aplicación como consecuencia de interceptación de los datos transmitidos por la red. | Requerir cifrado de las comunicaciones en el acceso a la aplicación. Por ejemplo, haciendo uso de SSL. | |
| Problemas derivados de la jurisdicción aplicable en caso de litigio. | En muchos contratos estándar propuestos por proveedores de servicios, se establece que la legislación aplicable es la del país del proveedor. Esto puede suponer problemas y costes añadidos para los clientes que deben someterse a jurisdicción extranjera en caso de necesidad de recurrir a los tribunales. | Establecer por contrato que la legislación aplicable, en caso de incidentes relacionados con el cumplimiento de normativas, reglamentos y leyes responsabilidad del cliente del servicio, será la de la nacionalidad de este. |
Consideraciones finales
Lo que queda claro es que tratándose de aplicaciones relevantes para el negocio y especialmente cuando implican el procesamiento de datos personales o sensibles, la única opción será contar con un proveedor que esté dispuesto a firmar un contrato y acuerdo de nivel de servicio específico, de modo que nos ayude a cumplir con nuestros requisitos. En el contrato deberán especificarse los roles y responsabilidades, así como los procedimientos de control que se hayan derivado del análisis de riesgos previo. Muchos proveedores no estarán interesados en un acuerdo de este tipo, ya que esta capacidad de adaptación y de ofrecer un servicio a la medida del cliente va en contra de su modelo de negocio, basado en la máxima simplicidad, el ahorro de costes y en la sub contratación. Este tipo de proveedores necesitan que todos sus clientes firmen un contrato de adhesión estándar que normalmente no cubre las necesidades del cliente corporativo en los casos que estamos tratando.
Cuando se trata de “poner en la nube” aplicaciones de negocio críticas, es necesario contar con proveedores capaces de adaptarse a nuestras necesidades y de prestar servicios en diferentes modalidades de despliegue; por ejemplo, desarrollando y gestionando para uno o varios clientes una nube privada de acuerdo a unos requisitos de seguridad y control previamente acordados. En la redacción del acuerdo será necesario hacer un gran esfuerzo de definición de los procedimientos que aplicarán y las clausulas contenidos en el contrato, para ello, será necesaria la participación de expertos de seguridad, tecnología y área de Legal. Esto nos llevará a escenarios más próximos al tradicional hosting y administración.
Esperemos que este artículo, así como los otros que ya hemos publicado aquí sobre este tema, sirvan de guía o cuando menos de inspiración para aquellas personas involucradas en un proceso de externalización en la nube…Gracias y hasta pronto
Otros artículos relacionados
Negocios bajo control 
por eso prefiero lo clásico ya que aun hay muchas dudas sobre este tema y más de seguridad