¿Qué tan expuesta está tu infraestructura AWS?

Tu infraestructura AWS puede estar funcionando perfectamente… y estar completamente expuesta.

AWS te da una infraestructura extraordinariamente potente. Pero la seguridad final de lo que corre ahí no depende solo de AWS: depende de tu configuración, tus permisos, tus identidades, tus aplicaciones, tus redes, tus secretos, tu almacenamiento, tu monitoreo, tu código y tus procesos operativos. Ese es el terreno donde la seguridad AWS se gana o se pierde.

AWS no necesariamente está "hackeado". Muchas veces el problema es que alguien configuró una puerta que nunca debió quedar abierta.

Una infraestructura puede funcionar correctamente y ser insegura

FUNCIONA  ≠  ESTÁ SEGURA

El servidor responde. La aplicación funciona. Los usuarios inician sesión. La base de datos está disponible. Los archivos se guardan. Todo en verde. Y aun así puede existir, en esa misma cuenta:

• Un puerto abierto que nadie recuerda por qué existe
• Una Access Key olvidada de un desarrollador que ya no está
• Un bucket S3 con más acceso del que debería
• Un usuario con permisos de administrador que solo necesitaba leer un reporte
• Una base de datos que acepta conexiones desde Internet
• Secretos escritos directamente en el código
• Cero logs y cero alertas: nadie sabría si algo ya pasó

La disponibilidad de un sistema no demuestra su seguridad.

¿Por dónde pueden entrar?

Una arquitectura AWS moderna no es un servidor: es un conjunto de servicios conectados — IAM, EC2, ECS, Lambda, API Gateway, ALB, CloudFront, S3, RDS, Aurora, DynamoDB, VPC, Secrets Manager, KMS… Cada servicio es también una superficie que revisar. El destino final del atacante casi siempre es el mismo: tus datos.

1. IAM: el primer lugar que deberías revisar

Uno de los mayores riesgos de una cuenta AWS no está en un servidor: está en quién tiene permiso para hacer qué. Usuarios, roles, policies, grupos, cuentas antiguas, Access Keys, MFA, accesos cross-account. La seguridad IAM en AWS es la cerradura maestra de todo lo demás.

Una identidad con permisos excesivos puede convertirse en una llave maestra.

2. Access Keys: una credencial puede convertirse en una puerta de entrada

Las Access Keys viven más de lo que deberían: en repositorios, en archivos .env, en scripts, en servidores, en pipelines de CI/CD, en laptops, en logs, en backups. Una credencial de larga vida que sale de tu control es una puerta de entrada directa a la API de AWS — con los permisos que esa identidad tenga.

Código
  ↓
Credencial expuesta
  ↓
AWS API
  ↓
IAM
  ↓
Recursos AWS

La dirección correcta: credenciales temporales, IAM Roles en lugar de llaves fijas, Secrets Manager, rotación, eliminación de credenciales que ya no se usan y monitoreo de su actividad.

3. S3: ¿quién puede leer tus datos?

En S3 viven documentos, backups, archivos de clientes, reportes, logs y exports de bases de datos — el corazón informativo de la empresa. El riesgo viene de un bucket público, una bucket policy demasiado generosa, permisos excesivos, accesos cross-account sin control o credenciales comprometidas.

El problema no es solamente dónde están tus datos. Es quién puede acceder a ellos.

4. EC2 y servidores expuestos

No todo debe estar accesible desde Internet. Un 0.0.0.0/0 sobre SSH, sobre una base de datos, sobre Redis, sobre un panel administrativo o sobre un puerto de administración significa: cualquiera en el mundo puede tocar esa puerta. La arquitectura correcta pone capas entre Internet y tu aplicación — y deja lo interno en redes privadas.

5. RDS y Aurora: tu base de datos no debería estar expuesta

Publicly Accessible, Security Groups abiertos, subnets públicas: la receta para que una base de datos empresarial reciba conexiones directas desde Internet. No toda exposición pública es automáticamente una vulnerabilidad — pero debe existir una justificación arquitectónica y controles a la altura: red privada, cifrado, credenciales en Secrets Manager, rotación y logging.

Si una base de datos empresarial puede recibir conexiones directamente desde Internet, hay que preguntarse por qué.

