Role Based Access Control (RBAC)

Role Based Access Control (RBAC)

Role Based Access Control (RBAC) is a method for setting up authorization management within your organisation. Here, you assign authorizations not on an individual basis, but based on RBAC roles. These roles are made up of department, job function, location, and cost centre of an employee within your organisation. On this page of our knowledge base, you can read all about RBAC, RBAC roles, and assigning rights based on these roles.

Within Identity & Access Management (IAM), RBAC can play an important role. By assigning rights based on RBAC roles, you can define the rights that certain groups of users receive in one go. This saves a lot of time, avoids the need to assign authorizations to individual users, and counteracts human errors in this process. The various RBAC roles are generally recorded in an RBAC table.

RBAC Model

What’s handy about RBAC is the use of RBAC roles. These allow you to define all necessary rights for a certain group of users at once. For example, take an employee active within your organisation’s finance team. For performing their work, this employee needs access to the CRM, ERP, and order systems, among various other data sources. With RBAC, you establish that every employee active in your finance department automatically gets assigned the necessary rights for this.

This method saves you a lot of time. You do not need to assign rights to individual users and you can be sure that all users have the rights they need to perform their work. However, the opposite is also true. If a finance employee leaves for another company or takes on a different role within your organisation, RBAC automatically adjusts the user’s authorizations to his or her new function.

In an IAM solution like HelloID, you record these authorizations in business rules. Conveniently, once configured, the RBAC process is fully automated through this. The IAM solution assigns the correct rights based on your business rules depending on the role assigned to a specific user.

The Advantages and Disadvantages of RBAC

Advantages

• Simplifying access rights: With RBAC, you can significantly simplify the management of access rights. You assign rights based on roles instead of individual users. This not only saves time but also reduces the chance of human errors.
• Compliance with laws and regulations: With RBAC, you organize your authorizations in a structured, standardized, and transparent manner. Important, among other things, with a view to compliance with laws and regulations such as the General Data Protection Regulation (GDPR). With RBAC, you can easily demonstrate that sensitive data is only accessible to authorized employees.

Disadvantages

• Complexity: The implementation of RBAC can be relatively complex. Among other things, because you must define all the roles present within your organisation and the associated responsibilities before you can start with RBAC. This process can be simplified with the help of role mining, a technique that analyzes the existing authorizations of employees and thus comes up with roles.
• Role explosion: You may face a ‘role explosion’. The number of roles within your organisation increases explosively. This risks shifting the management burden from individual users to a proliferation of roles. The administrative burden shifts thereby, but does not necessarily decrease. Therefore, we always advise the use of service automation for assigning, among other things, temporary rights to users.

RBAC vs ABAC

A method that closely resembles RBAC is Attribute Based Access Control (ABAC). The main difference between the two methods is how authorizations are granted. In RBAC, you grant authorizations based on roles. These roles are based on department, location, job level, and work-related tasks.

In ABAC, on the other hand, you grant authorizations based on user attributes, object attributes, and types of actions performed. For instance, you can assign rights based on the user, looking specifically at job title, average tasks, or job level to determine the type of work a user performs. Consider also attributes of objects users try to access. It can include the type of file, the person who created a file, or the sensitivity of a file. The moment a user tries to access a file, such as the date and/or time, can also be decisive in ABAC for granting rights.

RBAC and ABAC in Practice

An example is a healthcare institution where you want to give doctors access to patient data. Using RBAC? Then you can give access to all patient data based on the doctor’s role. Or, for example, grant access to all patient data linked to that specific location depending on a location. You base yourself here also to a significant extent on static data.

Using ABAC? Then you can use multiple attributes, which can be dynamic. This means, for example, that you can give doctors access to patient data of patients with whom they have a direct doctor-patient relationship according to the scheduling system. ABAC thus allows authorizations to be more precisely tailored to the actual needs of users and offers more flexibility than RBAC in that respect.

Role Engineering: Top-Down or Bottom-Up

If you want to get started with RBAC, you start by establishing the roles present within your organisations. You can choose between two approaches: top-down and bottom-up. With top-down, you start this process with the functions within your organisation, while with bottom-up, you start with user data. Both approaches have their own advantages. We outline the differences.

Top-down

With top-down role engineering, you focus on the existing users and the functions they fulfil. You map their actions accurately, identifying which applications they use a lot and which they do not. There are various possibilities for carrying out this analysis. For example, you can monitor an employee for a day and record which applications they use. However, you could also choose to interview managers of specific departments and have them map out which applications their team members need. Consider also involving system owners, who can precisely set out which functions should never use a specific application.

Regardless of the type of top-down analysis you choose, you thereby identify which applications an employee actually uses or should use. This gives you the opportunity, for example, to revoke authorizations that have been unnecessarily granted. Important if you adhere to a least privilege policy.

Bottom-up

In addition to a top-down approach, you can also choose a bottom-up analysis. Here, you do not look so much at the functions of users but search for relationships between granted rights and specific functions. For example, if all employees of the finance department have access to the CRM and order system? Then this pattern could indicate that this function always needs access to these systems.

Various tools are available to help you perform a bottom-up analysis. An important consideration here is the quality of your data: the cleaner your data, the more accurate a bottom-up analysis is. Conversely, however, contamination in your data related to authorizations can lead to erroneous conclusions and affect the quality of your bottom-up analysis.

Role Mining

Another interesting option is role mining, a method that combines the best of top-down and bottom-up role engineering. The process consists of several steps:

• Inventorying existing roles.
• Mapping existing rights(groups).
• Designing your RBAC concept.
• Evaluating the concept with stakeholders such as department managers.
• Establishing your first baseline version of the role model based on the results from the above steps.

Role Based Access Control with HelloID

HelloID is an IAM solution that significantly assists with RBAC. HelloID acts as a mediator between your source system such as an HR system and target systems like Active Directory (AD), Azure AD, or Google Workspace.

Both for RBAC and ABAC, HelloID offers extensive support. Thus, the IAM solution offers you the best of both worlds. The role mining process at HelloID consists of the following steps:

• Inventorying the roles.
• Mapping existing rights(groups).
• Designing an RBAC concept.
• An evaluation of the concept with stakeholders, including department managers.

These steps lead to a first baseline version of the role model, which you can apply operationally. You can then expand this model, regularly renew and update it based on new insights.

HelloID guides you step by step through the role mining process. So you can easily and without worries get started with RBAC and thus elevate the digital security of your organisation to a higher level. Curious about how HelloID can assist you in this process? Then read our blog post on the use of smart role mining, where we delve deeper into this method. Want to experience the possibilities yourself in practice? Then book a demo now!

HelloID Software HelloID Whitepaper