Skriptgjelden

PowerShell-mappen, app-registreringene og hemmelighetene ingen eier

Dette er ikke slurv. Det er det rasjonelle utfallet av at Entra ID mangler et delegeringslag: når portalen ikke lar deg gi bort en avgrenset oppgave, skriver du et skript som gjør den, og kjører det selv.

Hvordan gjelden bygger seg opp

Livsløpet er forutsigbart:

1. En administrator skriver et skript for en repeterende oppgave — opprette bruker med riktige grupper, rydde i lisenser, generere en rapport.

2. Skriptet kjøres interaktivt med administratorens egne rettigheter. Det virker.

3. Noen ber om at det skal kjøre automatisk om natten. Interaktiv innlogging går ikke, så det opprettes en app-registrering med en klienthemmelighet.

4. Rettighetene settes bredt, fordi det er raskere enn å finne det minimale settet — typisk Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All som application permissions, med admin consent.

5. Skriptet legges som en scheduled task på en server, eller i en Azure Automation-konto.

6. Administratoren bytter jobb.

Nå har du en tjenesteidentitet med skrivetilgang til hele katalogen, som kjører kode ingen har lest på to år, autentisert med en hemmelighet som ligger i klartekst i skriptfilen eller i en variabel noen satte en gang.

Hvorfor application permissions er den farlige delen

Skillet mellom delegerte rettigheter og applikasjonsrettigheter er det tekniske kjernepunktet, og det underkommuniseres.

Delegerte rettigheter utøves på vegne av en innlogget bruker. Den effektive tilgangen er snittet av appens rettighet og brukerens egen rolle — en app med User.ReadWrite.All delegert kan ikke gjøre noe brukeren ikke selv kunne gjort.

Applikasjonsrettigheter har ingen bruker. Tjenesteprinsipalen handler i eget navn, uten noe rollesnitt, uten Conditional Access-policy som treffer en bruker, uten MFA. En app-registrering med RoleManagement.ReadWrite.Directory kan tildele seg selv Global Administrator. Den kjører like godt klokken 03:00 fra en kompromittert byggeserver som fra din egen konsoll.

Det er derfor «vi har fjernet alle permanente administratorroller» ofte er en halv sannhet. Rollene er borte. Tjenesteprinsipalene som gjør det samme arbeidet, står igjen — og de er sjelden med i den samme gjennomgangen.

Hemmeligheter som utløper på verst mulig tidspunkt

Klienthemmeligheter har en utløpsdato satt ved opprettelse. Utfallene er to, og begge er dårlige:

• Hemmeligheten utløper, nattjobben stopper, og feilen oppdages først når noen lurer på hvorfor nye ansatte ikke har fått lisens på tre uker.
• Hemmeligheten fornyes i panikk med lengst mulig levetid, uten at rettighetsomfanget noen gang blir revurdert.

Sertifikatbasert autentisering og managed identities løser hemmelighetsproblemet teknisk, men ikke styringsproblemet: hvem godkjente at denne identiteten skal kunne skrive til katalogen, og hvor står det?

Loggen som ville avslørt det, må kjøpes separat

Entra audit log viser at en endring skjedde og hvilken tjenesteprinsipal som gjorde den. Den viser ikke hvilken kode som kalte, med hvilken parameter, fra hvilken vert. Det gjør Microsoft Graph Activity Logs, som logger hver HTTP-forespørsel Graph mottar for tenanten — men den krever P1 eller P2, en Security Administrator til å sette opp diagnostic settings, et Azure-abonnement, og den har ingen retensjon i portalen. Den finnes ikke med mindre du aktivt ruter den til Log Analytics, en storage account eller Event Hubs, og betaler for volumet: rundt 14 GiB per måned ved 1 000 brukere.

De færreste mellomstore norske selskaper har dette på. Det betyr at API-kallene som endrer katalogen deres, i praksis ikke er logget utover 30 dager med grovkornet audit-informasjon.

Regnestykket ingen gjør

Skriptgjelden ser gratis ut fordi arbeidet allerede er gjort. Den reelle kostnaden er fire poster:

• Nøkkelpersonrisiko. Skriptene kan leses av én person. Er vedkommende sykmeldt under en omorganisering, står prosessen.
• Angrepsflate. Hver app-registrering med brede applikasjonsrettigheter er en permanent bakdør som ikke omfattes av Conditional Access.
• Uverifiserbarhet. Du kan ikke vise revisor hva skriptet gjorde i mars, bare at noe skjedde.
• Duplisering. I et konsern med flere tenanter finnes samme skript i fem varianter, som har divergert.

Hva dette betyr for Entra Logic

Entra Logics utførelsesmotor er bygget på nøyaktig den teknologien IT allerede stoler på — PowerShell mot Microsoft Graph. Det er ikke et proprietært skriptspråk administratorene må lære. Forskjellen er hvor koden lever og hva som utløser den.

I stedet for at n administratorer har hver sin lokale kopi og hver sin app-registrering, kjøres utførelsen sentralt, fra én versjonert kodebase, utløst av en godkjent ordre — ikke av en scheduled task ingen eier. Tjenesteidentiteten er én, dens rettigheter er ett sted, og hver kjøring har en godkjenner og en begrunnelse knyttet til seg.

Det er også her multi-tenant-arkitekturen gir en konkret gevinst: samme operasjon, samme kode, mot 58 selskaper — i stedet for 58 divergerende varianter av samme skript.

Nødvendig forbehold: dette erstatter Entra Logics egne utførelser og de operasjonene som legges inn i portalen. Eksisterende lokale skript i en kundes miljø forsvinner ikke av seg selv — de må kartlegges og avvikles som et eget arbeid. Enhver fremstilling som antyder noe annet, vil ikke overleve første tekniske møte.

Kilder

• Microsoft Learn — Overview of permissions and consent in the Microsoft identity platform
• Microsoft Learn — Microsoft Graph permissions reference
• Microsoft Learn — Microsoft Graph activity logs overview
• Microsoft Learn — Data retention for Microsoft Entra monitoring and health