Seguridad en la Nube: Protegiendo los Datos en AWS, Azure y GCP

La nube ha transformado la infraestructura tecnológica — pero las misconfiguraciones son hoy la principal causa de brechas de datos. Aprende el modelo de responsabilidad compartida y cómo asegurar tus recursos en la nube.

El Modelo de Responsabilidad Compartida

El concepto más importante en seguridad cloud es el modelo de responsabilidad compartida: el proveedor de nube (AWS, Azure, GCP) es responsable de la seguridad de la nube; el cliente es responsable de la seguridad en la nube. La línea exacta depende del modelo de servicio.

Las Misconfiguraciones: La Causa #1 de Brechas en la Nube

Según el Cloud Security Alliance, las misconfiguraciones (errores de configuración) son responsables del mayor porcentaje de incidentes de seguridad en la nube. Dos casos emblemáticos ilustran el problema:

Capital One (2019) — $80 millones en multas, 100 millones de registros

Una exempleada de Amazon Web Services explotó una misconfiguration en el Web Application Firewall (WAF) de Capital One. El WAF estaba mal configurado de forma que permitía realizar solicitudes a IMDS (Instance Metadata Service) — un servicio interno de AWS que proporciona credenciales temporales de IAM a las instancias EC2. A través de un ataque SSRF (Server-Side Request Forgery), la atacante hizo que el WAF le pidiera al IMDS las credenciales de IAM de la instancia y se las devolviera. Con esas credenciales temporales, accedió a más de 700 buckets de S3 que contenían datos de 100 millones de clientes norteamericanos. Capital One fue multada con $80 millones por la OCC.

Twitch (2021) — Código fuente filtrado

Un bucket de S3 con configuración de acceso público expuso el código fuente completo de Twitch, datos internos y documentos confidenciales. Los datos fueron publicados en 4chan en un archivo de 125 GB. El origen: un servidor mal configurado que permitía acceso público sin autenticación.

Misconfiguraciones más comunes

• Bucket S3 con acceso público de lectura (permite a cualquiera descargar todos los archivos)
• Security groups con regla 0.0.0.0/0 en puertos críticos (SSH 22, RDP 3389) — abre esos puertos a todo internet
• Roles IAM con permisos de AdministratorAccess otorgados a servicios que no lo necesitan
• Credenciales de AWS hardcodeadas en código fuente subido a GitHub público
• Contraseñas por defecto en bases de datos desplegadas en cloud
• Versioning y logging de S3 desactivados (sin auditoría de quién accedió a qué)
• IMDSv1 habilitado (vulnerable a SSRF como en Capital One; IMDSv2 requiere autenticación adicional)

Identity and Access Management (IAM) en AWS

IAM es el sistema de control de acceso de AWS. Dominarlo es fundamental para la seguridad en la nube.

Componentes de IAM

