En seguridad de la información insistimos mucho en la confidencialidad y la integridad. Pero la disponibilidad, la tercera pata de la tríada CIA, suele quedar en segundo plano hasta que falla y un equipo completo deja de poder trabajar.

Este caso real, documentado a partir de trazas de un proxy Symantec ProxySG, muestra cómo un control de seguridad legítimo puede convertirse en un incidente de disponibilidad por una mala configuración o un cambio que no se propagó.

El síntoma

Un área de diseño reportó que algunas herramientas de edición creativa en la nube, entre ellas Adobe Express y Adobe Firefly, dejaban de reproducir video y audio de forma intermitente. La navegación general funcionaba y el inicio de sesión también, pero los elementos multimedia no cargaban.

Desde una red externa sin restricciones corporativas todo funcionaba bien. Eso apuntaba de inmediato a la infraestructura de red como origen del fallo.

La investigación

El diagnóstico se basó en varias capturas de política (policy trace) del proxy, analizando transacción por transacción:

  1. Se descartó la inspección SSL. El equipo afectado navegaba en túnel, sin descifrado de HTTPS. Por eso ninguna regla de manipulación de contenido podía ser la causa, como el recorte de cabeceras Range, que es clave para reproducir video.
  2. Se descartó la política de categorías por grupo. El equipo no pertenecía al grupo con reglas para herramientas de IA generativa. Aun así, los dominios principales de Adobe quedaban permitidos por su categorización general.
  3. El hallazgo real apareció al filtrar por veredicto. Varias conexiones hacia ftcdn.net, el dominio que usa Adobe Stock como CDN para servir los archivos de video y audio de su biblioteca, terminaban en EXCEPTION(tcp_error), con cero bytes transferidos y una duración de exactamente 300 segundos.

Ese número no era casualidad. El dominio resuelve a cuatro direcciones IP distintas detrás de una misma CDN, y el proxy esperaba 75 segundos contra cada una antes de rendirse: 

ftcdn.net → 4 IP × 75 s de timeout = 300 s → EXCEPTION(tcp_error), 0 bytes

En otras palabras, la página, el editor y la sesión cargaban, pero el archivo de video nunca llegaba porque la conexión hacia las IP de esa CDN no se completaba.

La causa raíz

La resolución DNS era correcta: el servidor interno devolvía las mismas IP que un DNS público, así que no era un problema de nombres. El patrón apuntaba a un bloqueo de red (firewall, IPS o falta de ruta) hacia ese rango de direcciones específico de ftcdn.net.

La causa probable era un geobloqueo o una categorización de "streaming/CDN" que no coincidía con una excepción ya aplicada a otros dominios de Adobe.

Por qué esto importa para la disponibilidad

  • Un solo dominio bloqueado puede inutilizar un servicio completo. Las plataformas SaaS modernas dependen de decenas de subdominios y CDN para la interfaz, la autenticación, la telemetría y los medios. Basta con que uno quede fuera de la lista blanca para que la experiencia se rompa de forma parcial y confusa. En este caso adobe.com estaba permitido, pero ftcdn.net no estaba en el radar. Es un dominio heredado de Fotolia, la empresa que Adobe compró en 2014 y que hoy es la base de Adobe Stock, y su nombre no hace ninguna referencia a "Adobe".
  • Los timeouts tienen un costo real. Cuatro intentos de 75 segundos dan una mala experiencia, cargan las conexiones del proxy y hacen que el problema parezca "lentitud" en lugar de "bloqueo". Eso retrasa el diagnóstico.
  • Las excepciones se mantienen por ecosistema, no por dominio aislado. Permitir el dominio principal de un proveedor no garantiza que todos sus dominios auxiliares queden cubiertos por la misma política. Muchos vienen de adquisiciones corporativas.

La lección operativa

Cuando investigas una caída de disponibilidad en un servicio en la nube, no basta con confirmar que el dominio principal está permitido. Hace falta:

  • Capturar tráfico en el momento exacto del fallo y filtrar por veredicto (denegado, excepción, error), en lugar de asumir que "si el sitio carga, todo funciona".
  • Mapear todos los subdominios y CDN reales que usa la aplicación; en este caso, ftcdn.net junto a adobe.com y adobe.io. Lo ideal es comparar una sesión desde una red sin restricciones con otra desde la red corporativa.
  • Tratar los tiempos anómalos como pista. Una duración que es múltiplo exacto del timeout configurado es una pista de diagnóstico, no solo un síntoma de lentitud.
  • Recordar que el exceso de control también rompe la disponibilidad. Un proxy que protege la confidencialidad y la integridad puede ser, al mismo tiempo, el punto único de falla que frena a un área completa.
En resumen: la seguridad perimetral bien diseñada no es la que bloquea más, sino la que entiende con precisión qué debe pasar y por qué, para no convertirse ella misma en el incidente.

¿Tienes un servicio en la nube que "carga a medias" detrás del proxy? Escríbeme y lo revisamos juntos.