Domain 5 · Lesson 3 of 5

Access Control Models (DAC, MAC, RBAC, ABAC)

Mô hình Kiểm soát Truy cập

Four Access Control Models

Model	Who Controls	How	Flexibility	TS Example
DAC Discretionary	Object owner	ACLs; owner grants/revokes permissions	High	Linux file permissions
MAC Mandatory	System enforces labels	Classification labels (Top Secret, Secret, Confidential)	Low	Government classified systems; Bell-LaPadula
RBAC Role-Based	Admin assigns roles	Permissions assigned to roles; roles assigned to users	Medium	Platform C admin portal module-scoped permissions
ABAC Attribute-Based	Policy engine	Attributes of user + resource + environment	Very High	Platform C per-lender: tenant_id of token must match resource tenant_id

DAC — Discretionary

The owner of an object controls access. Flexible but hard to enforce organization-wide policy — one careless owner can expose sensitive data. Classic example: Linux/Windows file ACLs.

Risk: subject to Trojan horse attacks — malicious program runs as user, inherits their DAC permissions.

MAC — Mandatory

The system enforces classification labels. Users cannot override. Most restrictive model. Bell-LaPadula: "no read up, no write down" (confidentiality). Biba: "no write up, no read down" (integrity).

Used in: government, military, high-security environments requiring strict compartmentalization.

RBAC — Role-Based

Roles bundle permissions. Users are assigned roles, not individual permissions. Most common enterprise model. Easier to manage at scale than DAC. Example: loan_officer role can view applications but not approve.

Risk: privilege creep — users accumulate roles over time without deprovisioning old ones.

ABAC — Attribute-Based

Policy engine evaluates attributes of user, resource, and environment. Most flexible — can express rules like: "allow if user.tenant_id == resource.tenant_id AND time_of_day == business_hours AND device.compliant == true."

Foundation of Zero Trust access control models.

Rule-Based Access Control (RuBAC)

Often confused with RBAC. Key differences:

Feature	RBAC (Role-Based)	RuBAC (Rule-Based)
Control mechanism	User's assigned ROLE determines access	System-level RULES determine access (ACLs, firewall rules)
Who sets it	Administrator assigns roles to users	System/administrator defines global rules
Dynamic?	Static (role assignment)	Can be time-based, location-based
Example	User in "loan_officer" role can view applications	Firewall ACL: "Block all traffic from 10.0.0.0/8 to port 22"
CISSP context	Enterprise IAM systems	Firewall rules, router ACLs, content filtering

Exam trap: "Rule-Based" and "Role-Based" are DIFFERENT models. Rule-Based uses system-defined rules (like firewall ACLs). Role-Based uses user roles. A firewall that blocks traffic based on IP/port rules is Rule-Based access control, NOT Role-Based.

Privilege Creep & Access Recertification

Privilege Creep

Users accumulate permissions over time — role changes, temporary access, project-based access — without old permissions being removed. Over months/years, a user ends up with far more access than their current role requires.

Example: Engineer moves from Platform C team to Platform A team — still has production DB access to Platform C's database. No one noticed. This is privilege creep.

Access Recertification

Managers periodically review and confirm their team members still need their current access. Quarterly for privileged access, annually for standard access.

• Manager sees list of what each person can access
• Manager certifies: "yes still needed" or "revoke"
• Uncertified access is auto-revoked
• Evidence stored for audit trail

ACL vs Capability List

Access Control List (ACL)

Attached to the object — lists which subjects can access it and with what permissions.

Example: File "loan_data.csv" has ACL: [alice: read, bob: read+write, carol: none]

Capability List

Attached to the subject — lists which objects the subject can access.

Example: User alice's capability list: [loan_data.csv: read, reports/: read+write]

Key Terms

DAC MAC RBAC ABAC ACL Capability List Privilege Creep Access Recertification Content-Dependent Context-Dependent Bell-LaPadula

Exam Tips

DAC = OWNER controls access (flexible but hard to enforce at scale — user can accidentally expose data).
MAC = SYSTEM enforces classification labels (most restrictive — users cannot override).
RBAC = most common enterprise model (roles define permissions — easier to manage than individual ACLs).
ABAC = most flexible (attribute policies — can express complex context-aware rules for Zero Trust).
Privilege creep = accumulation of excess permissions — detected and remediated via access recertification reviews.

Work Application — Platform C Access Control

RBAC (Admin Portal): Module-scoped roles — loan_officer: view applications only; credit_analyst: view scores; admin: manage users. No wildcard permissions. Role assignments reviewed quarterly.

ABAC (Per-lender isolation): Partner A service token has tenant_id=mafc. Row-level policy on every DB query: WHERE tenant_id = token.tenant_id. Partner A token cannot see Partner D records even if the query is crafted to request them.

Access recertification: Quarterly manager review of all Platform C admin portal roles. Any engineer who left the team gets deprovisioned within 24 hours of manager review — not waiting for the quarterly cycle for leavers.

Practice Quiz

Q1. In DAC vs MAC — which model allows the resource owner to grant access to other users?

▼ Reveal Answer

DAC (Discretionary Access Control) — the object owner decides who gets access and can grant/revoke permissions at their discretion. In MAC, the system enforces labels and owners cannot override policy.

DAC is "discretionary" because it's at the owner's discretion. Linux file permissions are a classic example — the file owner can chmod to grant others access. MAC removes this owner control — only the system (based on classification labels) determines access. Government systems use MAC because DAC creates too much risk of accidental over-sharing.

Q2. An engineer moves from the Platform C team to the Platform A team but still retains all Platform C production access 6 months later. What security problem is this, and how is it detected?

▼ Reveal Answer

Privilege creep — accumulation of excess permissions over time without deprovisioning old access. Detected through access recertification: quarterly manager review where the Platform C manager sees a list of people with access and identifies that this engineer no longer belongs.

Privilege creep is a natural consequence of organizational change without a formal offboarding process for role changes (Movers — see Lesson 5). Access recertification is the primary detective control. The Platform C manager reviews their access list quarterly, sees the engineer's name, and removes them since they moved teams. For leavers this must be immediate; for movers, it should happen on the day of role change.

Q3. RBAC vs ABAC — which is more flexible, and which is more commonly used in enterprises?

▼ Reveal Answer

ABAC is more flexible (can express complex attribute-based policies including time of day, device compliance, location). RBAC is more commonly used in enterprises (simpler to implement and manage).

RBAC is the dominant enterprise model because it maps naturally to org charts (roles = job functions). ABAC is more powerful but requires a policy engine and attribute management infrastructure. Modern Zero Trust implementations combine both: RBAC for coarse-grained access, ABAC for fine-grained context-aware decisions (e.g., "even if you have the role, you can't access from an unmanaged device").

Q4. Platform C's per-lender token validation (Partner A token cannot see Partner D data) — which access control model is this?

▼ Reveal Answer

ABAC (Attribute-Based Access Control) — the policy uses an attribute of the token (tenant_id) matched against an attribute of the resource (tenant_id) to make the access decision.

This is a classic ABAC rule: if subject.tenant_id != resource.tenant_id, deny. The decision depends on attributes of both the subject (the JWT token) and the resource (the database row), not just the role. This is also an example of content-dependent access control — what the user can see depends on the data content itself.

Q5. An ACL is attached to a file and a capability list is attached to a user. What does each one contain?

▼ Reveal Answer

ACL (attached to the object/file): lists which subjects (users/processes) can access it and with what permissions. Capability list (attached to the subject/user): lists which objects the subject can access and with what permissions.

Both describe the same access control matrix from different angles. ACL = object perspective (who can read this file?). Capability = subject perspective (what can this user access?). For answering "who has access to file X?" — check the ACL. For answering "what can user Y access?" — check the capability list. On the exam, know which is attached to what.

← Lesson 2: SSO & Federation Lesson 4: Privileged Access →