Apagón de internet en Irán: lecciones de resiliencia y continuidad para equipos de infraestructura y seguridad

La caída masiva de conectividad en Irán durante seis días expone riesgos técnicos que también afectan a empresas: dependencia de rutas internacionales, fragilidad de autenticación remota y falta de planes de operación degradada.

La interrupción casi total de internet en Irán durante varios días volvió a poner sobre la mesa un escenario que muchos equipos de infraestructura consideran “improbable”, pero que en realidad es cada vez más relevante: la pérdida sostenida de conectividad internacional en medio de una crisis.

Aunque el caso tiene un contexto geopolítico específico, las implicancias técnicas trascienden fronteras. Cuando una red nacional cae al 1-2% de tráfico habitual, no solo se afecta la comunicación civil: también se rompen dependencias de autenticación, monitoreo, telemetría, CDN, DNS externos, proveedores SaaS y flujos de soporte remoto.

Para equipos SysAdmin, DevOps y Seguridad, el aprendizaje clave es claro: no alcanza con tener “alta disponibilidad” en condiciones normales. Hace falta diseñar para operación degradada real.

Qué pasó y por qué importa técnicamente

Distintos observatorios de conectividad reportaron una caída abrupta del tráfico en Irán a partir del 28 de febrero. NetBlocks, Cloudflare Radar e IODA mostraron una reducción extrema de visibilidad y salida internacional, con patrones compatibles con un corte a escala país.

Este tipo de apagón no siempre implica “internet totalmente apagada”. En muchos casos persiste una intranet nacional o redes con lista blanca, donde ciertos servicios internos siguen funcionando. El problema operativo es que la mayoría de los entornos empresariales modernos dependen, en mayor o menor medida, de componentes externos:

• IdP y MFA en la nube
• Repositorios de paquetes y artefactos
• APIs de terceros
• Consolas de observabilidad administradas
• Servicios de correo y mensajería SaaS
• Integraciones CI/CD distribuidas

Cuando esas dependencias quedan inaccesibles, los runbooks clásicos suelen quedarse cortos.

Riesgos operativos inmediatos para organizaciones

1) Bloqueo de acceso administrativo

Si bastiones, VPN o consolas requieren validación en servicios externos, el acceso privilegiado puede quedar bloqueado justo cuando más se necesita. Este riesgo crece en arquitecturas con MFA estrictamente online y sin modos de contingencia.

2) Pérdida de observabilidad útil

Muchas organizaciones centralizan logs, métricas y trazas en plataformas cloud fuera de su región. Ante un corte internacional, “la ceguera” operacional llega rápido: no hay paneles, no hay alertas, no hay evidencia para responder incidentes.

3) Fallas en cadena de suministro de software

Builds y despliegues pueden depender de registries públicos, mirrors externos o validaciones remotas. Sin cache local ni repositorios internos, la entrega continua se detiene.

4) Degradación de comunicaciones de crisis

Canales de coordinación (chat corporativo, ticketing SaaS, correo externo) pueden volverse intermitentes o directamente inalcanzables. Sin un plan B local, el tiempo de respuesta se multiplica.

5) Exposición por uso de bypass no controlados

En eventos de bloqueo prolongado, usuarios y equipos tienden a improvisar túneles, VPN alternativas o herramientas no aprobadas. Eso abre una superficie nueva para fuga de datos, malware y pérdida de trazabilidad.

Cinco controles que conviene priorizar ahora

1) Definir un modo “degradado” explícito

No es suficiente un DR tradicional orientado a caída de datacenter. Se necesita un plan para pérdida parcial o total de internet internacional. Debe incluir: qué servicios son críticos, qué componentes pueden operar offline y qué funciones se suspenden temporalmente.

2) Revisar identidad y acceso para contingencia

Implementar mecanismos de acceso de emergencia auditables: cuentas break-glass, tokens de respaldo, métodos de MFA alternativos y procedimientos aprobados para operar sin dependencia continua del IdP externo.

3) Localizar capacidades mínimas de observabilidad

Mantener un stack local (aunque sea reducido) para logs de seguridad, métricas de infraestructura y eventos críticos. El objetivo no es reemplazar la plataforma central, sino sostener visibilidad durante la disrupción.

4) Fortalecer repositorios internos y cachés

Para entornos DevOps, es clave contar con mirrors internos de paquetes base, imágenes de contenedor y dependencias de build. Sin esto, cualquier corte externo detiene pipelines y parches urgentes.

5) Diseñar comunicaciones resilientes

Establecer canales alternativos de coordinación dentro de la red local (wiki offline, mensajería interna, telefonía de contingencia, árbol de escalamiento). La comunicación debe sobrevivir incluso si los servicios SaaS no responden.

Cómo traducirlo a un plan de 72 horas

Un enfoque práctico para equipos técnicos es trabajar en tres etapas:

• **Primeras 24 horas:** inventario de dependencias externas críticas (identidad, DNS, monitoreo, CI/CD, soporte remoto).
• **48 horas:** pruebas controladas de operación degradada (simular pérdida de salida internacional en un entorno de staging).
• **72 horas:** actualización de runbooks, definición de owners y ejecución de un ejercicio corto de mesa con infraestructura, seguridad y operaciones.

Este enfoque reduce improvisación y permite detectar fallas de diseño antes de un evento real.

Conclusión

El apagón en Irán no es solo una noticia internacional: es un recordatorio técnico sobre la fragilidad de arquitecturas demasiado dependientes de conectividad global continua. Para SysAdmin, DevOps y Seguridad, la pregunta no es si habrá una próxima interrupción severa, sino qué tan preparada está la operación para sostener servicios críticos cuando internet deja de comportarse como “siempre disponible”.

La mejor respuesta no pasa por alarmismo, sino por ingeniería: dependencias mapeadas, contingencias probadas y procedimientos ejecutables bajo presión.

Acciones recomendadas

1. Mapear hoy las 10 dependencias externas que detendrían su operación.
2. Implementar al menos un mecanismo de acceso administrativo de emergencia auditado.
3. Garantizar telemetría mínima local para incidentes de seguridad.
4. Crear un runbook de “operación sin internet internacional” y validarlo con simulación.
5. Repetir el ejercicio trimestralmente con métricas de tiempo de recuperación.

Fuente principal: https://therecord.media/iran-internet-outage-israel-war