Når en penetrationstest viser, at testeren kunne komme fra en almindelig brugerkonto til hele miljøet, er forklaringen ikke nødvendigvis én enkelt fejl. Den ligger i rettigheder, der tilsammen åbnede en vej: en gruppe med for mange medlemmer, en tjenestekonto med for bred adgang, en delt mappe, alle kunne læse. Princippet bag rettelserne hedder mindst mulig adgang, og det hviler på en enkel regel: hver konto, hvert program og hver proces skal kun have den adgang, opgaven kræver, og kun så længe den kræver det.
Hvad princippet siger
I den amerikanske standardorganisation NIST’s ordliste beskrives mindst mulig adgang som et sikkerhedsprincip, hvor et system begrænser adgangsrettighederne for brugere, og for processer, der handler på deres vegne, til det nødvendige minimum for de tildelte opgaver. Princippet gælder altså ikke kun personer. Det gælder også programmer, integrationer og automatiserede job. Og det handler både om, hvad en konto må, og om, hvor den må det fra og hvor længe.
Pointen er at begrænse skaden. Hvis en konto bliver misbrugt, kan angriberen kun det, kontoen kan. En konto med smal adgang giver en smal skade. En konto med administratorrettigheder overalt giver angriberen hele miljøet.
Hvor rettighederne gemmer sig
Microsoft anbefaler i sin vejledning om sikring af Active Directory at undgå for brede rettigheder og at kontrollere fem områder: kataloget selv, medlemsservere, arbejdsstationer, programmer og datalagre. Listen er en god disposition for oprydningen efter en test, også uden for Active Directory.
- Kataloget · medlemskab af de grupper, der giver de højeste rettigheder, og delegerede rettigheder over brugere og computere. → Privilegerede grupper i Active Directory
- Servere · hvem er lokal administrator, og hvilke konti kan logge på?
- Klienter · har brugerne administratorrettigheder på egen maskine? → Brugere med administratorrettigheder på egen maskine
- Programmer · roller i forretningssystemer og administrationsadgang til de systemer, driften bruger. → Roller og rettigheder i forretningssystemer
- Data · rettigheder på delte mapper, fildelinger og lagre i cloud. → Delte mapper og filservere
Dertil kommer cloudplatformene, hvor roller kan være tildelt på et højt niveau og arvet ned gennem abonnementer og ressourcer. → Roller i Azure
Hvorfor rettighederne vokser
Rettigheder bliver ikke fjernet af sig selv. En medarbejder skifter job og beholder den gamle adgang. Et projekt får administratorrettigheder til en opsætning og glemmer at afgive dem. En leverandør får bred adgang til fejlfinding, som aldrig bliver lukket. Hver tildeling var begrundet, da den blev givet.
Det betyder, at mindst mulig adgang ikke kan nås ved én oprydning. Det kræver, at nye tildelinger følger princippet, og at eksisterende tildelinger bliver gennemgået med faste mellemrum.
Sådan skærer I ned uden at stoppe arbejdet
Den største risiko ved at fjerne rettigheder er, at noget holder op med at virke. Arbejd derfor i en rækkefølge, der gør det muligt at se konsekvensen.
- Kortlæg brugen · find ud af, hvad kontoen eller gruppen faktisk bruger sine rettigheder til. Logning af brug giver et bedre svar end at spørge.
- Fjern det ubrugte først · rettigheder, der ikke er brugt i lang tid, kan fjernes med lille risiko.
- Erstat brede rettigheder med smalle · en konto, der er domæneadministrator for at kunne nulstille adgangskoder, skal have netop den rettighed.
- Tidsbegræns det, der sjældent bruges · høje rettigheder kan gives, når de skal bruges, i stedet for at ligge fast. → Tidsbegrænsede administratorrettigheder
- Hav en vej tilbage · notér, hvad der er fjernet, så det kan gives igen, hvis det viser sig nødvendigt.
AWS beskriver i sin dokumentation om rettigheder, at man kan starte med brede rettigheder, mens man finder ud af, hvad en arbejdsopgave kræver, og derefter arbejde sig ned mod mindst mulig adgang. Samme dokumentation anbefaler at gennemgå og fjerne ubrugte brugere, roller, rettigheder og nøgler jævnligt. Det er en realistisk tilgang i alle miljøer: det første skridt behøver ikke være perfekt, men det skal være begyndelsen på en bevægelse nedad.
Tjenestekonti og integrationer
Programmer og integrationer er de konti, der lettest får for meget. De er sat op af en leverandør, der ville være sikker på, at alt virkede, og ingen tør røre dem bagefter. Netop derfor kan de optræde i testrapporter. → Tjenestekonti
Find ejeren af hver konto, find ud af, hvad den skal kunne, og bed leverandøren om en beskrivelse af de nødvendige rettigheder. Hvis leverandøren kun kan oplyse, at kontoen skal være administrator, er det et spørgsmål, der hører med i næste samtale om aftalen. Indtil da kan kontoen begrænses på anden vis, fx ved at den kun kan bruges fra de servere, hvor integrationen kører, og ikke til at logge interaktivt på. Notér begrænsningen, så den ikke fjernes ved en fejl under næste opgradering.
IT-afdelingens egne konti
Princippet gælder også dem, der administrerer miljøet. En administrator, der bruger samme konto til mail, internet og administration af domænet, giver en angriber en kort vej, hvis den konto bliver misbrugt. Adskil daglig brug og administration, så den konto, der læser mail, ikke har høje rettigheder. → Én konto til alt
Gør det samme med administrationen i lag: den, der vedligeholder klienter, behøver ikke rettigheder på domænecontrollerne, og den, der passer en enkelt server, behøver ikke rettigheder på alle. Det kan føles som en hindring i en lille IT-afdeling, hvor få personer gør alt. Men netop dér er det vigtigt, fordi en enkelt misbrugt konto ellers giver adgang til hele miljøet. Start med de højeste rettigheder, og arbejd nedad.
Det skal I lade være med
- At fjerne rettigheder uden at kende brugen. Så opdager I afhængigheden, når noget stopper.
- At give administratorrettigheder for at løse et enkelt problem. Find den smalle rettighed.
- At glemme programmer og integrationer. De kan have bredere adgang end personer.
- At rydde op én gang og stoppe. Rettigheder vokser igen.
- At lade tildelinger stå uden ejer. Nogen skal kunne svare på, hvorfor adgangen findes.
Hvad kan og ikke kan konkluderes
Færre rettigheder gør skaden mindre, når en konto bliver misbrugt, og gør det sværere at bevæge sig fra én konto til hele miljøet. De forhindrer ikke, at en konto bliver misbrugt, og de retter ikke svagheder i selve systemerne. En retest kan vise, om den vej, testeren brugte, er lukket. Den kan ikke vise, at alle rettigheder i miljøet nu følger princippet.
Tjekliste til færre rettigheder
- ☐ Er kataloget, servere, klienter, programmer og data gennemgået?
- ☐ Er brugen af rettighederne kortlagt, før de fjernes?
- ☐ Er ubrugte rettigheder fjernet først?
- ☐ Er brede rettigheder erstattet af smalle, hvor det kan lade sig gøre?
- ☐ Er høje rettigheder gjort tidsbegrænsede, hvor de sjældent bruges?
- ☐ Har hver tjenestekonto en ejer og en beskrivelse af nødvendige rettigheder?
- ☐ Er der aftalt en fast gennemgang af tildelingerne?
Kilder
- CSRC Glossary: Least privilege: definition af mindst mulig adgang som begrænsning af brugeres og processers rettigheder til det nødvendige minimum for de tildelte opgaver.
- Microsoft Learn: Best practices for securing Active Directory: undgå for brede rettigheder og kontrollér kataloget, medlemsservere, arbejdsstationer, programmer og datalagre.
- AWS: Security best practices in IAM: start med brede rettigheder og arbejd ned mod mindst mulig adgang; gennemgå og fjern ubrugte brugere, roller, rettigheder og nøgler jævnligt.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Tidsbegrænsede administratorrettigheder · Skærpelser, brugerne mærker
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
