Seguridad en la nube: guía completa de cloud security (2026)

La seguridad en la nube es el conjunto de políticas, controles, procedimientos y tecnologías que protegen los sistemas, datos y aplicaciones alojados en infraestructuras cloud. No es una disciplina nueva, pero sí una que ha evolucionado a una velocidad que muchas organizaciones no han sido capaces de seguir: los mismos informes de CSA (Cloud Security Alliance) y de los grandes proveedores muestran que la mayoría de los incidentes graves en entornos cloud no se producen por vulnerabilidades de día cero, sino por errores de configuración que cualquier equipo técnico podría haber evitado.

Este artículo es un hub de cloud security: cubre desde los fundamentos hasta las certificaciones, las herramientas del mercado y cómo practicar de forma gratuita. Si buscas el detalle de una certificación concreta, encontrarás los enlaces directos a las guías específicas a lo largo del texto.

Qué es la seguridad en la nube y por qué importa ahora más que nunca

La adopción cloud se aceleró de forma irreversible durante la pandemia y no ha frenado. Según el informe State of the Cloud 2024 de Flexera, el 87% de las empresas tiene una estrategia multicloud y el 72% utiliza una estrategia híbrida. El gasto en cloud crece a doble dígito anual y la mayoría de las cargas de trabajo críticas —ERP, CRM, bases de datos de clientes, sistemas de pago— ya residen en AWS, Azure o GCP.

El problema es que la velocidad de adopción supera sistemáticamente a la madurez de seguridad. El informe Cloud Security Report 2024 de Check Point indica que el 61% de los profesionales de seguridad considera las misconfiguraciones como la mayor amenaza en entornos cloud. A eso se suman la proliferación de identidades (cada servicio cloud genera sus propias credenciales), la dispersión de datos entre regiones y cuentas, y la responsabilidad compartida que muchos equipos no terminan de entender.

La consecuencia práctica: incidentes como la exposición masiva de buckets S3 de Capital One (2019, 100 millones de registros) o las configuraciones permisivas de IAM que permitieron acceso no autorizado en decenas de startups no se deben a que AWS fuera inseguro, sino a que los equipos no configuraron correctamente lo que AWS les proporcionaba. La seguridad en la nube es, en gran medida, un problema de configuración y de disciplina operativa.

El modelo de responsabilidad compartida

El concepto más importante para entender la seguridad cloud —y el que más se malinterpreta— es el modelo de responsabilidad compartida (shared responsibility model). Todos los grandes proveedores lo publican explícitamente, pero en la práctica muchos equipos asumen que «la nube es segura» sin entender qué parte de esa seguridad les corresponde a ellos.

La regla general es sencilla: el proveedor protege la nube; el cliente protege lo que pone en la nube.

El proveedor (AWS, Azure, GCP) es responsable de la seguridad de la infraestructura: los centros de datos físicos, la red global, el hardware de los servidores, el hipervisor, y los controles que garantizan que un inquilino no puede acceder a los recursos de otro. Ningún cliente tiene que preocuparse de que alguien robe un disco duro de un datacenter de Amazon, porque eso es responsabilidad de Amazon.

El cliente es responsable de la seguridad en la infraestructura: cómo configura sus máquinas virtuales, qué permisos otorga a sus usuarios y aplicaciones, si cifra los datos en reposo y en tránsito, cómo gestiona los secretos (claves API, contraseñas de base de datos), si parchea los sistemas operativos que despliega, y si monitoriza lo que ocurre en su entorno.

Este reparto cambia según el modelo de servicio, lo que lleva directamente al siguiente punto.

IaaS, PaaS y SaaS: cómo cambia la responsabilidad en cada modelo

Los tres modelos de servicio cloud definen qué partes de la pila tecnológica gestiona el proveedor y cuáles el cliente. Esto tiene implicaciones directas en qué controles de seguridad debe implementar cada parte.

IaaS (Infraestructura como Servicio)

Ejemplos: EC2 (AWS), Virtual Machines (Azure), Compute Engine (GCP). El proveedor gestiona el hardware y la virtualización. El cliente gestiona el sistema operativo, las aplicaciones, los datos, el firewall de nivel de instancia (grupos de seguridad / NSG) y la red virtual (VPC / VNet). Es el modelo con mayor control pero también con mayor superficie de ataque gestionada por el cliente. Un servidor EC2 mal parcheado, con un grupo de seguridad abierto a 0.0.0.0/0 en el puerto 22, es responsabilidad exclusiva del cliente.

PaaS (Plataforma como Servicio)

