Access Control Models

• Compare DAC, MAC, RBAC, ABAC and relationship-based models
• Explain policy × decision engine separation (XACML/OPA style)
• Choose a model for a realistic system

• Saying 'add me to the admin group' is RBAC in action; most breaches are role misassignment or ABAC attribute errors.
• The enforcement/decision split (PEP/PDP) is why 'deny by default' can be tested centrally.
• Knowing the model lets you audit thousands of rules as a pattern, not case by case.
• Compliance frameworks (SOC 2, HIPAA) find RBAC/ABAC language natural to certify against.

The badge is a credential. Whether a badge opens a door can follow roles (all 'DevOps' badges), rules (badges stamped 'contractor' and time-aware) or a per-door policy (this door trusts this badge). Models are just consistent philosophies for answering 'opens?'.

• DAC: owners set ACLs on their resources — flexible, but sprawl and lateral risk.
• MAC: labels (e.g., clearance/classification) are compared; no one lowers labels casually — used in classified and some kernel contexts.
• RBAC: define roles (viewer, operator, admin), assign permissions to roles, assign users to roles; sessions assume roles.
• ABAC: rules like 'allow access IF department==user.department AND time within support window AND resource.tier <= user.tier'.
• Enforcement point (PEP) intercepts the call and asks a decision point (PDP/OPA) for a policy verdict; the PDP answers with allow/deny and obligations.
• ReBAC: edges in a graph ('member of team X' or 'reports to') become grants — natural for SaaS tenants and org hierarchies.

• An HR app uses RBAC: roles 'recruiter', 'hiring_manager', 'admin'; permission review reports list each user's roles quarterlly.
• A cloud platform uses ABAC (principal tags, resource tags, aws:SourceIp) to centralize policy logic across services.
• A SaaS adds ReBAC so 'only members of a shared folder's team' can view it, even as teams change shape.

• Start RBAC, add ABAC attributes only where roles alone can't express the rule.
• Centralize policy in one decision engine; enforce everywhere consistently.
• Default deny in the PDP and write allow rules narrowly.
• Audit decisions, not just failures — knowing 'who was ALLOWED what' is the compliance answer.
• Review role assignments; stale roles are the usual perennial weakness.

• Implementing thousands of per-user ACLs (DAC style) and losing all ability to review.
• Confusing 'has role' with 'allowed' when roles carry too many permissions.
• Special-casing policy in each service so the same rule behaves differently across the fleet.
• Forgetting the environment attributes (time, IP, device) that a break-glass path needs.

• A 'should be allowed' denial → check the PDP evaluation trace: which rule denied and which attribute caused it.
• Permission explosion → query roles × permissions matrix and collapse duplicates.
• Cross-environment inconsistency → standardize on one PDP and migrate rules, don't patch per-app.

• ABAC attributes are only as trustworthy as the feature sources feeding them; attacker-influenced attributes can grant access.
• RBAC with too-coarse roles becomes 'everyone is admin of something' — a top root-cause of data breaches.