Sikre Microsoft 365 riktig: Conditional Access, MFA-unntak og Break-Glass-Accounts i hverdagen

Den som vil sikre Microsoft 365 riktig, kommer ikke utenom Conditional Access (tilgangsavhengige retningslinjer i Entra ID, tidligere Azure AD) og Multi-Faktor-autentisering (MFA, altså pålogging med minst to faktorer). I mange organisasjoner aktiveres MFA og de første Conditional-Access-reglene raskt – og så begynner arbeidet: unntak må begrunnes, nødtilganger må organiseres ryddig, og driftsprosesser må utformes slik at sikkerhet ikke blir en supportflom.

I praksis mislykkes «M365 sikre» sjelden på grunn av grunnleggende teknologi, men på grunn av hverdagstemaer: servicekontoer for grensesnitt, legacy-protokoller, feltarbeid uten pålitelig mobilnett, administratorer med for vide rettigheter, eller en hendelse der nettopp sikkerhetstiltaket blokkerer ITs tilgang. Denne artikkelen setter orden på hvordan Conditional Access, MFA-unntak og Break-Glass-Accounts samvirker – og hvordan du drifter det slik at det forblir pålitelig også etter go-live.

Warum Conditional Access der Hebel ist – und MFA allein nicht reicht

MFA reduserer risikoen for stjålne passord betydelig, men MFA er ikke et fullstendig tilgangskonsept. Conditional Access (CA) avgjør kontekstavhengig, under hvilke betingelser tilgang er tillatt: for eksempel kun fra administrerte enheter, kun fra bestemte land, kun ved risikovurdering eller kun med bestemte klientapper. Dette er det avgjørende steget mot Zero Trust (sikkerhetsmodell der ingen tilgang er tillit som standard, men kontinuerlig vurderes).

Typiske grunner til at MFA alene i Microsoft 365 ikke er tilstrekkelig:

• Token i stedet for passord: Moderne autentisering bruker tokens (tidsbegrensede tilgangsbilletter). Et stjålet token kan omgå MFA hvis CA ikke stiller tilleggsvilkår (f.eks. enhetstilstand eller sesjonskontroll).
• Admin-risiko: Administrative kontoer er spesielt attraktive. Uten CA-regler for admin-tilganger (f.eks. kun fra admin-arbeidsstasjoner eller kun med phishing-resistent MFA) forblir den største angrepsflaten åpen.
• «Tillatt» er for bredt: Hvis CA ikke skiller mellom apper, dataklasser og tilgangstyper, blir sikkerheten raskt enten for svak eller for RESTriktiv – begge deler skaper problemer.

Kjernepunktet i driften er derfor: CA som policiesjikt, MFA som en byggekloss i det, pluss ryddig unntakshåndtering og robuste nødprosedyrer.

Architekturüberblick: Was Conditional Access in Entra ID tatsächlich steuert

For IT-ledelse og drift er det viktig å ikke oppfatte CA som «en enkelt policy», men som en beslutningskjede. Entra ID vurderer signaler ved hver pålogging og anvender policies. Viktige signaler er:

• Identitet: Brukere, grupper, roller (f.eks. privilegerte roller som Global Administrator).
• Målressurs: Cloud-app (Exchange Online, SharePoint/OneDrive, Teams, men også tredjepartsleverandører via Enterprise App).
• Klienttype: Nettleser, moderne klienter, mobile apper, samt «Legacy Authentication» (eldre protokoller uten moderne tokens, f.eks. eldre IMAP/POP/SMTP-autentiseringsvarianter).
• Enhetstilstand: «Compliant» eller «hybrid joined» (administrert enhet, typisk via Intune eller domenetilknytning med enhetstilstand).
• Nettverk/Plassering: Named Locations (definerte IP-områder), land/regioner, risikoindikatorer.
• Sesjonsbetingelser: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (kontinuerlig nyvurdering ved risikohendelser).

