Seguridad en la nube: los errores más costosos en AWS, Azure y Google Cloud

Introducción al Problema#

Cuando ocurre un incidente de seguridad en la nube, la respuesta más común del equipo técnico es variaciones de "fue un problema de AWS" o "Azure tuvo un fallo". En la gran mayoría de los casos, eso es incorrecto. El modelo de responsabilidad compartida que todos los grandes proveedores cloud publican explícitamente dice: el proveedor es responsable de la seguridad DE la nube; el cliente es responsable de la seguridad EN la nube.

AWS protege los datacenters físicos, el hipervisor, la red subyacente. Vos sos responsable de cómo configurás tus instancias, tus buckets de almacenamiento, tus reglas de red, tus identidades y permisos. Y esa responsabilidad, en la práctica, se ejerce mal con una frecuencia sorprendente.

El problema no es que la nube sea insegura. El problema es que la nube es extraordinariamente fácil de usar — incluyendo fácil de configurar mal. Un bucket S3 público tarda 3 clics en crearse. Un security group que abre todos los puertos de internet a un servidor de base de datos tarda 30 segundos. Un usuario IAM con AdministratorAccess que nadie revocó cuando el proveedor externo terminó el proyecto sigue activo porque nadie hizo el offboarding. Las misconfiguraciones no son accidentes exóticos — son el estado default cuando no hay un proceso de revisión.

Cloud Security Posture Management (CSPM) es la categoría de herramientas que audita continuamente la configuración de tu entorno cloud y detecta estas desviaciones antes de que se conviertan en incidentes.

Caso Real o Ejemplo Cotidiano#

En 2025, una empresa de e-commerce argentina con presencia en AWS descubrió que tenía más de 40.000 archivos de clientes — incluyendo documentos de identidad capturados en el proceso de verificación — almacenados en un bucket S3 con acceso público de lectura. El bucket había sido creado como "temporal" durante un proceso de migración, y la configuración de "público" nunca fue revertida. El bucket llevaba 8 meses expuesto.

La empresa no lo descubrió por su propia auditoría. Lo descubrió porque alguien externo lo encontró usando Google Dork (site:s3.amazonaws.com) y los notificó responsablemente. El proceso de notificación responsable tardó 3 semanas en llegar al equipo correcto dentro de la empresa.

El costo del incidente: notificación a 40.000+ clientes (obligatoria bajo PDPA argentina y GDPR para clientes europeos), multa regulatoria, cobertura mediática negativa, y la consultoría de incident response. Todo evitable con una herramienta como ScoutSuite o Prowler — que hubiera detectado ese bucket público en la primera ejecución, en menos de 5 minutos.

Riesgos para la Empresa#

Explicación Técnica Sencilla#

El modelo de responsabilidad compartida#

PROVEEDOR CLOUD (AWS/Azure/GCP) es responsable de:
  ✅ Seguridad física del datacenter
  ✅ Red física y hardware de virtualización
  ✅ Hipervisor y aislamiento entre tenants
  ✅ Servicios managed (RDS, Lambda, etc.) a nivel de plataforma
  ✅ SLAs de disponibilidad

CLIENTE (vos) es responsable de:
  ❌ Configuración de seguridad de los recursos (S3, EC2, RDS)
  ❌ Gestión de identidades y accesos (IAM, RBAC)
  ❌ Cifrado de datos en tránsito y en reposo
  ❌ Configuración de red (Security Groups, NACLs, NSGs)
  ❌ Parcheo del SO en instancias IaaS
  ❌ Gestión de secretos y claves
  ❌ Auditoría y monitoreo de tu propio entorno

Las 5 misconfiguraciones más costosas#

1. Buckets de almacenamiento públicos

# Detectar con AWS CLI
aws s3api list-buckets --query 'Buckets[].Name' | \
  xargs -I {} aws s3api get-bucket-acl --bucket {}
# Buscar "AllUsers" o "AuthenticatedUsers" en los permisos

# Bloquear con "Block Public Access" a nivel de cuenta (AWS)
aws s3control put-public-access-block \
  --account-id TU_ACCOUNT_ID \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,\
   BlockPublicPolicy=true,RestrictPublicBuckets=true"

2. Security Groups / NSGs demasiado permisivos

Configuración peligrosa (muy común):
  Inbound: 0.0.0.0/0 → TCP 3306 (MySQL)
  Inbound: 0.0.0.0/0 → TCP 5432 (PostgreSQL)
  Inbound: 0.0.0.0/0 → TCP 3389 (RDP)

Configuración correcta:
  Inbound: 10.0.0.0/8 → TCP 3306 (solo red interna)
  Inbound: [IP_ESPECIFICA]/32 → TCP 3389 (solo IPs de admin autorizadas)

