Amazon SCS-C02: Seguridad de Redes y VPC — 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.
VPC Endpoints y Políticas de Endpoint
Los VPC endpoints mantienen el tráfico hacia los servicios de AWS en la red de AWS, evitando el internet público, los NAT gateways y los internet gateways. Hay dos tipos estructuralmente diferentes, y confundirlos es uno de los errores de diseño más comunes.
Los gateway endpoints existen solo para Amazon S3 y DynamoDB. Son entradas en la tabla de rutas: asocias el endpoint con las tablas de rutas, y el tráfico destinado a la lista de prefijos del servicio (por ejemplo, pl-63a5400a para S3 en us-east-1) se redirige silenciosamente a través del endpoint. No tienen costo y no se puede acceder a ellos desde fuera de la VPC a la que están asociados.
Los interface endpoints (impulsados por AWS PrivateLink) son ENIs con direcciones IP privadas ubicadas en tus subredes. Son necesarios para todos los servicios que no son S3 o DynamoDB: Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR y cientos de otros. Si una instancia EC2 en una subred privada sin NAT gateway necesita ejecutar GetSecretValue desde Secrets Manager, un gateway endpoint no ayudará; debes crear un interface endpoint com.amazonaws.<region>.secretsmanager y habilitar el DNS privado para que el nombre de host estándar del servicio se resuelva a la IP privada del endpoint.
Las políticas de endpoint restringen qué se puede hacer a través del endpoint, independientemente de las políticas de IAM del llamador. Las dos claves de condición más importantes para prevenir la exfiltración de datos son aws:PrincipalOrgID (la identidad que realiza la llamada debe pertenecer a tu Organization) y aws:ResourceOrgID (el bucket de S3, la clave de KMS, etc., al que se accede debe pertenecer a tu Organization). Aplicar ambas cierra la ruta de exfiltración clásica donde una instancia comprometida con permisos legítimos de S3 escribe en un bucket controlado por un atacante fuera de tu organización: las credenciales siguen funcionando contra S3, pero el endpoint se niega a reenviar la solicitud.
{
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-abc123",
"aws:ResourceOrgID": "o-abc123"
}
}
}]
}
La política de endpoint por defecto es totalmente permisiva ("Action":"*" en "Resource":"*"), razón por la cual una subred con solo un gateway endpoint y IAM de mínimo privilegio aún puede ser abusada para la exfiltración a menos que restrinjas la propia política del endpoint.
Conectividad Híbrida: VPN y Direct Connect
Site-to-Site VPN establece dos túneles IPsec entre un virtual private gateway (o Transit Gateway) y un dispositivo customer gateway. Es rápido de aprovisionar, está cifrado por defecto y atraviesa el internet público, por lo que el rendimiento y la latencia dependen de la ruta de tu ISP.
AWS Direct Connect aprovisiona un circuito físico dedicado a través de una ubicación de Direct Connect. Proporciona una latencia baja y predecible y un ancho de banda alto y consistente (1/10/100 Gbps), lo cual es importante para el tráfico de bases de datos on-premises muy comunicativas (“chatty”). Direct Connect no está cifrado en la capa 3 por sí mismo; las tramas viajan por fibra privada. Para cargas de trabajo que requieren tanto baja latencia como IPsec, la respuesta canónica es Direct Connect más una Site-to-Site VPN funcionando sobre una VIF pública (o un Transit Gateway con MACsec en puertos DX más nuevos). Una VPN por sí sola es también el respaldo cifrado recomendado para un enlace principal de Direct Connect, proporcionando resiliencia si el circuito falla.
- Solo Direct Connect: baja latencia, privado, pero no cifrado en la capa IP.
- Solo VPN: cifrado, rápido de implementar, pero con la latencia y el jitter de la ruta de internet.
- Direct Connect + VPN: baja latencia y cifrado IPsec; también es el patrón estándar de alta disponibilidad (HA).
Security Groups, NACLs, DHCP y Comprobaciones de Origen/Destino
Los security groups son “stateful” (con estado): si permites una solicitud de entrada, la respuesta se permite automáticamente de salida. Solo admiten reglas de permiso (“allow”) y se evalúan por cada ENI.
Las Network ACLs son “stateless” (sin estado) y operan en el límite de la subred. Cada flujo requiere dos reglas: una para la dirección inicial y otra para el tráfico de retorno en el rango de puertos efímeros (Linux típicamente 32768–60999, Windows 49152–65535 y NLBs/ELBs usan 1024–65535). Una NACL que permite el tráfico entrante por TCP 443 pero olvida el saliente en el rango TCP 1024–65535 romperá silenciosamente TLS. ICMP no es TCP/UDP: los paquetes de retorno “echo reply” deben permitirse explícitamente, y el Path MTU Discovery depende de ICMP tipo 3 código 4, que es fácil de descartar inadvertidamente. Las reglas de las NACL también se evalúan en orden numérico, la primera coincidencia gana, con una denegación implícita al final.
Los DHCP option sets controlan lo que una VPC entrega a las instancias en el arranque: domain-name-servers, domain-name, servidores NTP, NetBIOS. Reemplazar el AmazonProvidedDNS por defecto con un resolver on-premises personalizado puede ser legítimo, pero tiene consecuencias de seguridad reales. Servicios como GuardDuty derivan hallazgos basados en DNS (por ejemplo, las detecciones de “cryptocurrency” y “C&C domain”) de las consultas que atraviesan el Route 53 Resolver. Una vez que apuntas las instancias a un servidor DNS de terceros, GuardDuty deja de ver las consultas y esos tipos de hallazgos desaparecen, una forma fácil de cegar accidentalmente la detección.
La comprobación de origen/destino (“Source/destination checking”) es un atributo de la ENI que descarta cualquier paquete cuya IP de origen o destino no coincida con la ENI. Ese valor por defecto es correcto para instancias ordinarias, pero rompe cualquier “appliance” cuyo trabajo sea reenviar tráfico: instancias NAT, firewalls virtuales (Palo Alto, Fortinet, Check Point), routers de tránsito, concentradores VPN. Para esas ENIs, deshabilita la comprobación:
aws ec2 modify-instance-attribute \
--instance-id i-0abc123 \
--no-source-dest-check
Peering de VPC, VPC compartidas con RAM y diseño de NAT
El peering de VPC es un enlace de capa 3 uno a uno y no transitivo. Si A se conecta con B y B se conecta con C, A no puede alcanzar C; debes conectar A y C directamente o usar un Transit Gateway. Las tablas de enrutamiento en ambos lados deben contener rutas hacia el CIDR del par, y los grupos de seguridad solo pueden hacer referencia a los ID de los grupos de seguridad del par dentro de una misma región.
Las VPC compartidas a través de AWS Resource Access Manager (RAM) permiten que una cuenta de red sea propietaria de una VPC y comparta subredes individuales con cuentas participantes. Los participantes lanzan recursos en las subredes compartidas, pero no pueden modificar la VPC, las tablas de enrutamiento ni los endpoints; el propietario mantiene el control de la política de conectividad. Esto suele ser más económico y sencillo que hacer peering con muchas VPC.
Para el tráfico de salida a internet desde subredes privadas, despliega un NAT gateway por cada Zona de Disponibilidad y enruta cada subred privada al NAT en su propia AZ. Un único NAT gateway es una dependencia entre Zonas de Disponibilidad y un cuello de botella para la escalabilidad y la disponibilidad. Cuando tu carga de trabajo llama a un tercero que añade tu IP de salida a una lista de permitidos (un procesador de pagos, por ejemplo), la IP elástica del NAT gateway es la que registras. Como las instancias detrás de un Auto Scaling group salen a través de esa EIP fija, la IP de origen no cambia a medida que el grupo escala. Ubicar las instancias EC2 y la base de datos RDS en subredes privadas y terminar solo el tráfico HTTP/HTTPS en el ALB completa este patrón.
Route 53 Resolver: Reenvío y registro de consultas
El Route 53 Resolver (la dirección .2 en cada VPC) es el eje para el DNS híbrido. Los endpoints de resolución de salida (outbound) reenvían nombres de dominio específicos desde AWS a servidores DNS on-premises mediante reglas de reenvío condicional; se usa, por ejemplo, para que corp.example.internal se resuelva contra tu Active Directory. Los endpoints de resolución de entrada (inbound) hacen lo contrario, proporcionando a los hosts on-premises una IP privada en tu VPC que pueden consultar para resolver *.eu-west-1.compute.internal y zonas alojadas privadas (Private Hosted Zones).
El registro de consultas del Resolver (Resolver query logging) escribe cada consulta DNS realizada desde la VPC en CloudWatch Logs, S3 o Kinesis Firehose. Es el registro autoritativo para investigar sospechas de exfiltración o uso indebido y complementa, pero no reemplaza, a GuardDuty. Recuerda que si un conjunto de opciones DHCP redirige las instancias a un resolver que no es de Amazon, tanto el registro de consultas como los hallazgos de DNS de GuardDuty se quedan a ciegas, porque las consultas nunca llegan al Route 53 Resolver.
Problema práctico: Escenario de caso de uso
Escenario: Meridian Financial opera un entorno de AWS multicuenta con una red hub-and-spoke: una VPC de servicios compartidos, compartida mediante RAM, aloja los NAT Gateways centrales, los endpoints de Route 53 Resolver y las conexiones (attachments) del Transit Gateway, mientras que múltiples VPC de aplicaciones están conectadas por peering o al Transit Gateway. Los centros de datos on-premises se conectan a través de Direct Connect con conmutación por error (failover) a VPN, y los equipos dependen de conjuntos de opciones DHCP centralizados y endpoints de resolución compartidos para la resolución de DNS híbrido.
Desafío: Un incidente reciente mostró que se accedía a objetos sensibles de S3 a través de la internet pública porque las VPC spoke enrutaban el tráfico al NAT compartido en lugar de a los VPC endpoints, las consultas de DNS para zonas internas se filtraron a resolvers públicos y una instancia EC2 utilizada como router ad-hoc (con la comprobación de origen/destino deshabilitada) permitió el movimiento lateral.
Enfoque recomendado:
- Desplegar Gateway VPC Endpoints para S3 y DynamoDB y Interface Endpoints (AWS PrivateLink) para Secrets Manager y KMS en la VPC de servicios compartidos, adjuntando políticas de endpoint explícitas que restrinjan el acceso a buckets y principales de servicio específicos.
- Rediseñar la arquitectura de NAT para que las subredes de aplicación usen VPC endpoints para las API de AWS y S3; mantener los NAT Gateways solo para el tráfico de salida a internet genuino, con grupos de seguridad de salida estrictos y Flow Logs hacia CloudWatch/S3.
- Reactivar las comprobaciones de origen/destino (source/dest checks) en todas las instancias EC2, excepto en los dispositivos de enrutamiento documentados; mover el enrutamiento a las conexiones del Transit Gateway o a instancias NAT gestionadas y aplicar el principio de mínimo privilegio en las tablas de enrutamiento.
- Reforzar los Security Groups y las NACL de subred a una postura de denegación por defecto (deny-by-default), y aplicar líneas base centralizadas de IAM y SG a través de SCP de AWS Organizations y reglas de AWS Config.
- Fortalecer el DNS híbrido desplegando endpoints de entrada/salida (inbound/outbound) de Route 53 Resolver, configurar reglas de reenvío condicional y de DNS Firewall, habilitar el registro de consultas del Resolver (Resolver query logging) en CloudWatch Logs y usar conjuntos de opciones DHCP para forzar el uso de resolvers internos en todas las VPC compartidas a través de RAM.
Justificación: Este enfoque elimina el tráfico de salida a internet innecesario mediante el uso de VPC endpoints con políticas de endpoint, centraliza y controla el enrutamiento a través de Transit Gateway/Direct Connect, restaura las protecciones a nivel de instancia y previene la fuga de DNS con endpoints de Resolver y su registro, alineándose con las mejores prácticas de redes y defensa en profundidad de AWS.
Endpoints de VPC y Políticas de Endpoint
Los endpoints de VPC permiten que las cargas de trabajo dentro de una VPC alcancen las API de los servicios de AWS sin atravesar la red pública de internet o un NAT gateway. Existen dos variantes arquitectónicas, y elegir la incorrecta es una fuente común de tráfico mal enrutado.
Endpoints de gateway: Se usan solo para Amazon S3 y DynamoDB. Se implementan como un destino en una tabla de rutas (lista de prefijos
pl-xxxxxxxxque apunta avpce-xxxxxxxx). No se crea ninguna ENI, no se necesitan cambios de DNS y no hay costo por hora.Endpoints de interfaz (PrivateLink): Se usan para KMS, SQS, SNS, Secrets Manager, STS, la API de EC2 y la mayoría de los demás servicios. Provisionan ENIs con IP privadas dentro de las subredes elegidas y se facturan por hora más por GB.
Para un trabajo por lotes (batch) entre cuentas donde las instancias EC2 en la Cuenta B leen de un bucket de S3 en la Cuenta A cifrado con una clave de KMS en la Cuenta A, el diseño correcto es un endpoint de gateway para S3 más un endpoint de interfaz para KMS. El endpoint de gateway mantiene s3:GetObject, s3:PutObject, s3:PutObjectAcl y s3:ListBucket fuera de internet; el endpoint de interfaz hace lo mismo para kms:Decrypt, kms:Encrypt y kms:GenerateDataKey. Debido a que el ARN de la clave de KMS utiliza el nombre de host estándar kms.<region>.amazonaws.com, el endpoint de interfaz debe tener el DNS privado habilitado para que el nombre de host sin modificar del SDK se resuelva a la ENI del endpoint en lugar del servicio público de KMS. Sin el DNS privado (o sin los nombres de host DNS y la resolución de DNS habilitados a nivel de VPC), el cliente seguiría contactando el endpoint público — de ahí que el requisito de “sin cambios en el código” exija implícitamente el DNS privado.
Las políticas de endpoint son una segunda capa de autorización independiente. Existe una política predeterminada permisiva, pero un reforzamiento para un bucket y una clave específicos se ve así:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
"Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
}]
}
La simple creación del endpoint no es suficiente. Dos modos de fallo son recurrentes: (1) el endpoint existe pero la tabla de rutas de la subred privada no tiene una entrada para la lista de prefijos de S3, por lo que el tráfico sigue saliendo a través del NAT gateway; (2) la política del endpoint omite una acción como s3:PutObjectAcl o apunta al ARN de bucket incorrecto, bloqueando silenciosamente llamadas que IAM de otro modo permitiría. Tanto la política del bucket como la política del endpoint deben permitir la solicitud — se intersecan, no se unen.
Grupos de Seguridad, NACL y Contención Rápida
Los grupos de seguridad y las NACL resuelven problemas superpuestos en diferentes capas, y el examen a menudo fuerza una elección entre ellos para la respuesta a incidentes.
Grupos de seguridad: Con estado (stateful), se evalúan a nivel de la ENI. El tráfico de retorno se permite automáticamente. Solo existen reglas de permiso (allow). Ideales para políticas a nivel de host (“la capa web puede alcanzar la capa de aplicación en el puerto 8080”).
Network ACLs (NACL): Sin estado (stateless), se evalúan en el límite de la subred. Existen tanto reglas de permiso (allow) como de denegación (deny), procesadas en orden numérico de la regla. Ideales para bloqueos generales a nivel de subred — especialmente para poner en lista de bloqueo un rango de IP o cerrar un puerto específico en cada instancia de una subred.
Cuando un brote de malware te obliga a bloquear el TCP/2905 saliente hacia un conjunto de IP de comando y control (C2) en muchas instancias, una regla de denegación (deny) en una NACL es el instrumento correcto. Los grupos de seguridad no pueden expresar “deny” y requerirían enumerar y modificar cada SG referenciado por cada ENI afectada. Una sola regla de denegación en una NACL a nivel de subred con un número de regla bajo (p. ej., 90) cubre todas las instancias en esa subred instantáneamente, mientras preserva el tráfico no relacionado evaluado por reglas de permiso posteriores.
Debido a que las NACL son sin estado, recuerda que ambas direcciones necesitan reglas. Bloquear la salida en el puerto 2905 no requiere una regla de entrada, pero si también quieres rechazar las respuestas entrantes, debes agregar una entrada de entrada — y deben existir entradas de permiso de entrada para los puertos efímeros (1024–65535) para permitir el paso del tráfico de retorno legítimo.
NAT Gateways, Enrutamiento e Independencia de AZ
Un NAT gateway es un recurso zonal. El patrón canónico es un NAT gateway por Zona de Disponibilidad (AZ), con la tabla de rutas de cada subred privada apuntando 0.0.0.0/0 al NAT en la misma AZ:
PrivateRouteTable-AZ-a: 0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b: 0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c: 0.0.0.0/0 -> nat-cccc (in subnet public-az-c)
Un solo NAT compartido entre Zonas de Disponibilidad parece más barato, pero introduce dos problemas: cargos por transferencia de datos entre AZ en cada paquete y una dependencia dura de disponibilidad — si esa AZ cae, cada subred privada pierde la salida a internet. El patrón de NAT zonal también evita particularidades de retorno asimétrico cuando se combina con la inspección de Transit Gateway (ver más abajo).
VPC Flow Logs para Investigación
Los Flow Logs capturan metadatos de 5 tuplas (IP de origen/destino, puerto, protocolo, acción ACCEPT/REJECT, bytes, paquetes) a nivel de VPC, subred o ENI. Para buscar instancias que se comunican con hosts de C2 en el puerto TCP/2905, habilita los Flow Logs en la VPC con el tipo de tráfico configurado en REJECT (ya que la NACL ahora está bloqueando el tráfico) y consulta en CloudWatch Logs Insights o Athena:
SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;
La columna srcaddr revela las IP de las instancias infectadas con un esfuerzo mínimo — sin capturas de paquetes, sin agentes en el host. Elegir el tráfico “ALL” funciona, pero produce más datos y costo; elegir solo “ACCEPT” omitiría por completo los intentos bloqueados, que es precisamente lo que necesitas ver.
PrivateLink, Transit Gateway y Network Firewall
PrivateLink extiende el modelo de endpoint de interfaz a sus propios servicios: una VPC proveedora expone un NLB detrás de un servicio de VPC endpoint, y los consumidores crean endpoints de interfaz para alcanzarlo sin necesidad de VPC peering o de compartir rutas. Es unidireccional y oculta por completo el CIDR del proveedor.
Transit Gateway (TGW) es el concentrador para la conectividad de muchos a muchos entre VPC y entornos on-premises. Un patrón común es una VPC de inspección centralizada que ejecuta AWS Network Firewall o appliances de terceros, con tablas de rutas de TGW que dirigen el tráfico de spoke a spoke a través de la VPC de inspección. Este diseño falla con el comportamiento predeterminado de TGW, ya que TGW distribuye los flujos mediante hash a través de las ENI de los adjuntos en diferentes AZ, y la ruta de retorno puede entrar por una AZ distinta a la de la ruta de ida. Los firewalls con estado descartan los paquetes a mitad de flujo para los que nunca vieron el SYN.
Se requieren dos correcciones en conjunto. Primero, habilitar el Modo Appliance en el adjunto de TGW para la VPC de inspección; esto fija cada flujo bidireccional a la misma ENI de la AZ para que la ida y el retorno atraviesen el mismo endpoint de firewall. Segundo, configurar las tablas de rutas de TGW para que los adjuntos de los spokes envíen tráfico al adjunto de la VPC de inspección, y una tabla de rutas post-inspección separada en la VPC de inspección devuelva el tráfico al spoke correcto. Omitir cualquiera de las dos —el modo appliance solo sin las tablas de rutas, o las tablas de rutas solas sin el modo appliance— mantiene los descartes asimétricos.
El propio Network Firewall utiliza reglas compatibles con Suricata y depende del enrutamiento simétrico para mantener el estado del flujo; combinarlo con Flow Logs tanto en la VPC de inspección como en las VPC de los spokes proporciona el rastro forense necesario para demostrar qué spoke inició una sesión y si el firewall la permitió o la descartó.
Problema práctico: Escenario de caso de uso
Escenario: Meridian Financial opera un entorno de AWS multicuenta con VPC de producción en tres Zonas de Disponibilidad en us-east-1, conectadas mediante un AWS Transit Gateway a una VPC de seguridad central. Utilizan NAT Gateways en cada AZ para la salida (egress), S3 Gateway Endpoints e Interface Endpoints (PrivateLink) para SaaS de socios, y un AWS Network Firewall centralizado junto con Security Groups y NACL; los VPC Flow Logs se transmiten a CloudWatch para su monitoreo.
Desafío: Se sospecha que una instancia EC2 de producción ha realizado intentos de movimiento lateral y exfiltración de datos hacia una IP externa y hacia S3, y Meridian necesita una contención rápida en todas las AZ sin interrumpir otras VPC críticas para el negocio.
Enfoque recomendado:
- Poner en cuarentena inmediatamente la instancia comprometida reemplazando sus Security Groups por un SG restrictivo de “cuarentena” que deniegue todo el tráfico entrante y saliente, y etiquetar la instancia para su remediación automatizada a través de Systems Manager; simultáneamente, aplicar reglas de Network ACL a nivel de subred para bloquear la salida hacia rangos de IP externas sospechosas.
- Aislar la VPC en el Transit Gateway eliminando o cambiando el adjunto de la tabla de rutas de TGW para la VPC afectada a una tabla de rutas de TGW de cuarentena (con una ruta blackhole o sin ruta hacia otros adjuntos), deteniendo el movimiento lateral hacia otras VPC.
- Redirigir la salida (egress) restante de la VPC a través del AWS Network Firewall centralizado actualizando las entradas de TGW/tabla de rutas para forzar la inspección y bloquear destinos maliciosos conocidos, preservando la independencia de las AZ al mantener los NAT Gateways por AZ para una salida resiliente e inspeccionada.
- Reforzar los controles del plano de datos aplicando políticas de VPC Endpoint restrictivas en los S3/DynamoDB Gateway Endpoints para denegar Put/Get de principales no aprobados y asegurar que las API internas utilicen Interface Endpoints (PrivateLink) para evitar rutas por internet.
- Utilizar VPC Flow Logs con CloudWatch Logs Insights y AWS CloudTrail para realizar el análisis forense, luego remediar (reinstalar la imagen, rotar claves) y reintroducir la instancia solo después de la validación; hacer cumplir las reglas a través de AWS Firewall Manager/AWS Config.
Justificación: Esta secuencia proporciona una contención rápida y de mínimo privilegio tanto en la capa de host como en la de red, centraliza la inspección con Network Firewall y el enrutamiento de Transit Gateway para minimizar el radio de impacto, preserva la resiliencia de las AZ con NAT por AZ, y utiliza VPC Flow Logs para una investigación auditable, alineándose con las mejores prácticas de defensa en profundidad de AWS.
← Protección de Datos y S3 · Todos los dominios · Seguridad de Borde y Aplicaciones →
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 →