Network - segmentación y zero-trust
La red en la nube es programable: VPCs, subnets, security groups y firewalls de aplicación escriben el perímetro aplicación por aplicación, en lugar de esperar al borde del data center.
Qué es
En la nube, la red no es cableado: es configuración. VPCs, subnets, route tables, security groups y network ACLs son objetos que creas y versionas como cualquier otro recurso. La topología se vuelve código, y la se vuelve un archivo que se puede leer en un PR.
Eso cambia el juego. En lugar de un firewall grande en la entrada, el control se reparte: cada subnet decide quién habla con ella, cada instancia define quién llega a ella, y el tráfico que sale del clúster pasa por un gateway que inspecciona y registra.
VPC y subnets: pública versus privada
Dentro de una , el diseño clásico tiene dos capas de subnets. La pública tiene ruta directa a un Internet Gateway y aloja lo que necesita una IP alcanzable (NAT gateway, bastion, load balancer público). La privada no tiene ruta de salida a internet, solo recibe tráfico interno y, cuando necesita salir, habla con el NAT.
El error más común es poner la base de datos en la subnet pública por pereza de configurar rutas. El resultado es un Postgres con IP elástica respondiendo en el 5432 al mundo, esperando que pase el primer escáner.
Security groups: stateful, a nivel de ENI
El es la primera línea en la nube. Es stateful: la respuesta a un request autorizado vuelve sin necesitar una regla de entrada. Asociado a la interfaz de red (ENI), funciona como un firewall por instancia, y varias instancias pueden compartir el mismo grupo cuando cumplen el mismo rol.
El antipatrón clásico es abrir 0.0.0.0/0 en los puertos de administración. Aparece en todos los postmortems:
{
"GroupName": "web-sg",
"Description": "Abierto a internet (NO usar en prod)",
"IpPermissions": [
{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"IpRanges": [ { "CidrIp": "0.0.0.0/0", "Description": "SSH abierto" } ]
},
{
"IpProtocol": "tcp",
"FromPort": 3389,
"ToPort": 3389,
"IpRanges": [ { "CidrIp": "0.0.0.0/0", "Description": "RDP abierto" } ]
}
]
}La regla que debería existir
Cierra los puertos de administración a internet y fuerza la entrada vía bastion o Systems Manager Session Manager. Para lo que necesita acceso humano, restringe por IP corporativa o por VPN:
{
"GroupName": "web-sg",
"Description": "Acceso administrativo vía bastion corporativo",
"IpPermissions": [
{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"IpRanges": [ { "CidrIp": "203.0.113.0/24", "Description": "rango corporativo VPN" } ]
},
{
"IpProtocol": "tcp",
"FromPort": 443,
"ToPort": 443,
"IpRanges": [ { "CidrIp": "0.0.0.0/0", "Description": "HTTPS público" } ]
}
]
}Network ACLs y VPC Flow Logs
La NACL es el complemento stateless de la subnet. Actúa antes del security group y sirve para reglas amplias (bloquear un rango entero conocido como malicioso, por ejemplo). Es stateless, así que la respuesta necesita una regla de entrada específica, y rara vez hace falta tocarla una vez que la topología está madura.
VPC Flow Logs captura todo el tráfico aceptado o rechazado en las ENIs de la VPC y lo vuelca en CloudWatch o S3. Sin flow logs, investigas un incidente a ciegas. Con un camino mínimo: bloqueo por defecto + log activo + endpoints aprendidos, y el equipo de seguridad puede responder qué entró, por dónde y cuándo.
Microsegmentación y zero-trust
Los security groups resuelven el perímetro por carga. Cuando el entorno crece, la clave es empezar a hablar de identidad de workload en lugar de IP: una política que dice 'el servicio A habla con el servicio B en el puerto 8080 vía mTLS' es más duradera que liberar un /24 entre subnets porque alguien pidió acceso una vez.
Herramientas como Calico, Cilium o VPC lattice abstraen la IP y dejan que la política viaje junto con el workload. Aunque el pod cambie de nodo, la regla sigue vigente.
Dónde aparece en el día a día
- diseño inicial de la VPC: topología de subnets públicas y privadas, NAT, rutas y bastion definidos como código en Terraform/Pulumi
- deploy de aplicación: el manifiesto declara el security group, y el pipeline lo crea/reconcilia con la VPC existente
- respuesta a incidentes: VPC flow logs + CloudTrail muestran el origen del ataque en minutos, no en horas
- auditoría continua: un detector de SGs con 0.0.0.0/0 en puertos sensibles rompe el build antes del merge
Puntos fuertes
- red convertida en código: revisar la topología en un PR atrapa errores de subnet antes que el tráfico
- logs nativos: VPC Flow Logs registra origen, destino, puerto y decisión sin agente en el host
- aislamiento por workload: cada servicio tiene el menor camino de red posible
Limitaciones
- complejidad de la topología: 5 cuentas, 12 subnets y 200 SGs necesitan herramientas de visualización y lint
- el SG no inspecciona el payload: el puerto puede ser el correcto y el contenido del request ser un ataque
- el zero-trust de verdad depende de la identidad del workload (mTLS, SPIFFE), que aún es temprana en muchos stacks
conexiones en el mapa
- Zero-trust - modelo de confianzasegmenta por identidadNetwork - segmentación y zero-trust
- Network - segmentación y zero-trustaísla la redContainers - imágenes y cadena de suministro
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Defensa en capas: diseño de sistemas de bordesecopssegmentación y borde diseñados juntos
Desbloquea
pon a prueba lo que entendiste
Cargando preguntas…