Ejemplos: AWS Elastic Beanstalk, Azure App Service, Google App Engine, bases de datos gestionadas como RDS (AWS) o Cloud SQL (GCP). El proveedor gestiona el sistema operativo y el middleware; el cliente gestiona el código de la aplicación, los datos y la configuración del servicio. La superficie de ataque se reduce respecto a IaaS, pero aparecen riesgos específicos: vulnerabilidades en el código de la aplicación, credenciales de base de datos mal gestionadas, o configuraciones de acceso público inadecuadas.

SaaS (Software como Servicio)

Ejemplos: Microsoft 365, Google Workspace, Salesforce, Slack. El proveedor gestiona casi todo. El cliente es responsable de la gestión de identidades (quién tiene acceso y con qué privilegios), la configuración de controles de seguridad que el SaaS exponga (MFA, reglas de acceso condicional, políticas de retención de datos), y la protección de los datos que introduce en la plataforma. La responsabilidad de seguridad se desplaza hacia la gestión de identidad y la gobernanza de datos.

La clave práctica: cuanto más «gestionado» es el servicio, menos superficie de ataque técnica gestiona el cliente, pero más importante se vuelve la gestión de identidades y accesos, porque los errores de configuración en IAM son la forma más común de comprometer un entorno SaaS o PaaS.

Principales amenazas y malconfiguraciones en cloud

La CSA publica cada dos años el informe Top Threats to Cloud Computing. Las ediciones recientes coinciden en un patrón: las amenazas técnicas sofisticadas quedan eclipsadas por los errores de configuración elementales. Estas son las más relevantes y frecuentes:

Buckets de almacenamiento abiertos al público

Amazon S3, Azure Blob Storage y Google Cloud Storage permiten configurar buckets como públicos, lo que tiene sentido para activos estáticos de un sitio web, pero es una catástrofe cuando afecta a backups, logs con información personal o documentos internos. Ha habido decenas de incidentes de este tipo: datos de millones de usuarios expuestos porque alguien olvidó desactivar el acceso público al crear el bucket.

La mitigación es sencilla: activar el bloqueo de acceso público a nivel de cuenta (AWS tiene S3 Block Public Access, Azure tiene la configuración equivalente a nivel de almacenamiento), auditar regularmente con herramientas CSPM (ver la sección de herramientas más adelante) y no otorgar permisos `s3:GetObject` a `*` sin una razón muy específica.

Políticas IAM excesivamente permisivas

El error más frecuente: otorgar permisos de administrador (`AdministratorAccess` en AWS, el rol `Owner` en Azure) a usuarios o aplicaciones que solo necesitan leer un servicio concreto. Una cuenta de servicio con permisos excesivos que se ve comprometida da al atacante acceso total al entorno.

Patrones problemáticos concretos: roles IAM con `»Action»: «*»` y `»Resource»: «*»`, funciones Lambda con el rol de ejecución de un administrador, pipelines de CI/CD con credenciales de larga duración y permisos amplios, o instancias EC2 con perfiles de instancia que permiten acceder a toda la cuenta.

Secretos expuestos en código o variables de entorno

Claves de API de AWS o GCP, contraseñas de bases de datos, tokens de acceso: cuando estos secretos se almacenan en variables de entorno sin cifrar, en archivos `.env` que acaban en un repositorio Git público, o en el código fuente directamente, cualquier atacante con acceso al repo tiene las llaves del entorno cloud.

La solución es usar servicios de gestión de secretos dedicados: AWS Secrets Manager, Azure Key Vault, Google Secret Manager. Estos servicios cifran los secretos, permiten rotarlos automáticamente y registran cada acceso en los logs de auditoría.

Grupos de seguridad y firewalls mal configurados

Reglas de entrada que permiten cualquier IP (`0.0.0.0/0`) en puertos críticos como SSH (22), RDP (3389) o bases de datos (3306, 5432, 1433) son configuraciones que los atacantes buscan activamente mediante escaneos masivos de internet. Un servidor con SSH abierto a todo internet recibirá intentos de fuerza bruta en minutos.

Logging y monitorización desactivados

AWS CloudTrail, Azure Monitor y Google Cloud Audit Logs registran todas las acciones en el entorno cloud. Cuando están desactivados —por coste o por descuido— es imposible detectar un ataque o investigar un incidente después del hecho. La monitorización es un control de seguridad, no un opcional.

Falta de cifrado en reposo y en tránsito

Bases de datos sin cifrado en reposo, almacenamiento de objetos sin cifrado del lado del servidor, o comunicaciones entre servicios internos sin TLS: estos son vectores de exfiltración de datos que los marcos de cumplimiento exigen cubrir y que los atacantes con acceso a la red o al almacenamiento pueden explotar.

Gestión de identidad y acceso (IAM): el perímetro nuevo

