VPC y Security Groups: quién puede hablar con quién
Modelo mental de red cloud sin levantar infraestructura real: subnets, rutas, security groups y reglas de entrada/salida con ejemplos ficticios.
Antes de empezar necesitás
- Entender IPs, puertos y CIDR básico
- Haber visto conceptos base de AWS
Al terminar vas a poder
- Dibujar una VPC mínima con subnets públicas y privadas
- Distinguir route table, NACL y security group
- Escribir reglas de SG con mínimo privilegio
- Detectar reglas demasiado amplias
En cloud, muchas brechas no empiezan con un exploit: empiezan con “abrí 0.0.0.0/0 porque no andaba”. Este lab te obliga a dibujar quién necesita hablar con quién.
flowchart LR I[Internet] -->|443| ALB[ALB público] ALB -->|8080| API[Backend privado] API -->|5432| DB[(DB privada)]
Security Group como firewall de intención
Una regla buena dice origen, puerto y motivo:
destino puerto origen motivo
ALB 443 0.0.0.0/0 tráfico HTTPS público
API 8080 sg-alb solo el balanceador llama al backend
DB 5432 sg-api solo la API habla con la DBReglas que deberían hacer ruido
0.0.0.0/0 hacia SSH/RDP
0.0.0.0/0 hacia base de datos
backend aceptando tráfico directo desde internet
egress abierto sin razón en componentes sensiblesNo toda regla amplia es vulnerabilidad inmediata, pero toda regla amplia necesita justificación.
Evidencia sin cuenta real
Podés documentarlo como diseño, sin desplegar:
sg-alb inbound: 443 desde 0.0.0.0/0
sg-api inbound: 8080 desde sg-alb
sg-db inbound: 5432 desde sg-apiLo que practicás en este lab
Llevátelo a tu repo si querés, pero no es obligatorio: es tu aprendizaje.
- Diagrama de VPC con subnets y flujo de tráfico
- Tabla de reglas permitidas y denegadas
- Writeup: qué regla abrirías y cuál no
Reto
Diseñá una app web ficticia con ALB público, backend privado y base de datos privada. Escribí las reglas mínimas de security group entre los tres.
Resolvelo y escribí dos líneas explicando qué pasó. Con eso lo fijás.