Assegurar Microsoft 365 correctament: Conditional Access, excepcions de MFA i comptes break-glass en l'operativa diària

Qui vulgui assegurar correctament Microsoft 365 no pot prescindir de Conditional Access (polítiques dependents d’accés a Entra ID, abans Azure AD) i de l’autenticació multifactor (MFA, és a dir, l’accés amb almenys dos factors). En moltes empreses la MFA i les primeres regles de Conditional Access s’activen ràpidament —i és aleshores quan comença la feina: cal justificar les excepcions, organitzar els accessos d’emergència de manera neta i dissenyar els processos operatius perquè la seguretat no es converteixi en una allau de suport.

En la pràctica, “assegurar M365” rarament fracassa per la tècnica bàsica, sinó per problemes quotidians: comptes de servei per a interfícies, protocols legacy, personal extern sense cobertura mòbil fiable, administradors amb permisos massa amplis o un incident en què precisament la mesura de protecció bloqueja l’accés de l’equip TI. Aquest article situa com interactuen Conditional Access, excepcions MFA i comptes break-glass —i com operar-ho perquè segueixi sent fiable després del go-live.

Per què Conditional Access és la palanca —i per què la MFA sola no n’hi ha prou

La MFA redueix de manera notable el risc de contrasenyes robades, però no constitueix un concepte d’accés complet. Conditional Access (CA) decideix de forma contextual sota quines condicions s’autoritza un accés: p. ex. només des de dispositius gestionats, només des de països concrets, només amb avaluació basada en risc o només amb certes aplicacions client. Aquest és el pas decisiu cap al Zero Trust (model de seguretat en què no es confia en cap accés per defecte, sinó que es revisa contínuament).

Motius típics per què la MFA sola no és suficient a Microsoft 365:

• Token statt Passwort: L’autenticació moderna funciona amb tokens (bitllets d’accés amb validesa temporal). Un token robat pot eludir la MFA si CA no exigeix condicions addicionals (p. ex. l’estat del dispositiu o controls de sessió).
• Admin-Risiko: Els comptes administratius són especialment atractius. Sense regles CA per als accessos d’administrador (p. ex. només des d’estacions d’administrador o només amb MFA resistent al phishing) es manté oberta la major superfície d’atac.
• „Erlaubt“ ist zu breit: Si CA no diferencia entre aplicacions, classes de dades i tipus d’accés, la seguretat ràpidament queda o bé massa fluixa o bé massa RESTrictiva —ambdós casos generen problemes.

El nucli operatiu, doncs, és: CA com a capa de polítiques, MFA com a component dins d’aquesta, més una gestió neta d’excepcions i rutes d’emergència fiables.

Visió general d’arquitectura: què controla realment Conditional Access a Entra ID

Per a la direcció TI i l’operació és important no entendre CA com “una política” aïllada, sinó com una cadena de decisions. Entra ID avalua senyals en cada inici de sessió i aplica polítiques. Senyals rellevants són:

• Identität: Usuaris, grups, rols (p. ex. rols privilegiats com Global Administrator).
• Zielressource: Aplicació al núvol (Exchange Online, SharePoint/OneDrive, Teams, però també proveïdors externs a través d’Enterprise App).
• Client-Typ: Navegador, clients moderns, aplicacions mòbils, així com «Legacy Authentication» (protocols antics sense tokens moderns, p. ex. variants IMAP/POP/SMTP-Auth més antigues).
• Gerätezustand: «Compliant» oder «hybrid joined» (dispositiu gestionat, típicament via Intune o integració de domini amb estat del dispositiu).
• Netzwerk/Standort: Named Locations (rangs d’IP definits), països/regions, indicadors de risc.
• Sitzungsbedingungen: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (reavaluació contínua davant d’esdeveniments de risc).

Des del punt de vista operatiu, la qualitat de la vostra configuració de CA depèn en gran mesura de si aquests senyals són fiables. Una Named Location només és tan bona com la vostra higiene d’adreces IP. „Compliant“ només és tan bo com la gestió dels vostres dispositius i la definició de compliance. I l’avaluació de risc només és útil si també treballeu amb els esdeveniments que en deriven.