En la nube, la identidad es el nuevo perímetro de seguridad. No hay firewall perimetral físico; cualquier servicio es potencialmente accesible desde internet. Lo que protege el acceso son las identidades y los permisos.

Principio de mínimo privilegio

Cada usuario, aplicación o servicio debe tener exactamente los permisos que necesita para hacer su trabajo, y nada más. Parece obvio, pero implementarlo bien requiere disciplina: analizar qué acciones realiza realmente cada entidad, crear roles con permisos específicos (en vez de reutilizar el rol de administrador), y revisar periódicamente los permisos para eliminar los que ya no se necesitan.

AWS, Azure y GCP tienen herramientas específicas para esto: AWS IAM Access Analyzer identifica acceso externo no intencionado y permisos sin uso; Azure Entra ID tiene Privileged Identity Management (PIM) para acceso just-in-time; GCP tiene IAM Recommender que sugiere reducir permisos basándose en el uso real.

MFA (autenticación multifactor)

MFA es imprescindible para todas las cuentas con acceso a la consola de gestión cloud, y especialmente para las cuentas de administrador o root. Las credenciales filtradas son una de las principales vías de entrada en entornos cloud; con MFA habilitado, una contraseña comprometida no es suficiente para acceder.

En AWS: el usuario root debe tener MFA obligatoriamente, y AWS recomienda MFA para todos los usuarios IAM con acceso a la consola. Azure Entra ID permite exigir MFA mediante políticas de acceso condicional. En GCP, la MFA se gestiona a través de las cuentas de Google Workspace o Cloud Identity.

Federación de identidades y SSO

En organizaciones con decenas o cientos de usuarios cloud, gestionar cuentas individuales en cada proveedor no escala. La federación permite usar un proveedor de identidades corporativo (Active Directory, Okta, Google Workspace) como fuente de verdad única, y los usuarios acceden a AWS, Azure o GCP usando sus credenciales corporativas mediante protocolos estándar como SAML 2.0 u OIDC. Esto centraliza la gestión de accesos, facilita la revocación inmediata cuando un empleado abandona la empresa, y evita la proliferación de cuentas locales.

Credenciales temporales vs credenciales de larga duración

Las claves de acceso de larga duración (access key ID + secret access key en AWS) son un riesgo: si se filtran, son válidas hasta que alguien las revoca manualmente. Las credenciales temporales —generadas por AWS STS (Security Token Service), por roles de instancia, o por la federación de identidades— expiran automáticamente, lo que limita el daño si se comprometen. La regla práctica: evitar claves de larga duración para aplicaciones; usar roles de instancia o identidades gestionadas en su lugar.

Seguridad por proveedor: AWS, Azure y GCP

Los tres grandes proveedores tienen portafolios de seguridad maduros. Conocer los servicios clave de cada uno es esencial para trabajar con cada entorno.

Amazon Web Services (AWS)

AWS tiene el portafolio de seguridad más amplio y el más antiguo. Los servicios fundamentales son:

• AWS Identity and Access Management (IAM): gestión de usuarios, roles, políticas y permisos. El centro de todo.
• AWS CloudTrail: registro de todas las llamadas a la API de AWS. Esencial para auditoría y respuesta a incidentes.
• Amazon GuardDuty: servicio de detección de amenazas basado en machine learning que analiza logs de CloudTrail, VPC Flow Logs y DNS para detectar actividad anómala (reconocimiento, movimiento lateral, cryptomining…).
• AWS Security Hub: agregador de hallazgos de seguridad. Recibe alertas de GuardDuty, Inspector, Macie y herramientas de terceros, y las presenta en un panel unificado con puntuaciones de conformidad (CIS Benchmarks, NIST).
• Amazon Macie: descubrimiento y clasificación automática de datos sensibles (PII, credenciales) en buckets S3.
• AWS Inspector: evaluación de vulnerabilidades en instancias EC2, imágenes de contenedor en ECR y funciones Lambda.
• AWS Secrets Manager: gestión y rotación automática de secretos (contraseñas de bases de datos, claves API).
• AWS WAF: firewall de aplicación web para proteger APIs y aplicaciones web de inyección SQL, XSS y otros ataques web.
• AWS Shield: protección contra DDoS (Standard incluido, Advanced de pago con SLA de protección).
• AWS IAM Access Analyzer: identifica recursos accesibles externamente de forma no intencionada y genera recomendaciones de permisos.

Microsoft Azure

