8.3 DAC, MAC, RBAC, and ABAC

Key Concepts

Access control models are patterns for making authorization decisions. The CC exam expects you to recognize the model that fits a scenario, not to recite theory. For every model, ask three questions: who controls the permission, what information drives the decision, and how flexible is the rule?

Discretionary access control (DAC) gives the owner of an object discretion to share it. A document owner grants a colleague read or edit rights to a file. DAC underlies operating-system file permissions, shared drives, and most cloud collaboration tools. It is flexible and user-friendly, but that very flexibility is its weakness: a user can over-share a sensitive file or grant edit when read would do. On exams, the keyword is owner decides.

Mandatory access control (MAC) is centralized and rigid. Access is governed by labels, classifications, and clearances that ordinary users cannot change. A document labeled Secret is readable only by subjects holding Secret clearance and a valid need-to-know. The owner cannot simply decide to share a Top Secret file with someone uncleared. MAC is associated with military, intelligence, and highly regulated environments. Keyword: labels and clearances enforced by the system.

Role-based access control (RBAC) assigns permissions to roles that represent job functions, then assigns users to roles. A hospital may define roles such as emergency nurse, attending physician, billing clerk, pharmacist, and system administrator. RBAC scales: hiring a new billing clerk means assigning one role, not hand-picking dozens of permissions. It must be governed, though. Roles that are too broad over-grant; too many tiny roles create role sprawl that nobody can audit. Good RBAC maps roles to real duties, separates conflicting responsibilities, and is reviewed periodically. Keyword: job function determines permissions.

Attribute-based access control (ABAC) decides using attributes of the subject, object, action, and environment: department, employment status, project code, data classification, device compliance, network location, time of day, or transaction amount. An ABAC rule might allow a claims adjuster to approve claims only for assigned regions, from a managed device, during business hours, below a dollar threshold. ABAC is powerful for context but depends on accurate attributes and well-tested policies. Keyword: context and conditions.

Most production systems combine models. A file-sharing app may use DAC when a user shares a document, RBAC for administrator privileges, and ABAC to block downloads from unmanaged devices. For exam purposes, identify the model that drives the main access decision the question describes.

Exam Application

Use this quick decision table to match clues to models:

Walk four micro-cases. A project manager creates a folder and invites two contractors — the owner chose, so DAC. A report labeled Confidential is readable only by cleared personnel and the user cannot relabel it — system-enforced labels, so MAC. All help-desk analysts can reset passwords but cannot approve payments because they hold the help-desk role — RBAC. Access is allowed only when the analyst is on the corporate network using a compliant laptop during business hours — conditional context, so ABAC.

Common traps: candidates pick MAC whenever they see the word "classification," but if a user chose to share, it is still DAC. They pick RBAC whenever a job title appears, but if the decisive factor is device or time, it is ABAC. And single sign-on (SSO) and multifactor authentication (MFA) are authentication mechanisms, not access-control models — they are tempting distractors precisely because they are not models at all.

Finally, match the model to the business need rather than the most technical-sounding option. DAC is flexible and collaborative, MAC is strict and consistent for classified data, RBAC is manageable and scalable for job functions, and ABAC is adaptive to risk and context. The strongest answer reflects which property the scenario actually requires.

Comparing the Models Head to Head

When two options seem plausible, compare the models on who controls the decision and what it costs to administer:

Notice the trade-off the table exposes: as control moves from the individual owner (DAC) toward central policy (MAC, ABAC), consistency improves but flexibility and ease of use drop. RBAC sits in the practical middle, which is why most enterprises adopt it as their backbone and layer ABAC conditions on top for sensitive actions.

A recurring CC distractor is rule-based access control, sometimes also abbreviated in ways that look like RBAC. Rule-based control applies the same fixed rules to everyone, such as a firewall permitting traffic only on specific ports regardless of who sends it. It is not driven by job role, so do not confuse it with role-based access control even though the acronyms collide. ABAC generalizes rule-based logic by letting the rules reference rich attributes about the subject, object, and environment.

One more practical point the exam rewards: RBAC simplifies the joiner-mover-leaver lifecycle. When someone is hired, they receive a role; when they transfer, the old role is removed and a new one assigned; when they leave, the role assignment is revoked and access disappears at once. Managing this through roles is far less error-prone than editing thousands of individual permissions, which is precisely why per-user grants tend to rot into privilege creep while well-governed roles do not. Match the model to whether the scenario emphasizes owner control, classification, job function, or context, and the right answer follows.