L'apany era apagar Global Secure Access: el consell que la teva pròpia política bloqueja

A les 18:20 UTC del 13 d'octubre, amb la incidència a punt de fer onze hores, la cronologia registra un apany per als afectats: apagar GSA. Onze minuts després, a les 18:31, es va donar la incidència per acabada, així que a efectes pràctics aquell consell no va arribar a temps per a gairebé ningú. Però val la pena aturar-s'hi, perquè hi ha una part dels desplegaments on no es pot seguir: exactament els que estan muntats com la documentació del mateix fabricant recomana muntar-los.

Què va passar el 13 d'octubre

Des de les 07:40 fins a les 18:31 UTC —10 h 51 m— els usuaris de Microsoft 365 que sortien per Global Secure Access no podien fer servir Outlook, Outlook al web, OneDrive, SharePoint Online, Teams ni els Cloud PC de Windows 365. L'abast inicial incloïa el Regne Unit i Alemanya; a partir de les 17:26 UTC es va reduir a Alemanya. A les actualitzacions intermèdies la causa apareix descrita com que «a section of GSA infrastructure is performing below acceptable performance thresholds», i la mitigació va ser redirigir trànsit fora d'aquella infraestructura i reiniciar-la per parts.

Convé dir què no va ser: no va ser una caiguda de Microsoft 365. Els serveis estaven aixecats i per a la resta del món funcionaven. El que estava degradat era el camí. Global Secure Access és la capa d'accés de Microsoft: un agent al portàtil captura el trànsit i l'envia al núvol d'Entra, on s'aplica política abans que arribi a destinació. És, gairebé paraula per paraula, el que venem nosaltres quan diem Zero Trust: deixa de refiar-te de quina xarxa fa servir l'usuari i refia't de la identitat i del camí pel qual ve.

La casella que converteix el camí en obligatori

A sobre d'aquest camí s'hi munta un control que es diu comprovació de xarxa conforme (compliant network check). En activar-lo, Accés Condicional guanya una ubicació anomenada All Compliant Network locations, i la documentació descriu per a què serveix: «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 d'exemple que la mateixa pàgina detalla pas a pas diu: tots els usuaris, tots els recursos, xarxa «qualsevol ubicació» excloent-ne les conformes, i la concessió és bloquejar l'accés. Traduït: si no véns per aquí, no entres enlloc.

El control no és un adorn. Està pensat contra el robatori i la reutilització de token, que és de les poques coses que deixen sense efecte un MFA ben posat. Entra ID «performs authentication plane enforcement at the time of user authentication», i si algú roba un token de sessió i el reutilitza des d'un equip que no és a la xarxa conforme, «Microsoft Entra ID immediately denies the request and blocks further access». Amb Avaluació Contínua d'Accés, a més, el rebuig passa també al pla de dades «in near-real time». És un bon control i nosaltres el recomanem. Aquest post no va de treure'l.

La mateixa pàgina documenta el bloqueig com a prova d'èxit

Al final d'aquesta pàgina hi ha un apartat titulat Try your compliant network policy. Són tres passos, i els dos últims són els que importen: amb el client funcionant, obre una aplicació del tenant; després, «pause the Global Secure Access client by right-clicking the application in the Windows tray and selecting Disable»; i llavors, en intentar entrar en una altra aplicació, «Microsoft Entra ID Conditional Access blocks your access». La captura que acompanya el pas mostra el missatge: You can't access this right now.

És a dir: apagar el client i quedar-te fora és la comprovació documentada que la política està ben posada. El que el dia 13 s'oferia com a sortida d'emergència és, al manual del mateix fabricant, el criteri d'èxit del control.

Les dues frases són correctes i no es contradiuen: parlen de tenants diferents. Qui tingui Global Secure Access desplegat sense política de xarxa conforme apaga el client i torna a treballar. Qui la tingui apaga el client i veu el missatge de la captura. La diferència entre tots dos no és la mida de l'empresa ni el pressupost: és una casella que algú va marcar un dia perquè algú —potser nosaltres— l'hi va recomanar. I saber en quin dels dos grups ets no s'esbrina mirant un tauler d'estat, s'esbrina mirant una política.

