{"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/role-based-access-control","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/role-based-access-control/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/role-based-access-control/"},"term":{"en":"Role-based access control (RBAC)","da":"Rollebaseret adgangskontrol (RBAC)"},"aka":{"en":["RBAC"],"da":["RBAC"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","era":1992,"summary":{"en":"Giving permissions to job roles rather than to individual people, and then giving people the roles that fit their job.","da":"At give rettigheder til jobroller i stedet for til enkeltpersoner og så give folk de roller, der passer til deres job."},"body":{"formal":{"en":"A form of access control in which permissions are attached to named roles, such as “accountant” or “nurse”, and accounts receive permissions only by being assigned one or more roles.","da":"En form for adgangskontrol, hvor rettigheder knyttes til navngivne roller som “bogholder” eller “sygeplejerske”, og konti kun får rettigheder ved at blive tildelt en eller flere roller."},"plain":{"en":"Like staff uniforms in a hotel - the uniform, not the person, decides which areas you may enter, and a new waiter simply gets the waiter's uniform.","da":"Som personaleuniformer på et hotel - det er uniformen og ikke personen, der afgør, hvor man må komme, og en ny tjener får bare tjeneruniformen."},"inPractice":{"en":"When a new accountant starts at an auditing firm, IT adds her to the “Finance” role and she instantly gets the dozen permissions every accountant needs; when she leaves, one change removes them all.","da":"Når en ny bogholder starter i et revisionsfirma, tilføjer IT hende til rollen “Økonomi”, og hun får straks de mange rettigheder, alle bogholdere skal bruge; når hun stopper, fjerner én ændring dem alle."},"whyItMatters":{"en":"Handing out permissions person by person drifts into chaos; roles keep access consistent, easy to review and in line with least privilege.","da":"Når rettigheder uddeles person for person, ender det i kaos; roller holder adgangen ensartet, let at gennemgå og i tråd med mindste privilegium."}},"deepDive":{"en":"RBAC was formalised in a 1992 paper by David Ferraiolo and Richard Kuhn of NIST and extended by Sandhu and colleagues in the RBAC96 family of models. NIST's unified model was adopted as ANSI INCITS 359-2004 in February 2004.The standard defines four components. Core RBAC consists of the sets USERS, ROLES, operations (OPS) and objects (OBS), permissions as operation-object pairs, a user-assignment relation UA between users and roles, a permission-assignment relation PA between permissions and roles, and sessions in which a user activates a subset of assigned roles. Hierarchical RBAC adds inheritance, where a senior role acquires the permissions of junior roles, in general or limited (tree-shaped) forms. Static separation of duty constrains assignment, so that no user may hold both \"create supplier\" and \"approve payment\", while dynamic separation of duty constrains which roles may be active together in one session.\n\nImplementations vary in how faithfully they follow the model. Active Directory security groups are commonly used as roles, although strictly a group is a collection of users and a role a collection of permissions; the AGDLP pattern (accounts into global groups, global groups into domain-local groups, permissions on domain-local groups) approximates that split. Kubernetes RBAC binds Roles or ClusterRoles to subjects through RoleBindings or ClusterRoleBindings; rules are purely additive with no deny, and the escalate and bind verbs, or any binding to cluster-admin, are effectively privilege grants to watch. Azure RBAC combines role definitions with assignments at management-group, subscription, resource-group or resource scope and inherits downward. Databases, ERP systems such as SAP and SaaS applications all have their own role layers.\n\nThe recurring failure is role explosion: when context such as department, site, project and data sensitivity is encoded in role names, the number of roles approaches the number of users and the model loses its point. Role engineering tries to prevent that, top-down from job functions or bottom-up through role mining on existing entitlements. RBAC also cannot natively express rules like \"only your own patients\" or \"only during a shift\"; those need attributes or relationships, which is why ABAC (NIST SP 800-162) and ReBAC are often layered on top, with the role treated as one attribute among several.\n\nOperationally, RBAC makes access reviews tractable: auditors certify each role's permission set once and then review who holds which roles, and separation-of-duty rules detect toxic combinations. It supports least privilege only if roles are kept narrow and personal exceptions are resisted; a few broad \"power user\" roles quietly undo the benefit.","da":"RBAC blev formaliseret i en artikel fra 1992 af David Ferraiolo og Richard Kuhn fra NIST og videreudviklet af Sandhu m.fl. i RBAC96-familien af modeller. NIST's samlede model blev vedtaget som ANSI INCITS 359-2004 i februar 2004.Standarden definerer fire komponenter. Core RBAC består af mængderne USERS, ROLES, operationer (OPS) og objekter (OBS), rettigheder som par af operation og objekt, en tildelingsrelation UA mellem brugere og roller, en tildelingsrelation PA mellem rettigheder og roller samt sessioner, hvor en bruger aktiverer en delmængde af sine tildelte roller. Hierarkisk RBAC tilføjer nedarvning, hvor en overordnet rolle får de underordnede rollers rettigheder, i en generel eller begrænset (træformet) udgave. Statisk funktionsadskillelse begrænser tildelingen, så ingen bruger kan have både \"opret leverandør\" og \"godkend betaling\", mens dynamisk funktionsadskillelse begrænser, hvilke roller der må være aktive samtidig i én session.\n\nImplementeringerne følger modellen i varierende grad. Sikkerhedsgrupper i Active Directory bruges ofte som roller, selv om en gruppe strengt taget er en samling brugere og en rolle en samling rettigheder; AGDLP-mønstret (konti i globale grupper, globale grupper i domænelokale grupper, rettigheder på domænelokale grupper) tilnærmer sig den opdeling. Kubernetes RBAC binder Roles eller ClusterRoles til subjekter via RoleBindings eller ClusterRoleBindings; reglerne er rent additive uden afvisninger, og verberne escalate og bind samt enhver binding til cluster-admin er reelt tildelinger af privilegier, der skal holdes øje med. Azure RBAC kombinerer rolledefinitioner med tildelinger på niveauerne management group, abonnement, ressourcegruppe eller ressource og nedarver nedad. Databaser, ERP-systemer som SAP og SaaS-applikationer har alle deres egne rollelag.\n\nDen tilbagevendende fejl er rolleeksplosion: Når kontekst som afdeling, lokation, projekt og datafølsomhed indkodes i rollenavnene, nærmer antallet af roller sig antallet af brugere, og modellen mister sin mening. Rolledesign (role engineering) forsøger at forhindre det, enten oppefra ud fra jobfunktioner eller nedefra via role mining på eksisterende rettigheder. RBAC kan heller ikke i sig selv udtrykke regler som \"kun dine egne patienter\" eller \"kun i din vagt\"; det kræver attributter eller relationer, og derfor lægges ABAC (NIST SP 800-162) og ReBAC ofte ovenpå, hvor rollen behandles som én attribut blandt flere.\n\nDriftsmæssigt gør RBAC adgangsgennemgange overskuelige: Revisorer godkender hver rolles rettighedssæt én gang og gennemgår derefter, hvem der har hvilke roller, og regler for funktionsadskillelse opdager giftige kombinationer. Modellen understøtter kun mindste privilegium, hvis rollerne holdes smalle, og man modstår personlige undtagelser; nogle få brede \"superbruger\"-roller ophæver stille og roligt gevinsten."},"edges":[{"type":"requires","to":"cs/permission","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/access-control","confidence":"high","strength":"normal"}],"depth":2,"sources":[{"title":"NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations","url":"https://doi.org/10.6028/NIST.SP.800-162","tier":"standard","publisher":"NIST"}],"draft":true}