Seguridad en el Edge con WAF, Shield, CloudFront y Defensa contra DDoS en AWS
_Category: Network Security_
Antes de que el tráfico de internet llegue a tus servidores, atraviesa decenas de Edge Locations y balanceadores de carga. El principio fundamental de la seguridad dice: "bloquea los ataques lo más lejos posible del núcleo". Es mucho más eficiente detener a un intruso en la puerta de entrada que perseguirlo dentro del edificio. AWS WAF, Shield, CloudFront y AWS Firewall Manager son los cuatro pilares que llevan ese principio a la práctica en la capa perimetral.
---
El principio del Edge: interceptar la amenaza lo más lejos posible
Cuando un ataque llega hasta dentro de la VPC, las instancias EC2 comienzan a consumir CPU procesando paquetes de DDoS, y las bases de datos quedan expuestas a inyecciones SQL. La línea de defensa ideal es la capa Global Edge donde operan CloudFront y AWS WAF.
La arquitectura de seguridad perimetral de AWS funciona por capas. En el extremo más externo, Shield absorbe el tráfico malicioso de Layer 3 y Layer 4. CloudFront recibe las peticiones en cientos de Edge Locations distribuidas por todo el mundo. A continuación, AWS WAF analiza cada solicitud HTTP/HTTPS y bloquea los patrones sospechosos. Solo las peticiones que superan esa criba llegan al Application Load Balancer o a las instancias de cómputo.
Conectar WAF directamente a CloudFront significa que las reglas de filtrado se ejecutan en el edge global. Conectarlo a un Application Load Balancer lo limita al ámbito regional. Desde la perspectiva de la defensa contra DDoS, la combinación CloudFront + WAF filtra el tráfico mucho antes de que alcance la infraestructura central.
---
Anatomía de AWS WAF: Web ACL, Rule, Rule Group y Managed Rules
AWS WAF es como el escáner de seguridad a la entrada de un edificio corporativo: toda solicitud HTTP debe pasar por él, y las reglas configuradas determinan si puede continuar o no.
El Web ACL es el contenedor principal de WAF. Puede asociarse a una distribución de CloudFront, a un Application Load Balancer, a API Gateway o a AWS AppSync. Dentro del Web ACL coexisten múltiples Rules, cada una con una prioridad numérica: a menor número, antes se evalúa la regla.
El Rule Group es un contenedor reutilizable que agrupa varias Rules relacionadas. Los Managed Rules son Rule Groups elaborados y mantenidos de forma continua por AWS y sus socios de seguridad, listos para activar sin necesidad de escribir lógica desde cero.
| Categoría | Descripción | Rule Group representativo | |-----------|-------------|---------------------------| | Core Rule Set (CRS) | Protección general basada en OWASP Top 10 | AWSManagedRulesCommonRuleSet | | Known Bad Inputs | Bloquea patrones de explotación de vulnerabilidades conocidas | AWSManagedRulesKnownBadInputsRuleSet | | SQL Database | Detiene inyecciones SQL | AWSManagedRulesSQLiRuleSet | | Amazon IP Reputation | Bloquea IPs maliciosas identificadas por AWS | AWSManagedRulesAmazonIpReputationList | | Bot Control | Detecta y gestiona tráfico de bots | AWSManagedRulesBotControlRuleSet |
Los IP Sets permiten almacenar hasta 10.000 direcciones IP o rangos CIDR que las Rules pueden referenciar directamente. Los registros de WAF se envían a S3 o a CloudWatch Logs mediante Kinesis Data Firehose, y contienen la IP de origen, la URI, las cabeceras, la regla que coincidió y el resultado (Allow/Block). Las métricas de CloudWatch ofrecen contadores agregados por regla, pero para rastrear cada solicitud individual es imprescindible habilitar el logging completo de WAF.
---
Rate-based Rule, Bot Control y Captcha: defensa contra ataques automatizados
La Rate-based Rule bloquea automáticamente cualquier IP que supere un umbral de solicitudes dentro de una ventana de cinco minutos (mínimo 100 peticiones). Combinada con una condición de URI, permite restringir solo las rutas bajo ataque sin afectar el tráfico legítimo que llega por otras vías. Si hay un DDoS de Layer 7 en curso dirigido a un endpoint concreto, añadir una Rate-based Rule con condición de URI es la respuesta más inmediata. El soporte del DRT de Shield Advanced puede tardar horas en activarse, por lo que WAF es siempre la primera línea de acción.
La Geo Match Rule filtra el tráfico según el país de origen. Conviene distinguirla de la función Geo Restriction nativa de CloudFront: esta última se configura directamente en la distribución de CloudFront sin necesidad de WAF, no genera costos adicionales y devuelve un HTTP 403 cuando bloquea. La Geo Match Rule de WAF, en cambio, permite combinar el criterio geográfico con patrones de URL para un control más granular, aunque implica el costo habitual de WAF.
Bot Control diferencia entre bots benignos (rastreadores legítimos) y bots maliciosos, y aplica la acción correspondiente. La acción Captcha presenta un desafío visual a las solicitudes sospechosas antes de permitir el acceso. Custom Response permite personalizar el código HTTP y el cuerpo de la respuesta que se devuelve al bloquear una petición.
---
Shield Standard vs Shield Advanced: tabla comparativa, DRT y Cost Protection
Shield Advanced es como contar con un equipo de guardias especializados disponibles las veinticuatro horas. No solo tienes el escudo: tienes expertos que acuden de inmediato cuando se produce un ataque.
| Aspecto | Shield Standard | Shield Advanced | |---------|----------------|-----------------| | Precio | Gratuito (activado automáticamente) | 3.000 USD/mes + transferencia de datos | | Capas protegidas | Layer 3/4 | Layer 3/4 + Layer 7 | | Soporte DRT 24/7 | No disponible | Disponible — respuesta en tiempo real | | Cost Protection | No disponible | Sí — reembolso por escala inesperada | | Métricas CloudWatch | Métricas básicas | DDoSDetected y otras métricas detalladas | | Detección basada en salud | No disponible | Basada en Route 53 Health Checks | | Exención de costos WAF | No aplica | WAF incluido con la suscripción |
La métrica DDoSDetected de CloudWatch en Shield Advanced pasa a 1 cuando se detecta un ataque y vuelve a 0 al cesar. Configurando una CloudWatch Alarm sobre esa métrica y vinculándola a un SNS Topic, se obtienen alertas inmediatas por correo, SMS o Lambda en cuanto comienza el ataque. Ese es el patrón estándar de notificación en tiempo real para DDoS con Shield Advanced.
Cost Protection cubre los incrementos anómalos de gasto en EC2 Auto Scaling, transferencia de datos en CloudFront y consultas de Route 53 provocados por un ataque DDoS, reembolsándolos en forma de créditos de AWS. Es una de las ventajas más concretas y diferenciadores de Shield Advanced frente a la versión gratuita.
!Shield Standard vs Shield Advanced
AWS Firewall Manager: despliegue de políticas a escala organizacional
Cuando una empresa opera decenas o cientos de cuentas AWS, gestionar los Web ACL de WAF de forma individual en cada cuenta hace imposible mantener un estándar uniforme. AWS Firewall Manager es como la sede central que distribuye el manual de seguridad a todas las sucursales de forma automática.
Firewall Manager se integra con AWS Organizations para que la cuenta administradora central pueda desplegar políticas de WAF, protección de Shield Advanced y políticas de Security Groups en toda la organización o en unidades organizativas específicas con un único clic. Cuando se crea un nuevo recurso que cumple las condiciones del scope definido, el Web ACL correspondiente se asocia de forma automática sin intervención manual.
El motivo más habitual por el que algunos Application Load Balancers quedan fuera de la política de Firewall Manager es la falta de las etiquetas de scope requeridas. Las políticas de Firewall Manager filtran los recursos de inclusión y exclusión basándose en etiquetas; cualquier recurso que no tenga la etiqueta correcta queda fuera del alcance de la política.
Un comportamiento importante que vale la pena recordar: si se excluye una cuenta del scope de una política de Firewall Manager, el Web ACL que ya estaba asociado a los recursos de esa cuenta no se elimina ni se desvincula automáticamente. Sigue aplicándose, pero los cambios futuros en la política central dejan de propagarse, por lo que la cuenta asume la gestión independiente del recurso. Los prerrequisitos de Firewall Manager son tener AWS Organizations activado y haber designado una cuenta administradora delegada.
---
Seguridad en CloudFront: OAC, Signed URL, Signed Cookie y Field-Level Encryption
OAI y OAC son los mecanismos que fuerzan a que el acceso a S3 pase exclusivamente por CloudFront. OAC es el método moderno que reemplaza a OAI y es la opción recomendada para nuevas configuraciones.
| Aspecto | OAI (legado) | OAC (actual, recomendado) | |---------|-------------|---------------------------| | Tecnología base | Identidad virtual exclusiva de CloudFront | Principal de servicio IAM (cloudfront.amazonaws.com) | | Soporte SSE-KMS | Limitado | Completo | | Firma dinámica SigV4 | No disponible | Disponible | | Recomendación | Evitar en nuevas configuraciones | Recomendado |
La combinación OAC + WAF IP Set es el patrón estándar para bloquear el acceso directo a S3 y al mismo tiempo restringir el acceso por IP a través de CloudFront. Intentar usar aws:SourceIp en la bucket policy de S3 no funciona para filtrar IPs de clientes finales porque CloudFront envía la solicitud con su propia IP, no con la del usuario.
Signed URL controla el acceso a un archivo individual mediante un enlace firmado con tiempo de expiración. Signed Cookie extiende ese control a múltiples archivos o rutas mediante una única cookie, lo cual resulta más adecuado para servicios de streaming donde los suscriptores deben acceder a un catálogo completo de contenido protegido.
Field-Level Encryption cifra campos específicos de un formulario POST directamente en el edge de CloudFront usando una clave pública, antes de reenviar la solicitud al backend. Así, datos sensibles como números de