Qui es queda fora, i quan

El bloqueig no cau alhora sobre tothom, i la documentació ho acota amb honestedat: «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». L'esglaó, per tant, és irregular:

• Qui tenia l'Outlook obert des d'abans de les 07:40 pot continuar treballant una estona, i per això et dirà que a ell li va bé.
• Qui va reiniciar, qui va arribar més tard, qui va canviar d'equip o qui va obrir el portàtil a les nou necessita un inici de sessió nou. Comprovació nova, bloqueig.
• Els Cloud PC de Windows 365, que eren a la llista d'afectats, no són una pestanya que ja tinguessis oberta: cada connexió arrenca autenticant-se.

La mateixa pàgina dóna una xifra que ajuda a acotar aquesta gràcia, encara que cal llegir-la amb compte: parlant d'un token robat sense Avaluació Contínua d'Accés, diu que la seva vida per defecte és «between 60 and 90 minutes». No és el sostre de la teva sessió d'aplicació, que pot durar més; és l'ordre de magnitud amb què convé raonar. Contra una incidència de 10 h 51 m és molt difícil que una sessió oberta arribi al final sense demanar un inici de sessió nou. I hi ha una ironia operativa que convé mirar de cara: als serveis integrats que admeten CAE, el rebuig es juga a més al pla de dades gairebé en temps real. Com més ben configurat ho tinguis, abans et quedes fora. Quant abans, exactament, depèn de la teva configuració; no hi ha cap número que valgui per a tothom.

El procediment bo existeix, i el va escriure Microsoft al març

Aquí és on convé ser justos amb el fabricant, perquè nosaltres mateixos anàvem a escriure una seqüència d'emergència pròpia i resulta que ja està publicada. Microsoft té dues pàgines, datades el 16 de març de 2026, amb sengles guions de PowerShell: una titulada Disable traffic forwarding and disable Conditional Access policies using the compliant network condition in a break glass scenario, i una altra de recuperació. El text és explícit: «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».

L'interessant no és que existeixi: és en quin ordre fa les coses, perquè l'ordre no és l'intuïtiu. El guió d'emergència busca totes les polítiques d'Accés Condicional que fan servir la ubicació de xarxa conforme —les localitza per un identificador fix, 3d46dbda-8382-466a-856d-eb00cbc6b910, que és el mateix a tots els tenants—, les passa a mode només informe i després deshabilita els perfils de reenviament. El de recuperació fa justament el contrari: primer torna a habilitar els perfils, i després les polítiques. I tots dos comencen amb el mateix advertiment a la capçalera: cal executar-los des d'«an Entra ID emergency access admin account, not subject to Microsoft Entra Internet Access Compliant Network policy».

Aquest ordre té un motiu, i l'avís en caixa de la pàgina de la política ho diu per a un cas veí —desactivar la senyalització de GSA a Accés Condicional, que és un interruptor diferent de desmarcar els perfils de trànsit—: «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 interruptors diferents, una mateixa lliçó: si treus el camí abans que la política, deixes la gent fora tu mateix.

El que els guions no et diuen: el rellotge

Els dos guions fan la seva feina en segons i acaben dient-te que ha anat bé. El que no apareix en cap dels dos és quant triga cada pas a arribar al portàtil de la teva gent, i aquí hi ha un número que convé saber de memòria. És a la guia de diagnòstic del client, la mateixa que documenta l'estat anomenat literalment 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»— i diu així: «the Global Secure Access client should receive the updated forwarding profile within one hour after you make changes in the portal».

Fins a una hora des que executes el guió fins que el portàtil se n'assabenta. Per a una caiguda d'onze hores, arriba a temps. Per a una de vint minuts, arribes tu després que l'incident. I a la tornada, la mateixa hora un altre cop: si reactives les polítiques abans que els clients hagin recuperat el perfil, repeteixes la caiguda tu mateix i ja sense culpa de ningú. Això no és en cap guió, perquè un guió no sap esperar: ho has de saber tu, i tenir-ho escrit al costat del pas.

La seqüència amb rellotge

