Ciberseguridad

Seguridad en Cloud

Intermedio 6 modulos • 16 horas •59 € IVA incluido

Curso orientado a asegurar entornos cloud con foco en identidad, red, datos, secretos, monitorizacion y arquitectura segura. El contenido aterriza principios que aplican a AWS, Azure y GCP sin perder detalle técnico en el modelo operativo real de la nube.

La cloud acelera despliegue y elasticidad, pero también introduce errores muy repetidos: cuentas sobredimensionadas, secretos expuestos, buckets públicos, security groups abiertos, logs sin revisión, workloads sin segmentación y posture management ignorado. El curso enseña a leer esos riesgos en el marco de responsabilidad compartida y a priorizar controles que reduzcan exposición.

El primer modulo es gratuito. Solicita informacion para conocer las condiciones de acceso al curso completo.

Proximamente a la venta. El primer modulo es gratuito: registrate y empieza.

hola@itlabcert.com

Solicitud recibida. Te responderemos a tu correo en menos de 48 horas laborables. No hace falta que la envies otra vez.

Para mi Para mi empresa o equipo

He leido y acepto la politica de privacidad. Usaremos tus datos unicamente para responderte.

hola@itlabcert.com

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

Riesgo	Causa tipica	Control recomendado	Herramienta asociada
Bucket o contenedor publico	Configuracion erronea al crear recurso	Politicas preventivas, CSPM, alertas	CSPM, Azure Policy, SCP
VM expuesta a internet	Puertos abiertos, hardening debil	Segmentacion, bastion, MFA, parcheo	CWPP, NSG/Security Groups
Abuso de credenciales IAM	Claves longevas sin rotacion, permisos excesivos	Roles temporales, identidad federada, vaulting	CIEM, IAM Access Analyzer
Shadow cloud	Recursos creados fuera de gobierno	Landing zone, tagging, politica de uso	CSPM, inventario multi-cuenta
Datos sin cifrar	Discos, snapshots o bases de datos sin encryption	Cifrado por defecto, policies que lo obliguen	CSPM, KMS
Logs no retenidos	Servicio creado sin habilitar logging	Politica que active logging por defecto	CloudTrail, Activity Log

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.

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

Que aprenderas

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.

Contenido del modulo

Desarrollo teorico
Contenido ampliado
Puntos clave
Checklist operativa
Errores frecuentes
Practica sugerida
Preguntas de autoevaluacion
Cierre