Cookies
Close Cookie Preference Manager
Cookie Settings
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts. More info
Strictly Necessary (Always Active)
Cookies required to enable basic website functionality.
Made by Flinch 77
Oops! Something went wrong while submitting the form.

The evolution of access control mechanisms - From ACL to PBAC

In today’s digital age, where data and information reign, securing data and protecting sensitive resources has become a top priority for organizations across all industries. Access control, the bedrock of security measures, serves as the gatekeeper to safeguarding our digital assets from unauthorized intrusions. As businesses handle a vast amount of sensitive information, implementing a robust access control mechanism is crucial to ensure data privacy and prevent unauthorized access.

In today’s digital age, where data and information reign, securing data and protecting sensitive resources has become a top priority for organizations across all industries. Access control, the bedrock of security measures, serves as the gatekeeper to safeguarding our digital assets from unauthorized intrusions. As businesses handle a vast amount of sensitive information, implementing a robust access control mechanism is crucial to ensure data privacy and prevent unauthorized access.

With each technological advancement, from the advent of personal computers to the birth of the internet and beyond, access control measures evolved to meet the challenges of a rapidly changing digital landscape. Join us as we explore the evolution of access controls from simple access control lists to cutting-edge policy-based access paradigms.

Access Control List

Access Control Lists are probably the most simple access control mechanism. An Access Control List is a list of rules or permissions that determines what actions or operations are allowed or denied for a specific user or group of users. In an ACL, each entry defines a combination of a subject (user or group) and an associated set of permissions. These permissions can include actions like read or write or other specific operations depending on the type of data source being protected.

ACLs are widely used. Azure Data Lake Storage Gen 2 uses ACLs and also the nameless bindings which Google Cloud Platform uses can be considered as the most basic example of an access control list: it assigns one permissions to one resource to one or more users. To allow a user to read from a BigQuery table called ‘employees’ for example he needs to be assigned to employees.dataviewer.

Nameless binding in BigQuery, an example of an access control list

As ACL is a simple access control mechanism that grants or denies access permissions to individual users or groups to specific data, it is a good mechanism to start with in a relatively small and straightforward system. While ACLs are easy to implement, they lack context-awareness and may not adequately address evolving access requirements in complex and fast-paced environments. In short: they lack great auditability and are a nightmare with regards to maintainability and scalability.

Role-Based Access Controls

Role-Based Access Control (RBAC) is an access control mechanism that simplifies and enhances security management. RBAC is designed to manage user access based on their roles or job functions within an organization, rather than defining permissions for individual users.

For example, an employee in the HR department might be assigned the “HR manager” role, granting them, amongst others, read permissions to the employees table in your data warehouse. Each role is associated with specific permissions that define what actions users in that role are allowed to perform. For instance, the “HR manager” will have access to employee data, but not to financial records.

Assignment of read permissions through RBAC

RBAC allows for hierarchical role structures. Roles can inherit permissions from other roles, making it easier to manage and maintain access controls. Such inheritance will reflect the job function structure of the company. For example, a “Supervisor” role might inherit permissions from both “Employee” and “Manager” roles.

Role inheritance

RBAC simplifies access control administration and makes it easier to manage access permissions in larger organizations. Access changes can be managed by simply modifying a user’s role rather than adjusting individual permissions for each user.

On the other hand, it still does not provide any context to the data access rather than the role a certain user has. Even though the goal of RBAC is to allow least-privilege access, in practice, far too often, users build up large amounts of permissions as they get rapidly assigned to an overprovisioned role to grant them a single permission or as clean-ups don’t take place when people switch roles.

Still RBAC is a good way to scale when your organization becomes larger and access requirements become more complex. Certainly when the number of roles within your organizations still remains manageable.

Attribute-Based Access Controls

An Attribute-Based Access Control (ABAC) is a highly dynamic access control which evaluates attributes belonging to the user and those belonging to your data to determine the permissions that you have.

Often ABAC policies are considered as a synonym for masking policies like “mask all PII data”, which is not entirely true. Even though an ABAC policy can be used for this, it can also dynamically grant access. For instance, it can be used to grant an HR manager access to HR management data, and a sales manager to sales management data with a single access control.

 

Multiple RBAC roles can be replaced by 1 ABAC policy based on qualitative metadata

ABAC is the most flexible and dynamic access management mechanism and when well-implemented it is by far easiest to maintain.  However, it requires qualitative metadata to base your ABAC policies upon. Therefore, not many organizations are ready to fully implement the ABAC mechanism.

Purpose-Based Access Controls

Purpose-based access control or PBAC is a type of access control mechanism that focuses on granting permissions to users based on the specific purposes or reasons for which they need access to certain data.

Purpose role granting read permissions to a table

As data access is aligned with the intended use, PBAC ensures that users have access to data they genuinely need for their specific tasks. PBAC is a powerful approach to prevent unauthorized access to sensitive information. This approach can lead to better security, privacy and compliance with data regulations.

Combining Access Control mechanisms

In practice, different access control mechanisms can be combined or used in conjunction with each other. For instance, attribute-based access control can complement RBAC or PBAC by providing more flexibility in defining policies based on attributes.

When for example data owners would tag their data with the purposes it can be used for, one can define a purpose based access control by defining an Attribute-Based Access Control. Doing the same for users will often push the boundaries of your identity store. You could instead create a purpose role and assign it to users as you would do within RBAC.

A combination of an ABAC and RBAC policy to construct a PBAC access control

How Raito helps

Raito supports its customers in setting up all these different access control mechanisms. It allows its customers to manage ACL, RBAC, ABAC and PBAC, where we of course try to guide you to a preferable maturity level.

Raito introduces the concept of an access control, which manages the link between who and what. Customers can specify individual users or groups and their corresponding permissions for specific data objects as you do within ACL. Raito ensures precise control over data access and offers its customers the ability to easily review and modify existing access controls to adapt to changing requirements.

A Raito access control - the link between who can do what

These access controls are actually more close to role-based access controls. What actually happens is that you assign permissions to the access control and then assign these roles to users. By doing so, customers can efficiently manage access rights based on job functions or responsibilities. Raito empowers customers to define and update roles easily, ensuring that users automatically inherit permissions on their assigned roles, reducing the complexity of access management.

Raito collects metadata from the data sources or identity stores it integrates with. This metadata can then be used as attributes to define dynamic policies in Raito. Raito also empowers customers to adopt a policy-based approach to access control, which involves defining high-level policies that dictate access decisions. Customers can create and manage complex access rules using Raito’s intuitive policy editor.

When creating a new access control, the purpose is the first thing Raito prompts for. This allows you to create purpose access controls, which can be managed by a purpose owner (access control owner in Raito) to offload your data team or data owners.

Raito first prompts for the purpose of a new access control

Overall, Raito stands as a robust data access management tool that caters to diverse access control requirements. It offers a user-friendly interface, supports different access control models and allows you to configure and manage these efficiently. By leveraging Raito’s capabilities, organizations can enhance their data security, achieve compliance, and ensure data accessibility in a controlled and auditable manner. And… you can start today!