Access Control

From identity to permission

Access control decides which subjects (people, services, devices) may perform which actions on which objects (files, systems, records). It works in a fixed order, the same order as the authentication, authorization and accounting (AAA) framework described in What Is Information Security?:

1. Identification: the subject claims an identity — a username, an email address, a badge number. A claim proves nothing yet.
2. Authentication: the subject proves the claim with one or more factors (see Passwords and Authentication).
3. Authorization: the system decides whether this authenticated subject may do this action on this object. This decision is what an access control model describes.
4. Accounting: the action is recorded, so it can be traced back to the subject later.

Every step depends on the one before. Strong authorization rules are worthless if accounts are shared ("everyone uses admin"), because then the system cannot tell who is acting and the logs cannot tell who did it.

Access control models

An access control model is the logic that answers "may this subject do this?". The four main models differ in who sets the rules and what they are based on.

Discretionary access control

In discretionary access control (DAC), the owner of an object — usually the person who created it — decides who else may access it. Windows NTFS permissions and Unix file permissions are DAC (see Users, Permissions and Access Control), and so is the "share" button in a document editor. DAC is flexible and easy to understand, but it depends on every owner making good decisions; it is how a confidential spreadsheet ends up shared with "everyone in the organization".

Mandatory access control

In mandatory access control (MAC), a central policy decides, and users — even the owner of a file — cannot change it. Every object carries a label (for example Confidential, Secret, Top Secret) and every subject a clearance; the system compares them on each access. A classic MAC policy for confidentiality, the Bell–LaPadula model, is summed up as "no read up, no write down": you may not read above your clearance, and you may not write information down to a lower level where it could leak. On Linux, SELinux adds mandatory rules on top of the normal permissions, so even a process running as root is limited to what the policy allows.

Role-based access control

In role-based access control (RBAC), permissions are attached to roles that match jobs — "accounts payable clerk", "service desk agent", "database administrator" — and people receive roles. When someone changes jobs, you change their roles instead of hundreds of individual permissions. Most organizations work this way, often with directory groups as roles; the cloud version is explained in Identity and Access Management.

Attribute-based access control

Attribute-based access control (ABAC) evaluates rules over attributes: of the subject (department, clearance, employment type), the object (classification, owner, project), the action (read, delete) and the environment (time, location, device health). A rule might say: "contractors may read project documents of their own project, only from a managed device, only during working hours". ABAC is very expressive and fits cloud policies with conditions and conditional access in identity platforms, but complex rule sets are hard to understand and to audit. In practice organizations combine RBAC for the basics with attribute conditions for the sensitive cases.

Rule-based access control is sometimes listed separately: global rules that apply to every subject alike, such as a firewall rule set or a ban on logins outside office hours.

Least privilege and need to know

Least privilege means every account — human or service — has only the permissions it needs for its task, and only for as long as it needs them (see also least privilege on Windows and Linux). It limits the damage of a mistake, of malware running under the account, and of an attacker who steals it.

Need to know adds a restriction on information: a clearance or role allows access to a category of data, but you only see the specific data your task requires. A service desk agent may be allowed to view customer records, but has no reason to browse the record of a famous customer who has not called.

Both principles meet implicit deny: what is not explicitly allowed is forbidden. Network access control lists end with an invisible deny (see how an ACL is processed) and cloud permission systems start from denial (see policy evaluation logic). A well-designed system fails closed: when it cannot decide, it refuses.

Separation of duties

Separation of duties (SoD) splits a sensitive process so that no single person can complete it alone. The person who creates a payment does not approve it; the engineer who requests a firewall change does not approve it; the developer who writes code does not deploy it to production unreviewed. Fraud or sabotage then needs two people working together (collusion), and honest mistakes are caught by the second pair of eyes.

Related controls: dual control or the two-person rule (two people must act together, for example two keys for a safe), job rotation (people change tasks, so irregularities come to light) and mandatory vacation (someone else does the work for a while).

An RBAC check with a separation-of-duties rule

This sketch implements the core of RBAC: a role-to-permission table, user-to-role assignments, an authorization check with implicit deny, and a scan for users whose roles together break a separation-of-duties rule. The names are fictional.

