Companies and or­ga­ni­za­tions only assign access per­mis­sions in their IT systems to users who actually need them to carry out their ac­tiv­i­ties. This protects sensitive data from unau­tho­rized access and mod­i­fi­ca­tion. To ensure that security is main­tained in large or­ga­ni­za­tions, in­di­vid­ual access per­mis­sions are defined in an access-control list (ACL). This does have a dis­ad­van­tage. The larger the number of users, the more high main­te­nance and error prone the as­sign­ment of in­di­vid­ual per­mis­sions will be. A flexible yet efficient al­ter­na­tive for handling this is role-based access control (RBAC).

What is RBAC?

Role-based access control (RBAC) is an approach to handling security and per­mis­sions in which roles and per­mis­sions are assigned within an or­ga­ni­za­tion’s IT in­fra­struc­ture. The key term here is “role-based”. This is what dis­tin­guish­es RBAC from other security ap­proach­es, such as mandatory access control. In this model, a system ad­min­is­tra­tor assigns a security level and category to each user and object. The operating system au­to­mat­i­cal­ly compares the two levels and then either grants or denies access.

In RBAC, access per­mis­sions are assigned based on a defined role model. Defined user roles represent the work processes in an or­ga­ni­za­tion and vary from company to company. To ef­fec­tive­ly break down user roles, you could do this by de­part­ment, location, cost center or employee re­spon­si­bil­i­ties.

How role-based access control works

Before RBAC can be im­ple­ment­ed in a company, the per­mis­sions for each role have to be defined as thor­ough­ly as possible. This involves precisely defining the per­mis­sions for the following areas:

  • Mod­i­fi­ca­tion per­mis­sions for data (e.g. read, read and write, full access)
  • Access per­mis­sions for company ap­pli­ca­tions
  • Per­mis­sions within the ap­pli­ca­tions

To fully benefit from the ad­van­tages of the RBAC model, the first step is always to establish a model for the roles and per­mis­sions. This involves the or­ga­ni­za­tion assigning all employee re­spon­si­bil­i­ties to specific roles which determine the cor­re­spond­ing access per­mis­sions. Then, the roles are assigned to employees according to their re­spon­si­bil­i­ties. Role-based access control allows you to assign one or more roles per user. This also lets you in­di­vid­u­al­ly assign access per­mis­sions with the role model. The goal of this is to ensure that the access per­mis­sions allow the users to perform their ac­tiv­i­ties without having to make any ad­di­tion­al mod­i­fi­ca­tions.

RBAC is im­ple­ment­ed and monitored by an identity access man­age­ment system (IAM). This system primarily supports companies with a large number of employees in recording, mon­i­tor­ing, and updating all iden­ti­ties and access per­mis­sions. Assigning per­mis­sions is called “pro­vi­sion­ing”, and removing per­mis­sions is called “de-pro­vi­sion­ing”. In order to use this kind of system, a uniform stan­dard­ized role model must be es­tab­lished.

Tip

Self-service portals allow users to modify their per­mis­sions them­selves. When a change is made, the system au­to­mat­i­cal­ly alerts the ad­min­is­tra­tors. They can then im­me­di­ate­ly reverse the changes if need be.

How do you create an RBAC?

Role-based access control is based on a three-level structure con­sist­ing of users, roles and groups. In role mining, or­ga­ni­za­tions define roles which are usually based on the or­ga­ni­za­tion­al structure of the company. Each employee is then assigned one or more roles which in turn consist of one or more access per­mis­sions. One or more groups are also assigned to a role, which are not nec­es­sar­i­ly the same.

In most cases, the pyramid approach is suitable when creating the role model:

The top level: per­mis­sions for all employees

At the top level, you will find the per­mis­sions required by all employees in the or­ga­ni­za­tion. These typically include access to the intranet, Office suite, email client, shared network directory, and login access via Active Directory.

The second level: de­part­ments