• Microsoft Entra ID (antes Azure Active Directory): directorio de identidades en la nube, base de la gestión de accesos en Azure y en entornos híbridos con Active Directory on-premises. Incluye Conditional Access, PIM y protección de identidades.
• Microsoft Defender for Cloud (antes Azure Security Center / Azure Defender): plataforma CSPM + CWPP nativa de Azure. Evalúa la postura de seguridad del entorno, detecta amenazas en VMs, bases de datos, contenedores y más, y da recomendaciones priorizadas.
• Microsoft Sentinel: SIEM y SOAR nativo en la nube. Recibe logs de todo Azure, de Microsoft 365 y de fuentes de terceros; tiene playbooks de automatización de respuesta.
• Azure Key Vault: almacenamiento seguro de secretos, claves de cifrado y certificados.
• Azure DDoS Protection: protección contra DDoS, standard y premium.
• Azure Firewall: firewall de red gestionado para VNets.
• Microsoft Defender for Endpoint: protección de endpoints, incluido en planes Microsoft 365.
• Azure Policy: definición y aplicación de políticas de cumplimiento en recursos Azure (equivalente a AWS Config).

Google Cloud Platform (GCP)

• Google Cloud IAM: gestión de identidades y roles. GCP tiene una jerarquía clara: organización → carpeta → proyecto → recurso, y las políticas IAM se heredan hacia abajo.
• Security Command Center (SCC): plataforma CSPM y de detección de amenazas nativa de GCP. Detecta malware en VMs, secretos expuestos en código, vulnerabilidades en contenedores y actividad anómala.
• Chronicle: SIEM de Google Cloud, diseñado para retención masiva de logs de seguridad con velocidad de búsqueda alta.
• Cloud Audit Logs: equivalente de CloudTrail en GCP. Registra actividad de administración, acceso a datos y eventos del sistema.
• Secret Manager: almacenamiento y gestión de secretos.
• Cloud Armor: WAF y protección DDoS para aplicaciones en GCP.
• VPC Service Controls: perímetros de seguridad que impiden la exfiltración de datos a través de servicios GCP incluso desde dentro de la red.
• Binary Authorization: garantiza que solo imágenes de contenedor firmadas y verificadas se despliegan en GKE.

Categorías de herramientas de seguridad cloud

El mercado de seguridad cloud ha generado un conjunto de categorías de herramientas con siglas propias. Entender qué hace cada categoría evita confusión entre productos que a menudo se presentan de forma similar.

CSPM (Cloud Security Posture Management)

Evalúa continuamente la configuración del entorno cloud en busca de desviaciones respecto a las mejores prácticas y los marcos de cumplimiento (CIS Benchmarks, NIST, ISO 27001, SOC 2). Detecta buckets abiertos, reglas de firewall permisivas, logging desactivado, cifrado ausente, etc. Es una herramienta preventiva: te dice qué está mal configurado antes de que alguien lo explote. Productos: Prisma Cloud (Palo Alto), Wiz, Orca Security, Lacework, y los servicios nativos de cada proveedor (Security Hub en AWS, Defender for Cloud en Azure, SCC en GCP).

CWPP (Cloud Workload Protection Platform)

Protege las cargas de trabajo en tiempo de ejecución: VMs, contenedores y funciones serverless. Incluye detección de malware, protección contra exploits, control de integridad de archivos y detección de comportamiento anómalo en el host. Complementa a CSPM: mientras CSPM analiza la configuración, CWPP monitoriza el comportamiento en ejecución. Productos: Prisma Cloud, Aqua Security, Sysdig, Lacework.

CNAPP (Cloud-Native Application Protection Platform)

Es la convergencia de CSPM y CWPP, más la seguridad de la cadena de suministro de software (escaneo de código, análisis de imágenes de contenedor, detección de secretos en código fuente). El término fue acuñado por Gartner. La tendencia del mercado es hacia plataformas integradas que cubran todo el ciclo de vida de la aplicación cloud, desde el código hasta la ejecución en producción. Wiz y Prisma Cloud son los referentes actuales.

CASB (Cloud Access Security Broker)

Actúa como intermediario entre los usuarios y los servicios SaaS/cloud, aplicando políticas de seguridad: control de acceso, prevención de pérdida de datos (DLP), detección de amenazas basada en comportamiento de usuario, y visibilidad sobre el uso de shadow IT (aplicaciones cloud que los empleados usan sin aprobación del departamento de TI). Productos: Microsoft Defender for Cloud Apps (antes MCAS), Netskope, Zscaler CASB.

SIEM cloud (Security Information and Event Management)

Los SIEMs tradicionales se quedan cortos en entornos cloud por el volumen de logs y la falta de contexto cloud-nativo. Los SIEMs modernos diseñados para cloud (Microsoft Sentinel, Chronicle, Splunk Cloud, Elastic Security) ingestan logs de proveedores cloud, correlacionan eventos a escala, y tienen reglas de detección específicas para TTPs en entornos AWS, Azure y GCP. Combinados con SOAR (Security Orchestration, Automation and Response), permiten automatizar la respuesta a incidentes.