3. Permisos IAM excesivos El principio de menor privilegio en IAM significa que cada usuario, rol o cuenta de servicio tiene exactamente los permisos necesarios para su función — nada más. El patrón más peligroso es la política AdministratorAccess ("Action": "*", "Resource": "*") asignada a cuentas que no son la cuenta de administración central. Prowler y ScoutSuite detectan todos los casos de este tipo en minutos.

4. Credenciales en código fuente Los bots de GitHub y GitLab escanean constantemente repositorios en busca de patrones que coincidan con Access Keys (AWS), Client Secrets (Azure), Service Account Keys (GCP). Una vez encontradas, esas credenciales son abusadas en minutos. GitLeaks y git-secrets previenen esto en el pre-commit hook.

CSPM: auditoría automatizada#

Las herramientas CSPM mapean tu configuración cloud contra frameworks de seguridad (CIS Benchmarks, NIST, SOC 2) y presentan los hallazgos priorizados:

Prowler (ejemplo de output):
  [FAIL] check_s3_bucket_public_access_block [HIGH]
  Bucket: empresa-backup-2024 no tiene Block Public Access habilitado
  
  [FAIL] check_iam_root_hardware_mfa [CRITICAL]
  La cuenta root no tiene MFA de hardware configurado
  
  [FAIL] check_ec2_security_group_ssh_open [HIGH]
  Security Group sg-0x1234 permite SSH (port 22) desde 0.0.0.0/0
  en instancias: i-0abc123, i-0def456

Cómo Prevenirlo#

1. Corré Prowler o ScoutSuite en tu entorno cloud esta semana. No requieren infraestructura adicional — son herramientas CLI open source que usas con las credenciales que ya tenés. Prowler en AWS se ejecuta con prowler aws y genera un reporte HTML completo en 15-30 minutos. El primer escaneo siempre revela hallazgos críticos que nadie sabía que existían.

2. Activá "Block Public Access" a nivel de cuenta en AWS (no solo por bucket). Esta configuración global evita que cualquier bucket nuevo o existente en tu cuenta pueda hacerse público accidentalmente. Es una protección a nivel de organización que no requiere revisar cada bucket individualmente. En Azure, el equivalente es la política de acceso anónimo en Storage Accounts.

3. Auditá todos los usuarios IAM con claves de acceso de larga duración. Las claves de acceso que no se rotan ni se revocan son una bomba de tiempo. Usá aws iam generate-credential-report para ver la última vez que cada clave fue usada. Cualquier clave con más de 90 días sin rotación o que no ha sido usada en 30 días debe desactivarse inmediatamente.

4. Activá CloudTrail (AWS) / Activity Log (Azure) / Cloud Audit Logs (GCP) con retención mínima de 1 año. Sin logs, cualquier incidente en tu entorno cloud es irreconstruible. CloudTrail registra todas las llamadas de API — quién creó qué recurso, quién modificó qué permiso, quién accedió a qué datos. Cuesta centavos por GB y es la única fuente de verdad forense ante un incidente.

5. Usá Trivy para escanear imágenes Docker y archivos de infraestructura como código (IaC). Si usás Terraform, CloudFormation, Bicep o Helm Charts, Trivy puede escanear esos archivos antes del deploy y detectar misconfiguraciones antes de que lleguen a producción. Un pipeline de CI/CD que corre trivy config . sobre el repositorio de infraestructura es Cloud Security Posture Management preventivo.

6. Activá AWS Security Hub o Microsoft Defender for Cloud con los CIS Benchmarks. Ambos servicios son nativos del proveedor, gratuitos o de muy bajo costo para el nivel básico, y proveen una vista consolidada del posture de seguridad con priorización automática. AWS Security Hub agrega hallazgos de GuardDuty, Inspector, IAM Access Analyzer y herramientas de terceros en una sola consola.

Herramientas Recomendadas#

ScoutSuite (github.com/nccgroup/ScoutSuite): Herramienta de auditoría multi-cloud open source de NCC Group. Soporta AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud. Genera un reporte HTML interactivo con hallazgos categorizados por severidad y mapeados a frameworks como CIS Benchmarks. No requiere infraestructura adicional — corre localmente con las credenciales cloud del auditor. Ideal para auditorías puntuales y penetration testing de configuración cloud.

Prowler (prowler.com): La herramienta CSPM open source más completa para AWS, con soporte creciente para Azure y GCP. Más de 300 controles de seguridad que cubren CIS AWS Foundations Benchmark, NIST 800-53, GDPR, SOC 2, PCI DSS e ISO 27001. Se puede correr como CLI one-shot o como herramienta de auditoría continua. Prowler Pro (versión SaaS) agrega dashboard centralizado y remediation guidance. La versión open source es completamente funcional para la mayoría de las organizaciones.

