Red segura en AWS

La red es la segunda capa de la defensa en profundidad, justo después del borde. En la nube no hay cables que puedas ver: todo son reglas. Un par de ellas mal puestas —un security group abierto a 0.0.0.0/0, una subred que puede salir a cualquier sitio— y el perímetro que creías tener no existe. Esta nota recorre los controles de red de AWS y los aplica a la VPC de Citas: ALB público, API en ECS Fargate en subredes privadas, RDS en subredes aisladas.

Security groups vs NACLs#

Son los dos cortafuegos nativos de la VPC y se confunden constantemente. La diferencia que de verdad importa es stateful vs stateless.

El security group está pegado a la ENI del recurso y es stateful: si permites una conexión de entrada, el retorno sale solo. Solo tiene reglas allow y se evalúan todas juntas, sin orden.
La NACL está en el borde de la subred y es stateless: no recuerda conexiones, así que tienes que permitir la ida y la vuelta por separado. Admite reglas allow y deny, numeradas y evaluadas en orden.

Security group (stateful) vs NACL (stateless)

Red · AWS

Paso 1 de 6Dos filtros

Antes de llegar a la instancia, el tráfico cruza dos controles: la NACL en el borde de la subred (stateless) y el security group pegado a la ENI (stateful).

Esa pequeña palabra —stateless— es la que hace que la gente pierda horas. Si pones una NACL que permite 443 de entrada pero olvidas permitir la salida por puertos efímeros (1024-65535), la respuesta nunca vuelve y parece un problema de aplicación.

El error clásico: abrir a todo internet#

La regla más peligrosa de una VPC es la que no acota el origen. En Citas, el único que debe hablar con el ALB es CloudFront; el único que debe hablar con la API es el ALB. Compara una regla que invita a todo internet con una acotada al origen real mediante una prefix list:

Vulnerable

Seguro

# Cualquiera en internet puede llegar al ALB:
# el WAF del borde se rodea yendo directo al balanceador.
resource "aws_vpc_security_group_ingress_rule" "alb_abierto" {
  security_group_id = aws_security_group.alb.id
  ip_protocol       = "tcp"
  from_port         = 443
  to_port           = 443
  cidr_ipv4         = "0.0.0.0/0" # [!code highlight]
}

# Solo las IPs de CloudFront, vía la prefix list gestionada.
data "aws_ec2_managed_prefix_list" "cloudfront" {
  name = "com.amazonaws.global.cloudfront.origin-facing"
}

resource "aws_vpc_security_group_ingress_rule" "alb_desde_cloudfront" {
  security_group_id = aws_security_group.alb.id
  ip_protocol       = "tcp"
  from_port         = 443
  to_port           = 443
  prefix_list_id    = data.aws_ec2_managed_prefix_list.cloudfront.id # [!code highlight]
}

Y entre niveles internos, la mejor práctica es referenciar el security group origen, no un CIDR: la regla sigue siendo correcta aunque cambien las IPs.

resource "aws_vpc_security_group_ingress_rule" "api_desde_alb" {
  security_group_id            = aws_security_group.api.id
  ip_protocol                  = "tcp"
  from_port                    = 443
  to_port                      = 443
  referenced_security_group_id = aws_security_group.alb.id
}

VPC endpoints y PrivateLink: no salir a internet#

Cuando la API de Citas sube un adjunto a S3 o lee un secreto de Secrets Manager, no hace falta que ese tráfico salga por un NAT gateway hacia internet. Los VPC endpoints mantienen la conexión dentro de la red de AWS:

