Guía Completa de Seguridad en la Nube: AWS, Azure y GCP (2026)

Las malas configuraciones en la nube son la causa número uno de filtraciones de datos en 2026. No hablamos de exploits sofisticados de zero-day: son buckets S3 públicos, roles IAM con permisos excesivos y grupos de seguridad que permiten acceso mundial.

Esta guía es el pilar del cluster Nube y DevOps de CyberFlows. Cubre los controles de seguridad fundamentales para los tres principales proveedores cloud — AWS, Azure y GCP — y conecta con artículos especializados que profundizan en cada área: desde la seguridad de contenedores Docker y Kubernetes hasta la forense en la nube post-incidente, pasando por pipelines CI/CD seguros, seguridad de APIs, aplicaciones móviles y APIs GraphQL.

1. Identidad y Acceso (IAM)

El 80% de los incidentes de seguridad en la nube involucran credenciales comprometidas o mal gestionadas. El principio de mínimo privilegio no es opcional.

Cuentas raíz y administrador global

Federación y roles

• AWS: Usar AWS IAM Identity Center (SSO) con un proveedor de identidad (Okta, Azure AD, Google Workspace) en lugar de crear usuarios IAM individuales. Implementar Service Control Policies (SCPs) a nivel de organización para establecer guardrails de permisos. Reemplazar políticas con Action: "*" por listas de acciones explícitas.
• Azure: Usar Azure AD Privileged Identity Management (PIM) para acceso just-in-time a roles elevados. Activar access reviews para revocar asignaciones obsoletas automáticamente. Aplicar Conditional Access que exija cumplimiento de dispositivo y restricciones por ubicación.
• GCP: Usar grupos de Google Workspace para gestionar roles a través de role bindings condicionales en lugar de otorgar permisos directamente a usuarios individuales. Usar Workload Identity Federation para que cargas de trabajo fuera de GCP puedan autenticarse sin service account keys de larga duración.

Rotación de credenciales

• AWS: Rotar IAM Access Keys cada 90 días. Preferir roles de IAM para servicios en lugar de access keys de larga duración.
• Azure: Usar managed identities para que los recursos de Azure se autentiquen sin necesidad de almacenar credenciales en el código.
• GCP: Usar service accounts con short-lived credentials (tokens JWT con expiración de 1 hora).

2. Seguridad de Red

No ejecutes todo en una sola red plana. La segmentación con VPCs/VNets es el pilar de una arquitectura segura.

• AWS: Usar VPCs separadas por entorno (producción, staging, desarrollo) conectadas mediante Transit Gateway. Desplegar recursos en subredes privadas. Usar VPC Endpoints (PrivateLink) para acceder a servicios de AWS sin atravesar internet público.
• Azure: Usar VNet peering con grupos de seguridad de red (NSGs) a nivel de subred y NIC. Implementar Azure Private Link para servicios PaaS.
• GCP: Usar VPCs con subnets segregadas por entorno. Usar Private Google Access y VPC Service Controls para evitar la exfiltración de datos.

Grupos de seguridad y firewall

• Asegurar que el security group por defecto en cada VPC deniegue todo el tráfico entrante (por defecto permite tráfico entrante desde sí mismo, lo cual debe eliminarse).
• Eliminar la VPC por defecto en todas las regiones para evitar el despliegue accidental de recursos con IPs públicas.
• Usar rangos de origen específicos en lugar de 0.0.0.0/0.
• Nunca exponer SSH (puerto 22) ni bases de datos a internet.

3. Cifrado y Protección de Datos

• AWS: Activar cifrado por defecto en buckets S3 (SSE-S3 o SSE-KMS). Usar AWS KMS para gestión centralizada de claves. Cifrar volúmenes EBS, instancias RDS, tablas DynamoDB y colas SQS. Establecer SCP para denegar cualquier acción que cree recursos sin cifrar.
• Azure: Usar Azure Disk Encryption para VMs. Cifrar bases de datos con Transparent Data Encryption (TDE). Usar Azure Key Vault para la gestión de secretos y claves.
• GCP: Usar CMEK (Customer-Managed Encryption Keys) con Cloud KMS. Activar cifrado por defecto en Cloud Storage (siempre activo, pero verificar que use CMEK si se requiere cumplimiento).

Dato real: Según el Cloud Security Baseline 2026, el cifrado del lado del servidor con claves gestionadas por el proveedor (SSE-S3, Azure SSE, Google Default Encryption) está activo por defecto en los tres proveedores desde 2024. El riesgo no es la falta de cifrado, sino que los recursos se expongan sin autenticación.

Buckets y almacenamiento público

• AWS: Activar S3 Block Public Access a nivel de cuenta (no solo a nivel de bucket). Usar S3 Access Points para control de acceso granular. Activar S3 Object Lock para backups inmutables. Monitorizar con Amazon Macie para descubrimiento de datos sensibles.
• Azure: Usar Azure RBAC para controlar acceso a Blob Storage. Activar soft delete y versioning en contenedores de almacenamiento.
• GCP: Usar IAM conditions y Public Access Prevention en buckets de Cloud Storage.