Fra driftssynspunkt avhenger kvaliteten på deres CA-konfigurasjon i stor grad av om disse signalene er pålitelige. En Named Location er bare så god som deres IP-adressehygiene. „compliant“ er bare så god som deres enhetsstyring og definisjon av compliance. Og risikovurderingen er bare nyttig dersom dere også arbeider med de hendelsene som oppstår.

Microsoft 365 richtig absichern mit Conditional Access: Ein praxistaugliches Policy-Set

I stedet for én «stor» regel fungerer i praksis et sett av noen få, klart avgrensede policies bedre. Det reduserer sideeffekter og gjør feilsøking ved incident enklere. Et velprøvd grunnmønster består av:

1) Baseline für alle Nutzer: MFA erzwingen, Legacy blocken

For vanlige brukerkontoer er baseline: MFA påkrevd, og Legacy Authentication blokkeres. «Legacy» er her ikke «gammeldags», men teknisk problematisk: Disse protokollene støtter ofte ikke moderne MFA-challenge og er derfor en klassisk inngangsvei for passordspraying.

Viktig: Blokker ikke Legacy «på et eller annet tidspunkt», men planlegg en overgangsperiode med måling. Sjekk via Sign-in-Logs hvilke klienter som fortsatt bruker Legacy. I virksomheter er dette ofte knyttet til multifunksjonsskrivere, Scan-to-Mail eller eldre e-postklienter i spesialmiljøer.

2) Admin-Policy: deutlich strenger als die Baseline

Privilegerte roller bør ha en egen policy: tilgang kun fra definerte admin-endepunkter (f.eks. „compliant“ og eventuelt en separat admin-workstation-strategi), MFA med høy sikkerhet (phishing-resistent, f.eks. FIDO2/Passkey eller sertifikatbasert), og helst begrensninger mot risikable land/steder. Selv om ikke alle virksomheter umiddelbart innfører en fullstendig Privileged-Access-Architektur (PAM, altså privilegert tilgangsstyring), er dette skillet umiddelbart nyttig: Et kompromittert admin-konto er et annet skadebilde enn et kompromittert brukerkonto.

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

Gjestetilganger (B2B Collaboration) skaper ofte uventede dataflyter: Gjestene laster ned filer fra SharePoint, jobber i Teams eller får tilgang til prosjektportaler. Definer her eksplisitt om gjester kun får tilgang med MFA, om bestemte apper skal ekskluderes og hvor lenge sesjoner skal være gyldige. For prosjektarbeid er ofte kortere sesjonsvarighet fornuftig for å redusere risikoen ved «glemte logins».

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

I hverdagen finnes ulike beskyttelsesbehov: En salgsperson kan kanskje lese e‑post fra hvilken som helst enhet, men ikke uten administrert enhet laste ned store datamengder fra SharePoint. Slike forskjeller modellerer du ikke gjennom en generell «tillatt/forbudt», men gjennom CA-kombinasjoner: «Tilgang tillatt hvis enhet er compliant» eller «Tilgang kun via nettleser med begrenset økt». Dette er mindre rigid enn full blokkering – og likevel effektivt.

MFA-Ausnahmen: Wo sie realistisch sind – und wie man sie kontrolliert

MFA-unntak er ikke et tegn på svakhet så lenge de er bevisst utformet og driftmessig kontrollert. Uten kontrollerte unntak oppstår skygge­løsninger: brukere omgår prosesser, administratorer slår av regler i panikk, og etter hvert er policy-samlingen ikke lenger etterprøvbar.

Viktig er skillet: Et MFA-unntak er sjelden «MFA av», men ofte «MFA annerledes» eller «tilgang kun under andre betingelser». Typiske unntakskategorier:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Mange prosessnære programvareløsninger integrerer M365-tjenester: e-postutsendelse, kalendertilgang, SharePoint-filoppbevaring, Teams-varsler eller Graph-API-tilganger. Slike integrasjoner bør ikke gå over brukerkontoer med deaktivert MFA. Bedre er teknisk tilgang via App-Registrierungen (applikasjon i Entra ID) med klare rettigheter og Secret-/sertifikatlivssyklus. Dette er ikke en «MFA-Ausnahme», men en annen autentiseringsmåte som er mer auditierbar.