In an or­ga­ni­za­tion, employees working in the same de­part­ment carry out similar ac­tiv­i­ties. For example, the finance de­part­ment needs access to the ERP system and the de­part­ment drive, while the HR de­part­ment needs access to all employee data. The cor­re­spond­ing per­mis­sions are assigned to all employees within a de­part­ment.

The third level: re­spon­si­bil­i­ties

Ad­di­tion­al per­mis­sions are defined based on the employees’ re­spon­si­bil­i­ties and cor­re­spond­ing tasks.

Tip

Team leaders know their employees’ tasks best. It is, therefore, rec­om­mend­ed to include them in the process of defining roles. By using an IAM system, per­mis­sions can au­to­mat­i­cal­ly be requested and confirmed with the de­part­ment heads.

The bottom level: roles

In many cases, employees must perform ac­tiv­i­ties that were not pre­vi­ous­ly covered by the role request for their de­part­ment and re­spon­si­bil­i­ties. Therefore, the or­ga­ni­za­tion will ul­ti­mate­ly assign each employee ad­di­tion­al roles that they need for their actual tasks.

Data sources for RBAC

To define and assign roles, the employee data of an or­ga­ni­za­tion needs to be complete and up to date. Detailed records of this data are logged in the HR system, primarily in larger companies. When creating a model for the roles and per­mis­sions, it is also rec­om­mend­ed to in­cor­po­rate roles that may not be filled at the moment. These roles typically include interns in a de­part­ment or positions that have not been filled for a long time.

Ad­van­tages and dis­ad­van­tages of RBAC

In some cases, role-based access control has been accepted as the best-practice model. If the model for the roles and per­mis­sions has been defined and has been im­ple­ment­ed and enforced through­out the company, RBAC can offer numerous ad­van­tages:

  • Flex­i­bil­i­ty: The company only assigns roles to an employee as required. Any mod­i­fi­ca­tions to the or­ga­ni­za­tion­al structure or per­mis­sions are quickly applied to all employees when the company modifies the cor­re­spond­ing role.
  • Reduced ad­min­is­tra­tion work: RBAC has rendered the time-consuming process of in­di­vid­u­al­ly assigning per­mis­sions obsolete.
  • Less error prone: Assigning per­mis­sions in­di­vid­u­al­ly is a more complex process and is thus more error prone than using role-based access control for assigning per­mis­sions.
  • Increased ef­fi­cien­cy: Reducing the amount of work and error rate increases the ef­fi­cien­cy of IT and other employees. There is no longer any need for manual mod­i­fi­ca­tions, error handling, wait times or in­di­vid­ual per­mis­sion requests.
  • Security: Access per­mis­sions are defined ex­clu­sive­ly via the role model which prevents you from giving more per­mis­sions than needed to in­di­vid­ual employees. This is in line with the Principle of Least Privilege (PoLP).
  • Trans­paren­cy: The naming of roles is usually straight­for­ward and thus increases trans­paren­cy and com­pre­hen­si­bil­i­ty for users.

Role-based access control also has some dis­ad­van­tages:

  • Labor-intensive setup: Trans­lat­ing or­ga­ni­za­tion­al struc­tures into the RBAC model requires a lot of work.
  • Temporary as­sign­ments: If a user only needs extended access per­mis­sions tem­porar­i­ly, it is easier to forget about them when using RBAC than when assigning per­mis­sions in­di­vid­u­al­ly.
  • Ap­pli­ca­tion: In small companies, creating and main­tain­ing roles would be more labor intensive than assigning per­mis­sions in­di­vid­u­al­ly. Therefore, the RBAC model is only used when a certain number of roles and employees has been reached. However, even in large companies, role-based access control suffers from the drawback that it is easy to end up creating a large number of roles. If a company has ten de­part­ments and ten roles, this will already result in 100 different groups.

When is RBAC used?

In many or­ga­ni­za­tions, role-based access control has been accepted as the best method for managing access per­mis­sions. In addition, the RBAC model is also used in operating systems and other software, such as the Microsoft Windows Server Active Directory, the highly secure Linux operating system SELinux, and the Unix operating system Solaris.

Go to Main Menu