Protegir correctament Microsoft 365 amb Conditional Access: un conjunt de polítiques pràctic

En lloc d’una „große“ regla, en el dia a dia funciona millor un conjunt de poques polítiques ben delimitades. Això redueix els efectes secundaris i facilita la cerca d’errors durant un incident. Un patró bàsic provat consta de:

1) Baseline per a tots els usuaris: exigir MFA, bloquejar Legacy

Per als comptes d’usuari normals la baseline és: MFA obligatòria, i cal bloquejar la Legacy Authentication. Aquí, Legacy no vol dir „altmodisch“, sinó tècnicament problemàtic: aquests protocols sovint no admeten un repte MFA modern i per això són un punt d’entrada clàssic per a password spraying.

Important: no bloquegeu la Legacy „irgendwann“, sinó planifiqueu una fase de transició amb mesurament. Comproveu mitjançant els Sign-in Logs quins clients encara utilitzen Legacy. A les empreses sovint hi estan connectades impressores multifunció, funcions de Scan-to-Mail o clients de correu antics en entorns especials.

2) Admin-Policy: deutlich strenger als die Baseline

Els rols amb privilegis haurien de tenir la seva pròpia política: accés només des de dispositius d’administrador definits (p. ex. „compliant“ i, si escau, una estratègia separada de Admin-Workstation), MFA amb elevat nivell de seguretat (resistent al phishing, p. ex. FIDO2/Passkey o basat en certificats), i, si és possible, restriccions per a països/ubicacions d’alt risc. Encara que no totes les empreses implantin immediatament una arquitectura completa de Privileged Access (PAM, és a dir, gestió d’accés privilegiat), aquesta diferenciació ja compensa de seguida: un compte d’administrador compromès comporta un abast de danys diferent al d’un compte d’usuari compromès.

3) Policy für externe Zusammenarbeit und Gäste

Els accessos d’invitats (B2B Collaboration) sovint generen rutes de dades inesperades: els convidats descarreguen fitxers des de SharePoint, treballen a Teams o accedeixen a portals de projecte. Definiu aquí de manera conscient si els convidats només poden entrar amb MFA, si s’exclouen aplicacions concretes i quant de temps són vàlides les sessions. Per a treballs de projecte sovint és recomanable una durada de sessió més curta per reduir el risc de „vergessener Logins“.

4) Policy für sensible Datenpfade: Gerät oder Sitzung absichern

La pràctica requereix diferents nivells de protecció: un comercial potser pot llegir correus des de qualsevol dispositiu, però no hauria de poder descarregar grans volums de dades de SharePoint sense un dispositiu gestionat. Aquestes diferències no les resols amb un simple „erlaubt/verbietet“, sinó amb combinacions de CA: „accés permès si el dispositiu és compliant“ o „accés només via navegador amb sessió restringida“. Això és menys dràstic que un bloqueig complet – i alhora eficaç.

Excepcions MFA: on són realistes – i com controlar-les

Les excepcions a l’MFA no són un signe de feblesa sempre que estiguin dissenyades de manera conscient i controlades operativament. Sense excepcions controlades surten solucions paral·leles: els usuaris esquiven els processos, els Admins desactiven regles de manera precipitada i, al cap d’un temps, la col·lecció de polítiques ja no és coherent.

És important la distinció: una excepció a l’MFA rarament és „MFA aus“, sinó sovint „MFA anders“ o „accés només sota altres condicions“. Categories típiques d’excepcions:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Moltes solucions de programari properes als processos integren serveis M365: enviament d’e-mails, accés a calendaris, emmagatzematge de fitxers a SharePoint, notificacions de Teams o accessos a l’API Graph. Aquestes integracions no haurien de funcionar amb comptes d’usuari amb MFA desactivat. És preferible un accés tècnic mitjançant registres d’aplicacions (aplicació a Entra ID) amb permisos clars i un cicle de vida per secrets/certificats. Això no és una «excepció MFA», sinó una altra forma d’autenticació, més auditable.

