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 current 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.

Minimum has a floor, a scope, and an end date. It means the least access that still lets the job be done, not less: an account that cannot do its work pushes people into workarounds such as borrowing a colleague's login. It is scoped to current duties: permissions that were correctly approved for someone's previous job stop satisfying least privilege the day they transfer, so a move must remove the old access, not just add the new. And it is time-bound: a contractor's access should end when the contract ends, and a temporary project grant should expire with the project.

Least privilege limits the blast radius of every failure. It does not stop an account from being compromised, since a phishing email can still succeed, but 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.

Privileged accounts, such as administrator accounts, deserve special care. Least privilege demands that administrators use a standard account for daily work such as email and browsing, and switch to a privileged account only when a task requires it. That privileged account should be personal to each administrator. A shared administrator account, one login used by several people, breaks individual accountability: the logs record the account, not the person, so no change can be attributed to whoever made it, and revoking one person's access means changing the password for everyone.

Least privilege applies to non-human identities too. An application's service account should hold exactly the operation it performs on exactly the object it touches, such as read access to one database table, not database-owner rights granted to avoid errors. Service accounts often run unattended with long-lived credentials, which makes excess rights on them especially dangerous.

Two similar-sounding terms describe different problems. Privilege creep is the gradual build-up of access by a legitimate user who changes jobs and keeps old permissions; nobody attacked anything, the access simply accumulated. Privilege escalation is an attacker or malicious insider gaining rights beyond those granted, for example by exploiting a flaw to become administrator. Least privilege reduces both: there is less to accumulate and less to start from.

AI agents, chatbots, and copilots are non-human identities, and least privilege applies to them exactly as it does to a service account: grant each one only the data and actions its task requires. A support bot that answers questions from the product documentation needs read access to that documentation, not write access to the ticketing system and not every customer's account history. If the task is only to look things up, the agent gets read-only access; if it never needs to send email or delete records, those tools are not connected to it.

An assistant that serves many users should act with the requesting user's own permissions, not through one all-powerful service account. When the agent runs as the person asking, it can only retrieve what that person could already open, so a sales representative cannot use the company copilot to pull up board meeting minutes they were never given. An agent identity with broad standing rights turns the assistant into a way around every other access decision, and its access logs can show only the agent, not the person who asked.

Instructions in a prompt are not an access control. Telling a model "never reveal board minutes" may stop casual leaks, but it is not a security control if the agent can technically reach that data, because prompt injection, crafted input hidden in a message, document, or web page, can override the instructions, so the instruction cannot be relied on. Real limits come from the permissions the agent's identity holds. The OWASP Top 10 for LLM Applications names this risk Excessive Agency: an agent given more functionality, permissions, or autonomy than its task needs, so that a manipulated or mistaken output causes real damage. The fixes are the familiar ones: minimal permissions, minimal tools, and human approval for high-impact actions.

Need-to-know is an information-centric restriction layered on top of least privilege and clearance: a person may access a specific piece of information only when the duties of their current assignment require that specific information. Least privilege is the broad rule covering all rights and permissions, such as read, write, execute, delete, and administer. Need-to-know is narrower: even among people authorized at the same level, a particular item is shared only with those whose work requires it.

Clearance is necessary but not sufficient. A clearance says a person is trusted to handle information at a given sensitivity level; need-to-know decides whether they should see this particular item. A general may hold a top secret clearance and still have no need to know the details of an operation they are not working on. Access requires both.

Several things that look like justification do not create a need-to-know:

• Seniority or rank. A senior manager has no automatic need-to-know for another team's data.
• Control of the system. An administrator who maintains a server, and could technically open the files on it, does not thereby need to read the salary records or case files stored there.
• Paperwork alone. A written request or a supervisor's sign-off documents a decision; it does not create the need. The need comes from the person's duties.

Need-to-know also ends with the assignment. When a person moves off a project, their need for its information ends that day, even though their clearance remains valid.

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.

Sometimes duties cannot be split, for example in a small organization where one bookkeeper handles all payments. When separation is impossible, the risk is handled with compensating controls: an independent person, such as the owner, a manager, or an external accountant, regularly reviews the transactions, reconciliations, and logs. A detective review by someone else stands in for the missing preventive split.