• Users: identidades para personas humanas. Cada usuario tiene credenciales propias (contraseña para consola, access keys para API).
• Groups: colecciones de usuarios que comparten los mismos permisos. Facilita la gestión a escala.
• Roles: identidades que pueden ser asumidas por servicios de AWS (como EC2 o Lambda) o por usuarios de otras cuentas. Los roles tienen credenciales temporales automáticamente rotadas.
• Policies: documentos JSON que definen qué acciones están permitidas o denegadas sobre qué recursos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::mi-bucket-produccion/*"
    }
  ]
}

Principio de Mínimo Privilegio

Cada usuario, servicio o sistema debe tener exactamente los permisos que necesita para su función — ni uno más. Comenzar con cero permisos y añadir solo lo necesario, nunca al revés.

Herramientas para implementarlo:

• IAM Access Analyzer: analiza los permisos y detecta accesos no utilizados o excesivos. Si un rol tiene permiso para 50 acciones pero solo usa 3, Access Analyzer te lo indica para que puedas restringirlo.
• AWS Organizations SCPs (Service Control Policies): guardianes a nivel de cuenta que definen el máximo de permisos posibles en toda la cuenta, sin importar qué digan las políticas IAM individuales.

Cifrado de Datos en la Nube

Cifrado en reposo (at rest)

• AWS S3: SSE-S3 (AWS gestiona las claves), SSE-KMS (tú controlas las claves en AWS KMS), SSE-C (tú provees las claves)
• AWS KMS (Key Management Service): servicio gestionado para crear, rotar y auditar claves de cifrado. Integrado con la mayoría de servicios AWS.
• Las claves deben rotarse regularmente (KMS puede hacerlo automáticamente cada año)

Cifrado en tránsito (in transit)

• Exigir TLS 1.2 o superior en todas las comunicaciones
• AWS Certificate Manager (ACM) gestiona certificados TLS gratuitos para tus dominios
• Deshabilitar protocolos obsoletos: TLS 1.0, TLS 1.1, SSL 3.0, SSL 2.0
• En bases de datos RDS: exigir conexiones SSL/TLS obligatorias

Seguridad de Red en la Nube: VPC

Una Virtual Private Cloud (VPC) es una red virtual privada aislada dentro de AWS. Permite controlar completamente el tráfico de red de tus recursos.

Regla de oro para security groups

Nunca usar 0.0.0.0/0 (todo internet) para puertos de administración (SSH 22, RDP 3389). En su lugar: permitir solo las IPs específicas de tu empresa u oficina, o usar AWS Systems Manager Session Manager (que no requiere puertos abiertos).

Seguridad de Contenedores y Kubernetes

Seguridad de imágenes Docker

Los contenedores Docker se construyen sobre imágenes base que pueden contener vulnerabilidades conocidas. Prácticas esenciales:

• Escanear imágenes antes de desplegarlas con Trivy (gratuito, open source) o Clair
• Usar imágenes base mínimas (Alpine Linux en lugar de Ubuntu completo — menos superficie de ataque)
• No ejecutar contenedores como root — usar usuario no privilegiado
• Nunca incluir secretos (contraseñas, API keys) en la imagen Docker — usar variables de entorno o gestores de secretos

Kubernetes RBAC

Kubernetes tiene su propio sistema de control de acceso basado en roles (RBAC). Los mismos principios de mínimo privilegio aplican: cada pod debe tener solo los permisos que necesita. Un pod de frontend no debe tener permisos para modificar la configuración del cluster.

Gestión de secretos

Los secretos (contraseñas de bases de datos, API keys, certificados) nunca deben estar en el código fuente ni en variables de entorno hardcodeadas en las definiciones de pods. Las alternativas correctas son:

• Kubernetes Secrets: mejor que código, pero los secretos están codificados en base64 (no cifrados) por defecto en etcd
• HashiCorp Vault: la solución más robusta — gestión centralizada de secretos con rotación automática, auditoría completa y acceso dinámico (credenciales temporales generadas al momento)
• AWS Secrets Manager: servicio gestionado para secretos, con rotación automática integrada con RDS

Serverless Security: AWS Lambda

Las funciones serverless (Lambda) tienen una superficie de ataque diferente:

• Vulnerabilidades en dependencias: cada función Lambda tiene sus propias librerías. Deben escanearse con Snyk o AWS Inspector.
• Permisos excesivos: muchos desarrolladores asignan permisos de administrador a funciones Lambda por conveniencia. Cada función debe tener solo los permisos para sus acciones específicas.
• Event injection: si la función procesa input de usuarios (desde API Gateway, por ejemplo) sin validación, es vulnerable a inyección de código.
• Timeout y concurrencia: un atacante puede agotar el límite de concurrencia (DoS) o ejecutar funciones por períodos extremadamente cortos para evitar detección.

Monitoreo y Detección: Ver Todo lo que Pasa

AWS CloudTrail

CloudTrail registra cada llamada a la API de AWS: quién hizo qué, cuándo, desde qué IP y con qué resultado. Es el log de auditoría fundamental de AWS. Sin CloudTrail activado, es imposible investigar un incidente de seguridad — no sabrás qué acciones tomó el atacante.

AWS GuardDuty

GuardDuty es el sistema de detección de amenazas de AWS basado en machine learning. Analiza automáticamente CloudTrail, VPC Flow Logs y DNS logs para detectar:

• Minería de criptomonedas (instancias EC2 con patrones de uso de CPU y red característicos de minería)
• Uso de credenciales IAM comprometidas (credenciales usadas desde IPs maliciosas conocidas o ubicaciones inusuales)
• Comunicación con servidores de comando y control (C2) de malware conocido
• Escaneo de puertos interno (movimiento lateral en la VPC)
• Acceso inusual a buckets S3

DevSecOps: Seguridad Integrada en el Desarrollo

El modelo DevSecOps integra la seguridad en cada etapa del pipeline de CI/CD, en lugar de añadirla al final como auditoría:

• SAST en CI (Static Application Security Testing): SonarQube o Semgrep analizan el código en cada pull request, detectando vulnerabilidades antes de que el código llegue a producción
• Escaneo de dependencias: Snyk verifica automáticamente que ninguna librería tenga CVEs conocidos
• Escaneo de contenedores: Trivy escanea imágenes Docker antes de subirlas al registro
• IaC security (Infrastructure as Code): Checkov escanea archivos Terraform o CloudFormation antes de aplicarlos, detectando misconfiguraciones como buckets S3 públicos o security groups abiertos
• Security gates: el pipeline falla automáticamente si se detectan vulnerabilidades críticas — el código no puede desplegarse sin resolverlas