{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/service-account","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/service-account/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/service-account/"},"term":{"en":"Service account","da":"Servicekonto"},"aka":{"en":["machine account","non-human account"],"da":["maskinkonto","systemkonto"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","summary":{"en":"An account used by a program rather than a person, so that software can log in to other systems on its own.","da":"En konto, som bruges af et program i stedet for et menneske, så software selv kan logge ind på andre systemer."},"body":{"formal":{"en":"An account that belongs to an application or service instead of a named person, holding its own credential and permissions so the software can reach databases, files or other services without anyone typing a password.","da":"En konto, der tilhører et program eller en tjeneste i stedet for en navngiven person, med sin egen loginoplysning og egne rettigheder, så softwaren kan få adgang til databaser, filer eller andre tjenester, uden at nogen taster en adgangskode."},"plain":{"en":"Like a key card issued to the cleaning robot rather than to a worker - it opens only the doors the robot needs, at any hour, with nobody holding it.","da":"Som et adgangskort, der er udstedt til rengøringsrobotten i stedet for til en medarbejder - det åbner kun de døre, robotten har brug for, på alle tider af døgnet, uden at nogen holder det."},"inPractice":{"en":"At a water utility, the nightly backup job signs in to the file server with its own service account, which may read files but not delete them, and whose password is kept in a locked store rather than written into the job's code.","da":"På et vandværk logger det natlige backupjob ind på filserveren med sin egen servicekonto, der må læse filer, men ikke slette dem, og hvis adgangskode opbevares i et låst lager i stedet for at stå i jobbets kode."},"whyItMatters":{"en":"These accounts often hold wide rights and old passwords that no one watches, making them a quiet way in for attackers; a named owner and narrow rights keep them in check.","da":"Disse konti har ofte brede rettigheder og gamle adgangskoder, som ingen holder øje med, og er derfor en stille vej ind for angribere; en navngiven ejer og få rettigheder holder dem i skak."}},"deepDive":{"en":"Service accounts take very different forms by platform. On Windows, the legacy pattern is an ordinary domain user whose password is typed into the service configuration and then never changed. Managed Service Accounts, and from Windows Server 2012 group Managed Service Accounts (gMSA), let Active Directory generate a long random password and rotate it automatically, every 30 days by default, with authorised hosts retrieving it from the directory. On Linux, daemons run as system users with a nologin shell. In Kubernetes, every pod runs as a ServiceAccount; since version 1.24 long-lived token Secrets are no longer generated automatically, and pods receive projected, audience-bound, time-limited tokens through the TokenRequest API. In the cloud, the preferred forms are AWS IAM roles assumed through STS, Azure managed identities and Google Cloud service accounts used without downloaded keys, plus workload identity federation, where an external OIDC token, for example from a CI pipeline, is exchanged for short-lived cloud credentials.\n\nThe classic weaknesses are static secrets and missing ownership. Passwords set to never expire, keys embedded in scripts or configuration files, one account shared by several applications, interactive logon still permitted, and exemptions from MFA and conditional access because \"a service can't do MFA\" all make these accounts ideal persistence for attackers. In Active Directory, Kerberoasting (MITRE ATT&CK T1558.003) exploits any account with a service principal name: any authenticated user can request a service ticket encrypted with a key derived from that account's password and crack it offline, especially when RC4 is still allowed. Long random gMSA passwords and AES-only encryption defeat it.\n\nGovernance is spelled out in control catalogues. CIS Controls v8.1 Safeguard 5.5 requires an inventory of service accounts recording at least the department owner, review date and purpose, with reviews at least quarterly; NIST SP 800-53 Rev. 5 AC-2 covers account management generally. Practical hardening means one account per application and environment, denying interactive and remote-desktop logon, restricting where the account may authenticate from, storing any unavoidable secret in a vault with rotation, alerting when a service account signs in interactively or from a new location, and disabling accounts whose application has been retired.\n\nA service account is one implementation of a non-human identity. The broader trend replaces stored secrets with platform-attested workload identities, such as SPIFFE IDs, cloud managed identities or Kubernetes projected tokens, whose credentials are short-lived and never handled by a person. AI agents and automation tools increasingly receive service accounts too, which makes least privilege and a named human owner more important, since the software acting through the account may be steered by untrusted input.","da":"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.\n\nDe 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.\n\nStyringen 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.\n\nEn 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å."},"edges":[{"type":"requires","to":"cs/service","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/credential","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/account","confidence":"high","strength":"normal"}],"depth":2,"sources":[{"title":"CIS Controls v8 - Safeguard 5.5 (Establish and Maintain an Inventory of Service Accounts)","tier":"standard","publisher":"Center for Internet Security"},{"title":"NIST SP 800-53 Rev. 5 - AC-2 (Account Management)","tier":"standard","publisher":"NIST"}],"draft":true}