DevSecOps, contenedores y Kubernetes

La seguridad en la nube moderna no puede separarse de los procesos de desarrollo y despliegue. DevSecOps integra la seguridad en el ciclo de vida de desarrollo de software (SDLC), haciendo que los controles de seguridad formen parte del pipeline de CI/CD en lugar de ser una fase separada al final.

Seguridad en el pipeline de CI/CD

Las herramientas de seguridad se integran en GitHub Actions, GitLab CI, Jenkins o Azure DevOps como pasos del pipeline:

• SAST (Static Application Security Testing): análisis del código fuente en busca de vulnerabilidades antes de compilar. Herramientas: Semgrep, SonarQube, Checkmarx.
• SCA (Software Composition Analysis): análisis de dependencias para detectar librerías con vulnerabilidades conocidas (CVEs). Herramientas: Dependabot, Snyk, OWASP Dependency-Check.
• Detección de secretos: escaneo del código y del historial Git para detectar credenciales expuestas. Herramientas: Gitleaks, truffleHog, detect-secrets.
• Escaneo de imágenes de contenedor: análisis de vulnerabilidades en la imagen antes de subirla al registry. Herramientas: Trivy, Grype, Amazon Inspector para ECR, Artifact Registry Vulnerability Scanning en GCP.
• IaC scanning: análisis de plantillas de Terraform, CloudFormation o Bicep en busca de misconfiguraciones antes del despliegue. Herramientas: Checkov, tfsec, Terrascan.

Seguridad en Kubernetes

Kubernetes añade complejidad de seguridad propia. Los vectores más relevantes:

• Control plane expuesto: el API server de Kubernetes no debe ser accesible desde internet sin autenticación fuerte.
• Pods con privilegios excesivos: contenedores que se ejecutan como root, con acceso al socket de Docker, o con capacidades Linux elevadas que permiten escapar del contenedor.
• Network policies ausentes: por defecto, todos los pods de un clúster Kubernetes pueden comunicarse entre sí. Las Network Policies permiten definir qué pods pueden hablar con quién, implementando segmentación de red.
• Imágenes sin escanear: imágenes base con vulnerabilidades conocidas o imágenes de repositorios no verificados.
• Secrets en texto claro: los Secrets de Kubernetes se almacenan en etcd codificados en Base64 (no cifrados) por defecto; hay que habilitar el cifrado en reposo de etcd.

Las herramientas específicas para Kubernetes incluyen Falco (detección de comportamiento anómalo en tiempo de ejecución), OPA/Gatekeeper (políticas de admisión), kube-bench (verificación contra CIS Benchmark para Kubernetes) y Kubescape.

Para ir más profundo en la seguridad defensiva y el uso de estas herramientas en un contexto de carrera, el itinerario de seguridad defensiva cubre la ruta de aprendizaje completa.

Cumplimiento y marcos de referencia

La seguridad cloud no opera en un vacío regulatorio. Las organizaciones deben cumplir con marcos de cumplimiento que varían según el sector, la geografía y el tipo de datos que manejan.

ISO/IEC 27017

Extensión de la norma ISO 27001 específica para servicios cloud. Añade controles concretos para proveedores y clientes cloud: gestión de activos virtuales, monitorización de operaciones de administración de servicios cloud, y separación de entornos. Los proveedores cloud principales (AWS, Azure, GCP) tienen certificación ISO 27017, lo que cubre la parte del proveedor; el cliente necesita implementar los controles que le corresponden para obtener su propia certificación.

NIS2 (Directiva de Seguridad de Redes y Sistemas de Información 2)

La directiva NIS2 de la UE, transpuesta en España y en todos los estados miembro antes de octubre de 2024, exige a las entidades esenciales e importantes (energía, transporte, salud, infraestructuras digitales, finanzas, agua…) implementar medidas de gestión de riesgos de ciberseguridad. En entornos cloud, esto implica: gestión de riesgos de proveedores cloud, cifrado, gestión de accesos, notificación de incidentes en 24-72 horas, y políticas de continuidad de negocio. Las multas por incumplimiento llegan al 1,4-2% de la facturación global anual para entidades esenciales.

CIS Benchmarks

