Fund om roller går igen i Azure-test. Det behøver ikke være spektakulært: for mange er ejere af et abonnement, en leverandør har stadig bidragyderrollen fra et afsluttet projekt, eller en gruppe har fået en bred rolle højt i hierarkiet, så den gælder alt derunder. Fundene er alligevel blandt dem, der vægtes højest, fordi rollerne bestemmer, hvad en kompromitteret konto kan gøre. Svaret på, hvordan I rydder op, hviler på Microsofts egen beskrivelse af, hvordan tildelinger virker, og på de anbefalinger, Microsoft giver for at holde dem små.
Sådan virker en rolletildeling
Microsoft beskriver en rolletildeling som tre ting sat sammen: hvem der får adgang, hvilken rolle de får, og på hvilket niveau. Hvem kan være en bruger, en gruppe eller en identitet for et program. Rollen er en samling af tilladelser, fx at læse, ændre eller slette. Niveauet kan være en administrationsgruppe, et abonnement, en ressourcegruppe eller en enkelt ressource.
To egenskaber er vigtige for at forstå fundene:
- Tildelinger arves nedad · niveauerne står i et forhold mellem forælder og barn. En rolle på abonnementet gælder også i alle ressourcegrupper og ressourcer i abonnementet.
- Rettigheder lægges sammen · har en person flere tildelinger, er den samlede adgang summen af dem. En læserolle på en ressourcegruppe begrænser ikke en bidragyderrolle, personen allerede har på hele abonnementet.
Dertil kommer, at grupper kan være medlem af andre grupper, og at en tildeling til en overordnet gruppe gælder for alle i de underliggende. Det gør det svært at se, hvem der i praksis har adgang, uden at følge kæden.
Ejer, bidragyder og læser
De tre mest brugte indbyggede roller er nemme at kende:
- Ejer · fuld adgang til ressourcerne og ret til at give andre adgang.
- Bidragyder · kan oprette og ændre ressourcer, men ikke give andre adgang.
- Læser · kan se ressourcerne, men ikke ændre dem.
Det lyder, som om bidragyderen er ufarlig sammenlignet med ejeren. Det er ikke altid tilfældet. Microsoft skriver fx, at roller med ret til at administrere lagerkonti også kan hente kontoens adgangsnøgler, og med dem kan man nå alle data i kontoen. En bred bidragyderrolle kan derfor give adgang til data, selvom den ikke er tænkt sådan. → Lagerkonti og databaser i Azure
Typiske fund om roller
En test kommenterer typisk nogle af disse forhold:
- For mange ejere af abonnementet · Microsoft anbefaler højst tre ejere pr. abonnement for at begrænse skaden, hvis en ejer bliver kompromitteret.
- Brede roller højt oppe · ejer eller bidragyder på abonnement eller administrationsgruppe, hvor en ressourcegruppe havde været nok.
- Roller tildelt personer direkte · i stedet for til grupper, hvilket gør oversigten uoverskuelig.
- Gamle tildelinger til leverandører · konti fra projekter, der er afsluttet.
- Egne roller med jokertegn · selvdefinerede roller, der giver alle handlinger på en tjeneste, også dem, der tilføjes senere. Microsoft fraråder det.
- Permanente roller til administratorer · hvor tidsbegrænset adgang havde været muligt. → Tidsbegrænsede administratorrettigheder
- Tjenesteidentiteter med brede roller · programmer eller automatisering, der er ejer af mere, end opgaven kræver.
Hvorfor fundene vægtes højt
En rolle i Azure er en direkte vej til at ændre, slette eller læse. Hvis en konto med ejerrollen på et abonnement bliver kompromitteret, kan den give sig selv eller andre adgang til alt i abonnementet. Hvis en tjenesteidentitet med bidragyderrollen ligger i et script, der lækker, rækker skaden lige så langt som rollen.
Testen viser typisk sammenhængen: fra en konto med en tilsyneladende beskeden rolle, via arv og gruppemedlemskab, til en adgang, ingen havde planlagt. Den kæde er mere værd end en liste over tildelinger, fordi den viser, hvilke led der skal brydes.
For en MSP er fundene ekstra vigtige. Hvis leverandøren har ejer- eller bidragyderroller hos mange kunder gennem de samme konti, kan én kompromitteret konto række ind i flere kunders abonnementer på én gang. Det gør leverandørens egne konti til et selvstændigt testområde. → Delegeret administration hos partnere
Sådan rydder I op
Microsofts anbefalinger kan omsættes til en plan på begrebsniveau:
- Lav en oversigt · hvem har ejer- og bidragyderroller, på hvilket niveau, og hvorfor?
- Skær ned på ejerne · til de få, der skal kunne give andre adgang til hele abonnementet.
- Flyt tildelinger nedad · fra abonnement til ressourcegruppe eller ressource, hvor det dækker behovet.
- Tildel til grupper · ikke til personer, så adgang følger funktion.
- Erstat brede roller med jobroller · Microsoft anbefaler at undgå privilegerede administratorroller, hvor en rolle til en bestemt funktion kan bruges i stedet.
- Gør administratoradgang tidsbegrænset · så rettighederne kun er aktive, når de bruges.
Planen hænger sammen med princippet om mindst mulig adgang, som gælder både lokalt og i cloud. → Mindst mulig adgang
Brug resultatet fra testen til at vælge, hvor I starter. De tildelinger, der indgik i en kæde i rapporten, kommer først. Derefter ejerne på abonnementsniveau, og til sidst de mange små tildelinger, der mest gør oversigten uklar.
Ryd op i etaper og med de berørte. En udvikler, der mister bidragyderrollen dagen før en udrulning, finder en anden vej. Aftal med projekter og leverandører, hvilke rettigheder de reelt har brug for, og giv dem netop det.
Det, testen skal have med
- En konto med en typisk rolle · fx den rolle, en udvikler eller en driftsleverandør normalt får.
- Læseadgang til tildelingerne · så testeren kan se hele billedet, også det, kontoen ikke selv kan nå.
- Liste over kendte leverandører · med de roller, de bevidst har.
- Overblik over administrationsgrupper · hvis I bruger dem til at samle abonnementer.
Det skal I lade være med
- At fjerne roller uden at spørge ejerne af løsningerne. Driften kan stoppe.
- At give ejerrollen, fordi bidragyder ikke var nok. Find den rolle, der passer, eller lav en snæver rolle.
- At lave egne roller med jokertegn. De vokser med tjenesten.
- At glemme tjenesteidentiteter. De kan have bredere roller end personer.
- At rydde op én gang. Uden en fast gennemgang vokser antallet igen. → Oprydning efter testen
Hvad kan og ikke kan konkluderes
Testen viser, hvilke tildelinger der fandtes, og hvad udvalgte konti og identiteter kunne gøre med dem på testtidspunktet. Den kan ikke afgøre, om en bestemt leverandør eller medarbejder har et legitimt behov for sin rolle. Den dækker heller ikke roller i Entra ID, som er et andet system med egne administratorroller, medmindre de var med i opdraget. → Administrative roller i Entra ID
Tjekliste til roller i Azure
- ☐ Har hvert abonnement kun få ejere?
- ☐ Er brede roller flyttet så langt ned som muligt?
- ☐ Er roller tildelt grupper frem for personer?
- ☐ Er gamle leverandørtildelinger fjernet?
- ☐ Er egne roller uden jokertegn?
- ☐ Er administratorroller tidsbegrænsede?
Kilder
- Microsoft Learn: What is Azure role-based access control?: rolletildeling som identitet, rolle og niveau, de fire niveauer, arv mellem forælder og barn, gruppemedlemskab og at rettigheder lægges sammen.
- Microsoft Learn: Best practices for Azure RBAC: mindst mulig adgang, højst tre ejere pr. abonnement, færre privilegerede administratorroller, smalt niveau, tidsbegrænset adgang, grupper frem for personer og ingen jokertegn i egne roller.
- Microsoft Learn: Remediate anonymous read access to blob data: roller, der kan administrere lagerkonti, kan hente adgangsnøgler og dermed nå alle data i kontoen.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Nøgler og hemmeligheder i cloud · Tidsbegrænsede administratorrettigheder
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
