Amazon ANS-C01: Seguridad de Red y Cumplimiento — Guía de estudio

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Forma parte de la AWS Advanced Networking Specialty ANS-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Concepto principal

La seguridad de red en AWS se implementa en capas: controles perimetrales, controles a nivel de VPC, controles a nivel de host y de aplicación, y monitorización/inspección. En el límite de la VPC, se utilizan grupos de seguridad (firewalls virtuales con estado, centrados en el host y aplicados a las ENI) y ACL de red (sin estado, filtrado a nivel de subred evaluado por número de regla) para aplicar controles de acceso de grano grueso. Los grupos de seguridad rastrean el estado de la conexión, por lo que un flujo de respuesta establecido se permite automáticamente, lo que los hace ideales para permitir conexiones iniciadas por el cliente a pods o instancias. Las NACL requieren entradas allow explícitas en ambas direcciones o reglas complementarias para el tráfico de retorno; se evalúan en orden ascendente de número de regla y, por lo tanto, son apropiadas para un endurecimiento general a nivel de subred, como eliminar rangos CIDR completos o aplicar mecanismos de escape efímeros para listas de bloqueo de emergencia.

La inspección y la aplicación centralizada de políticas son proporcionadas por servicios gestionados y autogestionados. AWS Network Firewall puede implementar protecciones con estado tipo Suricata, filtrado de listas de dominios y firmas de estilo de prevención de intrusiones en el perímetro de la VPC con políticas de firewall y grupos de reglas explícitos. Web Application Firewall (AWS WAF) se centra en la aplicación para la protección de la capa HTTP(S) y se integra con Application Load Balancer, Amazon CloudFront y API Gateway para aplicar protecciones de OWASP, reglas basadas en la tasa de peticiones y comprobaciones de cabeceras personalizadas. Las protecciones contra DDoS son proporcionadas por AWS Shield (Standard es automático y gratuito; Shield Advanced proporciona ingeniería de tráfico, protección de costos e integración con WAF para la mitigación en la capa de aplicación). Los servicios de detección como Amazon GuardDuty analizan VPC Flow Logs, logs de DNS y CloudTrail para detectar actividades de reconocimiento, escaneos de puertos y comportamiento de instancias comprometidas.

La visibilidad y la captura de paquetes completan el modelo. Los VPC Flow Logs registran metadatos de flujo por ENI y pueden ser entregados a CloudWatch Logs, Amazon S3 o Kinesis Data Firehose para su análisis con Athena. Para la captura completa de paquetes o una inspección más profunda, Traffic Mirroring permite replicar el tráfico de una ENI a un dispositivo de IDS/captura de paquetes (un sensor EC2 con una ENI replicada o un destino de Network Load Balancer) donde se ejecutan herramientas como Suricata o Zeek. Juntos, estos controles permiten una postura de defensa en profundidad donde la prevención, la detección y el análisis forense están presentes.

Servicios clave y configuración

Varios servicios de AWS son centrales para la seguridad de red y cada uno tiene patrones de configuración y API específicos que se deben conocer:

• Grupos de seguridad (Security Groups)
• ACL de red (NACL)
• AWS Network Firewall
• AWS WAF
• AWS Shield (Standard y Advanced)
• Amazon GuardDuty
• VPC Flow Logs
• Traffic Mirroring

Los grupos de seguridad se configuran por ENI a través de la API de EC2 o la Consola; para añadir una regla de entrada, utilice

undefined

. Recuerde usar los CIDR de mínimo privilegio y asociar grupos de seguridad separados para los balanceadores de carga y los pods de backend para evitar reglas demasiado permisivas. Cree las NACL mediante

undefined

y añada entradas numeradas con

undefined

especificando rule-number, rule-action, protocol, port-range y el indicador egress.

AWS Network Firewall utiliza grupos de reglas y políticas de firewall vinculados a un recurso de firewall creado en una subred de la VPC. Use

undefined

para definir reglas sin estado o con estado,

undefined

para componerlas y

undefined

para desplegarlo. Elija grupos de reglas con estado para la inspección consciente del protocolo y reglas de firma compatibles con Suricata; use reglas sin estado para un filtrado de primer paso y de muy alto rendimiento.

