Modelo de responsabilidad compartida en la nube

¿Qué es el modelo de responsabilidad compartida en la nube?

El modelo de responsabilidad compartida es una división de deberes de seguridad entre un proveedor de servicios en la nube y la organización que lo usa. El proveedor responde por las instalaciones, el hardware, el sistema operativo anfitrión y la capa de virtualización. El cliente responde por los datos, las identidades, las políticas de acceso y la configuración de cada servicio que activa.

AWS enuncia su mitad del modelo de responsabilidad compartida en una frase: "Los asuntos relacionados con la seguridad y la conformidad son una responsabilidad compartida entre AWS y el cliente". La compañía separa las dos mitades como seguridad "de" la nube frente a seguridad "en" la nube. AWS opera la primera. Tú operas la segunda.

Microsoft traza el piso del cliente en el mismo punto: "Para todos los tipos de implementación en la nube, posee sus datos e identidades". Esos dos no se mueven nunca en el modelo de responsabilidad compartida, compres lo que compres.

El modelo de responsabilidad compartida asigna trabajo, no responsabilidad legal. Nada en él hace que un proveedor responda por cómo configuras su producto. CISA se lo dice a las agencias federales sin suavizarlo: las agencias deben identificar y entender con claridad la delimitación de responsabilidades entre ellas y su proveedor.

Tres cosas que el modelo de responsabilidad compartida no es:

• No es una cláusula contractual que puedas negociar a la baja. El proveedor no puede ver dentro de tus datos, y tú no puedes llegar a su hypervisor.

• No es idéntico entre proveedores. CISA advierte que los proveedores pueden definir esta relación de seguridad compartida de forma distinta de un fabricante a otro.

• No es estático. Cada servicio nuevo que habilitas vuelve a mover la línea.

Seguridad de la nube y seguridad en la nube

La seguridad de la nube es todo lo que opera el proveedor y tú no puedes tocar. La seguridad en la nube es todo lo que despliegas, configuras y a lo que das acceso. El modelo de responsabilidad compartida es la línea entre ambas, y esa línea queda en un lugar distinto según el modelo de servicio.

En IaaS alquilas máquinas y redes, así que casi todo lo que está por encima del hypervisor es tuyo. En PaaS el proveedor también opera el sistema operativo y el runtime, de modo que tu parte se reduce a la aplicación y sus datos. En SaaS configuras y alimentas software terminado, así que el modelo de responsabilidad compartida te deja los datos, las cuentas y los ajustes para compartir.

NIST describió el modelo de responsabilidad compartida en SP 800-210 antes de que se asentara el lenguaje de mercadeo. Para IaaS: los datos en las capas de middleware, datos, aplicaciones y sistema operativo pertenecen al consumidor y están bajo su control. Para SaaS: los datos gestionados por la capa de aplicación pertenecen al consumidor y están bajo su control. Distinta superficie, mismo dueño.

Responsabilidad por modelo de servicio, siguiendo la división de Microsoft y el reparto IaaS, PaaS y SaaS de NIST SP 800-210.

Lee la tabla por las tres primeras filas. Los datos del cliente, las configuraciones y ajustes, y las identidades y usuarios no cambian de manos en ninguna versión del modelo de responsabilidad compartida. Toda brecha en la nube originada en un bucket público, un rol con privilegios de más o una llave filtrada vive en una de esas tres filas.

SaaS es donde más se malinterpreta el modelo de responsabilidad compartida, porque la parte del proveedor parece total. No lo es. Los ajustes para compartir, los colaboradores externos, los tokens de API y el ciclo de vida de las cuentas siguen siendo tuyos, y un tenant SaaS sin autenticación multifactor es una falla del lado del cliente.

El modelo de responsabilidad compartida en Fluid Attacks

Trabajamos en los dos lados del modelo de responsabilidad compartida. Probamos las configuraciones en la nube de nuestros clientes con Cloud Security Posture Management (CSPM) y técnicas manuales, y operamos nuestra propia infraestructura de producción sobre AWS bajo el mismo modelo de responsabilidad compartida por el que les preguntamos. Esto es lo que se ve, y lo que no.

