Tres incidentes de seguridad en seis meses en una red plana donde un endpoint comprometido podía alcanzar directamente los servidores de producción y el ERP financiero.
Estado inicial
✗Red plana — todos los segmentos en la misma subred /20
✗47 reglas "permit any any" en firewall heredado de ISP
✗ERP financiero accesible desde la VLAN de invitados WiFi
✗Endpoints de planta con acceso directo a servidor de AD
✗Cero visibilidad de tráfico lateral — sin logs de red
Restricciones operacionales
⚠Ventana de mantenimiento máxima: 2h por sede (turnos 24/7)
⚠ERP legacy en Windows Server 2012 sin soporte de dominio moderno
⚠Sucursales conectadas por MPLS de contrato vigente
⚠Equipo IT interno: 1 administrador sin experiencia en Fortinet
Decisiones de arquitectura
01
FortiGate 100F central + FG-60F en cada sucursal──Consola unificada FortiManager · visibilidad norte-sur y este-oeste desde un punto
02
8 VLANs funcionales (Corp, Servers, ERP, Mgmt, Print, IoT, Guest, Branch)──ERP aislado en VLAN 25 con ACL explícitas · invitados en VLAN 99 sin acceso interno
03
SD-WAN overlay sobre MPLS + failover ISP secundario──Elimina dependencia de MPLS único · ha de implementarse sin cambiar el contrato vigente
04
IPS profile restrictivo solo en tráfico norte-sur + Application Control──Mantiene latencia baja en LAN · máxima inspección en perímetro y entre segmentos críticos
Despliegue
Sem 1
Auditoría de topología · diseño VLAN y política
HLD aprobado
→
Sem 2–3
Instalación FortiGate · migración sede central
VLAN Corp + Servers activas
→
Sem 4–5
Sucursales · site-to-site IPsec · IPS/IDS
ERP aislado en VLAN 25
→
Sem 6
Hardening reglas · documentación · handoff
Runbook entregado
Entregables
→Diagrama topológico L2/L3 por sede (Visio)
→Política de firewall documentada (254 reglas → 38 explícitas)
→Runbook operacional FortiGate
→Procedimiento de respuesta ante incidente de red
→Baseline de configuración para replicación en nuevas sedes
Resultados operacionales
✓0 incidentes de seguridad
14 meses consecutivos tras implementación
✓Visibilidad completa
100% endpoints identificados y mapeados en topología
✓Reducción de reglas: −91%
254 reglas "any/any" colapsadas a 38 reglas explícitas
✓ERP aislado en VLAN dedicada
Acceso restringido a 8 usuarios nominados con log de auditoría
✓MTTR ante incidente: < 2h
Antes: sin visibilidad · tiempo de detección indefinido
Madurez operativa documentada
Overlay de arquitectura
Mapa por sede con core, enlaces MPLS, VLANs funcionales, reglas inter-VLAN y ruta de failover ISP.
Matriz de gobierno
FortiGate / FortiManager
Administrador IT interno · Cambios de politica, backup y monitoreo · Mensual
VLAN ERP
Finanzas + IT · Altas de usuarios nominados y excepciones · Quincenal
Dependencias de despliegue
Core switchfeedsVLAN ERP · El cambio de trunks antecede politicas NGFW
FortiAnalyzermonitorsRespuesta a incidente · Alertas de movimiento lateral
Dependencias
01Ventana de 2h por sede aprobada por operaciones
02Inventario de puertos fisicos validado antes de mover VLANs
Tradeoffs
01IPS restrictivo solo en norte-sur para conservar latencia LAN
02ERP se mantuvo con excepciones temporales mientras se validaban flujos reales
Rollback
01Snapshot de configuracion FortiGate previo a cada sede
02Plan de retorno a VLAN plana documentado solo para contingencia P1
Lecciones aprendidas
01El inventario fisico de switchports fue mas critico que el diagrama heredado
02La reduccion de reglas any/any requiere observacion de trafico antes de bloquear
Personal62 usuarios · 1 sede principal + 2 consultorios
Endpoints58 equipos Windows · 4 Mac · 24 dispositivos iOS (médicos)
PlataformaMicrosoft 365 Business Premium (parcialmente configurado) · HIS on-premises
6 semanas
62 usuarios con acceso irrestricto a expedientes de pacientes usando únicamente usuario y contraseña — sin MFA, sin gestión de dispositivos, y con cuentas administrativas compartidas entre tres médicos.
Estado inicial
✗Cero MFA — credencial única para acceso a M365 y HIS
✗Cuentas admin compartidas (3 médicos · misma contraseña)
✗Sin MDM — 82 dispositivos sin inventario ni política
✗Expedientes accesibles desde cualquier dispositivo sin control
✗Fuera de NOM-024 — sin clasificación de datos sensibles
Restricciones operacionales
⚠Plazo regulatorio NOM-024: 90 días desde inicio de proyecto
⚠Médicos con alta resistencia al cambio en flujos de autenticación
⚠HIS legacy no integrable con Entra ID (autenticación local propia)
⚠Dispositivos iOS personales usados para acceder a Teams/correo
Decisiones de arquitectura
01
Entra ID P2 + Conditional Access por riesgo y cumplimiento──MFA obligatorio pero sin fricción en dispositivos gestionados ya inscritos en Intune
02
Intune MAM para iOS sin MDM completo en dispositivos personales──Protege datos corporativos en apps M365 sin requerir gestión del dispositivo personal
03
PIM just-in-time para las 3 cuentas admin existentes──Eliminación de acceso permanente · log de activación con aprobación · sin fricción en operación diaria
04
Microsoft Purview DLP para datos de pacientes──Prevenir exfiltración de datos NOM-024 por correo, Teams, USB o share externo
Despliegue
Sem 1–2
Entra ID P2 · CA · MFA enrollment
100% usuarios con MFA
→
Sem 3
Intune MDM Windows · Autopilot · MAM iOS
82 dispositivos inscritos
→
Sem 4–5
Purview DLP · clasificación NOM-024 · PIM
Políticas DLP activas
→
Sem 6
Auditoría · testing · documentación
Entrega certificación
Entregables
→Conjunto de 12 políticas de Acceso Condicional documentadas
→Baseline Intune: 6 perfiles de configuración + 4 de cumplimiento