Seguridad en VPC y Aislamiento de Red con Security Group, Network ACL, Network Firewall y PrivateLink para SCS-C03
_Category: Network Security_
Gran parte de los incidentes de seguridad ocurren porque nadie pudo responder a tiempo la pregunta: ¿desde dónde hacia dónde fluyó el tráfico? En AWS, el aislamiento de red no se reduce a unas pocas reglas de firewall; se diseña como una frontera multicapa que va desde la cuenta hasta la ENI, pasando por la VPC y las subnets. En este artículo desglosamos de forma estructurada los temas de seguridad de red en VPC que más peso tienen en el SCS-C03, con hasta 84 preguntas atribuidas a este dominio.
---
La Arquitectura Multicapa de Aislamiento en VPC: Cuenta → VPC → Subnet → ENI
El aislamiento de red en AWS funciona como esas muñecas rusas Matryoshka: capas dentro de capas, cada una con su propia frontera de control.
La capa exterior es la cuenta de AWS. Dos VPC de cuentas distintas permanecen completamente aisladas a menos que se conecten de forma explícita. La siguiente capa es la VPC en sí. Dentro de una misma cuenta, se pueden crear varias VPC para separar entornos —desarrollo, staging, producción— o para aislar cargas de trabajo según sus requisitos. Dentro de cada VPC, las subnets dividen la red en una zona pública y una zona privada. La Public Subnet se conecta directamente a internet a través del Internet Gateway (IGW), mientras que la Private Subnet solo permite tráfico saliente mediante el NAT Gateway. La capa más interna es la ENI (Elastic Network Interface): cada instancia EC2 tiene asociado un Security Group a nivel de ENI, que aplica control de acceso granular por instancia.
Desde la perspectiva del enrutamiento, el Route Table determina hacia dónde fluye el tráfico. La Route Table de una Public Subnet incluye la ruta , mientras que la de una Private Subnet apunta a . Sin la ruta correcta, aunque el Security Group esté abierto, los paquetes no llegan a su destino. Por eso, cuando aparecen preguntas sobre VPC peering, siempre hay que verificar que la Route Table incluya la ruta de peering correspondiente.
En entornos empresariales que requieren control de red centralizado, se utiliza el patrón de Shared VPC mediante AWS RAM. La cuenta central controla el CIDR, el enrutamiento y los Network ACL de las subnets, mientras que cada cuenta de carga de trabajo despliega sus recursos —EC2, RDS, etc.— de forma independiente dentro de esas mismas subnets.
---
Security Group y Network ACL: La Diferencia Decisiva entre Stateful y Stateless
Imagina que el Security Group es el lector de tarjetas de acceso junto al escritorio de cada empleado. Cuando alguien entra, lo registra; cuando sale, recuerda que ya entró y lo deja pasar automáticamente. Eso es stateful: recuerda el estado de la conexión. El Network ACL, en cambio, es el guardia de seguridad en la entrada del edificio: revisa las reglas al entrar y vuelve a revisarlas al salir, sin guardar memoria de lo ocurrido. Eso es stateless: cada decisión se toma desde cero.
| Atributo | Security Group | Network ACL | |----------|---------------|-------------| | Ámbito de aplicación | ENI (nivel de instancia) | Nivel de subnet | | Gestión de estado | Stateful — el tráfico de respuesta se permite automáticamente | Stateless — se necesitan reglas separadas para entrada y salida | | Comportamiento por defecto | Deniega todo (solo opera con permisos explícitos) | VPC predeterminada permite todo; una NACL nueva deniega todo | | Tipo de reglas | Solo reglas de permitir (no existe denegar) | Permite y deniega; se evalúan en orden numérico ascendente | | Referencia de origen | Puede usar otro SG ID como origen (misma región) | Solo acepta IP o bloques CIDR | | Aplicación de cambios | Inmediata | Inmediata |
Un punto crítico en la práctica es que Security Group no admite reglas de denegación explícita. Si necesitas bloquear una IP específica, debes recurrir a una regla DENY en el Network ACL. Recuerda además que el Network ACL evalúa las reglas de menor a mayor número, por lo que la regla DENY debe tener un número inferior a la regla ALLOW para tener efecto.
En el VPC peering entre regiones distintas, no es posible referenciar IDs de Security Group. En el peering dentro de la misma región sí se puede usar el SG ID del VPC remoto como origen, pero en el peering entre regiones es obligatorio especificar un bloque CIDR (por ejemplo, 10.0.0.0/16).
!Security Group vs Network ACL
VPC Flow Logs: Visibilidad Total sobre el Tráfico de Red
VPC Flow Logs registra a nivel de ENI el IP origen, IP destino, puerto, protocolo y el resultado ACCEPT o REJECT de cada flujo, y los envía a CloudWatch Logs o a S3. Cuando el tráfico que debería estar permitido resulta bloqueado, el campo REJECT permite identificar si el origen del problema es el Security Group o el Network ACL.
Sin embargo, Flow Logs opera a nivel de ENI, lo que significa que tiene puntos ciegos dentro del Network Load Balancer. En escenarios de fallo de PrivateLink donde el Interface Endpoint aparece en buen estado pero el tráfico no llega, Flow Logs no revela la causa: si una instancia EC2 en el grupo de destino del NLB está siendo bloqueada por su Security Group o Network ACL, eso queda fuera del alcance de Flow Logs. El NLB en sí no tiene Security Group, pero las instancias EC2 detrás de él deben permitir el tráfico entrante desde las IPs privadas del NLB o desde el CIDR de la VPC. El orden de verificación correcto es: Endpoint Policy del consumidor → Security Group del grupo de destino del NLB del proveedor → Network ACL.
Combinar Flow Logs con Route 53 Resolver Query Logging permite visualizar también los patrones de consultas DNS. Identificar qué instancias envían consultas a dominios externos desconocidos es útil para detectar comunicaciones de tipo C2 (Command and Control).
---
AWS Network Firewall y Firewalls de Terceros con Gateway Load Balancer
Si Security Group y Network ACL son la primera línea de defensa, AWS Network Firewall es la línea avanzada con capacidad de inspección profunda de paquetes (DPI).
Network Firewall opera creando una Firewall Subnet dedicada dentro de la VPC y manipulando las Route Tables para que todo el tráfico pase obligatoriamente por esa subnet. Admite reglas stateless (coincidencia rápida de 5 tuplas) y reglas stateful con inspección a nivel IPS/IDS. Es compatible con reglas en formato Suricata y permite filtrado por URL, bloqueo basado en dominio (por ejemplo, el patrón ) e incluso inspección TLS.
Gateway Load Balancer (GWLB) es el mecanismo para insertar de forma transparente appliances de firewall de terceros —Palo Alto, Fortinet, etc.— en la red de AWS. GWLB utiliza túneles GENEVE para reenviar los paquetes originales al appliance sin modificarlos. Una vez que el appliance completa la inspección, GWLB los devuelve al destino original.
| Atributo | AWS Network Firewall | GWLB + Firewall de Terceros | |----------|---------------------|------------------------------| | Gestión | Servicio totalmente administrado por AWS | El cliente gestiona el appliance directamente | | Personalización | Reglas Suricata, filtrado por dominio | Aprovecha todas las funcionalidades del appliance | | Escalabilidad | Escalado automático horizontal | GWLB distribuye el tráfico entre el pool de appliances | | Escenario ideal | Minimizar sobrecarga operativa, solución nativa AWS | Migrar políticas de firewall on-premise al cloud sin cambios | | Visibilidad | Alertas de Network Firewall → CloudWatch/S3 | Logs nativos del appliance |
En el examen: si el enunciado pide «usar el appliance de seguridad on-premise existente para inspeccionar tráfico en AWS», elige GWLB. Si pide «IPS nativo de AWS con filtrado basado en dominio», elige Network Firewall.
---
VPC Endpoint y PrivateLink: Comunicación sin Pasar por Internet
PrivateLink es como recibir a un visitante externo en una sala de reuniones privada, sin que entre al edificio principal. Permite consumir servicios SaaS o servicios de otras cuentas sin exponer el tráfico a internet.
Existen dos tipos de VPC Endpoint:
| Atributo | Gateway Endpoint | Interface Endpoint (PrivateLink) | |----------|-----------------|----------------------------------| | Servicios soportados | Solo S3 y DynamoDB | La mayoría de servicios AWS y servicios personalizados | | Implementación | Agrega una ruta a la Route Table | Crea una ENI con IP privada dentro del VPC | | Costo | Gratuito | Tarifa por hora + tarifa por procesamiento de datos | | Conexión on-premise | No es posible (solo dentro del VPC) | Posible vía Direct Connect o VPN desde on-premise | | DNS Privado | No aplica | Si se activa, enruta todo el dominio del servicio hacia el VPC Endpoint |
La configuración de Private DNS en Interface Endpoint es una trampa frecuente en el examen. Al activarla, el dominio completo del servicio (por ejemplo, ) se enruta hacia la IP del VPC Endpoint. Si en el mismo VPC también se necesita acceder a una API pública, las solicitudes a esa API pública podrían bloquearse sin que sea evidente. En entornos donde coexisten APIs públicas y privadas, lo recomendable es desactivar Private DNS y configurar manualmente solo el DNS para la API privada.
VPC Endpoint Policy restringe, mediante lenguaje de políticas IAM, el alcance de los recursos accesibles a través del Endpoint. Se puede adjuntar una política al Gateway Endpoint de S3 para permitir solo ciertos buckets, o usar una política de Interface Endpoint para limitar las llamadas a APIs específicas.
AWS Systems Manager Session Manager requiere únicamente tres Interface Endpoints —, y — para acceder de forma segura a instancias EC2 sin necesidad de IP pública ni Bastion. EC2 Instance Connect Endpoint permite conexiones SSH desde el navegador sin abrir el puerto 22 a internet.
---
Transit Gateway, Direct Connect y VPN: Opciones de Seguridad con MACsec
En entornos multi-VPC o con conectividad hacia instalaciones on-premise, Transit Gateway actú