Tjenestekonti er de konti, som programmer, planlagte job og integrationer bruger til at logge på. De kan gå igen i rapporter fra en intern test af et Windows-miljø, og grunden er ikke nødvendigvis én fejl. Det er kombinationen: kontoen har flere rettigheder end nødvendigt, adgangskoden er ikke skiftet i årevis, den bruges af flere systemer, og ingen ved helt, hvem der ejer den. Svaret på, hvordan I får styr på dem, hviler på tre ting: et overblik over hvilke konti der findes, en ejer til hver, og rettigheder, der passer til opgaven.
Det er driftens arbejde, og det går ikke nødvendigvis hurtigt. Men det kan gøres i en rækkefølge, hvor de farligste konti kommer først.
Hvorfor tjenestekonti er et yndet mål
En tjenestekonto er bygget til at køre uden et menneske bag. Den logger på uden tofaktor, den må ikke låses, og dens adgangskode skiftes nødigt, fordi et skift kan stoppe et system. Nogle er desuden oprettet med høje rettigheder, fordi programmet ikke ville virke uden ved installationen.
CISA og NSA beskriver i deres vejledning om typiske fejlopsætninger, at tjenestekonti ofte har forhøjede rettigheder, og at det gør dem til attraktive mål, fordi en kompromitteret tjenestekonto giver samme adgang. Vejledningen anbefaler, at tjenestekonti kun får de rettigheder, tjenesten har brug for.
Testen undersøger derfor, hvilke tjenestekonti der findes, hvad de har adgang til, og hvordan de er beskyttet. Hvordan testeren gør det, er ikke afgørende for jer. Det afgørende er, hvad rapporten konstaterer om rettigheder og beskyttelse.
Fundtyper, der går igen
Fundene om tjenestekonti kan have nogle få former.
- For høje rettigheder · kontoen er medlem af en privilegeret gruppe eller har administratoradgang til mange maskiner. → Privilegerede grupper i Active Directory
- Svage eller gamle adgangskoder · adgangskoden er kort, er aldrig skiftet, eller er sat til aldrig at udløbe.
- Delte konti · én konto bruges af flere systemer, så ingen kan sige, hvilket system der har gjort hvad.
- Loginoplysninger i klar tekst · adgangskoden ligger i et script, en konfigurationsfil eller en beskrivelse i kataloget. → Adgangskoder i scripts og konfigurationsfiler
- Glemte konti · kontoen hører til et system, der er nedlagt, men den er stadig aktiv. → Inaktive konti og gamle computere i kataloget
Flere af formerne kan stå på samme konto. En gammel tjenestekonto med høje rettigheder og en adgangskode, der aldrig er skiftet, er et fund, der kan føre testeren langt.
Find dem, og giv dem en ejer
Det første skridt er en oversigt. Rapporten nævner de konti, testeren fandt, men den er ikke en komplet liste. Supplér med jeres egen gennemgang af konti, der bruges af programmer og planlagte job, og spørg systemejerne, hvilke konti deres systemer bruger.
Microsoft anbefaler i sin vejledning om tjenestekonti i et lokalt AD, at hver konto dokumenteres med nogle få oplysninger:
- Ejer · den person, der står til ansvar for kontoen.
- Formål · hvilket system eller hvilken opgave kontoen bruges til.
- Rettigheder · hvad kontoen har, og hvad den bør have, herunder gruppemedlemskaber.
- Risiko · hvad det betyder for forretningen, hvis kontoen bliver misbrugt.
- Levetid og gennemgang · hvor længe kontoen forventes at leve, og hvor tit ejeren skal bekræfte behovet.
- Adgangskoden · hvor den opbevares, og hvem der har adgang til den.
Microsoft anbefaler også en fast navngivning, så tjenestekonti er lette at finde, og at hver tjeneste har sin egen konto. Selve dokumentationen er ikke svær. Det svære er at få systemejerne til at påtage sig ejerskabet.
Hjælp dem på vej ved at gøre ejerskabet konkret. En ejer skal ikke selv kunne ændre kontoen, men skal kunne svare på, hvad den bruges til, godkende ændringer og bekræfte ved den faste gennemgang, at den stadig er nødvendig. Hvor et system drives af en leverandør, kan leverandøren være teknisk ansvarlig, men ejeren bør sidde hos jer. Konti, som ingen vil eje efter en rimelig frist, er kandidater til at blive deaktiveret, fordi ingen kan forklare, hvorfor de findes.
Ret de farligste først
Når oversigten findes, kan I prioritere. Start med de konti, der har høje rettigheder i kataloget, og som rapporten har kunnet bruge som led i en vej. Derefter kommer konti med administratoradgang til mange servere, og til sidst resten.
Rettelserne følger nogle få principper, beskrevet på begrebsniveau:
- Færre rettigheder · kontoen får kun det, tjenesten har brug for. Microsoft skriver, at tjenestekonti ikke bør være medlem af privilegerede grupper. → Mindst mulig adgang i praksis
- Én konto pr. tjeneste · delte konti deles op, så hver tjeneste kan spores og begrænses for sig.
- Administrerede tjenestekonti · hvor systemet understøtter det, bruges konti, hvor adgangskoden håndteres automatisk af platformen. Microsoft anbefaler den type, hvor det er muligt.
- Skift af adgangskoder · adgangskoder, som testeren kan have set, skiftes, og der aftales en fast rytme for resten.
- Lukning · konti uden ejer og uden aktuelt formål deaktiveres og slettes senere.
Uden at stoppe systemerne
Den største hindring for oprydning i tjenestekonti er frygten for at stoppe et system, ingen helt kender. Den frygt er berettiget. Behandl derfor hver ændring som en planlagt ændring med test og vej tilbage. Deaktivér en konto, før den slettes, så den kan genaktiveres, hvis et glemt job holder op med at virke. → Rettelser uden at stoppe driften
Opret hver konto som en opgave med ejer og frist, så arbejdet kan følges. → Fra fund til opgave
En ændring kan med fordel ske, mens systemets ejer er til stede og kan kontrollere, at alt virker bagefter. Hold også øje med logs for mislykkede logins de første dage efter ændringen, så et glemt job bliver fundet hurtigt.
Det skal I lade være med
- At skifte adgangskoder uden at kende afhængighederne. Et system kan stoppe midt i arbejdsdagen.
- At lade tjenestekonti være medlem af privilegerede grupper. Det gør dem til den korteste vej.
- At lade flere systemer dele én konto. Ingen kan bagefter se, hvem der gjorde hvad.
- At slette konti uden først at deaktivere dem. Så er der ingen vej tilbage.
- At rydde op uden at give kontiene en ejer. Så vokser problemet igen.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke tjenestekonti testeren fandt, hvilke rettigheder de havde, og om de kunne bruges som led i en vej i testperioden. Den er ikke en komplet oversigt over jeres tjenestekonti, og den kan ikke sige, hvilke rettigheder de enkelte systemer reelt har brug for. Det skal afklares med systemejerne.
Tjekliste til tjenestekonti
- ☐ Findes der en oversigt over alle tjenestekonti?
- ☐ Har hver konto en ejer, et formål og en dokumenteret rettighed?
- ☐ Er tjenestekonti fjernet fra privilegerede grupper?
- ☐ Er adgangskoder, testeren kan have set, skiftet?
- ☐ Bruges administrerede tjenestekonti, hvor det er muligt?
- ☐ Er glemte konti deaktiveret?
Kilder
- Microsoft Learn: Introduction to Active Directory service accounts: typer af tjenestekonti, ingen medlemskab af privilegerede grupper, én konto pr. tjeneste og dokumentation af ejer, formål, rettigheder og gennemgang.
- CISA og NSA: Top Ten Cybersecurity Misconfigurations (AA23-278A): tjenestekonti med forhøjede rettigheder som mål og anbefalingen om kun nødvendige rettigheder.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Adgangskoder i scripts og konfigurationsfiler · API-nøgler og integrationskonti
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
