El apaño era apagar Global Secure Access: el consejo que tu propia política bloquea

A las 18:20 UTC del 13 de octubre, con la incidencia a punto de cumplir once horas, la cronología registra un apaño para los afectados: apagar GSA. Once minutos después, a las 18:31, se dio la incidencia por terminada, así que a efectos prácticos ese consejo no llegó a tiempo para casi nadie. Pero vale la pena pararse en él, porque hay una parte de los despliegues donde no se puede seguir: exactamente los que están montados como la documentación del propio fabricante recomienda montarlos.

Qué pasó el 13 de octubre

Desde las 07:40 hasta las 18:31 UTC —10 h 51 m— los usuarios de Microsoft 365 que salían por Global Secure Access no podían usar Outlook, Outlook en web, OneDrive, SharePoint Online, Teams ni los Cloud PC de Windows 365. El alcance inicial abarcaba Reino Unido y Alemania; a partir de las 17:26 UTC se redujo a Alemania. En las actualizaciones intermedias la causa aparece descrita como que «a section of GSA infrastructure is performing below acceptable performance thresholds», y la mitigación fue redirigir tráfico fuera de esa infraestructura y reiniciarla por partes.

Conviene decir qué no fue: no fue una caída de Microsoft 365. Los servicios estaban levantados y para el resto del mundo funcionaban. Lo que estaba degradado era el camino. Global Secure Access es la capa de acceso de Microsoft: un agente en el portátil captura el tráfico y lo envía a la nube de Entra, donde se aplica política antes de que llegue al destino. Es, casi palabra por palabra, lo que vendemos nosotros cuando decimos Zero Trust: deja de fiarte de en qué red está el usuario y fíate de la identidad y del camino por el que viene.

La casilla que convierte el camino en obligatorio

Encima de ese camino se monta un control que se llama comprobación de red conforme (compliant network check). Al activarlo, Acceso Condicional gana una ubicación llamada All Compliant Network locations, y la documentación describe para qué sirve: «ensures users connect through the Global Secure Access service for their specific tenant and are compliant with security policies enforced by administrators». La política de ejemplo que la propia página detalla paso a paso dice: todos los usuarios, todos los recursos, red «cualquier ubicación» excluyendo las conformes, y la concesión es bloquear el acceso. Traducido: si no vienes por ahí, no entras a nada.

El control no es un adorno. Está pensado contra el robo y la reutilización de token, que es de lo poco que deja sin efecto a un MFA bien puesto. Entra ID «performs authentication plane enforcement at the time of user authentication», y si alguien roba un token de sesión y lo reutiliza desde un equipo que no está en la red conforme, «Microsoft Entra ID immediately denies the request and blocks further access». Con Evaluación Continua de Acceso, además, el rechazo ocurre también en el plano de datos «in near-real time». Es un buen control y nosotros lo recomendamos. Este post no va de quitarlo.

La misma página documenta el bloqueo como prueba de éxito

Al final de esa página hay un apartado titulado Try your compliant network policy. Son tres pasos, y los dos últimos son los que importan: con el cliente funcionando, abre una aplicación del tenant; después, «pause the Global Secure Access client by right-clicking the application in the Windows tray and selecting Disable»; y entonces, al intentar entrar en otra aplicación, «Microsoft Entra ID Conditional Access blocks your access». La captura que acompaña al paso muestra el mensaje: You can't access this right now.

Es decir: apagar el cliente y quedarte fuera es la comprobación documentada de que la política está bien puesta. Lo que el día 13 se ofrecía como vía de escape es, en el manual del mismo fabricante, el criterio de éxito del control.

Las dos frases son correctas y no se contradicen: hablan de tenants distintos. Quien tenga Global Secure Access desplegado sin política de red conforme apaga el cliente y vuelve a trabajar. Quien la tenga apaga el cliente y ve el mensaje de la captura. La diferencia entre los dos no es el tamaño de la empresa ni el presupuesto: es una casilla que alguien marcó un día porque alguien —puede que nosotros— se lo recomendó. Y saber en cuál de los dos grupos estás no se averigua mirando un panel de estado, se averigua mirando una política.

Quién se queda fuera, y cuándo

El bloqueo no cae a la vez sobre todo el mundo, y la documentación lo acota con honestidad: «if you're already signed in to an application, access isn't interrupted»; Entra «reevaluates the Compliant Network check the next time sign-in is required, when your application session expires». El escalón, por tanto, es irregular:

