Saltear al contenido principal
Computación En La Nube: Responsabilidad Compartida

Computación en la Nube: Responsabilidad Compartida

La importancia de conocer los alcances de la responsabilidad compartida en servicios de Nube

Parte 1

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, y así 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 delimitada 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.

¿Qué necesitan analizar las organizaciones del modelo de nube para poder delimitar sus alcances en la seguridad en la 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:

  • SaaS (Software as a Service): Son las aplicaciones o software que alguna empresa desarrolló y renta su utilidad al consumidor típicamente en mensualidades o licenciamientos anuales, dependiendo también del número de usuarios que acceden, según sea el caso.

          Ejemplos: Gmail, Office 365, Spotify, Netflix.

  • PaaS (Platform as a Service): Brinda una plataforma integrada de recursos de infraestructura, virtualización, sistemas operativos, middleware y runtimes (servidores web, bases de datos y frameworks de desarrollo) para que el contratante pueda construir aplicaciones web sin tener que instalar alguna herramienta adicional.

           Ejemplos: Cloud Foundry, Salesforce, Openshift, Google App Engine.

  • IaaS (Infrastructure as a Service): Provee recursos informáticos equivalentes a hardware virtualizado tales como servidores, S.O., software, redes, memoria, capacidad de procesamiento y almacenamiento, en un esquema similar al de PaaS, de pago por consumo, permitiendo al contratante escalabilidad según la demanda del negocio y ahorros en CapEx.

          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.

Fig. 1. Componentes de un SDDC Privado y de los Modelos de Servicio de Nube.

 

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:

Trazando el límite de las responsabilidades entre el CSP y el contratante para un entorno de nube segura

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.

 

Por: Gabriel Medina, Arquitecto de Soluciones, Data Warden

CIBERSEGURIDAD APLICADA A TU NEGOCIO

Contáctanos ventas@datawarden.com.mx

 

Referencias:

https://www.isaca.org/

https://www.nist.gov/

https://cloudsecurityalliance.org/

https://datawarden.com/new/soluciones/