Logical Access Controls: Least Privilege, DAC, MAC, and RBAC

Access control answers one question: should this subject be allowed to perform this action on this object? The subject is the active party, usually a user or a process acting for a user. The object is the resource, such as a file, database record, or application function. Logical access controls, sometimes called technical controls, enforce the answer in software: permissions, access control lists, security labels, and role assignments.

Logical controls are one of three control categories. Physical controls, such as locks and badge readers, govern access to spaces and hardware. Administrative controls, such as policies and background checks, govern people through rules. The CC exam expects you to keep these categories straight: a firewall rule and a file permission are logical, a mantrap is physical, an acceptable use policy is administrative.

Access control operates after identification and authentication have established who the subject is. Authorization is the access control step: given a proven identity, the system consults its rules to permit or deny the request. Everything in this lesson, least privilege, separation of duties, and the four models, is about how those authorization rules are designed and who gets to set them.

The Principle of Least Privilege (PoLP) says every user, process, and system should be granted the minimum access required to perform its assigned task, and nothing more. A payroll clerk needs the payroll application, not the customer database. A web server process needs to read its content directory, not write to system files. If access is not needed for the job, it is not granted, regardless of rank or convenience.

Least privilege limits the blast radius of every failure. When an account is compromised by phishing, the attacker inherits only that account's permissions, so the less it holds, the less is lost. The same logic contains malware, insider misuse, and honest mistakes: a user who cannot delete the finance share cannot delete it accidentally either.

Least privilege is often paired with need-to-know, and the exam distinguishes them. Least privilege is the broad rule covering all rights and permissions: read, write, execute, delete, administer. Need-to-know is narrower and information-centric: even among people authorized at the same level, a specific piece of information is shared only with those whose duties require that specific information. A general may hold a high clearance, satisfying the access rules, and still have no need to know the details of a particular operation.

Privileged accounts, such as administrator accounts, deserve special mention. Least privilege demands that administrators use a standard account for daily work and switch to the privileged account only when the task requires it.

Separation of Duties (SoD) splits a sensitive process across two or more people so that no single person can complete it alone. The classic target is fraud: the person who creates a vendor in the payment system should not be the person who approves payments to vendors. To steal, the two would have to collude, and requiring collusion is exactly the point, because conspiracies are harder to start and easier to detect than solo abuse.

SoD also prevents concealment. If one person could both make a change and approve the audit record of that change, they could commit an error or a crime and erase the evidence. Splitting commit from approve, and both from audit, means someone else always sees the transaction.

Two related controls appear alongside SoD on the exam. Dual control requires two people to act together to perform one action, such as two key holders who must both turn keys, or two officers who must each enter half of a master password. SoD divides a process into stages held by different people; dual control puts two people on the same stage at the same moment.

Job rotation moves people between roles periodically. It cross-trains staff, but its security value is detection: a fraud that depends on the perpetrator personally managing the same accounts forever tends to surface when someone new takes over. Mandatory vacations serve the same detective purpose, forcing someone else to run the process for a while.

In Discretionary Access Control, the owner of a resource decides who may access it. If you create a file, you own it, and you may grant a colleague read access, give a team write access, or share it with everyone, entirely at your discretion. The system enforces whatever the owner sets, typically through an access control list (ACL) attached to the object listing which subjects hold which permissions.

DAC is the default model in mainstream operating systems and file sharing platforms, and its strength is flexibility. Owners know their own data and can grant access instantly without waiting for an administrator, which suits collaborative environments where sharing needs change constantly.

That same flexibility is its weakness. Security depends on thousands of individual owners making consistently good decisions, and they do not. Owners overshare, forget to revoke, and can be tricked into granting access. Malware running as a user inherits that user's discretion and can pass access along. There is no central guarantee that organizational policy is actually reflected in the permissions on any given object.

The exam trigger for DAC is ownership and discretion. When a scenario says the file creator decides who can read it, or a user shares their document with a coworker, the model in play is DAC.

In Mandatory Access Control, the system, not the user, decides all access. Every object carries a security label, such as confidential, secret, or top secret, and every subject holds a clearance. The operating system compares label to clearance on every access attempt and enforces the outcome. Neither the file's creator nor its user can change the label, share the file, or override the decision. Policy is set centrally by a security administrator and enforced uniformly by the system, which is why the model is called mandatory.

MAC is the most rigid and most restrictive of the models, and that rigidity is the feature. It exists for environments where the cost of unauthorized disclosure is severe: military systems, intelligence agencies, and other high-security government settings where information is formally classified. A user with secret clearance simply cannot open a top secret document, and no amount of ownership, seniority, or goodwill changes that.

The price of that assurance is inflexibility and administrative overhead. Every object must be labeled, every user cleared, and routine sharing that DAC handles in seconds requires a formal decision in MAC. That trade is worthwhile only where confidentiality outranks convenience.

The exam triggers for MAC are labels, classifications, clearances, and the phrase system-enforced. When users cannot change permissions even on data they created, you are looking at MAC.

In Role-Based Access Control, access is attached to roles, and users get access by being assigned to roles. The organization defines a role such as help desk technician, grants the role the permissions that job needs, and then every person assigned the role inherits exactly those permissions. Nobody grants access to individuals directly; membership in the role is the grant.

RBAC is how large organizations scale access management. Ten thousand employees do not need ten thousand hand-crafted permission sets; they need a few hundred well-defined roles. Onboarding becomes assign the role, a transfer becomes swap the roles, and offboarding becomes remove the roles, which makes RBAC a natural partner to the identity life cycle and a structural defense against privilege creep. Reviews get easier too, because auditors certify a role's permissions once instead of certifying each user separately.

Attribute-Based Access Control decides access by evaluating attributes of the subject, the object, the action, and the environment against policy rules. A policy might allow access when the user's department is finance, the document is labeled internal, and the request comes from a managed device during business hours. ABAC is the most fine-grained and context-aware model, and the CC exam expects only recognition: attributes and conditions, rather than owners, labels, or roles, signal ABAC.

Most exam questions about the models reduce to one question: who or what decides access? Anchor each model to its decider and the trigger words follow.

Try a scenario. A hospital wants every newly hired nurse to automatically receive the same access as every other nurse, with no per-person decisions. That is RBAC: access follows the job role. Change the scenario so a records clerk decides which colleagues may open a file she created, and it becomes DAC. Change it again so records carry sensitivity labels that no user can alter and access depends on each employee's clearance, and it is MAC. Add a rule granting access only from hospital-managed devices during a shift, and the attribute logic is ABAC.

One last trap: the most restrictive or most rigid model is MAC, and the model that scales best for large organizations is RBAC. The exam rarely rewards DAC as a security improvement; it appears as the flexible default whose weaknesses the other models fix.