Access Control: RBAC and ABAC

Access-control models decide whether a principal may perform an action on a resource, from coarse role grants to fine-grained attribute rules.

The access-control question

Every request to read or write data poses one question: may this principal perform this action on this resource? Access-control models are structured ways to answer it consistently. The two dominant models are role-based and attribute-based; most real systems combine them.

Role-based access control

RBAC groups permissions into roles and assigns roles to principals. Instead of granting each person access to each table, you grant the role "analyst" read access to a schema, then assign people to that role. This scales administration: onboarding is one role assignment, and revoking a role removes many permissions at once. Its weakness is coarseness, since a role either has a permission or does not, independent of context.

Attribute-based access control

ABAC decides using attributes of the principal, the resource, the action, and the environment, evaluated by a policy. A rule might read: allow read if the user's clearance is at least the record's classification and the request comes from an approved network. ABAC expresses fine-grained, contextual policy that RBAC cannot, at the cost of more complex evaluation and harder reasoning about the effective permission set.

Comparing the models

Principle of least privilege

Whatever the model, the guiding rule is least privilege: grant the minimum access needed for the task, and no more. Broad standing access is the main way data leaks, because a single compromised account then reaches everything. Least privilege limits the blast radius. Complementary techniques include row- and column-level security, so one table can expose different subsets to different principals, and time-bounded grants that expire automatically. See data governance.