Skriptspredning, tjenestekontoer og nøkkelpersonrisiko: automatiseringen ingen har oversikt over

I nesten enhver IT-avdeling i norsk kritisk infrastruktur finnes det et lag med automatisering som ikke står i noe arkitekturdiagram: PowerShell-skript på enkeltadministratorers maskiner, planlagte oppgaver på en gammel server, en Azure Automation-runbook fra 2021, et Python-skript som kjører fra en virtuell maskin ingen har omstartet på to år.

De gjør reelt arbeid. De oppretter brukere, synkroniserer grupper fra fagsystemer, rydder i lisenser, genererer rapporter til ledelsen. De kjører som regel under en brukerkonto med forhøyede rettigheter, ofte med legitimasjon lagret i skriptet eller i en fil ved siden av. De er skrevet av en person som fortsatt jobber der, eller som ikke gjør det.

Dette laget har fire egenskaper som gjør det til en av de mest undervurderte risikoene i identitetsplattformen:

1. Det er ikke inventarisert. Ingen kan liste alle skript som gjør endringer i katalogen.

2. Det er ikke versjonert. Endringer i et skript etterlater ingen historikk.

3. Det er ikke revidert. Handlinger utført av skriptet fremstår i loggen som handlinger utført av tjenestekontoen, uten begrunnelse.

4. Det er nøkkelpersonavhengig. Én person forstår hvorfor det finnes.

To datoer som allerede har brutt ting

Microsofts utfasing av de gamle PowerShell-modulene er den enkeltendringen som har avdekket mest skjult automatisering i norske virksomheter de siste to årene.

Azure AD-, Azure AD Preview- og MSOnline-modulene ble erklært utdaterte 30. mars 2024, med støtte kun for kritiske sikkerhetsfikser fram til 30. mars 2025. MSOnline ble pensjonert 30. mai 2025. Anbefalt vei videre er Microsoft Graph PowerShell SDK, eventuelt den nyere Microsoft Entra PowerShell-modulen, som ifølge Microsofts migrasjons-FAQ gir over 90 % paritet med de gamle Azure AD-kommandoene.

Den andre datoen er 1. oktober 2025. Fra da av begynte Microsoft gradvis å håndheve multifaktorautentisering også for Azure CLI, Azure PowerShell, Azure mobilapp, IaC-verktøy og REST-endepunkter, for alle opprettelses-, oppdaterings- og slettehandlinger. Leseoperasjoner er unntatt. Microsofts eksplisitte anbefaling er å migrere brukerbaserte tjenestekontoer til arbeidsbelastningsidentiteter.

Konsekvensen for det skjulte automatiseringslaget er direkte: skript som autentiserer som en brukerkonto uten MFA, og som gjør skriveoperasjoner, slutter å virke. I mange virksomheter har dette allerede skjedd, og feilen ble håndtert ved at noen la til et unntak i stedet for å migrere. Det er en teknisk gjeld som forfaller.

Hvorfor dette er en beredskapssak, ikke bare en driftssak

For virksomheter i kritisk infrastruktur er argumentet sterkere enn «dette er uryddig».

Nøkkelpersonrisiko er en beredskapsrisiko. Kraftberedskapsforskriften bygger på at KBO-enheter skal kunne opprettholde funksjon. Hvis evnen til å gjennomføre masseendringer i identitetsplattformen — for eksempel å stenge ute en kompromittert gruppe kontoer raskt — avhenger av ett skript på én persons maskin, og den personen er på fjelltur, er det en beredskapssvakhet uavhengig av hva beredskapsplanen sier.

Uidentifiserte tjenestekontoer bryter med sporbarhetskravet. NSMs grunnprinsipp 2.6.1 krever tilgangskontroll med sporbarhet til ansvarlig person. En tjenestekonto som utfører hundre endringer i uken uten at noen av dem kan knyttes til en beslutning eller en person, oppfyller ikke dette. Grunnprinsipp 2.6.2 krever en formell prosess for administrasjon av kontoer og rettigheter gjennom hele livssyklusen — også for tjenestekontoer.

Skript med innebygd legitimasjon er en direkte angrepsvektor. Angripere som får fotfeste på en administrators arbeidsstasjon, leter etter nettopp dette. Norsk Hydro-hendelsen i 2019 eskalerte fra et fotfeste til full kontroll nettopp gjennom administrative rettigheter og domenekontrollere.

Avviksbehandling forutsetter at man vet hva som skjedde. Styringsforskriften § 22 krever årsaksanalyse. Når en uønsket masseendring har skjedd, og den ble utført av en tjenestekonto som kjører et skript ingen har lest på tre år, er årsaksanalysen et arkeologisk prosjekt.

De tekniske grensene som tvinger fram struktur