AWS WAF asocia una Web ACL a un ALB y puede aplicar coincidencias de conjuntos de IP, coincidencias de cadenas en las cabeceras o reglas basadas en la tasa de peticiones. Use

undefined

y especifique reglas que comprueben las cabeceras (por ejemplo, bloquear peticiones que no contengan una cabecera personalizada que usted inyecta en su punto de entrada de confianza). AWS Shield Advanced se habilita por cuenta y proporciona acceso al equipo de respuesta a DDoS y protecciones adicionales para los recursos registrados en Shield Advanced.

Habilite GuardDuty mediante

undefined

e integre los hallazgos con CloudWatch Events o EventBridge para la automatización. Para la telemetría, cree VPC Flow Logs mediante

undefined

. Para la captura de paquetes, use

undefined

,

undefined

y

undefined

para dirigir el tráfico replicado a la ENI de un dispositivo o a un NLB.

Patrones de diseño y contrapartidas

El cifrado de extremo a extremo con TLS mutuo, donde el balanceador de carga no debe terminar la conexión TLS, requiere un patrón de paso directo (pass-through) de capa 4. Utilice un Network Load Balancer (NLB) delante de los pods de backend para que la sesión TLS se negocie directamente con los puntos de conexión del servicio. En Kubernetes sobre EKS, despliegue un Service de tipo LoadBalancer respaldado por un NLB y registre los pods como destinos por IP; el AWS Load Balancer Controller o las anotaciones de Service heredadas aseguran que el tipo de destino sea IP y que el protocolo del grupo de destino sea TCP. Para la alta concurrencia característica de gRPC y de muchas conexiones HTTP/2 de larga duración, el NLB preserva las IP de origen e impone una sobrecarga por conexión menor que los proxies de L7. Si se requiere la terminación de TLS en el ALB (por ejemplo, para el enrutamiento basado en URL), debe terminar la conexión TLS en el ALB utilizando un certificado de ACM y luego reenviar el tráfico a los backends; preserve la IP del cliente confiando en X-Forwarded-For (ALB) o utilizando un NLB compatible con Proxy Protocol v2 para los backends que necesiten la IP de origen original en L4.

Para arquitecturas escalables de múltiples cuentas y múltiples VPC donde se requieren servicios centrales, PrivateLink (AWS VPC Endpoint Services) es la opción más segura y escalable. Exponga los servicios centrales desde la VPC de servicios compartidos como un servicio de punto de conexión (endpoint service) de AWS PrivateLink. Cada cuenta consumidora crea un punto de conexión de VPC de interfaz (interface VPC endpoint) hacia ese servicio; el propietario del servicio puede requerir la aceptación del punto de conexión y aplicar controles basados en grupos de seguridad en las ENI del punto de conexión. Este modelo mantiene el tráfico en la red de AWS, evita los límites de escala del peering y proporciona seguridad granular por consumidor. Se puede utilizar Transit Gateway con segmentación y Network Firewall para el tránsito a nivel de red y la inspección central, pero es más apropiado cuando se requiere una conectividad totalmente enrutada con políticas de enrutamiento complejas en lugar de un aislamiento por servicio.

Al diagnosticar el uso de ancho de banda a través de múltiples VIF en Direct Connect, priorice primero los metadatos: habilite y consulte los VPC Flow Logs agregados en S3 o CloudWatch y analícelos a través de Athena para mapear los flujos IP de alto volumen a VPC y subredes específicas. Complemente los flow logs con las métricas de CloudWatch para las interfaces virtuales de Direct Connect, y si necesita inspección a nivel de carga útil (payload) o protocolos heterogéneos, despliegue Traffic Mirroring para capturar paquetes hacia un IDS basado en EC2. Traffic Mirroring es pesado e incurre en costos; úselo solo para sesiones/ventanas donde los flow logs y los hallazgos de GuardDuty sean insuficientes.

Errores comunes y criterios de decisión

