{"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/least-privilege","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/least-privilege/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/least-privilege/"},"term":{"en":"Principle of least privilege","da":"Mindste privilegium"},"aka":{"en":["least privilege","principle of least authority"],"da":["princippet om mindste privilegium","least privilege"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","era":1975,"summary":{"en":"Giving every user, program and service only the permissions its task needs, and nothing more.","da":"At give hver bruger, hvert program og hver tjeneste kun de rettigheder, der er nødvendige for opgaven, og intet mere."},"body":{"formal":{"en":"A design principle stating that each account and process should run with the smallest set of permissions, for the shortest time, that still lets it do its job.","da":"Et designprincip om, at hver konto og proces skal køre med så få rettigheder og i så kort tid som muligt, men stadig kunne udføre sit arbejde."},"plain":{"en":"Like giving a house-sitter the key to the front door but not to the safe - they can water the plants, and a lost key costs you less.","da":"Som at give en huspasser nøglen til hoveddøren, men ikke til pengeskabet - de kan vande blomsterne, og en mistet nøgle koster dig mindre."},"inPractice":{"en":"In a municipality's family services department, each case officer can see only her own cases, and a student trainee gets read access for the three months of her placement, after which it ends automatically.","da":"I en kommunes børne- og familieafdeling kan hver sagsbehandler kun se sine egne sager, og en praktikant får læseadgang i de tre måneder, praktikken varer, hvorefter den udløber af sig selv."},"whyItMatters":{"en":"It limits how far a mistake, a stolen login or harmful software can spread - the damage is capped by what the account was allowed to do.","da":"Det begrænser, hvor langt en fejl, et stjålet login eller skadelig software kan sprede sig - skaden kan ikke blive større end det, kontoen havde lov til."}},"deepDive":{"en":"The canonical statement comes from Saltzer and Schroeder's \"The Protection of Information in Computer Systems\" (1975): every program and every user of the system should operate using the least set of privileges necessary to complete the job. It sits among their eight design principles alongside fail-safe defaults, complete mediation, separation of privilege and least common mechanism, and its stated rationale is damage containment and a smaller set of code and people to audit. The capability-security community's variant, the principle of least authority (POLA), stresses authority rather than permissions, meaning everything a subject can cause, including indirectly through the objects and services it can invoke.\n\nControl frameworks make it auditable. NIST SP 800-53 Rev. 5 control AC-6 has enhancements that are widely used as a checklist: AC-6(1) restricts who may reach security functions, AC-6(2) requires non-privileged accounts for non-security work, AC-6(5) limits privileged accounts to defined roles, AC-6(7) requires periodic review of privileges, AC-6(9) logs use of privileged functions and AC-6(10) prevents non-privileged users from executing them. ISO/IEC 27001:2022 Annex A 8.2 (privileged access rights) and CIS Controls v8.1 Safeguard 5.4 (dedicated administrator accounts) express the same idea.\n\nLeast privilege has three dimensions: scope (which actions on which resources), time (standing versus just-in-time access that expires) and context (only from a managed device, only for an approved change). At the operating-system level it means a daemon binds its port and then drops root, or holds only the Linux capability CAP_NET_BIND_SERVICE; seccomp filters and Windows UAC's split token work in the same spirit. In containers it means running as non-root, dropping all capabilities, a read-only root filesystem and no privileged flag; in Kubernetes, namespace-scoped Roles instead of ClusterRoles and no automatically mounted service-account token where none is needed. In cloud IAM it means resource-scoped policies without wildcards, permission boundaries, and tools that generate policies from observed activity or flag unused permissions.\n\nThe hard part is maintenance rather than design. Privilege creep through job moves, \"temporary\" grants that never expire, role explosion that pushes admins toward broad roles, and service accounts made domain administrators \"to make it work\" are the usual failure modes. Good practice measures the gap between granted and used permissions and trims it continuously, while keeping audited break-glass paths so least privilege does not undermine availability. Least privilege is a principle; RBAC, PAM and just-in-time elevation are mechanisms that implement it, and separation of duties is a related but distinct principle that splits one sensitive task across several people.","da":"Den klassiske formulering stammer fra Saltzer og Schroeders \"The Protection of Information in Computer Systems\" (1975): Hvert program og hver bruger af systemet bør arbejde med det mindste sæt privilegier, der er nødvendigt for at løse opgaven. Princippet står blandt deres otte designprincipper sammen med sikre standardvalg (fail-safe defaults), fuldstændig kontrol (complete mediation), adskillelse af privilegier og mindst fælles mekanisme, og begrundelsen er at begrænse skader og at mindske den mængde kode og antallet af personer, der skal revideres. Capability-sikkerhedsmiljøets variant, princippet om mindste autoritet (POLA), lægger vægt på autoritet frem for rettigheder, altså alt, hvad et subjekt kan forårsage, også indirekte gennem de objekter og tjenester, det kan kalde.\n\nKontrolrammeværker gør princippet revisionsbart. NIST SP 800-53 Rev. 5, kontrol AC-6, har udvidelser, der bruges bredt som tjekliste: AC-6(1) begrænser, hvem der kan nå sikkerhedsfunktioner, AC-6(2) kræver ikke-privilegerede konti til andet arbejde, AC-6(5) begrænser privilegerede konti til definerede roller, AC-6(7) kræver periodisk gennemgang af privilegier, AC-6(9) logger brug af privilegerede funktioner, og AC-6(10) forhindrer ikke-privilegerede brugere i at udføre dem. ISO/IEC 27001:2022 bilag A 8.2 (privilegerede adgangsrettigheder) og CIS Controls v8.1 Safeguard 5.4 (dedikerede administratorkonti) udtrykker samme idé.\n\nMindste privilegium har tre dimensioner: omfang (hvilke handlinger på hvilke ressourcer), tid (faste rettigheder over for just-in-time-adgang, der udløber) og kontekst (kun fra en administreret enhed, kun til en godkendt ændring). På styresystemniveau betyder det, at en dæmon binder sin port og derefter opgiver root eller kun har Linux-capabilityen CAP_NET_BIND_SERVICE; seccomp-filtre og Windows UAC's opdelte token arbejder i samme ånd. I containere betyder det at køre som ikke-root, fjerne alle capabilities, bruge et skrivebeskyttet rodfilsystem og undlade privileged-flaget; i Kubernetes navnerumsafgrænsede Roles i stedet for ClusterRoles og intet automatisk monteret service-account-token, hvor der ikke er brug for det. I cloud-IAM betyder det ressourceafgrænsede politikker uden wildcards, permission boundaries og værktøjer, der genererer politikker ud fra faktisk aktivitet eller markerer ubrugte rettigheder.\n\nDet svære er vedligeholdelsen, ikke designet. Rettigheder, der hober sig op ved jobskift, \"midlertidige\" tildelinger, der aldrig udløber, rolleeksplosion, der skubber administratorer mod brede roller, og servicekonti, der gøres til domæneadministratorer \"for at få det til at virke\", er de typiske fejl. God praksis måler forskellen mellem tildelte og brugte rettigheder og beskærer løbende, mens der bevares auditerede nødadgange, så mindste privilegium ikke går ud over tilgængeligheden. Mindste privilegium er et princip; RBAC, PAM og just-in-time-eskalering er mekanismer, der implementerer det, og funktionsadskillelse er et beslægtet, men særskilt princip, der fordeler én følsom opgave på flere personer."},"edges":[{"type":"requires","to":"cs/permission","confidence":"high","strength":"normal"},{"type":"part-of","to":"security/zero-trust","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/ransomware","why":{"en":"Ransomware can only lock the files and machines the infected account is allowed to reach.","da":"Ransomware kan kun låse de filer og maskiner, den inficerede konto har adgang til."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/privilege-escalation","why":{"en":"Fewer standing rights on each account means fewer stepping stones for an attacker to climb.","da":"Færre faste rettigheder på hver konto betyder færre trædesten, en angriber kan klatre op ad."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"platform/container-escape","why":{"en":"A container given only the rights it needs has far fewer tools to break out with, and gains little if it does.","da":"En container, der kun har de rettigheder, den har brug for, har langt færre redskaber at bryde ud med og vinder ikke meget, hvis den gør."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"ai/excessive-agency","why":{"en":"Giving an AI agent only the tools and rights its task needs caps the damage when it is wrong or hijacked.","da":"At give en AI-agent kun de værktøjer og rettigheder, opgaven kræver, sætter et loft over skaden, når den tager fejl eller bliver kapret."},"confidence":"medium","strength":"normal"},{"type":"used-with","to":"cs/role-based-access-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/service","why":{"en":"Services often run all the time with wide rights, so each should get its own account with only the rights it needs.","da":"Tjenester kører ofte hele tiden med vide rettigheder, så hver bør have sin egen konto med kun de rettigheder, den skal bruge."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/service-account","confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/mcp-server","why":{"en":"Give each MCP server only the accounts, folders and rights its tools need, so a careless or hostile one can reach little.","da":"Giv hver MCP-server kun de konti, mapper og rettigheder, dens værktøjer kræver, så en skødesløs eller ondsindet en kan nå lidt."},"confidence":"medium","strength":"normal"}],"depth":2,"sources":[{"title":"NIST SP 800-207, Zero Trust Architecture","url":"https://doi.org/10.6028/NIST.SP.800-207","tier":"standard","publisher":"NIST"},{"title":"Modern Operating Systems","tier":"textbook","publisher":"Tanenbaum & Bos (Pearson)"}],"draft":true}