RBAC
In access management, RBAC is role-based access control: permissions attach to roles, and roles attach to users. It replaced the practice of granting rights person by person, and it scales administration well, but only while the number of roles stays smaller than the number of people they describe.
How it works
A role is a named bundle of permissions that corresponds to a job. Identities are assigned roles, the decision at request time is a lookup of whether any held role grants the operation, and administration becomes managing membership rather than managing rights. Roles are often hierarchical, so a senior role inherits a junior one, and separation of duties can be expressed as a rule that two named roles may not be held by the same identity.
The alternative model, attribute-based control, evaluates attributes at request time instead: department, location, device state, the classification of the object, the time of day. RBAC answers what job you do; ABAC answers whether the circumstances of this request are acceptable. Most estates use RBAC for the coarse decision and attributes for the conditions on top, which is also what conditional access does in a Microsoft tenant.
What goes wrong
Role explosion. Every exception becomes a new role, and an estate that started with fifteen has four hundred, at which point nobody can say what any of them mean and administration is worse than the per-user model it replaced. The tell is roles named after individuals or after projects.
The second is accumulation. People change jobs and keep the old role because removing it might break something, so tenure and privilege correlate. The senior engineer who has been through four teams is the most valuable account in the directory and nobody designed it that way.
The third is what the role actually contains. Built-in cloud roles are frequently far broader than their names suggest, and one that appears to cover reading configuration may include reading secrets, or the permission to modify the policy that grants roles, which is administration by another name. This is where a role assignment becomes an attack path, and it is why least privilege has to be measured against effective permissions rather than against role names.
Where this shows up in an audit
We resolve effective permissions rather than reading assignments, because inheritance, group nesting, resource hierarchy and role assumption change the answer. The finding names the identity, the resolved permission and the path by which it was obtained, since the path is what has to be cut. Roles nobody is assigned and roles everybody is assigned are both reported: the first is clutter, the second is the absence of a model. This is part of how we enumerate effective permissions in a cloud tenant.