• Quien tenía Outlook abierto desde antes de las 07:40 puede seguir trabajando un rato, y por eso te dirá que a él le va bien.
• Quien reinició, quien llegó más tarde, quien cambió de equipo o quien abrió el portátil a las nueve necesita un inicio de sesión nuevo. Comprobación nueva, bloqueo.
• Los Cloud PC de Windows 365, que estaban en la lista de afectados, no son una pestaña que ya tuvieras abierta: cada conexión arranca autenticándose.

La misma página da una cifra que ayuda a acotar esa gracia, aunque hay que leerla con cuidado: hablando de un token robado sin Evaluación Continua de Acceso, dice que su vida por defecto está «between 60 and 90 minutes». No es el techo de tu sesión de aplicación, que puede durar más; es el orden de magnitud con el que conviene razonar. Contra una incidencia de 10 h 51 m es muy difícil que una sesión abierta llegue al final sin pedir un inicio de sesión nuevo. Y hay una ironía operativa que conviene mirar de frente: en los servicios integrados que soportan CAE, el rechazo se juega además en el plano de datos casi en tiempo real. Cuanto mejor configurado lo tengas, antes te quedas fuera. Cuánto antes, exactamente, depende de tu configuración; no hay un número que valga para todos.

El procedimiento bueno existe, y lo escribió Microsoft en marzo

Aquí es donde conviene ser justos con el fabricante, porque nosotros mismos íbamos a escribir una secuencia de emergencia propia y resulta que ya está publicada. Microsoft tiene dos páginas, fechadas el 16 de marzo de 2026, con sendos guiones de PowerShell: una titulada Disable traffic forwarding and disable Conditional Access policies using the compliant network condition in a break glass scenario, y otra de recuperación. El texto es explícito: «temporarily disabling traffic forwarding profiles and disabling the Compliant Network condition policies can help your users regain access to their Microsoft apps in favor of productivity».

Lo interesante no es que exista: es en qué orden hace las cosas, porque el orden no es el intuitivo. El guion de emergencia busca todas las políticas de Acceso Condicional que usan la ubicación de red conforme —las localiza por un identificador fijo, 3d46dbda-8382-466a-856d-eb00cbc6b910, que es el mismo en todos los tenants—, las pasa a modo solo informe y después deshabilita los perfiles de reenvío. El de recuperación hace justo lo contrario: primero vuelve a habilitar los perfiles, y luego las políticas. Y los dos empiezan con la misma advertencia en la cabecera: hay que ejecutarlos desde «an Entra ID emergency access admin account, not subject to Microsoft Entra Internet Access Compliant Network policy».

Ese orden tiene un motivo, y el aviso en caja de la página de la política lo dice para un caso vecino —desactivar la señalización de GSA en Acceso Condicional, que es un interruptor distinto de desmarcar los perfiles de tráfico—: «if your organization has active Conditional Access policies based on compliant network check, and you later disable Global Secure Access signaling in Conditional Access, you might unintentionally block targeted end users from accessing the resources. If you must disable this feature, first delete any corresponding Conditional Access policies». Dos interruptores diferentes, una misma lección: si quitas el camino antes que la política, dejas a la gente fuera tú mismo.

Lo que los guiones no te dicen: el reloj

Los dos guiones hacen su trabajo en segundos y terminan diciéndote que ha ido bien. Lo que no aparece en ninguno de los dos es cuánto tarda cada paso en llegar al portátil de tu gente, y ahí hay un número que conviene saberse de memoria. Está en la guía de diagnóstico del cliente, la misma que documenta el estado llamado literalmente break-glass mode —«break-glass mode prevents the Global Secure Access client from tunneling network traffic to the Global Secure Access cloud service. In break-glass mode, all traffic profiles in the Global Secure Access portal are unchecked and the Global Secure Access client isn't expected to tunnel any traffic»— y dice así: «the Global Secure Access client should receive the updated forwarding profile within one hour after you make changes in the portal».

Hasta una hora desde que ejecutas el guion hasta que el portátil se entera. Para una caída de once horas, llega a tiempo. Para una de veinte minutos, llegas tú después que el incidente. Y en la vuelta, la misma hora otra vez: si reactivas las políticas antes de que los clientes hayan recuperado el perfil, repites la caída tú mismo y ya sin culpa de nadie. Eso no está en ningún guion, porque un guion no sabe esperar: lo tienes que saber tú, y tenerlo escrito al lado del paso.

