Access control models

Introduction

Access Control Security : Typically, rules and policies are used to establish which users have access to which resources and what actions are approved. In layman's terms, Access Control entails determining who you are and what you are permitted/restricted from doing, and then granting you permission to conduct those actions on resources.

For example, after entering your login and password, authentication occurs, and the system determines if you are authorized to send or receive emails. Access Control models establish who has access to a certain resource. And what actions they can perform!

Access control is a security framework that determines who has access to which resources through previously placed authentication and authorization rules. Access controls authenticate users by verifying login credentials, including usernames, passwords, PINs, security tokens, and biometric scans.

Types of Access control framework

1. DAC

Discretionary Access Control: It is an access control model where the owner or creator of a resource (such as a file, folder, or database) has the authority to decide who can access it and what level of access they have. The owner grants or revokes permissions to other users or groups at their discretion.

Key features of DAC

Ownership-Based Control: The resource owner has complete control over permissions.
Flexibility: Users can easily modify permissions to fit their needs.
User-Centric: Permissions are granted at an individual or group level.
Lack of Centralization: Access control is decentralized, as each owner manages their resources independently.
Prone to Errors: Since users control permissions, mistakes or malicious changes can lead to security vulnerabilities.

Example : In a DAC system, if a user creates a document, they can decide:

Who can read, write, or execute the file.
Whether to share it with others or keep it private.

Advantages of DAC

Easy to implement and manage.
Highly flexible for collaborative environments.

Disadvantages of DAC

Less Secure: Vulnerable to privilege escalation and accidental misuse.
No Centralized Oversight: Difficult to enforce organization-wide policies.

DAC is commonly used in operating systems like Windows and Linux, where file permissions are assigned by the user who owns the file.

2. Non DAC

Non-Discretionary Access Control refers to access control models where permissions are managed centrally by an authority rather than being controlled at the discretion of individual resource owners. These models enforce access rules based on predefined policies, roles, or attributes, making them more structured and less prone to human error compared to DAC.

Key features of Non-DAC

Centralized Control: Permissions are managed by system administrators or predefined policies.
Policy-Based Decisions: Access depends on rules, roles, or attributes rather than user discretion.
Higher Security: Minimizes risks from user errors or malicious changes.
Complex Implementation: Requires thorough planning and consistent policy enforcement.

Key Types of Non-DAC Models

1. RBAC

Role-Based Access Control is an access control model where access to resources is determined based on the roles assigned to users within an organization. Permissions are associated with roles, not individual users, making it easier to manage access across large systems.

RBAC allows employees to access only the information they need to do their job. Employee roles in an organization determine the privileges granted to individuals and prevent lower-level employees from accessing sensitive information or performing higher-level tasks.

Key Concepts of RBAC

Roles:
- A role represents a job function or responsibility within an organization (e.g., "Admin," "Manager," "Employee").
- Permissions are assigned to roles, and users are assigned to roles.
Permissions:
- Define what actions a role can perform on specific resources (e.g., "read," "write," "delete").
Users:
- Individuals are assigned one or more roles, inheriting the permissions associated with those roles.
Separation of Duties:
- Ensures no single user is given excessive permissions, reducing the risk of fraud or error.
Role Hierarchies:
- Roles can be organized in a hierarchy, where higher-level roles inherit permissions from lower-level ones.

User-Role Mapping:
- Each user (e.g., Admin Jane, Pharmacist John) is assigned a specific role (Administrator, Pharmacist) based on their responsibilities within the hospital system.
Role-Permission Mapping:
- Each role is linked to specific permissions that define the actions the role can perform. For example:
- The Administrator can manage staff but does not have access to prescribe medication or view patient records.
- The Doctor and Nurse share some overlapping permissions, such as prescribing medication and accessing patient records.
Access Control:
- Admin Jane cannot dispense or prescribe medication since her role as an Administrator does not include those permissions.
- Pharmacist John cannot prescribe medication or manage staff, as these actions are outside the scope of the Pharmacist role.

This example highlights how RBAC ensures that users can perform only the actions necessary for their roles, enhancing security and reducing unauthorized access.

Advantages of RBAC:

