Access control models: RBAC, ABAC, least privilege and access reviews

Access control models in brief

An access control model is the logic used to decide whether a principal may perform an action on a resource. You will meet four names in exams:

• Discretionary (DAC): the owner decides who gets access, as with sharing a file from your own drive.
• Mandatory (MAC): a central authority assigns labels such as Secret or Official, and the system enforces them. Used in government and in kernel features like SELinux.
• Role-based (RBAC): permissions are attached to roles that reflect job functions.
• Attribute-based (ABAC): decisions use attributes of the user, resource, action and environment.

Role-based access control

In RBAC you define roles such as Network Operator, Database Reader or Billing Admin, give each role the permissions that job needs, and then add people (usually through groups) to roles. Azure RBAC, Kubernetes RBAC and Google Cloud IAM roles all follow this pattern. RBAC is easy to explain to auditors: "Ali is in the Database Reader role, so he can read these databases."

The common problem is role explosion. As exceptions pile up you end up with hundreds of near-identical roles such as Database Reader Project X Europe, which nobody can review sensibly.

Attribute-based access control

ABAC writes rules in terms of attributes. A single policy might say: allow a user to start or stop virtual machines if the machine's project tag matches the user's project tag. New projects then need no new roles, just correct tags. AWS supports this with tags in IAM policy conditions, and Azure offers role assignment conditions. The trade-off is that tags become security-critical, so you must control who can change them.

In practice most organisations use RBAC as the foundation and add attribute conditions where they remove the need for many extra roles.

Least privilege and separation of duties

Least privilege means each identity has only the permissions it needs, for only as long as it needs them. In the cloud this means avoiding wildcard permissions such as "Action": "*", scoping roles to a specific resource group, project or account, and preferring built-in read-only roles for people who only look. Separation of duties splits sensitive tasks so no single person can complete them alone, for example the person who requests a payment cannot approve it.

Tip: cloud providers can show which granted permissions have not been used recently (for example AWS IAM Access Analyzer and last-accessed data). Use this to trim roles safely.

Running access reviews

1. Export who has which role for each important system, including service accounts.
2. Send each list to the people who understand the business need, usually managers or system owners.
3. Ask reviewers to confirm or remove each entry, not just approve the whole list.
4. Remove access promptly and record the decisions as evidence.
5. Review privileged roles more often, for example quarterly, and standard access at least yearly.

Rubber-stamping is the biggest weakness of reviews. Make lists short and meaningful by granting access through well-named groups, and highlight unused or unusual permissions for reviewers.