Modelo de responsabilidad compartida: IaaS, PaaS y SaaS

Los servicios en la nube se ofrecen mediante tres modelos principales, cada uno con un nivel de abstracción diferente. Infrastructure as a Service (IaaS) proporciona capacidad de cómputo, almacenamiento y redes sin procesar. Platform as a Service (PaaS) añade el sistema operativo, el middleware y los entornos de ejecución. Software as a Service (SaaS) ofrece aplicaciones completamente funcionales a través de Internet. Comprender estos modelos es esencial porque las responsabilidades de seguridad difieren considerablemente entre ellos.

El modelo de responsabilidad compartida define qué tareas de seguridad son obligación del proveedor de nube y cuáles corresponden al cliente. El modelo suele resumirse así: el proveedor es responsable de la seguridad de la nube (centros de datos físicos, hipervisores e infraestructura de red), mientras que el cliente es responsable de la seguridad en la nube (datos, gestión de acceso, seguridad de las aplicaciones y configuración). No comprender este límite es una de las principales causas de incidentes de seguridad en la nube.

En IaaS, el cliente asume la mayor parte de la responsabilidad de seguridad. El proveedor de nube protege la infraestructura física, el hipervisor y la red subyacente. El cliente es responsable de: la instalación, aplicación de parches y refuerzo de la seguridad del sistema operativo; la configuración del entorno de ejecución y el middleware; la seguridad de las aplicaciones; las reglas de los grupos de seguridad de red; las políticas de IAM y la gestión de usuarios; el cifrado de los datos en reposo y en tránsito; y la configuración de cumplimiento. IaaS ofrece el máximo control, pero requiere el máximo esfuerzo de seguridad.

En PaaS, el proveedor asume la gestión del sistema operativo y del entorno de ejecución. El cliente ya no aplica parches al sistema operativo ni administra el middleware; de ello se encarga el proveedor. Sin embargo, el cliente sigue siendo responsable de: la seguridad del código de la aplicación (sin SQLi, XSS, etc.), la clasificación y el cifrado de los datos, la gestión de identidades y accesos, la configuración de la aplicación (variables de entorno y gestión de secretos) y la seguridad de las API. PaaS traslada parte de la carga al proveedor, mientras los clientes se centran en la lógica de la aplicación.

En SaaS, el proveedor gestiona prácticamente todo. Las principales responsabilidades de seguridad del cliente son: la gestión de acceso (quién tiene cuentas, aplicación de MFA y revisión de permisos), la gobernanza de datos (qué datos se cargan y durante cuánto tiempo se conservan), la seguridad de la configuración (ajustes de privacidad, permisos de uso compartido e integraciones de terceros) y el cumplimiento de las políticas de uso aceptable. Muchas filtraciones en SaaS se deben a configuraciones incorrectas de uso compartido o a permisos excesivos de aplicaciones de terceros, no a fallos del proveedor.

Algunos controles son compartidos entre el proveedor y el cliente. Por ejemplo, el cifrado: el proveedor de la nube puede ofrecer servicios de cifrado (KMS, cifrado predeterminado), pero el cliente debe habilitarlos, configurar la gestión de claves y elegir algoritmos adecuados. Del mismo modo, en cuanto a la identidad, el proveedor proporciona herramientas de IAM, pero el cliente debe configurar políticas de privilegio mínimo y exigir MFA. Suponer que el proveedor gestiona un control compartido y no configurarlo es un error frecuente y peligroso.

El modelo de responsabilidad compartida falla con mayor frecuencia por errores de configuración del cliente, no por fallos del proveedor. Algunos ejemplos clásicos son: buckets de S3 que se dejan accesibles públicamente (la brecha de Capital One de 2019, que expuso 100 millones de registros), roles de IAM con permisos excesivos que permiten la escalada de privilegios, grupos de seguridad con reglas entrantes 0.0.0.0/0 en puertos confidenciales y credenciales predeterminadas que no se cambian en bases de datos implementadas en la nube. La infraestructura subyacente del proveedor era segura; la configuración del cliente no lo era.

Un desafío clave del modelo compartido es la visibilidad. En los entornos locales, los equipos de seguridad controlan todos los registros. En la nube, es posible que los registros de la infraestructura del proveedor no estén disponibles. Los clientes deben habilitar servicios de registro nativos de la nube: AWS CloudTrail, Azure Monitor y GCP Cloud Audit Logs registran las llamadas a la API y los cambios de configuración. Si no se habilitan estos servicios, una organización no tiene un registro de auditoría que muestre quién hizo qué en su entorno de nube, lo que supone una importante carencia de cumplimiento y análisis forense.

Cuando las organizaciones utilizan proveedores de servicios gestionados (MSP) para operar entornos de nube, la responsabilidad se divide entre tres partes. El cliente debe asegurarse de que los contratos (SLA y DPA) definan claramente las obligaciones de seguridad. Las aplicaciones de nube de terceros a las que se accede mediante SaaS introducen complejidad adicional: otorgar consentimiento de OAuth a una aplicación con permisos excesivos proporciona a esa aplicación acceso a sus datos. Revisar y auditar periódicamente los consentimientos de OAuth de terceros forma parte de una buena higiene de seguridad de SaaS.

Los requisitos de cumplimiento no desaparecen porque las cargas de trabajo se hayan trasladado a la nube. HIPAA exige un Business Associate Agreement (BAA) con los proveedores de nube que gestionan PHI; AWS, Azure y GCP ofrecen BAA. PCI-DSS exige que el entorno de nube esté incluido en el alcance de la evaluación; las matrices de responsabilidad compartida de los proveedores documentan qué controles de PCI se cumplen. Las organizaciones deben comprender qué cubre el proveedor y qué deben implementar por su cuenta para superar las auditorías.

El modelo de responsabilidad compartida tiene implicaciones legales. Los Terms of Service y los Service Level Agreements (SLA) del proveedor de nube especifican las garantías de disponibilidad y las exclusiones. Los Data Processing Agreements (DPA) contemplados en el RGPD definen las obligaciones del encargado del tratamiento. Si se produce una brecha debido a un fallo del proveedor, el cliente puede reclamar las medidas correctivas previstas en el SLA. Si la brecha se debe a un error de configuración del cliente, el proveedor no asume ninguna responsabilidad. Comprender los contratos es tan importante como comprender los controles técnicos.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que el modelo de responsabilidad compartida define las obligaciones de seguridad del proveedor y del cliente en IaaS, PaaS y SaaS, que los clientes asumen la mayor parte de la responsabilidad de seguridad en IaaS y la menor en SaaS, pero siempre son responsables de la gestión de acceso y la gobernanza de los datos, y que los errores de configuración del cliente, no los fallos del proveedor, son la principal causa de las brechas en la nube. A continuación, exploraremos la seguridad del almacenamiento en la nube y los riesgos de exposición de datos.