Trivy (github.com/aquasecurity/trivy): Scanner de seguridad open source de Aqua Security. Escanea imágenes de contenedores en busca de vulnerabilidades conocidas (CVEs) en paquetes del OS y librerías de aplicación, archivos de IaC (Terraform, CloudFormation, Kubernetes manifests, Helm Charts) en busca de misconfiguraciones, y repositorios de código en busca de secretos expuestos. La integración con pipelines CI/CD es directa — un trivy image mi-imagen:latest antes de push al registry detecta vulnerabilidades críticas antes del deploy.

AWS Security Hub (aws.amazon.com/security-hub): Servicio nativo de AWS que agrega y normaliza hallazgos de seguridad de múltiples fuentes (GuardDuty, Inspector, IAM Access Analyzer, Firewall Manager, y más de 60 integraciones de terceros). Provee un score de seguridad basado en CIS AWS Foundations Benchmark con seguimiento de progreso en el tiempo. El primer mes es gratuito; después es un costo muy bajo por hallazgo procesado. Recomendado como componente central del stack de seguridad cloud para cualquier organización en AWS.

Microsoft Defender for Cloud (azure.microsoft.com/en-us/products/defender-for-cloud): Equivalente de AWS Security Hub para Azure. Evalúa el posture de seguridad contra CIS Microsoft Azure Foundations Benchmark, activa detección de amenazas en tiempo real en recursos Azure (VMs, containers, bases de datos, storage), y provee Secure Score con recomendaciones priorizadas. La capa básica (Foundational CSPM) es gratuita. Las capacidades avanzadas de detección de amenazas se facturan por recurso protegido.

Checklist Final#

• Se ejecutó al menos un escaneo CSPM (Prowler o ScoutSuite) en el entorno cloud en los últimos 90 días
• "Block Public Access" está habilitado a nivel de cuenta/organización en AWS para todos los S3 buckets
• No existen buckets de almacenamiento con acceso público (verificado, no asumido)
• CloudTrail / Activity Log / Cloud Audit Logs están habilitados en todas las regiones con retención ≥1 año
• La cuenta root (AWS) / cuenta de administración global (Azure/GCP) tiene MFA de hardware configurado
• No existen security groups / NSGs con puertos de base de datos (3306, 5432, 1433) abiertos a 0.0.0.0/0
• No existen usuarios IAM con políticas AdministratorAccess fuera de las cuentas de administración central
• Las claves de acceso IAM / Service Principal keys tienen rotación ≤90 días o son reemplazadas por roles con credenciales temporales
• El repositorio de código tiene GitLeaks o equivalente como pre-commit hook o pipeline check
• Las imágenes Docker se escanean con Trivy u otro scanner antes del deploy a producción
• AWS Security Hub o Microsoft Defender for Cloud está activo con CIS Benchmarks habilitados
• Existe un proceso documentado para remediar hallazgos críticos de CSPM en SLA definido (ej: 24hs para críticos)

CVE / Vulnerabilidades Relacionadas#

No se listan CVEs específicos en este artículo porque la naturaleza de los riesgos en seguridad cloud reside principalmente en misconfiguraciones operativas, no en vulnerabilidades de software con CVE asignado. Este punto es en sí mismo una lección importante: los escáneres de CVEs no detectan los riesgos más críticos en entornos cloud. Un bucket S3 público no tiene CVE. Un security group abierto a internet no tiene CVE. Un usuario IAM con AdministratorAccess no tiene CVE. Son decisiones de configuración incorrectas que ninguna herramienta de parcheo puede detectar.

Esta es la razón por la que el CSPM existe como categoría separada de la gestión de vulnerabilidades tradicional, y por qué organizaciones con procesos maduros de parcheo pueden tener incidentes graves en la nube. Son disciplinas complementarias, no intercambiables.

La fuente de referencia para misconfiguraciones con impacto real es el CSA Cloud Security Alliance Cloud Incidents Database y los reportes anuales de Verizon DBIR, que consistentemente muestran que las misconfiguraciones superan a las vulnerabilidades de software explotadas como causa raíz de incidentes cloud.

Conclusión y CTA#

"Es culpa de AWS" casi nunca es verdad. La nube tiene una postura de seguridad tan buena como las decisiones de configuración que tomaste al usarla. Y la realidad es que la mayoría de los entornos cloud empresariales tienen hallazgos críticos que nunca fueron auditados — no por negligencia, sino porque nadie estableció un proceso de revisión.

El primer paso no requiere presupuesto: bajate Prowler, configurá tus credenciales AWS/Azure, y corré el primer escaneo. El reporte que genera en 20 minutos va a mostrar más hallazgos de los que esperabas. Eso no es una mala noticia — es el estado real de tu postura de seguridad cloud, y es preferible descubrirlo vos primero.

¿Querés una auditoría de tu entorno cloud o ayuda para implementar CSPM continuo en tu organización? Hablá con nuestro equipo o continuá con el siguiente artículo: DevSecOps: integrá la seguridad en tu pipeline sin frenar al equipo.