Modulo 01. Riesgos y responsabilidades en cloud

Objetivo del modulo

Comprender que cambia de verdad cuando una organizacion mueve cargas a la nube y como se reparte la responsabilidad entre proveedor y cliente segun el modelo de servicio.

Resultados esperados

• Explicar el modelo de responsabilidad compartida con precision tecnica.
• Identificar riesgos tipicos de malentender ese reparto en IaaS, PaaS y SaaS.
• Distinguir riesgos de servicio, configuracion, identidad y gobierno.
• Relacionar los riesgos cloud con herramientas de postura y visibilidad como CSPM y CWPP.

Desarrollo teorico

Uno de los errores mas frecuentes al migrar a cloud es asumir que "como lo opera el proveedor, la seguridad tambien es suya". Esa idea es falsa y peligrosa. Todos los grandes proveedores cloud (AWS, Azure, GCP) publican un modelo de responsabilidad compartida que delimita claramente que protege cada parte. El proveedor se responsabiliza de la seguridad de la nube: centros de datos fisicos, hardware, hipervisores, red del backbone, ciertos servicios gestionados y los controles base del servicio. El cliente sigue siendo responsable de la seguridad en la nube: identidades, permisos, configuracion de recursos, segmentacion de red, cifrado, logging, datos, workloads y aplicaciones.

El reparto no es identico en todos los modelos de servicio, y esta diferencia es fundamental para cualquier profesional de seguridad:

En IaaS (Infrastructure as a Service), el cliente controla la mayor parte de la pila: sistema operativo, hardening, puertos abiertos, parcheo de la VM, agentes de seguridad, configuracion de aplicaciones, datos y gestion de identidades. El proveedor protege la infraestructura fisica, la red subyacente y el hipervisor. Ejemplos: EC2 en AWS, Virtual Machines en Azure, Compute Engine en GCP. El riesgo principal es que el cliente trate la VM como si estuviera en un CPD propio sin adaptar sus controles al entorno cloud (security groups, metadata service, roles IAM).

En PaaS (Platform as a Service), el proveedor abstrae mas infraestructura (runtime, middleware, sistema operativo), pero el cliente sigue gobernando acceso, secretos, configuracion del servicio, exposicion publica, datos y logica de aplicacion. Ejemplos: Azure App Service, AWS Lambda, Cloud Functions. El riesgo principal es la sobreconfianza: "como no gestiono el servidor, no necesito asegurar nada". Un servicio PaaS mal configurado puede exponer datos, aceptar conexiones no autenticadas o ejecutar funciones con permisos excesivos.

En SaaS (Software as a Service), el cliente gestiona menos capa tecnica pero sigue teniendo responsabilidades criticas sobre identidades, politicas de acceso, configuracion de seguridad del servicio (MFA, conditional access, sharing policies), retencion de datos, comparticion de documentos y cumplimiento normativo. Ejemplos: Microsoft 365, Salesforce, ServiceNow. El riesgo principal es asumir que el proveedor se encarga de todo y no configurar las opciones de seguridad disponibles.

Un riesgo clasico y recurrente es el almacenamiento expuesto. El proveedor puede ofrecer un servicio de objetos extraordinariamente robusto (S3, Blob Storage, Cloud Storage), pero si el cliente marca un bucket o contenedor como publico, los datos quedan accesibles a cualquiera con la URL. Este problema no es del servicio; es de la configuracion. Historicamente, decenas de brechas de datos masivas han ocurrido por buckets S3 publicos que contenian backups, bases de datos, credenciales o informacion personal. El control pasa por politicas organizativas que impidan la creacion de recursos publicos, revisiones automatizadas de postura y alertas cuando se detecta una desviacion.

La velocidad y elasticidad de cloud amplifican los errores de configuracion. En minutos se pueden crear decenas de maquinas virtuales, redes, roles IAM, funciones serverless, bases de datos y colas de mensajeria. Si no existen plantillas estandarizadas (Infrastructure as Code), politicas preventivas (Service Control Policies en AWS, Azure Policies, Organization Policies en GCP) y revisiones automatizadas, los desvios se multiplican exponencialmente: security groups abiertos a 0.0.0.0/0, cuentas de servicio con permisos de administrador, discos sin cifrado, logs no retenidos, snapshots publicas, claves de acceso sin rotacion, funciones Lambda con roles excesivos o redes sin segmentacion.

Para abordar estos riesgos a escala, la industria ha desarrollado categorias de herramientas especificas:

• CSPM (Cloud Security Posture Management) evalua continuamente la configuracion de recursos cloud contra benchmarks de seguridad (CIS Benchmarks, mejores practicas del proveedor) y alerta sobre desviaciones. Ejemplos: Microsoft Defender for Cloud, AWS Security Hub, Prisma Cloud. Un CSPM es esencial para organizaciones con mas de un puñado de recursos cloud, porque la revision manual no escala.

• CWPP (Cloud Workload Protection Platform) protege las cargas de trabajo (VMs, contenedores, funciones serverless) en tiempo de ejecucion: deteccion de malware, anomalias de comportamiento, vulnerabilidades en imagenes de contenedor y proteccion de runtime. Mientras CSPM se centra en configuracion, CWPP se centra en lo que ocurre dentro de la carga de trabajo.

