Casi ninguna cuenta de AWS se compromete por un zero-day exótico. Se compromete —o genera una factura sorpresa— por configuraciones aburridas y perfectamente arreglables que nadie tenía asignadas: un bucket público, una clave de acceso de hace tres años, un grupo de seguridad abierto a 0.0.0.0/0, un CloudTrail que nunca se activó.

Este es el checklist que aplico cuando entro en una cuenta nueva. No es teórico. Es el orden real en el que miro las cosas, y está ordenado por lo que más veces me he encontrado roto.

1. Identidad y accesos (IAM)

Aquí es donde aparecen la mitad de los hallazgos.

  1. La cuenta raíz no se usa. Ni para desplegar, ni para “una cosita rápida”. Si el último acceso de root es reciente, eso es el hallazgo número uno.
  2. La cuenta raíz tiene MFA. Sin excepciones.
  3. La cuenta raíz no tiene claves de acceso. Si existen, se borran hoy.
  4. Todos los usuarios IAM humanos tienen MFA activo.
  5. No hay claves de acceso con más de 90 días sin rotar.
  6. No hay claves de acceso sin usar desde hace meses. Una clave que nadie usa es una clave que nadie va a echar de menos cuando se filtre.
  7. Nadie tiene AdministratorAccess “por comodidad”. Cuento cuántos administradores hay. La respuesta sana suele ser uno o dos.
  8. Hay una política de contraseñas con longitud mínima y caducidad.
  9. Las aplicaciones usan roles, no claves. Una EC2 con credenciales en un .env es deuda de seguridad.
  10. Los roles cross-account exigen ExternalId. Si un tercero puede asumir un rol tuyo sin ese guardarraíl, cualquiera que adivine el ARN puede intentarlo.
# Credenciales sin usar y claves viejas, en una sola tabla
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

2. Exposición de red

  1. Ningún grupo de seguridad abre SSH (22) o RDP (3389) a 0.0.0.0/0. Este es el clásico absoluto.
  2. Ninguna base de datos es accesible desde internet. RDS con PubliclyAccessible: true aparece más de lo que debería.
  3. Los buckets de S3 tienen Block Public Access a nivel de cuenta.
  4. Ningún bucket concreto lo tiene desactivado sin una razón escrita.
  5. Las instancias EC2 usan IMDSv2 obligatorio. IMDSv1 es lo que convierte un SSRF en un robo de credenciales.
  6. No hay balanceadores ni API Gateway huérfanos apuntando a nada.
  7. Los registros DNS no apuntan a recursos que ya no existen. Un CNAME colgando hacia un bucket borrado es una toma de subdominio esperando a que alguien la reclame.

3. Datos y cifrado

  1. Los volúmenes EBS están cifrados, y el cifrado por defecto está activo en cada región.
  2. Las instantáneas de RDS están cifradas.
  3. Los buckets con datos personales tienen cifrado en reposo y versionado.
  4. Hay copias de seguridad reales y probadas. Una copia que nadie ha restaurado nunca no es una copia, es una esperanza.
  5. Las claves de KMS tienen rotación activada.

4. Trazabilidad

  1. CloudTrail está activo en todas las regiones, no solo en la que usas.
  2. Los logs de CloudTrail van a un bucket que las cuentas operativas no pueden borrar.
  3. GuardDuty está activo. Cuesta poco y detecta lo que a ti se te escapa.
  4. AWS Config está registrando cambios, al menos sobre los recursos críticos.
  5. Hay alertas de facturación. Un pico de coste suele ser el primer síntoma visible de un compromiso.

5. Capacidad de respuesta

  1. Alguien recibe las alertas. Una alarma que llega a un correo que nadie lee no existe.
  2. Sabes a quién llamar. Hay un responsable con nombre y apellidos para incidentes de seguridad.
  3. Has hecho el ejercicio mental una vez: si mañana se filtra una clave, ¿cuáles son los tres primeros comandos que ejecutas?

Qué encuentro normalmente

En la práctica, casi ninguna cuenta suspende los 30 puntos. Lo habitual es fallar entre seis y doce, y que dos o tres de ellos sean serios.

CategoríaQué falla más a menudo
IAMClaves viejas sin rotar, exceso de administradores
RedPuerto 22 abierto al mundo, RDS público
DatosVolúmenes sin cifrar, copias sin probar
TrazabilidadCloudTrail solo en una región, GuardDuty apagado
RespuestaAlertas que no llegan a nadie

Lo interesante es que casi ninguno de estos hallazgos requiere un proyecto. La mayoría se arreglan en una tarde. El problema no es la dificultad: es que nadie los tiene asignados.

Preguntas frecuentes

¿Cuánto se tarda en revisar esto? Con la cuenta delante y permisos de solo lectura, entre dos y cuatro horas para el barrido completo. Lo que lleva tiempo no es mirar: es priorizar y escribir por qué cada cosa importa en tu contexto concreto.

¿Hace falta dar acceso a la cuenta? Un rol de solo lectura es suficiente. Nunca hace falta permiso de escritura para auditar.

¿Esto sirve para el RGPD? Ayuda, pero no es lo mismo. El RGPD te va a preguntar por cifrado, control de accesos y trazabilidad —puntos 18 a 27 de esta lista— pero también por cosas que no viven en AWS, como tu registro de actividades de tratamiento.

¿Puedo hacerlo yo? Sí. La lista está entera aquí arriba. Lo que aporta alguien de fuera es criterio para ordenar los hallazgos y la costumbre de haber visto las mismas cosas cien veces.

Trabaja conmigo: auditoría completa de seguridad en AWS.

Sigue leyendo: cómo reducir la factura de AWS.

Pon unos ojos senior sobre tu cuenta de AWS. Empieza gratis con el checklist de 30 puntos, o contrata la auditoría completa a precio cerrado: cobertura de nivel CTO sin contratar a uno a jornada completa. Descarga el checklist gratuito