Conceptos

Arquitectura de red segura y segmentación

Actualizada el Jan 21, 2026

#defense#network

La arquitectura de red segura es el diseño de la red (capas, segmentación, controles y flujos permitidos) con el objetivo de mantener disponibilidad, reducir el movimiento lateral, limitar…

Definición

La arquitectura de red segura es el diseño de la red (capas, segmentación, controles y flujos permitidos) con el objetivo de:

Mantener disponibilidad (redundancia/continuidad).
Reducir el movimiento lateral (segmentación + controles).
Limitar impacto ante compromiso (zonas, mínimos privilegios, monitoreo).
Hacer el tráfico observable y gobernable (políticas, logs, detección).

Contexto

En un entorno corporativo, la red no solo conecta sistemas: también define qué puede hablar con qué, con qué protocolos y bajo qué controles.

Una red “bien diseñada” (según el RAW) busca:

Resiliencia: si un switch falla, el tráfico se redistribuye por otra ruta sin perder uptime.
Contención: si un servidor expuesto (p.ej. web) se compromete, no debe poder pivotar hacia activos críticos.
Aislamiento por defecto: si un dispositivo “aleatorio” se conecta (BYOD/guest), debe quedar segmentado y sin acceso a sistemas sensibles.

Desarrollo (MIT-style)

Principios prácticos (para que la red sea “segura”)

Segmentar por riesgo y función, no solo por comodidad.
Definir flujos permitidos (allowlist) entre zonas.
Usar controles por capas: L2 (switch), L3/L4 (router/firewall), L7 (proxy/UTM) + observabilidad.
Diseñar con logging: si no se puede detectar, no se puede responder.

Segmentación: subredes vs VLAN (por qué importa)

Las subredes segmentan a nivel de capa 3 (IP). Por sí solas, no siempre crean un límite de seguridad si el routing es amplio o la red es “plana”.
Las VLAN segmentan en capa 2 usando 802.1Q (etiquetado), separando dominios de broadcast y facilitando separar grupos de dispositivos por política.

Idea clave: si existe una ruta permisiva entre VLANs, hay conectividad; por eso VLAN ≠ seguridad automáticamente. Se necesita zonificación + control (ACL/firewall).

Notas rápidas (contexto adicional):

El RAW usa tag=<0-99> en ejemplos. En la práctica, los IDs de VLAN suelen estar en el rango 1–4094 (según plataforma/diseño).
La segmentación no sustituye controles de identidad: se complementa con IAAA (autenticación/autorización) y con principios como Defense in Depth.

Zonas de seguridad (zonificación)

Una práctica común es modelar la red como zonas (external/DMZ/trusted/restricted/management/audit) y definir qué tráfico puede cruzar entre ellas.

Regla simple de diseño:

Las zonas más expuestas (Externo/DMZ/Guest) deben tener el mínimo de rutas y privilegios hacia las zonas internas.
Las zonas más sensibles (Restringido/Gestión/Auditoría) deben estar más aisladas y con mayor monitoreo.

Controles de tráfico: ACL vs firewall con estado

ACL (stateless): lista de reglas (ACE) que permiten/deniegan según criterios (IP origen/destino, puertos, etc.). Útil y rápida, pero con contexto limitado.
Firewall con estado (stateful): correlaciona conexiones (established/related/invalid) y puede aplicar políticas más ricas. Base típica para pares de zonas.

Pares de zonas (zone pairs)

Modelo: definir políticas por dirección entre dos zonas (A → B y B → A). Esto mejora la claridad y la capacidad de aplicar “mínimo necesario” por flujo.

Inspección de tráfico cifrado (SSL/TLS inspection)

Si un implante/malware usa HTTPS hacia el exterior, el firewall puede verlo como “legítimo”. La inspección TLS (proxy/UTM) permite descifrar y aplicar controles.

Trade-offs (importante):

Privacidad/Legal/Compliance.
Riesgo de MiTM corporativo (confianza en el proxy y en su protección).
Ruptura de pinning/casos donde no se puede inspeccionar.

Controles L2/L3 contra ataques comunes

DHCP Snooping: evita servidores DHCP rogue y construye una tabla de bindings.
Dynamic ARP Inspection (DAI): valida ARP contra los bindings del snooping de DHCP, mitigando ARP spoofing.

Herramienta recomendada para observar/validar tráfico (lab): Wireshark.

Ejemplos (diseño rápido)

Ejemplo 1 — Segmentación mínima por zonas

Externo (Internet)
DMZ (servicios públicos / invitados)
Confianza (usuarios/workstations)
Restringido (DCs/DBs/datos sensibles)
Gestión/Auditoría (admin, backups, SIEM)

Flujos típicos (alto nivel):

Externo → DMZ: solo servicios publicados (p.ej. HTTPS) + WAF/IDS si aplica.
Confianza → DMZ: solo lo necesario (p.ej. navegación proxy/HTTPS) con inspección según política.
Confianza → Restringido: solo apps necesarias (allowlist), autenticación fuerte, logging.
Gestión/Auditoría: acceso muy limitado y altamente auditado.

Ejemplo 2 — Checklist de verificación rápida

¿Qué zonas existen y quién pertenece?
¿Qué flujos están permitidos y por qué?
¿Qué controles aplican (ACL/firewall/UTM)?
¿Qué logs existen y dónde se centralizan?
¿Cómo evitas pivoting desde DMZ/Guest?

Pitfalls / Errores comunes

“Tengo VLANs, por tanto estoy seguro”: si hay routing permisivo, no hay contención.
VLAN nativa/trunks mal configurados (fugas de tráfico no etiquetado).
ACLs sin logging (invisible) o demasiado amplias (equivalen a “permit any”).
Firewall stateful sin diseño por pares de zonas (reglas difíciles de entender y mantener).
Inspección TLS sin gobernanza (impacto en privacidad, pinning, breakage).
DHCP snooping/DAI mal configurados (puertos trusted incorrectos, falsos positivos, bypass).

Diagrama

flowchart LR
  I[Externo / Internet] -->|HTTPS| DMZ[DMZ]
  DMZ -->|Flujos allowlist| LAN[Zona de confianza]
  LAN -->|Solo lo necesario| RES[Restringido]
  MGMT[Gestión/Auditoría] -->|Admin + telemetría| LAN
  MGMT -->|Admin + telemetría| RES

  subgraph Controles
    FW[Firewall stateful / zone pairs]
    UTM[Proxy/UTM + inspección TLS]
    L2[L2: VLAN + DHCP snooping + DAI]
  end

  FW --- DMZ
  FW --- LAN
  FW --- RES
  UTM --- DMZ
  L2 --- LAN