Cloud security: errores comunes en empresas

El estado de la seguridad cloud en Chile y LATAM

La adopcion de servicios cloud en Chile ha crecido exponencialmente. Segun Statista 2025, el 78% de las empresas chilenas medianas y grandes utilizan al menos un proveedor cloud (AWS, Azure o GCP). Sin embargo, esta rapida migracion no siempre ha sido acompanada por una postura de seguridad adecuada.

En Latinoamerica, los incidentes de seguridad en la nube han aumentado un 48% entre 2023 y 2025, segun el reporte de Fortinet. Los errores mas comunes no son sofisticados exploits, sino configuraciones incorrectas que exponen datos y servicios al publico. Estos errores son prevenibles con los procesos y herramientas adecuados.

Los sectores mas afectados en la region incluyen financiero, retail y salud, donde la combinacion de datos sensibles y rapida adopcion cloud crea un escenario de riesgo significativo.

Error 1: Buckets S3/Blobs publicos

Este es probablemente el error mas comun y mas costoso en la nube. Un bucket S3 o Azure Blob Storage configurado como publico expone todo su contenido a internet sin autenticacion. Cualquier persona con la URL puede descargar los archivos.

Cada ano se reportan cientos de incidentes por buckets publicos que contienen datos de clientes, credenciales, backups, registros medicos y otra informacion confidencial. El costo promedio de una exposicion de datos por este medio supera los $3.5M USD.

Como ocurre

El error tipico ocurre cuando un desarrollador o administrador configura un bucket con politica de acceso publico para resolver un problema de conectividad temporario y olvida revertir el cambio. Otro escenario comun es el uso de ACLs (Access Control Lists) heredadas de la configuracion por defecto del proveedor.

# Politica de bloqueo de acceso publico en S3 (Terraform)
resource "aws_s3_bucket_public_access_block" "block_all" {
  bucket = aws_s3_bucket.data_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# Politica de bucket que requiere cifrado y deniega acceso publico
resource "aws_s3_bucket_policy" "deny_public" {
  bucket = aws_s3_bucket.data_bucket.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyPublicAccess"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:GetObject"
        Resource  = "${aws_s3_bucket.data_bucket.arn}/*"
        Condition = {
          StringNotEquals = {
            "s3:x-amz-server-side-encryption" = "aws:kms"
          }
        }
      }
    ]
  })
}

Mitigacion

• Habilitar Block Public Access a nivel de cuenta en AWS
• Implementar Service Control Policies (SCPs) que impidan la creacion de buckets publicos
• Configurar CloudTrail alerts para detectar cambios en politicas de acceso
• Usar herramientas como Prowler o ScoutSuite para auditorias automaticas
• Revisar periodicamente las ACLs y politicas de todos los buckets existentes

Error 2: Identidades con exceso de permisos (Overprivileged IAM)

El principio de menor privilegio es fundamental en la nube, pero raramente se implementa correctamente. Las identidades IAM (usuarios, roles, servicios) tipicamente reciben permisos mucho mas amplios de los necesarios, creando un superficie de ataque innecesaria.

El problema de "Effect": "Allow", "Action": "*", "Resource": "*"

Esta politica otorga acceso total a todos los recursos de AWS. Es sorprendentemente comun encontrarla en cuentas de produccion, especialmente en roles de servicios que fueron configurados rapidamente para resolver problemas de conectividad.

# MAL: Politica con acceso total
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}

# BIEN: Politica con least privilege para un Lambda
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789:table/UserSessions",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${aws:userid}"]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

Estrategia de remediacion

• Auditoria de permisos: Usar AWS Access Advisor o IAM Access Analyzer para identificar permisos no utilizados
• Politicas basadas en contexto: Implementar condiciones (IP, tiempo, MFA) en las politicas IAM
• Roles para servicios: Cada servicio debe tener su propio rol con permisos minimos, nunca compartidos
• Revision periodica: Establish trimestral de permisos con stakeholders de cada equipo

Error 3: Falta de segmentacion y network security

Muchas empresas migran a la nube manteniendo una arquitectura de red plana, donde todos los servicios pueden comunicarse libremente. Esto viola el principio de segmentacion y permite que un servicio comprometido sea usado como punto de pivot para atacar otros recursos.

El error de "todo abierto al mundo"

Un error clasico es configurar un Security Group o firewall que permite trafico SSH/RDP desde 0.0.0.0/0. Esto expone los servidores de administracion a escaneo y fuerza bruta desde cualquier parte del mundo.

# MAL: Security Group abierto al mundo
resource "aws_security_group" "bad_example" {
  name   = "web-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # Exponer SSH al mundo
  }
}

# BIEN: Security Group segmentado
resource "aws_security_group" "web" {
  name   = "web-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
    description     = "Solo desde ALB"
  }

  # Sin acceso SSH directo - usar SSM Session Manager
}

resource "aws_security_group" "app" {
  name   = "app-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web.id]
    description     = "Solo desde tier web"
  }
}

resource "aws_security_group" "db" {
  name   = "db-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "Solo desde tier app"
  }
}

Error 4: Secrets hardcodeados en codigo o configs