4. Monitorización y Registro

Sin logs, no hay detección. Sin detección, no hay respuesta.

• AWS: Activar CloudTrail en todas las regiones con multi-region trail. Activar VPC Flow Logs en todas las VPCs. Enviar todo a un bucket S3 centralizado en una cuenta de seguridad dedicada con Object Lock habilitado. Usar AWS Config Rules (gestionadas y personalizadas) para evaluar el cumplimiento de recursos en tiempo real.
• Azure: Usar Diagnostic Settings para enviar logs a Log Analytics Workspace. Implementar Microsoft Defender for Cloud para monitorización unificada.
• GCP: Usar log sinks agregados a nivel de organización. Activar Data Access logs para Cloud Storage y BigQuery (generan costos adicionales pero son esenciales para forense).

5. Detección de Amenazas

• AWS: Activar GuardDuty en todas las regiones y cuentas. GuardDuty analiza CloudTrail, VPC Flow Logs y registros de DNS para detectar amenazas. Aproximadamente cuesta $4 por millón de eventos de CloudTrail y $1/GB de logs de VPC Flow analizados. Activar GuardDuty S3 Protection y EKS Protection. Configurar los hallazgos para enviarlos a SecurityHub y SNS para alertas.
• Azure: Usar Microsoft Defender for Cloud (anteriormente Azure Security Center) con planes mejorados para servidores, bases de datos y cargas de trabajo de Kubernetes.
• GCP: Usar Security Command Center (Premium) para detectar amenazas en todas las cargas de trabajo. Activar Event Threat Detection y Container Threat Detection.

6. Cumplimiento y Postura de Seguridad

• AWS: Usar AWS Security Hub para agregar hallazgos de GuardDuty, Inspector, Macie y AWS Config en un solo lugar. Suscribirse a los CIS Benchmarks y AWS Foundational Security Best Practices.
• Azure: Usar Microsoft Defender for Cloud para el panel de cumplimiento normativo. Azure Policy permite auditar y forzar configuraciones seguras basadas en el Microsoft Cloud Security Benchmark (MCSB), que pasó de 220+ a 420+ controles en 2025.
• GCP: Usar Security Health Advisors y la política de la organización para aplicar restricciones a nivel de organización (ej: prohibir IPs públicas en VMs, requerir CMEK).

El Microsoft Secure Future Initiative (SFI) 2026, impulsado tras los incidentes de seguridad de 2023-2024 en Microsoft, establece seis pilares de ingeniería alineados con Zero Trust y el NIST CSF 2.0: proteger identidades y secretos, aislar sistemas, proteger redes, proteger sistemas de ingeniería, monitorizar y detectar amenazas, y acelerar la respuesta y remediación.

7. Marco Legal en la Nube

La nube no exime de obligaciones legales. De hecho, introduce complejidades adicionales que no existen en infraestructura on-premise.

Modelo de Responsabilidad Compartida

Todos los proveedores cloud operan bajo un modelo de responsabilidad compartida: el proveedor asegura la infraestructura (hardware, red, data centers), pero tú eres responsable de lo que despliegas en ella. La confusión sobre dónde empieza y termina la responsabilidad del proveedor es una de las causas principales de brechas.

RGPD y Residencia de Datos

Si procesas datos de ciudadanos europeos en la nube, el RGPD aplica independientemente de dónde esté el data center:

• Localización de datos: El RGPD no exige que los datos permanezcan en la UE, pero sí requiere que tengas una base legal para transferirlos fuera (cláusulas contractuales estándar, adecuación).
• Derechos del titular: Debes poder localizar, exportar y eliminar datos personales de la nube bajo demanda. Verifica que tu proveedor ofrezca herramientas para esto (AWS Macie + S3 Inventory, Azure Purview, GCP DLP).
• Notificación de brechas: El RGPD requiere notificación en 72 horas. En la nube, esto significa que tus procesos de detección (GuardDuty, Defender, SCC) deben estar configurados para alertar rápidamente, y tu plan de respuesta a incidentes debe incluir pasos específicos para forense en la nube.

NIS2 y Servicios Esenciales

La Directiva NIS2 amplía los requisitos de seguridad para entidades que proveen servicios digitales esenciales. Si tu infraestructura cloud soporta servicios críticos (salud, energía, transporte, telecomunicaciones), debes:

• Implementar controles de seguridad medibles (no solo "tenemos un firewall")
• Realizar evaluaciones de riesgo periódicas
• Reportar incidentes significativos en 24 horas (early warning)
• Mantener un plan de continuidad de negocio que incluya la nube