Qué evaluamos y bajo qué reglas

Nuestro CSPM revisa un entorno de AWS en busca de configuraciones que incumplen requisitos de seguridad, que es la mitad del cliente en el modelo de responsabilidad compartida, y lo hace de forma continua en vez de una vez por trimestre. Registras el entorno en nuestra plataforma como un activo Cloud (CSPM), que nuestra documentación define así: estás agregando tu entorno de AWS para probarlo con gestión de la postura de seguridad en la nube.

El acceso es acotado, no abierto, porque el modelo de responsabilidad compartida corre en las dos direcciones. Nuestra documentación de conexión afirma que Fluid Attacks alcanza solo los recursos que autorizas y el resto de tu red permanece privado. La regla de menor privilegio con la que te evaluamos aplica al acceso que nos das.

Cómo se ve en la práctica

Cada hallazgo en la nube se mapea a una entrada de nuestro catálogo abierto de debilidades y a los requisitos que lo cierran. Ese mapeo convierte una alerta de scanner en algo sobre lo que un desarrollador puede actuar, y cada fila de abajo está del lado del cliente en el modelo de responsabilidad compartida.

Cada debilidad en la nube que reportamos lleva el requisito que la resuelve.

Nuestra ficha en database para almacenamiento en la nube de acceso público, con sus requisitos enlazados.

Cómo cumplimos con nuestra propia parte

También somos clientes del modelo de responsabilidad compartida, y nuestra infraestructura se reconstruye en vez de parchearse. Nuestra documentación de stack dice que Terraform se usa para escribir todo nuestro stack de infraestructura como código y que la infraestructura se regenera desde cero cada vez que se requiere. Una configuración que se desvía no sobrevive al siguiente deploy.

Los secretos nunca quedan legibles en un repositorio. Los gestionamos con Sops, que resuelve los secretos en el momento del despliegue dentro de GitLab CI/CD, sin dependencias en tiempo de ejecución. Esa es la contramedida directa a la debilidad que más encontramos en el código de nuestros clientes, y está de nuestro lado del modelo de responsabilidad compartida igual que estaría del tuyo.

Nuestros pentesters trabajan entornos de AWS con AWS CLI, Pacu y enumerate-iam, todos listados en nuestro conjunto público de herramientas. Las herramientas sacan a la superficie la mala configuración. Una persona encuentra la cadena que convierte tres ajustes inofensivos por separado en una escalada de privilegios, que es la parte del modelo de responsabilidad compartida que la automatización sola no cierra.

El patrón se ha mantenido durante años. Jonathan Armas, analista de seguridad en Fluid Attacks, escribió en Secure Cloud as Code que "las fallas más comunes que encontramos cuando probamos despliegues de IaC son los secretos en texto claro y las credenciales embebidas en el código". Y agregó una observación de sus propios trabajos: "la mayoría de las veces que he comprometido llaves de AWS, estaban configuradas con permisos excesivos".

Dónde se detiene nuestro benchmark

En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra un dataset de 1.201 vulnerabilidades, un pentester encontró 1.076 de ellas, que es un 89,6 % de recall con 100 % de precisión, mientras que nuestro propio scanner encontró 273, o 22,7 % de recall con 99 % de precisión. Tiene dos límites que preferimos decir a que los deduzcas.

Ese benchmark corrió contra una aplicación web, no contra un entorno de nube. No mide qué tan bien cualquier herramienta detecta un bucket mal configurado o un rol con privilegios de más.

La distancia entre 22,7 % y 89,6 % es el segundo límite, y la razón por la que no presentamos el escaneo automatizado como la respuesta completa a tu mitad del modelo de responsabilidad compartida. Un scanner te dice que un servicio de almacenamiento es público. No puede decirte si eso fue una decisión o un accidente, y bajo el modelo de responsabilidad compartida solo tú puedes responder eso.

