Amazon SCS-C02: Seguridad de Borde y Aplicaciones — Guía de estudio
Forma parte de la AWS Security Specialty SCS-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Restricción geográfica y bloqueo por país de CloudFront
CloudFront ofrece dos mecanismos para bloquear el tráfico por país, y elegir entre ellos es importante por el costo y la funcionalidad. La característica integrada de restricción geográfica (también llamada geobloqueo) se configura directamente en la distribución y evalúa las solicitudes en el borde contra una lista de países permitidos (allowlist) o una lista de bloqueo (blocklist) derivada de la IP del espectador. Es gratuita, no requiere evaluación de reglas y devuelve un HTTP 403 antes de que ocurra cualquier solicitud al origen. Para escenarios de cumplimiento normativo simples —“bloquear visitantes del país X”—, esta es la opción más barata y sencilla.
La alternativa es una declaración de coincidencia geográfica (geo match) de WAF, que es más flexible: puedes combinar coincidencias de países con rutas URI, encabezados, límites de tasa, o negarlas (“permitir el país A solo para /admin”). WAF es necesario cuando la lógica es condicional; la restricción geográfica por sí sola no puede expresar “bloquear el país X solo para una ruta específica”. Elige la restricción geográfica nativa cuando el requisito sea un bloqueo de país sin condiciones y quieras evitar el costo por solicitud de WAF.
URL firmadas versus cookies firmadas para contenido privado
CloudFront admite dos formas de servir contenido privado autorizado mientras se mantiene el origen (bucket de S3, ALB u origen de Media) oculto detrás de un control de acceso de origen (OAC) o un encabezado personalizado:
URL firmadas: cada URL lleva una firma y una política. Ideal para la descarga de un único archivo o cuando se necesita un control de acceso por archivo (p. ej., un enlace único para un instalador de software).
Cookies firmadas: el cliente recibe un conjunto de cookies
CloudFront-Policy,CloudFront-SignatureyCloudFront-Key-Pair-Iduna sola vez por parte de tu servicio de autenticación. Todas las solicitudes posteriores a patrones de ruta coincidentes se autorizan automáticamente sin necesidad de reescribir las URL.
Para el streaming de video HLS, donde una sola sesión de reproducción obtiene miles de segmentos .ts referenciados por un manifiesto, las cookies firmadas son drásticamente más simples. Reescribir cada URL de segmento en el manifiesto con una URL firmada distinta es posible, pero añade latencia y complejidad. Establece la cookie después de que el suscriptor se autentique contra tu almacén de usuarios interno, limitándola al patrón de ruta del streaming.
Una política canónica para una cookie firmada con comodín (wildcard) se ve así:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
Combina esto con un control de acceso de origen (OAC) o un encabezado personalizado secreto validado por WAF en el origen para que los usuarios no puedan eludir CloudFront y acceder al origen directamente.
AWS WAF: Reglas administradas, ATP y reglas basadas en la tasa
Adjunta la Web ACL a la distribución de CloudFront en lugar de a un ALB regional cuando la carga de trabajo se encuentra detrás de CloudFront. Adjuntarla en el borde (edge) termina las solicitudes maliciosas en uno de los cientos de POPs (puntos de presencia) —más cerca del atacante— lo que reduce la carga en el origen durante un DDoS y disminuye el egreso desde el origen porque el tráfico bloqueado nunca atraviesa tu VPC. Adjuntar WAF solo al ALB significa que la inundación volumétrica aún alcanza el balanceador de carga regional y consume LCUs, y los ataques interregionales son manejados por una sola región en lugar de la red de borde global.
Grupos de reglas clave para combinar:
Conjuntos de reglas administradas por AWS:
AWSManagedRulesCommonRuleSet(estilo OWASP top-10),AWSManagedRulesKnownBadInputsRuleSetyAWSManagedRulesAmazonIpReputationListbrindan una cobertura amplia con casi sin necesidad de ajustes.Prevención de Robo de Cuentas (ATP):
AWSManagedRulesATPRuleSetinspecciona el endpoint de inicio de sesión que designes, rastrea patrones de credential stuffing, comprueba las credenciales enviadas contra una base de datos de credenciales comprometidas y bloquea bots que reutilizan contraseñas filtradas. Configúralo con la ruta de inicio de sesión exacta y los nombres de los campos del cuerpo JSON para el nombre de usuario y la contraseña.Reglas basadas en la tasa (Rate-based): limitan el número de solicitudes desde una única IP en una ventana de 5 minutos (por ejemplo, 2,000 solicitudes). Limítalas por URI o método para que el scraping de
/searchno afecte la navegación anónima de/. Las reglas de tasa mitigan ataques volumétricos de Capa 7 y la enumeración por fuerza bruta.
Un bloque de reglas de WAF recortado:
Rules:
- Name: RateLimitLogin
Priority: 1
Action: { Block: {} }
Statement:
RateBasedStatement:
Limit: 500
AggregateKeyType: IP
ScopeDownStatement:
ByteMatchStatement:
SearchString: /api/login
FieldToMatch: { UriPath: {} }
PositionalConstraint: STARTS_WITH
TextTransformations: [{ Priority: 0, Type: LOWERCASE }]
Certificados de ACM, validación por DNS y CloudFront
Para CloudFront, el certificado debe ser aprovisionado en ACM en us-east-1 (N. Virginia) sin importar dónde resida tu origen; este es un requisito estricto porque CloudFront es un servicio global que lee los certificados desde esa región. Los servicios regionales como ALB leen desde la propia región del ALB.
Usa siempre la validación por DNS con un registro CNAME en Route 53 para cualquier certificado público que quieras autorrenovar. ACM autorrenueva los certificados validados por DNS siempre que el CNAME de validación permanezca publicado; Route 53 hace esto trivial (la consola ofrece “Crear registros en Route 53” durante la solicitud). La validación por correo electrónico, en cambio, envía una confirmación a cinco direcciones del dominio (admin@, administrator@, hostmaster@, postmaster@, webmaster@) más el contacto de WHOIS. Estos buzones de correo frecuentemente son inexistentes o puestos en cuarentena por los filtros de correo corporativos, por lo que las renovaciones fallan 60 días antes de la expiración y causan interrupciones prevenibles. No hay forma de automatizar los clics de validación por correo electrónico.
El patrón de renovación correcto para ALBs multirregionales es: solicitar un certificado de ACM validado por DNS por región, publicar el CNAME de validación en Route 53 una sola vez, adjuntar el certificado al listener del ALB y dejar que ACM gestione la renovación y el redespliegue. La intervención humana termina en la emisión.
DNSSEC y Route 53
Habilita la firma DNSSEC en la zona alojada (hosted zone) de Route 53 para prevenir el DNS spoofing y el envenenamiento de caché (cache poisoning) contra tu dominio. Route 53 gestiona la KSK en KMS (una clave asimétrica ECC en us-east-1); debes publicar el registro DS en el registrador de dominios. Ten en cuenta que la firma DNSSEC protege la resolución de tu zona; no cifra el tráfico DNS (para eso están DoH/DoT) y no afecta al TLS de CloudFront.
Encabezados de respuesta: Políticas vs. Lambda@Edge
CloudFront no inyecta automáticamente encabezados de seguridad como Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options o Content-Security-Policy. Si tu origen no puede ser modificado (un sitio S3 heredado, un origen de terceros), tienes dos opciones:
Política de encabezados de respuesta: una característica nativa y declarativa de CloudFront. Asocia una política administrada o personalizada a un comportamiento de caché para agregar encabezados HSTS, CORS, de seguridad y personalizados. Esta debería ser la opción por defecto: sin código, sin arranques en frío, sin costo por invocación.
Lambda@Edge (respuesta al visor o respuesta al origen): úsalo cuando necesites lógica dinámica, como variar los nonces de CSP por solicitud o reescribir encabezados basándose en los atributos de la solicitud. Cambia la simplicidad por la flexibilidad y añade un costo por solicitud.
La política de encabezados de respuesta administrada SecurityHeadersPolicy cubre la línea base común en una sola asociación.
Errores comunes explicados
Solicitar certificados públicos de ACM con validación por correo electrónico es frágil precisamente porque la renovación depende de que los humanos lean el correo enviado a direcciones genéricas que la mayoría de las organizaciones no monitorean o que enrutan a spam. La validación por DNS con Route 53 elimina por completo la intervención humana.
Asociar WAF solo al ALB parece equivalente en teoría, pero fuerza el tráfico de ataque a entrar en tu Región y consume la capacidad del ALB. El WAF asociado en el borde en CloudFront bloquea en cientos de puntos de presencia (POP), por lo que una inundación distribuida se absorbe globalmente y el egreso del origen se mantiene bajo, lo cual es crítico durante un DDoS.
Asumir que CloudFront agrega automáticamente encabezados de seguridad conduce a fallos en las pruebas de penetración. La distribución actúa como proxy para cualquier encabezado que envíe el origen; debes asociar explícitamente una política de encabezados de respuesta o una función de Lambda@Edge para inyectar X-Frame-Options: DENY, HSTS y CSP.
Problema práctico: Escenario de caso de uso
Escenario: Meridian Financial opera un portal de clientes distribuido globalmente y un portal de informes interno en AWS. El tráfico público se enruta a través de Amazon CloudFront hacia Application Load Balancers para las API dinámicas y hacia orígenes S3 para los informes privados; el DNS está en Route 53 y los certificados TLS son emitidos por AWS Certificate Manager (ACM).
Desafío: Los atacantes están realizando scraping y credential stuffing en las cuentas desde varios países, evitando CloudFront al acceder directamente a los endpoints del origen para descargar informes privados, y causando sobrecarga del origen y exposición de datos.
Enfoque recomendado:
- Configurar CloudFront como el único punto de entrada público y aplicar la restricción geográfica (Geo Restriction) de CloudFront para bloquear los países infractores; habilitar el Control de Acceso al Origen (OAC) y bloquear las políticas de los orígenes S3/ALB para que solo CloudFront pueda obtener contenido del origen.
- Servir informes privados por usuario con URL firmadas de CloudFront (TTL corto) en lugar de cookies firmadas, para que cada descarga esté autorizada y sea auditable individualmente.
- Asociar AWS WAF a la distribución de CloudFront usando las Reglas Administradas de AWS (AWS Managed Rules), habilitar AWS WAF Bot Control (protección avanzada contra amenazas) y crear reglas basadas en la tasa además de desafíos CAPTCHA para mitigar el scraping y el credential stuffing.
- Aprovisionar certificados TLS en ACM (en us-east-1 para distribuciones de CloudFront) usando la validación por DNS a través de Route 53, y publicar registros Alias de Route 53 hacia la distribución de CloudFront.
- Habilitar DNSSEC en la zona alojada de Route 53, habilitar los registros de acceso de CloudFront y WAF en S3, y crear alarmas de CloudWatch y opcionalmente AWS Shield Advanced para visibilidad y alertas de DDoS.
Justificación: Forzar todo el tráfico a través de CloudFront con OAC y WAF impone un acceso al origen con el mínimo privilegio, la restricción geográfica y las protecciones basadas en la tasa/WAF detienen el tráfico abusivo, las URL firmadas proporcionan autorización por objeto, y ACM+validación por DNS con DNSSEC asegura la integridad de TLS y DNS de confianza según las mejores prácticas de AWS.
Reglas de AWS WAF e integración con ALB y CloudFront
AWS WAF es un firewall de Capa 7 que evalúa las solicitudes HTTP(S) contra una Web ACL compuesta por reglas ordenadas. Cada regla inspecciona atributos de la solicitud (URI, encabezados, cuerpo, cadena de consulta, IP de origen) y devuelve una acción de terminación (Permitir, Bloquear, Desafiar, CAPTCHA) o una acción de no terminación (Contar). Las Web ACLs se asocian a distribuciones de CloudFront, Application Load Balancers, API Gateway, AppSync, grupos de usuarios de Cognito y servicios de App Runner. Cuando se asocia a CloudFront, la ACL se ejecuta en el borde y debe crearse en el ámbito us-east-1 (Global); para ALB, debe estar en la misma Región que el balanceador de carga.
Las reglas basadas en la tasa rastrean el número de solicitudes que llegan desde una única IP (o un encabezado de IP reenviada, o una clave agregada como una combinación de URI + IP) en una ventana móvil de cinco minutos. Cuando el recuento excede el umbral configurado, la acción de la regla se dispara hasta que la tasa vuelve a caer por debajo del límite. Debido a que AWS WAF actualiza continuamente la lista de infractores en segundos, las reglas basadas en la tasa son la respuesta canónica para el abuso de alto volumen desde un conjunto pequeño y rotativo de IPs; no tienes que mantener manualmente un conjunto de IP, y la sobrecarga operativa es esencialmente cero después de que se despliega la regla inicial.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
Los conjuntos de IP (IP sets) son listas reutilizables de rangos CIDR a las que se hace referencia en las reglas con una IPSetReferenceStatement. Son el primitivo adecuado cuando tienes una lista determinista de bloqueo/permisión; por ejemplo, endpoints de administración restringidos geográficamente o rangos maliciosos conocidos de fuentes de inteligencia de amenazas. Las reglas personalizadas combinan múltiples declaraciones con operadores lógicos AndStatement, OrStatement y NotStatement, permitiéndote expresar condiciones como “bloquear solicitudes a /login de países que no sean EE. UU. que además carezcan de un encabezado específico”.
CloudFront como capa de mitigación de DDoS y protección del origen
CloudFront absorbe los ataques volumétricos y de agotamiento de estado en el borde de AWS, mucho antes de que el tráfico llegue a tu flota de ALB o EC2. Cada ubicación de borde ejecuta AWS Shield Standard automáticamente, proporcionando mitigación de ataques de inundación SYN (SYN flood) y de reflexión sin costo alguno. Poner CloudFront delante de un ALB reduce la superficie de ataque a la red de borde y habilita WAF a nivel de borde, restricción geográfica y terminación de TLS.
La mitigación solo es efectiva si los atacantes no pueden eludir CloudFront accediendo directamente al nombre DNS del ALB. Dos mecanismos refuerzan esta ruta. Primero, configura CloudFront para que inyecte un encabezado de origen personalizado y secreto (por ejemplo, X-Origin-Verify: <valor-aleatorio>) y configura una regla en el listener del ALB que devuelva un 403 para cualquier solicitud que no contenga ese valor exacto de encabezado. Rota el secreto periódicamente a través de AWS Secrets Manager. Segundo, restringe el grupo de seguridad del ALB a la lista de prefijos gestionada por AWS com.amazonaws.global.cloudfront.origin-facing, que contiene los rangos de IP de borde de CloudFront.
ALBListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Properties:
Actions:
- Type: fixed-response
FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
Conditions:
- Field: http-header
HttpHeaderConfig:
HttpHeaderName: X-Origin-Verify
Values: ["!Ref OriginSecret"]
- Field: http-header
HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
Priority: 1
Simplemente asociar una ACL de WAF al ALB sin forzar el tráfico a través de CloudFront deja el endpoint del ALB públicamente resoluble. Los atacantes que descubren el nombre DNS (a través de registros de transparencia de certificados, DNS histórico o enumeración de subdominios) pueden atacarlo directamente, eludiendo todas las protecciones de borde. Este es el error de arquitectura más común en los diseños de «CloudFront + ALB».
Métricas, alarmas y notificaciones de Shield Advanced
Shield Advanced añade detección mejorada, acceso 24/7 al Shield Response Team, protección de costos para el escalado durante ataques y visibilidad de ataques a la capa de aplicación. Sin embargo, no envía automáticamente correos electrónicos o SMS cuando ocurre un ataque. Las notificaciones deben configurarse explícitamente a través de CloudWatch.
Shield Advanced publica la métrica DDoSDetected (con valor 1 mientras un ataque está en curso) y las métricas DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond y DDoSAttackRequestsPerSecond por cada recurso protegido en el namespace AWS/DDoSProtection. Crea una alarma de CloudWatch sobre DDoSDetected >= 1 con un tema de SNS como acción de la alarma; SNS luego distribuye la notificación a correo electrónico, SMS, chat o una función Lambda de respuesta.
aws cloudwatch put-metric-alarm \
--alarm-name ShieldDDoSDetected \
--namespace AWS/DDoSProtection \
--metric-name DDoSDetected \
--statistic Maximum --period 60 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts
Asumir que Shield Advanced «simplemente te enviará un correo» es un error frecuente; sin la alarma de CloudWatch más la suscripción de SNS, la única señal es la consola de Shield y el evento en el AWS Health Dashboard.
AWS Network Firewall con bloqueo automatizado mediante Lambda
Network Firewall es un firewall con estado (stateful), de capas 3 a 7, que se asocia a una VPC e inspecciona el tráfico que atraviesa las tablas de enrutamiento de las subredes. Su política consiste en grupos de reglas sin estado (stateless) y con estado (stateful); los grupos de reglas con estado utilizan una sintaxis compatible con Suricata. Debido a que los grupos de reglas se gestionan mediante API, son objetivos ideales para la automatización basada en eventos.
Un patrón común responde a los hallazgos de GuardDuty (por ejemplo, UnauthorizedAccess:EC2/RDPBruteForce o Backdoor:EC2/C&CActivity). Security Hub agrega el hallazgo, EventBridge lo compara con un patrón de evento e invoca una función Lambda, y la función Lambda llama a UpdateRuleGroup para insertar una regla de denegación (drop) dirigida a la IP infractora o a la ENI de la instancia comprometida.
def handler(event, _):
ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
nfw.update_rule_group(
RuleGroupArn=RG_ARN,
UpdateToken=rg["UpdateToken"],
RulesSource={"RulesString": rules})
Network Firewall es la opción correcta cuando necesitas bloquear tráfico bidireccional hacia/desde una instancia EC2 o un CIDR en el borde de la VPC. WAF solo inspecciona solicitudes HTTP destinadas a endpoints de capa 7 compatibles, por lo que no puede detener el tráfico C2 saliente ni protocolos que no sean HTTP.
Registro, monitoreo y despliegue seguro con Count
Habilite el registro de WAF en cada Web ACL y transmítalo a CloudWatch Logs, S3 o Kinesis Data Firehose. Los registros incluyen la regla coincidente, la acción, las cabeceras de la solicitud y (con reglas de redacción) los cuerpos saneados. Las solicitudes muestreadas en la consola ofrecen una vista rápida, pero solo conservan las últimas 3 horas y 100 muestras por regla; los registros completos son necesarios para auditorías y análisis forenses.
La acción Count es esencial para un despliegue seguro de reglas. Despliegue nuevos grupos de reglas administradas (por ejemplo, AWSManagedRulesCommonRuleSet o el grupo Bot Control) con las acciones de regla anuladas a Count primero. Vigile la métrica CountedRequests de CloudWatch y las entradas de registro en busca de falsos positivos: tráfico legítimo que habría sido bloqueado. Solo después de ajustar las exclusiones, cambie las acciones a Block. Desplegar reglas administradas directamente en modo Block sin una fase de Count suele causar interrupciones cuando una regla como SizeRestrictions_BODY bloquea un punto de carga de archivos grandes legítimo, o cuando CrossSiteScripting_BODY se activa en la carga útil de un editor de texto enriquecido. La solución no es deshabilitar todo el grupo, sino agregar una declaración de reducción de alcance (scope-down) o una anulación de la acción de regla para la regla específica que falla.
Combine las métricas de WAF (BlockedRequests, AllowedRequests, CountedRequests) con alarmas de CloudWatch para que un pico repentino de bloqueos —o una caída abrupta del tráfico permitido— alerte al ingeniero de guardia, cerrando el ciclo entre la protección en el borde y la conciencia operativa.
Problema práctico: Escenario de caso de uso
Escenario: Meridian Financial opera una aplicación web de cara al cliente en una VPC multi-AZ utilizando Application Load Balancers (ALBs) frente a servicios de ECS, y distribuye contenido estático y dinámico a través de CloudFront. El equipo usa AWS WAF, pero ha tenido una automatización limitada para las amenazas a nivel de red y un registro inconsistente entre los servicios.
Desafío: Un pico reciente de tráfico volumétrico y de capa de aplicación apuntó a los puntos de inicio de sesión y causó el agotamiento de la CPU del ALB mientras buscaba ataques de credential stuffing; el equipo de seguridad necesita una mitigación rápida de DDoS, protección de origen consistente, bloqueo automatizado de IPs maliciosas y despliegues seguros de reglas más estrictas.
Enfoque recomendado:
- Habilitar CloudFront delante del ALB para la mitigación global en el borde, configurar el ALB para que acepte tráfico solo desde CloudFront validando una cabecera de origen personalizada y restringiendo el acceso de entrada con una lista de prefijos administrada por CloudFront o rangos de IP conocidos.
- Desplegar AWS WAFv2 con conjuntos de reglas administradas de AWS más reglas personalizadas basadas en la tasa y de detección de bots; asociar el WAF tanto a la distribución de CloudFront como al ALB. Inicialmente, establecer las nuevas reglas personalizadas en modo COUNT para recopilar telemetría.
- Inscribir la cuenta en AWS Shield Advanced y asociar la distribución de CloudFront y el ALB; crear alarmas de métricas de CloudWatch utilizando métricas de Shield/DDoS y reenviar las alarmas a un tema de SNS para notificaciones al personal de guardia y activadores de runbooks.
- Centralizar los registros: transmitir los registros de CloudFront, ALB, WAF y AWS Network Firewall a Kinesis Data Firehose → S3 y habilitar métricas/paneles de control de CloudWatch para monitorear los recuentos de coincidencias de reglas desde el modo COUNT.
- Desplegar AWS Network Firewall en la VPC con grupos de reglas con estado (stateful) y habilitar su registro; crear filtros de métricas de CloudWatch para patrones sospechosos y una función Lambda que se active por alarmas para actualizar automáticamente el grupo de reglas de Network Firewall y agregar las IPs infractoras a una lista de denegación.
- Después de observar el tráfico en modo COUNT y los paneles de control durante una ventana de observación acordada, cambiar las reglas de WAF de alta confianza a modo BLOCK y mantener las actualizaciones automatizadas de Network Firewall con reversiones seguras y versionado de los grupos de reglas.
Justificación: Usar CloudFront como capa de borde con WAF y Shield Advanced proporciona protección DDoS por capas, mientras que el registro centralizado, la validación de reglas en modo COUNT y las actualizaciones automatizadas de Network Firewall impulsadas por Lambda ofrecen una defensa de red segura, observable y automatizada, consistente con las mejores prácticas de AWS.
← Seguridad de Redes y VPC · Todos los dominios · Gobernanza →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →