Når tenanten er kompromittert: nødtilgang, break-glass og kontinuitet i identitetsadministrasjon

Åpne virksomhetens IKT-beredskapsplan og finn avsnittet om hva som skjer ved en alvorlig identitetskompromittering. I de fleste planer står det en variant av: «IT-avdelingen sperrer berørte kontoer og gjenoppretter tilgang.»

Still deretter tre spørsmål:

1. Hvem konkret gjør det, og hva skjer hvis nettopp den personens konto er en av de kompromitterte?

2. Hvordan logger de seg inn, hvis den betingede tilgangspolicyen krever en enhet som er meldt kompatibel, og enhetsadministrasjonen er en del av det som er berørt?

3. Hvordan dokumenteres hva som ble gjort, når det som gjøres er hastetiltak utenom normal prosess?

Spørsmål 1 og 2 handler om nødtilgang. Spørsmål 3 handler om at en hendelse alltid etterfølges av en gransking, og at granskingen er lettere eller vanskeligere avhengig av beslutninger tatt før hendelsen.

Nødtilgangskontoer: Microsofts oppskrift, og hvorfor den ofte er feil implementert

Microsofts anbefaling er presis: organisasjoner bør ha to skybaserte nødtilgangskontoer permanent tildelt Global Administrator-rollen. Kontoene tilhører ikke navngitte personer og er begrenset til nødsituasjoner der normale kontoer ikke kan brukes eller alle andre administratorer er utestengt ved et uhell.

Fire krav følger med, og alle fire brytes rutinemessig:

Ekskludert fra betingede tilgangspolicyer som blokkerer eller begrenser pålogging. Microsofts begrunnelse er direkte: en nødtilgangskonto som er underlagt en policy som krever MFA på en bestemt måte, en kompatibel enhet eller en annen kontroll, kan bli ubrukelig i nøyaktig de situasjonene den er laget for. Anbefalt praksis er en egen sikkerhetsgruppe — for eksempel EmergencyAccess — som ekskluderes fra de relevante policyene. Policyer i rapport-modus trenger ikke ekskludering.

Sterk, phishingresistent autentisering, ulik den vanlige. Microsoft anbefaler passnøkkel (FIDO2) som førstevalg, alternativt sertifikatbasert autentisering der virksomheten allerede har PKI. Metoden skal være en annen enn den administratorene bruker til daglig — poenget er at et kompromiss av den ordinære autentiseringsmekanismen ikke også skal ramme nødtilgangen.

Skybaserte, ikke synkroniserte fra lokal katalog. En konto som stammer fra lokal AD, er avhengig av at lokal AD fungerer.

Testet. En nødtilgangskonto som ikke er verifisert de siste tolv månedene, er en antakelse, ikke en kontroll.

Det andre punktet krever en presisering som ofte overses: Microsoft har innført obligatorisk multifaktorautentisering for administrasjonsflatene. Fase 1 fra oktober 2024 dekker Azure-portalen, Entra admin center og Intune admin center for alle opprett-, les-, oppdater- og slettehandlinger, utvidet til Microsoft 365 admin center fra februar 2025. Fase 2 begynte 1. oktober 2025 og dekker Azure CLI, Azure PowerShell, Azure-mobilappen, IaC-verktøy og REST-endepunkter for skriveoperasjoner. Nødtilgangskontoer må derfor ha en MFA-metode som oppfyller kravet — de kan ikke være unntatt fra MFA som sådan, bare fra de betingede tilgangspolicyene som legger på ytterligere betingelser.

Kontinuitet i selve administrasjonsevnen

Nødtilgang løser tilgangsproblemet. Det løser ikke kapasitetsproblemet.

Under en alvorlig hendelse er de operative behovene som regel: sperre et større antall kontoer raskt, tilbakestille legitimasjon for en definert populasjon, fjerne bestemte gruppemedlemskaper, tilbakekalle aktive økter, og gjøre det samme igjen når man oppdager at avgrensningen var for snever.

Dette er masseoperasjoner under tidspress, utført av folk som ikke har sovet. Det er den kombinasjonen som produserer de dyreste feilene: feil gruppe deaktivert, feil filter i skriptet, en operasjon som stopper halvveis på grunn av struping i Microsoft Graph uten at noen merker det.

Her er det verdt å være ærlig om et paradoks i den styrte modellen. En arkitektur der ingen har stående administratorrettigheter og alt går gjennom godkjenning, er sikrere til daglig — men den må håndtere at det oppstår situasjoner der godkjenningsleddet ikke kan vente. Løsningen er ikke å hoppe over kontrollen, men å designe for hastebehandling: en definert nødprosedyre der handlingen kan utføres umiddelbart, med etterfølgende dokumentert godkjenning, og der selve bruken av hasteveien er en registrert hendelse i seg selv.

En virksomhet som ikke har definert dette på forhånd, kommer til å improvisere det under press, og improvisasjonen etterlater ingen dokumentasjon.

Det regulatoriske ankeret

Kraftberedskapsforskriften § 7-7 krever registrering av alle sikkerhetsbrudd og sikkerhetshendelser, med varslings- og rapporteringsplikt til beredskapsmyndigheten ved umiddelbar risiko for driftskontrollsystemets funksjon. KBO-enheter har i tillegg KraftCERT/InfraCERT som sektorvist responsmiljø.

