El modelo de responsabilidad compartida en la nube es uno de los conceptos más importantes en materia de seguridad en la nube, y uno de los que más se malinterpretan. Esta malinterpretación sigue un patrón concreto: las organizaciones dan por sentado que el traslado a la nube transfiere al proveedor una mayor responsabilidad en materia de seguridad de la que realmente le corresponde. Esta suposición genera brechas de seguridad que los atacantes aprovechan activamente.
Gartner estima que, hasta 2026, el 99 % de los fallos de seguridad en la nube serán culpa del cliente, principalmente debido a una configuración incorrecta. Esa cifra no supone una crítica a la seguridad de la nube. Es una indicación de dónde se sitúa el límite de la responsabilidad. La infraestructura del proveedor de la nube suele estar bien protegida. Las configuraciones erróneas, los depósitos de almacenamiento expuestos, los roles de IAM con permisos excesivos y las máquinas virtuales sin parches se encuentran casi en su totalidad en el lado del cliente.
Esta guía aclara exactamente cuáles son las responsabilidades de los proveedores de servicios en la nube, cuáles son las de los clientes y sus MSP, y cómo varían los límites según los distintos modelos de servicios en la nube. La plataforma de Kaseya cubre la parte correspondiente al cliente del modelo de responsabilidad compartida para más de 50 000 MSP y equipos de TI en todo el mundo.
El principio fundamental
Todos los principales proveedores de servicios en la nube —AWS, Microsoft Azure y Google Cloud— publican un modelo de responsabilidad compartida que define la división de tareas en materia de seguridad. El principio es el mismo en todos ellos: el proveedor se encarga de la seguridad de la nube; el cliente, de la seguridad de lo que hay en ella.
Las responsabilidades del proveedor abarcan la infraestructura física (centros de datos, servidores, hardware de red), la capa de hipervisor, la estructura de red, así como la disponibilidad y fiabilidad de los managed services ofrece. Todo lo que el cliente implemente en el entorno de la nube —sistemas operativos, aplicaciones, datos, configuración de identidades y controles de acceso a la red— es responsabilidad del cliente o de su proveedor de servicios gestionados (MSP).
La consecuencia práctica es que un entorno en la nube no es seguro por defecto. Su seguridad depende de que el cliente lo configure correctamente. Una instancia de EC2 con un sistema operativo sin parches es responsabilidad del cliente. Un depósito de S3 con acceso público habilitado es responsabilidad del cliente. Una función de IAM con permisos de administrador asignada a un servicio que solo necesita acceso de lectura es responsabilidad del cliente. El proveedor de la nube no detectará ni solucionará ninguno de estos problemas.
Cómo varía la responsabilidad según el modelo de servicio
Los límites exactos varían en función del modelo de servicio en la nube que se utilice. Cuanto más arriba se sitúe el servicio en la pila, más responsabilidades asume el proveedor y menos gestiona el cliente a nivel de infraestructura. Sin embargo, los datos, la identidad y el control de acceso siguen siendo responsabilidad del cliente en todos los modelos.
Infraestructura como servicio (IaaS)
El proveedor se encarga de la infraestructura física y de la capa de virtualización. El cliente gestiona todo lo demás: el sistema operativo, el middleware, el entorno de ejecución, las aplicaciones, los datos y la configuración de red. Este es el modelo que se aplica a las máquinas virtuales alojadas en la nube, como AWS EC2, Azure VM y Google Compute Engine.
El modelo IaaS es el que impone una mayor responsabilidad al cliente de entre todos los modelos de servicio. Un MSP que gestiona el entorno IaaS de un cliente es responsable de toda la pila de seguridad situada por encima del hipervisor. Esto incluye la aplicación de parches al sistema operativo y a las aplicaciones, las reglas del cortafuegos y la configuración de los grupos de seguridad, el cifrado de datos en reposo y en tránsito, la configuración de IAM y el registro de eventos. Nada de esto corre a cargo del proveedor.
Plataforma como servicio (PaaS)
El proveedor también se encarga de la gestión del sistema operativo, el middleware y el entorno de ejecución. El cliente es responsable de las aplicaciones y los datos. Los servicios de bases de datos gestionados, Azure SQL Database, AWS RDS y las plataformas de alojamiento de aplicaciones funcionan según este modelo.
El PaaS reduce considerablemente la carga administrativa. Los clientes no tienen que aplicar parches al sistema operativo subyacente ni gestionar el motor de la base de datos. No obstante, siguen siendo responsables de la seguridad de los datos, el control de acceso, la configuración a nivel de aplicación y la seguridad del código de las aplicaciones.
Software como servicio (SaaS)
El proveedor se encarga de toda la pila, desde la infraestructura hasta la aplicación. El cliente es responsable de los datos, la gestión de accesos y la configuración de los controles de seguridad de la aplicación.
Microsoft 365, Google Workspace y Salesforce son todos servicios SaaS. El error más común en este sentido es que, dado que el proveedor gestiona la aplicación, los clientes dan por sentado que también se encarga de proteger los datos. Pero no es así. Microsoft es responsable de la disponibilidad y la fiabilidad de la plataforma de Microsoft 365. Los datos que se encuentran dentro de cada inquilino, así como su recuperabilidad, son responsabilidad del cliente.
Una organización que pierda datos de Microsoft 365 debido a un borrado masivo accidental, a un administrador malintencionado o a un ransomware que cifre archivos sincronizados de OneDrive no puede confiar en las herramientas de retención de Microsoft para recuperarlos. Esas herramientas están orientadas al cumplimiento normativo, con plazos de retención cortos, y no están diseñadas para la recuperación operativa en un momento concreto.
Las deficiencias más habituales en materia de responsabilidad compartida
Una cosa es comprender el principio. Las deficiencias que surgen en entornos reales son específicas y predecibles. Estas cinco deficiencias aparecen en casi todos los entornos en la nube que no han sido evaluados formalmente.
Copias de seguridad de SaaS. El malentendido más extendido entre todos los modelos de servicio. Ni Microsoft ni Google realizan copias de seguridad de los datos de Microsoft 365 o Google Workspace de una forma que permita la recuperación operativa tras un borrado accidental, un ataque de ransomware o el compromiso de una cuenta. Datto SaaS Protection este problema directamente, realizando copias de seguridad de los datos de Microsoft 365 y Google Workspace tres veces al día en un repositorio independiente e inmutable de Datto Cloud, con retención ilimitada y restauración granular.
Configuración de IAM. La gestión de identidades y accesos —es decir, quién tiene qué permisos en los entornos en la nube— es siempre responsabilidad del cliente, independientemente del modelo de servicio. Una configuración incorrecta de IAM es la principal causa de las filtraciones de datos en la nube. Un pequeño proveedor de servicios gestionados (MSP) que se haga cargo del entorno de AWS de un nuevo cliente suele encontrarse con roles de IAM cuyos permisos son mucho más amplios de lo que requieren los servicios a los que dan servicio. Corregir esto es un trabajo poco glamuroso y que requiere mucho tiempo, pero que es necesario en casi todos los entornos.
Actualización de parches del sistema operativo y las aplicaciones para cargas de trabajo de IaaS. Las máquinas virtuales en la nube no se actualizan automáticamente. Una instancia de AWS EC2 o una máquina virtual de Azure que ejecute un sistema operativo sin parches es tan vulnerable como un servidor local en las mismas condiciones. VSA y Datto RMM amplían la gestión automatizada de parches a los terminales alojados en la nube utilizando el mismo despliegue basado en agentes y la misma automatización basada en políticas que se emplean para los servidores locales.
Configuración de la seguridad de red. Los grupos de seguridad, las listas de control de acceso a la red y la configuración de VPC/VNet son responsabilidad del cliente en entornos IaaS. En las evaluaciones de entornos en la nube se detectan constantemente grupos de seguridad que permiten el acceso entrante sin restricciones en los puertos 22 o 3389; estos siguen activos porque se dejaron abiertos para la resolución de problemas y nunca se cerraron. Su corrección es sencilla y su resolución es de alta prioridad.
Registro y supervisión. Los proveedores de servicios en la nube ponen a disposición registros de auditoría (como AWS CloudTrail, los registros de actividad de Azure Monitor y los registros de auditoría de Google Cloud), pero es responsabilidad del cliente habilitar el registro, almacenarlo correctamente y supervisarlo para detectar incidentes de seguridad. Un entorno en la nube sin registros habilitados supone un callejón sin salida a la hora de investigar incidentes. Kaseya SIEM integra los registros de las plataformas en la nube junto con la telemetría de los terminales y del correo electrónico, normalizando los incidentes de seguridad de todos los proveedores en una única capa de detección.
Qué implica esto para el diseño de los servicios de MSP
El modelo de responsabilidad compartida no es solo un concepto de seguridad. Es un marco de diseño de servicios. Los MSP que diseñan sus ofertas de servicios basándose explícitamente en las categorías de responsabilidad que cubren pueden transmitir el valor a los clientes con precisión. Los MSP que no comprenden el modelo probablemente tengan lagunas no documentadas en su cobertura y se enfrenten a conversaciones difíciles cuando un incidente las ponga de manifiesto.
Una lista de verificación práctica para la incorporación de cualquier nuevo entorno de nube de un cliente, estructurada en torno al modelo de responsabilidad compartida:
Para cargas de trabajo de IaaS:
- Instala VSA o el agente Datto RMM en todas las máquinas virtuales en la nube e incorpóralas a las políticas de gestión de parches existentes
- Auditar los roles de IAM y las cuentas de servicio; documentar y corregir los permisos excesivos
- Revisar la configuración de los grupos de seguridad y las listas de control de acceso de red; cerrar cualquier acceso sin restricciones a los puertos de gestión
- Comprueba que el registro de auditoría esté habilitado en todas las regiones y que los registros se envíen a un destino independiente y supervisado
- Comprueba que la copia de seguridad esté configurada independientemente de la cuenta en la nube y prueba la recuperación
Para entornos SaaS:
- Implementa Datto SaaS Protection Microsoft 365 y Google Workspace
- Revisar los permisos de las cuentas de administrador y aplicar la autenticación de dos factores (MFA) a todas las cuentas con privilegios a través de Kaseya 365
- Documenta qué datos se encuentran en cada plataforma SaaS y cuál es el procedimiento de recuperación para cada una de ellas
Para todos los entornos en la nube:
- Definir y documentar las responsabilidades que asume el MSP en el contrato de servicios
- Verificar los requisitos de cumplimiento (HIPAA, PCI DSS, CMMC, CCPA) que se aplican a los datos alojados en la nube y relacionarlos con los controles existentes
- Añadir la arquitectura del entorno en la nube y la estructura de IAM a IT Glue el cliente
La fase de documentación tiene una importancia que va más allá del valor operativo. Cuando un cliente se enfrenta a una reclamación de seguro cibernético o a una auditoría de cumplimiento normativo, la capacidad del proveedor de servicios gestionados (MSP) para aportar pruebas de qué controles de seguridad se aplicaban y en qué momento suele ser lo que determina el resultado.
Cómo Kaseya 365 al cliente
Kaseya 365 ofrece herramientas que abordan cada uno de los ámbitos de responsabilidad del cliente en IaaS, PaaS y SaaS.
VSA y Datto RMM automatizan la gestión de parches del sistema operativo y las aplicaciones tanto para máquinas virtuales alojadas en la nube como para terminales locales, cubriendo así las necesidades de aplicación de parches en IaaS desde una única consola.
Datto SaaS Protection se encarga de la protección de datos SaaS para Microsoft 365 y Google Workspace, con copias de seguridad tres veces al día, retención ilimitada y almacenamiento inmutable independiente.
Kaseya 365 se encarga de la gestión de identidades y accesos en Microsoft 365 y los entornos en la nube conectados, lo que incluye la aplicación de la autenticación de dos factores (MFA) y la supervisión Dark Web ID .
Kaseya SIEM se encarga del registro y la supervisión, integrando los registros de auditoría de la plataforma en la nube junto con la telemetría de los terminales y del correo electrónico en una capa unificada de detección de amenazas.
IT Glue se encarga de la documentación, almacenando la arquitectura del entorno en la nube, la estructura de IAM y los manuales de recuperación con aislamiento por cliente y acceso controlado.
Kaseya Intelligence aplica el reconocimiento y la respuesta automatizados de patrones en entornos de nube gestionados, detectando desviaciones de configuración en el lado del cliente de la línea de responsabilidad compartida y ejecutando medidas correctivas sin esperar a una revisión manual.
