Arquitectura de Red Diseño Implementable RGPD · ISO 27001 · ENS Medio Multisede · Híbrido Azure

MedCore Solutions SL — Arquitectura de Red Empresarial

Rediseño completo de infraestructura: segmentación clínica, WAN resiliente y migración en 3 fases

Cliente: MedCore Solutions SL
Sedes: Madrid (HQ) · Barcelona · Valencia
Empleados: 120 · ~250 dispositivos
Cloud: Azure ExpressRoute 1 Gbps
Horizonte: 6 meses · 3 fases
Uptime SLA: ≥ 99,9% aplicación clínica
7
VLANs / Zonas
3
Sedes
6 mo
Migración
OSPF
Routing interno
Dual ISP
WAN Madrid HQ
0
Cortes totales
🎯
Objetivo y Alcance
Rediseñar la infraestructura de red de MedCore Solutions SL para eliminar la red plana existente y sustituirla por una arquitectura segmentada, resiliente y auditable que cumpla los requisitos de RGPD para datos sanitarios, ISO 27001 y ENS nivel medio. El diseño cubre las tres sedes (Madrid HQ, Barcelona y Valencia), conectividad WAN con doble ISP en sede central, integración con Azure vía ExpressRoute ya contratado, y una migración en 3 fases que garantiza continuidad operativa para el sistema clínico (sin cortes en horario 8h–22h).

Dentro del alcance

  • Segmentación completa Madrid HQ (7 VLANs)
  • Reemplazo firewall perimetral ASA 5506-X EOL
  • WAN dual ISP + SD-WAN ligero (PfSense/Fortinet) Madrid
  • IPSec/GRE site-to-site a BCN y VLC sobre doble ISP
  • Activación ExpressRoute para tráfico Azure productivo
  • IPAM, monitorización centralizada, SIEM básico
  • Modelo de acceso OOB y gestión de configuración

Fuera del alcance

  • Renovación switches de acceso 2960-X (se reutilizan)
  • Reconfiguración de APs UniFi (conservar, reVLAN)
  • Diseño de la aplicación clínica en Azure
  • Políticas de seguridad endpoint (dominio de EDR)
  • Cableado estructurado físico (fuera de presupuesto)
