Existe mucha desinformación y omisión sobre este tópico debido al acelerado crecimiento de los nuevos esquemas comerciales que trae la computación en la nube y a su ágil adopción por parte de las organizaciones que buscan incursionar, crecer o evolucionar su negocio en el mercado competitivo, sin embargo, comprender los límites de responsabilidad compartida entre los CSP (Cloud Service Provider) y los contratantes es fundamental para lograr una exitosa estrategia de TI que cumpla con los objetivos generales de la empresa, para evitar poner en riesgo información sensible de empleados, clientes, proveedores y todos los que participen en el flujo del negocio.
La mayoría de las organizaciones que contratan servicios de nube pública en el modelo de ‘Infraestructura como Servicio’ erróneamente dan por hecho que los temas de “seguridad en la nube” recaen justamente en el Proveedor de Servicios de Nube.
Sin embargo, para los CSP, como propietarios de su infraestructura y sus métodos de gestión aplicada, naturalmente tienen bien comprendida y delimitar su responsabilidad en cuanto a la “seguridad de la nube”, la cual aplica básicamente sobre los componentes de hardware y software que proveen. Sucede lo mismo con los otros 2 modelos de servicio de nube.
Primeramente, revisar qué componentes integran a los modelos, IaaS, PaaS y SaaS para analizar física y lógicamente lo que se está contratando y poder asegurarlo con base en las mejores prácticas de la industria.
El NIST (Instituto Nacional de Estándares y Tecnología– U.S) declara 3 modelos de entrega del servicio en la nube en su publicación SP 800-144:
Ejemplos: Gmail, Office 365, Spotify, Netflix.
Ejemplos: Cloud Foundry, Salesforce, Openshift, Google App Engine.
Ejemplos: Amazon Web Services, Google Cloud Platform, Microsoft Azure.
Además de 5 características esenciales (autoservicio bajo demanda, elasticidad rápida, amplio acceso a la red, servicio medido, y agrupación de recursos) y 4 tipos de despliegue de nube (pública, privada, comunitaria e híbrida).
Estos atributos son los que dan vida a un modelo de computación en la nube, según el NIST.
En la figura 1 se observan los componentes que generalmente conforman una arquitectura de Centro de Datos Definido por Software (SDDC) o Nube Privada, comparados con los componentes que se ofrecen en cada uno de los modelos de servicio de nube, permitiendo así trazar el alcance en cuanto a la seguridad de la nube por parte del CSP y la seguridad en la nube por parte del contratante:
Una organización que cuenta con una arquitectura de SDDC para consumir servicios de Nube Privada en sus instalaciones, por razones coherentes es la única responsable de aplicar y gestionar una estrategia de seguridad integral que contemple a Personas, Políticas y Tecnología (que vaya desde el edificio físico, el clima, el personal, hasta el hardware y software) abarcando implícitamente los 14 dominios descritos en la Guía de Seguridad para Áreas Críticas enfocadas en Computación en la Nube v4 por la Cloud Security Alliance (CSA, organización que promueve el uso de las mejores prácticas para asegurar la computación en la nube).
Por consiguiente, en los modelos IaaS, PaaS y SaaS, el proveedor del servicio únicamente es responsable de proteger su infraestructura ofertada basados en la figura 1, es decir, del aseguramiento y del correcto funcionamiento físico y lógico de las capas o componentes que proporciona al contratante, cumpliendo con las 5 características esenciales antes mencionadas.
De la misma forma el contratante, independientemente del modelo de nube que elija, siempre será responsable del gobierno de sus datos y la gestión de derechos, de cuentas y de acceso, así como de la seguridad de los puntos finales de cliente.
En la segunda parte de este artículo haremos una separación de responsabilidades de las partes (el CSP, el contratante y el alcance mutuo) con base en lo que describen algunos de los principales CSP en su oferta, y notaremos que existen formas de poder transferir algunas responsabilidades de seguridad en la nube a otras empresas mediante un esquema de ‘Seguridad como Servicio’ (SecaaS), cubriendo dominios críticos de seguridad de TI.
