2. Modelo de responsabilidad compartida y riesgos en entornos cloud

2.1 Introducción

El modelo cloud permite crear infraestructura y consumir servicios con gran velocidad. Esa agilidad es una ventaja operativa, pero también puede generar exposición si las configuraciones, permisos y datos no se controlan correctamente.

Una idea central de la seguridad cloud es que el proveedor no protege todo. El proveedor administra y asegura la infraestructura del servicio, pero el cliente decide cómo usarlo: quién accede, qué datos se almacenan, qué redes se exponen, qué aplicaciones se despliegan y qué registros se conservan.

Entender esta división evita dos errores frecuentes: asumir que "la nube ya es segura por defecto" o trasladar controles tradicionales sin considerar las características propias de cloud.

2.2 Qué es el modelo de responsabilidad compartida

El modelo de responsabilidad compartida define qué aspectos de seguridad quedan a cargo del proveedor cloud y cuáles quedan a cargo del cliente. No es una regla única para todos los servicios: cambia según el modelo de consumo y el nivel de administración del servicio.

En términos generales, el proveedor se ocupa de la seguridad de la nube: datacenters, hardware, red física, virtualización base y disponibilidad de servicios administrados. El cliente se ocupa de la seguridad en la nube: identidades, datos, configuraciones, aplicaciones, permisos, monitoreo y cumplimiento.

2.3 Responsabilidades por modelo de servicio

Cuanto más administrado es el servicio, menos componentes técnicos administra el cliente. Sin embargo, el cliente conserva decisiones críticas de acceso, datos, configuración y uso.

2.4 Responsabilidades que casi siempre quedan del lado del cliente

Aunque los servicios cloud varíen, hay responsabilidades que rara vez desaparecen. Son áreas que una organización debe gobernar de forma explícita.

• Identidad y acceso: usuarios, grupos, roles, cuentas de servicio, MFA y mínimo privilegio.
• Datos: clasificación, cifrado, retención, backups, ubicación y control de exposición.
• Configuración: parámetros de seguridad, redes, políticas, logging y opciones de acceso público.
• Aplicaciones: código, dependencias, secretos, APIs, autenticación y autorización.
• Monitoreo: logs, alertas, trazabilidad, detección de cambios y respuesta a incidentes.
• Cumplimiento: evidencias, auditoría, segregación de ambientes y gestión de excepciones.

2.5 Riesgo de configuración insegura

La configuración insegura es una de las causas más comunes de incidentes cloud. No requiere que el proveedor falle: basta con que el cliente habilite acceso público, deje permisos amplios o desactive registros importantes.

Ejemplos habituales:

• Almacenamiento accesible públicamente sin necesidad real.
• Bases de datos expuestas a internet o a rangos demasiado amplios.
• Security groups o reglas de firewall con origen 0.0.0.0/0 para puertos administrativos.
• Logs de auditoría deshabilitados o con retención insuficiente.
• Recursos creados manualmente fuera de estándares aprobados.

2.6 Riesgo de identidad y privilegios excesivos

La identidad es el nuevo perímetro operativo. En cloud, una credencial con permisos amplios puede crear recursos, leer datos, modificar redes, cambiar políticas y desactivar controles.

Los riesgos típicos incluyen:

• Usuarios sin MFA o con credenciales reutilizadas.
• Roles administrativos usados para tareas automatizadas simples.
• Claves de acceso estáticas guardadas en equipos, scripts o repositorios.
• Permisos comodín como * en acciones o recursos sin justificación.
• Cuentas de servicio sin dueño, sin rotación y sin monitoreo.

El control básico es aplicar mínimo privilegio, autenticación fuerte, revisión periódica de permisos, roles temporales y eliminación de credenciales permanentes cuando sea posible.

2.7 Riesgo de exposición de datos

Los datos pueden quedar expuestos por permisos de almacenamiento, enlaces compartidos, snapshots, backups, exportaciones, integraciones SaaS o errores de clasificación. La protección no depende solo del cifrado: también importa quién puede acceder y cómo se audita ese acceso.

2.8 Riesgo de red y exposición pública

