Servicekonto

Servicekonti ser meget forskellige ud fra platform til platform. På Windows er det gamle mønster en almindelig domænebruger, hvis adgangskode tastes ind i tjenestens konfiguration og derefter aldrig ændres. Managed Service Accounts og fra Windows Server 2012 group Managed Service Accounts (gMSA) lader Active Directory generere en lang tilfældig adgangskode og rotere den automatisk, som standard hver 30. dag, mens autoriserede værter henter den fra directoryet. På Linux kører dæmoner som systembrugere med en nologin-shell. I Kubernetes kører hver pod som en ServiceAccount; siden version 1.24 genereres der ikke længere automatisk langlivede token-Secrets, og pods får i stedet projicerede, audience-bundne og tidsbegrænsede tokens via TokenRequest-API'et. I cloud er de foretrukne former IAM-roller i AWS, der antages via STS, managed identities i Azure og servicekonti i Google Cloud uden downloadede nøgler samt workload identity federation, hvor et eksternt OIDC-token, fx fra en CI-pipeline, veksles til kortlivede cloudloginoplysninger.

De klassiske svagheder er statiske hemmeligheder og manglende ejerskab. Adgangskoder, der aldrig udløber, nøgler indlejret i scripts eller konfigurationsfiler, én konto delt af flere applikationer, interaktivt login, der stadig er tilladt, og undtagelser fra MFA og betinget adgang, fordi "en tjeneste ikke kan lave MFA", gør alle disse konti til ideel persistens for angribere. I Active Directory udnytter Kerberoasting (MITRE ATT&CK T1558.003) enhver konto med et service principal name: Enhver autentificeret bruger kan anmode om en servicebillet krypteret med en nøgle afledt af kontoens adgangskode og knække den offline, især hvis RC4 stadig er tilladt. Lange tilfældige gMSA-adgangskoder og kryptering udelukkende med AES stopper angrebet.

Styringen er beskrevet i kontrolkatalogerne. CIS Controls v8.1 Safeguard 5.5 kræver en oversigt over servicekonti med mindst ejende afdeling, gennemgangsdato og formål og gennemgang mindst hvert kvartal; NIST SP 800-53 Rev. 5 AC-2 dækker kontostyring generelt. Praktisk hærdning betyder én konto pr. applikation og miljø, forbud mod interaktivt login og fjernskrivebordslogin, begrænsning af, hvorfra kontoen må autentificere sig, opbevaring af uundgåelige hemmeligheder i et vault med rotation, alarmer, når en servicekonto logger ind interaktivt eller fra et nyt sted, og deaktivering af konti, hvis applikation er udfaset.

En servicekonto er én måde at implementere en ikke-menneskelig identitet på. Den bredere tendens erstatter gemte hemmeligheder med workload-identiteter, som platformen attesterer, fx SPIFFE-id'er, managed identities i cloud eller projicerede tokens i Kubernetes, hvis loginoplysninger er kortlivede og aldrig håndteres af et menneske. AI-agenter og automatiseringsværktøjer får i stigende grad også servicekonti, hvilket gør mindste privilegium og en navngiven menneskelig ejer endnu vigtigere, fordi den software, der handler gennem kontoen, kan styres af input, man ikke kan stole på.