⚠️
Supuestos y Preguntas que Cambian el Diseño
Supuesto
Los Catalyst 2960-X de acceso soportan 802.1Q trunk hacia el nuevo switch de distribución/core. Se mapearán a las nuevas VLANs.
Supuesto
Azure ExpressRoute circuit está provisionado pero el BGP peering con la VNet está sin configurar. Se activará en Fase 2.
Supuesto
Los APs UniFi admiten múltiples SSIDs mapeados a VLANs distintas (usuarios, guest, IoT). Requiere controlador UniFi accesible.
Supuesto
Budget "tier medio" implica firewall NGFW de gama media (Fortinet 100F class o equivalente), no chassis enterprise.
Pregunta crítica
¿Los equipos DICOM se comunican sólo dentro de Madrid HQ o también necesitan acceso a servidores DICOM en Azure? Afecta a las ACLs y a si ExpressRoute necesita filtros para DICOM.
Pregunta crítica
¿Las sucursales BCN y VLC acceden a la aplicación clínica on-premise en Madrid o directamente a Azure? Determina si el VPN site-to-site debe pasar por el CPD de Madrid o ir directo a Azure.
Pregunta crítica
¿Existe Active Directory / LDAP? La segmentación dinámica (802.1X) depende de un directorio y un RADIUS. Si no hay, se usa segmentación estática por puerto.
Pregunta crítica
¿Cuál es la tolerancia a corte en ventana de mantenimiento nocturna (22h–8h)? Ventanas de 2–4h permiten migración sin servicios adicionales de rollback caliente.
🗺️
Topología Recomendada: Routed Campus + Hub-and-Spoke WAN
Se elige topología routed campus con capa Core/Distribución dedicada en Madrid HQ, eliminando cualquier stretched L2. Las sucursales son spoke sobre IPSec/GRE con failover. Azure se conecta vía ExpressRoute (tráfico productivo) + VPN IPSec de backup. Esta elección es la más simple que satisface compliance, HA y operaciones con el hardware disponible.
  ┌─────────────────────────────────────────────────────────────────────────────┐
  │                          INTERNET / WAN                                     │
  │              ISP-A (fibra 1Gbps)          ISP-B (4G/cable backup)          │
  └──────────────┬──────────────────────────────┬──────────────────────────────┘
                 │                              │
  ┌──────────────▼──────────────────────────────▼──────────────────────────────┐
  │         FIREWALL NGFW (activo/pasivo HA)  — Madrid HQ Perímetro              │
  │    NAT · IPS · App-Control · SSL-Inspect · Zonas: WAN/LAN/DMZ/OOB         │
  └──────────────────────────────┬─────────────────────────────────────────────┘
                                 │  L3 routed (OSPF area 0)
  ┌──────────────────────────────▼─────────────────────────────────────────────┐
  │              CORE / DISTRIBUCIÓN L3  — Madrid HQ                            │
  │          (stack 2 switches, OSPF, inter-VLAN routing, STP root)            │
  │  VLAN10 MGMT · VLAN20 SERVERS · VLAN30 DICOM · VLAN40 USERS               │
  │  VLAN50 VOIP  · VLAN60 GUEST  · VLAN70 IoT                                │
  └──────┬──────────────┬──────────────┬───────────────────────────────────────┘
         │              │              │
  ┌──────▼──────┐ ┌─────▼──────┐ ┌────▼──────────┐
  │  ACCESO USR  │ │ ACCESO DICOM│ACCESO IoT   │
  │ Catalyst    │ │ Catalyst   │ │ Switch dedicado│
  │ 2960-X      │ │ 2960-X     │ │ (nuevo, aislado)│
  └─────────────┘ └────────────┘ └────────────────┘
         │
  ┌──────▼──────────────────────────────────┐
  │        UniFi APs  (trunk 40/60/70)        │
  │  SSID:CORP→VLAN40  GUEST→VLAN60  IoT→VLAN70 │
  └─────────────────────────────────────────┘

  ──── WAN SITE-TO-SITE ────

  Madrid HQ  ──[IPSec/GRE pri]──►  BCN (spoke, 20 emp, VLAN40+VLAN20 acceso limitado)
  Madrid HQ  ──[IPSec/GRE pri]──►  VLC (spoke, 10 emp, VLAN40 sólo)
  Madrid HQ  ──[IPSec failover]──►  BCN / VLC (vía ISP-B si ISP-A cae)
  Madrid HQ  ──[ExpressRoute]──►    Azure VNet (app clínica, CI/CD, backups)
  Madrid HQ  ──[IPSec VPN backup]── Azure VNet (failover ExpressRoute)

Justificación: Routed campus elimina riesgos de broadcast storms y facilita microsegmentación sin recableado. Hub-and-spoke WAN es suficiente para el volumen y simplifica el troubleshooting. ExpressRoute ofrece latencia predecible para la app clínica y cumple ENS nivel medio (cifrado en capa de transporte).