La práctica que decide el resto

La verificación continua le gana a una buena configuración inicial. Tu mitad del modelo de responsabilidad compartida cambia cada vez que alguien despliega, y una revisión de marzo no dice nada sobre julio.

Nuestro análisis de seguridad on-premises frente a la nube sostiene que el monitoreo continuo sigue siendo del cliente, corra la carga de trabajo donde corra. Profundiza en nuestros textos sobre DevSecOps en AWS y Azure.

Dónde falla el modelo de responsabilidad compartida

El modelo de responsabilidad compartida falla del lado del cliente, en tres lugares recurrentes: almacenamiento abierto, identidades con más privilegios de los que el trabajo necesita y credenciales subidas al código fuente. La Cloud Security Alliance ubicó la mala configuración con control de cambios insuficiente, la gestión de identidad y acceso, y las interfaces y API inseguras como las tres principales amenazas de su reporte Top Threats to Cloud Computing 2024. Las tres están en la mitad del cliente del modelo de responsabilidad compartida.

El mismo reporte señala que los problemas asociados tradicionalmente a los proveedores de nube siguen perdiendo importancia. Los proveedores mejoraron en su mitad del modelo de responsabilidad compartida. La brecha se movió a la nuestra.

Almacenamiento que le responde a cualquiera

Un servicio de almacenamiento alcanzable sin credenciales es el error de nube más antiguo y todavía el más productivo para los atacantes. Nuestra base de datos lo describe así: algún servicio de almacenamiento en la nube que usa la aplicación puede accederse públicamente, sin requerir autenticación. Y la solución es igual de simple: restringir el acceso a los servicios de almacenamiento público del sistema.

No es un hallazgo raro, y el modelo de responsabilidad compartida lo pone de lleno en el cliente. En nuestro Reporte de ataques 2026, el acceso no autorizado a archivos en servicios de almacenamiento en la nube sumó 13.499 instancias reportadas y 500.832,48 unidades CVSSF de exposición al riesgo en las aplicaciones que probamos en 2025.

Identidades con más privilegios de los que el trabajo necesita

El privilegio excesivo convierte un compromiso pequeño en uno grande. Nuestra base de datos define la debilidad como una aplicación, un usuario o un rol que tienen más privilegios de los que requieren, y señala que un atacante puede aprovecharlo para ejecutar acciones normalmente restringidas en un sistema.

La remediación es un requisito, no una herramienta: los usuarios y las aplicaciones siempre deben tener un rol con el nivel mínimo de privilegio necesario para ejecutar sus funciones. Nada de lo que entregue un proveedor de nube va a aplicarlo por ti, que es el modelo de responsabilidad compartida funcionando como fue diseñado.

La gestión de identidad y acceso está enteramente dentro de la parte del cliente en el modelo de responsabilidad compartida, y la identidad sobreprivilegiada rara vez es una persona: es un rol de servicio que nadie revisó después del lanzamiento. Nuestro catálogo también marca el equivalente en red, donde la definición de infraestructura para los segmentos de red en AWS es demasiado permisiva.

Credenciales que viajan con el código

Una llave de acceso en un repositorio es una llave sin vencimiento y sin dueño, y ninguna lectura del modelo de responsabilidad compartida le pasa al proveedor las credenciales embebidas en el código. Nuestro análisis de DevSecOps en la nube reporta que los pentesters de Fluid Attacks encuentran de forma repetida credenciales de servicios en la nube dentro del código fuente de los clientes, y que evaluamos los archivos de infraestructura como código por las malas configuraciones que vienen después.

La cifra del Reporte de ataques 2026 lo cuantifica: la información sensible en el código fuente con credenciales llegó al 37,4 % de los sistemas que probamos, con una exposición media al riesgo de 112,62 unidades CVSSF por sistema afectado.

Las credenciales en el código fuente afectaron al 37,4 % de los sistemas que probamos en 2025.

