Access Controls

Least Privilege

Least privilege is the foundational access control principle: every user, process, and system should have access only to the resources required to perform their specific job function, and nothing more. Least privilege limits blast radius when an account is compromised — an attacker who gains access to a low-privilege account can only access what that account can access. It also limits damage from insider threats by ensuring users cannot access data outside their job scope.

Implementing least privilege requires:

• Role-based provisioning: access is determined by job role, not by individual request
• Regular access reviews: certifying that current permissions still match current responsibilities
• Just-in-time access: temporary elevation for specific tasks rather than permanent privileged access
• Separation of duties: preventing any single person from having both the ability to perform a sensitive action and the ability to conceal it

Mandatory Access Control (MAC)

In a MAC system, access decisions are made by the operating system based on security labels assigned to subjects (users) and objects (files, resources). The critical characteristics of MAC:

• System enforced: the OS or security kernel makes all access decisions, not users or application owners
• Admin-assigned labels: a security administrator assigns classification labels to both subjects and objects. Users cannot modify these labels regardless of file ownership.
• Users cannot change labels: even if a user owns a file, they cannot downgrade its classification label or grant access to users below the required clearance level
• Government/military environments: MAC is the model used for classified systems where data classification (Confidential, Secret, Top Secret) must be strictly enforced

Access in MAC is determined by comparing the subject's clearance level against the object's classification label. A user with Secret clearance can access Secret and Confidential data but not Top Secret data, regardless of file ownership or personal relationships.

Discretionary Access Control (DAC)

In a DAC system, the owner of a resource controls who can access it. This is the default model in most operating systems — when you create a file, you can decide who can read, write, or execute it by modifying its permissions.

• Owner controlled: the creator or designated owner of a resource manages its access permissions
• Flexible: owners can grant access to others without needing administrator involvement
• Weak security: the model is fundamentally weak because it relies on every user making correct access decisions. A user can inadvertently (or intentionally) grant access to sensitive data to unauthorized parties.
• NTFS file system: Windows NTFS permissions are a DAC implementation — file owners can change permissions

DAC's weakness is that security is only as strong as the decisions made by individual resource owners, who may not understand the sensitivity of their data or the risks of sharing it.

MAC vs. DAC Comparison

Role-Based Access Control (RBAC)

RBAC assigns access rights to roles (or groups) rather than to individual users. A user gains access by being assigned to a role; the role defines what resources are accessible. This is the most common enterprise access control model.

Key RBAC characteristics:

• Group membership grants rights: in Windows Active Directory, being a member of the “Finance” security group implicitly grants all the access rights assigned to that group — the user does not need individual permission grants for each resource
• Implicit rights: access is not explicitly granted to the individual; it is inherited through group membership. Adding a user to a group automatically extends all of that group's permissions.
• Scalable administration: changing access for a role (by modifying the group) affects all users in that role simultaneously, rather than requiring individual user modification
• Principle of least privilege: roles should be designed with minimal permissions; users should be assigned only to roles relevant to their job function

Rule-Based Access Control

Rule-based access control uses system-enforced rules in access control lists (ACLs) rather than role membership. The rules are evaluated automatically by the system when access is attempted. Key characteristics:

• System-enforced: rules are evaluated by the system (firewall, OS, application), not by user or admin discretion at the time of access
• Conditions and attributes: rules can be based on time of day, browser type, IP address range, geographic location, or any attribute the system can evaluate
• ACL implementation: firewall ACLs are the classic example — a rule allows or denies traffic based on source IP, destination IP, port, and protocol, regardless of which user is making the request

Rule-based example: “Allow access to the financial system only from IP addresses in the 10.1.0.0/24 subnet, only on weekdays, only between 8 AM and 6 PM, only from devices running Windows 10 or later.” These conditions are checked automatically by the system for every access attempt.

Important distinction: Rule-based vs. RBAC: RBAC is about who you are (your role/group). Rule-based is about conditions that must be met (time, location, device type). Both can be combined.

Attribute-Based Access Control (ABAC)

ABAC is the most flexible and context-aware access control model, often called next-generation access control. Instead of relying on a single attribute (role, rule, or label), ABAC evaluates a combination of attributes from multiple sources simultaneously to make each access decision:

• Subject attributes: user's role, department, clearance level, employment status, location
• Object attributes: file classification, data type, owner, sensitivity level
• Environment attributes: time of day, day of week, IP address, geographic location, device type, network type (VPN vs. corporate vs. home)
• Action attributes: read, write, delete, execute, share

A single ABAC policy might read: “Allow read access if subject.department = Finance AND subject.clearance ≥ Confidential AND object.type = financial_report AND environment.time between 8AM-6PM AND environment.network = corporate.” Changing any one of these attributes changes the access decision.

Why ABAC is Called Next-Generation

Traditional access control models make binary, context-free decisions: a user either has access or they do not, based on a static role or rule. ABAC makes dynamic, context-aware decisions that change based on the full situation at the time of access:

• The same user can be granted access from the office network but denied from home Wi-Fi
• The same user can be granted read access but denied write or delete access based on the current context
• A file that is accessible during business hours can be automatically blocked after hours without changing any permissions
• A user can be granted access during normal operations but denied during a declared security incident

ABAC policies are more complex to write and manage than RBAC policies, but they provide significantly finer-grained and more adaptive control. ABAC is the model used in zero-trust architectures where no access is implicitly trusted and every request is evaluated against full context.

Access Control Model Comparison

Time-of-Day Restrictions

Time-of-day restrictions limit when a user or system can access resources, regardless of their credentials. These are a form of rule-based access control implemented at the account or policy level:

• A call center employee who works 9 AM to 5 PM can have their account configured to reject logins outside those hours
• A server can be configured to reject authentication attempts between midnight and 6 AM
• Combined with ABAC, time restrictions become one attribute among many in a contextual policy

Time-of-day restrictions are effective at limiting the window during which stolen credentials can be used — an attacker who obtains a call center employee's password cannot log in at 3 AM if time restrictions are enforced. They also reduce the window during which automated attacks can operate.