Compromiso de producción sobre FortiGate
Dos semanas. Alcance definido. Hardening, SD-WAN, integración de identidad, upgrades o migración — elegido en la evaluación inicial.
Dos semanas de trabajo senior sobre FortiGate, dimensionado antes de tocar nada.
Alcance fijo. Dos semanas. El cambio que necesitas — hardening, SD-WAN, SAML a Entra, upgrade de FortiOS o migración — elegido en la evaluación inicial. Auditoría previa, ensayo en lab, ejecución y una semana de soporte post-compromiso. Runbook y templates de configuración incluidos.
- Sprint de 2 semanas
- Producción FortiOS 7.4 / 7.6
- Runbooks bilingües · ES o EN
La mayoría de los shops con FortiGate están sentados sobre la misma forma del mismo problema: un equipo único o un cluster HA que acumuló cinco años de drift de políticas, tres proyectos a medio terminar y un ticket abierto que el equipo está esperando cerrar antes de empezar el próximo. No necesitan otro vendor; necesitan a alguien senior en el teclado durante dos semanas que pueda decidir qué se queda, qué se va y cómo se ve el rollback.
Este es ese compromiso. Dos semanas, alcance fijo, dimensionado en la evaluación inicial contra tu entorno real.
Qué recibes
- Auditoría pre-compromiso · configuración actual exportada, versión + hardware confirmados, dependencias mapeadas. La auditoría llega al cierre de la Semana 1 incluso si la ventana de cambio se corre a la Semana 2.
- Diseño del cambio · diseño escrito cubriendo el alcance que elegiste. Mismo template entre tipos de compromiso — contexto, decisiones, alternativas que rechazamos, qué tocamos y qué no.
- Ensayo en lab · cambios aplicados a un setup de prueba representativo antes de tocar producción. Pre-checks, el cambio mismo, post-validación — todo ensayado.
- Ventana de ejecución · estamos en la llamada de bridge durante el cambio. Tus ingenieros corren los comandos; nosotros estamos ahí para atrapar lo que el ensayo no haya sacado a la luz. Ventana fuera de horario si involucra cutover.
- Una semana de soporte post-compromiso · días hábiles en horario laboral, Slack o email. Casos borde, preguntas de seguimiento, ruido de monitoreo que necesita interpretación.
- Runbook + templates de configuración · escrito para que un ingeniero Tier 2 pueda re-correr el mismo cambio en el próximo sitio sin re-contratarnos. El runbook es parte del entregable, no un detalle.
Formas comunes de compromiso
Eliges una en la evaluación inicial. La forma de 2 semanas se mantiene; el contenido se llena:
- Pase de hardening · revisión de configuración contra baselines de FortiOS 7.4 / 7.6. Postura de acceso administrativo, logging, cobertura de tier de FortiGuard, higiene de políticas, postura del SSL VPN si sigue habilitado. Los fixes principales se implementan durante el compromiso.
- Bring-up de SD-WAN · de WAN único a multi-WAN con health checks sensatos, reglas de traffic steering, identificación de aplicaciones y comportamiento de failover que puedas describirle a tu CFO.
- Integración SAML + Entra ID · SSO para acceso administrativo del FortiGate, auth del VPN, o ambos. Políticas de Conditional Access del lado de Entra alineadas con la postura del FortiGate.
- Upgrade de FortiOS · cruzando una barrera de versión mayor (7.2 → 7.4, 7.4 → 7.6). Revisión de breaking changes, pre-checks, ventana de upgrade, validación post-upgrade, plan de rollback.
- Integración FortiSwitch / FortiAP · agregando switches o APs administrados por FortiLink a un FortiGate existente. Diseño de VLANs, presupuesto de PoE, integración RADIUS / SAML cuando aplica.
- Modernización de VPN · SSL VPN a IKEv2 IPsec adelantándose a la deprecation de Fortinet, limpieza de IPsec site-to-site, o migración de PSK a auth por certificado. El checklist de migración de SSL VPN es la versión pública de este playbook.
Multi-firewall, multi-sitio, o proyectos que legítimamente necesitan más de dos semanas son otras formas — lo señalamos en la evaluación inicial.
Alcance
- Un FortiGate (dispositivo único o cluster HA) · hardware que soporta FortiOS 7.4 / 7.6 — las familias 60F / 100F / 200F y posteriores.
- Un cambio elegido de las formas arriba. Si tu entorno necesita dos de éstas a la vez, lo conversamos en la evaluación inicial — a veces es una extensión limpia, a veces son dos compromisos.
- Forma de auth se queda donde está salvo que el compromiso sea explícitamente la integración SAML / Entra. Migraciones de backend de autenticación en paralelo a otro cambio re-dimensionan el compromiso.
Cronograma — dos semanas, punta a punta
- Lun (Semana 1) · arranque. Acceso confirmado, configuración actual obtenida, versión + hardware confirmados.
- Mar–Mié (Semana 1) · auditoría + lock de alcance. Estado actual mapeado, dependencias en la superficie, diseño del cambio comprometido por escrito.
- Jue (Semana 1) · borrador del runbook. Secuencia paso a paso por CLI / GUI, pre-checks, checklist de validación, ruta de rollback. Borrador del runbook circulado para revisión.
- Vie (Semana 1) · ensayo en lab. Cambios aplicados a un setup de prueba representativo; pre-checks, el cambio mismo, post-validación ensayados. Runbook actualizado con base en lo que el ensayo haya sacado a la luz.
- Ventana de ejecución (Semana 2). Sábado en la noche si involucra cutover (modernización de VPN, upgrade de FortiOS); días hábiles en horario laboral si no (pase de hardening, integración FortiSwitch). Estamos en el bridge. Ventana típica: 2–4 horas incluyendo validación post-cambio.
- Lun–Vie (resto de la Semana 2) · soporte post-compromiso. Días hábiles en horario laboral. Casos borde, preguntas de seguimiento, ruido de monitoreo.
Si el ensayo saca algo material a la luz — una incompatibilidad de hardware descubierta, una dependencia load-bearing que nadie conocía — lo señalamos, re-dimensionamos honestamente, y seguimos o pausamos. Preferimos extender el cronograma a entregar un cambio a medio probar.
Cuándo aplica
- FortiGate en producción (dispositivo único o cluster HA) que necesita un cambio definido con ojos seniors.
- FortiOS 7.4 / 7.6 (o 7.2 con ruta de upgrade viable dentro del compromiso).
- Entorno mid-market donde el equipo es el equipo correcto para operar la caja a largo plazo, pero un cambio específico ha estado en el backlog suficiente tiempo como para que alguien externo lo haga.
- SMB de LATAM donde el equipo de red es una o dos personas y un par de manos seniors extras durante dos semanas destranca un trimestre de planificación.
Cuándo no aplica
- Decenas de FortiGates en muchos sitios donde el cambio necesita escalar — es un programa multi-compromiso (conversemos).
- Cisco, Palo Alto, SonicWall — no fingimos hacer esos a nivel producción.
- Despliegue de FortiGate desde cero — posible, pero la forma es más cercana a un proyecto que a un sprint. La página de consultoría cubre ese flujo.
- Compromisos puros de diseño o estrategia donde nada cambia realmente en producción. La auditoría (revisión de arquitectura de seguridad) es mejor punto de partida para eso.
Preguntas frecuentes
¿Cómo elegimos el alcance?
En la llamada de evaluación de 30 min. Recorremos tu entorno actual, qué ha estado en la lista, qué está bloqueando al equipo, cómo se ve la presión de deadlines. El alcance se cierra por escrito luego de la llamada. Si el alcance cambia a mitad del compromiso, re-dimensionamos por escrito también — sin drift sorpresa.
¿Se pueden combinar alcances — digamos, pase de hardening más integración SAML?
A veces. Combinaciones livianas funcionan (ej. pase de hardening que incluye la reescritura de configuración SAML). Combinaciones más pesadas (SD-WAN + upgrade de FortiOS) son realistamente dos compromisos consecutivos. Evaluación honesta en la llamada.
¿Hacen upgrade de FortiOS si hace falta?
Sí. Si el cambio que elegiste depende de un feature que entró en 7.4 o 7.6 y estás en una versión más vieja, el upgrade es parte del compromiso — pre-checks, ventana de upgrade, post-validación. No hacemos ese trabajo invisible — lo vas a ver en el documento de auditoría y en el runbook.
¿Cuál es el plan de rollback?
Escrito en el runbook, ensayado en el lab y sobre la mesa en la llamada de bridge durante la ventana de cambio. Las configs viejas no se borran durante la ejecución — se deshabilitan o se reemplazan con templates versionados. Si algo material se rompe post-cambio, restauramos servicio primero y re-dimensionamos el próximo intento. Restaurar + reintentar le gana a entregar igual.
¿Listos para dimensionarlo? Evaluación gratuita de 30 min ↑ o escribe directo a cflores@packetloss.tech.