6. Security Groups: una regla puede abrir demasiado

SSH         0.0.0.0/0
PostgreSQL  0.0.0.0/0
MySQL       0.0.0.0/0

Cada regla debería poder explicar su existencia: origen, destino, puerto, servicio y necesidad real. Cuando la respuesta es "así funcionó", la regla está diseñada por accidente.

"Está funcionando" no significa "está correctamente expuesto".

7. Secretos dentro del código

API_KEY
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
DATABASE_PASSWORD
JWT_SECRET

Repos Git, archivos .env, imágenes de Docker, logs, scripts, pipelines: todos son lugares donde los secretos terminan viviendo — y multiplicándose. El destino correcto es AWS Secrets Manager o Parameter Store, IAM Roles donde una credencial ni siquiera es necesaria, variables seguras en CI/CD y rotación.

8. CloudTrail: si no sabes quién hizo qué, estás prácticamente ciego

La seguridad no consiste únicamente en bloquear ataques. También consiste en poder reconstruir lo ocurrido.

¿Quién modificó este recurso? ¿Cuándo, desde dónde, con qué API? ¿Se creó un usuario? ¿Se cambió una policy? ¿Se eliminó algo? Si tu organización no puede responder esas preguntas, no tiene visibilidad — tiene fe. AWS CloudTrail, CloudWatch, AWS Config y Detective existen exactamente para esto.

9. GuardDuty y detección de amenazas

Prevención + Detección + Respuesta

Configurar Security Groups es prevención. Pero una arquitectura de seguridad madura también detecta: GuardDuty analiza señales de la cuenta —actividad de APIs, patrones de red, comportamiento de identidades— y levanta la mano cuando algo no cuadra, sin que tengas que construir esa detección tú mismo. Security Hub concentra los hallazgos en un solo lugar priorizable.

10. Tu aplicación también forma parte de la superficie de ataque

AWS puede estar correctamente configurado y tu aplicación seguir siendo vulnerable.

Laravel, FastAPI, Node.js, tus APIs, tus dependencias, tus contenedores, tu CI/CD, tu autenticación y autorización, tus endpoints administrativos: nada de eso lo protege AWS por ti. La seguridad real es la suma — seguridad de AWS, seguridad de infraestructura y seguridad de aplicación. Evaluar una sin las otras deja huecos exactamente donde los atacantes buscan.

11. Containers y Kubernetes agregan otra superficie

Docker, ECR, ECS, EKS, Fargate: una arquitectura cloud moderna también corre software empaquetado, con sus imágenes, sus permisos, sus secretos y sus workloads. Una imagen vieja con dependencias vulnerables o un rol de tarea con permisos de más son superficie de ataque igual que un puerto abierto — solo que menos visible.

¿Qué pasa si alguien consigue acceso?

Según los permisos y controles existentes, el impacto puede ir de robo de información a modificación o eliminación de datos, interrupción del servicio, creación de infraestructura no autorizada, cryptomining y abuso de recursos — o el compromiso de otras cuentas conectadas.

Cryptojacking: cuando alguien usa tu AWS para su propio beneficio

Con acceso a una cuenta, un atacante puede levantar cómputo para cargas que no son tuyas — minería incluida. Los síntomas: CPU inesperada, instancias nuevas que nadie pidió, consumo que sube y una factura AWS que no cuadra con tu operación.

Ransomware y destrucción de datos

El ransomware en cloud no es solo cifrar servidores: es eliminar, modificar, cifrar y —el golpe real— destruir los backups con las mismas credenciales comprometidas. Los controles que cambian el resultado: backups con versioning y Object Lock, separación de cuentas, mínimo privilegio, MFA, logging y monitoreo.

Un backup que puede ser eliminado con las mismas credenciales que protegen producción no es una estrategia de recuperación suficientemente aislada.

La IA está cambiando la velocidad de los ataques

Sin sensacionalismos: la automatización y la IA aceleran el análisis de grandes volúmenes de información, la identificación de configuraciones débiles y la generación de campañas. Lo que antes requería semanas de trabajo manual hoy se automatiza. La conclusión práctica no es miedo — es simetría: la defensa también necesita automatización.