Conseqüències operatives: cal rotar els secrets, els certificats caduquen i els permisos s’han de recertificar. Si planifiqueu integracions, definiu ownership (qui renova certificats/secrets) i monitoring (p. ex. alertes abans de la caducitat). Si no, una autenticació d’aplicació «sàvia» es pot convertir en una fallada no planificada.

Excepció 2: dispositius sense un inici de sessió modern (p. ex. escàner, impressora, sistemes de sala)

Aquí surten les discussions clàssiques sobre SMTP-Relay, Scan-to-Mail o bústies de sala. La solució equivocada gairebé sempre és «un compte d’usuari sense MFA». Millor optar per rutes tècniques que no depenguin d’un inici de sessió interactiu: un relay de correu centralitzat amb RESTricció d’IP, enfocaments basats en certificats o connectors, o bústies de sistema separades amb permisos molt RESTringits. El punt clau: el dispositiu no pot gestionar MFA per si mateix, per tant el disseny s’ha d’assegurar al nivell de transport i de la ruta de xarxa.

Excepció 3: operació d’emergència i accessibilitat RESTringida

El personal de camp, la producció o el treball per torns tenen situacions sense cobertura mòbil o sense dispositius mòbils privats. Val la pena pensar abans en mètodes alternatius de MFA: tokens hardware, claus de seguretat FIDO2, o Windows Hello for Business (inici de sessió lligat al dispositiu). «MFA temporalment desactivada» és operativament temptador, però escala malament i és difícil d’auditar.

Excepció 4: treballs automatitzats en context d’usuari

Alguns sistemes antics inicien treballs «com a usuari», per exemple per a pujades a SharePoint o informes. Això és arriscat des del punt de vista actual perquè barreja rols i drets d’accés. Si no es pot substituir immediatament, treballau amb mesures intermèdies: comptes de servei limitats, Named Locations clars, polítiques fortes de contrasenyes/secrets i registre exhaustiu. I: planifiqueu la migració cap a identitats d’aplicació com un paquet de treball propi, no com un «més endavant».

Com documentar, aprovar i eliminar excepcions

Les excepcions en operació només són acceptables si tenen un cicle de vida. En la pràctica, és útil un procediment lleuger que eviti la burocràcia però que sigui auditable:

1. Justificació en una frase: quina funció de negoci o operativa depèn d’això (p. ex. «Scan-to-Mail a la ubicació X»)?
2. Classificació tècnica: quina aplicació/protocols, quins comptes, quins camins de dades?
3. Controls compensatoris: què limita el risc (RESTricció d’IP, permisos mínims necessaris, monitoratge)?
4. Data de caducitat: cada excepció rep una data de revisió. Sense revisió s’elimina o se’n sol·licita una nova aprovació.
5. Propietari: qui és responsable si hi ha un problema o quan l’excepció expira?

Això no fa que les excepcions siguin «bones», però les fa gestionables. I precisament això és, en el dia a dia, la diferència entre una base de seguretat M365 robusta i un caos de polítiques.

Break-Glass-Accounts: accés d’emergència sense forat de seguretat

Els comptes Break-Glass són comptes d’emergència per accedir al Tenant quan els accessos d’administrador habituals no funcionen – per exemple per una mala configuració a Conditional Access, la fallada d’un proveïdor MFA o un incident d’identitat. L’objectiu és clar, però la implementació té trampes típiques: un compte Break-Glass que mai no es prova no serveix en cas d’emergència. Un compte Break-Glass massa fàcil d’accedir és una diana atractiva per a atacs.

Què no és Break-Glass

• No és un compte d’administrador diari: No s’ha d’utilitzar en l’operativa normal.
• No és un dipòsit d’excepcions: No substitueix un disseny de CA ben estructurat.
• No és «ja en tenim un, ja està bé»: Sense procés, proves i alertes només és un pla teòric.

Principis fonamentals per a Break-Glass en el funcionament

Una configuració pràctica s’orienta per tres objectius: accessible en cas d’emergència, difícil d’atacar en l’operativa normal, i fàcilment rastrejable.