Un error común es depender únicamente de los grupos de seguridad para la aplicación de un perímetro amplio y no usar NACL o Network Firewall cuando se requiere una inspección a nivel de subred o con estado. Los grupos de seguridad son por ENI y fáciles de gestionar, pero no escalan bien como un plano de control centralizado para muchas VPC en diferentes cuentas; use AWS Firewall Manager para centralizar las reglas de WAF y Network Firewall entre cuentas. Otro error es terminar TLS en el balanceador de carga sin tener en cuenta la preservación de la IP del cliente; ALB inserta encabezados X-Forwarded-For, pero los registros de la aplicación deben leer explícitamente ese encabezado y se debe establecer una confianza (por ejemplo, que solo el ALB deba enviarlo). Para garantizar estrictamente que solo Global Accelerator pueda alcanzar un ALB, evite depender únicamente del DNS; en su lugar, restrinja los listeners del ALB mediante grupos de seguridad a los rangos de IP publicados del acelerador (automatice las actualizaciones con el archivo ip-ranges.json o las listas de prefijos administradas) o use un ALB solo interno cuando sea posible y colóquelo detrás del endpoint del acelerador.

Decida entre PrivateLink y Transit Gateway sopesando la granularidad del servicio frente al enrutamiento de malla completa. PrivateLink proporciona control de acceso por servicio con filtrado a nivel de grupo de seguridad y escala sin hacer explotar las tablas de enrutamiento; Transit Gateway es necesario cuando necesita conectividad basada en rutas entre muchas VPC y redes on-premises, y cuando requiere inspección centralizada de paquetes con AWS Network Firewall. Para un alto rendimiento, prefiera reglas sin estado de Network Firewall en el perímetro combinadas con grupos con estado específicos para flujos críticos; el procesamiento sin estado escala, pero pierde el conocimiento del protocolo.

Problema práctico: Escenario de caso de uso

Empresa: Meridian Payments — desafío: habilitar una API de pagos basada en gRPC en EKS que requiere TLS mutuo de extremo a extremo (sin terminación de TLS en la ruta), soportar miles de conexiones concurrentes de larga duración, autoescalado de pods e identificación de las IP de cliente de origen para el registro y la detección de fraude.

1. Enfoque: Desplegar un Amazon Network Load Balancer delante del Service de EKS configurado con tipo de destino IP para que las ENI de los pods se registren directamente en los grupos de destino del NLB. Usar el AWS Load Balancer Controller para crear un Service respaldado por un NLB con anotaciones para asegurar que el protocolo del grupo de destino sea TCP en el puerto 443 y que las comprobaciones de estado usen TCP. Terminar mTLS en los pods de backend; configurar Istio o una biblioteca TLS en un sidecar si necesita una rotación estandarizada de certificados, usando Kubernetes Secrets poblados desde AWS Certificate Manager Private Certificate Authority o AWS Secrets Manager. Preservar las IP de los clientes porque el NLB preserva la IP de origen; asegurar que las reglas de networkPolicy y de los grupos de seguridad del pod de backend permitan los rangos de origen del NLB/clientes. Usar HPA y Cluster Autoscaler para escalar los pods; asegurar que el retraso de anulación de registro del grupo de destino esté ajustado para permitir un drenaje de conexiones ordenado.

2. Enfoque de observabilidad y forense: Habilitar VPC Flow Logs para la VPC de EKS hacia CloudWatch Logs y agregarlos en S3 a través de Kinesis Firehose para la retención y para consultas con Athena que mapeen los flujos de gran ancho de banda. Habilitar GuardDuty para la detección de anomalías en los flujos de la VPC y en el DNS. Si se requiere una inspección de paquetes más profunda durante las ventanas de sospecha de fraude, crear sesiones de Traffic Mirror en las ENI problemáticas hacia un sensor en EC2 que ejecute Suricata; gestionar los filtros de duplicación para capturar solo el tráfico relevante y limitar el costo.

Justificación de AWS: NLB proporciona paso directo de capa 4 (L4), por lo que TLS y mTLS se negocian de extremo a extremo y el backend ve la IP real del cliente, lo que satisface el requisito de que el tráfico no sea descifrado por proxies intermedios y que el análisis de registros/fraude vea la fuente original. El registro de pods por IP y el uso de AWS Load Balancer Controller se integran con el autoescalado de EKS. VPC Flow Logs, GuardDuty y Traffic Mirroring proporcionan una visibilidad graduada, desde metadatos hasta la captura completa de paquetes, para un cumplimiento y una respuesta a incidentes escalables y rentables.

← Balanceo de Carga y Gestión de Tráfico · Todos los dominios · Entrega de Contenido y Redes de Borde →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →