Authorization Models: RBAC, MAC, and DAC

Access control models define the rules and policies that govern which subjects (users, processes) can access which objects (files, systems, data). The model chosen determines who can grant access, how permissions are assigned, and how enforcement works. The Security+ exam covers four primary models: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Rule-Based Access Control. Understanding each model's strengths and appropriate use cases is essential for designing effective authorization systems.

In Discretionary Access Control (DAC), the resource owner has discretion over who can access their resources and can grant or revoke access to other users. The 'discretionary' aspect is that owners decide — the system enforces their decisions but doesn't dictate them. This is the model used in most personal computing environments (Windows NTFS file permissions, Linux/Unix file permissions). The security limitation of DAC is that it requires every resource owner to make correct access decisions — a user who receives access to a file can grant that access to others without administrator involvement, potentially spreading sensitive data beyond its intended audience.

DAC has two inherent security risks. Transitive access: user A grants user B access, user B grants user C access — the original owner may not even know C has access to their resource. The Confused Deputy Problem: a privileged program acting on behalf of a less-privileged user can inadvertently use its privileges in a way the user couldn't directly. In DAC environments, a single compromised account can potentially access all resources that user has been granted access to, and may grant others access before the compromise is detected. DAC is convenient but creates challenges for strict information containment.

In Mandatory Access Control (MAC), the operating system enforces access policies based on security labels assigned to both subjects (users) and objects (data). Users cannot override or change these policies — only the system administrator or security policy can modify them. MAC is used in classified government and military environments where data must be strictly compartmentalized. A user with a 'Secret' clearance cannot access data labeled 'Top Secret' even if the data owner would like to grant them access. The Bell-LaPadula model (no read up, no write down) and Biba model (no write up, no read down) are formal MAC implementations.

Two formal MAC models encode security objectives as mathematical rules. Bell-LaPadula focuses on confidentiality: subjects cannot read data above their classification level (no read up) and cannot write data to a lower classification level (no write down). This prevents sensitive information from flowing to unauthorized users. Biba focuses on integrity: subjects cannot write to a higher integrity level (no write up) and cannot read from a lower integrity level (no read down). Biba prevents contamination of high-integrity data by low-integrity inputs. Real MAC systems (like SELinux) combine aspects of both models.

Role-Based Access Control (RBAC) assigns permissions to roles rather than directly to individual users, then assigns users to roles. This solves the management challenge of assigning individual permissions at scale. Common roles in enterprise environments: admin, auditor, developer, HR_manager, finance_analyst. When a new employee joins, they are added to the appropriate role and immediately inherit all the permissions that role requires. When an employee changes positions, their role changes and permissions adjust automatically. RBAC is the dominant model in enterprise IAM systems.

RBAC's primary advantage is administrative scalability. Modifying a role's permissions instantly affects all users in that role — no need to update individual user records across hundreds of systems. RBAC naturally supports separation of duties by ensuring no single role has conflicting permissions (e.g., a role that can both create and approve financial transactions). RBAC also simplifies compliance: auditors can review roles and their permissions rather than auditing thousands of individual user assignments. The limitation: role explosion — organizations sometimes create too many granular roles, creating management complexity that undermines the scalability benefit.

Rule-Based Access Control (not to be confused with RBAC) grants or denies access based on a set of conditional rules rather than identity or role alone. Firewall rules are the classic example: 'Allow TCP from 192.168.1.0/24 to any on port 443. Deny all other traffic.' Access is evaluated against rules in order until a match is found. Rule-based control is commonly combined with other models: MAC uses security labels as rules, and Attribute-Based Access Control (ABAC) extends rule-based logic to evaluate multiple attributes (user department, device type, time of day, resource classification) simultaneously for fine-grained decisions.

ABAC (Attribute-Based Access Control) is the most flexible and fine-grained access control model. Access decisions evaluate multiple attributes simultaneously: subject attributes (user department, clearance level, location), object attributes (data classification, owner department, retention label), environmental attributes (time of day, device type, network location), and action attributes (read, write, delete). A policy might say: 'Allow access if user.department = Finance AND resource.classification = Internal AND device.type = corporate AND time.hour BETWEEN 8 AND 18.' ABAC enables zero-trust policy decisions and is implemented by products like XACML and cloud IAM policy engines.

The appropriate access control model depends on the security requirements and organizational context. DAC: suitable for personal computing and small teams where convenience is prioritized over strict control. MAC: required for classified government/military environments with strict information compartmentalization. RBAC: ideal for enterprises where administrative scalability is critical and roles map cleanly to job functions. ABAC: appropriate for cloud environments and zero-trust architectures where context-aware, fine-grained policies are needed. In practice, most organizations use a combination: RBAC as the foundation with ABAC for context-sensitive access decisions.

Regardless of the access control model, Access Control Lists (ACLs) are the most common technical implementation mechanism. An ACL attached to a resource specifies which subjects can perform which actions. File system ACLs (Windows NTFS, Linux POSIX ACLs) control file and directory access. Network ACLs control traffic flow at the router or cloud network level. Database ACLs control table and row-level access. ACLs can implement any of the models discussed: a file's ACL implements DAC when the owner controls it; a security system's ACL implements MAC when labels determine entries; an application's ACL implements RBAC when entries reference roles.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: DAC lets resource owners control access (flexible but risky); MAC uses system-enforced security labels (strict, used in classified environments); RBAC assigns permissions to roles for enterprise scalability; and ABAC evaluates multiple attributes for fine-grained zero-trust decisions. Next up we explore Federated Identity: SAML, OAuth, and OpenID Connect.