ABAC (Attribute-Based Access Control)

What is ABAC (Attribute-Based Access Control)?

ABAC decides who may do something by evaluating attributes at the moment of the request, instead of checking whether the person belongs to a named role. Every request carries four kinds of attribute: who is asking (the subject), what they are reaching for (the resource), what they want to do with it (the action), and the circumstances around the request (the environment, such as time, location, or network). A policy engine reads those attributes and returns allow or deny.

The reference definition comes from the US standards body NIST, in publication SP 800-162. It frames ABAC as authorisation decided by evaluating attributes of the subject, the object, the requested operation, and, where relevant, environment conditions against rules that state which attribute combinations are allowed. Access is no longer a fixed list you were added to, but a decision recomputed on every request from the current value of each attribute.

A policy in plain language

Attributes stay abstract until you write a real rule. Take a hospital: a nurse may read a patient record only if the patient is admitted to the nurse's own ward, and only during the nurse's shift.

Each clause tests a different attribute:

• Subject. The ward the nurse is assigned to, read from the HR or identity system.

• Resource. The ward the patient is currently on, stored on the record.

• Action. Read, as opposed to edit or export.

• Environment. The current time, checked against the roster.

Move the patient to another ward, or let the shift end, and the same nurse loses access without anyone editing a permission. A role-based setup would more likely hand every nurse a blanket read on all records and rely on people not to look.

ABAC versus RBAC

RBAC, role-based access control, is the model most systems start with. It grants access by membership: you get a role's rights because you were added to the role. That makes it easy to audit, because who can see something is a lookup of the role's members.

The strain shows when access depends on combinations. An international company needs Belgian sales to see Belgian customers, Dutch sales to see Dutch customers, and finance to see revenue but not personal data. In pure roles you end up minting Sales BE, Sales NL, Finance BE, Finance NL, one role for every combination. This is role explosion, and it grows faster than anyone wants to maintain.

ABAC folds those into a handful of policies written over attributes like department, country, and classification. That is the upside: fine-grained control that scales as you add teams, regions, and datasets, without a fresh role for each. The honest cost is that a policy is harder to reason about than a role. "Who can access this record?" stops being a lookup and becomes a query you run against the current state of every attribute, and the answer can change tomorrow because one department field changed. Auditing gets harder.

How ABAC and RBAC work together

Most real systems do not pick one model. They use RBAC for the coarse grant and ABAC conditions to narrow it.

This is how Azure works. Azure RBAC assigns a role such as Storage Blob Data Reader to a user, granting read across a set of storage. An ABAC role assignment condition then filters that permission down: read is allowed only for blobs carrying the tag Project=Cascade, or only within a set time window, or only over a private network link. Microsoft describes Azure ABAC as building on Azure RBAC by adding conditions that filter the permissions a role already grants. AWS uses the same idea with tags, allowing an action when the principal's tag matches the resource's tag, so a new resource tagged for a project becomes reachable by that project's people the moment it is created, with no policy change.

Where ABAC fits in data governance

ABAC leans on good metadata. A policy that keys off classification, owner, or country only works if those attributes are set correctly on every dataset, which is why ABAC and data classification tend to arrive together. That places ABAC squarely inside data governance, next to the data catalogue, the owners, and the classification scheme that feed it.

It also sits close to a few neighbouring controls. Row level security applies attribute-driven filters so a signed-in user sees only their own rows, which is ABAC thinking inside a single BI model. Data masking blurs or hides sensitive column values depending on who is asking. Least privilege is the principle all of this serves: give each person the narrowest access that still lets them do the work. ABAC is one of the more precise ways to express least privilege, provided the attributes underneath it can be trusted.

What to watch out for with ABAC

• Bad attributes make bad decisions. If a person's department or a dataset's classification is wrong in the source system, the policy will confidently grant or deny the wrong thing. Attribute quality becomes a security control.

• Keep policies readable. A policy nobody can explain is a policy nobody can audit. Prefer a few clear rules over a sprawl of clever ones.

• Log the decision, not just the access. Record which attributes led to each allow or deny, so that after an incident you can say why access was granted, not only that it was.

• Start narrow. Put a few genuinely sensitive datasets behind conditions first, confirm the attributes are reliable, then widen. Making everything conditional on day one is how ABAC earns a bad name.