Debilidades del lado de la nube en el Reporte de ataques 2026 de Fluid Attacks, sobre sistemas probados entre el 1 de enero y el 31 de diciembre de 2025.

Qué no resuelve el modelo de responsabilidad compartida

No te dice cómo configurar nada, y no vuelve infalible la mitad del proveedor. Los propios proveedores reconocen las dos brechas.

Google es el más directo. Su documentación de arquitectura afirma que, en su opinión, el modelo de responsabilidad compartida se queda corto para ayudar a los clientes de nube a lograr mejores resultados de seguridad, porque cada servicio tiene un perfil de configuración distinto y puede ser difícil determinar cuál es la mejor configuración de seguridad. La respuesta de Google es lo que llama destino compartido: el proveedor toma un papel activo en el resultado del cliente en vez de trazar una línea y hacerse a un lado.

La segunda brecha es más simple. El modelo de responsabilidad compartida da por sentado que la mitad del proveedor aguanta, y a veces no lo hace. En 2023, un actor de amenazas llegó a los buzones de Exchange Online de funcionarios del gobierno de Estados Unidos a través de la propia infraestructura de autenticación del proveedor. La Cyber Safety Review Board hizo una revisión independiente, y el resumen de CISA sobre sus hallazgos apunta a las decisiones del proveedor y no a cliente alguno: el reporte detalló las decisiones operativas y estratégicas que llevaron a la intrusión.

Los clientes no habrían podido prevenir esa. Quedó enteramente del lado del proveedor, y es la razón para revisar el historial de seguridad de un proveedor en vez de dar por hecha su mitad.

De quién fue la culpa

Tres incidentes, tres respuestas distintas del mismo modelo de responsabilidad compartida. Lo que los separa no es el tamaño de la empresa ni el proveedor que eligió. Es de qué lado del modelo de responsabilidad compartida quedó la falla.

Dos de las tres fallas quedaron del lado del cliente en el modelo de responsabilidad compartida.

Sobre Toyota, la revisión de la Cloud Security Alliance concluyó que la causa raíz fue un error al configurar los ajustes de nube de la compañía. Una década de exposición no es un ataque sofisticado. Es un ciclo de revisión ausente en la mitad del cliente del modelo de responsabilidad compartida.

Twitch describió su propio incidente en los mismos términos: dijo que fue resultado de un cambio de configuración en un servidor que permitió el acceso indebido de un tercero no autorizado.

Si cada incidente en la nube fuera culpa del cliente, el modelo de responsabilidad compartida sería un descargo de responsabilidad y no una división del trabajo.

Cómo cumplir con tu parte

Empieza por escribir la línea. Pídele a tu proveedor su versión documentada del modelo de responsabilidad compartida, servicio por servicio, y contrástala con lo que realmente operas. La instrucción de CISA a las agencias sirve igual para un banco: identificar y entender la delimitación antes de necesitarla.

Aplica el menor privilegio a los roles, no solo a las personas. Nuestro requisito establece que los usuarios y las aplicaciones deben tener el privilegio mínimo que exige su función. La gestión de identidad y acceso se queda de tu lado del modelo de responsabilidad compartida en todos los modelos de servicio, y la identidad sobreprivilegiada suele ser un rol de servicio que nadie revisó después del lanzamiento.

Saca las credenciales del código y ponlas en un resolutor. Los secretos cifrados que se resuelven en el despliegue eliminan toda la clase de hallazgo que afecta a más de un tercio de los sistemas que probamos. Es el cambio con la mejor relación entre esfuerzo y riesgo eliminado en todo el modelo de responsabilidad compartida.

Restringe el almacenamiento y la red por defecto. Estos son los dos ajustes que el modelo de responsabilidad compartida te deja enteramente a ti. El acceso público en un servicio de almacenamiento y una regla de red 0.0.0.0 son cambios de una línea que los atacantes encuentran más rápido que los auditores.