Práctica recomendada: Documenta explícitamente qué datos almacenas en la nube, dónde residen, bajo qué proveedor, y qué controles de seguridad applies. Este inventario es el primer paso tanto para RGPD como para NIS2.

Walkthrough: Un Incidente en la Nube, Paso a Paso

Para entender cómo se conectan todos los temas de este cluster, sigamos un escenario realista: una empresa detecta actividad sospechosa en su infraestructura cloud.

Hora 0: Detección

El equipo de seguridad recibe una alerta de GuardDuty (AWS): tráfico inusual desde un contenedor en el clúster EKS hacia una IP externa desconocida. El análisis de VPC Flow Logs confirma conexiones salientes no autorizadas.

Artículo relacionado: Forense en la Nube — cómo preservar evidencias de API y snapshots antes de que el atacante los destruya.

Hora 1-3: Investigación Inicial

Se inicia el proceso de forense en la nube. Se toma un snapshot del contenedor comprometido y se preservan los logs de CloudTrail y CloudWatch. El análisis preliminar revela que el contenedor ejecutaba una versión de la imagen con vulnerabilidades conocidas.

Artículo relacionado: Seguridad en Contenedores Docker y Kubernetes — por qué las imágenes base mínimas sin root y el escaneo continuo de vulnerabilidades con Trivy hubieran detectado esta problema antes del despliegue.

Hora 3-6: Vector de Entrada

La investigación rastrea el vector de entrada: el contenedor fue desplegado desde un pipeline de CI/CD que no ejecutaba escaneo de seguridad en la fase de build. El pipeline usaba una imagen base compartida entre múltiples servicios.

Artículo relacionado: DevSecOps: Pipeline CI/CD Seguro — las 5 etapas de un pipeline seguro (pre-commit, CI build, release, deploy, monitor) y por qué el escaneo en pre-commit y CI build hubiera bloqueado el despliegue.

Hora 6-12: Explotación

El atacante explotó una vulnerabilidad BOLA en una API interna para escalar privilegios dentro del clúster. La API no tenía rate limiting ni validación de autorización a nivel de objeto.

Artículo relacionado: OWASP API Security Top 10 — BOLA como la vulnerabilidad más común en APIs y cómo mitigarla con validación de autorización en cada endpoint.

Hora 12-24: Análisis de Alcance

Se descubre que la misma empresa también tiene una aplicación móvil que se comunica con las APIs afectadas. La app almacena tokens de autenticación de forma insegura en el dispositivo.

Artículo relacionado: Seguridad en Aplicaciones Móviles — OWASP MASVS como estándar para almacenamiento seguro, comunicación cifrada y autenticación robusta en Android e iOS.

Hora 24-48: Remediación

Se corrige el pipeline CI/CD, se actualizan las imágenes del contenedor, se implementa autorización BOLA en la API, se refuerza la app móvil, y se configuran alertas más granulares en GuardDuty. Se genera el informe de incidente con trazabilidad completa.

Artículo relacionado: Seguridad en APIs GraphQL — si la empresa usara GraphQL, introspection abuse y batching attacks habrían sido vectores adicionales a considerar.

Lecciones Aprendidas

Este escenario demuestra por qué la seguridad en la nube no es un solo tema: es un ecosistema donde IAM, red, cifrado, monitorización y detección trabajan juntos. Un fallo en cualquiera de ellos puede comprometer toda la cadena.

Checklist de Seguridad en la Nube

Usa esta lista como línea base mínima para cualquier cuenta en la nube:

• MFA activado en todas las cuentas humanas
• Cuenta raíz/administrador asegurada y no usada en el día a día
• Políticas IAM siguen el principio de mínimo privilegio
• No hay access keys de larga duración (o rotadas cada 90 días)
• VPC/VNet con segmentación adecuada por entorno
• Security groups deniegan todo el tráfico entrante por defecto
• No hay SSH público (puerto 22) ni acceso público a bases de datos
• Cifrado activado en todo almacenamiento y bases de datos
• TLS 1.2+ forzado en todos los endpoints
• CloudTrail / Audit Logs activados en todas las regiones
• VPC Flow Logs activados
• GuardDuty / Defender / Security Command Center activados
• S3 Block Public Access activado a nivel de cuenta
• Políticas de organización/SCP aplicadas para denegar configuraciones inseguras

Dentro de este Cluster: Deep Dives

Cada tema cubierto en esta guía tiene su propio artículo dedicado con tutoriales, configuraciones y casos de uso avanzados:

Lecturas Relacionadas

Temas complementarios que complementan esta guía desde otras perspectivas del cluster:

• Qué es Zero Trust (Confianza Cero) — Arquitectura de confianza cero para entornos cloud
• Firewall: Qué es, Tipos y Cómo Configurar uno — Tipos de firewall, iptables, pfSense y WAF
• Forense Digital: Guía Completa de Análisis de Incidentes — Disk, memory, network y cloud forensics con Volatility, Autopsy, Plaso y más