Simplified Management: Centralized control makes it easier to manage permissions for large numbers of users.
Enhanced Security: Limits access based on job functions, reducing the risk of unauthorized access.
Privilege creep occurs when users accumulate permissions over time that are no longer necessary for their current roles, often due to role changes or insufficient revocation of old permissions. This can lead to security risks. RBAC helps in preventing the same
Regulatory Compliance: Helps organizations comply with standards by enforcing least privilege access.

Disadvantages of RBAC:

Complex Role Design: Defining and maintaining roles can be challenging in dynamic environments.
Role Explosion: Over time, too many roles might be created, complicating management.

Ideal Use Cases:

Organizations with well-defined roles and responsibilities.
Scenarios requiring clear separation of duties and regulatory compliance.
Systems where scalability and streamlined access control are priorities.

RBAC is widely used in enterprise systems like databases, cloud platforms, and application servers to enforce structured and secure access control

2. RuBAC

Rule-Based Access Control is an access control model where access decisions are made based on predefined rules or policies. These rules determine whether access should be granted or denied based on specific conditions. Unlike RBAC, RuBAC does not rely on roles but focuses on rules applied to users, actions, resources, and environments.

Rules Considered in the Hospital System:

Rule Format: Each rule specifies the condition for granting or denying access.
Example Rule:
- IF (User Role = "Doctor" AND Resource = "Patient Record" AND Action = "View") THEN Allow Access.
Example Access Rules:
1. Doctors can view and modify patient records only during working hours (8 AM–6 PM).
- Rule:
  - IF (User Role = "Doctor" AND Action = "View" OR "Modify" AND Resource Type = "Patient Record" AND Time = "8 AM–6 PM") THEN Allow Access.
1. Nurses can view patient records but cannot prescribe medication.
- Rule:
  - IF (User Role = "Nurse" AND Action = "View" AND Resource Type = "Patient Record") THEN Allow Access.
  - IF (User Role = "Nurse" AND Action = "Prescribe") THEN Deny Access.
1. Pharmacists can dispense medication only for approved prescriptions.
- Rule:
  - IF (User Role = "Pharmacist" AND Action = "Dispense" AND Prescription Status = "Approved") THEN Allow Access.
1. Administrators can manage staff information but cannot access patient records.
- Rule:
  - IF (User Role = "Administrator" AND Resource Type = "Staff Record" AND Action = "Manage") THEN Allow Access.
  - IF (User Role = "Administrator" AND Resource Type = "Patient Record") THEN Deny Access.
1. Emergency Rule: During emergencies, all healthcare staff can access patient records without restrictions.
- Rule:
  - IF (Emergency = "True" AND Action = "View" AND Resource Type = "Patient Record") THEN Allow Access.

Example Scenarios:

Dr. Smith (Doctor):
- Can modify patient records at 2 PM.
- Cannot access records after 6 PM unless it's an emergency.
Nurse Kelly:
- Can view patient records of any patient during working hours.
- Cannot prescribe medication under any condition.
Pharmacist John:
- Can dispense medication only if there is an approved prescription in the system.
Admin Jane:
- Can modify staff details but is explicitly denied access to patient records.

Key Features of RuBAC:

Centralized Rules: Access is determined by system-defined rules, not individual discretion or assigned roles.
Policy-Driven: Rules define all conditions for granting or denying access.
Dynamic Decision Making: Rules can incorporate contextual information like time, location, or emergency status.

Benefits of RuBAC:

Consistency: Access is strictly governed by predefined rules, reducing human error or misconfiguration.

Flexibility: New rules can be added or modified without changing user assignments or roles.

Strong Security: Explicit deny rules can minimize the risk of unauthorized access.

When to Use RuBAC:

RuBAC is ideal in environments where precise, predefined policies are critical, such as:

Hospital Systems (e.g., access to sensitive patient data).
Financial institutions (e.g., controlling transactions).
Industrial systems (e.g., regulating machine access).

3. ABAC

Attribute-Based Access Control is an access control model that grants or denies access to resources based on attributes associated with users, resources, environments, or actions. Unlike Role-Based Access Control (RBAC), which relies on predefined roles, ABAC provides a more flexible and fine-grained approach by using attributes to determine access rights dynamically.

Key Concepts of ABAC

Attributes:
- User Attributes: Characteristics of the user, such as their job title, department, location, clearance level, or role.
- Resource Attributes: Properties of the resource, like data classification (e.g., confidential, public), owner, or creation date.
- Environment Attributes: Contextual factors like the time of day, location of the request, or device used.
- Action Attributes: The specific action being attempted, such as reading, writing, deleting, or modifying a resource.
Policies:
- ABAC policies are rules that define access control decisions based on a combination of attributes. Policies are often written in a formal language, like XACML (eXtensible Access Control Markup Language), and they dictate how attributes should be evaluated to allow or deny access.
Policy Enforcement Point (PEP):
- The component that intercepts a user's access request, gathers the relevant attributes, and enforces the decision based on the policies.
Policy Decision Point (PDP):
- The component that evaluates the access request against the policies and attributes, making the decision to allow or deny access.
Policy Information Point (PIP):
- The source of attributes, providing the necessary information about users, resources, environment, or actions to the PDP for decision-making.
- Access decisions are made based on attributes of the user, resource, or environment (e.g., time of access, user's department).
- Policies are centrally defined to evaluate attributes dynamically.
- Example: A user in the HR department can access payroll data only during working hours.

How ABAC Works

Access Request: A user attempts to access a resource, triggering an access request.
Attribute Collection: The system collects relevant attributes about the user, resource, environment, and action involved in the request.
Policy Evaluation: The PDP evaluates the request against defined policies, considering all attributes involved. For example, "If the user's clearance level is 'Top Secret' and the resource is classified as 'Confidential,' allow access."
Decision Enforcement: Based on the policy evaluation, the PEP enforces the decision, either granting or denying access to the resource.

This diagram shows the key components of an ABAC (Attribute-Based Access Control) system and how they interact. Let’s break it down step by step:

Policy Administration Point (PAP):
- Role in ABAC
  - The PAP is responsible for creating, managing, and storing policies that define access control rules.
- In Context:
  - An administrator defines access policies, such as:
  - Doctors can access patient records during working hours.These policies are stored in the Policy Repository and deployed to the PDP for execution.
Policy Repository:
- Role in ABAC
  - A storage location for access control policies.
- In Context:
  - The policy created by the administrator is stored here and deployed to the PDP for evaluation during access requests.
Policy Enforcement Point (PEP):
- Role in ABAC
  - The PEP is the gatekeeper that enforces access control decisions. It intercepts user requests and sends them to the PDP for evaluation.
- In Context:
  - Dr. Smith (the user) tries to access a patient’s record via the Application. The PEP intercepts this request and forwards it to the PDP.
Policy Decision Point (PDP):
- Role in ABAC
  - The PDP evaluates the access request against the policies deployed by the PAP. It retrieves attributes via the PIP to make a decision: allow or deny.
- In Context:
  - The PDP checks:
    - Dr. Smith’s role (Doctor).
    - The resource’s sensitivity (Patient Record).
    - The time of access (2 PM).
    - The location of access (Hospital Premises).
    - Based on these attributes and the policies, the PDP sends a decision to the PEP.
Policy Information Point (PIP):
- Role in ABAC
  - The PIP provides descriptive attributes about the user, resource, action, and environment to the PDP.
- In Context:
  - The PIP fetches:
    - Dr. Smith’s attributes (e.g., Role = Doctor, Department = Cardiology).
    - Resource attributes (e.g., Sensitivity = Confidential).
    - Environmental attributes (e.g., Time = 2 PM, Location = Hospital).
    - This data helps the PDP evaluate the access request.
Attribute Store:
- Role in ABAC
  - A database or repository that holds the attributes required for policy evaluation.
- In Context:
  - The PIP retrieves attributes like:
    - User details from the HR database.
    - Resource details from the hospital’s data system.
    - Environment details from a time/location service.

Real-World Scenario Example

Imagine an online banking system
- PEP: When you log into your online banking account, the PEP is the login page that collects your username, password, and possibly a two-factor authentication code. It sends this information to the PDP.
- PDP: The PDP is the backend system that checks whether your login credentials are correct and if you’re allowed to access your account at that moment.
- PIP: The PIP in this scenario would be where your account details, login history, and security settings are stored. This information helps the PDP decide if your login attempt is legitimate or not.

This flow ensures fine-grained, dynamic, and context-aware access control using ABAC principles.

Ideal use case of ABAC

Financial Institutions
- Bank employees need access to customer data or transactions based on specific criteria:
- Loan officers can access financial records for customers assigned to them.
- Customer support agents can view account information but cannot modify it.
- High-value transaction approvals require multi-factor authorization and senior-level clearance.

ABAC can dynamically enforce access control policies based on attributes like transaction value, user role, clearance level, and action type.

Cloud Computing and Multi-Tenant Systems
- cloud platforms (e.g., AWS, Azure), access control must support:
- Users from different organizations (multi-tenancy).
- Context-aware policies like allowing access only from approved devices or IP ranges.
- Granular permissions based on resource type, user department, and compliance needs.

ABAC enables dynamic, attribute-driven access to resources in highly distributed and scalable environments.

Government and Defense Systems
- Sensitive government data needs strict access control based on:
- Security clearance level (e.g., Confidential, Secret, Top Secret).
- Citizenship and location of the user.
- Time-bound access for specific projects or missions.

ABAC enforces complex policies using attributes like clearance level, citizenship, time, and project assignment.

Remote Work and BYOD (Bring Your Own Device) Policies
- Organizations need to ensure secure access for employees working remotely:
  - Allow access to sensitive data only from managed devices.
  - Restrict access to non-critical systems if accessing from an untrusted network or location.
  - Implement stricter controls for high-risk countries.

ABAC evaluates device type, network trust level, location, and time to dynamically enforce access policies.

Why ABAC Stands Out:

Dynamic Decisions: Access control adapts to changes in user attributes, resources, and environment.
Granularity: ABAC allows precise control over who can do what, when, where, and how.
Scalability: No need to predefine roles for every scenario; attributes drive decision-making.

4. MAC

Mandatory Access Control is an access control model in which access to resources is regulated by a central authority based on predefined security policies.The users or resource owners have no ability to alter the access control rules. MAC is often used in environments where strict control over data access is required, such as military or government systems.

Under MAC, access decisions are based on the classification or labels assigned to resources and users, and the policies are centrally managed by the system.

Key Features of MAC

Centralized Control : Access is determined and enforced by a central authority or policy, not by resource owners.
Security Labels: Every resource (e.g., file, document) and user is assigned a security label (e.g., "Top Secret," "Confidential," "Public").
Access Levels: Access is granted based on the user's security clearance and the classification of the resource.
Non-Discretionary: Users cannot modify access permissions or delegate access to others.
Strict Enforcement :Policies are enforced consistently, with no exceptions or overrides by users.

How MAC Works

Labels Assignment:
- Users and resources are assigned security labels. For example:
- User A: Clearance = "Secret"
- File X: Classification = "Confidential"
Policy Evaluation:
- Access is granted only if the user's clearance level meets or exceeds the resource's classification.
- For example:
  - User A (Clearance = "Secret") can access File X (Classification = "Confidential") because "Secret" is higher than "Confidential."
Rules Enforcement:
- Centralized policies enforce rules like "No user with 'Public' clearance can access 'Confidential' resources."

Example of MAC in Action:

Scenario: Military Document Access System

User Assignments:
- User A: Clearance = "Top Secret"
- User B: Clearance = "Confidential"
Resource Assignments:
- Document X: Classification = "Top Secret"
- Document Y: Classification = "Confidential"
Access Control:
- User A: Can access both Document X and Document Y (Top Secret clearance is higher than Confidential).
- User B: Can access only Document Y (Confidential clearance matches Document Y's classification).

Advantages of MAC:

High Security: Ensures strict control over access, reducing risks of data breaches or unauthorized access.

Regulatory Compliance: Meets stringent requirements for environments like defense, finance, or healthcare.

Consistency: Policies are centrally defined and uniformly applied.

Use Cases for MAC

Government and Military Systems: Enforcing strict access to classified information (e.g., "Top Secret" or "Confidential").

Healthcare: Restricting access to patient data based on regulations like HIPAA.

Financial Systems: Protecting sensitive customer data from unauthorized access.

While MAC provides robust security, its inflexibility and administrative complexity make it less suitable for dynamic or collaborative environments. For organizations requiring finer-grained, context-aware, or more flexible access control, models like ABAC or RBAC may be more appropriate.

Refs

strongdm