Mejorando la Seguridad de tu API con CloudFront y AWS Managed Prefix Lists
- hace 3 días
- 5 Min. de lectura
Introducción
Cuando desplegamos APIs en AWS usando Application Load Balancers (ALB), es común configurar los Security Groups para permitir tráfico HTTP/HTTPS desde cualquier origen (0.0.0.0/0). Si bien esto funciona, viola el principio de mínimo privilegio y expone tu infraestructura a riesgos innecesarios.
En este artículo, te mostraré cómo mejorar la seguridad de tu API utilizando CloudFront como capa de distribución y restringiendo el acceso al ALB únicamente a las IPs de CloudFront mediante AWS Managed Prefix Lists.
Arquitectura Actual (Insegura)
Nuestra infraestructura inicial incluye:
VPC: 10.100.0.0/16 con subnets públicas y privadas en 2 AZs.
Application Load Balancer: Internet-facing en subnets públicas.
EC2 Instance: En subnet privada ejecutando Nginx.
CloudFront: Distribución con dominio personalizado testmauro.sandbox.teratest.net.
Route53: DNS apuntando a CloudFront.
ACM Certificate: SSL/TLS para el dominio personalizado.
El Problema de Seguridad
Actualmente, el Security Group del ALB tiene la siguiente configuración:
{
"IpProtocol": "tcp",
"FromPort": 80,
"ToPort": 80,
"CidrIpv4": "0.0.0.0/0"
}
¿Qué significa esto?
Cualquier persona en internet puede acceder directamente al ALB.
Se bypasea CloudFront y sus beneficios (caching, DDoS protection, WAF).
No hay control sobre quién accede a tu origen.
Validación del Problema
Prueba 1: Acceso Directo al ALB
Probemos acceder directamente al ALB sin pasar por CloudFront:
curl -s -o /dev/null -w "Status: %{http_code}\n" \ http://demo-sbx-alb-142673723.us-east-1.elb.amazonaws.com
Resultado:
Status: 200
El ALB responde correctamente - Esto es un problema de seguridad.
Prueba 2: Contenido Accesible
Resultado:
<!DOCTYPE html>
<html>
<head>
<title>Teratest</title>
</head>
<body>
<h1>Hola desde teratest</h1>
</body>
</html>
El contenido completo es accesible sin restricciones.
Prueba 3: Acceso via CloudFront
Ambas rutas funcionan, pero solo CloudFront debería ser el punto de entrada.
Análisis del Security Group
Inspeccionemos las reglas actuales del Security Group del ALB:
aws ec2 describe-security-group-rules \
--filters Name=group-id,Values=sg-0482d99e7921588bc \
--profile teracloud-sbx --region us-east-1
Reglas actuales:
Tipo | Protocolo | Puerto | Origen | Descripción |
Ingress | TCP | 80 | 0.0.0.0/0 | ⚠️ TODO internet |
Egress | All | All | 0.0.0.0/0 | Salida sin restricción |
¿Por qué es esto un problema?
Bypass de CloudFront: Los atacantes pueden descubrir la URL del ALB y acceder directamente.
Sin protección DDoS: CloudFront incluye AWS Shield Standard, pero se bypasea.
Sin WAF: Si configuras AWS WAF en CloudFront, no aplica al tráfico directo.
Sin caching: Cada request golpea directamente tu origen.
Costos mayores: Pagas más por transferencia de datos desde el ALB vs CloudFront.
Violación de compliance: Muchos frameworks de seguridad requieren mínimo privilegio.
Implementación del Hardening
En la siguiente sección, implementaremos las siguientes mejoras:
Identificar el Managed Prefix List de CloudFront para la región.
Remover la regla insegura 0.0.0.0/0 del Security Group.
Agregar regla permitiendo solo el Prefix List de CloudFront.
Validar que el acceso directo al ALB falla.
Confirmar que el acceso via CloudFront sigue funcionando.
Arquitectura Mejorada (Segura)
Flujo de tráfico seguro:
Usuario → CloudFront (HTTPS) → ALB (HTTP, solo desde CloudFront IPs) → EC2
Flujo bloqueado:
Usuario → ALB directo ❌ BLOQUEADO
Recursos de la infraestructura
Toda la infraestructura fue creada en la cuenta AWS 208619972546 (región us-east-1):
VPC: vpc-0e56f6e80dd047044.
Security Group ALB: sg-0482d99e7921588bc.
CloudFront Distribution: EYE32G0U68ZU6.
Dominio: testmauro.sandbox.teratest.net.
Próximos pasos
En la siguiente parte de este artículo, implementaremos el hardening de seguridad y validaremos que:
El acceso directo al ALB es bloqueado.
El acceso via CloudFront funciona correctamente.
La configuración cumple con el principio de mínimo privilegio.
Parte 2: Implementación del Hardening
Paso 1: Identificar el Managed Prefix List de CloudFront
AWS proporciona Managed Prefix Lists para los servicios de CloudFront. Primero, necesitamos identificar el ID del prefix list:
aws ec2 describe-managed-prefix-lists \
--filters "Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing" \
--region us-east-1
Paso 2: Modificar el Security Group
Ahora modificaremos el Security Group del ALB para: 1. Remover la regla insegura que permite 0.0.0.0/0 2. Agregar una nueva regla que solo permita el Prefix List de CloudFront.
Comando para remover la regla insegura:
aws ec2 revoke-security-group-ingress \
--group-id sg-0482d99e7921588bc \
--ip-permissions IpProtocol=tcp,FromPort=80,ToPort=80,IpRanges='[{CidrIp=0.0.0.0/0}]' \
--region us-east-1
Comando para agregar la regla segura:
aws ec2 authorize-security-group-ingress \
--group-id sg-0482d99e7921588bc \
--ip-permissions IpProtocol=tcp,FromPort=80,ToPort=80,PrefixListIds='[{PrefixListId=<PREFIX_LIST_ID>}]' \
--region us-east-1
Paso 3: Validación Post-Hardening
Prueba 1: Acceso directo al ALB (debe fallar)
Resultado esperado:
Status: 000curl: (28) Connection timed out
El acceso directo ahora está bloqueado - ¡Éxito!
Prueba 2: Acceso via CloudFront (debe funcionar)
curl -s -o /dev/null -w "Status: %{http_code}\n" \
Resultado esperado:
Status: 200
CloudFront funciona correctamente - La aplicación sigue accesible por la ruta correcta.
Prueba 3: Verificar contenido
Resultado:
<!DOCTYPE html>
<html>
<head>
<title>Teratest</title>
</head>
<body>
<h1>Hola desde teratest</h1>
</body>
</html>
El contenido se sirve correctamente a través de CloudFront.
Paso 4: Inspeccionar las nuevas reglas
aws ec2 describe-security-group-rules \
--filters Name=group-id,Values=sg-0482d99e7921588bc \
--region us-east-1
Reglas actualizadas:
Tipo | Protocolo | Puerto | Origen | Descripción |
Ingress | TCP | 80 | pl-xxxxxx (CloudFront) | Solo CloudFront |
Egress | All | All | 0.0.0.0/0 | Salida sin restricción |
Comparación: antes vs después
Antes (inseguro)
Después (seguro)
Beneficios obtenidos
Seguridad
Principio de mínimo privilegio: Solo CloudFront puede acceder al ALB .
Protección DDoS: AWS Shield Standard protege CloudFront.
WAF ready: Puedes agregar AWS WAF en CloudFront.
Ofuscación del origen: La URL del ALB no es útil para atacantes.
Performance
Caching global: Contenido servido desde edge locations.
Menor latencia: Usuarios acceden desde el edge más cercano.
Compresión: CloudFront comprime automáticamente.
Costos
Menor transferencia desde origen: CloudFront cachea contenido.
Free tier: 50GB/mes + 2M requests gratis por 12 meses.
Optimización de requests: Menos carga en el ALB y EC2.
Operacional
Sin mantenimiento de IPs: AWS actualiza el Prefix List automáticamente.
Auditable: Todos los cambios en CloudTrail.
Compliance: Cumple con frameworks de seguridad (CIS, NIST).
Consideraciones adicionales
1. Custom headers para mayor seguridad
Puedes agregar un header personalizado en CloudFront que el ALB valide:
{
"CustomHeaders": {
"Quantity": 1,
"Items": [{
"HeaderName": "X-Custom-Secret",
"HeaderValue": "tu-secreto-aleatorio"
}]
}
}
Luego configura el ALB para rechazar requests sin este header.
2. Monitoreo y alertas
Configura CloudWatch Alarms para detectar:
Intentos de acceso directo al ALB (aunque serán bloqueados).
Cambios en el Security Group.
Distribución de CloudFront deshabilitada.
3. Múltiples orígenes
Si tienes múltiples ALBs o orígenes, todos deben usar el mismo Prefix List de CloudFront.
4. IPv6
El Managed Prefix List de CloudFront incluye tanto IPv4 como IPv6. Asegúrate de que tu VPC y ALB soporten IPv6 si lo necesitas.
Conclusión
Implementar el principio de mínimo privilegio en AWS no tiene que ser complicado. Usando AWS Managed Prefix Lists para CloudFront, podemos:
Restringir el acceso al ALB solo a CloudFront
Eliminar la exposición innecesaria a internet
Mantener la configuración actualizada automáticamente
Mejorar seguridad, performance y costos
Esta configuración es especialmente importante para:
APIs públicas.
Aplicaciones web con contenido estático.
Entornos que requieren compliance (PCI-DSS, HIPAA, SOC2).
Arquitecturas multi-región.
Recursos
Mauro Rosales
Cloud Engineer