El Center for Internet Security publica benchmarks de configuración segura para todos los proveedores cloud principales (CIS AWS Foundations Benchmark, CIS Microsoft Azure Foundations Benchmark, CIS Google Cloud Platform Foundation Benchmark). Son guías prescriptivas —con niveles L1 y L2— que definen exactamente cómo configurar cada servicio. Son el punto de partida más práctico para cualquier equipo que quiera mejorar su postura de seguridad cloud sin empezar desde cero. Las herramientas CSPM nativas (Security Hub, Defender for Cloud, SCC) los usan como base de sus evaluaciones.

Well-Architected Frameworks

AWS, Azure y GCP tienen sus propios frameworks de arquitectura bien diseñada (Well-Architected). Todos incluyen un pilar de seguridad con principios y mejores prácticas específicas para cada plataforma. AWS Well-Architected tiene una herramienta gratuita de evaluación; Azure y GCP tienen revisiones equivalentes. Son recursos valiosos para evaluar la madurez de un entorno cloud existente.

SOC 2, GDPR y PCI DSS

SOC 2 (para empresas tecnológicas que manejan datos de clientes), GDPR (para datos de ciudadanos europeos) y PCI DSS (para entornos de procesamiento de tarjetas de pago) tienen implicaciones específicas en cloud: transferencias internacionales de datos (con qué regiones de AWS/Azure/GCP se pueden almacenar datos de ciudadanos europeos), controles de acceso, auditoría y retención de logs. Los contratos de procesamiento de datos (DPA) con los proveedores cloud son obligatorios bajo el GDPR para cualquier organización europea.

Certificaciones de cloud security: cuáles estudiar y cuáles evitar

El mercado de certificaciones cloud es amplio y cambia con frecuencia. Estas son las más relevantes para 2026, con información verificada de los propios organismos certificadores.

Certificaciones de proveedores

AWS Certified Security – Specialty: la certificación de seguridad de referencia para AWS. Cubre IAM, detección de amenazas, respuesta a incidentes, logging y monitorización, protección de infraestructura y protección de datos. Es exigente y requiere experiencia práctica con AWS antes de intentarla. Recomendada para ingenieros cloud con 2+ años de experiencia en AWS.

Microsoft AZ-500 (Microsoft Azure Security Technologies): durante años la certificación estándar de seguridad en Azure. ATENCIÓN: Microsoft ha anunciado la retirada del examen AZ-500 el 31 de agosto de 2026. Su sucesor es el examen SC-500 (Microsoft Certified: Security Administrator Associate), que amplía el alcance e incorpora Copilot for Security. Si vas a estudiar seguridad Azure, orienta tu formación al SC-500. Puedes ver el detalle del examen actual en nuestra guía de AZ-500 y el perfil del SC-200 en la guía de SC-200.

Google Cloud Professional Cloud Security Engineer (PCSE): la certificación de seguridad de Google Cloud. Cubre diseño e implementación de infraestructura segura en GCP, gestión de operaciones de seguridad, cumplimiento y configuración de seguridad de red en GCP. Válida 2 años.

Certificaciones neutras de proveedor

CCSP (Certified Cloud Security Professional) — (ISC)²: la certificación de cloud security más reconocida a nivel global y no atada a ningún proveedor. Cubre los seis dominios del CBK cloud: conceptos y arquitectura, gobernanza, diseño y operaciones de infraestructura cloud, seguridad de aplicaciones cloud, operaciones de seguridad cloud, y aspectos legales y de cumplimiento. Requiere cinco años de experiencia en TI (con al menos uno en cloud security). Es la certificación más valorada en ofertas de trabajo de cloud security enterprise. Más detalles en nuestra guía del CCSP.

CCSK (Certificate of Cloud Security Knowledge) — CSA: certificación de nivel de entrada emitida por la Cloud Security Alliance. Es el punto de entrada antes del CCSP para quien no tiene experiencia. No requiere años de experiencia previos. Cubre el Cloud Controls Matrix (CCM) de la CSA y los fundamentos de cloud security. Recomendada como primer paso.

CompTIA Cloud+: certificación generalista de cloud que incluye seguridad. Nivel intermedio, sin experiencia mínima requerida formalmente. Menos específica de seguridad que CCSP pero útil como base generalista.

Ruta recomendada por nivel

• Principiante: CCSK (base conceptual cloud security) + cualquier certificación de fundamentos de un proveedor (AWS Cloud Practitioner, AZ-900, Cloud Digital Leader de GCP).
• Intermedio: certificación de arquitecto o practitioner del proveedor cloud que uses en tu trabajo + AZ-500/SC-500 (Azure) o AWS Security Specialty (AWS) o PCSE (GCP).
• Avanzado / sin atadura de proveedor: CCSP. Es el techo para perfiles de cloud security architect o CISO.

Para una visión completa del árbol de certificaciones de seguridad con cloud integrado, consulta el Mapa de Certificaciones de Seguridad y el listado de las mejores certificaciones cloud.