• CIEM (Cloud Infrastructure Entitlement Management) analiza permisos y privilegios en identidades cloud para detectar permisos excesivos, cuentas inactivas con acceso y rutas de escalada de privilegios. Es especialmente relevante porque IAM en cloud es la superficie de ataque numero uno.

La gobernanza cloud requiere una estructura organizativa clara. Los conceptos de landing zone (configuracion base estandarizada para nuevos entornos), tagging obligatorio (etiquetar recursos con owner, proyecto, entorno, clasificacion), segregacion de cuentas o suscripciones (separar produccion de desarrollo, separar proyectos entre si), y networking hub-spoke (centralizar conectividad y seguridad de red) son fundamentales para evitar que cloud se convierta en un entorno caotico donde nadie sabe que existe, quien lo creo ni que datos contiene.

El concepto de shadow IT o shadow cloud es especialmente peligroso: equipos que crean recursos en cloud fuera del control del equipo de seguridad o TI, usando tarjetas corporativas o cuentas personales. Un shadow deployment puede contener datos sensibles, estar mal configurado y no estar monitorizado. La solucion combina governance (politica clara de uso de cloud), visibilidad (herramientas que descubran cuentas y recursos no gestionados) y cultura (formar a los equipos sobre los riesgos y ofrecerles alternativas agiles dentro del marco gobernado).

Contenido ampliado

Puntos clave

• El proveedor no protege automaticamente tus configuraciones, identidades ni datos; protege la infraestructura subyacente.
• El reparto de responsabilidades cambia significativamente entre IaaS, PaaS y SaaS.
• La elasticidad cloud exige mas disciplina de gobierno, no menos; la velocidad amplifica errores.
• CSPM, CWPP y CIEM son categorias complementarias que cubren configuracion, runtime e identidad respectivamente.
• La gobernanza (landing zone, tagging, segregacion de cuentas) es prerequisito para seguridad cloud a escala.
• Shadow cloud es un riesgo creciente que requiere visibilidad, politica y alternativas agiles.

Checklist operativa

• Identificar para cada servicio cloud que parte protege el proveedor y cual el cliente.
• Revisar exposicion publica real de almacenamiento, VMs y servicios.
• Validar si existen plantillas IaC y politicas preventivas para nuevos despliegues.
• Confirmar que logging esta habilitado en todas las cuentas y servicios criticos.
• Verificar ownership de cuentas o suscripciones cloud: quien creo cada una y quien la gestiona.
• Implementar o evaluar herramientas CSPM para revision continua de postura.
• Auditar permisos IAM buscando cuentas con privilegios excesivos o inactivas.
• Verificar que existe un proceso para detectar y gobernar shadow cloud.

Errores frecuentes

• Pensar que PaaS o SaaS significan "sin necesidad de asegurar nada por parte del cliente".
• Publicar recursos como publicos temporalmente y olvidar revertir la configuracion.
• No documentar cuentas, suscripciones o proyectos cloud ni asignar ownership.
• Depender exclusivamente de revision manual de configuracion en entornos con cientos de recursos.
• Conceder permisos de administrador a cuentas de servicio que solo necesitan permisos especificos.
• No separar entornos de produccion y desarrollo en cuentas o suscripciones distintas.
• Asumir que "el proveedor ya lo cifra" sin verificar si el cifrado esta activado y con que clave.

Practica sugerida

Elabora una matriz de responsabilidad compartida para una aplicacion web compuesta por: web frontend (en PaaS tipo App Service), API backend (en contenedores), base de datos gestionada (PaaS), almacenamiento de archivos (bucket) y autenticacion via Entra ID (SaaS). Para cada componente: (1) indica que protege el proveedor y que el cliente, (2) identifica el riesgo principal de configuracion, (3) propone un control preventivo y una herramienta de verificacion.

Preguntas de autoevaluacion

• ¿Que protege el proveedor cloud y que sigues protegiendo tu como cliente?
• ¿Por que los errores de configuracion son la causa principal de brechas en cloud?
• ¿Como cambia la responsabilidad del cliente entre IaaS, PaaS y SaaS?
• ¿Que diferencia hay entre CSPM, CWPP y CIEM?
• ¿Por que una landing zone es prerrequisito para seguridad cloud a escala?
• ¿Que riesgo representa shadow cloud y como se mitiga?

Cierre

Cloud no elimina la seguridad; cambia donde y como debes ejercerla. Entender el reparto de responsabilidades, los riesgos de configuracion, las herramientas de postura y la necesidad de gobernanza es el primer paso para no dejar huecos por falsa confianza en el proveedor.

Modulo 02. Identidad, privilegios y acceso

Objetivo del modulo

Controlar quién puede hacer qué en cloud, usando identidades federadas, roles y mínimo privilegio.

Resultados esperados

• Explicar diferencias entre usuarios, roles y cuentas de servicio.
• Reducir exposición por credenciales estáticas y privilegios excesivos.
• Diseñar una baseline IAM básica para cloud.

Desarrollo teorico