Això no és una llista de bones pràctiques ni una seqüència nostra: són els passos del guió oficial, en el seu ordre, amb el rellotge de cadascun al costat. La columna de la dreta és l'únic que hi posem nosaltres, i és el que converteix un guió en un procediment. Mitja pàgina, allà on sigui el procediment d'incidents.

I una exclusió que no neix d'aquest incident però es cobra el mateix dia: si la teva organització enrola dispositius a Intune, la documentació recomana excloure de la política les aplicacions Microsoft Intune Enrollment i Microsoft Intune «to avoid a circular dependency». El portàtil nou que algú intenta enrolar justament aquell matí necessita aquesta excepció escrita d'abans, perquè durant l'incident no hi ha manera elegant d'escriure-la.

El que no estem dient

• No vam tenir clients afectats i no tenim telemetria pròpia d'aquest incident. Tot el que hi ha a dalt surt de la cronologia publicada i de la documentació del fabricant; l'avís original només es veu des de dins del tenant afectat.
• No estem dient que treguis la comprovació de xarxa conforme. Fa el que promet, el robatori de token és un problema seriós i hi ha poquíssim que el freni igual de bé. La continuarem recomanant.
• Tampoc que el fabricant no ho tingués previst: ho tenia, amb procediment i dos guions, des del març. Nosaltres anàvem a escriure la seqüència des de zero i ens la vam trobar publicada; ho diem perquè la troballa útil per a tu és que aquelles dues pàgines existeixen.
• El que sí que diem: un control que depèn d'un camí converteix la salut d'aquell camí en una dependència de la teva capacitat de treballar. Això no és motiu per no posar-lo. És motiu per escriure, el dia que el poses, el procediment de treure'l.

Hi ha un patró aquí que ja ens hem trobat dues vegades aquest mes. Escrivíem fa unes setmanes que les polítiques d'accés condicional que no vas escriure ja són al teu tenant, posades pel fabricant i no per tu; i després de la caiguda d'Azure, que l'important no eren les quatre portes i el lloc on guardaves el pla B. Les tres vegades el problema no és la fallada: és que la peça que t'havia de salvar viu dins d'allò que ha fallat. Un control d'accés que exigeix un camí, un pla B guardat darrere del pla A, una política que no vas escriure. La pregunta bona no és «què passa si cau?», és «per on hi entro a arreglar-ho quan caigui?».

Fonts (consultades el 15-10-2026): les hores 07:40–18:31 UTC del 13 d'octubre de 2026, la durada de 10 h 51 m, la llista de serveis afectats, l'estrenyiment de l'abast a Alemanya a les 17:26, la frase sobre la infraestructura per sota del llindar i l'apany de les 18:20 surten de la cronologia que IncidentHub reconstrueix a partir de la pàgina d'estat de Microsoft. Precisió que ens importa: l'entrada d'aquella cronologia diu «workaround suggested to users to turn off GSA», sense més; no hem vist l'avís original —només és visible des de dins del tenant afectat— així que no posem cap frase en boca de Microsoft. Els onze minuts de diferència amb el tancament els assenyala la mateixa pàgina. La incidència va ser coberta també per Neowin i The Register. La comprovació de xarxa conforme, la política d'exemple, l'exclusió de comptes d'emergència i d'Intune, l'apartat «Try your compliant network policy» amb el pas de Disable, la nota sobre sessions ja iniciades, els 60–90 minuts del token i l'avís sobre l'ordre en desactivar la senyalització són a «Enable Compliant Network Check with Conditional Access» de Microsoft Learn. El break-glass mode i el termini d'una hora perquè el client rebi el perfil de reenviament, a la guia de diagnòstic del client Windows. El procediment d'emergència, el seu ordre, l'identificador de la ubicació i el requisit de compte d'accés d'emergència, als dos guions de PowerShell del 16 de març de 2026: el de break glass i el de recuperació. El que és nostre, i ho acotem: la lectura de l'apany del dia 13 contra l'apartat de prova de la documentació, i la columna del rellotge —els «fins a una hora» posats al costat de cada pas—, que no apareix en cap dels dos guions. La seqüència en si no és nostra: és la del fabricant.