🔐
Direccionamiento IP y Segmentación por Zonas
Zona / VLAN Propósito Subred Madrid HQ Límite de routing Flujos permitidos
VLAN 10
MGMT / OOB
Acceso gestión a switches, firewalls, servidores, APs. Solo administradores. 10.10.10.0/27
30 hosts
Aislada. Sin acceso desde VLAN usuario. Solo desde jump host. → SNMP, SSH, HTTPS a dispositivos de red
→ Syslog out
← Jump host (VLAN20)
VLAN 20
SERVERS / CPD
Servidores físicos y VMs on-premise: AD, BD clínica, DICOM server, archivo. 10.10.20.0/24
254 hosts / VMs
ACL estricta. Solo recibe de zonas autorizadas. Inspección IPS activa. ← VLAN40 TCP 443/8443 (app)
← VLAN30 DICOM 11112
→ Azure (ExpressRoute) TCP 443
→ VLAN10 (logs, backup)
VLAN 30
DICOM / MÉDICO
Equipos de imagen médica (rayos-X, TAC, escáneres). Dato sensible RGPD cat. especial. 10.10.30.0/25
126 hosts
Zona regulada. Sin acceso a Internet. Solo DICOM server en VLAN20. → VLAN20 TCP 11112 (DICOM store)
→ VLAN20 TCP 104 (DIMSE)
✗ Internet prohibido
✗ VLAN40 prohibido
VLAN 40
USUARIOS corp
Empleados corporativos: PCs, laptops, impresoras no clínicas. Acceso a app y Office365. 10.10.40.0/23
510 hosts
Acceso al exterior via proxy/NGFW. App clínica vía HTTPS. → Internet via firewall (HTTP/HTTPS)
→ VLAN20 TCP 443 (app clínica)
→ Azure TCP 443 (O365, SaaS)
✗ VLAN30 prohibido
VLAN 50
VoIP
Teléfonos IP, centralita. QoS DSCP EF prioritario. 10.10.50.0/25
126 hosts
QoS strict. Llamadas out via SBC (DMZ). Sin acceso a servidores de datos. → SBC/PBX (DMZ) SIP/RTP
→ NTP (VLAN20)
✗ VLAN20 datos prohibido
VLAN 60
GUEST WiFi
WiFi para visitas, proveedores, demos clientes. Acceso sólo a Internet. 10.10.60.0/24
254 hosts
Totalmente aislada. Captive portal. Rate limit 20 Mbps/usuario. → Internet TCP 80/443
✗ Todo tráfico interno prohibido
VLAN 70
IoT / OT
Sistemas de acceso físico, climatización BMS, cámaras IP, impresoras de etiquetas. 10.10.70.0/25
126 hosts
Sin salida a Internet. Acceso solo al controlador de gestión en VLAN20. → VLAN20 controlador IoT TCP 8080
→ NTP
✗ Internet prohibido
✗ VLAN40 prohibido

Sucursales: Barcelona usa 10.20.x.0/24 (VLAN 40+20 acceso limitado). Valencia usa 10.30.x.0/24 (VLAN 40 sólo). Summarización de rutas a nivel WAN: Madrid anuncia 10.10.0.0/16, cada spoke la suya.

🔄
Routing, Conectividad WAN y Redundancia

Routing interno — OSPF área 0

OSPF single-area en Madrid HQ entre firewall y core L3. Simple de operar, convergencia <1s con BFD en enlaces de distribución. No se extiende a sucursales (spoke están como rutas estáticas/BGP sobre el túnel). Inter-VLAN routing en el core L3 para tráfico local.

WAN sucursales — IPSec/GRE + ECMP

Cada sucursal tiene túnel IPSec primario sobre ISP local y túnel de failover sobre 4G. Madrid HQ termina los dos túneles y hace IP SLA tracking para failover automático <30s. No se necesita SD-WAN complejo — el volumen no lo justifica.

Azure — ExpressRoute + IPSec VPN backup

Se activa el BGP peering con Azure VNet vía ExpressRoute (1 Gbps, latencia <5ms Madrid→Azure West Europe). La VPN IPSec existente se convierte en failover de ExpressRoute. El tráfico de la app clínica sigue siempre ExpressRoute; si cae, conmuta a VPN automáticamente.

Redundancia HQ — Firewall HA activo/pasivo

El NGFW se despliega en par HA activo/pasivo con heartbeat dedicado en VLAN10 MGMT. Failover <3s (sub-second con conntrack sync). El core L3 se despliega en stack de 2 unidades con LACP/VSS; si cae un miembro, el tráfico conmuta sin interrupción.

