01El modelo de responsabilidad compartida según IaaS, PaaS y SaaS
El proveedor de nube y el cliente se reparten la responsabilidad de la seguridad; el reparto exacto depende del modelo de servicio. En IaaS, el cliente responde del sistema operativo, los controles de red y las aplicaciones; en PaaS, el proveedor asume el sistema operativo, mientras que la configuración de aplicaciones y de red sigue siendo compartida; en SaaS, casi toda la pila recae en el proveedor. Con independencia del modelo, según la matriz de responsabilidades de Microsoft cuatro ámbitos permanecen siempre en manos del cliente: los datos, los dispositivos finales, las cuentas y la gestión de accesos, al igual que las configuraciones y los ajustes. El malentendido más frecuente es «el proveedor se ocupa de la seguridad»: precisamente en SaaS se subestima con regularidad la responsabilidad sobre accesos y configuraciones, y sin una asignación explícita, las responsabilidades compartidas quedan de hecho sin dueño.
02La identidad es el nuevo perímetro
En la nube, el plano de administración y las API son accesibles a través de Internet: quien posee credenciales válidas no está delante del cortafuegos, sino en pleno centro del entorno. En consecuencia, la Cloud Security Alliance sitúa Identity and Access Management en el puesto 2 de sus Top Threats 2024. Las contramedidas eficaces son una autenticación multifactor generalizada y, a ser posible, resistente al phishing; roles de mínimo privilegio en lugar de derechos de administrador permanentes; cuentas privilegiadas separadas y especialmente supervisadas, y credenciales de corta duración. Las identidades no humanas —cuentas de servicio, claves API, identidades de workload— deben someterse a la misma gobernanza, ya que suelen pasarse por alto en las revisiones de permisos y rara vez se recertifican.
03Errores de configuración y control de cambios insuficiente
«Misconfiguration and Inadequate Change Control» ocupa el puesto 1 de los CSA Top Threats to Cloud Computing 2024. Los patrones típicos son buckets de almacenamiento accesibles públicamente, roles IAM demasiado amplios, accesos de administración expuestos, registro de eventos desactivado y recursos de prueba y en la sombra olvidados. La causa rara vez es la falta de conocimiento, sino la velocidad: el autoservicio y la infraestructura como código generan a diario cambios que, sin barreras de protección, nadie revisa de forma consistente. La solución pasa por políticas definidas como código (Policy as Code), Cloud Security Posture Management (CSPM) para detectar desviaciones de forma continua y un proceso de gestión de cambios que se aplique expresamente también a los recursos en la nube.
04CSA Top Threats: lo que el sector considera un riesgo
Para su serie «Top Threats to Cloud Computing», la Cloud Security Alliance encuesta periódicamente a especialistas; para la edición de 2024 (publicada en agosto de 2024), más de 500 expertos priorizaron once amenazas. Los tres primeros puestos corresponden a los errores de configuración y el control de cambios insuficiente, a Identity and Access Management y a las interfaces y API inseguras, todos ellos temas dentro del ámbito de responsabilidad del cliente. El informe complementario «Top Threats to Cloud Computing - Deep Dive 2025» (abril de 2025) analiza ocho incidentes de seguridad reales según este marco de amenazas y deriva de ellos recomendaciones de controles; en el centro están los errores humanos, las debilidades de identidad y configuración y los riesgos de la cadena de suministro.
05Landing zones, líneas base y gobernanza multinube
Una landing zone es un entorno de nube preestructurado en el que la gobernanza, la red, la identidad y el registro de eventos están anclados antes de que llegue la primera workload. El Cloud Adoption Framework de Microsoft distingue para ello una landing zone de plataforma central y, por cada workload, landing zones de aplicación propias que heredan automáticamente las políticas de seguridad a través de la jerarquía de management groups. Como línea base de configuración se han consolidado los CIS Benchmarks, basados en consenso: más de 100 benchmarks para más de 25 familias de productos, entre ellas AWS, Azure, Google Cloud y Oracle Cloud. Para la evaluación de proveedores en el mercado alemán también es relevante el catálogo de criterios C5 del BSI, revisado a fondo en 2025/26 (C5:2026). En entornos multinube, lo decisivo no es tanto la herramienta individual como la coherencia: políticas uniformes, gobernanza centralizada de identidades y registro de eventos consolidado en todas las plataformas.
06Cómo iniciar un programa de seguridad en la nube
El punto de partida es la transparencia: ¿qué cuentas de nube, servicios y datos existen, incluidos los entornos que nunca pasaron por una revisión de arquitectura? A continuación se aclaran las responsabilidades por modelo de servicio y se protegen las dos palancas más importantes: las identidades (MFA, accesos privilegiados) y el registro centralizado de eventos. Después, una línea base como los CIS Benchmarks se declara vinculante y su cumplimiento se mide de forma continua con herramientas CSPM, en lugar de auditarlo solo de forma puntual. La seguridad en la nube es, en definitiva, un programa con operación continua —con roles definidos, indicadores y procesos de cambio— y no un proyecto de refuerzo puntual.