Colocar credenciales, tokens API, contraseñas de base de datos o claves de cifrado directamente en el codigo fuente o en archivos de configuracion es uno de los errores mas criticos y evitables. Estos secrets quedan expuestos en repositorios Git, historial de commits, artefactos de compilacion y logs.

Como llegan los secrets al codigo

• Desarrolladores que hardcodean credenciales para pruebas rapidas y el codigo llega a produccion
• Archivos .env o config.yaml commiteados al repositorio
• Variables de entorno en archivos docker-compose.yml
• Credenciales en pipelines de CI/CD como parte de la configuracion

# MAL: Secrets en docker-compose.yml (NUNCA hacer esto)
version: '3.8'
services:
  api:
    image: myapp:latest
    environment:
      - DB_PASSWORD=SuperSecret123!
      - AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
      - AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# BIEN: Secrets desde Vault o gestion de secrets
version: '3.8'
services:
  api:
    image: myapp:latest
    environment:
      - DB_PASSWORD=/run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    external: true

Soluciones

• Git-secrets / TruffleHog: Herramientas que escanean repositorios antes del commit para detectar secrets
• HashiCorp Vault: Gestor centralizado de secrets con rotacion automatica
• AWS Secrets Manager / Azure Key Vault: Servicios nativos de cada proveedor
• pre-commit hooks: Hooks que impiden el commit de archivos que contengan secrets
• Scan en CI/CD: Pipeline que escanea el codigo y los artefactos antes del despliegue

Error 5: Ausencia de monitoreo y logging

Sin logging y monitoreo adecuado, una brecha en la nube puede pasar desapercibida durante meses. El monitoreo no es opcional: es un requisito fundamental para la deteccion temprana de incidentes y el cumplimiento normativo.

Que debes monitorear

• CloudTrail: Todas las llamadas API en la cuenta, incluyendo who, what, when, from where
• VPC Flow Logs: Trafico de red entrante y saliente de las VPCs
• Access Logs: Logs de ALB, CloudFront, S3 para detectar patrones de acceso anomalo
• GuardDuty / Microsoft Defender for Cloud: Deteccion de amenazas basada en ML
• Config Rules: Monitoreo continuo de la configuracion y compliance

# Ejemplo de regla CloudWatch para alerta de actividad sospechosa
# Detecta deshabilitar CloudTrail desde una IP externa

{
  "source": ["aws.cloudtrail"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["cloudtrail.amazonaws.com"],
    "eventName": ["StopLogging", "DeleteTrail"],
    "userIdentity": {
      "sessionContext": {
        "sessionIssuer": {}
      }
    },
    "sourceIPAddress": {
      "not-ip-prefix": ["10.0.0.0/8", "172.16.0.0/12"]
    }
  }
}

Error 6: No tener plan de respuesta en la nube

Las organizaciones tipicamente tienen planes de respuesta a incidentes para infraestructura on-premise, pero no consideran los escenarios especificos de la nube. Un incidente cloud requiere procedimientos diferentes: revocar access keys, aislar cuentas, preservar evidencia en servicios managed y coordinar con el proveedor cloud.

Componentes de un plan de respuesta cloud

• Playbooks especificos: Procedimientos para escenarios como compromiso de access keys, bucket publico, cryptomining, etc.
• Contactos del proveedor: Numeros de emergencia y procesos de soporte para AWS, Azure o GCP
• Herramientas pre-instaladas: Configuracion de GuardDuty, CloudTrail, alertas automatizadas
• Preservacion de evidencia: Como preservar logs y snapshots antes de que un atacante los elimine
• Comunicacion interna: Canales seguros para coordinar la respuesta cuando los sistemas principales estan comprometidos

Frameworks de referencia

Para estructurar el programa de seguridad cloud, existen frameworks reconocidos que proporcionan guias y benchmarks especificos:

CIS Benchmarks

El Center for Internet Security publica benchmarks especificos para AWS, Azure y GCP. Estos documentos detallan cientos de configuraciones recomendadas con nivel de impacto (Level 1 / Level 2) y procedimientos de verificacion. Son la referencia tecnica mas utilizada para auditorias de configuracion cloud.

AWS Well-Architected Framework - Security Pillar

El pillar de seguridad del Well-Architected Framework define 6 principios: seguridad de la nube, trazabilidad, seguridad en ciudades, automatizacion de seguridad, datos en reposo y en transito, y manage de accesos. Cada principio se desglose en best practices verificables.

CSA Cloud Controls Matrix (CCM)

El Cloud Security Alliance ofrece el CCM, un framework de controles de seguridad alineado con multiples estandares (ISO 27001, NIST, PCI-DSS). Es especialmente util para organizaciones que necesitan demostrar compliance con multiples regulaciones simultaneamente.

# Ejemplo de evaluacion CIS Benchmark con Prowler
# Instalacion y ejecucion

pip install prowler
prowler aws --checks \
  check_s3_bucket_public_access \
  check_iam_root_access_key \
  check_security_groups_unrestricted \
  check_cloudtrail_enabled \
  check_guardduty_enabled \
  --output-format html \
  --report-name cis-benchmark-report