📊
Gestión, Observabilidad y Backup de Configuración

Plano de gestión

  • Jump host dedicado en VLAN10 (VM en CPD, acceso SSH/HTTPS)
  • SSH v2 only, autenticación por certificado. Telnet deshabilitado.
  • NTP sincronizado desde servidor interno (VLAN20) → NTP pool ES
  • SNMP v3 authPriv — sin community strings en claro
  • IPAM: NetBox (self-hosted en VLAN20) para todas las subredes
  • Controlador UniFi en VLAN20 para todos los APs

Monitorización y SIEM

  • Zabbix/PRTG para uptime, latencia, uso de ancho de banda por VLAN
  • Alertas: caída de interfaz WAN, uso CPU firewall >80%, túnel IPSec caído
  • Syslog centralizado: Graylog / Wazuh en VLAN20 (gap ISO 27001 cubierto)
  • Logs de firewall retención 12 meses (RGPD art. 32 + ENS)
  • Dashboard de red visible para el equipo IT en panel web interno

Backup y Rollback de Configuración

  • RANCID/Oxidized para backup diario automatizado de configs de todos los dispositivos a repositorio Git privado en Azure
  • Antes de cualquier cambio: backup manual + snapshot VM del firewall
  • Runbooks de rollback documentados para cada fase de migración
  • Consola out-of-band (4G USB o iDRAC/iLO en servidores) obligatoria antes de cambios en firewall o core
🚀
Plan de Implementación en 3 Fases — 6 Meses
1
Fase 1 — Cimientos y Segmentación HQ Madrid
Semanas 1–8 (2 meses)
  • Instalar y configurar NGFW HA (activo/pasivo) en paralelo al ASA actual (no se retira hasta validación)
  • Desplegar core L3 stack en la sala de servidores (sin corte de acceso)
  • Crear VLANs 10/20/30/40/50/60/70 en el core y trunk a 2960-X existentes
  • Migrar servidores CPD a VLAN20: primero uno a uno en ventana nocturna 00h–04h
  • Configurar IPAM NetBox y rellenar inventario completo de IPs actuales
  • Instalar OOB (4G router + acceso iDRAC a todos los servidores)
  • Retirar ASA 5506-X y limpiar reglas de routing antiguas
Puerta de validación Tráfico productivo de la app clínica fluye a través del nuevo NGFW sin degradación de latencia. Ping entre VLANs respeta las ACLs definidas. Prueba de failover HA: 0 pérdida de sesiones activas.
2
Fase 2 — WAN Resiliente y Activación ExpressRoute
Semanas 9–16 (2 meses)
  • Contratar ISP-B en Madrid HQ y configurar dual-WAN con IP SLA en NGFW
  • Reemplazar Cisco RV340 EOL en BCN y VLC por routers NGFW clase media con soporte IPSec/GRE
  • Configurar túneles IPSec primario y failover (4G) a cada sucursal
  • Activar BGP peering ExpressRoute con Azure VNet West Europe
  • Migrar tráfico app clínica de VPN sobre Internet a ExpressRoute
  • Configurar VPN IPSec como failover de ExpressRoute con IP SLA
  • Validar latencia <5ms app clínica Madrid→Azure
Puerta de validación Simular caída de ISP-A: failover a ISP-B <30s, tunnels BCN/VLC reconectados. Simular caída ExpressRoute: VPN IPSec activa en <60s. Latencia app clínica <5ms en condiciones normales.
3
Fase 3 — Segmentación IoT/DICOM, Observabilidad y Compliance
Semanas 17–24 (2 meses)
  • Migrar equipos DICOM/médicos a VLAN30 (ventana mantenimiento de noche)
  • Instalar switch dedicado para VLAN IoT/OT (VLAN70) completamente aislado
  • Reconfigurar UniFi APs: SSID corp → VLAN40, guest → VLAN60, IoT → VLAN70
  • Desplegar Wazuh/Graylog SIEM en VLAN20, conectar logs de NGFW y switches
  • Configurar Zabbix + alertas email/SMS para IT
  • Activar backup automático Oxidized para todos los dispositivos
  • Documentar arquitectura final (Diagrama Visio + runbooks operativos)
  • Entrega de evidencias para auditoría ISO 27001: logs 12 meses, ACLs documentadas
