Access Control Models

Data Governance Fundamentals named "who can access what" as the first question a governance program has to answer. This article covers the two dominant access control models used to answer it, and the principle that should constrain either one.

Role-based access control: permissions attached to roles#

Role-based access control (RBAC) attaches permissions to a role, not directly to a person — a user is assigned one or more roles, and inherits whatever that role grants:

Role: analyst          -> can read aggregated sales tablesRole: pii_reader        -> can read raw customer PII columnsRole: pipeline_operator -> can run and monitor scheduled jobs
Alice: analyst              -> reads aggregates, not raw PIIBob:   analyst + pii_reader -> reads both

Auditing "who can see raw PII" reduces to "who has the pii_reader role" — a query against a small, stable list, not an investigation into every individual grant.

Attribute-based access control: permissions computed from context#

Attribute-based access control (ABAC) evaluates a rule against attributes of the user, the resource, and the request itself, rather than checking a fixed role membership:

Rule: allow read access to customer_data      IF user.region == resource.region      AND user.department == "analytics"      AND current_time is within business_hours

This expresses policies RBAC cannot represent as a static role — access that depends on matching regions, or on when the request happens — at the cost of readability: the actual answer to "can this person see this data" now requires evaluating a rule against live context, not reading a list.

The principle both models should be designed under#

Whichever model is used, the principle of least privilege is the design constraint that makes it actually protective: grant the minimum access a role or attribute rule genuinely needs, not the most convenient broad grant available. A role that grants blanket read access "because scoping it precisely was extra work" defeats the purpose of having roles at all — it just renames the "everyone can see everything" default this whole module exists to replace.

Applying this at the data layer#

Access control is not only about who can log into a system — it applies at the level of individual columns and rows too. A customers table can expose region and signup_date to every analyst role while masking or omitting email and phone_number entirely for roles without pii_reader, and a region-scoped role can be restricted to rows matching that region specifically. The mechanism (column masking, row-level security policies) varies by database; the underlying model — RBAC, ABAC, or both — is the same one covered above, just applied at query time instead of at login.

Common mistakes#

Role explosion#

Creating an increasingly fine-grained role for every new combination of access needed eventually produces more roles than anyone can meaningfully audit — the opposite of RBAC's original goal of making "who can see this" a simple lookup. Consolidating overlapping roles periodically keeps the model actually auditable.

Defaulting to broad access "to fix later"#

A temporary broad grant — full admin, full read access — made to unblock someone quickly tends to become permanent, because narrowing an existing grant requires someone to notice it, question it, and take action, none of which happen automatically.

ABAC rules too complex for anyone to audit confidently#

An attribute rule with enough nested conditions becomes difficult for anyone, including its author, to state confidently what it actually permits in a given case. Keeping ABAC rules simple enough to reason about directly is worth prioritizing over maximum expressiveness.

Further reading#

• Access control — the general concept both models implement.
• Role-based access control and Attribute-based access control — full definitions of both models compared above.
• Principle of least privilege — the design constraint that makes either model actually protective.
• Mandatory access control — a stricter, centrally enforced alternative used where RBAC and ABAC's flexibility is itself a risk.

See also#