Access Control — RBAC & ABAC
Who can access what data, under what conditions. RBAC (by role) is simple but rigid; ABAC (by attributes) is flexible but complex. Most orgs use both.
**RBAC** (NIST definition, 2004): users assigned to **roles**, roles granted **permissions** on **objects**. Supports role hierarchies (Analyst inherits from Reader), separation of duties (SoD — user can't hold conflicting roles like Approver + Requester). Primary strength: simple mental model, straightforward audit (list roles per user and permissions per role).
Limitations: role explosion in multi-dimensional access (department × region × classification × project × time-window = combinatorial roles). For a non-trivial org, the role catalog balloons to hundreds-to-thousands, making maintenance brittle.
**ABAC** (NIST SP 800-162): policies are expressions over attributes of the **subject** (user.dept, user.clearance, user.region), **object** (data.classification, data.tags, data.row.country), **action** (read, write, share), and **environment** (request.time, request.ip, mfa=true). Evaluated by a Policy Decision Point (PDP) — e.g., OPA (Open Policy Agent), Cedar (AWS), Casbin.
Example ABAC policy (Rego/OPA): allow if input.user.region == input.resource.region and input.resource.classification != "restricted" or input.user.clearance >= 3. Flexible; scales to fine-grained row/column controls.
(RLS)** and **column-level security (CLS)** are modern manifestations — Snowflake row access policies, BigQuery row filters, Databricks Unity Catalog's dynamic views. Evaluated at query time; the user sees a filtered view of the same physical table.
Policy-as-code: access policies stored in Git, versioned, tested (opa test policy.rego), deployed via CI. Brings software engineering discipline to access control — no more copy-pasted IAM JSON drift across accounts.
Just-in-time (JIT) access eliminates standing access to sensitive systems: users request a time-bound grant with justification, approved by a reviewer (or auto-approved for low-risk), automatically revoked after TTL (typically hours). Reduces lateral-movement blast radius in a breach. Tools: Okta Access Requests, AWS IAM Identity Center + AWS SSO, Sym, Indent, ConductorOne.
Separation of duties: the person who requests access cannot approve their own request; the person who changes a production policy cannot also be the sole reviewer. Encoded in either approval workflows or mutually-exclusive role constraints.
Zero-trust adjacency: 'never trust, always verify'. Each request is authenticated, authorized, and (often) mTLS-wrapped regardless of network location. RBAC/ABAC are the decision layer; ZT is the architectural stance.
Diagram
Grounded on https://csrc.nist.gov/projects/role-based-access-control
Next up
Retention & Data Lifecycle
When to keep data, when to archive it, when to delete it — driven by legal, business, and privacy requirements.