Driftsfølger: Secrets må roteres, sertifikater utløper, og rettigheter må re-sertifiseres. Når dere planlegger integrasjoner, definer Ownership (hvem fornyer sertifikater/Secrets) og Monitoring (f.eks. varsler før utløp). Ellers kan «sikker» app-autentisering bli en uplanlagt nedetid.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Her oppstår de klassiske diskusjonene rundt SMTP-Relay, Scan-to-Mail eller rom-postkasser. Den feilaktige løsningen er nesten alltid «ein Benutzerkonto ohne MFA». Bedre er tekniske veier som ikke er avhengige av interaktiv pålogging: sentralt mail-relay med IP-RESTriksjon, sertifikat- eller connector-tilnærminger, eller separate systempostkasser med stramme rettigheter. Avgjørende er: Enheten kan ikke håndtere MFA selv, derfor må designet sikres i transport- og nettverksstien.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Feltarbeid, produksjon eller skiftdrift har situasjoner uten mobildekning eller uten private mobiltelefoner. Her lønner det seg å tidlig vurdere alternative MFA-metoder: Hardware-Token, FIDO2-sikkerhetsnøkler, eller Windows Hello for Business (enhetsbundet pålogging). «Temporär MFA aus» er operativt fristende, men skalerer dårlig og er vanskelig å revidere.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Noen eldre systemer starter jobber «als Benutzer», for eksempel for SharePoint-opplastinger eller rapporter. Det er i dag risikabelt, fordi det blander roller og tilgangsrettigheter. Hvis utskifting ikke er mulig med en gang, arbeid med mellomløsninger: begrensede servicekontoer, klare Named Locations, sterke passord-/Secret-policyer og konsekvent logging. Og: planlegg migrasjonen til app-identiteter som et eget arbeidspakke, ikke som «später mal».

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Unntak er i drift bare akseptable hvis de har en livssyklus. Praktisk har en lettvektsprosess vist seg å fungere, som unngår byråkrati, men som likevel er revisjonssikker:

1. Begründung in einem Satz: Hvilken forretnings- eller driftsfunksjon avhenger av dette (f.eks. «Scan-to-Mail an Standort X»)?
2. Technische Einordnung: Hvilken app/protokoller, hvilke kontoer, hvilke dataflyter?
3. Kompensierende Kontrollen: Hva begrenser risikoen (IP-RESTriksjon, minimale nødvendige rettigheter, overvåking)?
4. Ablaufdatum: Hvert unntak får en gjennomgangsdato. Uten gjennomgang fjernes det eller godkjennes på nytt.
5. Owner: Hvem er ansvarlig hvis det oppstår problemer eller hvis unntaket utløper?

Det gjør ikke unntakene «gut», men de blir styrbare. Og nettopp det er i praksis forskjellen mellom et robust M365-sikkerhetsgrunnlag og et viltvoksende regelverk.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Break-Glass-kontoer er nødbrukerkontoer for tilgang til tenanten når vanlige administrator-tilganger ikke fungerer – for eksempel på grunn av feilkonfigurasjon i Conditional Access, svikt hos en MFA-leverandør eller en identitetshendelse. Formålet er klart, men implementeringen har typiske fallgruver: En Break-Glass-konto som aldri testes, hjelper ikke i en krisesituasjon. En Break-Glass-konto som er for lett tilgjengelig, er et attraktivt angrepsmål.

Hva Break-Glass ikke er

• Ikke en daglig administratorkonto: Den må ikke brukes i normal drift.
• Ikke et oppsamlingssted for unntak: Den erstatter ikke et ryddig CA-design.
• Ikke «vi har en, det holder»: Uten prosess, test og varsling er det bare en teoretisk plan.

Grunnprinsipper for Break-Glass i drift

Et praktisk oppsett orienterer seg mot tre mål: tilgjengelig i nød, vanskelig å angripe i normal drift, og godt etterprøvbart.