Telemetría → Contexto → Análisis → Detección → Priorización → Respuesta

¿Cómo saber qué tan expuesto está tu AWS?

Identidad

• MFA habilitado en todas las cuentas humanas
• Usuarios antiguos eliminados
• Access Keys innecesarias eliminadas
• IAM Roles bien utilizados y privilegio mínimo
• Sin permisos administrativos innecesarios
• Accesos cross-account controlados

Red

• Sin puertos administrativos innecesariamente públicos
• Security Groups revisados regla por regla
• Bases de datos en redes privadas cuando corresponde
• VPC con segmentación adecuada

Datos

• S3 revisado y bloqueo de acceso público activo
• Cifrado en reposo
• Versioning donde corresponde
• Backups existentes y protegidos

Aplicaciones

• Dependencias actualizadas
• Secrets fuera del código
• APIs protegidas, autenticación y autorización robustas
• Contenedores e imágenes revisados

Monitoreo

• CloudTrail activo con retención de logs
• GuardDuty y Security Hub habilitados
• AWS Config y CloudWatch con alertas que alguien recibe

Una auditoría de seguridad AWS debería responder estas preguntas

1. 1¿Quién tiene acceso a nuestra cuenta AWS y qué usuarios tienen privilegios administrativos?
2. 2¿Existen credenciales antiguas todavía activas?
3. 3¿Qué recursos están expuestos a Internet — y cuáles no deberían estarlo?
4. 4¿Tenemos bases de datos públicas o buckets S3 con permisos excesivos?
5. 5¿Dónde están almacenados nuestros secretos?
6. 6¿Podemos saber quién modificó un recurso, cuándo y desde dónde?
7. 7¿Tenemos detección de amenazas funcionando — o solo prevención?
8. 8¿Nuestros backups sobrevivirían a las credenciales que protegen producción?
9. 9¿Qué pasaría si una credencial fuera comprometida hoy?
10. 10¿Nuestra aplicación tiene vulnerabilidades que la infraestructura no puede tapar?

No se trata solamente de encontrar vulnerabilidades

Descubrir → Analizar → Priorizar → Corregir → Validar → Monitorear

Una lista de 200 alertas sin contexto no protege nada. El valor está en clasificar cada hallazgo — crítico, alto, medio, bajo — por impacto real, probabilidad, exposición, facilidad de explotación e impacto de negocio, y en atacar primero lo que de verdad reduce riesgo.

¿Qué revisamos en una evaluación de seguridad AWS?

La arquitectura segura no es igual para todas las empresas

No existe la checklist universal. La arquitectura correcta depende del tipo de empresa, sus datos, su regulación, la criticidad de la operación, los usuarios, el tráfico, el presupuesto y la tolerancia al riesgo. Por eso la evaluación importa más que la receta.

Seguridad no significa cerrar todo. Significa permitir exactamente lo necesario y controlar lo demás.

Un caso conceptual

Una empresa —ficticia, pero el patrón se repite— tenía AWS funcionando, la aplicación funcionando, la base de datos funcionando y backups corriendo. Durante una evaluación aparecieron: permisos IAM excesivos, Security Groups innecesariamente abiertos, credenciales antiguas activas, secretos almacenados donde no debían, monitoreo incompleto y recursos sin controles.

No había ocurrido un incidente. Ese era precisamente el mejor momento para corregirlo.

AWS no puede proteger lo que tú configuraste incorrectamente

El modelo de responsabilidad compartida de AWS es simple de enunciar y fácil de olvidar: AWS asegura la infraestructura del cloud; tú aseguras lo que pones dentro. Las fronteras exactas dependen del servicio (no es lo mismo Lambda que EC2), pero identidades, permisos, datos, configuración y aplicaciones siempre quedan de tu lado.

¿Tu AWS está realmente protegido?

No necesitas esperar una intrusión para descubrir que tu infraestructura tenía una puerta abierta. Una evaluación de seguridad permite conocer qué está expuesto, qué permisos sobran, qué controles faltan y qué debe corregirse primero — con prioridades, no con una lista interminable.

La seguridad no consiste en esperar a detectar un ataque. Consiste en reducir las oportunidades para que ocurra.

WITS — Software · IA · Automatización · Ciberseguridad · AWS