Cómo practicar cloud security de forma gratuita

La teoría sin práctica no sirve para conseguir trabajo. La buena noticia es que los tres grandes proveedores tienen capas gratuitas que permiten practicar los conceptos de seguridad sin coste.

Cuentas gratuitas de los proveedores

AWS Free Tier: durante 12 meses incluye instancias EC2 t2.micro/t3.micro (750 horas/mes), S3 (5 GB), RDS (750 horas), Lambda (1M invocaciones/mes) y muchos otros servicios. GuardDuty tiene 30 días de prueba gratuita. CloudTrail tiene un trail gratis. Suficiente para practicar IAM, configuración de grupos de seguridad, configuración de S3, CloudTrail, y GuardDuty.

Azure Free Account: 200 dólares de crédito durante 30 días + servicios gratuitos durante 12 meses (VMs B1s, 5 GB de almacenamiento Blob, Azure SQL Database…). Microsoft Defender for Cloud tiene 30 días de prueba. Suficiente para practicar Entra ID, Conditional Access, NSGs y Azure Policy.

Google Cloud Free Tier: siempre gratis: 1 instancia e2-micro en regiones seleccionadas, 5 GB de Cloud Storage, 1 GB de Cloud SQL. Más 300 dólares de crédito para nuevas cuentas. Security Command Center Standard es gratuito.

Laboratorios y plataformas de práctica

CloudGoat (Rhino Security Labs): entorno vulnerable de AWS deliberadamente inseguro, diseñado para practicar técnicas de ataque y defensa en AWS. De código abierto, se despliega en tu propia cuenta AWS. Escenarios incluyen privesc en IAM, explotación de roles Lambda, y acceso a datos en S3.

flaws.cloud y flaws2.cloud (Scott Piper): dos aplicaciones web vulnerables alojadas en S3 que guían a través de vulnerabilidades reales de AWS (bucket público, credenciales de instancia accesibles, roles IAM mal configurados). Gratuitas, sin necesidad de cuenta AWS para empezar.

TryHackMe: tiene rutas de aprendizaje específicas de cloud security con labs guiados en AWS y Azure. Algunos gratuitos, la mayoría requieren suscripción. Buena opción para principiantes que quieren estructura.

Hack The Box: tiene máquinas y laboratorios de cloud con configuraciones reales vulnerables. Más orientado a perfiles intermedios-avanzados.

A Cloud Guru / Pluralsight: plataformas de formación con entornos sandbox que dan acceso temporal a cuentas de AWS, Azure o GCP reales sin riesgo de facturación inesperada. De pago, pero con periodos de prueba.

Para más recursos gratuitos de ciberseguridad en general, consulta la guía de mejores cursos gratuitos de ciberseguridad.

Salidas profesionales y salarios en cloud security

Cloud security es uno de los perfiles más demandados y mejor pagados en ciberseguridad. La escasez de profesionales con conocimiento simultáneo de arquitectura cloud y seguridad crea un diferencial salarial claro respecto a perfiles de seguridad generalistas.

Los roles más frecuentes en ofertas de trabajo son:

• Cloud Security Engineer: implementa y mantiene controles de seguridad en entornos cloud (IAM, logging, CSPM, herramientas de detección). Perfil técnico.
• Cloud Security Architect: diseña la arquitectura de seguridad de entornos cloud complejos (multicloud, híbrido). Requiere experiencia amplia en cloud + seguridad.
• DevSecOps Engineer: integra seguridad en pipelines de CI/CD y en prácticas de desarrollo. Combina conocimiento de seguridad con desarrollo y operaciones.
• Cloud Security Analyst / SOC Analyst (Cloud): monitoriza entornos cloud desde un SOC usando SIEM y herramientas de detección como GuardDuty o Sentinel.

En cuanto a salarios, los datos varían según fuente y mercado. Como referencia orientativa (que puede variar significativamente por empresa, ubicación y experiencia): en España, perfiles de Cloud Security Engineer con 3-5 años de experiencia y certificaciones (AWS Security Specialty o CCSP) se sitúan en rangos de 45.000-70.000 € brutos anuales según datos de portales como InfoJobs, LinkedIn Jobs y Tecnoempleo para 2025-2026; en el mercado anglosajón (UK, EE.UU.), los rangos son notablemente más altos. Estos datos son orientativos y deben contrastarse con las ofertas actuales del mercado, ya que varían considerablemente.

Para una comparativa más amplia, consulta la guía de cómo empezar en ciberseguridad y el Mapa de Certificaciones con las rutas por especialidad.

Recursos para formarse en cloud security