• Minst to kontoer: Redundans mot sperring, feilbruk eller kompromitterte legitimasjoner.
• Sterkt sikret: Lange, tilfeldige passord; ingen e-postvideresending; ingen bruk for apper/integrasjoner.
• Spesifikt unntatt fra CA – men snevert: Typisk er et unntak fra bestemte CA-policyer, slik at man i nødssituasjoner ikke sperres ute av egne regler. Samtidig bør andre sikkerhetsmekanismer være i kraft: varsler ved bruk, RESTriktiv rollefordeling, og at påloggingsdata oppbevares separat.
• Logging og varsling: Hver pålogging må utløse et umiddelbart signal (SIEM/SOC eller i det minste e-post/Teams-varsling til en incident-innboks). Bruk av Break-Glass er per definisjon en sikkerhetshendelse.

Et sentralt punkt: Beslutt bevisst om Break-Glass skal drives med eller uten MFA. Mange organisasjoner lar det være uten MFA for å være operasjonelle ved MFA-svikt. Da må de kompenserende kontrollene være særlig strenge (oppbevaring, tilgang til passordet, varsling, regelmessig bytte). Alternativt kan man utstyre Break-Glass med maskinvarebasert MFA (f.eks. FIDO2) som er uavhengig av mobilnett. Det viktige er ikke den „riktige“ ideologien, men en nødvei som fungerer reelt i deres kontekst.

Utrullingsrealitet: Slik unngår dere lockouts og supporttopper

Mange CA-/MFA-utrullinger feiler ikke teknisk, men organisatorisk: for raskt, for bredt, uten telemetri og uten en klar supportprosess. En stabil utrulling jobber i bølger med målepunkter.

Trinn 1: Skap synlighet (før dere begynner å blokkere)

Bruk sign-in-logger og analyser for å finne ut: Hvilke apper brukes? Hvilke klienter er ‚Legacy‘? Hvilke lokasjoner/IP-områder er reelle? Hvilke brukere har spesielt mange påloggingsproblemer? Uten disse dataene er enhver policy en blindflyvning.

Trinn 2: Pilotgrupper med reelle særtilfeller

Pilotene bør ikke bare være ‚IT og noen få frivillige‘. Ta bevisst med randtilfeller: feltpersonell, produksjonssteder, prosjektmedarbeidere med gjestetilgang, og minst én avdeling med typiske tredjepartsverktøy. Målet er ikke harmoni, men å finne de virkelige snublefellene tidlig.

Trinn 3: Definer helpdesk-playbooks

Når MFA påtvinges, øker antallet saker: bytte av enheter, tapte telefoner, nye ansatte, konto sperret etter for mange forsøk. Fastsett hva førstelinje kan håndtere (f.eks. MFA-tilbakestilling etter identitetskontroll) og når det skal eskaleres. Uten Playbooks eskalerer alt – og administratorene blir flaskehalsen.

Trinn 4: Tekniske etterarbeider som eget Backlog

CA gjør skjult teknisk gjeld synlig: utdaterte e-postklienter, ikke-dokumenterte skannere, skript med passord i Task Scheduler, eller integrasjoner som fortsatt bruker Basic Auth. Planlegg disse etterarbeidene som synlige arbeidspakker. Ellers blir de hengende som «varige unntak».

Typiske feilmønstre fra drift – og hvordan man raskere klassifiserer dem

I det daglige gjelder raske hypoteser. Noen mønstre gjentar seg:

«Plutselig fungerer ikke Outlook lenger»

Vanlige årsaker: legacy-klient, gammel profil eller en CA-blokkering på grunn av manglende enhetstilstand. Sjekk: klienttype i sign-in-loggen, anvendt CA-policy, og om enheten er registrert som compliant. Den operative løsningen er sjelden «policy av», men heller «modernisere klienten» eller «rydde opp i enhetsstyringen».

«Service XY kan ikke sende e-post lenger»

