Mindste privilegium

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.

Kontrolrammevæ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é.

Mindste 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.

Det 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.