Sådan bruger du Entra ID Protection til at stoppe risky sign-ins, opsæt policies, alerts og testscenarier
Et kompromitteret login ligner ofte et helt normalt login. Det er bare fra et andet land, en anonym IP, eller et token der opfører sig mærkeligt. For en SMV kan det være forskellen på en rolig tirsdag og en uge med oprydning.
Entra ID Protection er Microsofts risikomotor i Microsoft Entra, som vurderer sign-ins og brugere og kan reagere automatisk via risikobaserede policies. Når det er sat rigtigt op, får man en “dørmand”, der beder om MFA, eller lukker døren, før skaden sker.
Artiklen her er skrevet beslutningsorienteret til små IT-teams, med konkrete policy-eksempler, anbefalede indstillinger, alerts og en mini-runbook til high-risk sign-ins.
Hvad Entra ID Protection fanger, og hvordan risky sign-ins stopper i tide
Flow fra login til risiko, policy og handling, lavet med AI.
Entra ID Protection arbejder med to centrale begreber:
- Sign-in risk : risiko ved selve login-forsøget (risky sign-in).
- User risk : sandsynlighed for at brugerkontoen allerede er kompromitteret.
Risikoen kommer fra Microsofts detektioner. Typiske signaler er “impossible travel”, “anonymous IP” og password spray. Hvis man vil forstå niveauer og typer, er Microsofts forklaring af risk detection types and levels et godt udgangspunkt.
Microsoft har også forbedret flere af disse detektioner i 2025, hvilket i praksis kan give færre falske positiver. Og fra februar 2026 bliver håndtering af jailbreak/root mere stram i Microsoft Authenticator, hvilket påvirker den samlede risikoprofil ved sign-ins på kompromitterede mobiler (relevant, hvis I kører meget mobil MFA).
Det vigtige for en SMV er ikke at kende alle algoritmer. Det vigtige er at få besluttet: Hvornår kræver vi MFA, hvornår blokerer vi, og hvem får alarmen?
Hvorfor det betyder noget
Når Entra ID Protection stopper et risky sign-in automatisk, sparer det ofte timer til dage i incident-håndtering. Det er billigere end at “finde ud af det bagefter”, også selv om man har antivirus og firewall.
Opsætning af risk policies: scope, undtagelser og anbefalede indstillinger
Den typiske opsætning (2026-terminologi) er:
- Slå Entra ID Protection til (kræver passende licens, ofte Entra ID P2).
- Definér jeres “pilot scope” (fx IT og et par nøglebrugere).
- Aktivér risikobaserede policies og rul ud i faser.
Start med Microsofts guide til konfiguration af risk policies og beslut derefter jeres niveau.
Anbefalet baseline (SMV) i en tabel
| Risikoniveau | Sign-in risk policy (handling) | User risk policy (handling) | Typiske undtagelser | Kommentar |
|---|---|---|---|---|
| Lav | Tillad, men kræv MFA for udvalgte apps | Overvåg, ingen automatisk reset | Break-glass konto, servicekonti uden interaktiv login | Brug lav risiko til synlighed, ikke blokering. |
| Medium | Kræv MFA | Kræv password change (med MFA) | Break-glass, evt. servicekonti | Ofte “sweet spot” for SMV. |
| Høj | Bloker sign-in | Kræv password change, og overvej at blokere indtil gennemgang | Break-glass (meget kontrolleret) | Sæt klare driftsregler før I aktiverer. |
To faldgruber går igen hos små IT-teams:
1) Break-glass uden kontrol.
I skal have mindst én nød-adgangskonto, men den skal beskyttes med stærk governance (langt password, offline opbevaring, overvågning, ingen daglig brug). Hvis I ikke har den, risikerer I at låse jer selv ude.
2) For bredt scope fra dag 1.
Rul ud i bølger. Det minimerer driftsstøj og supportsager til it-support.
Konkrete policy-eksempler (med navne der kan driftes)
En enkel navngivningskonvention gør det nemmere at fejlsøge og auditere:
Forslag:
IDP-<Scope>-<RiskType>-<Action>-v<nr>
Eksempler:
-
IDP-ALL-SignInRisk-MFA-v1 -
IDP-ALL-SignInRisk-BlockHigh-v1 -
IDP-ALL-UserRisk-PasswordChange-v1 -
IDP-PILOT-SignInRisk-MFA-v1
Det er samme tankegang som gode it-løsninger generelt: hvis ingen kan forstå navnet om tre måneder, bliver det ikke vedligeholdt.
Hvis I kombinerer med Conditional Access, så hold princippet enkelt: risk policies styrer risikohændelser, Conditional Access styrer kontekst (enhed, app, lokation). Microsofts gennemgang af risk-based sign-in med MFA er en god reference, når man skal vælge “MFA vs block”.
Alerts og drift: sådan gør I det til en rutine, ikke et projekt
Et oversigtsbillede af risikoniveauer og hændelser, lavet med AI.
Policies uden alarmer er som en firewall uden logs. Man aner ikke, om den gør sit job.
Sæt notifikationer op med det samme. Entra ID Protection kan sende automatiske mails (fx “users at risk” og ugentlig digest). Brug Microsofts side om ID Protection notifications til at få de rigtige modtagere på plads (fælles mailbox, vagttelefon, eller ticket-system).
Driftsmæssigt er målet en enkel rytme:
- Dagligt: kig på high-risk sign-ins og blokerede forsøg.
- Ugentligt: trend (stiger det, falder det, er det samme brugere?).
- Månedligt: justér scope, undtagelser og krav, især hvis Microsoft 365-apps ændrer brugsmønstre.
Hvorfor det betyder noget
Når alarmsignalet lander det rigtige sted, falder MTTR (tid til afklaring). Det er ofte vigtigere end at have “flere værktøjer”. Mange SMV’er har både antivirus, firewall og backup, men mangler en klar alarmvej ved identitetshændelser.
Mini-runbook: incident response ved high-risk sign-ins (15 til 30 minutter)
Brug den her som start, og tilpas den til jeres forretning:
- Bekræft hændelsen i Entra: hvilken bruger, hvilken app, hvilken IP og hvilken detektion.
- Stop blødning : blokér sign-in (hvis ikke allerede), og revokér aktive sessions hvor relevant.
- Kontakt brugeren : var det dem? Hvis ja, hvorfor ser det risky ud (VPN, rejse, ny enhed)?
- Remedier : kræv password change og MFA re-registration hvis der er mistanke.
- Tjek sideeffekter : mail-forwarding regler, nye OAuth-consents, usædvanlige logins.
- Dokumentér : tidspunkt, handlinger, udfald, og om policy skal justeres.
Til selve undersøgelsen er Microsofts guide til investigate risk nyttig, især hvis man er ny i arbejdsgangen.
I NETDK’s it-support for SMV’er i århus og lystrup ser vi ofte, at den største tidsbesparelse kommer fra punkt 2 og 3. Hurtig afklaring fjerner panik og unødige blokeringer.
Testscenarier i en test-tenant: undgå at spænde ben for jer selv
Test af policies i et kontrolleret miljø, lavet med AI.
Test er ikke “nice to have”. Det er måden man undgår at en policy spærrer direktøren ude mandag kl. 08:05.
En enkel testmodel for små teams:
Opsætning (1 til 2 timer første gang):
- Lav en test-tenant eller et isoleret pilot-scope i jeres eksisterende tenant.
- Opret to testbrugere:
test.normal@...ogtest.risky@.... - Aktivér policies kun for pilotgruppen.
Test 1: Normal sign-in (kontroltest)
Login fra kendt enhed og kendt netværk. Forvent “ingen ekstra friktion” (eller kun den MFA I allerede kræver).
Test 2: “Ny kontekst” sign-in
Login fra ny browserprofil, ny enhed eller via et kendt VPN-udgangspunkt, så sign-in properties ændrer sig. Målet er ikke at “hacke”, men at se om policies reagerer fornuftigt med MFA og logs.
Test 3: High-risk håndtering uden at låse jer ude
Simulér proces: markér en bruger som “kræver gennemgang” (organisatorisk), og gennemfør runbooken. Tjek at break-glass virker, og at alarmer lander korrekt.
En praktisk detalje: planlæg test uden for spidsbelastning. Hvis jeres Microsoft 365-miljø er forretningskritisk, så test en fredag eftermiddag eller i et fast vedligeholdelsesvindue.
Konklusion: få risikobaseret adgangskontrol til at arbejde for jer
Entra ID Protection kan stoppe risky sign-ins, men kun hvis I har taget tre beslutninger: niveauer , handlinger og alarmvej . Kombinér det med en enkel navngivning, en realistisk undtagelsesliste og en kort runbook, så drift ikke ender som ad hoc-brandslukning. Når det spiller, bliver identitet et stærkt lag i jeres it-sikkerhed, på linje med backup, antivirus og firewall. Det giver ro, især når ressourcerne er små.
