{"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://atlas.maintz.dev/)"},"id":"cs/least-privilege","url":{"en":"https://atlas.maintz.dev/en/terms/cs/least-privilege/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Have management approve a policy that every account, service and application gets only the rights its task needs, and only for as long as it needs them.","List the privileged accounts and roles in the directory, cloud platforms, databases and business systems, and record who holds each one and why.","Give administrators a separate admin account used only for admin work, and remove local admin rights from ordinary users' computers.","Replace standing admin rights with just-in-time elevation, for example through a PAM or PIM tool, with MFA, a stated reason and a time limit on each activation.","Give each service and application its own account limited to the resources it uses, and remove wildcard permissions and domain admin rights from service accounts.","Compare granted and used permissions every quarter with reports from the cloud platform or identity governance tool, and remove rights that are not used.","Set up audited break-glass accounts for emergencies, so least privilege does not lock the organisation out during an incident.","Log all use of privileged functions, review the logs regularly, and re-certify privileged roles at a fixed interval, for example every six months."],"da":["Lad ledelsen godkende en politik om, at hver konto, tjeneste og applikation kun får de rettigheder, opgaven kræver, og kun så længe den kræver dem.","Lav en oversigt over privilegerede konti og roller i kataloget, cloudplatforme, databaser og forretningssystemer, og notér, hvem der har hver enkelt og hvorfor.","Giv administratorer en separat administratorkonto, der kun bruges til administrativt arbejde, og fjern lokale administratorrettigheder fra almindelige brugeres computere.","Erstat faste administratorrettigheder med just-in-time-eskalering, fx via et PAM- eller PIM-værktøj, med MFA, en begrundelse og en tidsgrænse for hver aktivering.","Giv hver tjeneste og applikation sin egen konto, der er begrænset til de ressourcer, den bruger, og fjern wildcard-rettigheder og domæneadministratorrettigheder fra servicekonti.","Sammenlign tildelte og brugte rettigheder hvert kvartal med rapporter fra cloudplatformen eller IGA-værktøjet, og fjern rettigheder, der ikke bruges.","Opret auditerede nødadgangskonti, så mindste privilegium ikke låser organisationen ude under en hændelse.","Log al brug af privilegerede funktioner, gennemgå loggene jævnligt, og recertificér privilegerede roller med faste mellemrum, fx hvert halve år."]},"pitfalls":{"en":["Granting a broad role temporarily to make something work and never taking it back.","Letting administrators read email and browse the web with the same account that holds domain or global admin rights.","Running service accounts as domain administrators because nobody mapped what they actually need."],"da":["At tildele en bred rolle midlertidigt for at få noget til at virke og aldrig fjerne den igen.","At lade administratorer læse mail og surfe på nettet med den samme konto, som har domæne- eller globale administratorrettigheder.","At køre servicekonti som domæneadministratorer, fordi ingen har kortlagt, hvad de faktisk har brug for."]},"guides":[{"title":"Secure system administration","url":"https://www.ncsc.gov.uk/collection/secure-system-administration","publisher":"NCSC UK","tier":"official-doc"},{"title":"What is Privileged Identity Management? - Microsoft Entra ID Governance","url":"https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure","publisher":"Microsoft","tier":"official-doc"},{"title":"CIS Critical Security Control 6 - Access Control Management","url":"https://www.cisecurity.org/controls/access-control-management","publisher":"Center for Internet Security","tier":"standard"},{"title":"Cyberforsvar der virker","url":"https://samsik.dk/publikation/cyberforsvar-der-virker/","publisher":"Center for Cybersikkerhed (Styrelsen for Samfundssikkerhed)","tier":"official-doc","lang":"da"}]},"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}