Digitalsikkerhetsloven pålegger varsling om hendelser som virker betydelig inn på leveransen, uten unødig opphold og uten hinder av taushetsplikt. NSM er nasjonalt kontaktpunkt og nasjonalt responsmiljø. De eksakte fristene bør kontrolleres mot digitalsikkerhetsforskriften.

Styringsforskriften § 20 krever registrering, undersøkelse og gransking av fare- og ulykkessituasjoner, og § 22 krever avviksbehandling med årsaksanalyse.

Felles for alle tre: rapporteringen krever at man vet hva som skjedde. Under en hendelse produseres det store mengder handlinger på kort tid. Om disse handlingene er dokumentert mens de utføres, eller må rekonstrueres i etterkant fra logger og hukommelse, avgjøres av arkitekturen — ikke av viljen til å dokumentere.

Fire designvalg som betaler seg under en hendelse

1. Kontinuerlig synkronisert referansetilstand. For å vite hva som er endret, må man vite hva som var. En løpende oppdatert, søkbar kopi av hele boet — brukere, grupper, enheter, Intune, Autopilot, postkasser, apper, lisenser — gjør «hva så det ut som før hendelsen» til et oppslag. Uten det er svaret en rekonstruksjon.

2. Masseoperasjoner med bevart sporbarhet. Muligheten til å endre mange poster i én operasjon, der hver enkelt endring likevel får sin egen tilregnelige post, er en hendelseshåndteringsegenskap først og fremst. Den lar en respons være rask uten å bli udokumentert, og den viser presist hvilke objekter som faktisk ble behandlet når en operasjon stopper halvveis.

3. Delegering som fungerer når nøkkelpersonene er utilgjengelige. Hvis kapasiteten til å handle er konsentrert i to personer, er beredskapen begrenset av at begge er tilgjengelige. En modell der flere kan foreslå og et definert sett kan godkjenne, skalerer bedre under press enn en modell der få har rettigheter.

4. Nødprosedyren er dokumentert og øvd. Inkludert: hvem som kan påberope den, hva som kan gjøres uten forhåndsgodkjenning, hvordan bruken registreres, og hvordan etterfølgende godkjenning gjennomføres. Dette er en organisatorisk beslutning, ikke en produktfunksjon.

Beredskapskortet som bør ligge klart

Erfaring fra hendelseshåndtering tilsier at det som ikke er skrevet ned på forhånd, ikke blir gjort riktig under press. For identitetssiden bør følgende foreligge som et konkret, oppdatert dokument — ikke som et avsnitt i en 80-siders plan:

• Hvor nødtilgangskontoenes legitimasjon oppbevares, hvem som er autorisert til å hente den ut, og hvordan uttaket registreres.
• Hvilke betingede tilgangspolicyer nødtilgangskontoene er ekskludert fra, og dato for siste verifikasjon.
• Navn og kontaktinformasjon på de som kan godkjenne hastetiltak, med minst tre navn i ulik geografi eller tidssone.
• Hvilke grupper som er kritiske — de som styrer fjerntilgang, privilegerte roller og tilgang til kraftsensitiv informasjon — med eier og forventet medlemsantall, slik at avvik er synlig umiddelbart.
• Rapporteringsveiene med navngitt mottaker: sektortilsynsmyndighet, NSM, sektorvist responsmiljø, og internt til ledelsen.
• Hvilke handlinger som kan utføres uten forhåndsgodkjenning, og hvordan de skal etterdokumenteres.

Punktet om forventet medlemsantall i kritiske grupper er undervurdert. Det er den enkleste deteksjonsmekanismen som finnes: en gruppe som skulle hatt tolv medlemmer og har fjorten, er et signal som ikke krever noe verktøy for å tolke — bare at noen kjenner tallet.

Om øvelser

Det er verdt å skille mellom to øvelsestyper som ofte blandes sammen.

Nødtilgangstest: logg inn med nødtilgangskontoen, verifiser at den fungerer, verifiser at ekskluderingene fortsatt gjelder etter siste policyendring, dokumenter. Bør gjøres minst hvert halvår, og alltid etter endringer i betinget tilgang. Tar en time.

Tabletop-øvelse på identitetskompromittering: anta at en administratorkonto er kompromittert og har vært det i to uker. Gå gjennom hvordan man fastslår hva som er endret, hvordan man avgrenser, hvordan man rapporterer innenfor fristen, og hvem som beslutter hva. Tar en dag, og avdekker som regel at spørsmålet «hva ble faktisk endret, av hvem, med hvilken begrunnelse» ikke lar seg besvare med den nødvendige presisjonen.

Det er den erkjennelsen som er verdt hele øvelsen.

Kilder

• Microsoft, Manage emergency access admin accounts — https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
• Microsoft, Secure access practices for administrators in Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning
• Microsoft, Plan for mandatory Microsoft Entra multifactor authentication — https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication
• Kraftberedskapsforskriften (FOR-2012-12-07-1157) §§ 2-5, 2-6, 7-7 — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• NSM, varsling om hendelser etter digitalsikkerhetsloven — https://nsm.no/regelverk-og-hjelp/digitalsikkerhetsloven-og-forskriften/varsle-om-hendelser-etter-digitalsikkerhetsloven
• Havtil, styringsforskriften §§ 20 og 22 — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• KraftCERT/InfraCERT — https://www.kraftcert.no/no/
• CISA, Emergency Directive 24-02 (Midnight Blizzard, kompromitterte skykontoer) — https://www.cisa.gov/news-events/directives/ed-24-02-mitigating-significant-risk-nation-state-compromise-microsoft-corporate-email-system-closed