Ofte ligger en endring i SMTP-autentisering, en endret relay-policy eller en ny CA-regel bak, som utilsiktet også rammer tekniske kontoer. Her hjelper en klar arkitekturavgjørelse: sending via relay/connector i stedet for brukerinnlogging, med IP-RESTriksjon og logging (etterprøvbarhet i incident).

«Admin kommer ikke lenger inn i tenantet»

Dette er øyeblikket Break-Glass-tilgang er ment for. Hvis Break-Glass-tilgangen heller ikke fungerer, mangler det som regel en testet nødprosedyre eller unntaket er feilkonstruert. Derfor: øv bruken regelmessig (med dokumentasjon over hvem som tester når, og hvordan alarmen ser ut).

«For mange unntak – ingen får oversikt»

Dette er et governance-problem. Konsolider policyene, definer et review-ritual (f.eks. månedlig 30 minutter), og fjern unntak som ikke lenger har en eier eller et formål. Teknisk er dette ikke glamorøst, men det er forskjellen mellom kontrollerbar sikkerhet og historisk opparbeidede særrettigheter.

Monitoring og etterprøvbarhet: Hva du virkelig trenger

CA og MFA genererer mange hendelser. Hvis du samler alt, drukner du; hvis du ikke analyserer noe, oppdager du problemer for sent. Praktisk nyttig er tre nivåer:

• Varsling på harde hendelser: Break-Glass-innlogging, admin-innlogging fra uvanlige land, blokkhendelser på kritiske apper.
• Regelmessige gjennomganger: topp blokkårsaker, toppbrukere med MFA-problemer, forsøk på legacy-autentisering, nye apper/Enterprise Apps.
• Revisjonsspor for unntak: hvem godkjente hvilket unntak, med hvilken utløpsdato, og når ble det gjennomgått?

Hvis dere allerede har sentrale logging- og incident-prosesser (SIEM, ticketing, change management), forankre CA-endringer der. Conditional Access er ikke en «liten innstilling», men et produksjonskritisk tilgangslag.

Arbeidsmengde og ansvar: Hvem må levere hva?

CA-/MFA-prosjekter undervurderes fordi de fremstår som ren konfigurasjon. I realiteten er de grensesnittprosjekter mellom identitet, endepunkter, nett og fagprosesser. En tydelig ansvarsmodell reduserer friksjon:

• Identity-Team / Entra Admins: policy-design, rollemodell, Break-Glass, app-registreringer.
• Client-Management (f.eks. Intune): Compliance-definisjon, enhetsstatus, utrulling av Authenticator/Passkeys, enhetens livssyklus.
• Nettverk: IP-områder for Named Locations, unntak for proxy-/TLS-inspeksjon, lokasjonsendringer.
• Tjenesteeier for forretningsapplikasjoner: integrasjonsstier (Graph/SMTP/SharePoint), overgang fra Legacy-Auth, rotasjon av secrets.
• Helpdesk: standardprosesser for MFA-reset, enhetsbytte, onboarding/offboarding.

Den viktigste ledelsesavgjørelsen er ofte ikke «MFA ja/nei», men: Har vi tid og ressurser til etterarbeidet (fjerne legacy, modernisere integrasjoner, stabilisere enhetsforvaltning)? Uten dette arbeidet blir sikkerhetsgevinsten lavere enn forventet – eller driften blir unødvendig tung.

Konklusjon: Sikkerhet vinner når nødtilfeller og unntak er en del av systemet

Å sikre Microsoft 365 riktig betyr at Conditional Access må drives som et sentralt styringslag – ikke som en engangskonfigurasjon. MFA er påkrevd, men den faktiske driftskvaliteten oppstår gjennom ryddige unntak (med utløpsdato, ansvarlig og kompenserende kontroller) og gjennom Break-Glass-kontoer som testes, overvåkes og er organisatorisk forankret. Den som ser disse tre elementene i sammenheng, reduserer konto-risiko, oppnår revisjonssporbarhet uten overflødig overhead og hindrer at sikkerhetsregler blir en motstander ved en hendelse.

Diskuter prosjekt eller moderniseringsprosjekt med Net-Base.