Gateway endpoint: una entrada en la tabla de rutas. Solo existe para S3 y DynamoDB, y es gratis.
Interface endpoint: basado en AWS PrivateLink, crea una ENI con IP privada en tus subredes para la mayoría de servicios (Secrets Manager, KMS, ECR, SQS…). Se factura por hora y por datos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::citas-adjuntos/*"
    }
  ]
}

Capas gestionadas: Network Firewall, WAF y Shield#

Los security groups y las NACLs filtran por IP y puerto. Para ir más allá, AWS ofrece servicios gestionados que cubren distintas capas:

AWS Network Firewall es un cortafuegos stateful a nivel de VPC, con reglas compatibles con Suricata. Vive en subredes de firewall dedicadas por las que haces pasar el tráfico. Sirve para egreso controlado (permitir solo dominios concretos por SNI), inspección este-oeste entre VPCs y firmas IDS/IPS. Opera por debajo de la capa 7 de aplicación.

AWS WAF inspecciona peticiones HTTP/HTTPS (capa 7) y bloquea inyecciones, XSS, bots y abusos de tasa. Se asocia a CloudFront, al ALB o a API Gateway. En Citas protege el borde delante de CloudFront. Es evadible con payloads ofuscados: complementa la validación en la aplicación, no la sustituye.

AWS Shield protege contra DDoS. Shield Standard es automático y gratuito, y cubre los ataques volumétricos de capa 3/4 más comunes. Shield Advanced es de pago y añade mitigación automática de capa 7, acceso al equipo de respuesta de Shield (SRT) y protección de costes frente al escalado frente al escalado provocado por un ataque.

DNS Firewall y Verified Access#

Dos piezas que suelen faltar en el diseño de red:

Route 53 Resolver DNS Firewall filtra las consultas DNS de salida de tu VPC: bloquea, permite o alerta según listas de dominios. Es una línea de defensa contra exfiltración por DNS y contra malware que resuelve dominios de command and control. Complementa a los DNS query logs, que verás en la nota de registro.
AWS Verified Access da acceso zero-trust a aplicaciones internas sin VPN. Evalúa cada petición contra políticas (escritas en Cedar) combinando un proveedor de identidad y señales de postura del dispositivo. Encaja con el principio de zero trust: no hay una red “de confianza”, cada acceso se verifica.

Un diseño de red para Citas#

Segmenta en tres niveles

Subredes públicas (solo el ALB), privadas (ECS Fargate, con egreso vía endpoints/NAT controlado) y aisladas (RDS, sin ruta a internet).
Encadena los security groups

CloudFront → (prefix list) → ALB → (SG referenciado) → API → (SG referenciado) → RDS. Cada nivel solo acepta del anterior.
Cierra el egreso

VPC endpoints para S3, KMS, Secrets Manager y ECR. DNS Firewall para las consultas de salida. El SG de egreso no permite 0.0.0.0/0.
Añade las capas gestionadas

WAF en CloudFront, Shield para DDoS y, si expones apps internas al equipo, Verified Access en lugar de una VPN.

Tu turno

Audita el perímetro de red de un sistema que conozcas

Elige una VPC (o red) real de tu trabajo o tu lab y revisa:

¿Hay algún security group con 0.0.0.0/0 en un puerto que no sea 80/443 público? ¿Por qué está ahí?
¿Qué puede alcanzar tu capa de cómputo de salida? ¿Podría un proceso comprometido llegar a un servidor externo arbitrario?
¿Usas NACLs? Si es así, ¿permiten los puertos efímeros en el retorno, o hay reglas que “no sabes por qué están”?
¿Qué servicios de AWS consumes por internet que podrías mover a VPC endpoints?

Escribe la tabla nivel → security group → qué acepta → qué puede alcanzar, y marca cada regla que no sepas justificar.

Reto

Pones una NACL que permite 443 de entrada a la subred de la API, pero las respuestas no llegan al ALB. ¿Qué falta?

▸Mostrar solución

La regla de salida para los puertos efímeros. La NACL es stateless: permitir 443 de entrada no autoriza el tráfico de vuelta, que sale por un puerto alto (1024-65535). Necesitas una regla outbound que permita ese rango hacia el ALB. Con un security group no tendrías este problema, porque es stateful.