En cloud, IAM es normalmente el control mas poderoso del entorno y al mismo tiempo la superficie de ataque mas critica. En MITRE ATT&CK, las tecnicas relacionadas con identidad cloud son protagonistas en la mayoria de incidentes reales: T1078 Valid Accounts (uso de credenciales validas robadas o filtradas), T1098 Account Manipulation (modificacion de permisos o creacion de credenciales persistentes), T1136 Create Account (creacion de nuevas identidades para mantener acceso), y T1550.001 Application Access Token (abuso de tokens OAuth). Una clave filtrada o un rol con permisos excesivos puede permitir crear recursos, leer secretos, desactivar logs, borrar datos o escalar privilegios hasta control total del tenant. Por eso la primera regla es clara: evitar credenciales permanentes cuando exista alternativa y aplicar principio de minimo privilegio de forma real, no declarativa.

En AWS, Azure y GCP existen equivalentes de usuarios, grupos, roles y entidades de carga de trabajo. En AWS, los usuarios IAM pueden tener access keys de larga duracion que son un riesgo frecuente; la alternativa son roles IAM con credenciales temporales obtenidas via STS (Security Token Service), y federacion con el IdP corporativo mediante SAML o OIDC. En Azure, las identidades se gestionan a traves de Entra ID (antes Azure AD) con usuarios, grupos, roles RBAC y Managed Identities para workloads. En GCP, Cloud IAM proporciona roles predefinidos y personalizados, service accounts y Workload Identity Federation. La mejor practica actual es favorecer federacion con el IdP corporativo (SSO via SAML/OIDC con Entra ID, Okta, Google Workspace) y acceso temporal frente a usuarios locales con keys de larga vida. Las workloads deben usar identidades gestionadas (Managed Identities en Azure, Instance Profiles/Roles en AWS, Service Accounts con Workload Identity en GCP) en lugar de secretos embebidos en codigo.

CIEM (Cloud Infrastructure Entitlement Management) es la categoria de herramientas que analiza permisos y privilegios en identidades cloud para detectar excesos que el administrador humano no puede revisar manualmente a escala. Un CIEM evalua: cuentas con permisos de administrador que nunca los han usado, service accounts con wildcard permissions (por ejemplo, iam: o s3:), rutas de escalada de privilegios donde una identidad con permisos limitados puede asumir un rol con permisos amplios, y claves de acceso que llevan meses sin rotacion. En entornos con cientos de roles y miles de politicas, la revision manual es inviable y CIEM se convierte en requisito operativo.

La separacion de cuentas o suscripciones es un control arquitectonico fundamental. En AWS se implementa con AWS Organizations y Service Control Policies (SCPs) que limitan lo que cualquier cuenta hija puede hacer, independientemente de los permisos IAM locales. En Azure, las Management Groups y Azure Policies proporcionan un control equivalente. En GCP, Organization Policies cumplen la misma funcion. Esta separacion limita el radio de explosion (blast radius) de un compromiso: si un atacante compromete credenciales de la cuenta de desarrollo, no deberia poder acceder a produccion. La practica recomendada incluye cuentas separadas para produccion, desarrollo, staging, seguridad (logs centralizados, SIEM), networking hub y administracion.

El acceso privilegiado en cloud merece controles especificos. Las cuentas root o equivalentes (AWS root account, Azure Global Administrator, GCP Organization Admin) deben tener MFA de hardware, no usarse para operaciones cotidianas y monitorizarse con alertas inmediatas ante cualquier uso. El acceso administrativo humano deberia pasar por mecanismos just-in-time (Azure PIM, AWS SSO con session duration limitada) que otorgan privilegios elevados solo durante el tiempo necesario y dejan registro de auditoria completo. Estas practicas se alinean con el principio de minimo privilegio de ISO 27001 Annex A (A.8.2 Privileged access rights) y con los requisitos de control de acceso del ENS y GDPR articulo 32 sobre medidas tecnicas apropiadas.

Contenido ampliado

Puntos clave

• IAM cloud es uno de los mayores multiplicadores de riesgo.
• Las claves permanentes deben ser excepción, no norma.
• Los permisos amplios “por rapidez” se convierten en deuda peligrosa.

Checklist operativa

• Revisar usuarios con claves de larga duración.
• Auditar roles con permisos admin o wildcard.
• Validar uso de federación y MFA para acceso humano.
• Revisar identidades de workloads y secretos asociados.

Errores frecuentes

• Usar cuentas root o equivalentes para tareas ordinarias.
• Reutilizar una misma service account para muchos sistemas.
• Conceder permisos * por comodidad.

Practica sugerida

Diseña una baseline IAM para una cuenta cloud con administradores, desarrolladores, pipelines y aplicaciones en producción.

Preguntas de autoevaluacion

• ¿Por qué una clave API permanente es tan peligrosa?
• ¿Qué diferencia operativa hay entre usuario humano y rol temporal?
• ¿Qué revisarías primero tras detectar un acceso cloud sospechoso?

Cierre

Quien controla IAM controla el tenant. Por eso la seguridad cloud empieza por identidades sólidas y privilegios realmente limitados.