¿Qué es el modelo de responsabilidad compartida en cloud? Límites según el servicio
El modelo de responsabilidad compartida separa tareas del proveedor y del cliente, y cambia según el servicio cloud y su configuración.
El modelo de responsabilidad compartida en cloud explica cómo se reparten ciertas tareas de seguridad entre el proveedor y el cliente. No es una transferencia completa de responsabilidad: el proveedor opera partes de la plataforma y el cliente sigue tomando decisiones sobre sus cuentas, datos, configuraciones y uso del servicio. El reparto concreto depende de qué servicio se contrata y de sus condiciones.
AWS resume su modelo distinguiendo seguridad “de” la nube —infraestructura que opera el proveedor— y seguridad “en” la nube —elementos que configura o utiliza el cliente—. Microsoft presenta una matriz en la que las responsabilidades cambian según se use infraestructura, plataforma o software como servicio. Son modelos explicativos de cada proveedor, no una tabla universal que pueda copiarse sin mirar el producto y el contrato.
El servicio cambia la frontera
En una oferta de infraestructura como servicio (IaaS), el proveedor suele operar instalaciones físicas y componentes base, mientras el cliente administra más capas, como sistemas invitados, aplicaciones y reglas de red que configura. En plataforma como servicio (PaaS), el proveedor gestiona más componentes de ejecución; el cliente mantiene decisiones sobre su aplicación, datos, identidad y configuración disponible. En software como servicio (SaaS), el proveedor administra la aplicación y su infraestructura, pero el cliente sigue controlando quién accede, qué comparte y cómo usa las funciones. La frontera se desplaza, no desaparece.
Un mismo nombre comercial puede abarcar varios servicios con responsabilidades distintas. Un bucket de almacenamiento, una máquina virtual, una base de datos gestionada y una herramienta SaaS pueden ofrecer controles diferentes, aunque pertenezcan al mismo proveedor. La unidad de análisis debe ser el servicio concreto: documentación técnica, configuración, opciones de seguridad, límites de soporte y condiciones contractuales ayudan a saber qué tarea corresponde a cada parte.
-SecureCrew dice: “Está en la nube” describe dónde corre un servicio, no quién revisa si una cuenta conserva permisos de administrador.-
Qué suele seguir en manos del cliente
El cliente normalmente gestiona las identidades y permisos que concede a su organización, la configuración de los recursos, los datos que carga y las decisiones de acceso que toma. El proveedor puede ofrecer cifrado, registros, políticas y controles, pero que una función exista no significa que esté activada o configurada correctamente. El equipo debe decidir cómo se usan las opciones y quién verifica su estado.
La protección de datos también depende de decisiones que no desaparecen al usar un servicio gestionado: clasificación, retención, permisos de compartición, requisitos de cifrado y respuesta ante una exposición. Una copia almacenada por el proveedor no equivale a una recuperación probada; hay que conocer su alcance y comprobar que el proceso permite recuperar lo que la organización necesita, en el tiempo previsto y bajo las condiciones contratadas.
Las cuentas administrativas, las llaves y los secretos de aplicaciones merecen tratamiento propio. Una configuración de red puede limitar el acceso externo, pero una identidad con permisos excesivos todavía puede exponer recursos desde una sesión válida. Las responsabilidades de identidad y configuración suelen cruzar varias capas: el proveedor ofrece controles; la organización los asigna, los revisa y responde si se usan mal.
-SecureCrew dice: Pagar por una cerradura inteligente no decide quién recibe llaves ni si una antigua sigue abriendo la puerta.-
Cómo evitar vacíos entre equipos
Un mapa de responsabilidad puede asociar cada control con un dueño: proveedor, equipo de plataforma, desarrollo, seguridad o propietario del dato. Conviene incluir tareas recurrentes como revisar avisos del proveedor, validar configuraciones, rotar credenciales y conservar registros necesarios. “Compartida” necesita nombres y fechas; si queda como responsabilidad abstracta, cada equipo puede suponer que otro la está atendiendo.
La auditoría y el cumplimiento tampoco se externalizan por usar una plataforma certificada. Un proveedor puede demostrar controles sobre su servicio, pero la organización debe entender el alcance del informe, qué servicios cubre y qué obligaciones de configuración conserva. Una certificación del proveedor no certifica automáticamente el despliegue del cliente.
Cuando un incidente afecta a un servicio cloud, la investigación puede necesitar registros que controla el proveedor y evidencia que conserva el cliente. Los canales de soporte, la retención y los tiempos de acceso conviene conocerlos antes de una urgencia. La preparación debe reflejar el modelo real del servicio, incluidas las tareas que el proveedor ejecuta y las que el cliente debe coordinar por su cuenta.
El modelo de responsabilidad compartida sirve para hacer visibles los límites operativos entre proveedor y cliente; no sustituye el análisis de un servicio concreto ni resuelve por sí mismo quién actuará. La pregunta práctica es quién configura, supervisa y responde ante cada control. Si ambas partes conocen esas tareas antes de desplegar datos y aplicaciones, es menos probable que un hueco quede escondido detrás de la palabra “cloud”.
Diccionario de la Crew
IaaS — Servicio cloud que ofrece recursos de infraestructura configurables por el cliente.
PaaS — Servicio cloud que aporta una plataforma gestionada para ejecutar aplicaciones.
SaaS — Aplicación consumida como servicio, administrada en gran medida por su proveedor.