Access Control Models and Least Privilege

Access control models and least privilege. Reliable authentication proved who someone is. This lesson is about what they should then be allowed to do.

The scene. An analyst who has moved from sales to procurement to finance over five years can still do all three jobs in the systems, because each move added access and none ever took any away. On paper they are one of the most powerful users in the company, not by design, but by accumulation. No one decided they should have this reach; it just built up.

The governing principle is least privilege: every user, and every process or account, is granted only the minimum access required to perform its function, and nothing more. Alongside it sits need-to-know: access to specific information is limited to those who require it for their work.

The point of both is containment. If an account is compromised or misused, the damage is bounded by how little it could do. Broad access to be efficient, or in case they need it, inverts this, turning every account into a large blast radius. Access should track function, not convenience and not seniority, and the default posture is deny: no access unless a need justifies it.

The exam expects you to recognise how access decisions are made. First, role-based access control, R-BAC: permissions attach to roles, and users get access by being assigned a role matching their job. It scales, and it is the most common model in business systems.

Second, discretionary access control, DAC: the data owner grants access at their discretion, common in file systems.

And third, mandatory access control, MAC: access is enforced centrally through security labels, such as classification levels, used in high-security environments where users cannot override the rules.

So the shortcut: by role, owner, or label. When a question describes access granted by job role, that is R-BAC. By the owner’s choice, DAC. By system-enforced labels, MAC.

Now the analyst is a textbook case of privilege creep: access accumulated across role changes and never removed. Each move was reasonable in isolation; the sum is an account that holds far more than the current role needs, breaching least privilege badly.

And the remedy is to strip it back. Not to add to it, not to tidy around it, but to reduce access to what the present role requires. Privilege creep is one of the most common findings a periodic access review exists to catch, which is the next lesson.

So the wrong answer to watch for. When a scenario describes someone retaining access from former roles, the answer is that their access is excessive and should be removed, not that they are versatile or due more. Accumulated access is a control problem, not a sign of flexibility.

So carry this away. Least privilege is the minimum the role needs, because every excess permission is extra risk if the account is compromised. And privilege creep is a real finding: access must be reduced when it is no longer needed, back to what the current role, and need-to-know, actually require.