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.
Access Control = the rules that decide who can read, write, or change data. The two main models: (Role-Based) and (Attribute-Based).
RBAC: you have roles (Analyst, Engineer, Admin), each role has permissions (read this table, write to that), users get roles. Simple, easy to audit. The weakness: every new nuance = new role ('Analyst EU only', 'Analyst EU except PII'). Role explosion is real — some orgs reach 2000+ roles.
**ABAC**: permissions are computed from ATTRIBUTES at request time. 'Allow if user.department == data.owner_department AND user.region == data.region AND data. != restricted'. Flexible, scales to many conditions. Downside: harder to audit (you can't just list roles — you have to evaluate policies).
Modern pattern: combine both. RBAC for coarse-grained (team/role/tool level), ABAC for fine-grained ( masking based on user clearance, row filtering based on user's region).
Two more principles to know: **least privilege** (give the smallest permission that works, expand only when needed), **just-in-time (JIT) access** (no standing access to sensitive data — you request, get a time-boxed grant with reason, auto-revoked). Oktas, AWS IAM Identity Center, Snowflake, Databricks all support JIT flows now.
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.