De fleste konto-angreb starter simpelt: et lækket password, en god phishing-mail, eller en bruger der trykker “godkend” lidt for hurtigt. Og når først en angriber er inde, går det ofte stærkt, mail, SharePoint, Teams og VPN kan blive næste skridt.
Conditional access (i Microsoft Entra) er en af de få sikkerhedsindstillinger, der kan stoppe rigtig mange angreb uden at gøre hverdagen umulig. Det handler ikke om flere regler for reglers skyld, men om at stille de rigtige krav, når login’et ser risikabelt ud.
Her får du en praktisk forklaring og fem konkrete policies, der normalt giver størst effekt i små og mellemstore virksomheder.
Hvad Conditional Access faktisk gør (og hvad det ikke gør)
Conditional Access er en “hvis-så” motor for adgang. Den kigger på signaler ved login og beslutter, om brugeren må ind, om der skal ekstra bevis på identitet, eller om adgangen skal blokeres.
De typiske signaler er:
- Hvem logger ind (bruger, rolle, gæst)
- Hvad der tilgås (Microsoft 365, admin-portaler, andre cloud-apps)
- Hvorfra (IP, land, named locations)
- Enhedens tilstand (er den compliant i Intune)
- Risiko (Identity Protection, hvis du har det licensmæssigt)
Og resultatet er som regel én af disse:
- Tillad adgang
- Kræv MFA
- Kræv compliant enhed
- Bloker
- Begræns sessionen (session controls), fx app enforced restrictions
Det her er ikke antivirus, firewall eller mailfilter. Det er adgangskontrol. Tænk på det som en dørmand, der tjekker ID ekstra grundigt, når noget virker off. Microsoft beskriver grundideen fint i deres overblik over Conditional Access.
En vigtig pointe: Conditional Access virker bedst, når du holder det simpelt. Få policies, klar målgruppe, og så løbende justering via sign-in logs.
De fem Conditional Access policies der giver mest effekt
Nedenstående er de fem, der i praksis stopper størstedelen af “standard-angreb” på Microsoft 365. Brug dem som baseline, og byg videre bagefter.
1) Kræv MFA for alle brugere (med break-glass undtagelse)
Hvis du kun gør én ting, så gør den her. MFA stopper rigtig mange password-baserede angreb, også når brugeren genbruger adgangskoder.
Praktisk opsætning (typisk):
- Users: All users
- Exclude: 1 til 2 break-glass konti (nød-adgang), stærke passwords, helst uden mailbox
- Cloud apps: All cloud apps (start gerne med Microsoft 365)
- Grant: Require multi-factor authentication
Faldgrube: MFA fatigue. Brugere kan blive trætte og trykke “godkend” pr. refleks. Overvej derfor at stramme metoderne (fx number matching) og vær ekstra skarp på usædvanlige login-forsøg.
Drift-tip: Start i Report-only, så du kan se hvem der bliver ramt, før du håndhæver.
2) Bloker legacy authentication (det er stadig en klassiker)
Legacy auth er gamle login-metoder, som ofte kan omgå MFA. Det er en favorit ved password spray og brute force mod mail.
Praktisk opsætning:
- Users: All users (pas på med undtagelser)
- Client apps: Markér legacy/other clients
- Cloud apps: Exchange Online (og eventuelt “All cloud apps”)
- Grant: Block access
Faldgrube: “Vi undtager bare den ene app”. App-baserede undtagelser ender tit som en bagdør. Hvis noget kræver legacy auth, så få det udfaset, eller isolér det hårdt (egen konto, kun fra fast IP, og overvågning).
Microsofts guide til at bygge Conditional Access policies giver et godt billede af, hvordan du rammer rigtigt med scope og kontroller.
3) Kræv compliant device for data-tunge apps (Intune giver ro i maven)
Når en bruger er logget ind, er næste problem ofte data: mail-eksport, SharePoint-synk, og filer på ukontrollerede pc’er. “Require compliant device” gør en stor forskel, især hvis I har bærbare på farten og hjemmearbejde.
Praktisk opsætning:
- Users: All users (eller en gruppe først)
- Cloud apps: SharePoint, OneDrive, Exchange, Teams
- Grant: Require device to be marked as compliant
Faldgrube: BYOD og gæster. En privat pc bliver sjældent compliant uden MDM. For gæster (B2B) kan du i stedet bruge session controls, fx app enforced restrictions, så de kan læse i browser, men ikke downloade alt lokalt.
4) Admin-roller skal have stærkere krav (ellers er det én fejl fra katastrofe)
Admin-konti er målet. Hvis en angriber får en Global Admin, kan alt ændres på minutter. Derfor skal admin-login være mere stramt end almindelige brugere.
Praktisk opsætning:
- Users: Directory roles (fx Global Admin, Exchange Admin, SharePoint Admin)
- Cloud apps: Admin-portaler (Microsoft admin portals)
- Grant: Require MFA (gerne stærkere metoder), og gerne compliant device
- Session controls: Kortere sign-in frequency på admin-portaler
Faldgrube: Lockout ved fejl. Hav altid break-glass konti, og test dem. De skal være ekskluderet fra de stramme policies, men de skal også overvåges og opbevares sikkert.
5) Geografi- og risiko-baseret adgang (named locations og Identity Protection)
Du behøver ikke blokere “alt udenfor Danmark” for at få værdi. Men det giver mening at styre adgang baseret på lokation og risiko, især hvis I normalt kun arbejder fra Danmark og få faste steder.
Praktisk opsætning:
- Named locations: Kontor-IP’er og kendte netværk
- Conditions: Sign-in risk (hvis tilgængeligt) og/eller land
- Grant: Kræv MFA ved høj risiko, eller block ved specifikke lande I aldrig bruger
Faldgrube: For brede exclusions. Når man først har lavet en named location, er det fristende at “slå alt fra” der. Men kompromitterede konti kan også logge ind fra kontoret. Named locations er et signal, ikke et fripas.
Hvis du vil nørde detaljerne i, hvad “conditions” faktisk betyder i praksis, så se Microsofts forklaring af betingelser i Conditional Access.
Faldgruber der giver lockout eller falsk tryghed
Conditional Access fejler sjældent teknisk. Det fejler i opsætning og undtagelser.
De mest almindelige problemer:
- For brede exclusions: “Exclude all service accounts” ender som en motorvej for angribere.
- Ingen break-glass plan: Uden nød-adgang kan en fejl låse hele virksomheden ude.
- Gæster/B2B glemmes: Gæster har ofte andre flows og kan ramme uventede blokeringer.
- Service accounts og automatisering: Planlæg dem separat. Brug mindst mulig adgang, og log alt.
- MFA fatigue ignoreres: Mange push-prompter gør brugere sløve. Skærp metoder og hold øje med mønstre.
Drift-tip: Brug sign-in logs aktivt. Når en policy rammer forkert, kan du som regel se præcis hvilken betingelse der udløste den.
En sikker udrulning i praksis, uden panik på en mandag
Hold processen stram og gentagelig:
- Lav policyen i Report-only først.
- Kør en pilot (fx IT og et par almindelige brugere).
- Tjek sign-in logs dagligt i starten, og ret scope og undtagelser.
- Slå til i produktion, én policy ad gangen.
- Dokumentér: hvem er break-glass, hvor ligger credentials, og hvem må bruge dem.
Hvis du vil have et hurtigt udgangspunkt, kan du også kigge på Microsoft-managed Conditional Access policies som inspiration til baseline, men tilpas altid til jeres virkelighed.
Conditional Access virker, fordi det rammer der, hvor angrebene starter: ved login og adgang til data. De fem policies her giver typisk mest sikkerhed pr. minut du bruger på opsætning, især MFA, blokering af legacy auth og strammere admin-krav. Start småt med Report-only, brug sign-in logs, og hold undtagelser på et minimum. Når det kører, har du en adgangsmodel der kan tåle både fejlklik og stjålne passwords.
