Hver politik for betinget adgang ser fornuftig ud for sig. Hullerne opstår mellem dem: en bruger, en enhed, et program eller en loginmetode, som ingen af reglerne rammer. En gennemgang læser derfor regelsættet som en helhed og spørger for hver kombination, om der er en regel, der gælder.
Kontrolpunktet er relevant for alle, der bruger Entra ID til at styre login til Microsoft 365 og andre programmer. Målestokkene er CISA’s baseline for Entra ID og Microsofts egen planlægningsvejledning.
Hvor hullerne typisk opstår
CISA’s baseline for Entra ID (SCuBA) har et afsnit om politikker for betinget adgang, der beskriver tre slags svagheder. Overlappende eller modstridende betingelser kan efterlade brugere eller enheder uden beskyttelse. Undtagelser, der ikke er tænkt igennem, fx for nye cloudprogrammer eller ustyrede enheder, kan gå uden om vigtige kontroller. Og i miljøer, der ændrer sig, med hybrid identitet og skiftende IP-områder, kan faste betingelser miste deres virkning.
CISA anbefaler at gennemgå politikkernes logik regelmæssigt, at kontrollere dækningen mod alle sammenhænge af brugere og enheder, og at holde øje med undtagelser, der ikke var tilsigtet. Nye politikker sættes først i tilstanden “Report-only”, så virkningen kan ses, før de håndhæves.
SCuBA er bindende for amerikanske civile føderale myndigheder. Herhjemme er den en offentlig målestok, som andre kan låne.
De regler, der skal findes
SCuBA har nogle politikker, der næsten altid indgår i en gennemgang:
- Gamle loginmetoder blokeret · MS.AAD.1.1v1 siger, at de skal blokeres (SHALL, det vil sige et krav i baselinens sprog). De kan ikke bede om en ekstra faktor og går derfor uden om MFA.
- Login med enhedskode blokeret · MS.AAD.3.9v1 siger, at det bør blokeres (SHOULD, en anbefaling).
- Styrede enheder krævet · MS.AAD.3.7v1 siger, at det bør kræves, at login sker fra enheder, virksomheden styrer.
Microsoft anbefaler i sin planlægningsvejledning, at hvert program har mindst én politik, og at en politik for “All resources” sikrer, at nye programmer også rammes. Det er det enkleste værn mod det hul, CISA beskriver med nye cloudprogrammer.
Sådan læses regelsættet
Det første udtræk er alle politikker med status, betingelser, undtagelser og krav. Microsoft har en grænse på 240 politikker pr. lejer, inklusive slukkede og dem i report-only. De fleste lejere har langt færre, men listen kan stadig være svær at overskue.
En gennemgang kan med fordel stille de samme spørgsmål til hele listen. Hvordan det gøres, er praksis:
- Hvem er undtaget? Saml alle undtagelser på tværs af politikkerne. Microsoft anbefaler at bruge grupper eller roller til undtagelser frem for enkeltbrugere. En enkeltbruger, der er undtaget i flere politikker, er et fund, der skal forklares.
- Hvilke programmer er uden regel? Holdt op mod listen over programmer i lejeren. Mangler politikken for alle ressourcer, kan nye programmer stå uden krav.
- Hvilke enheder og platforme er uden regel? Politikker, der kun gælder bestemte styresystemer, efterlader de andre.
- Hvilke placeringer er betroede? IP-områder, der fritager for krav, skal stadig svare til virksomhedens egne adresser.
- Hvilke politikker er slukket eller står i report-only? En politik, der har stået i report-only i lang tid, beskytter ikke.
Microsoft oplyser, at politikker skrevet til brugere ikke stopper de kald, som tjenesteidentiteter foretager. De hører derfor ikke til i denne kontrol, men skal have deres egen begrænsning.
Tilsigtede undtagelser
Nogle undtagelser skal være der. Microsoft anbefaler at undtage nødkonti fra blokerende politikker, så adgangen til lejeren ikke kan låses af en fejl i reglerne. Det ser ud som et hul, men er en bevidst beslutning, som er beskrevet i nødkonti. Servicekonti undtages også ofte. Forskellen mellem en tilsigtet og en utilsigtet undtagelse er, om den står på undtagelseslisten med begrundelse og ejer.
Afprøvning af en enkelt situation
Microsoft henviser til et “What If”-værktøj i lejeren, der kan vise, hvilke politikker der rammer en given login-situation. Vi har ikke læst værktøjets egen dokumentation og beskriver det ikke nærmere. Loginloggen viser under alle omstændigheder, hvilke politikker der blev anvendt ved hvert faktisk login, og den er det stærkeste bevis for, hvordan regelsættet virker.
Hvad det kræver, og hvad det koster at lade være
Det kræver læseadgang til politikkerne og loginloggen og tid til at læse regelsættet som helhed. Rettelserne er ofte at tilføje en politik for alle ressourcer, at samle undtagelser i grupper og at flytte politikker fra report-only til håndhævelse, efter at virkningen er set.
Uden kontrollen hviler beskyttelsen på, at hver enkelt politik ser rigtig ud. Den bruger eller det program, ingen regel rammer, får lov at logge på uden krav, og det ses ikke i nogen af de enkelte politikker.
Det skal I lade være med
- At undtage enkeltbrugere direkte i politikkerne · brug en gruppe med en ejer.
- At lade nye politikker stå i report-only uden slutdato · de beskytter ikke.
- At læse hver politik for sig · hullerne ses først i helheden.
Det skal gennemgangen kunne vise
- ☐ En dateret liste over alle politikker med status, betingelser, undtagelser og krav.
- ☐ En samlet liste over undtagne brugere og grupper med begrundelse.
- ☐ Et udtræk, der viser blokeringen af gamle loginmetoder.
- ☐ En politik, der rammer alle ressourcer, eller en forklaring på, hvorfor den mangler.
- ☐ Politikker i report-only med dato for, hvornår de skal håndhæves.
Kilder
- CISA, M365 Secure Configuration Baseline for Microsoft Entra ID, MS.AAD.1.1v1, 3.7v1, 3.9v1 og afsnittet Conditional Access Policies, læst 13. november 2026.
- Microsoft Learn, Plan a Conditional Access deployment, opdateret 1. juni 2026, læst 13. november 2026.
- Microsoft Learn, Manage emergency access admin accounts, opdateret 4. juni 2026, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Saml alle undtagelser fra jeres politikker i én liste, og skriv en ejer og en begrundelse ud for hver.
Læs også: Gennemgang af Microsoft 365 · Undtagelseslisten
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