La secuencia con reloj

Esto no es una lista de buenas prácticas ni una secuencia nuestra: son los pasos del guion oficial, en su orden, con el reloj de cada uno al lado. La columna de la derecha es lo único que ponemos nosotros, y es lo que convierte un guion en un procedimiento. Media hoja, allá donde esté el procedimiento de incidentes.

Y una exclusión que no nace de este incidente pero se cobra el mismo día: si tu organización enrola dispositivos en Intune, la documentación recomienda excluir de la política las aplicaciones Microsoft Intune Enrollment y Microsoft Intune «to avoid a circular dependency». El portátil nuevo que alguien intenta enrolar justo esa mañana necesita esa excepción escrita de antes, porque durante el incidente no hay forma elegante de escribirla.

Lo que no estamos diciendo

• No tuvimos clientes afectados y no tenemos telemetría propia de este incidente. Todo lo de arriba sale de la cronología publicada y de la documentación del fabricante; el aviso original solo se ve desde dentro del tenant afectado.
• No estamos diciendo que quites la comprobación de red conforme. Hace lo que promete, el robo de token es un problema serio y hay poquísimo que lo frene igual de bien. La seguiremos recomendando.
• Tampoco que el fabricante no lo tuviera previsto: lo tenía, con procedimiento y dos guiones, desde marzo. Nosotros íbamos a escribir la secuencia desde cero y nos la encontramos publicada; lo decimos porque el hallazgo útil para ti es que esas dos páginas existen.
• Lo que sí decimos: un control que depende de un camino convierte la salud de ese camino en una dependencia de tu capacidad de trabajar. Eso no es motivo para no ponerlo. Es motivo para escribir, el día que lo pones, el procedimiento de quitarlo.

Hay un patrón aquí que ya nos hemos encontrado dos veces este mes. Escribíamos hace unas semanas que las políticas de acceso condicional que no escribiste ya están en tu tenant, puestas por el fabricante y no por ti; y tras la caída de Azure, que lo importante no eran las cuatro puertas y el sitio donde guardabas el plan B. Las tres veces el problema no es el fallo: es que la pieza que tenía que salvarte vive dentro de lo que ha fallado. Un control de acceso que exige un camino, un plan B guardado detrás del plan A, una política que no escribiste. La pregunta buena no es «¿qué pasa si se cae?», es «¿por dónde entro a arreglarlo cuando se caiga?».

Fuentes (consultadas el 15-10-2026): las horas 07:40–18:31 UTC del 13 de octubre de 2026, la duración de 10 h 51 m, la lista de servicios afectados, el estrechamiento del alcance a Alemania a las 17:26, la frase sobre la infraestructura por debajo del umbral y el apaño de las 18:20 salen de la cronología que IncidentHub reconstruye a partir de la página de estado de Microsoft. Precisión que nos importa: la entrada de esa cronología dice «workaround suggested to users to turn off GSA», sin más; no hemos visto el aviso original —solo es visible desde dentro del tenant afectado— así que no ponemos ninguna frase en boca de Microsoft. Los once minutos de diferencia con el cierre los señala la propia página. La incidencia fue cubierta también por Neowin y The Register. La comprobación de red conforme, la política de ejemplo, la exclusión de cuentas de emergencia y de Intune, el apartado «Try your compliant network policy» con el paso de Disable, la nota sobre sesiones ya iniciadas, los 60–90 minutos del token y el aviso sobre el orden al desactivar la señalización están en «Enable Compliant Network Check with Conditional Access» de Microsoft Learn. El break-glass mode y el plazo de una hora para que el cliente reciba el perfil de reenvío, en la guía de diagnóstico del cliente Windows. El procedimiento de emergencia, su orden, el identificador de la ubicación y el requisito de cuenta de acceso de emergencia, en los dos guiones de PowerShell del 16 de marzo de 2026: el de break glass y el de recuperación. Lo nuestro, y lo acotamos: la lectura del apaño del día 13 contra el apartado de prueba de la documentación, y la columna del reloj —los «hasta una hora» puestos al lado de cada paso—, que no aparece en ninguno de los dos guiones. La secuencia en sí no es nuestra: es la del fabricante.