RBAC
acronymcloudsecurityIT supportgovernance & risk
Stands for: Role-Based Access Control (ANSI INCITS 359)
Role-Based Access Control: permissions granted to roles, people assigned to roles - access managed by job, not by individual favor.
ABAC extends it with attributes (department, time, device); both exist to make revocation possible. NIST's project page gives the lineage: Ferraiolo and Kuhn's 1992 paper "introduced formal model for role based access control", a framework followed in 1996, the unified NIST model in 2000, and the model was "adopted as American National Standard 359-2004 by the American National Standards Institute" in February 2004 and "revised as INCITS 359-2012". The standard's reference model "defines sets of basic RBAC elements (i.e., users, roles, permissions, operations and objects)": a permission is an operation on an object, a role collects permissions, a user is assigned roles, and a session activates some of them. NIST states the case for it as cost: RBAC "has become the predominant model for advanced access control because it reduces" the cost of security administration, and an RTI International analysis of December 2010 estimated it "to have saved industry $1.1 billion over multiple years" through reduced employee downtime and more efficient provisioning and policy administration. The model's characteristic failure is role explosion, when every exception becomes a role; its characteristic strength is that a role can be reviewed once where a thousand individual grants cannot.
Role-based access control grants permissions to roles and assigns people to roles, rather than granting permissions to individuals. The benefit is reviewability: a role can be examined once and understood, where a thousand individual grants cannot. The idea is older than its name, but the formal model and the standard are American and dated. NIST's project page records that Ferraiolo and Kuhn's 1992 paper "introduced formal model for role based access control", that Sandhu and colleagues proposed a framework in 1996, and that NIST unified the two in 2000; the unified model "was adopted as American National Standard 359-2004 by the American National Standards Institute" in February 2004 and "revised as INCITS 359-2012" in 2012. The standard's reference model "defines sets of basic RBAC elements (i.e., users, roles, permissions, operations and objects)": an operation on an object is a permission, a role is a named collection of permissions, a user is assigned to roles, and a session is a user's activation of some of them. Hierarchies let a senior role inherit a junior one's permissions, and constraints express separation of duties, so that two roles that must not be held together cannot be.
NIST's argument for the model is economic before it is anything else. Its page says that RBAC "has become the predominant model for advanced access control because it reduces" the cost of security administration, and it cites an RTI International analysis of December 2010 that estimated RBAC "to have saved industry $1.1 billion over multiple years", the savings coming from "reduced employee downtime, more efficient provisioning, and more efficient access control policy administration". The mechanism of the saving is the one every administrator knows: a new hire in a known job gets the job's roles on day one instead of a ticket per system, and a leaver loses everything by losing the roles.
Its characteristic failure is role explosion. Every exception becomes a new role, the set grows past the point anyone can reason about, and the model provides the paperwork of governance without the clarity it was adopted for. The discipline is to keep roles aligned to job functions rather than to requests, to handle genuine exceptions as time-bounded grants rather than permanent roles, and to review the set periodically, because a role nobody can explain is a role nobody should be assigned. The second failure is the one the privilege creep entry describes: people change jobs and keep the roles of the old one, so that the model's clean picture of who may do what drifts from the truth unless the assignments are reviewed on a schedule, which is what NIST's control catalogue asks for in AC-6(7).
The alternatives are refinements rather than replacements. Attribute-based access control, in NIST SP 800-162's definition, decides each request by evaluating attributes of the subject, the object, the operation and the environment against policy, which handles the cases roles cannot, such as access that depends on the time of day, the device in use or a relationship between the requester and the record. Most real systems combine the two, roles for the bulk of access and attributes for the conditions, and the ABAC entry sets them side by side. Separation of duties, which the standard's constrained model expresses as roles that cannot be held or activated together, has its own entry, as does least privilege, the principle both models exist to implement.
In network and security operations the roles are often the groups of a directory: a RADIUS or TACACS+ server maps an Active Directory group to a VLAN, a device privilege level or a command set, a cloud platform maps a group to a set of permissions, and a policy engine's rules are written against group membership. Those groups are an RBAC model whether or not anyone drew it, and reviewing them is the access review the Microsoft documentation describes and the control catalogue requires.
Also known as: role-based access control, role based access control, incits 359, role explosion