Puerta de validación Pentesting interno: equipo DICOM en VLAN30 no alcanza VLAN40 ni Internet. Guest WiFi no accede a recursos internos. SIEM recibe logs de todos los dispositivos. Simulacro de auditoría ISO 27001 supera checklist de controles de red (A.13).
🛡️
Riesgos Residuales y Mitigaciones
Riesgo Impacto Nivel Mitigación
Migración de DICOM a VLAN30 rompe flujo de trabajo clínico si se hace sin inventario completo de IPs de equipos médicos Pérdida de imágenes médicas en pruebas. Paro operativo clínica. Alto Inventariar TODOS los equipos DICOM antes de Fase 3. Mantener VLAN legacy en paralelo hasta validar migración equipo a equipo. Nunca hacer cut-over masivo.
2960-X de acceso con firmware antiguo pueden no soportar VLAN >32 o trunk 802.1Q correctamente Bucles STP, tráfico VLAN incorrecto, caída de red. Alto Validar firmware y feature set de todos los 2960-X antes de Fase 1. Actualizar a última IOS-LAN-LITE disponible. Probar trunk en lab antes de producción.
ExpressRoute BGP peering mal configurado puede atraer todo el tráfico de Azure a Madrid en lugar de bifurcar por VPN Pérdida de failover WAN-Azure. Dependencia única de ExpressRoute. Medio Configurar MED/AS-PATH correctamente para preferir ExpressRoute pero con IP SLA hacia Azure. Probar failover en ventana antes de migrar tráfico productivo.
Active Directory / DNS no segmentado puede filtrar nombres internos a VLAN Guest o IoT vía broadcast DNS Exposición de topología interna. Violación de compliance RGPD. Medio DNS split-horizon: VLAN60/70 usan resolver externo (8.8.8.8), no el AD interno. Confirmar con equipo Windows antes de Fase 3.
UniFi controller inaccesible durante migración VLAN impide reconectar APs WiFi corporativo caído hasta recuperar acceso al controlador. Bajo Controlador UniFi en VLAN20 (servidores) con IP estática fija. Siempre accesible desde VLAN10 management. Documentar URL en runbook.
🔗
Handoff a Skills Especializadas
network-config-validation
Revisar configuración completa del NGFW (ACLs, zonas, NAT) y la config de trunk/VLAN de los 2960-X antes de cualquier cut-over en Fase 1. Detectar comandos peligrosos o reglas que anulen la segmentación.
network-bgp-diagnostics
Validar el peering BGP de ExpressRoute en Fase 2: prefijos anunciados desde Azure, políticas de aceptación de rutas, comparar con lo esperado. Verificar failover IPSec y que no hay route-leaking entre VRFs.
network-interface-health
Tras activar cada fase, auditar contadores CRC, drops e inestabilidades de enlace en los 2960-X existentes. Detectar errores de cableado o puertos degradados antes de que impacten al nuevo diseño segmentado.
cisco-ios-patterns
Generar los comandos exactos para trunk 802.1Q, configuración de VLANs, spanning-tree root-bridge y QoS DSCP en los Catalyst 2960-X, siguiendo sintaxis IOS-LAN-LITE. No aplicar sin validación previa.
netmiko-ssh-automation
Automatizar la recogida de inventario read-only (show vlan brief, show ip interface brief, show version) en todos los 2960-X y el nuevo core para alimentar NetBox/IPAM antes de Fase 1.