Cloud facilita publicar servicios, abrir puertos y conectar entornos. Esa flexibilidad debe gobernarse. La exposición pública debe ser intencional, documentada y protegida con controles adecuados.

• Los puertos administrativos no deberían estar disponibles desde internet.
• Las bases de datos normalmente deben residir en subredes privadas.
• Los servicios públicos deberían estar detrás de balanceadores, WAF, gateways o proxies apropiados.
• Las conexiones entre redes deben limitar rutas, orígenes y destinos necesarios.
• La segmentación debe separar ambientes, niveles de sensibilidad y planos de administración.

2.9 Riesgo operativo y de cambio acelerado

Cloud permite cambiar rápido, pero el cambio rápido sin control introduce errores. Recursos creados manualmente, excepciones sin vencimiento, ambientes temporales olvidados y plantillas sin revisión pueden degradar la postura de seguridad.

Para controlar este riesgo se usan prácticas como infraestructura como código, revisión por pares, pipelines de despliegue, políticas como código, etiquetado obligatorio, inventario continuo y detección de drift.

2.10 Riesgo de costos y abuso de recursos

En cloud, seguridad y costos se relacionan. Una credencial comprometida puede usarse para desplegar infraestructura costosa, minar criptomonedas, generar tráfico abusivo o almacenar grandes volúmenes de datos.

Los controles recomendados incluyen presupuestos, alertas de consumo, cuotas, detección de recursos anómalos, separación de cuentas y revisión de permisos para crear recursos de alto costo.

2.11 Controles base para reducir riesgos cloud

Una postura inicial razonable debería cubrir controles preventivos, detectivos y correctivos. No todos requieren herramientas complejas; muchos dependen de decisiones de arquitectura y operación disciplinada.

• Activar MFA para usuarios privilegiados y evitar cuentas compartidas.
• Aplicar mínimo privilegio en roles humanos, servicios y automatizaciones.
• Bloquear exposición pública por defecto en almacenamiento y bases de datos.
• Habilitar logs de auditoría, actividad de red y eventos administrativos.
• Cifrar datos sensibles en reposo y en tránsito con gestión clara de claves.
• Usar infraestructura como código para estandarizar configuraciones.
• Escanear configuraciones y detectar drift contra políticas aprobadas.
• Definir proceso de respuesta para credenciales filtradas, datos expuestos y recursos comprometidos.

2.12 Matriz simple de riesgo y control

2.13 Preguntas para evaluar responsabilidad

Antes de adoptar o desplegar un servicio cloud conviene responder preguntas concretas. Si no hay respuesta, probablemente el riesgo no está gobernado.

• ¿Qué parte del servicio administra el proveedor y qué parte configuramos nosotros?
• ¿Quién puede crear, modificar, eliminar o exponer este recurso?
• ¿Qué datos procesa y cuál es su sensibilidad?
• ¿Está habilitado el logging necesario para auditoría e investigación?
• ¿Qué pasa si una credencial asociada al servicio se filtra?
• ¿Existe una forma automatizada de validar que la configuración cumple la política?
• ¿Cómo se restaura el servicio si se borra, cifra, altera o compromete?

2.14 Qué debes recordar de este tema

• La responsabilidad compartida cambia según el modelo de servicio, pero el cliente conserva obligaciones críticas.
• Identidad, datos, configuración, monitoreo y aplicaciones casi siempre requieren gobierno del cliente.
• Muchos incidentes cloud nacen de permisos excesivos, exposición pública, secretos filtrados o registros insuficientes.
• La velocidad de cloud exige automatización segura, revisión continua y detección de drift.
• Una buena postura cloud combina prevención, detección, respuesta y evidencia auditable.

2.15 Conclusión

El modelo de responsabilidad compartida es la base para tomar decisiones correctas en cloud. Permite saber qué controles dependen del proveedor, qué controles dependen del cliente y dónde se necesitan evidencias para operar con confianza.

En el próximo tema estudiaremos cómo organizar una arquitectura cloud segura mediante cuentas, proyectos, regiones, ambientes y landing zones.