Dual control, also called two-person control or two-person integrity, requires two people to act together to complete one action at the same time, such as two key holders who must both turn keys to open a vault, or two officers who must both authorize a high-value transfer. ISC2 presents it as a form of separation of duties applied to a single step. SoD divides a process into stages held by different people; dual control puts two people on the same stage at the same moment, which is the choice when the sensitive action cannot be broken into stages.

Split knowledge means no single person knows the whole secret: each holds only part of it, such as half of a passphrase, part of a vault combination, or one component of a cryptographic key, and the secret works only when the parts are combined. Split knowledge is a common way to enforce dual control: two officers who each enter half of a master password are using split knowledge to make sure neither can act alone.

All of these controls share one residual risk: collusion. If the people involved agree to cooperate, the control is defeated. That is why SoD and dual control are usually paired with logging and independent review, and with job rotation, which makes long-running collusion harder to sustain.

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 tends to surface when someone new takes over. Mandatory vacations serve the same detective purpose by requiring an employee to take a block of consecutive leave. Both work only if someone else actually performs the duties during the absence; if the work is simply held until the person returns, nothing is exposed. Mandatory vacations are the fallback when rotation is impossible, for example when nobody else is qualified to take over a specialist role permanently but a trained colleague can cover it for a week or two. The warning signs that call for this control are an employee who never takes leave, refuses to let anyone else touch certain accounts, or insists on personally processing particular transactions.

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 many individual owners making consistently good decisions, and they do not. Owners overshare, forget to revoke, and can be tricked into granting access. There is no central guarantee that organizational policy is actually reflected in the permissions on any given object.

Malware exposes DAC's deepest weakness. A program runs with the identity of the user who launched it, so under DAC it inherits that user's discretion: it can change the permissions on the owner's files and share them with anyone, exactly as the owner could. This is the classic Trojan horse problem, where a malicious program leaks data simply by granting access to it. MAC prevents it, because not even the owner, and therefore no program running as the owner, can relabel data or share it past the system's policy.

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.

MAC and DAC can be enforced together. Many high-security systems keep owner-set permissions but apply the mandatory label check as well, and a request succeeds only if both checks pass. An owner can use discretion to restrict access further, or to share with people whose clearance already meets the label, but an owner's grant can never give a user access to an object labeled above that user's clearance. The mandatory check always wins.

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.

Privilege creep often enters through shortcuts that RBAC replaces. Setting up a new hire by copying an existing colleague's permissions clones everything that colleague has accumulated over the years, including access left over from previous jobs. Assigning a defined role gives the new person what the job needs, not what one individual collected.

Access reviews, also called recertification, check the result. Managers or role owners periodically confirm who still needs what, and excess access is removed. A review is a detective control: it finds privilege creep and leftover access after they have built up. It cannot detect fraud committed with rights a person legitimately holds, which is the job of separation of duties, dual control, and rotation. Swapping roles at the moment of transfer is the preventive counterpart, stopping creep before it starts. How reviews are run is covered in the identity life cycle lesson (Task 3.1).

RBAC has its own weakness: role explosion. When access must vary by context, such as location, shift, project, or device, a pure role model needs a new role for every combination until there are more roles than anyone can manage or review. Role explosion is a manageability problem with the role design, which is different from privilege creep, where individual users accumulate access. It is the usual reason to move context decisions into ABAC.

Attribute-Based Access Control decides access by evaluating attributes against policy rules. Attributes fall into four categories:

A policy might allow a read when the user's department is finance, the document is labeled internal, and the request comes from a managed device during business hours. Because one rule covers every combination, ABAC handles context without multiplying roles. It 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.

Environment attributes also drive risk-based MFA, also called adaptive authentication. Instead of asking for the same factors on every sign-in, the system scores the context of each attempt, such as a new device, an unusual location or impossible travel, an unfamiliar network, or behaviour that an AI or machine-learning model flags as abnormal for that user, and steps the sign-in up to an extra factor (or blocks it) only when the risk is high. A routine sign-in from a known device passes with fewer prompts. It is the same idea as ABAC's environment attributes applied at the moment of authentication.

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.