Además de las certificaciones y los labs, hay recursos de formación concretos que merecen mencionarse:

Documentación oficial: las guías de mejores prácticas de seguridad de cada proveedor son gratuitas y exhaustivas. AWS Security Best Practices, el Microsoft Azure Security Benchmark, y el GCP Security Foundations Blueprint son puntos de partida excelentes y actualizados.

Cloud Security Alliance (CSA): el sitio de la CSA (cloudsecurityalliance.org) publica el Cloud Controls Matrix (CCM), la Guía de Seguridad Cloud (v4), el CAIQ (Consensus Assessments Initiative Questionnaire) y recursos para el CCSK, todos gratuitos.

CISA Cloud Security Resources: la Agencia de Ciberseguridad e Infraestructura de EE.UU. (cisa.gov/cloud-security) publica guías técnicas de seguridad cloud, incluyendo su serie sobre configuraciones seguras en entornos cloud.

Cursos estructurados: para quien prefiere formación guiada, las plataformas de cursos de ciberseguridad incluyen opciones cloud específicas, y el listado de cursos gratuitos tiene opciones accesibles sin inversión inicial.

Preguntas frecuentes sobre seguridad en la nube

¿Es la nube más segura que un datacenter propio?

La nube puede ser más segura o menos segura que un datacenter on-premises, dependiendo de quién la configure. La infraestructura física de AWS, Azure o GCP tiene inversiones en seguridad que pocas organizaciones pueden igualar por su cuenta. El problema es que esa infraestructura hay que configurarla correctamente, y muchos equipos no lo hacen. Un datacenter propio mal gestionado también tiene brechas; la diferencia es que los incidentes en cloud exponen directamente a internet.

¿Cuál es la diferencia entre CASB y CSPM?

CASB controla el acceso y la seguridad de los servicios SaaS (Microsoft 365, Salesforce, apps de shadow IT) desde la perspectiva del usuario. CSPM evalúa la configuración de los recursos IaaS/PaaS en las plataformas cloud (AWS, Azure, GCP) buscando misconfiguraciones. Son herramientas complementarias, no alternativas.

¿Qué certificación de cloud security debo sacar primero?

Depende de tu punto de partida. Si no tienes experiencia cloud: CCSK (CSA) como base conceptual + certificación de fundamentos del proveedor que uses (AWS Cloud Practitioner, AZ-900). Si ya trabajas en cloud: la certificación de seguridad del proveedor que uses en tu trabajo (AWS Security Specialty, SC-500 para Azure, PCSE para GCP). Si buscas algo agnóstico de proveedor y tienes experiencia: CCSP.

¿Qué es Zero Trust y cómo se aplica en cloud?

Zero Trust es un modelo de seguridad que no confía en nada ni en nadie por defecto, ni siquiera dentro de la red corporativa. En cloud, se implementa mediante: verificación explícita de identidad en cada acceso (MFA, acceso condicional), mínimo privilegio en todos los accesos, microsegmentación de red, y monitorización continua de comportamiento. Es el principio arquitectónico de referencia para entornos multicloud e híbridos. Microsoft tiene un framework Zero Trust documentado; Google Cloud tiene BeyondCorp (su implementación original de Zero Trust).

¿Las empresas pequeñas también necesitan seguridad cloud?

Sí, y especialmente si procesan datos de clientes o manejan pagos. Una startup con tres desarrolladores en AWS tiene exactamente las mismas posibilidades de tener un bucket abierto o una clave de AWS comprometida que una empresa grande. Los atacantes automatizados no discriminan por tamaño: escanean rangos de IP y repositorios en busca de credenciales expuestas de forma masiva.

¿Qué es la superficie de ataque en cloud y por qué es mayor que on-premises?

En un datacenter on-premises, la mayoría de los recursos no son accesibles desde internet. En cloud, la configuración por defecto de muchos servicios los expone a internet inmediatamente al crearlos. Añade el acceso a la consola de gestión (accesible desde cualquier navegador del mundo), las APIs que permiten gestionar toda la infraestructura programáticamente, y la federación de identidades que conecta el entorno cloud con el directorio corporativo, y tienes una superficie de ataque cualitativamente mayor que cualquier datacenter tradicional.

¿Qué pasa si mi proveedor cloud sufre una brecha?

Los incidentes que afectan a la infraestructura del proveedor en sí son raros (AWS, Azure y GCP tienen programas de seguridad física y lógica muy maduros). La mayoría de los incidentes que se atribuyen a «la nube» son en realidad misconfiguraciones o credenciales comprometidas del cliente. Si hay una brecha real en el proveedor, este tiene la obligación contractual de notificarla; los SLAs de seguridad están documentados en sus condiciones de servicio.