# Role-based access control: permissions belong to roles, people get roles.
ROLE_PERMISSIONS = {
    "employee": {"timesheet:submit", "intranet:read"},
    "accounts-payable": {"payment:create", "invoice:read"},
    "finance-manager": {"payment:approve", "invoice:read", "report:read"},
    "network-engineer": {"firewall:request-change"},
    "change-approver": {"firewall:approve-change"},
}

USER_ROLES = {
    "Anna de Vries": {"employee", "accounts-payable"},
    "Bram Jansen": {"employee", "finance-manager"},
    "Chris Bakker": {"employee", "network-engineer", "change-approver"},
}

# Separation of duties: no one may hold both permissions of a pair.
SOD_RULES = [
    ("payment:create", "payment:approve"),
    ("firewall:request-change", "firewall:approve-change"),
]


def permissions(user):
    result = set()
    for role in USER_ROLES.get(user, set()):
        result |= ROLE_PERMISSIONS[role]
    return result


def is_allowed(user, permission):
    return permission in permissions(user)  # anything not granted is denied


print("Anna approves payment:", is_allowed("Anna de Vries", "payment:approve"))
print("Bram approves payment:", is_allowed("Bram Jansen", "payment:approve"))
print("Unknown user reads intranet:", is_allowed("Dana Smit", "intranet:read"))

for user in sorted(USER_ROLES):
    granted = permissions(user)
    for first, second in SOD_RULES:
        if first in granted and second in granted:
            print(f"SoD conflict: {user} has both {first} and {second}")

Anna approves payment: False
Bram approves payment: True
Unknown user reads intranet: False
SoD conflict: Chris Bakker has both firewall:request-change and firewall:approve-change

Each of Chris's roles is harmless on its own; the combination lets him request and approve his own firewall change. That is why separation-of-duties checks look at the total set of permissions a person has, and why identity management tools run them whenever a role is assigned, not only during an audit.

Privileged accounts

Privileged accounts — domain administrators, root, cloud global administrators, database administrators, service accounts with wide rights — can change security settings, read all data and erase their own traces. Attackers go after them first, so they need more than a strong password:

• Separate accounts: administrators use a normal account for email and browsing and a separate administrator account only for admin work, ideally from a dedicated, hardened workstation.
• Phishing-resistant MFA on every privileged account.
• Few of them, each with a named owner, and no shared accounts without a way to see who used them.
• Break-glass accounts: two or more emergency accounts, stored securely and monitored closely, for when the normal sign-in path is down (see Privileged Access Management).

Privileged access management (PAM) is the set of tools and processes that control, monitor and record the use of privileged accounts. Typical capabilities:

• Vaulting: privileged passwords and keys are stored in a vault. People check a credential out for a task, and the vault changes the password afterward, so nobody knows it permanently.
• Just-in-time (JIT) access: nobody holds administrator rights permanently; they are granted on request, with approval and a reason, for a few hours, then removed automatically. An attacker who steals the account outside that window gets nothing.
• Session recording: administrative sessions run through the PAM system, which records them, so you can see exactly what was done — useful for investigations and as a deterrent.

Joiners, movers and leavers

Access is not set once. It follows a person through the organization in the joiner-mover-leaver (JML) process:

• Joiner: a new employee gets the roles of their job on day one, triggered by the human resources (HR) system — not by copying a colleague's account with all its history.
• Mover: someone changing jobs gets the new roles and loses the old ones. Forgetting the second half is the main cause of privilege creep.
• Leaver: all access ends on the last day — accounts, virtual private network (VPN) access, cloud applications and badges are disabled, and shared passwords they knew are changed. With single sign-on, one switch covers most applications; local accounts and third-party tools need their own step.

Accounts whose owner has left, or that belong to nobody, are called orphaned accounts. They are attractive to attackers because nobody notices when they are used.

Access reviews

An access review (also called access recertification) is a periodic check in which managers or data owners confirm, for each person, that every access right is still needed — and remove what is not. Reviews catch what the JML process missed: privilege creep, orphaned accounts, temporary rights that became permanent. Privileged access is typically reviewed more often (for example quarterly) than ordinary access. A review only works if the reviewer understands what they approve; a list of cryptic group names invites "approve all".