Key Takeaways: Authorization and Access Control

A one-page reference. Reread before an exam or before moving on. Dense by design.

Core vocabulary (memorize cold)

Threshold idea: Authentication determines whether an attacker who steals a credential gets in; authorization determines how much it is worth when they do. Strong authN makes weak authZ worse (over-broad access reliably attached to a confirmed identity). AAA = AuthN (who) + AuthZ (what's allowed) + Accounting (what happened — the safety net).

The four models — comparison

Mature pattern: RBAC backbone + ABAC conditions — roles for coarse "what job function," attributes for fine "but only under these conditions" (managed device, business hours, own branch).

Role design checklist (avoiding role explosion)

• [ ] Roles map to durable job functions, not individuals (no Sam_Special_Access).
• [ ] Far fewer roles than users (many users per role; one-occupant roles are a smell).
• [ ] A base role (All_Employees) holds common access; other roles inherit it (role hierarchy).
• [ ] Senior roles = "junior role plus a few permissions," not from-scratch copies.
• [ ] High-risk permissions split across roles by design (initiate-wire ≠ approve-wire).
• [ ] Mutually-exclusive role pairs are refused at provisioning (can't assign both).
• [ ] Built with top-down (job functions) + bottom-up (mine real access) — reconcile the two.
• [ ] Warning sign — role explosion: ≥ as many roles as users; most held by 1–2 people; undocumented. Cause: minting a new role per individual exception. Why it's a security problem: an access model no one can comprehend is one no one can audit — over-privilege hides in the sprawl.

Least privilege & privilege creep — defenses

The asymmetry that creates creep: access is granted eagerly (someone asks, work is blocked, "yes" is frictionless) and revoked reluctantly (nobody files a ticket to lose access). The mover (internal transfer) is the #1 creep generator.

Reading the access matrix

• ACL = matrix stored per resource ("who can touch this object"). Capability = stored per subject ("what can this subject touch"). Same matrix, two slices.

Segregation of duties — enforce at BOTH layers

Wire transfer = maker-checker workflow: INITIATE (maker) → APPROVE (checker, different person) → RELEASE. PDP checks on approval: (1) holds approve_wire; (2) approver ≠ initiator; (3) ABAC context (managed device/on-net/MFA); (4) amount > threshold ⇒ second approver. A human habit is not a substitute for rule 2.

PDP / PEP (reference monitor, decomposed)

• PDP = brain (decides, holds policy) · PEP = gate (in the request path, imposes verdict).
• Supporting: PIP supplies attributes; PAP is where policy is authored.
• Why split: one consistent policy enforced at many gates (policy lives/changes in one place, not copied into and drifting across many codebases). This is the architecture of zero trust (🔗 Ch.32): PDP = policy engine; PEP = policy enforcement point on every resource.
• Rules: PEP unbypassable (always invoked) · decision fail-closed (deny when PDP unreachable — fail-safe defaults, 🔗 Ch.3) · every decision logged (permit and deny = accounting + a sensor).

When to use what (decision aids)

• Owner-knows-best, low-stakes sharing? → DAC (but keep sensitive data out of free-for-all stores).
• Must prevent flows regardless of owner wishes / confine a process? → MAC (incl. SELinux/AppArmor).
• Scale job-based access across a workforce? → RBAC (roles = job functions).
• Need context (device, time, relationship, risk)? → ABAC conditions on top of RBAC.
• Express "manager can approve but not their own"? → role design + runtime self-approval check.
• Stop one stolen credential from reaching everything? → least privilege + JIT, time-boxed access.
• Find creep on an account? → read across its row; run an automated SoD combination scan.

Mapped frameworks

RBAC formal model: NIST RBAC standard (ANSI/INCITS 359). ABAC: NIST SP 800-162.

Project additions this chapter

• Meridian program: the access-control policy — RBAC backbone + ABAC conditions; least privilege as default (start at the base role); a defined set of segregation-of-duties rules (forbidden combinations) enforced at provisioning and runtime with self-approval prevention; time-boxed temporary access; periodic access reviews (quarterly for wire/admin/CDE roles, annual otherwise). Hands off lifecycle mechanics to IGA (🔗 Ch.18) and privileged accounts to PAM (🔗 Ch.19).
• bluekit toolkit: authz.py — rbac_check(user_roles, action) (permit iff a held role grants the action; the role itself enforces SoD) and abac_eval(attrs, policy) (permit iff every condition is met; fail-closed). Composes into the wire PDP's can_approve_wire and extends toward zerotrust.py (🔗 Ch.32).

Common pitfalls

• "We have MFA, so access is secure" — MFA is authentication; it does nothing for over-permissioning.
• Treating a role as a person (Sam_Special_Access) — back to per-user management; abandon RBAC's gain.
• Reviewing access one permission at a time — toxic combinations are invisible per-grant; read the row.
• Relying on a human habit (always a different approver) instead of a runtime rule — habits fail.
• Believing clean role definitions prove access is fine — the danger is in accumulated assignments.
• Standing, broad access "for convenience" (support sees all tenants) — one credential theft = full breach.
• Letting the PDP fail open when unreachable — fail closed; deny by default.
• Bottom-up role mining alone — it launders existing privilege creep into official roles.