Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- La seguridad en la nube consiste en los controles, las políticas y las herramientas que protegen los datos, las aplicaciones y la infraestructura en la nube.
- La responsabilidad compartida divide las tareas de seguridad entre usted y el proveedor, y esta división varía en función del modelo de servicio.
- En IaaS, el sistema operativo invitado y sus actualizaciones son responsabilidad tuya, no del proveedor.
Los proveedores de servicios en la nube gestionan los centros de datos, el hardware y la capa de virtualización sobre la que se ejecutan sus cargas de trabajo. Más allá de eso, todo depende del modelo de servicio. En IaaS, el sistema operativo invitado, las cuentas de usuario y los datos almacenados quedan todos en su lado de la línea, y esa línea se desplaza a medida que se pasa a plataformas gestionadas y a SaaS.
Esa línea en constante cambio es donde suelen surgir las brechas de seguridad. Es fácil dar por sentado que el proveedor se encarga de tarea de aplicación de parches o de configuración que, en realidad, te corresponde a ti.
¿Qué es la seguridad en la nube?
La seguridad en la nube es la combinación de controles, políticas y herramientas que protegen los datos, las aplicaciones y la infraestructura que se ejecutan en entornos en la nube. Abarca las capas de identidad, red, cargas de trabajo y datos, y se aplica tanto si se ejecutan máquinas virtuales como plataformas gestionadas o software suministrado por un proveedor.
A veces verás que se utiliza la expresión «seguridad basada en la nube» para referirse a herramientas de seguridad que, a su vez, se proporcionan desde la nube. En este contexto, el término abarca la tarea más amplia de proteger lo que se ejecuta en la nube, hasta llegar a los servidores Linux que soportan gran parte de esas cargas de trabajo.
Es importante porque un solo parámetro mal configurado, una cuenta con permisos excesivos o un servidor sin parches pueden dejar los datos al descubierto o provocar la interrupción de un servicio. Algunos de esos riesgos persisten independientemente del modelo de servicio que elijas, tal y como muestra la matriz que aparece más abajo.
¿En qué consiste el modelo de responsabilidad compartida en la seguridad en la nube?
El modelo de responsabilidad compartida establece claramente qué tareas de seguridad corresponden al proveedor de la nube y cuáles te corresponden a ti. Un error habitual es pensar que el proveedor se encarga de la seguridad de todo lo que aloja. En la práctica, la línea divisoria varía en función del modelo de servicio y puede cambiar de un servicio a otro.
AWS, Microsoft y Google lo plantean cada uno de forma ligeramente diferente. Microsoft publica una matriz por modelo de servicio. AWS distingue entre la seguridad «de» la nube —es decir, la infraestructura del proveedor— y la seguridad «en» la nube —es decir, todo lo que el usuario aloje en ella—. Google va un paso más allá con lo que denomina «destino compartido», en el que el proveedor asume un papel más activo a la hora de ayudar a los clientes a conseguir una configuración segura. La propia Microsoft describe su matriz como una orientación ilustrativa que no modifica los términos de tu contrato, así que considera cualquiera de estos modelos como una guía y consulta tu contrato y la documentación del servicio específico que utilices.
Cómo se distribuyen las responsabilidades entre IaaS, PaaS y SaaS
Los servicios en la nube se clasifican en tres modelos de servicio: infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y software como servicio (SaaS). Cuanto mayor sea la parte de la pila que gestiona el proveedor, menos tendrás que gestionar tú directamente, aunque en los tres modelos sigues asumiendo algunas responsabilidades. La matriz actual de Microsoft, adaptada a continuación, muestra cómo se distribuye el trabajo.
| Ámbito de responsabilidad | IaaS | PaaS | SaaS |
| Datos de los clientes | Tú | Tú | Tú |
| Configuraciones y ajustes | Tú | Tú | Tú |
| Identidades y usuarios | Tú | Tú | Tú |
| Dispositivos de cliente | Tú | Tú | Compartido |
| Aplicaciones | Tú | Compartido | Compartido |
| Controles de red | Tú | Compartido | Proveedor |
| Sistema operativo | Tú | Proveedor | Proveedor |
| Servidores físicos, red y centro de datos | Proveedor | Proveedor | Proveedor |
Fuente: Microsoft Learn, «Responsabilidad compartida en la nube». Adaptado: «Cliente» y «Microsoft» aparecen como «Usted» y «Proveedor», se omite la columna «Local» y las filas correspondientes a los hosts físicos, la red y el centro de datos se han combinado en una sola.
Microsoft también enumera cuatro responsabilidades que te corresponden independientemente del modelo de servicio: datos, terminales, cuentas y gestión de accesos. Los dispositivos cliente aparecen como «Compartidos» en el modelo SaaS porque Microsoft puede ayudarte a gestionarlos en ese contexto, pero proteger esos terminales sigue siendo tu responsabilidad.
Infraestructura como servicio (IaaS)
Con IaaS, se alquilan recursos de computación, almacenamiento y red, como Amazon EC2, Azure Virtual Machines o Google Compute Engine. El proveedor se encarga de la seguridad de la infraestructura física y de la capa de virtualización. El usuario se encarga del sistema operativo invitado (SO invitado), del software instalado y de la configuración de red.
AWS lo deja muy claro. Los clientes que implementan una instancia de EC2 son responsables de la «gestión del sistema operativo invitado (incluidas las actualizaciones y los parches de seguridad)», así como de cualquier software que instalen y de la configuración del grupo de seguridad en cada instancia. AWS también incluye la gestión de parches como un control compartido: AWS aplica los parches a la infraestructura, y los clientes aplican los parches a su sistema operativo invitado y a sus aplicaciones. La matriz de Microsoft coincide en lo que respecta a IaaS y atribuye la responsabilidad del sistema operativo al cliente.
Plataforma como servicio (PaaS)
Las plataformas gestionadas, como Azure App Service, Azure Functions y Azure SQL Database —que Microsoft clasifica como PaaS—, transfieren una mayor parte del trabajo al proveedor. El proveedor se encarga del sistema operativo, el entorno de ejecución y el middleware. Las aplicaciones y los controles de red pasan a ser compartidos. Tú te encargas de la configuración de la aplicación, la seguridad del código, los controles de acceso y las bibliotecas que incluyes en tu implementación.
Las versiones de Runtime también se retiran según calendarios publicados y, cuando eso ocurre, la tarea de migración recae de nuevo sobre ti.
Software como servicio (SaaS)
Los servicios SaaS, como Microsoft 365 o Dynamics 365, dejan en manos del proveedor prácticamente toda la pila tecnológica. Google lo explica así: en el modelo SaaS, el proveedor asume la mayor parte de las responsabilidades en materia de seguridad, mientras que tú sigues siendo responsable de tus controles de acceso y de los datos que decidas almacenar. Microsoft considera los dispositivos de los clientes como un ámbito compartido. Puede ofrecer algunas funciones de gestión de dispositivos, pero la protección de los puntos finales y el cumplimiento normativo siguen siendo responsabilidad tuya.
De qué son responsables los proveedores de servicios en la nube
Los proveedores se encargan de las capas más cercanas al hardware. La documentación de Microsoft divide su parte en varias áreas, y AWS establece una delimitación similar.
Infraestructura física
La seguridad del centro de datos es responsabilidad del proveedor: las instalaciones, los controles de acceso físico y los controles ambientales, además de los servidores físicos que alojan tus cargas de trabajo.
Fundamentos de redes
La gestión de los routers, los conmutadores y el cableado dentro del centro de datos corresponde al proveedor. En PaaS, Microsoft proporciona un nivel básico de seguridad de red, y en SaaS se encarga de gestionar la seguridad de la red. Reglas de cortafuegos y la la segmentación de tus propias instancias siguen siendo de tu responsabilidad en IaaS.
Virtualización y capas de host
El hipervisor y el sistema operativo anfitrión también pertenecen al proveedor. AWS describe su parte del proceso como aquella que abarca desde el sistema operativo anfitrión y la capa de virtualización hasta la seguridad física de las instalaciones, lo que deja a tu sistema operativo invitado fuera de ese ámbito.
Documentación sobre el cumplimiento normativo
AWS, Microsoft y Google Cloud publican, cada uno, documentación sobre cumplimiento normativo. AWS afirma que los clientes pueden utilizar su documentación sobre controles y cumplimiento normativo para realizar su propia evaluación y verificación de los controles. Además, les remite a documentos de certificación de auditoría de terceros para determinar qué controles ya tienen implementados y cuáles aún deben implementar. Microsoft publica informes de auditoría a través de su Portal de Confianza de Servicios, y Google Cloud ofrece informes de auditoría y certificaciones a través de su Gestor de informes de cumplimiento. Algunos recursos de Microsoft y Google requieren que se inicie sesión, y determinados materiales se comparten bajo condiciones de confidencialidad.
De qué se encargan las organizaciones
En IaaS, eres responsable de la mayor parte de la pila. Esto empieza por aplicar parches al sistema operativo invitado y al núcleo en cada instancia, incluidas las que se inician a partir de imágenes antiguas, y se extiende a las aplicaciones que ejecutas y a las bibliotecas que estas incorporan, incluso aquellas que nunca has seleccionado directamente.
También debes configurar la red. En IaaS, esto implica grupos de seguridad, reglas de cortafuegos y segmentación. En PaaS, se refiere a controles de red a nivel de aplicación. El registro y la supervisión también corren de tu cuenta. En Google Cloud, por ejemplo, los registros de auditoría de acceso a datos están desactivados por defecto en todos los servicios, salvo en algunos de BigQuery, por lo que en la mayoría de los servicios no dispondrás de ellos hasta que los actives.
Las copias de seguridad y la recuperación varían según el servicio. En Amazon EC2, eres tú quien configura las instantáneas o las políticas de copia de seguridad de tus volúmenes, mediante herramientas como AWS Backup o Amazon Data Lifecycle Manager. Amazon RDS activa las copias de seguridad automáticas de forma predeterminada, pero tú decides durante cuánto tiempo se conservan.
Para conocer las prácticas de desarrollo e implementación seguras, consulta nuestra guía sobre buenas prácticas de seguridad de software.
Tipos de medidas de seguridad en la nube
Los marcos de seguridad en la nube suelen abarcar ámbitos como los cinco que se indican a continuación.
Gestión de identidades y accesos
Los roles, las políticas, las cuentas de servicio y la federación suelen determinar a qué puede acceder una credencial comprometida. El principio del privilegio mínimo, la autenticación multifactorial en las cuentas de usuario y la rotación periódica (o la eliminación directa) de las claves estáticas son medidas que limitan ese alcance. Las cuentas de servicio creadas para tareas puntuales deben someterse a una revisión periódica, y aquellas que ya no sean necesarias deben eliminarse.
Protección de datos y cifrado
Clasifica primero los datos según su nivel de confidencialidad y, a continuación, decide quién gestiona las claves. Las claves gestionadas por el proveedor son más sencillas de administrar, mientras que las gestionadas por el cliente te ofrecen un mayor control sobre su rotación y revocación. Elijas la opción que elijas, anota qué conjuntos de datos utilizan cada una.
Controles y segmentación de redes
Los grupos de seguridad, las listas de control de acceso (ACL) de red, los puntos finales privados y los perímetros de servicio controlan qué sistemas pueden comunicarse entre sí. La segmentación limita el alcance de una carga de trabajo comprometida, y el filtrado del tráfico saliente limita a qué recursos puede acceder dicha carga de trabajo.
Carga de trabajo y aplicación de parches al sistema operativo invitado
En IaaS, la aplicación de parches es una de las tareas recurrentes más importantes que hay que realizar. Linux se utiliza ampliamente en servidores en la nube y de alojamiento, y una actualización del núcleo ha supuesto tradicionalmente reiniciar la instancia. En una gran flota de servidores, encontrar una ventana de mantenimiento para cada reinicio puede retrasar la aplicación de los parches.
Los proveedores sí ofrecen herramientas para ello. AWS Systems Manager Patch Manager, la aplicación automática de parches en máquinas virtuales de Azure y Google Cloud VM Manager Patch pueden automatizar la aplicación de parches al sistema operativo invitado en tus instancias. Cada uno de ellos puede reiniciar la instancia como parte del proceso, y cada uno tiene su propio ámbito de aplicación. La aplicación automática de parches de Azure, por ejemplo, solo cubre los parches clasificados como «Críticos» o de «Seguridad». En cualquier caso, el propio sistema operativo invitado sigue estando bajo tu responsabilidad en IaaS.
La aplicación de parches en tiempo real sigue un enfoque diferente y aplica correcciones de seguridad del núcleo a un sistema en funcionamiento. Algunas distribuciones y proveedores ofrecen su propio sistema de parches en tiempo real para determinadas plataformas, por lo que un parque informático que combine varias distribuciones puede acabar teniendo que manejar varias herramientas. KernelCare ofrece parches en tiempo real para el núcleo de Linux en más de 70 versiones de distribuciones de Linux, lo que te permite corregir vulnerabilidades del núcleo en servidores de nube y de alojamiento en funcionamiento sin necesidad de programar un reinicio.
Registro y supervisión
Servicios como AWS CloudTrail, Azure Monitor y Google Cloud Audit Logs registran la actividad en tu entorno. El envío de registros a una cuenta o proyecto independiente dificulta que, en caso de que un entorno se vea comprometido, se pueda borrar su propio registro de auditoría, especialmente cuando el acceso al destino está estrictamente restringido. Las auditorías de seguridad ayudan a confirmar que los registros cubren lo que necesitas.
Cómo se relacionan las amenazas más comunes en la nube con tus responsabilidades
Las amenazas en la nube suelen ajustarse al modelo de responsabilidad compartida, lo que facilita identificar aquellas sobre las que se puede actuar. Según la matriz de Microsoft, los ajustes mal configurados y las identidades comprometidas son responsabilidad tuya en los tres modelos de servicio. Las vulnerabilidades del sistema operativo son responsabilidad tuya en IaaS y pasan a ser del proveedor en PaaS y SaaS. Si creas y distribuyes tus propias imágenes de contenedores y dependencias, siguen siendo tuyas independientemente de la plataforma en la que se ejecuten. Nuestra publicación sobre amenazas a la seguridad en la nube trata cada categoría en profundidad.
Los sistemas sin parches y al final de su ciclo de vida siguen la misma regla en IaaS, donde el mantenimiento del sistema operativo es responsabilidad del usuario. Una instancia en la nube puede seguir funcionando durante años con una imagen creada hace mucho tiempo. Cuando su distribución de Linux, su entorno de ejecución o su marco de trabajo llegan al final de su ciclo de vida, el proveedor deja de publicar actualizaciones de seguridad; sin embargo, la carga de trabajo suele seguir gestionando el tráfico mientras se planifica la migración. El servicio Endless Lifecycle Support (ELS) de TuxCare proporciona parches de seguridad para distribuciones de Linux, entornos de ejecución, marcos de trabajo y aplicaciones que han llegado al final de su vida útil una vez finalizado el soporte estándar de sus proveedores, lo que te da margen para migrar según tu propio calendario.
Retos habituales en materia de responsabilidad compartida
La cola avanza con cada servicio
En un servicio gestionado de Kubernetes, el proveedor se encarga del plano de control, y lo que ocurre con los nodos de trabajo depende de la opción que elijas. En Amazon EKS, AWS asume más responsabilidades a medida que pasas de los nodos autogestionados a los grupos de nodos gestionados y, finalmente, a Fargate. Incluso con los grupos de nodos gestionados, tú sigues teniendo que iniciar la actualización a una versión más reciente de la AMI, y EKS se encarga luego de implementarla en todos tus nodos. Un modelo basado en un servicio concreto puede llevarte a conclusiones erróneas sobre el siguiente, así que consulta la documentación sobre las responsabilidades de cada servicio.
La aplicación de parches puede quedar en manos de varios equipos
Si el equipo de ingeniería de plataformas se encarga de la estructura de cuentas, los equipos de aplicaciones se encargan de sus propias implementaciones y el equipo de seguridad se encarga de las políticas, la aplicación de parches al sistema operativo invitado puede quedar a cargo de los tres. Nombra a un responsable. Una pregunta útil para tu próxima revisión es quién aplicó el parche al núcleo de la instancia de producción más antigua y cuándo lo hizo.
Las instancias olvidadas pasan fácilmente desapercibidas
Una instancia que nunca se haya incluido en tu inventario de activos tampoco aparecerá en tus informes de parches. Si comparas ese inventario con tus listados de recursos en la nube y tus datos de facturación, puedes detectar sistemas que ningún equipo ha reclamado.
Consejos sobre seguridad en la nube para 2026
Lee la documentación sobre responsabilidades de un nuevo servicio antes de implementarlo, no después. Aplica parches al sistema operativo invitado y parches del núcleo a un responsable concreto en cada entorno de IaaS. Refuerza la seguridad de las identidades mediante el principio de privilegios mínimos, la autenticación multifactorial y la rotación periódica de las credenciales estáticas, y decide quién custodia las claves de cifrado de cada conjunto de datos (y anótalo).
En el ámbito operativo, envía los registros a una cuenta o proyecto independiente y comprueba que las alertas lleguen a una persona. Planifica sistemas que sigan funcionando una vez que el proveedor deje de ofrecer soporte, incluyendo los entornos de ejecución y las imágenes base. Y redacta tu flujo de trabajo de respuesta a incidentes antes de que lo necesites, porque en pleno incidente no es el mejor momento para empezar.
Ejecuta entornos seguros con TuxCare
En IaaS, el proveedor se encarga de la seguridad de la infraestructura, mientras que el sistema operativo invitado de cada instancia sigue siendo responsabilidad de tu equipo. Las dependencias de código abierto que incorporas a tu propio software también son tuyas, independientemente de dónde se ejecute. Soporte técnico durante todo el ciclo de vida proporciona parches de seguridad para distribuciones de Linux, entornos de ejecución, marcos de trabajo y aplicaciones que han llegado al final de su ciclo de vida, de modo que la migración pueda ajustarse a tu calendario en lugar de a los plazos del proveedor. SecureChain proporciona a tus compilaciones paquetes de código abierto verificados, analizados en busca de malware y actualizados continuamente para JavaScript, Python, Java, Go, Rust y PHP. Y KernelCare aplica parches de seguridad del kernel a los servidores Linux en funcionamiento sin necesidad de reiniciar, por lo que las correcciones del kernel no tienen que esperar a una ventana de mantenimiento.
Para saber cómo encaja la aplicación de parches en una rutina más amplia de gestión de la nube, lee nuestra guía sobre gestión de parches en la nube.
