130 lines
7.3 KiB
Markdown
130 lines
7.3 KiB
Markdown
See also:
|
||
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
|
||
- [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
|
||
- [RBAC Access levels](../Literature%20notes/RBAC%20Access%20levels.md)
|
||
- [CRUD Matrices](CRUD%20Matrices.md)
|
||
|
||
|
||
Source: [](../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
|
||
|
||
- Mandatory Access Control (MAC):
|
||
- Every object gets a label
|
||
- Confidential, secret, top secret, etc
|
||
- The administrator decides who gets access to what security level;
|
||
- Users cannot change these settings
|
||
- Used on old systems (e.g. Top Secret Gov. information)
|
||
|
||
- Discretionary Access Control (DAC):
|
||
- Used in most OS
|
||
- Owner of the data defines access
|
||
- Very flexible access control; Very weak security
|
||
|
||
- Role-based Access Control (RBAC):
|
||
- Access to resources is defines by a set of rules defined by a role in your organization/job function (Manager, Director etc)
|
||
- e.g., "Administrators can read, write, and delete all files," "Employees can only read certain files."
|
||
- Administrators provide access based on the role of the user
|
||
- Rights are gained implicitly instead of explicitly
|
||
- In Windows, use Groups to provide role-based access control
|
||
- e.g. Admin Groups --> Rights and Perms,
|
||
- Sales Group --> Rights and Perms
|
||
|
||
Also found, with Gemini, 2 juni 2025:
|
||
- Attribute-Based Access Control (ABAC):
|
||
- e.g., "Only users from the 'Finance' department located in 'Head Office' can access this financial report."
|
||
- Relationship-Based Access Control (ReBAC)
|
||
- e.g., "Friends can view my photos."
|
||
|
||
|
||
## Mandatory vs. Discretionary access control
|
||
Source: Wikipedia, dec. 2024
|
||
|
||
In mandatory access control (MAC), the security policy is centrally controlled by a policy administrator and is guaranteed (in principle) to be enforced for all users. Users cannot override the policy and, for example, grant access to files that would otherwise be restricted.
|
||
|
||
By contrast, discretionary access control (DAC) allows users the ability to make policy decisions or assign security attributes. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).
|
||
|
||
Systems can implement both MAC and DAC simultaneously, where DAC refers to one category of access controls that subjects can transfer among each other, and MAC refers to a second category of access controls that imposes constraints upon the first.
|
||
|
||
Occasionally, a system as a whole is said to have "discretionary" or "purely discretionary" access control when that system lacks mandatory access control.
|
||
|
||
## Different access control models
|
||
|
||
Access control models govern how users are granted access to resources in a system. This document compares **RBAC (Role-Based Access Control)**, **ABAC (Attribute-Based Access Control)**, **NGAC (Next-Generation Access Control)**, and **PBAC (Policy-Based Access Control)**, outlining their differences, advantages, and disadvantages.
|
||
|
||
### RBAC (Role-Based Access Control)
|
||
|
||
- **Definition**: Access is granted based on roles assigned to users. A role represents a set of permissions, and users inherit permissions from their assigned roles. RBAC is policy-neutral in the sense that it can be used to implement MAC or DAC.
|
||
- **Key Components**: Users, roles, and permissions.
|
||
|
||
**Pros:**
|
||
- Simple and intuitive to implement for organizations with clear hierarchical structures.
|
||
- Reduces administrative overhead when managing permissions.
|
||
- Well-suited for stable environments with predictable access needs.
|
||
|
||
**Cons:**
|
||
- Lacks flexibility; difficult to handle exceptions or dynamic contexts (e.g., time-based restrictions).
|
||
- Role explosion: Managing a large number of roles becomes cumbersome as the system scales.
|
||
- Not context-aware.
|
||
|
||
### ABAC (Attribute-Based Access Control)
|
||
|
||
- **Definition**: Access is granted based on attributes of users, resources, actions, and the environment. Attributes can include user roles, resource sensitivity, location, time, and more.
|
||
- **Key Components**: Policies, attributes, and conditions.
|
||
|
||
**Pros:**
|
||
- Highly flexible and fine-grained access control.
|
||
- Supports dynamic, context-aware decisions (e.g., granting access only during work hours or from specific locations).
|
||
- Eliminates role explosion.
|
||
|
||
**Cons:
|
||
- Complex to implement and manage due to the need for a robust attribute infrastructure.
|
||
- Policy authoring can be error-prone and challenging for administrators.
|
||
- Requires real-time evaluation, which may impact performance.
|
||
|
||
### NGAC (Next-Generation Access Control)
|
||
|
||
- **Definition**: A standards-based approach that integrates various access control concepts, combining RBAC, ABAC, and policy-based models. It uses a graph-based structure to represent relationships between users, attributes, and policies.
|
||
- **Key Components**: Graphs (users, attributes, and policies) and decision engines.
|
||
|
||
**Pros:**
|
||
- Flexible and adaptable to different access control needs.
|
||
- Unified framework for managing diverse access control models.
|
||
- Highly efficient for environments requiring a mix of models.
|
||
|
||
**Cons:
|
||
- Complexity in setup and management.
|
||
- Limited adoption and tooling support compared to RBAC or ABAC.
|
||
|
||
### PBAC (Policy-Based Access Control)
|
||
|
||
- **Definition**: Access is managed through explicitly defined policies that dictate who can access what under which conditions. Often overlaps with ABAC.
|
||
- **Key Components**: Policies, rules, and conditions.
|
||
|
||
**Pros:**
|
||
- Fine-grained control with a focus on clear, centralized policy definition.
|
||
- Scalable for distributed systems or multi-tenant architectures.
|
||
- Strongly aligned with regulatory compliance requirements.
|
||
|
||
**Cons:
|
||
- Similar to ABAC, policy complexity can grow quickly.
|
||
- Administrators require expertise to define and maintain accurate policies.
|
||
- Performance overhead due to policy evaluation.
|
||
|
||
## Summary Comparison
|
||
|
||
| Feature / Model | RBAC | ABAC | NGAC | PBAC |
|
||
| -------------------------- | ------------------------- | --------------- | ----------- | -------------- |
|
||
| **Flexibility** | Low | High | High | High |
|
||
| **Complexity** | Low | High | Moderate | Moderate |
|
||
| **Context-Awareness** | No | Yes | Yes | Yes |
|
||
| **Scalability** | Limited (role explosion) | High | High | High |
|
||
| **Ease of Implementation** | Easy | Difficult | Moderate | Moderate |
|
||
| **Adoption** | Widespread | Increasing | Emerging | Increasing |
|
||
|
||
## Choosing the Right Model
|
||
|
||
- Use **RBAC** for environments with stable, well-defined roles and minimal need for contextual decisions.
|
||
- Use **ABAC** or **PBAC** for systems requiring dynamic, context-aware, and fine-grained access control.
|
||
- Consider **NGAC** if a unified, standards-based approach is necessary and you need to integrate multiple models.
|
||
|
||
The decision depends on your organization's complexity, security needs, and resource availability.
|
||
|