Selv der automatiseringen er velmenende og velskrevet, setter plattformen grenser som gjør ad hoc-tilnærmingen skjør.

Microsoft Graph har tjenestespesifikke struperegler. For identitets- og katalogobjekter gjelder blant annet en grense per applikasjon og tenant på 3 500 ResourceUnits per 10 sekunder for små tenanter, 5 000 for mellomstore (50–500 brukere) og 8 000 for store (over 500 brukere). I tillegg gjelder en skrivekvote per tenant på 18 000 forespørsler per fem minutter, og per applikasjon og tenant 3 000 skriveforespørsler per 2 minutter og 30 sekunder. Kostnaden varierer per kall — GET /groups/{id}/transitiveMembers koster 5 ResourceUnits, bruk av $select gir én enhet rabatt, $expand koster én ekstra.

I praksis betyr dette at et naivt skrevet skript som skal endre noen tusen objekter under en omorganisering, kommer til å bli strupt midtveis. Hva som da skjer — om skriptet gjenopptar, hvilke objekter som ble behandlet, hvilke som ikke ble det — avhenger av om den som skrev det tenkte på det. Ofte gjorde de ikke det, og resultatet er en delvis gjennomført masseendring uten fullstendig oversikt over hva som faktisk ble utført.

Dette er en av de mest undervurderte kildene til feil i identitetsplattformen: ikke ondsinnede handlinger, men halvferdige.

Hva sentralisert utførelse endrer

Entra Logic bygger på nøyaktig de samme byggeklossene som skriptene gjør — PowerShell og Microsoft Graph. Det er et poeng i seg selv: dette er standardmåten å automatisere Entra ID på, og ikke et proprietært språk administratorer må lære. Forskjellen ligger i hvor utførelsen skjer og hva som følger med den.

Sentralisert, versjonert utførelse. Automatiseringen kjører ett sted, ikke på enkeltmaskiner. Hva som ble kjørt, i hvilken versjon, mot hvilke objekter, er kjent.

Hver handling har en ordre bak seg. En masseendring på tusen objekter gjennomføres som én operasjon, men hver enkelt endring får sin egen tilregnelige post med begrunnelse og godkjenner. Dette er både en revisjonsegenskap og en driftsegenskap: en delvis gjennomført operasjon er synlig som delvis gjennomført, per objekt.

Ingen legitimasjon i omløp. Det er ikke nødvendig for en administrator å ha en lagret credential for å kunne gjøre jobben, fordi jobben gjøres av motoren etter godkjenning.

Nøkkelpersonavhengigheten forsvinner. Når ingen enkeltperson sitter med alle nøklene og alle skriptene, er organisasjonen ikke lenger sårbar for at akkurat den personen er syk, på ferie eller har sluttet.

To ærlige forbehold. For det første er omfanget av i hvilken grad dette faktisk erstatter eksisterende lokale skript hos en gitt kunde — i motsetning til å styre nye operasjoner — noe som må avklares konkret i en teknisk gjennomgang; det avhenger av hva skriptene gjør. For det andre løser ikke sentralisering av utførelse i Entra-domenet de skriptene som gjør noe helt annet, for eksempel integrasjoner mot fagsystemer eller OT-nære verktøy.

Tre oppgaver med umiddelbar verdi

1. Inventarisér tjenestekontoene. List alle brukerkontoer i tenanten som har autentisert seg de siste 30 dagene uten interaktiv innlogging, og finn ut hva hver av dem gjør. Antallet pleier å overraske.

2. Finn skriptene før de finner deg. Spør hver enkelt i driftsteamet hvilke skript de har som gjør endringer i Entra eller M365. Ikke som revisjon — som kartlegging. Svarene kommer bare hvis spørsmålet ikke er truende.

3. Test om noe kjører på utdaterte moduler. MSOnline er pensjonert. Alt som fortsatt kaller den, virker ikke lenger, uansett om noen har oppdaget det.

Kilder

• Microsoft, Azure AD PowerShell to Microsoft Graph and Microsoft Entra PowerShell migration FAQ (MSOnline pensjonert 30.05.2025) — https://learn.microsoft.com/en-us/powershell/azure/active-directory/migration-faq?view=azureadps-2.0
• Microsoft, Plan for mandatory Microsoft Entra multifactor authentication (fase 2 fra 01.10.2025) — https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication
• Microsoft Graph, Service-specific throttling limits — https://learn.microsoft.com/en-us/graph/throttling-limits
• NSM, Grunnprinsipper for IKT-sikkerhet v2.1, tiltak 2.6.1–2.6.3 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf
• Havtil, styringsforskriften § 22 — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• Microsoft/Norsk Hydro om angrepet i 2019 (eskalering via administrative rettigheter) — https://news.microsoft.com/source/features/digital-transformation/hackers-hit-norsk-hydro-ransomware-company-responded-transparency/