Conditional Access gjelden du sannsynligvis allerede har
- Bjørnar Aassveen
- 2 days ago
- 4 min read
Conditional Access har blitt en av de viktigste sikkerhetskontrollene i Microsoft 365. For mange organisasjoner er det selve ryggraden i den moderne tilgangsstyringen.
Samtidig er det få områder i Entra ID som har en tendens til å samle opp mer teknisk gjeld over tid.
De fleste starter med noen få enkle policyer. Så kommer unntakene, nye applikasjoner, konsulenter, midlertidige behov, pilotprosjekter.. Og plutselig sitter man med et oppsett ingen lenger helt forstår.
Hvis dette høres kjent ut, er du neppe alene.
Det skjer sjelden over natten.
Den klassiske historien starter ofte ganske fornuftig:
"Denne applikasjonen fungerer ikke med MFA."
"Vi må ekskludere denne gruppen mens vi tester."
"Kan vi ikke bare lage et lite unntak?"
Problemet er at ingen er spesielt flinke til å fjerne unntak når behovet er borte.
Etter noen år består deler av policysettet av historiske kompromisser som har overlevd både systemer, prosjekter og organisasjonsendringer.
Det er lite nytt under solen, hvem har vel ikke vært borti en server eller applikasjon som ble satt opp i DMZ med full åpning fra internett. Serveren heter ofte noe som starter med "test" og skulle bare være noe midlertidig greier, noe midlertidig som egentlig løste oppgaven godt nok og som plutselig ble en del av en arbeidsprosess som igjen ble permanent.
Det som skulle være et midlertidig avvik blir plutselig permanent arkitektur.
Noen typiske tegn på Conditional Access gjeld
1. Du har policyer ingen tør å røre
Policyen med det litt kryptiske navnet som ble opprettet for flere år siden. Ingen husker helt hvorfor den finnes, men alle er enige om at det virker risikabelt å deaktivere den.
Bare det er et varselsignal.
2. Unntakslistene er lengre enn policyen
Conditional Access skal håndtere tilgang.
Ikke være et museum over alle spesialtilfeller organisasjonen har opplevd siden 2020.
Hvis policyen beskytter "alle brukere", men samtidig ekskluderer:
Servicekontoer
Konsulenter
Eksterne brukere
Testbrukere
Driftspersonell
Diverse prosjektgrupper
...da kan det være verdt å stoppe opp og spørre om policyen faktisk gjør det den er ment å gjøre.
3. Du vet ikke hvem som eier policyen
Hver policy bør ha en tydelig eier.
Hvis ingen kan forklare:
hvorfor policyen finnes
hvilke systemer den beskytter
hvilke brukere som påvirkes
er den moden for gjennomgang.
Dokumentasjon er kanskje ikke det mest spennende området innen IAM, men alternativet er som regel mye mindre spennende, eller veldig spennende med uheldig utfall.. litt avhengig av hvordan man ser på det 🙄.
4. Du har flere policyer som løser samme problem
En policy som krever MFA.
En annen som også krever MFA.
Og en tredje som egentlig gjør omtrent det samme, men med litt andre grupper og litt andre unntak.
Resultatet blir ofte vanskelig feilsøking og uforutsigbar adferd når policyer overlapper hverandre.
5. Du har ikke brukt "What If" på lenge
Mange organisasjoner implementerer Conditional Access en gang og ser seg fornøyd.
Men organisasjonen står ikke stille.
Nye applikasjoner kommer til, brukere flytter roller (selv om dette helst skal løses med dynamiske grupper og tilgangspakker..),tilgangsbehov endrer seg.
Hvis du ikke regelmessig tester hvordan policyene faktisk evalueres, er det lett å få seg noen overraskelser.
Når Microsoft strammer inn, blir gjelden synlig
Noe av det mest interessante de siste årene er hvordan endringer i Entra stadig oftere avdekker gammel teknisk gjeld.
Administratoren opplever gjerne at:
"Dette fungerte jo før."
Og det stemmer ofte.
Men det betyr ikke nødvendigvis at konfigurasjonen var god.
Mange miljøer har historiske unntak, spesialtilfeller og gamle designvalg som har fungert fordi plattformen har vært relativt tilgivende.
Når Microsoft strammer inn håndhevingen eller endrer hvordan policyer evalueres, blir svakhetene plutselig synlige.
Problemet er som regel ikke den nye funksjonen.
Problemet er at ingen har sett på policyene siden Teams fortsatt het "det nye samarbeidsverktøyet".
En enkel helsesjekk
Du trenger ikke et stort moderniseringsprosjekt for å få oversikt.
Start med disse spørsmålene:
Hvilke ekskluderinger finnes?
Hvem er ekskludert?
Hvorfor?
Er begrunnelsen fortsatt gyldig?
Finnes gruppene fortsatt?
Jeg har sett flere policyer referere til grupper som ingen lenger bruker aktivt.
Noen ganger eksisterer gruppen fortsatt.
Ingen vet bare hvorfor.
Hvilke policyer brukes faktisk?
Se på:
Sign-in logs
Policy Insights
What If analyse
Der finner du ofte både policyer som aldri treffer og policyer som treffer langt bredere enn planlagt.
Kan noen forklare oppsettet?
Hvis du må grave gjennom gamle Teams kanaler eller lete etter pensjonerte kolleger for å forstå en policy, har du sannsynligvis funnet teknisk gjeld.
En liten gulrot på tampen🥕
Jeg er glad i å tegne, det gir bedre rom for diskusjon og gir ofte en bedre samlet forståelse, ofte oppdager man at noen har tenkt noe og noen andre har tenkte noe helt annet men begge snakker om den samme tingen. Merill har laget en "CA visualiser" hvor du mater inn CA policyer og får i retur en PowerPoint som visuelt viser hvordan policyene henger sammen, det anbefales på det sterkeste idPowerApp
Min vurdering
Mange ser på Conditional Access som et implementeringsprosjekt.
Jeg mener det er en driftsdisiplin.
Det handler ikke om å lage flest mulig policyer. Det handler om å forstå hvilke policyer du faktisk trenger.
Et enkelt, ryddig og godt dokumentert oppsett vil nesten alltid være bedre enn en samling historiske kompromisser som ingen lenger har full kontroll på.
Og ja, det gjelder selv om antallet policyer ser imponerende ut på skjermbildet.
Conditional Access kan gi en imponerende følelse av kontroll. Litt som å låse inngangsdøra og samtidig la terrassedøra stå på vidt gap. "Trusted Locations" har nemlig en tendens til å bli veldig, veldig trusted. Whitelistet alle kontor IP`er? Kutt ut 🙄😠
Oppsummert
Conditional Access er sannsynligvis den viktigste sikkerhetskontrollen mange Microsoft 365-miljøer har.
Nettopp derfor bør den også få jevnlig vedlikehold.
Ta en titt på policyene dine. Let etter gamle unntak. Se på gruppene som er ekskludert. Kjør noen What If analyser.
Det er betydelig hyggeligere å rydde opp på egne premisser enn å oppdage gjelden når noe plutselig slutter å fungere.
Bjørnar&AI
Comments