• Com a mínim dos comptes: Redundància contra bloqueig, errors d’operació o credencials compromeses.
• Fortament assegurat: Contrasenyes llargues i aleatòries; sense reenviaments de correu; sense ús per a aplicacions o integracions.
• Exclòs de la CA de manera específica – però de manera limitada: Habitualment es concedeix una excepció a certes polítiques de CA perquè en cas d’emergència no quedis tancat fora per les teves pròpies regles. Al mateix temps han d’actuar altres mecanismes de seguretat: alertes en cas d’ús, assignació de rols RESTrictiva, emmagatzematge separat de les credencials d’accés.
• Registre i alertes: Cada inici de sessió ha d’activar un senyal immediat (SIEM/SOC o com a mínim una alerta per E‑mail/Teams a una bústia d’incidents). L’ús del Break-Glass és per definició un esdeveniment de seguretat.

Un punt central: decidiu conscientment si el Break-Glass es gestiona amb o sense MFA. Moltes organitzacions el deixen sense MFA per poder actuar en cas de fallada del MFA. Però aleshores els controls compensatoris han de ser especialment estrictes (emmagatzematge, accés a la contrasenya, alertes, rotació periòdica). Alternativament es pot dotar el Break-Glass d’un MFA basat en maquinari (p. ex. FIDO2) que sigui independent de la telefonia mòbil. L’important no és la «ideologia» correcta, sinó un camí d’emergència que funcioni de manera real en el vostre context.

Realitat del desplegament: com evitar bloqueigs i pics de suport

Molts desplegaments de CA/MFA no fracassen per motius tècnics, sinó per organitzatius: massa ràpids, massa extensos, sense telemetria i sense un procés de suport clar. Un desplegament estable treballa per onades i punts de mesura.

Pas 1: Crear visibilitat (abans de bloquejar)

Utilitzeu els Sign-in Logs i les anàlisis per determinar: Quines aplicacions s’utilitzen? Quins clients són «legacy»? Quines ubicacions/rangs d’IP són reals? Quins usuaris tenen més problemes d’inici de sessió? Sense aquestes dades, qualsevol política és un vol a cegues.

Pas 2: Grups pilot amb casos especials reals

Els pilots no haurien de ser només «IT i uns quants voluntaris». Incloeu deliberadament casos marginals: personal de camp, ubicacions de producció, membres de projectes amb accés de convidat i com a mínim un departament amb les eines habituals de tercers. L’objectiu no és l’harmonia, sinó trobar aviat els veritables entrebancs.

Pas 3: Establir playbooks per al helpdesk

Quan s’imposa MFA, augmenten les incidències: canvi de dispositiu, telèfons perduts, nous empleats, compte bloquejat després de massa intents. Defineixi què pot resoldre el primer nivell (p. ex., RESTabliment de MFA després de la comprovació d’identitat) i quan cal escalar. Sense guions d’actuació tot s’escalarà — i els administradors esdevindran el coll d’ampolla.

Pas 4: Treballs tècnics posteriors com a backlog propi

La CA fa visibles deutes tècnics ocults: clients de correu obsolets, escàners no documentats, scripts amb la contrasenya en el Task Scheduler, o integracions que encara utilitzen Basic Auth. Planifiqueu aquestes tasques de seguiment com a paquets de treball visibles. Altrament, quedaran com a «excepció permanent».

Patrons d’errors típics en l’explotació – i com classificar-los més ràpid

En el dia a dia compten les hipòtesis ràpides. Alguns patrons es repeteixen sovint:

«De sobte Outlook ja no funciona»

Causes freqüents: client legacy, perfil antic o un bloqueig de CA per falta d’estat del dispositiu. Comproveu: tipus de client al registre d’inici de sessió, política CA aplicada i si el dispositiu consta com a compliant. La solució operativa rarament és «desactivar la política», sinó «modernitzar el client» o «posar en ordre la gestió de dispositius».

«El servei XY no pot enviar més correus electrònics»

