SEGMENTACIÓN DE RED: DEL PLANO ÚNICO AL MICROSEGMENTADO
Introducción
Una red plana es cómoda hasta el día del incidente. Cuando un atacante entra, el movimiento lateral es su
autopista.
La segmentación de red rompe esa autopista y convierte cada salto en un control.
Es la diferencia entre un susto contenido y un problema mayor.
Por qué segmentar (de verdad)
- Reduce superficie de ataque: limita el movimiento lateral y el impacto de un compromiso.
- Aísla activos críticos: bases de datos, backups, administración y OT/IoT en zonas separadas.
- Facilita el cumplimiento: alinea controles por zona (PCI, ENS, ISO, datos personales).
- Mejora la observabilidad: menos ruido, más señal en controles y alertas.
Controles ISO/IEC 27002 relacionados
- A.8.20 – Seguridad de redes: diseño, separación y protección del tráfico.
- A.8.21 – Seguridad de servicios de red: firewalls, VPN, proxies, DNS seguros.
- A.8.9 – Gestión de la configuración: estándares, baselines y control de cambios en dispositivos.
Modelo por zonas (punto de partida realista)
- Zona de usuarios/endpoints (VLANs por departamento o riesgo).
- Zona servidores (servicios internos, sin acceso directo desde usuarios).
- Zona DMZ (servicios publicados: reverse proxy, WAF, VPN).
- Zona administración (bastiones/jump servers, solo desde redes de admin).
- Zona datos críticos (BBDD, backups inmutables) con reglas muy restrictivas.
- OT/IoT segregada, con pasarelas y listas blancas bien definidas.
Del macro al micro: cómo avanzar
- Inventario y flujos: quién habla con quién (aplicaciones, puertos, direcciones).
- VLANs y ACLs: separa dominios de broadcast y controla tráfico inter-VLAN en L3.
- Firewalls internos: zonas/segmentos con políticas explícitas “deny by default”.
- Microsegmentación: controles por workload (host firewall/EDR, SDN, policy-based).
- Bastiones y RBAC para administración (sin RDP/SSH directos desde usuario).
- Monitoreo y ajuste: registra, afina y elimina reglas “temporales” que se hacen eternas.
Errores frecuentes
- Crear VLANs pero permitir "any-to-any" entre ellas.
- Publicar administración en DMZ o Internet “para salir del paso”.
- No documentar reglas: nadie sabe qué rompe si se limpia.
- Excepciones “temporales” que nunca se revisan.
- Olvidar OT/IoT y permitir acceso libre a la red corporativa.
Buenas prácticas esenciales
- Política deny-by-default y lista blanca de servicios por zona.
- Reglas por aplicación (FQDN, etiquetas, grupos) en lugar de IPs sueltas.
- Administración a través de bastión con MFA y registro de sesión.
- Filtrado este-oeste (no solo norte-sur) con firewalls internos/host firewall.
- DNS y NTP controlados por zona; bloquea resoluciones/salidas arbitrarias.
- Revisión trimestral de reglas y eliminación de “allow any/any”.
Checklist rápida
- ¿Existe mapa de zonas y flujos autorizados?
- ¿Tráfico inter-VLAN pasa por control L3/Firewall con política explícita?
- ¿Administración solo vía bastión con MFA y logging?
- ¿Hay microsegmentación (host firewall/SDN/EDR) en servidores críticos?
- ¿Revisión y limpieza de reglas documentada y periódica?
Herramientas/tecnologías útiles
- Red/Firewall: VLANs, ACLs L3, firewalls NGFW (zonas, IDS/IPS), WAF/Reverse-proxy.
- Microsegmentación: políticas host (Windows Firewall, iptables/nftables), EDR con control de red, SDN/NSX/ACI.
- Acceso admin: jump servers, PAM, VPN con MFA, ZTNA.
- Visibilidad: NetFlow/sFlow, NDR, CMDB + mapas de dependencias.
Relación con otras áreas
- Gestión de accesos: segmentación + mínimo privilegio de red.
- Registros/Logs: zonas = puntos claros de monitorización.
- Continuidad/DRP: aislar backups y BBDD reduce impacto.
Reflexión final
La red perfecta no es la que conecta todo con todo, sino la que solo conecta lo necesario. Cada salto que bloqueas hoy es un movimiento lateral que evitas mañana.
Conclusión
La segmentación es la base práctica de Zero Trust. No requiere “grandes compras”: requiere diseño y disciplina.
En Gondor diseñamos arquitecturas por zonas y microsegmentación alineadas con ISO/IEC 27002 y el ENS.