Exige autenticación multifactor en cada cuenta administrativa de nube. El modelo de responsabilidad compartida la convierte en un control del cliente en todos los modelos de servicio, incluido SaaS, donde a menudo es el único control que te queda.

Y después verifica todo de forma continua. Aquí es donde un enfoque DevSecOps se gana su lugar: una revisión de configuración es exacta mientras nadie despliegue. En una pipeline que publica a diario, eso son horas.

Conclusiones

El modelo de responsabilidad compartida no es complicado, pero se lee de forma consistente como más generoso de lo que es. En el modelo de responsabilidad compartida, los proveedores protegen lo que operan. Tú proteges tus datos, tus identidades y cada configuración que tocas, y esa última categoría es donde se origina casi todo incidente del lado del cliente.

La evidencia de que el modelo de responsabilidad compartida falla del lado del cliente es consistente entre fuentes. Las tres principales amenazas de 2024 de la Cloud Security Alliance son todas del lado del cliente. Toyota pasó una década sin notarlo y Twitch publicó su propio código fuente, las dos cosas por ajustes que nadie volvió a leer.

La mitad de los proveedores tampoco es perfecta, como mostró la intrusión a Exchange Online en 2023. Ese es un argumento para verificar las dos mitades del modelo de responsabilidad compartida, no para dar por cubierta ninguna.

Preguntas frecuentes

¿Qué es el modelo de responsabilidad compartida en la nube?

El modelo de responsabilidad compartida es la división de deberes de seguridad entre un proveedor de servicios en la nube y su cliente. El proveedor protege las instalaciones físicas, el hardware, el sistema operativo anfitrión y la capa de virtualización. El cliente protege los datos, las identidades, las políticas de acceso y la configuración de los servicios que habilita.

¿Quién responde cuando una mala configuración en la nube causa una brecha?

El cliente, en casi todos los casos. La configuración está del lado del cliente en el modelo de responsabilidad compartida tanto en IaaS como en PaaS y SaaS, así que un bucket de almacenamiento público o un rol sobreprivilegiado es un hallazgo que corrige el cliente y un incidente que él reporta. Los proveedores entregan los controles; aplicarlos bien no es parte de lo que venden.

¿Cambia el modelo de responsabilidad compartida entre IaaS, PaaS y SaaS?

Sí, pero no para todo. El sistema operativo, el runtime y los controles de red se desplazan hacia el proveedor a medida que vas de IaaS a SaaS. Los datos, las identidades y los ajustes de configuración se quedan con el cliente en los tres. NIST SP 800-210 lo dice sin rodeos para SaaS: los datos gestionados por la capa de aplicación pertenecen al consumidor y están bajo su control.

¿Alguna vez es culpa del proveedor de nube?

Sí, y ha pasado en los más grandes. En 2023 la Cyber Safety Review Board revisó independientemente una intrusión a buzones de Exchange Online y documentó las decisiones del proveedor detrás de ella. Google también ha dicho que el modelo de responsabilidad compartida se queda corto para ayudar a los clientes de nube a lograr mejores resultados de seguridad, y propone en su lugar el destino compartido. Dar por hecha la mitad del proveedor es un riesgo en sí.

¿Fluid Attacks prueba configuraciones en la nube?

Sí, con CSPM en entornos de AWS y pruebas manuales. Probamos la mitad del cliente del modelo de responsabilidad compartida con CSPM, apoyados en técnicas manuales y en el escaneo de credenciales e infraestructura como código insegura. En nuestro Reporte de ataques 2026, las credenciales en el código fuente aparecieron en el 37,4 % de los sistemas que probamos durante 2025, que es el problema del modelo de responsabilidad compartida que más encontramos del lado del cliente.

Conoce qué debes proteger

Nuestros scanners y pentesters revisan de forma continua tu configuración en la nube, tu código y tus identidades, para que la mitad del modelo de responsabilidad compartida que te pertenece quede verificada y no supuesta. Prueba gratuita · Contáctanos