Sovint hi ha al darrere un canvi en l’autenticació SMTP, una política de relay modificada o una nova regla de CA que captura sense voler també comptes tècnics. Aquí ajuda una decisió arquitectònica clara: enviament via Relay/Connector en lloc d’inici de sessió d’usuari, amb RESTricció per IP i registre (traçabilitat en l’incident).

«L’admin ja no accedeix al tenant»

Aquesta és la situació per a la qual està pensat el Break-Glass. Si l’accés Break-Glass tampoc funciona, sovint manca un camí d’emergència provat o l’excepció s’ha creat incorrectament. Per tant: practiqueu-ne l’ús de forma regular (amb documentació de qui prova quan i com és l’alarma).

«Masses d’excepcions – ningú hi veu clar»

Això és un problema de governança. Consolideu les polítiques, definiu un ritual de revisió (p. ex., 30 minuts mensuals) i elimineu les excepcions que ja no tenen un responsable ni cap propòsit. Tècnicament això no és glamurós, però marca la diferència entre una seguretat controlable i privilegis especials històricament acumulats.

Monitoratge i traçabilitat: què necessiteu realment

La CA i la MFA generen molts esdeveniments. Si recolliu-ho tot, us ofegareu; si no n’analitzeu res, detectareu els problemes massa tard. Hi ha tres nivells pràcticament útils:

• Alertes per esdeveniments crítics: inici de sessió Break-Glass, inici de sessió d’admin des de països inusuals, esdeveniments de bloqueig a aplicacions crítiques.
• Revisions periòdiques: principals motius de bloqueig, usuaris amb problemes de MFA, intents d’autenticació legacy, noves apps/aplicacions d’empresa.
• Pista d’auditoria per a les excepcions: qui va autoritzar quina excepció, amb quina data de caducitat i quan es va revisar?

Si ja disposeu de processos centrals de registre i incident (SIEM, ticketing, gestió de canvis), ancoreu-hi els canvis de CA. Conditional Access no és una «petita configuració», sinó una capa d’accés crítica per a la producció.

Esforç i responsabilitats: qui ha de lliurar què?

Els projectes CA/MFA s’infravaloren perquè semblen pura configuració. En realitat són projectes d’integració entre identitat, dispositius finals, xarxa i processos de negoci. Un model de responsabilitats clar redueix la fricció:

• Equip d’identitat / Entra Admins: disseny de polítiques, model de rols, Break-Glass, registre d’aplicacions.
• Client-Management (p. ex. Intune): definició de compliment, estat dels dispositius, desplegament d’Authenticator/Passkeys, cicle de vida dels dispositius.
• Netzwerk: rangs d’IP per a Named Locations, excepcions de proxy/inspecció TLS, canvi d’ubicació.
• Service Owner von Business-Anwendungen: rutes d’integració (Graph/SMTP/SharePoint), transició de l’autenticació heredada, rotació de secrets.
• Helpdesk: processos estàndard per a restabliment de MFA, canvi de dispositiu, incorporació i baixa.

La decisió de direcció més important sovint no és «MFA sí/no», sinó: tenim temps i recursos per als treballs posteriors (desmantellar el legacy, modernitzar integracions, estabilitzar la gestió de dispositius)? Sense aquesta feina, el benefici en seguretat quedarà per sota de les expectatives — o l’operació esdevindrà innecessàriament difícil.

Conclusió: la seguretat guanya quan l’emergència i l’excepció formen part del sistema

Assegurar Microsoft 365 correctament significa operar Conditional Access com a capa central de control — no com una configuració puntual. MFA és obligatori, però la qualitat operativa veritable s’aconsegueix mitjançant excepcions ben definides (amb data de caducitat, responsable i controls compensatoris) i mitjançant Break-Glass-Accounts, que han de ser provats, monitoritzats i integrats organitzativament. Qui articula aquests tres elements redueix els riscos dels comptes, obté capacitat d’auditoria sense sobrecàrrega i evita que les regles de seguretat es converteixin en enemigues durant un incident.

Parlar d’un projecte o d’una iniciativa de modernització amb Net-Base.